WO1999060497A1 - Verfahren zur rechnergestützten simulation eines technischen systems - Google Patents

Verfahren zur rechnergestützten simulation eines technischen systems Download PDF

Info

Publication number
WO1999060497A1
WO1999060497A1 PCT/DE1999/001324 DE9901324W WO9960497A1 WO 1999060497 A1 WO1999060497 A1 WO 1999060497A1 DE 9901324 W DE9901324 W DE 9901324W WO 9960497 A1 WO9960497 A1 WO 9960497A1
Authority
WO
WIPO (PCT)
Prior art keywords
component
interface
components
main process
event
Prior art date
Application number
PCT/DE1999/001324
Other languages
English (en)
French (fr)
Inventor
Roland Rosen
Konrad WÖLLHAF
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to EP99931003A priority Critical patent/EP1078326A1/de
Publication of WO1999060497A1 publication Critical patent/WO1999060497A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/20—Design optimisation, verification or simulation

Definitions

  • the invention relates to a method for computer-aided simulation of a technical system, which system comprises several components.
  • Such systems are, in particular, large plants for the production or the coordination of chemical and / or physical processes.
  • Terms of object-oriented programming are known from [1].
  • a class is instantiated and an object of the type of the class is created.
  • any number of objects of the same type i.e. with the same functionality, can be instantiated.
  • the functionality is hidden (encapsulated) in the object, the access from outside or the message to the outside remains via predetermined interfaces, in particular through method calls.
  • a hierarchical structure of types is possible, which use common functionality via the mechanism of inheritance.
  • the object of the invention is to provide a method for computer-aided simulation of a technical system, which simulation before the planning is implemented ensures a significant reduction in planning errors and the associated costs.
  • the computer-aided simulation takes place in particular based on real plant components.
  • one component in particular is assumed to represent the real plant component.
  • a method for computer-aided simulation of a technical system comprises several components.
  • Each component contains at least one interface and a functionality is inscribed in each component.
  • the simulation of the technical system is carried out by assembling the several components and exchanging information between the components via the at least one interface, an interaction of the several components being controlled and evaluated on the basis of a main process.
  • the main process ensures in particular an interaction of the individual components and thus a simulation process by ensuring that the main process manages a simulated time (the time that would pass in the real replica of the simulated technical system).
  • a further development of the invention is that a component is a plant object.
  • the plant object is part of the technical system to be simulated.
  • the component is a
  • the instantiation of a class enables the creation of a (simulated) plant object, whereby all the described functionality of the plant object is available in this instance. If you need several plant objects of this type, they can be instantiated several times. Hierarchical types of plant objects that have different functionalities are created using the inheritance mechanism. The functionality of a plant object is encapsulated in the respective plant object and can only be accessed from the outside via predefined interfaces. In this way, many plant objects can be combined as a new plant object and made available as part of the technical system. According to the explanation from [1], the type of the plant object is declared as a class, an instance represents an actual representative of the class.
  • a technical system is understood to mean a more or less complex technical system, preferably from the field of process engineering, whereby each system can in turn be part of a higher-level - accordingly larger - system.
  • This hierarchical structuring is taken into account in particular by the mechanism of encapsulating the functionality of the plant object.
  • the component is in particular a plant object, e.g. Motor, pump, valve, pipeline, container, fitting, controller (PID, PI, P), machine tool, bearing, converter, transformer, generator, gear, propeller, busbar,
  • Circuit breaker hydraulics, and is preferably modeled by a suitable description form.
  • a suitable description form When describing the component, particular attention is paid to the specification to be simulated, i.e. the functionality of the component is simulated using the description form, preferably using systems of equations.
  • the main process (also: sequence control) ensures their functional interaction through suitable control of the components.
  • the main process also evaluates the
  • the at least one interface comprises a first partial interface and a second partial interface.
  • the first sub-interface has an input and an output, a material flow being modeled via the input and the output of the first sub-interface.
  • the second sub-interface also has an input and an output, a change in a manipulated variable of the component being carried out by the input of the second sub-interface and one by the output of the second sub-interface
  • Feedback about the state of the material flow and / or about a state of the change in the manipulated variable can be determined.
  • the component in particular the plant object, thus comprises a material flow relevant in process engineering (first sub-interface) and an information technology interface (second sub-interface).
  • the information technology interface is used in particular to control a manipulated variable of the respective component and to determine a target / actual difference between the set manipulated variable and the resulting manipulated variable.
  • the component in particular the plant object, is represented by at least one of the following forms of description:
  • a differential algebraic system includes both algebraic systems of equations as well
  • F is the filling quantity
  • t is the time
  • q 2u the inflow into the container
  • g_ab the outflow from the container
  • p the bottom pressure in the container
  • A the base area of the container
  • p the density of the liquid
  • g the acceleration due to gravity.
  • An event-discrete model means in particular a time-triggered model. Based on time units, a message is transmitted to the main process or to another component in order to initiate processing associated with a triggering time.
  • Interfaces of the components in particular have structural information. Using this structural information, it is possible to suitably model properties that result from the structure of the technical system (or the overall system).
  • the properties of the interfaces are set according to a state of a component, these
  • a closed valve gives the Structure property "pressure is set” does not pass on to an adjacent component.
  • a container surrenders the pressure at its interface. If a component is located between two closed valves, this special situation is known from the structural information within the component and can be taken into account in the modeling. Accordingly, the component provides a substitute value for the pressure that is used in the modeling.
  • the structural information inherent in the component is taken into account by the main process in such a way that this structural information is communicated across components in accordance with the predetermined connection of the components and thus potential conflicts of the simulation are resolved.
  • Another further development consists in that a process behavior is modeled by the first interface and a control behavior by the second interface.
  • the process behavior is understood to be the mapping of the material flow customary in process engineering to the model, with a control behavior of the information technology design equaling the target / actual value of the manipulated variables of a component.
  • the component generates messages via at least one of the following mechanisms:
  • the component generates a variable change with the address of a target component and transmits it to the main process; c) the component becomes one method of another
  • Called component by generating the name of the method with the address of the target component and transmitting it to the main process.
  • the main process comprises the following steps:
  • the management of the queue is the main process.
  • Another development consists in the fact that at least one interface of each component is designed in such a way that several components can be simply put together according to their underlying technical meaning.
  • the modularity of the individual components, which connect to one another via predefined interfaces, and a simulation sequence according to a technical system, which results from the way in which the components are connected to one another, is particularly advantageous.
  • Fig.l a component that forms part of the system to be simulated
  • Fig. 3 is a flow chart illustrating steps of a sequential control
  • FIG. 6 shows a process plant for a three-tank example.
  • Fig.l shows a sketch of a component, which is inscribed a functionality to be simulated.
  • Component 101 comprises a first partial interface (102, 103), which has an input 102 and an output 103, and models a material flow.
  • a second partial interface (104, 105) comprises an input 104, which input 104 enables a manipulated variable of component 101 to be changed, and an output 105, which Output 105 enables feedback on a state of the material flow and / or on a state of the change in the manipulated variable.
  • Such a component 101 represents a modular unit of a technical system to be simulated.
  • the component 101 is connected to further components via the interfaces (102-105).
  • the combination of several components is the technical system which is an object of the invention to simulate.
  • Interfaces can interact with components that have different functionalities, controlled by the main process.
  • the sequence controller 204 ensures that the simulation is carried out, both communication between the components and communication between a component and the sequence controller taking place.
  • the sequence controller 204 controls the components via the information technology interface (second sub-interface) and transfers the process behavior (material flow via the first sub-interface) taking into account a simulated time from one component to the next, with an influence on the process behavior in a respective component corresponding to that of the Component underlying technical functionality is taken into account.
  • process behavior first sub-interface
  • the control behavior second sub-interface, information technology interface
  • the process control assigns messages to the components.
  • FIG. 3 A flow diagram, which contains the steps of a main process 301 (sequence control), is shown in FIG.
  • the overall functionality of the component is created by combining the description forms. Both this combination and the interaction of different components is guaranteed by the main process.
  • Each form of description comprises one or more parts, which are referred to here as (description) segments. By naming the segments, the main process accesses the different segments, combines them and forms the corresponding sub-functionalities. 3 shows a segment in the form of a rectangle.
  • the main process 301 executes the system simulation for a predetermined time interval which is between "start interval” 302 and "end interval” 303. By repeatedly executing the main process 301, a longer period of time can be simulated.
  • the main process 301 calls up the segment "InputControl" 304 for all components, in which the inputs received from the simulation environment (for example user inputs, data from other programs, for example planning or control programs) are checked and accepted for each component become.
  • the inputs received from the simulation environment for example user inputs, data from other programs, for example planning or control programs
  • the main process 301 then processes the segment "SettingProperties" 305 for all components, in which the structural information that each component contributes is processed.
  • the main process then evaluates 301 this structural information (cf. block 306) and thus makes the results of the evaluation available to subsequent segments.
  • event-discrete modeling part 307 which is divided into a total of three segments.
  • a segment "InitDiscreteModel” 308 is called once for each component, then a segment “DiscreteModel” 309 is executed repeatedly for all components. The main process repeats this segment
  • Events that are to be taken into account at later times can be formulated within the three segments 307.
  • the main process stores these events and makes them (and the data associated with the event) available to the segments when the time of the event is reached.
  • the differential algebraic modeling part 311 which is divided into a total of seven segments, is now processed.
  • the two segments "SelectionOfVariables" 312 and “SelectionOfEquations” 313 store which variables and which equations (algebraic equations and / or ordinary differential equations) should be included in the modeling at the current time.
  • the definition of the equations is in the segments “G-Equations” 315 (for algebraic equations) and "F-Equations” 316 (for differential equations).
  • the main process collects this data 301 and evaluates the resulting differential algebraic system (see block 318).
  • the segment "JacobiEquations" 317 is optionally used, which allows the creation of the Jacobi matrix required for the mathematical solution of the system in minimal computing time.
  • the evaluation requires that the simulated time progresses.
  • the main process 301 controls this progress and stops the simulation computing time as soon as either an event time from the event-discrete model part or the end time of the time interval is reached.
  • the main process 301 also checks whether a switching function, which is described in the "SwitchmgFunctions" segment 314, is triggered during the evaluation.
  • a switching function can be used, for example, to check whether a time-dependent variable that is triggered by a
  • Differential equation is modeled, has exceeded or fallen below a certain limit. If this is the case, the main process 301 generates an event for the current point in time.
  • the segment "PostAlgebraic" 319 is called once for all components. Afterwards, if an event is pending, the system jumps back to evaluating the event-discrete event
  • the segment “PostExecution” 320 is called once for all components, in which, in particular, outputs are made to a user or to other connected programs.
  • FIG. 3 Not shown in FIG. 3 are two further segments that are called once by the main process for all components, at the time the simulation starts and immediately before the simulation ends. These two segments allow administrative and EDP measures (eg reading initialization files, closing files with additional statistical output, for example).
  • the message format 401 comprises a time stamp 403 which provides information about a point in time to be executed and an addressee 404, the target component.
  • a field 402 is also provided that classifies the type of message. If it is an event, this is shown in field 402 as well as if the message 401 is a notification of a change in the variable or the call of a function in a target component.
  • FIG. 5 shows a queue 501 over a time t.
  • a time t1 there are three events 502 to 504 in the queue, at a time t2 there is only the event 502 in the queue and at a time t3 the events 502 and 505 are in the queue.
  • events 503 and 504 have ended, i.e. Event 504 included in the
  • Fig. 6 shows a three-tank example of a process plant for mixing liquids.
  • the three tanks T1, T2 and T3 are connected to one another via valves VI, V2 and V3, it being possible for liquids S1 and S2 to be added in the tanks T1 and T3 via pumps P1 and P2.
  • the emerging material flow is indicated by arrow S3.
  • Domain fill level_type ⁇ set ⁇ empty, half full, full ⁇ Domain stepchain_tankstrom ⁇ set ⁇ ready, pretreatment tank_fuell, curistank_fuellen, clean, reaction tank_fuelll, reaction tank_fuellen2, react, empty
  • Terminal type volume flow ⁇ // 701 process ⁇ inoutdata ⁇ print: real default 1.0; flow: real default 0.0; ⁇
  • Component type pump (// 704 Parameters ⁇ q_min: real unit kubikmeter_ ro_sekünde; q max: real unit kubikmeter_per second; ⁇ ter inals ⁇ input: volume flow; output: volume flow; ⁇ behavior_descriptions ⁇ // 705 control ⁇
  • SetBalance (incoming. Flow, outgoing, flow); SetExplicitEquation (emgang. Flow);
  • Resistance coefficient real default 1.0; terminals ⁇ output: volume flow; output: volume flow;
  • JacobiVariables (gl, & input. Pressure, & output. Pressure, & input. Flow, 0);
  • JacobiVariables (gl, sea entrance. Flow, 0);
  • interface_connections ⁇ control.pm process. sr; Component type tank ⁇ parameters ⁇ height: real default 10.0 unit meter; initial level: real default 5.0 and t meter; footprint: real default 10.0 unit meter;
  • Interfaces ⁇ sr if tank pm2sr; variables ⁇ real height cont_state default 0.0; d_fuellhoehe real d ⁇ ff_quot; gT ⁇ ; l] real residue; g out [0; 2] real residue;
  • Component type source_sink ⁇ parameters ⁇ external pressure: real default 1.0 unit bar; ⁇ terms ⁇ output: volume flow; behav ⁇ or_descr ⁇ pt ⁇ ons ⁇ process ⁇ variables ⁇ gl: real residue; // residue;
  • the two interface values for the flow are identical in terms of the amount and in the
  • Modeling options that result from structural information and evaluations are not specifically listed in the present example, the "SettingProperties” segment is therefore not included;

Abstract

Eine reale technische Anlage wird rechnergestützt simuliert, wobei einzelne Anlagenkomponenten der technischen Anlage als Komponenten der Simulation modelliert werden und jede Komponente eine Schnittstelle für einen verfahrenstechnischen Stofffluß und eine informationstechnische Schnittstelle aufweist. Die Steuerung und die Interaktion der Komponenten untereinander zur Gewährleistung des zu simulierenden Gesamtsystems wird durch einen Hauptprozeß gewährleistet. Funktionalitäten des realen technischen Systems sind dabei in den Komponenten gekapselt, wobei der Stofffluß und die informationstechnische Schnittstelle das Verhalten jeder Komponente mit der Außenwelt bestimmen.

Description

Beschreibung
Verfahren zur rechnergestützten Simulation eines technischen Systems
Die Erfindung betrifft ein Verfahren zur rechnergestützten Simulation eines technischen Systems, welches System mehrere Komponenten umfaßt.
In der Verfahrenstechnik ist eine große Herausforderung die
Planung komplexer technischer Systeme. Derartige Systeme sind insbesondere große Anlagen für die Fertigung oder die Koordination chemischer und/oder physikalischer Prozesse.
Die Umsetzung einer fehlerhaften Planung führt unter
Umständen zu hohen Zusatzausgaben, ehe ein reibungsloser Ablauf der Anlage gewährleistet werden kann. Ein Planungsfehler stellt eine signifikante Größe in den Kosten für die Anlage dar.
Begriffe der objektorientierten Programmierung sind aus [1] bekannt. Insbesondere wird eine Klasse instantiiert und dabei ein Objekt vom Typ der Klasse geschaffen. Auf diese Art können beliebig viele Objekte des gleichen Typs, also mit jeweils gleicher Funktionalität, instantiiert werden. Dabei ist die Funktionalität in dem Objekt verborgen (gekapselt) , der Zugriff von außen bzw. die Mitteilung nach außen bleibt findet über vorgegebene Schnittstellen, insbesondere durch Methodenaufrufe, statt. Weiterhin ist eine hierarchische Struktur von Typen möglich, die auf eine gemeinsame Funktionalität über den Mechanismus der Vererbung zurückgreifen.
Die Aufgabe der Erfindung besteht darin, ein Verfahren zur rechnergestützten Simulation eines technischen Systems anzugeben, welche Simulation vor der Umsetzung der Planung eine deutliche Reduzierung der Planungsfehler und der damit verbundenen Kosten sicherstellt.
Diese Aufgabe wird gemäß den Merkmalen des unabhängigen Patentanspruchs gelöst.
Die rechnergestützte Simulation findet insbesondere in Anlehnung an reale Anlagenkomponenten statt. Nachfolgend wird insbesondere von einer Komponente als eine Abbildung der realen Anlagenkomponente ausgegangen.
Es wird ein Verfahren zur rechnergestützten Simulation eines technischen Systems angegeben, welches (simulierte) System mehrere Komponenten umfaßt. Dabei enthält jede Komponente mindestens eine Schnittstelle, und jeder Komponente ist eine Funktionalität einbeschrieben. Die Simulation des technischen Systems wird durchgeführt, indem die mehreren Komponenten zusammengefügt werden und über die mindestens eine Schnittstelle Information zwischen den Komponenten ausgetauscht wird, wobei anhand eines Hauptprozesses ein Zusammenwirken der mehreren Komponenten gesteuert und ausgewertet wird.
Der Hauptprozeß stellt insbesondere ein Interagieren der einzelnen Komponenten und somit einen Simulationsablauf sicher, indem eine Verwaltung einer simulierten Zeit (die Zeit, die in der realen Nachbildung des simulierten technischen Systems vergehen würde) von dem Hauptprozeß gewährleistet wird.
Eine Weiterbildung der Erfindung besteht darin, daß eine Komponente ein Anlagenobjekt ist. Das Anlagenobjekt ist ein Teil des zu simulierenden technischen Systems.
Auch ist es eine Weiterbildung, daß die Komponente eine
Instanz einer Klasse eines objektorientierten Programms ist, durch welche Klasse der Typ des Anlagenobjekts beschrieben wird.
Gemäß den Möglichkeiten der objektorientierten Programmierung (vgl. [1]) ermöglicht die Instantiierung einer Klasse die Erschaffung eines (simulierten) Anlagenobjekts, wobei alle einbeschriebene Funktionalität des Anlagenobjekts in dieser Instanz verfügbar ist. Benötigt man mehrere Anlagenobjekte dieses Typs, so können diese mehrfach instantiiert werden. Hierarchische Typen von Anlagenobjekten, die unterschiedliche Funktionalitäten aufweisen, werden über den Mechanismus der Vererbung erzeugt. Die Funktionalität eines Anlagenobjekts ist in dem jeweiligen Anlagenobjekt gekapselt und von außen nur über vorgegebene Schnittstellen erreichbar. Auf diese Weise können viele Anlagenobjekte als ein neues Anlagenobjekt zusammengefaßt und als Teil des technischen Systems bereitgestellt werden. Gemäß der Erklärung aus [1] wird der Typ des Anlagenobjekts als eine Klasse vereinbart, eine Instanz stellt einen tatsächlichen Repräsentanten der Klasse dar.
Ein Vorteil ist darin zu sehen, daß lediglich im Zusammenschluß mehrerer Komponenten, die vorzugsweise Anlagenobjekte darstellen, eine Simulation eines vollständigen technischen Systems in Koordination durch einen Hauptprozeß ermöglicht wird.
Hierbei sei angemerkt, daß neben der objektorientierten Programmierung auch eine prozedurale Programmierung des Verfahrens möglich ist. Allerdings stellt die objektorientierte Programmierung bereits Funktionalitäten bereit, deren Verwendung die beschriebenen Vorteile begründet .
Nachfolgend werden einige Begriffe, die im Zusammenhang mit der vorliegenden Erfindung genannt sind, erläutert. Technisches System:
Unter einem technischen System wird eine mehr oder minder komplexe technische Anlage, vorzugsweise aus dem Bereich der Verfahrenstechnik, verstanden, wobei jede Anlage wiederum ein Teil einer übergeordneten - dementsprechend größeren - Anlage sein kann. Dieser hierarchischen Strukturierung wird insbesondere durch den Mechanismus der Kapselung der Funktionalität des Anlagenobjekts Rechnung getragen.
- Komponente :
Die Komponente ist insbesondere ein Anlagenobjekt, z.B. Motor, Pumpe, Ventil, Rohrleitung, Behälter, Formstück, Regler (PID, PI, P) , Werkzeugmaschine, Lager, Stromrichter, Trafo, Generator, Getriebe, Propeller, Sammelschiene,
Leistungsschalter, Hydraulik, und wird bevorzugt durch eine geeignete Beschreibungsform modelliert. Bei der Beschreibung der Komponente wird insbesondere geachtet auf die zu simulierende Vorgabe, d.h. die Funktionalität der Komponente wird anhand der Beschreibungsform, vorzugsweise durch Gleichungssysteme, nachgebildet.
Die oben genannten Beispiele für Komponenten stellen keine vollständige Menge aller möglichen Komponenten dar, sondern deuten vielmehr an, inwieweit unterschiedliche Komponenten modelliert werden können.
- Hauptprozeß :
Der Hauptprozeß (auch: Ablaufsteuerung) gewährleistet durch geeignete Ansteuerung der Komponenten deren funktionales Zusammenwirken. Ferner wertet der Hauptprozeß die
Ergebnisse der einzelnen Komponenten aus und stellt sie einem Benutzer vorzugsweise graphisch dar.
- Simulationsrechenzeit: Eine Zeit, die zur Durchführung der Simulation benötigt wird. Eine andere Weiterbildung besteht darin, daß die mindestens eine Schnittstelle eine erste Teilschnittstelle und eine zweite Teilschnittstelle umfaßt. Dabei weist die erste Teilschnittstelle einen Eingang und einen Ausgang auf, wobei über den Eingang und den Ausgang der ersten Teilschnittstelle ein Stoff-Fluß modelliert wird. Die zweite Teilschnittstelle weist ebenfalls einen Eingang und einen Ausgang auf, wobei durch den Eingang der zweiten Teilschnittstelle eine Veränderung einer Stellgröße der Komponente durchgeführt wird und durch den Ausgang der zweiten Teilschnittstelle eine
Rückmeldung über den Zustand des Stoff-Flusses und/oder über einen Zustand der Veränderung der Stellgröße ermittelbar ist.
Somit umfaßt die Komponente, insbesondere das Anlagenobjekt, einen in der Verfahrenstechnik relevanten Stoff-Fluß (erste Teilschnittstelle) und eine informationstechnische Schnittstelle (zweite Teilschnittstelle) . Die informationstechnische Schnittstelle wird insbesondere verwendet zur Steuerung einer Stellgröße der jeweiligen Komponente und Ermittlung eines Soll/Ist-Unterschieds zwischen der eingestellten Stellgröße und der sich ergebenden Stellgröße .
Die Komponente, insbesondere das Anlagenobjekt, wird durch mindestens eine der folgenden Beschreibungsformen dargestellt :
a) Differentialalgebraisches System:
Ein differentialalgebraisches System umfaßt sowohl algebraische Gleichungssysteme als auch
Differentialgleichungssysteme, um die vorgegebene Funktionalität des Anlagenobjekts zu beschreiben. Ein Beispiel für ein differentialalgebraisches System ist die Modellierung eines Behälters:
ÖF dt = Qzu - 3ab F • P
A
wobei F die Füllmenge, t die Zeit, q2u den Zufluß in den Behälter, g_ab den Abfluß aus dem Behälter, p den Bodendruck in dem Behälter, A die Grundfläche des Behälters, p die Dichte der Flüssigkeit und g die Erdbeschleunigung bezeichnen.
b) Ereignisdiskretes Modell:
Unter einem ereignisdiskreten Modell versteht man insbesondere eine zeitgetriggerte Modellierung. Basierend auf Zeiteinheiten erfolgt eine Nachrichtenübermittlung an den Hauptprozeß oder an eine andere Komponente, um dort eine mit einem Auslöse-Zeitpunkt verknüpfte Bearbeitung anzustoßen.
c) Strukturinformation:
Schnittstellen der Komponenten weisen insbesondere eine Strukturinformation auf. Anhand dieser Strukturinformation ist es möglich, Eigenschaften, die sich aus der Struktur des technischen Systems (bzw. des Gesamtsystems) ergeben, geeignet zu modellieren.
Einem Zustand einer Komponente entsprechend werden die Eigenschaften der Schnittstellen gesetzt, diese
Eigenschaften an Schnittstellen anderer Komponenten durchgereicht, abgefragt oder blockiert (nicht weitergegeben) . Die Strukturinformation läßt sich im Rahmen der Modellierung auf verschiedene Art und Weise verwenden.
Beispielsweise gibt ein geschlossenes Ventil die Struktureigenschaft "Druck ist gesetzt" nicht an eine benachbarte Komponente weiter. Ein Behälter hingegeben legt den Druck an seinen Schnittstelle fest. Befindet sich eine Komponente zwischen zwei geschlossenen Ventilen, ist diese spezielle Situation durch die Strukturinformation innerhalb der Komponente bekannt und kann bei der Modellierung berücksichtigt werden. Dementsprechend stellt die Komponente einen Ersatzwert für den Druck bereit, der in die Modellierung einfließt.
Die der Komponente innewohnende Strukturinformation wird von dem Hauptprozeß derart berücksichtigt, daß diese Strukturinformation über Komponenten hinweg entsprechend der vorgegebenen Verbindung der Komponenten kommuniziert wird und somit potentielle Konflikte der Simulation aufgelöst werden.
Eine andere Weiterbildung besteht darin, daß durch die erste Schnittstelle ein Prozeßverhalten und durch die zweite Schnittstelle ein Kontrollverhalten modelliert wird.
Unter dem Prozeßverhalten versteht man die Abbildung des in der Verfahrenstechnik üblichen Stoff-Flusses auf das Modell, wobei ein Kontrollverhalten der informationstechnischen Auslegung von Soll/Ist-Wert der Stellgrößen einer Komponente gleichkommt.
Auch ist es eine Weiterbildung, daß die Komponente über mindestens eine der folgenden Mechanismen Nachrichten erzeugt:
a) Von der Komponente selbst wird ein Ereignis (engl.
Fachbegriff: Event) generiert und an den Hauptprozeß übermittelt;
b) von der Komponente wird eine Variablenänderung mit der Adresse einer Zielkomponente generiert und an den Hauptprozeß übermittelt; c) von der Komponente wird eine Methode einer anderen
Komponente aufgerufen, indem die Bezeichnung der Methode mit der Adresse der Zielkomponente generiert und an den Hauptprozeß übermittelt wird.
Im Rahmen einer Ausgestaltung umfaßt der Hauptprozeß folgende Schritte :
a) Das Ereignis wird in einer Warteschlange abgespeichert.
b) Wenn das Ereignis fällig ist, d.h. wenn der Zeitpunkt der Fälligkeit in der simulierten Zeit erreicht ist, wird dieses Ereignis an den Adressaten weitergeleitet und dort ausgeführt; das Ereignis wird in diesem Fall aus der Warteschlange gelöscht.
Die Verwaltung der Warteschlange liegt beim Hauptprozeß.
Eine andere Weiterbildung besteht darin, daß mindestens eine Schnittstelle jeder Komponente derart ausgeführt ist, daß mehrere Komponenten entsprechend ihrer zugrundeliegenden technischen Bedeutung einfach zusammengefügt werden können. Dabei ist insbesondere die Modularität der einzelnen Komponenten von Vorteil, die über vorgegebene Schnittstellen miteinander in Verbindung treten und einen Simulationsablauf entsprechend einem technischen System, das sich aus der Art und Weise der Verbindung der Komponenten untereinander ergibt, gewährleistet ist.
Insbesondere sei an dieser Stelle darauf hingewiesen, daß der in vorliegendem Dokument beschriebene Stoff-Fluß unabhängig von der im Modell angegebenen Richtung modelliert werden kann. Somit bedingen Eingang und Ausgang einer Komponente nicht die Richtung des Stoff-Flusses. Bei Eingang und Ausgang handelt es sich lediglich um bei der Modellierung bezeichnete Schnittstellen der jeweiligen Komponente. Weiterbildungen der Erfindung ergeben sich auch aus den abhängigen Ansprüchen.
Ausführungsbeispiele der Erfindung werden nachfolgend anhand der Zeichnung dargestellt und erläutert.
Es zeigen
Fig.l eine Komponente, die einen Teil des zu simulierenden Systems darstellt;
Fig.2 einen Verbund aus mehreren Komponenten, die von einer Ablaufsteuerung verwaltet werden;
Fig.3 ein Flußdiagramm, das Schritte einer Ablaufsteuerung darstellt;
Fig.4 ein Nachrichtenformat, das zur Kommunikation zwischen Komponenten bzw. zwischen Komponente und Hauptprozeß verwendet wird;
Fig.5 eine Warteschlange, die von der Ablaufsteuerung bearbeitet wird;
Fig.6 eine verfahrenstechnische Anlage für ein Drei-Tank- Beispiel.
Fig.l zeigt eine Skizze einer Komponente, der eine zu simulierende Funktionalität einbeschrieben ist. Die Komponente 101 umfaßt eine erste Teilschnittstelle (102, 103) , die einen Eingang 102 und einen Ausgang 103 aufweist, und einen Stoff-Fluß modelliert. Eine zweite Teilschnittstelle (104, 105) umfaßt einen Eingang 104, welcher Eingang 104 eine Veränderung einer Stellgröße der Komponente 101 ermöglicht, und einen Ausgang 105, welcher Ausgang 105 eine Rückmeldung über einen Zustand des Stoff- Flusses und/oder über einen Zustand der Veränderung der Stellgröße ermöglicht.
Eine derartige Komponente 101 stellt eine modulare Einheit eines zu simulierenden technischen Systems dar. Über die Schnittstellen (102-105) wird die Komponente 101 mit weiteren Komponenten verbunden. In dem Zusammenschluß mehrerer Komponenten besteht das technische System, das zu simulieren ein Ziel der Erfindung darstellt. Durch die normierten
Schnittstellen können Komponenten, denen unterschiedliche Funktionalitäten einbeschrieben sind, gesteuert durch den Hauptprozeß, interagieren.
Fig.2 zeigt einen möglichen Zusammenschluß dreier Komponenten (201, 202, 203) deren Schnittstellen (205, 206, 207) jeweils mit einer Ablaufsteuerung 204 verbunden sind. Die Ablaufsteuerung 204 gewährleistet die Durchführung der Simulation, wobei sowohl eine Kommunikation zwischen den Komponenten als auch eine Kommunikation zwischen einer Komponente und der Ablaufsteuerung erfolgt. Die Ablaufsteuerung 204 steuert die Komponenten über die informationstechnische Schnittstelle (zweite Teilschnittstelle) und überträgt das Prozeßverhalten (Stoff- Fluß über erste Teilschnittstelle) unter Berücksichtigung einer simulierten Zeit von einer Komponente zur nächsten, wobei ein Einfluß auf das Prozeßverhalten in einer jeweiligen Komponente entsprechend der der Komponente zugrundeliegenden technischen Funktionalität, berücksichtigt wird. Zu jedem (diskreten) Zeitpunkt der simulierten Zeit erfolgt eine Abarbeitung aller zu diesem Zeitpunkt anstehenden parallelen Aktionen. Dabei werden das Prozeßverhalten (erste Teilschnittstelle) und das Kontrollverhalten (zweite Teilschnittstelle, informationstechnische Schnittstelle) für die Beeinflussung des Stoff-Flusses der Ablaufsteuerung mitgeteilt bzw. von der Ablaufsteuerung an die betroffenen Komponenten verteilt. Die Zuordnung von Nachrichten zu den Komponenten übernimmt die Ablaufsteuerung.
Ein Ablaufdiagramm, das die Schritte eines Hauptprozesses 301 (Ablaufsteuerung) enthält, ist in Fig.3 dargestellt. Zur Beschreibung einer Funktionalität der Komponente stehen verschiedene Beschreibungsformen (Differentialalgebraisches System, ereignisdiskretes Modell, Strukturinformation) zur Auswahl, die jeweils für eine bestimmte Teilfunktionalität geeignet sind. Durch Kombination der Beschreibungsformen entsteht die Gesamtfunktionalität der Komponente. Sowohl diese Kombination als auch das Zusammenwirken verschiedener Komponenten wird vom Hauptprozeß gewährleistet. Jede Beschreibungsform umfaßt ein oder mehrere Teile, die hier als (Beschreibungs-) Segmente bezeichnet werden. Durch Benennung der Segmente greift der Hauptprozeß auf die unterschiedlichen Segmente zu, kombiniert sie und bildet entsprechende Teilfunktionalitäten. In Fig.3 ist ein Segment in Form eines Rechtecks dargestellt.
Der Hauptprozeß 301 führt die Anlagensimulation für ein vorgegebenes Zeitintervall aus, das zwischen "Start intervall" 302 und "End intervall" 303 liegt. Durch wiederholtes Ausführen des Hauptprozesses 301 kann eine längere Zeitdauer simuliert werden.
Zu Beginn des Zeitintervalls ruft der Hauptprozeß 301 für alle Komponenten das Segment "InputControl" 304 auf, in dem für jede Komponente die von der Simulationsumgebung eingetroffenen Eingaben (z.B. Benutzereingaben, Daten anderer Programme, z.B. Planungs- oder Steuer-/Regelungsprogramme) überprüft und übernommen werden.
Daraufhin wird vom Hauptprozeß 301 für alle Komponenten das Segment "SettingProperties" 305 abgearbeitet, in der die Strukturinformation, die jede Komponente beiträgt, aufbereitet wird. Anschließend wertet der Hauptprozeß 301 diese Strukturinformation aus (vgl. Block 306) und stellt damit nachfolgenden Segmenten Ergebnisse der Auswertung zur Verfügung.
Es schließt sich nun der ereignisdiskrete Modellierungsteil 307 an, wobei dieser auf insgesamt drei Segmente aufgeteilt wird. Zunächst wird für jede Komponente einmalig ein Segment "InitDiscreteModel" 308 aufgerufen, anschließend wird wiederholt für alle Komponenten ein Segment "DiscreteModel" 309 ausgeführt. Der Hauptprozeß wiederholt dieses Segment
"DiscreteModel" 309 für alle Komponenten so lange, wie neue Daten über die Schnittstellen, die zwischen den Komponenten bestehen, zu den Komponenten gelangen. Abgeschlossen wird dieser Modellierungsteil durch den einmaligen Aufruf des Segmentes "PostDiscreteModel" 310 für alle Komponenten.
Innerhalb der drei Segmente 307 können Ereignisse, die zu späteren Zeitpunkten berücksichtigt werden sollen, formuliert werden. Der Hauptprozeß speichert diese Ereignisse und stellt sie (und die mit dem Ereignis verbundenen Daten) bei Erreichen des Ereigniszeitpunktes den Segmenten zur Verfügung.
In den ereignisdiskreten Segmenten können zusätzlich auch strukturrelevante Daten modifiziert werden. Dies führt unmittelbar zu einem Rücksprung vor die Ausführung der Komponenten-Segmente "SettingProperties" 305.
Nun wird der differentialalgebraische Modellierungsteil 311, der in insgesamt sieben Segmente unterteilt ist, abgearbeitet. In den beiden Segmenten "SelectionOfVariables" 312 und "SelectionOfEquations" 313 wird hinterlegt, welche Variablen und welche Gleichungen (algebraische Gleichungen und/oder gewöhnliche Differentialgleichungen) zum aktuellen Zeitpunkt in die Modellierung eingehen sollen. Die Definition der Gleichungen befindet sich in den Segmenten "G-Equations" 315 (für algebraische Gleichungen) und "F-Equations" 316 (für Differentialgleichungen) . Diese Daten sammelt der Hauptprozeß 301 auf und wertet das so entstehende differentialalgebraische System aus (vgl. Block 318). Dabei wird optional das Segment "JacobiEquations" 317 verwendet, das die Erstellung des zur mathematischen Lösung des Systems erforderliche Jacobi-Matrix in minimaler Rechenzeit erlaubt. Die Auswertung bedingt, daß die simulierte Zeit voranschreitet. Der Hauptprozeß 301 kontrolliert dieses Voranschreiten und stoppt die Simulationsrechenzeit, sobald entweder ein Ereigniszeitpunkt aus dem ereignisdiskreten Modellteil oder der Endzeitpunkt des Zeitintervalls erreicht ist. Außerdem kontrolliert der Hauptprozeß 301, ob wahrend der Auswertung eine Schaltfunktion, die im Segment "SwitchmgFunctions" 314 beschrieben ist, ausgelöst wird. Mit einer Schaltfunktion kann beispielsweise geprüft werden, ob eine zeitabhängige Variable, die durch eine
Differentialgleichung modelliert wird, eine bestimmte Schranke über- oder unterschritten hat. Ist dies der Fall, so wird vom Hauptprozeß 301 ein Ereignis für den aktuelle Zeitpunkt erzeugt.
Liegt (mindestens) ein Ereignis an bzw. ist der Endzeitpunkt für ein Ereignis erreicht, so wird einmalig für alle Komponenten das Segment "PostAlgebraic" 319 aufgerufen. Danach erfolgt im Falle des Anliegens eines Ereignisses ein Rucksprung vor die Auswertung des ereignisdiskreten
Modellteils, in dem das (die) Ereignis (se) berücksichtigt werden.
Ist der Endzeitpunkt erreicht, so wird einmalig für alle Komponenten das Segment "PostExecution" 320 aufgerufen, in dem insbesondere Ausgaben an einen Benutzer oder an andere angeschlossene Programme erfolgen.
Nicht abgebildet in der Figur Fig. 3 sind zwei weitere Segmente, die für alle Komponenten einmalig, zum Zeitpunkt des Programmstartes der Simulation und unmittelbar vor Programmende der Simulation vom Hauptprozeß aufgerufen wird. Diese beiden Segmente erlauben verwaltungstechnische und EDV- technische Maßnahmen (z.B. Lesen von Initialisierungsdateien, Schliessen von Dateien mit beispielsweise statistschen Zusatzausgaben) .
Fig.4 zeigt ein bevorzugtes Nachrichtenformat 401 für die beschriebenen Ereignisse und/oder Nachrichten. Das Nachrichtenformat 401 umfaßt einen Zeitstempel 403, der Aufschluß über einen auszuführenden Zeitpunkt gibt und einen Adressaten 404, die Zielkomponente. Ferner ist ein Feld 402 vorgesehen, daß die Art der Nachricht klassifiziert. Handelt es sich um ein Ereignis, so ist dies in Feld 402 ebenso angezeigt, wie wenn es sich bei der Nachricht 401 um eine Benachrichtigung über eine Variablenänderung oder den Aufruf einer Funktion in einer Zielkomponente handelt.
Fig.5 zeigt eine Warteschlange 501 über einer Zeit t. Zu einem Zeitpunkt tl befinden sich drei Ereignisse 502 bis 504 in der Warteschlange, zu einem Zeitpunkt t2 befindet sich nur noch das Ereignis 502 in der Warteschlange und zu einem Zeitpunkt t3 befinden sich die Ereignisse 502 und 505 in der Warteschlange. Zu dem Zeitpunkt tl sind die Ereignisse 503 und 504 beendet worden, d.h. Ereignis 504 enthielt in dem
Feld 403 (Zeitstempel) den Zeitpunkt t]_, zu dem Zeitpunkt t3 ist das Ereignis 505 neu in die Warteschlange eingetragen worden.
Fig.6 zeigt ein Drei-Tank-Beispiel für eine verfahrenstechnische Anlage zur Mischung von Flüssigkeiten. Die drei Tanks Tl, T2 und T3 sind über Ventile VI, V2 und V3 miteinander verbunden, wobei in den Tanks Tl und T3 über Pumpen Pl und P2 Flüssigkeit Sl und S2 hinzugegeben werden kann. Über den Pfeil S3 wird der austretende Stoff-Fluß angezeigt . Nachfolgend wird gezeigt, wie die Komponenten zur Modellierung der Anlage von Fig.6 aus Sicht der Prozeßmodellierung beschrieben werden. Mit Hilfe dieser Komponenten wird ein einfaches und funktionsfähiges
Simulationsmodell für die in Fig.6 dargestellte Anlage erstellt. Dazu wird eine an die Programmiersprache C++ angelehnte Notation verwendet.
Einige wichtige Erläuterungen sind nachfolgend als Kommentare 701 bis 713, eingeleitet durch "//", in dem Quellcode vorgenommen. Die Beschreibungen zu den einzelnen Bezugszeichen 701 bis 713 erfolgt im -Anschluß an den Quellcode .
QUELLCODE FÜR DREI-TANK-BEISPIEL:
ComponentLibrary n_tank { Domain binary { ränge [0;1] )
Domain auf_zu { set { zu, auf } }
Domain notaus_typ { set { notaus, notaus_rueckname ) )
Domain fehlermeldungen { set ( pumpe_defekt, pumpe_ok } }
Domain fuellgrad_typ { set { leer, halbvoll, voll } } Domain schrittkette_tankanlage { set { bereit, vorbehandlungstank_fuellen, reinigungstank_fuellen, reinigen, reaktionstank_fuellenl , reaktionstank_fuellen2, reagieren, leeren
} Terminaltype volumenstrom { // 701 process { inoutdata { druck: real default 1.0; durchfluss: real default 0.0; }
Connectiontype volumenstrom_verbindung { terminals { ende a: volumenstrom; ende b: volumenstrom; behavior_des criptions { proces s { body (
SelectionOf Equations ( ) { $ SetBalance ( ende_a . durchfluss , ende_b . durchf lus s ) ; // 702a
Setidentity ( ende_a . druck, ende_b . druck) ; $ // 702b } } } }
}
// 703 Interfacetype if_pumpe_sr2pm { inputevents ( rueckmeldung: bool default false; // false: steht, true: laeuft q__ist : real default 0.0;
} outputsynchronousevents { q_soll : real default 0.0; } } Interfacetype if_tank_pm2sr { Outputevents { fuellstand : real default 0.0; } }
Interfacetype if_ventil_sr2pm { inputevents { rueckmeldung_auf : bool default false; rueckmeldung_zu: bool default true; } outputsynchronousevents { zustand_soll : auf_zu default zu; }
}
Componenttype pumpe ( // 704 Parameters { q_min: real unit kubikmeter_ ro_sekünde; q max: real unit kubikmeter_pro Sekunde; } ter inals { eingang: volumenstrom; ausgang: volumenstrom; } behavior_descriptions { // 705 control {
process mterfaces { sr : ιf__pumpe_sr2pm mverted;
} variables { } body { // 706
SelectionOfEquations () {$
SetBalance (emgang. durchfluss, aus gang, durchf luss ) ; SetExplicitEquation (emgang. durchf luss) ;
$} G_Equatιons ( ) { $ emgang. durchfluss = (double) sr.q_soll; $) PostExecutio ( ) ($ lf ( sr.q_soll > 0.0 ) sr . rueckmeldung = true; eise sr. rueckmeldung = false; sr.q_ιst = sr.q_soll;
$)
} visualization { // 707
1 terface connections {
Componenttype ventil { Parameters {
Widerstandsbeiwert: real default 1.0; terminals { emgang: volumenstrom; ausgang: volumenstrom;
) behavιor_descrιpt ons ( control {
} process { terfaces { sr : f_ventιl_sr2pm mverted;
} variables { gl : real residue; state_offen : bool dιsc_state;
} body {
InitSimulation ( ) ($ f( widerstandsbeiwert <= 0.0 ){
Erro C'Value for parameter widerstandsbeiwert = %g not valid", (double) widerstandsbeiwert) ; } if ( ! eingang. IsConnected( ) ) {
Error ( "Terminal %z not connected", eingang. getFullName ()) ; } if ( ! ausgang. IsConnected( ) ) {
Error ("Terminal %z not connected", ausgang. getFullName ()) ; } state_offen = false; // 708 $}
InitDiscreteModel ( ) {$ if ( (sr . zustand_soll. value ( ) == auf_zu: : auf ) ) { state_offen = true; ) if ( (sr. zustand_soll .value ( ) == auf_zu::zu)) { state_offen = false; 1 $}
SelectionOfEquations ( ) {$
SetBalance (eingang. durchfluss, ausgang. durchfluss ) ; SelectGEquation (gl) ; if (state__offen) (
JacobiVariables (gl, &eingang. druck, &ausgang. druck, &eingang. durchfluss ,0) ;
} eise {
JacobiVariables (gl, Seingang. durchfluss, 0) ;
} $)
G_Equations ( ) { $ if (state_offen) { gl = eingang. durchfluss*widerstandsbeiwert - (eingang . druck- ausgang. druck) ; // 709 } eise { gl = eingang. durchfluss; } $)
PostExecution ( ) {$ if (state_offen) ( sr . rueckmeldung_auf = true; sr . rueckmeldung_zu = false; ) eise { sr. rueckmeldung_auf = false; sr . rueckmeldung_zu = true; )
visualization {
) interface_connections { control.pm = process. sr; Componenttype tank { parameters { hoehe: real default 10.0 unit meter; anfangsfuellhoehe : real default 5.0 un t meter; grundflaeche : real default 10.0 unit meter;
) ter als { eingang [0; 1] : volumenstrom; ausgang [ 1;2] : volumenstrom; ) behavιor_descrιptιons ( control {
process {
Interfaces { sr : if tank pm2sr; variables { fuellhoehe real cont_state default 0.0; d_fuellhoehe real dιff_quot; gTθ;l] real residue; g out[0;2] real residue;
1 body (
In tSimulationO { $ II 710 g. set_sιze (eingang. size ()) ; g.notιfy(thιs, "g") ; g_out . set_sιze (ausgang . size ( ) ) ; g_out.notιfy (this, "g_out") ; fuellhoehe . pm_mιt (0.0) ; $ }
SelectionOfEquations ( ) {$ int l ; for (ι=0; Ke gang. s ze ( ) ; ι++) { if (emgang [l] . IsConnected () ) { SelectGEquation (g [l] ) ;
JacobiVariables (g[ι] , &eingang [I] .druck, 0) ; ) ) for(ι=0; Kausgang. size ( ) ; ++) { if (ausgang.i] . IsConnectedf ) ) ( SelectGEquation (g_out [l] ) ; JacobiVariables (g_out [l] , &ausgang [l] . druck, 0) ;
} }
SelectFEquation (d_fuellhoehe, fuellhoehe, "fuellhoehe" ) $}
G_Equatιons ( ) { $
Figure imgf000021_0001
double Bodendruck = fuellhoehe / 10.0 + 1.0; for (ι=0; Kemgang. size () ; ι++) ( if (IsSelectedGEquation (g[ι] ) ) { g[ι] = eingang [1] .druck - 1.0; } ) for (ι=0; Kausgang. size ( ) ; ι++) ( if (IsSelectedGEquation (g_out [I] ) ) { g_out[ι] = ausgang [ ] .druck - Bodendruck; ) } $}
PostExecution ( ) {$ sr . fuellstand = fuellhoehe;
$1
F_Equatιons ( ) {$ int I; double zufluss = 0.0; for ( =0; Kemgang. size () ; ι++) { if (emgang [l] . IsConnected () ) { zufluss += emgang.i] .durchfluss; ) } for (ι=0; Kausgang. size () ; ι++) ( if (ausgang [ ] . IsConnected () ) { zufluss += ausgang[ι] .durchfluss; ) } d_fuellhoehe = zufluss / grundflaeche; // 711
$)
} 1 visualization { mterfaces { sr : ιf_tank_sr2v s mverted; ) } } mterface_connectιons ( control.pm = process. sr; control.vis = visualization. sr;
}
Componenttype quelle_senke { Parameters { aussendruck: real default 1.0 unit bar; } termmals { emausgang: volumenstrom; behavιor_descrιptιons { process { variables { gl : real residue; //residue;
body ( InitSimulation ( ) ($ if ( ! einausgang. IsConnected ( ) ) { Error ("Terminal %z not connected" , einausgang . getFullName ( ) ) ; ) $)
SelectionOfEquations ( ) {$ SelectGEquation (gl) ;
JacobiVariables (gl, &einausgang. druck, 0) ; $}
G_Equations ( ) { $ gl = aussendruck - einausgang. druck;
$)
Componenttype tank_anlage { Parameters { 1 parts { // 712 vorbehandlungstank : tank; reinigungstank [1;] : tank; reaktortank : tank; ventil [l;number (reinigungstank) +1] : ventil; ausgangsventil : ventil; pumpel: pumpe; pumpe2 : pumpe; quellel : quelle_senke; quelle2 : quelle_senke; senke : quelle_senke;
} connections { quellel . einausgang = pumpel . eingang; pumpel. ausgang = vorbehandlungstank. eingang [1] ; vorbehandlungstank. ausgang [1] = ventil [1] . eingang; forall I in [ l;number (reinigungstank) ] ventil [I] . ausgang = reinigungstank [I] . ausgang [1] ; forall I in [ 1; number (reinigungstank) ] reinigungstank [I] . ausgang [2] = ventil [1+1] . eingang; ventil [number (reinigungstank) +1] .ausgang = reaktortank. ausgang [1] ; reaktortank. ausgang [2] = ausgangsventil . eingang; ausgangsventil . ausgang = senke . einausgang; quelle2. einausgang = pumpe2. eingang; pumpe2. ausgang = reaktortank. eingang [ 1] ; ) behavior_descriptions { control (
process { } // 713 visualization ( interfaces { sr : if_tankanlage_vis2sr ;
}
) } interface_connections { control.vis = visualization. sr; ) }
}
Die Bezugszeichen 701 bis 713 werden nachfolgend kurz erläutert:
701: Definition der Schnittstelle für den Stoff-Fluß;
702a: "SetBalance" bewirkt, daß bei Verwendung dieser
Verbindung die beiden Schnittstellenwerte für den Durchfluß dem Betrag nach identisch und sich im
Vorzeichen unterscheiden (die Bilanz ist dann gleich Null) ;
702b: "Setidentitiy" bewirkt eine Identifizierung der beiden Druckwerte;
703: Definition der informationstechnischen Schnittstellen;
704: Definition der Komponententypen;
705: eine Funktionalität der Komponente, die außerhalb des prozeßtechnischen Modells liegt;
706: Beschreibung des prozeßtechnischen Modells in Segmenten;
707: Hinterlegung besonderer Visualisierungsinformation;
708: diskrete Modellierung des Ventilzustands (offen/geschlossen) ; 709: gl ist eine algebraische Gleichung, die dann gelöst ist, wenn der Wert von gl Null wird;
710: Modellierungsmöglichkeiten, die sich mit Strukturinformationen und -auswertungen ergeben, sind in vorliegendem Beispiel nicht extra aufgeführt, das Segment "SettingProperties" wird daher nicht aufgenommen;
711: mit "d_fuellhoehe" wird der Differentialquotient für die Differentialgleichung zur Variable "fuellhoehe" beschrieben;
712: Festlegung der Komponenten und deren struktureller Beziehungen;
713: leeres Prozeßmodell.
Literaturverzeichnis :
[1] U. Claussen: Objektorientiertes Programmieren - Mit Beispielen und Übungen in C++, Springer Verlag, Heidelberg 1993, ISBN 3-540-55748-2, Seiten 17-43.

Claims

Patentansprüche
1. Verfahren zur rechnergestützten Simulation eines technischen Systems, welches System mehrere Komponenten umfaßt, a) bei dem jede der mehreren Komponenten mindestens eine Schnittstelle umfaßt, b) bei dem jeder Komponente gemäß einer zu simulierenden Vorgabe eine Funktionalität einbeschrieben ist, c) bei dem die Simulation durch ein Zusammenfügen der mehreren Komponenten durchgeführt wird, wobei über die mindestens eine Schnittstelle Information zwischen den Komponenten ausgetauscht wird und anhand eines Hauptprozesses ein Zusammenwirken der mehreren Komponenten gesteuert und ausgewertet wird.
2. Verfahren nach Anspruch 1, bei dem die Komponente ein Anlagenobjekt ist.
3. Verfahren nach Anspruch 1 oder 2, bei dem die Komponente eine Instanz einer Klasse eines objektorientierten Programms ist, durch welche Klasse der Typ des Anlagenobjekts beschrieben wird.
4. Verfahren nach einem der Ansprüche 1 bis 3, a) bei dem die mindestens eine Schnittstelle eine erste Teilschnittstelle und eine zweite Teilschnittstelle umfaßt, b) bei dem die erste Teilschnittstelle einen Eingang und einen Ausgang aufweist, wobei über den Eingang und den
Ausgang der ersten Teilschnittstelle ein Stoff-Fluß modelliert wird, c) bei dem die zweite Teilschnittstelle einen Eingang und einen Ausgang aufweist, durch welchen Eingang eine Veränderung einer Stellgröße der Komponente durchgeführt wird und durch welchen Ausgang eine Rückmeldung über einen Zustand des Stoff-Flusses und/oder über einen Zustand der Veränderung der Stellgröße ermittelt wird.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Komponente beschrieben wird durch mindestens eine der folgenden Beschreibungsformen: a) ein differentialalgebraisches System; b) ein ereignisdiskretes Modell und c) eine Strukturinformation.
Verfahren nach Anspruch 4 oder 5, bei dem durch die erste Schnittstelle ein Prozeßverhalten modelliert und durch die zweite Schnittstelle ein Kontrollverhalten modelliert wird.
7. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Komponente über mindestens einen der folgenden Mechanismen Nachrichten erzeugt: a) von der Komponente wird ein Ereignis (Event) generiert und an den Hauptprozeß übermittelt, b) von der Komponente wird eine Variablenänderung für eine andere Komponente generiert, indem die Variablenänderung mit der Adresse der anderen Komponente generiert und an den Hauptprozeß übermittelt wird, c) von der Komponente wird eine Methode einer anderen Komponente aufgerufen, indem die Methode mit der Adresse der anderen Komponente generiert und an den Hauptprozeß übermittelt wird.
8. Verfahren nach Anspruch 7, bei dem der Hauptprozeß folgende Schritte umfaßt: a) das Ereignis wird in einer Warteschlange abgespeichert, b) wenn das Ereignis bezogen auf eine
Simulationsrechenzeit fällig ist, wird dieses Ereignis an den Adressaten weitergeleitet und dort ausgeführt.
9. Verfahren nach einem der Ansprüche 5 bis 8, bei dem die Strukturinformation von dem Hauptprozeß derart berücksichtigt wird, daß diese Strukturinformation über Komponenten hinweg, entsprechend der Verbindung der Komponenten, kommuniziert werden und somit kontextabhängige Besonderheiten in der Simulation aufgedeckt werden.
10. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die mindestens eine Schnittstelle jeder Komponente derart ausgeführt ist, daß mehrere Komponenten entsprechend ihrer zugrundeliegenden technischen Bedeutung zusammengefügt werden.
PCT/DE1999/001324 1998-05-19 1999-05-03 Verfahren zur rechnergestützten simulation eines technischen systems WO1999060497A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP99931003A EP1078326A1 (de) 1998-05-19 1999-05-03 Verfahren zur rechnergestützten simulation eines technischen systems

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE19822502.4 1998-05-19
DE19822502 1998-05-19

Publications (1)

Publication Number Publication Date
WO1999060497A1 true WO1999060497A1 (de) 1999-11-25

Family

ID=7868318

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE1999/001324 WO1999060497A1 (de) 1998-05-19 1999-05-03 Verfahren zur rechnergestützten simulation eines technischen systems

Country Status (2)

Country Link
EP (1) EP1078326A1 (de)
WO (1) WO1999060497A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003046671A1 (en) * 2001-11-27 2003-06-05 3M Innovative Properties Company Reusable software components for invoking computational models
CN107808012A (zh) * 2017-11-20 2018-03-16 武汉大学 一种基于共位的地理信息叠加方法
US9990463B2 (en) 2012-11-30 2018-06-05 Solar Turbines Incorporated System for automated design of multi-body machine

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5331579A (en) * 1989-08-02 1994-07-19 Westinghouse Electric Corp. Deterministic, probabilistic and subjective modeling system
FR2724744A1 (fr) * 1994-09-16 1996-03-22 Ass Pour Le Dev De L Enseignem Procede de modelisation d'un processus physique
US5572733A (en) * 1993-05-25 1996-11-05 Fujitsu Limited Data processing system which executes composite objects by combining existing objects

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5331579A (en) * 1989-08-02 1994-07-19 Westinghouse Electric Corp. Deterministic, probabilistic and subjective modeling system
US5572733A (en) * 1993-05-25 1996-11-05 Fujitsu Limited Data processing system which executes composite objects by combining existing objects
FR2724744A1 (fr) * 1994-09-16 1996-03-22 Ass Pour Le Dev De L Enseignem Procede de modelisation d'un processus physique

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003046671A1 (en) * 2001-11-27 2003-06-05 3M Innovative Properties Company Reusable software components for invoking computational models
US7117480B2 (en) 2001-11-27 2006-10-03 3M Innovative Properties Company Reusable software components for invoking computational models
US9990463B2 (en) 2012-11-30 2018-06-05 Solar Turbines Incorporated System for automated design of multi-body machine
CN107808012A (zh) * 2017-11-20 2018-03-16 武汉大学 一种基于共位的地理信息叠加方法

Also Published As

Publication number Publication date
EP1078326A1 (de) 2001-02-28

Similar Documents

Publication Publication Date Title
EP1061422B1 (de) Informationstechnisches System zur Definition, Optimierung und Steuerung von Prozessen
EP0852759B1 (de) Entwurfsverfahren für die anlagentechnik und rechnergestütztes projektierungssystem zur verwendung bei diesem verfahren
DE19712946A1 (de) Methode zum Generieren einer Implementierung wiederverwendbarer Teile von Containern eines Workflow-Prozessmodells
DE102007046642A1 (de) Verfahren und Modulklassenobjekte zur Konfiguration von fehlenden Einrichtungen in verfahrenstechnischen Anlagen
DE10206902A1 (de) Engineeringverfahren und Engineeringsystem für industrielle Automatisierungssysteme
EP1917611A2 (de) System für den maschinengestützten entwurf technischer vorrichtungen
DE69532307T2 (de) Ausdrucks-Propagierung für hierarchisches Netzlisten
DE19910311A1 (de) Automatisierungssystem mit wiederverwendbaren Automatisierungsobjekten und Verfahren zur Wiederverwendung von Automatisierungslösungen in Engineering-Werkzeugen
DE10206903A1 (de) Softwareapplikation, Softwarearchitektur und Verfahren zur Erstellung von Softwareapplikationen, insbesondere für MES-Systeme
DE602004012399T2 (de) Vefahren zur Generierung von optimalen Steuerungsproblemen für industrielle Prozesse
EP0838054B1 (de) Verfahren und steuereinrichtung für eine graphische steuerung von abläufen in einem netzwerkmanagementsystem
WO2011023589A1 (de) Verfahren zur unterstützung einer planung einer technischen anlage
WO1999060497A1 (de) Verfahren zur rechnergestützten simulation eines technischen systems
DE102020119853B3 (de) Verfahren zum Steuern eines Automatisierungssystems mit Visualisierung von Programmobjekten eines Steuerprogramms des Automatisierungssystems und Automatisierungssystem
EP3862822A1 (de) Verfahren und system zum validieren eines steuerungsprogramms
DE102016214666A1 (de) Verfahren und Vorrichtung zur Gestaltung einer technischen Anlage
DE19831651C1 (de) Verfahren zum Erzeugen eines regel- und anpassbaren Netzwerkes von Modellen von Verhaltensmustern einschließlich Software-Systemen
DE19939593C2 (de) Verfahren zum Erzeugen eines mathematischen Modells einer Anlage
EP3696621A1 (de) Computerimplementiertes verfahren und vorrichtung zum steuern eines modularen technischen systems
WO2015172814A1 (de) Verfahren und engineering-werkzeug zum automatisieren einer industriellen anlage
DE102004039884A1 (de) Verfahren und System zur Beschreibung und Ausführung automatischer Tests
WO1995014281A1 (de) Verfahren zur automatischen modellierung eines teilprozesses aus einem gesamtprozess durch einen rechner
EP1067444B1 (de) Verfahren und Anordnung zur Modellierung eines technischen Systems
DE10131438B4 (de) Verfahren zur Entwicklung einer technischen Komponente
WO2004053739A2 (de) System zur generierung von automatisierungscode

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1999931003

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 09700564

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 1999931003

Country of ref document: EP

WWR Wipo information: refused in national office

Ref document number: 1999931003

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1999931003

Country of ref document: EP