Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
SYSTEM FOR WRITING A SIMULATION PROGRAM
Document Type and Number:
WIPO Patent Application WO/2009/021541
Kind Code:
A1
Abstract:
The invention relates to a system for writing a simulation program for simulating an automation installation. To facilitate the writing of a simulation program for a complex automation installation, the system comprises - means for defining a respective resource object (1, 3) for at least two components of the automation installation, wherein each of these resource objects (1, 3) has an associated program fragment (2, 4) with computer program code for simulating the functionality of the associated component and wherein each of these resource objects (1, 3) has at least one port (30, 40) whose value can be engaged and/or read in by the program fragment (2, 4) of the associated resource object (1, 2), - means for defining port data (31, 41, 61, 71) for each port (30, 40, 60, 70), which define characteristics of the values which can be interchanged on the associated port (30, 40, 60, 70), - means for identifying a first port (30) of a first resource object (1), which is provided for interchanging values with a second port (60) of a second resource object (3), on the basis of the port data (31, 61) associated with the first and second ports (30, 60), - means for defining precisely one variable which can be engaged with the values to be interchanged between the first and second ports (30, 60), and - means for integrating the program fragments (2, 4) associated with the first and second resource objects (1, 3) into the simulation program (5) and for engaging the variables with the values to be interchanged between the first and second ports (30, 60).

Inventors:
PLEWINSKI NICOLAI (DE)
STOLPER THILO (DE)
Application Number:
PCT/EP2007/007263
Publication Date:
February 19, 2009
Filing Date:
August 16, 2007
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
SIEMENS AG (DE)
PLEWINSKI NICOLAI (DE)
STOLPER THILO (DE)
International Classes:
G05B17/02; G05B19/418; G05B19/042; G05B19/05; G06F9/455; G06G7/66
Domestic Patent References:
WO2002079974A22002-10-10
Foreign References:
EP1265333A12002-12-11
US20070088533A12007-04-19
Attorney, Agent or Firm:
SIEMENS AKTIENGESELLSCHAFT (München, DE)
Download PDF:
Claims:
Patentansprüche

1. System zur Erstellung eines Siraulationsprogramms (5) zur Simulation einer Automatisierungsanlage mit - Mitteln zur Definition jeweils eines Ressourcenobjektes (1,3) für mindestens zwei Komponenten der Automatisierungsanlage, wobei jedem dieser Ressourcenobjekte (1,3) ein Programmfragment (2,4) mit Computerprogrammcode zur Simulation der Funktionalität der zugehörigen Komponente zugeordnet ist und wobei jedes dieser Ressourcenobjekte

(1,3) mindestens einen Port (30,40) aufweist, dessen Wert durch das Programmfragment (2,4) des zugehörigen Ressourcenobjektes (1,2) belegt und/oder eingelesen werden kann, Mitteln zur Definition von Portdaten (31,41,61,71) zu je- dem Port (30,40,60,70), die Eigenschaften der am zugehörigen Port (30,40,60,70) austauschbarer Werte definieren, Mitteln zur Identifikation eines ersten Ports (30) eines ersten Ressourcenobjekte (1), der zum Austausch von Werten mit einem zweiten Port (60) eines zweiten Ressourcenobjek- tes (3) vorgesehen ist, auf Basis der dem ersten und zweiten Port (30,60) zugehörigen Portdaten (31,61), Mitteln zur Definition genau einer Variablen, die mit den zwischen dem ersten und zweiten Port (30,60) auszutauschenden Werten belegt werden kann und - Mitteln zur Integration der dem ersten und zweiten Ressourcenobjekt (1,3) zugeordneten Programmfragmente (2,4) in das Simulationsprogramm (5) und zur Belegung der Variablen mit den zwischen dem ersten und zweiten Port (30,60) auszutauschenden Werten.

2. System nach Anspruch 1, wobei die Variable eine globale Variable (6) ist.

3. System nach Anspruch 1, wobei die Variable ein global definiertes Array (7) ist.

4. System nach Anspruch 1, wobei die Variable ein Pointer ist.

5. System nach Anspruch 1, wobei die Variable eine Liste ist.

6. System nach einem der vorgehenden Ansprüche, wobei das System Mittel zur automatischen Vergabe einer eindeutigen Bezeichnung für die Variable umfasst, die derart gestaltet ist, dass sie das Ressourcenobjekt (1,3) kennzeichnet, das die Variable mit Werten belegt, und den Port (30,40,60,70) kennzeichnet, an dem das Ressourcenobjekt (1,3) den Wert ausgibt.

7. System nach einem der vorgehenden Ansprüche, wobei die Portdaten (31,41,61,71) den jeweiligen zugehörigen Port (30,40,60,70) als Eingangsport oder Ausgangsport kenn- zeichnen.

8. System nach einem der vorgehenden Ansprüche, wobei die Portdaten (31,41,61,71) die maximale Anzahl weiterer Ports (30,40,60,70) kennzeichnen, mit denen ein den Port- daten zugehöriger Port (31,41,61,71) Werte austauschen kann.

9. System nach einem der vorgehenden Ansprüche, wobei das System Mittel zur Instanziierung der Ressourcenobjekte (1,3) aufweist, die eine Bildung von Instanzen der Res- sourcenobjekte (1,3) zur Laufzeit des Simulationsprogramms (5) ermöglichen.

10. System nach einem der vorhergehenden Ansprüche, wobei das System als Engineeringsystem ausgeführt ist.

Description:

Beschreibung

System zur Erstellung eines Simulationsprogramms

Die Erfindung betrifft ein System zur Erstellung eines Simulationsprogramms zur Simulation einer automatisierungstechnischen Anlage.

Automatisierte prozess- oder fertigungstechnische Anlagen sind heute sehr komplex aufgebaut und bestehen aus einer

Vielzahl miteinander interagierender Komponenten. Unter Komponenten einer Automatisierungsanlage sollen hier sowie im gesamten Dokument alle am automatisierten Prozess teilnehmenden Komponenten verstanden werden. So gehören die am Automa- tisierungsprozess beteiligten Sensoren und Aktoren zu den in diesem Sinne zu verstehenden Anlagenkomponenten. Darüber hinaus werden aber auch von einer derartigen Automatisierungsanlage bearbeitete Werkstücke als Anlagenkomponenten verstanden.

Aufgrund der Vielzahl und der Komplexität der an einem Auto- matisierungsprozess beteiligten Komponenten weist auch die zur Steuerung der Komponenten vorgesehene Software in der Regel einen sehr hohen Komplexibilitätsgrad auf. Hieraus er- wächst schließlich das Bestreben, bei Neuentwicklungen von

Anlagen oder prozessbedingten Modifikationen bestehender Anlagen die Steuerungssoftware vor der Inbetriebnahme der Anlage testen zu können. Dies geschieht in der Regel dadurch, dass die Automatisierungsanlage und die realen Steuerungen mit der zu testenden Software simuliert werden. Neben einer erheblichen Kosten- und Zeitersparnis bringt dies den Vorteil, dass bei einer Neuentwicklung einer Automatisierungsanlage diese noch nicht existieren muss, wenn die Steuerungssoftware entwickelt ist und getestet werden soll. Mit Hilfe eines Rechners werden die mechatronischen Komponenten der Automatisierungsanlage simuliert und auf diese Art und Weise sinnvolle Eingangssignale zu den vom Steuerungsprogramm generierten Ausgangssignalen erzeugt.

übliche Simulationsprogramme stellen in der Regel Verhaltensmodelle zur Verfügung, mit denen das Verhalten einzelner Anlagenkomponenten nachgebildet werden kann. Mit Hilfe dieser Verhaltensmodelle ist es möglich, abhängig von vorgegebenen Eingangswerten, die in der Regel von den Modellen anderer am Automatisierungsprozess beteiligten Komponenten erzeugt werden, Ausgangswerte zu berechnen und diese wiederum anderen Komponenten der Automatisierungsanlage bzw. deren Verhaltensmodellen als Eingangswert zur Verfügung zu stellen. In einer graphischen Oberfläche eines derartigen Simulationsprogramms werden die einzelnen realen Anlagenkomponenten daher in der Regel durch graphische Symbole repräsentiert, die Ein- und Ausgänge aufweisen, welcher mit entsprechenden Ein- und Ausgangswerten belegt werden können. Um nun eine automatisie- rungstechnische Anlage mit vielen einzelnen Komponenten zu simulieren, wird der Benutzer die graphischen Objekte, die den jeweiligen Komponenten zugeordnet sind, über die Ein- und Ausgänge miteinander verbinden, um so den Informationsfluss innerhalb der realen Anlage nachzubilden. Je komplexer die zu modulierende automatisierungstechnische Anlage ist, desto schwieriger und fehleranfälliger wird die Generierung eines Simulationsmodells für die komplette automatisierungstechnische Anlage.

Der Erfindung liegt die Aufgabe zugrunde, die Erstellung eines Simulationsprogramms für eine komplexe automatisierungstechnische Anlage zu erleichtern.

Diese Aufgabe wird durch ein System zur Erstellung eines Si- mulationsprogramms zur Simulation einer Automatisierungsanlage gelöst mit

- Mitteln zur Definition jeweils eines Ressourcenobjektes für mindestens zwei Komponenten der Automatisierungsanlage, wobei jedem dieser Ressourcenobjekte ein Programmfrag- ment mit Computerprogrammcode zur Simulation der Funktionalität der zugehörigen Komponente zugeordnet ist und wobei jedes dieser Ressourcenobjekte mindestens einen Port aufweist, dessen Wert durch das Programmfragment des zuge-

hörigen Ressourcenobjektes belegt und/oder eingelesen werden kann,

Mitteln zur Definition von Portdaten zu jedem Port, die Eigenschaften der am zugehörigen Port austauschbarer Werte definieren,

- Mitteln zur Identifikation eines ersten Ports eines ersten Ressourcenobjekte, der zum Austausch von Werten mit einem zweiten Port eines zweiten Ressourcenobjektes vorgesehen ist, auf Basis der dem ersten und zweiten Port zugehörigen Portdaten,

- Mitteln zur Definition genau einer Variablen, die mit den zwischen dem ersten und zweiten Port auszutauschenden Werten belegt werden kann und

Mitteln zur Integration der dem ersten und zweiten Res- sourcenobjekt zugeordneten Programmfragmente in das Simulationsprogramm und zur Belegung der Variablen mit den zwischen dem ersten und zweiten Port auszutauschenden Werten.

Der Erfindung liegt die Erkenntnis zugrunde, dass die Ver- schaltung der Ein- und Ausgabe der Graphikobjekte, die in einer Simulationsumgebung die realen Komponenten der Anlage repräsentieren, erheblich vereinfacht bzw. sogar automatisiert werden kann, wenn die miteinander zu verschaltenden Ports durch geeignete Metainformationen hinreichend charakterisiert werden.

Erfindungsgemäß wird einer Komponente der Automatisierungsanlage ein Ressourcenobjekt zugeordnet, wobei jedem dieser Res- sourcenobjekte besagte Metainformationen in Form der Portdaten zugeordnet sind. Die einem Ressourcenobjekt zugeordneten Portdaten werden für jeden Port des Ressourcenobjektes angelegt und kennzeichnen die über den jeweiligen Port austauschbaren Daten. Eine solche Kennzeichnung geht deutlich über die reine Definition eines zulässigen Datentyps hinaus, denn sie soll eine automatische Zuordnung von miteinander kompatiblen Ein- und Ausgängen verschiedener Ressourcenobjekte ermöglichen. Das System umfasst entsprechende Mittel, mit denen an-

hand der Portdaten die zum Werteaustausch zu verbindenden Ports ermittelt werden können. Auf diese Art und Weise entfällt ein händisches "Verdrahten" der Ein- und Ausgänge dieser Verhaltensmodellpräsentationen .

Darüber hinaus enthält jedes Ressourcenobjekt ein Programmfragment, in dem der Code abgespeichert ist, der die dem Ressourcenobjekt zugehörige Anlagenkomponente bzw. deren Verhalten nachbildet, sofern dieser Code mit einem geeigneten Simu- lationsprogramm ausgeführt wird.

Erfindungsgemäß wird, sobald die zum gegenseitigen Austausch von Werten vorgesehenen Ports identifiziert wurden eine Variable definiert, auf die die identifizierten Ports Zugriff ha- ben und die von diesen Ports mit Werten belegt werden kann.

Darüber hinaus können die entsprechenden Ports natürlich auch Werte aus dieser Variablen zur Ausführungen ihrer Programmfragmente auslesen.

Schließlich wird das Simulationsprogramm, welches zur Simulation der kompletten Automatisierungsanlage geeignet ist, dadurch generiert bzw. erweitert, dass die den identifizierten Ressourcenobjekten zugeordneten Programmfragmente zu einem gemeinsamen Programm verschmolzen werden. Innerhalb dieses Programms kann schließlich die zuvor definierte Variable von den Programmfragmenten belegt bzw. ausgelesen werden. Eine innerhalb der Programmfragmente definierte lokale Variable wird hierzu auf die erfindungsgemäß definierte Variable ge- mapt .

Das erfindungsgemäße System bietet dem Anwender den Vorteil, dass er Verhaltensmodelle einzelner Anlagenkomponenten isoliert voneinander definieren kann und bei deren Verschaltung zum Gesamtmodell der Automatisierungsanlage vom System erheb- lieh unterstützt wird. Dies wird dadurch ermöglicht, dass dem Anwender die Möglichkeit gegeben wird, die Ports der einzelnen Ressourcenobjekte mit entsprechenden Metadaten, den Portdaten, so zu beschreiben, dass das System durch Auswertung

dieser Portdaten in der Lage ist, die korrekte Verschaltung der einzelnen Ressourcenobjekte autark durchzuführen. Hieraus resultiert auch eine sehr viel übersichtlichere Darstellung des Anlagenmodells insbesondere bei sehr komplex aufgebauten Automatisierungsanlagen als es aus dem Stand der Technik bekannt ist, bei dem graphische Objekte an ihren Ein- und Ausgängen in einer einzigen Darstellung miteinander verdrahtet werden.

Für die zum Werteaustausch vorgesehene Variable existieren verschiedene programmierte technische Realisierungsmöglichkeiten. So kann in einer ersten vorteilhaften Ausführungsform der Erfindung die Variable eine globale Variable sein.

Insbesondere dann, wenn eine Vielzahl gleichartiger Komponenten innerhalb der Automatisierungsanlage vorgesehen ist, ist eine Ausführungsform der Erfindung besonders vorteilhaft, bei der die Variable ein global definiertes Array ist. Hierbei können Ein- oder Ausgänge verschiedener Instanzen eines Res- sourcenobjektes desselben Typs mit verschiedenen Einträgen ein und desselben Arrays verknüpft werden.

Anstelle einer globalen Variablen kann in weiterer vorteilhafter Ausgestaltung die Variablen auch ein Pointer sein.

Auch hier kann in weiterer vorteilhafter Ausgestaltung insbesondere im Falle mehrerer Ressourcenobjekte des gleichen Typs die Variable eine Liste sein.

Um die Abbildung der in den einzelnen Programmfragmenten belegten oder eingelesenen Werten lokal definierter Variablen auf die zum Werteaustausch vorgesehenen Variablen in einer eindeutigen Weise zu ermöglichen, umfasst in weiterer vorteilhafter Ausgestaltung der Erfindung das System Mittel zur automatischen Vergaben einer eindeutig Bezeichnung für die

Variable, die derart gestaltet ist, dass sie das Ressourcenobjekt kennzeichnet, dass die Variable mit Werten belegt und

den Port kennzeichnet, an dem Ressourcenobjekt den Wert ausgibt.

Die automatische Ermittlung der miteinander zu verschaltenden Ein- und Ausgänge wird in einer weiteren vorteilhaften Ausführungsform der Erfindung dadurch erleichtert, dass die Portdaten den jeweiligen zugehörigen Port als Eingansport o- der Ausgangsport kennzeichnen.

Eine Plausibilitätskontrolle für eine überprüfung miteinander verschalteter Ressourcenobjekte kann dadurch ermöglicht werden, dass in weiterer vorteilhafter Ausgestaltung die Portdaten die maximale Anzahl weiterer Ports kennzeichnen, mit denen ein den Portdaten zugehöriger Port Werte austauschen kann. Hierzu kann beispielsweise eine Kardinalzahl als Metadatum eingeführt werden.

Durch die automatisierte Verschaltung der einzelnen Ressourcenobjekte wird eine weitere Ausführungsform der Erfindung ermöglicht, bei der das System Mittel zur Instanziierung der Ressourcenobjekte aufweist, die eine Bildung von Instanzen der Ressourcenobjekte zur Laufzeit des Simulationsprogramms ermöglichen. Ein Benutzer kann also neue Ressourcenobjekte dynamisch instanziieren und somit eine Simulation während ih- res Ablaufs beeinflussen. Beispielsweise kann während einer Simulation von einer Förderanlage, die Werkstücke transportiert, die Anzahl der Werkstücke durch Instanzbildung erhöht werden.

Eine hohe Datenkonsistenz wird bei der Projektierung und der Simulation eines Automatisierungssystems dadurch ermöglicht, dass in weiterer vorteilhafter Ausgestaltung das System als Engineeringsystem ausgeführt ist.

Im Folgenden wird die Erfindung anhand der in den Figuren dargestellten Ausführungsbeispiele näher beschrieben und erläutert.

Es zeigen:

FIG 1 eine schematische Darstellung eines ersten in einem

Engineeringsystem definierten Ressourcenobjektes, das einer ersten Komponente einer zu simulierenden Automatisierungsanlage zugeordnet ist,

FIG 2 eine schematische Darstellung eines zweiten in dem

Engineeringsystem definierten Ressourcenobjektes, das einer zweiten Komponente der zu simulierenden Automa- tisierungsanlage zugeordnet ist,

FIG 3 eine Prinzipdarstellung eines Simulationsprogramms zur Simulation der ersten und zweiten Komponente,

FIG 4 eine schematische Darstellung eines dritten in dem

Engineeringsystem definierten Ressourcenobjektes, das einer dritten Komponente der zu simulierenden Automatisierungsanlage zugeordnet ist,

FIG 5 eine schematische Darstellung eines vierten in dem

Engineeringsystem definierten Ressourcenobjektes, das eine vierten Komponente der zu simulierenden Automa- tisierungsanlage zugeordnet ist und

FIG 6 eine Prinzipdarstellung eines weiteren Simulationsprogramms zur Simulation der dritten und vierten Komponente.

Im Folgenden soll anhand der Figuren 1,2 und 3 ein sehr einfaches Beispiel dargestellt werden, welches die erfindungsgemäße automatische Verschaltung zweier Ressourcenobjekte zur Erzeugung eines Simulationsprogramms veranschaulicht.

FIG 1 zeigt eine schematische Darstellung eines ersten in einem Engineeringsystem definierten Ressourcenobjektes 1, das eine erste Komponente einer zu simulierenden Automatisierungsanlage zugeordnet ist. Das Ressourcenobjekt 1 umfasst zwei Ports 30, 40, über die Daten mit anderen Ressourcenob- jekten ausgetauscht werden können und die in FIG 1 schematisch als Pins dargestellt sind.

Darüber hinaus ist dem Ressourcenobjekt 1 ein Programmfragment 2 zugeordnet. Das Programmfragment 2 besteht aus Computerprogrammcode, mit dem das Verhalten der dem Ressourcenobjekt 1 zugeordneten Automatisierungskomponente beim Ablauf in einem Simulationsprogramm nachgebildet werden kann.

Das Ressourcenobjekt 1 ist einem Förderband der Automatisierungsanlage zugeordnet. Ein Anwender des Engineeringsystems weist dem Ressourcenobjekt 1 daher auch den Namen "Förder- band" zu. Aufgabe des realen Förderbandes ist es, Werkstücke zu transportieren. Das Programmfragment 2 beschreibt nun das Verhalten des Förderbandes dahingehend, dass es für ein Werkstück, das sich an einer bestimmten Position befindet, eine Weglänge delta berechnet, die dieses Werkstück innerhalb ei- nes Zeitintervalls T durchläuft, wenn das Förderband mit der Geschwindigkeit v läuft. Hierbei ist angenommen, dass das besagte Werkstück nur dann von dem Förderband bewegt wird, wenn die Position pos des Werkstücks einen Wert größer als 100 annimmt. Dieses Verhalten ist innerhalb des Programmfragmentes 2 in Form einer Istanweisung definiert. Innerhalb des Programmfragmentes 2 werden die lokalen Variablen pos und delta verwendet, die die Position und die Weglänge beschreiben. Die Geschwindigkeit v des Förderbandes und das Zeitintervall T sind vorbelegte statische Parameter, die sich zur Laufzeit des Programmfragmentes 2 nicht ändern.

Darüber hinaus umfasst das erste Ressourcenobjekt 1 ein erstes Zuweisungsfenster 8. Innerhalb dieses Zuweisungsfensters 8 werden die lokalen Variablen pos und delta mit den an den Ports 30, 40 des Ressourcenobjektes 1 anliegenden Werten verknüpft. So wird die lokale Variable pos mit dem Wert am Port 1 30 belegt. Die Position des Werkstücks wird somit am Port 1 30 eingelesen. Nachdem nun mit diesem Wert die zurückgelegte Wegstrecke delta berechnet wurde, wird in einem ersten Zuwei- sungsfenster 8 dem zweiten Port 40 (Port 2) der Wert der Variablen delta zugewiesen.

Aus der Beschreibung des Prograπunfragmentes 2 und den Zuweisungen geht klar hervor, dass der erste Port 30 einen Eingang des ersten Ressourcenobjektes 1 darstellt und der zweite Port 40 einen Ausgang.

Die Besonderheit des in FIG 1 dargestellten ersten Ressourcenobjekts 1 liegt nun darin, dass eine Menge erster und zweiter Positionsdaten 31, 41 vorgesehen ist, die Eigenschaften der zugehörigen Ports 30, 40 bzw. der an diesen Ports auszutauschenden Werte kennzeichnen. So ist für jeden dieser Ports 30,40 eine Kategorie angegeben, anhand der die Ports 30,40 bezüglich einer insbesondere benutzerdefinierten Kate- goriesierung eingeordnet werden können. Darüber hinaus wird der Typ des zugehörigen Ports 30, 40 bezüglich Ein- oder Aus- gang gekennzeichnet. Weiterhin ist für jeden Port 30, 40 eine Kardinalzahl card angegeben. Die Kardinalzahl legt fest, mit wie viel weiteren Ports der zugehörige Port zwecks Werteaustausch verbunden werden kann.

Basierend auf diesen Portdaten 31, 41 und Portdaten weiterer Ressourcenobjekte, die weitere Komponenten der Automatisierungsanlage bezüglich ihres Verhaltens beschreiben, kann nun das Engineeringsystem eine automatische Verknüpfung der Ports durchführen und somit die Datenflusswege automatisch definie- ren.

FIG 2 zeigt eine schematische Darstellung eines zweiten in dem Engineeringsystem definierten Ressourcenobjektes 3, das einer zweiten Komponente der zu simulierenden Automatisie- rungsanlage zugeordnet ist. Dieses Ressourcenobjekt 3 ist einem auf dem Förderband zu transportierenden Werkstück zugeordnet und soll sein Verhalten innerhalb einer Simulation beschreiben. Hierzu umfasst das zweite Ressourcenobjekt 3 ein zweites Programmfragment 4, welches Computerprogrammcode ent- hält, mit dem das Verhalten des Werkstücks innerhalb des Simulationsprogramms nachgebildet werden kann. Dieses Programmfragment 4 berechnet die aktuelle Position pos des Werkstücks anhand der Wegstreckenänderung delta, die es an einem seiner

Ports 60, 70 einliest. Innerhalb des zweiten Programmfragmen- tes 4 sind daher zwei lokale Variablen pos und delta definiert, die mit entsprechenden Werten belegt werden können.

In einem zweiten Zuweisungsfenster 9 werden schließlich die Verknüpfungen zwischen den lokalen Variablen pos und delta und den Ports 60,70 des zweiten Ressourcenobjektes 3 definiert. So wird die mit dem zweiten Programmfragment 4 berechnete neue Position pos dem Port 1 zugewiesen. Die lokale Va- riable delta, die für die Berechnung benötigt wird, wird am Port 72 eingelesen.

Den Ports 60, 70 sind auch hier Portdaten 61, 71 zugeordnet, die die Eigenschaften der zugehörigen Ports 60, 70 bzw. der an diesen Ports 60, 70 auszutauschenden Werte kennzeichnen. Auch hier werden wiederum die Meterdatenkategorie, Typ und Kardinalzahl analog zur FIG 1 belegt.

Da der erste Port 30 des ersten Ressourcenobjektes 1 der sel- ben Kategorie angehört wie der erste Port 60 des zweiten Ressourcenobjektes 3 und der erste Port 30 des ersten Ressourcenobjektes 1 ein Eingang ist und der erste Port 60 des zweiten Objektes 3 ein Ausgang, erkennt das System, dass diese beiden Ports 30, 60 zum gemeinsamen Datenaustausch vorgesehen sind. ähnlich verhält es sich mit den jeweiligen zweiten Ports 41, 71 die ebenfalls der selben Kategorie angehören, wobei der zweite Port 41 des ersten Ressourcenobjektes 1 ein Ausgang ist und der zweite Port 71 des zweiten Ressourcenobjektes 3 ein Eingang ist.

Das Engineeringsystem kann also aufgrund der Portdaten 31, 41, 61, 71 unter einer Vielzahl von Ressourcenobjekten das zweite Ressourcenobjekt 3 identifizieren, um es mit dem ersten Ressourcenobjekt 1 wie zuvor beschrieben zwecks Werteaus- tausch datentechnisch zu verbinden. Darüber hinaus kann das

Engineeringsystem nunmehr die Programmfragmente 2, 4 des ersten und zweiten Ressourcenobjektes 1, 3 in ein Simulationsprogramm integrieren, welches unter anderem die Interaktion

der den beiden Ressourcenobjekten 1, 3 zugeordneten Komponenten nachbildet.

FIG 3 zeigt eine Prinzipdarstellung eines Simulationspro- gramms 5 zur Simulation der ersten und zweiten Komponente der Automatisierungsanlage. Nachdem nun die beiden Ressourcenobjekte 1, 3 identifiziert wurden, wurden die zugehörigen Programmfragmente 2, 4 in das Simulationsprogramm 5 integriert. Darüber hinaus wurden zwei globale Variablen 6 definiert, die mit den von den Programmfragmenten 2, 4 berechneten Werten belegt werden können. Die in den Programmfragmenten 2, 4 verwendeten lokalen Variablen delta und pos werden schließlich in einem dritten Zuweisungsfenster 10 auf diese global definierten Variablen gemapt .

Die Bezeichnung der globalen Variablen 6 geschieht nach einem gewissen Automatismus. Dieser Automatismus stellt sicher, dass keine Doppelbenennung stattfinden und der Ursprung der globalen Variablen, d.h. der Port, an dem der Wert ausgegeben wurde, identifizierbar ist. So lässt sich anhand des Namens der globalen Variablen das Ressourcenobjekt identifizieren, an dessen Port der zugehörige Wert als Ausgangswert erscheint und schließlich besagt der Port selbst. D.h., die globale Variable Werkstueck. Porti wird mit den Werten des ersten Ports 61 des zweiten Ressourcenobjektes 3 belegt, da das zweite Ressourcenobjekt 3 dem Werkstück zugeordnet ist. Analog wird die globale Variable Foerderband. Port2 mit dem Wert am zweiten Port 40 des ersten Ressourcenobjektes 1 belegt, da das erste Ressourcenobjekt dem Förderband zugeordnet ist.

FIG 4 zeigt eine schematische Darstellung eines dritten in einem Engineeringsystem definierten Ressourcenobjektes 11, das einer dritten Komponente der zu simulierenden Automatisierungsanlage zugeordnet ist. Das dritte Ressourcenobjekt 11 ist wie das erste Ressourcenobjekt 1 aus FIG 1 einem Förderband zugeordnet. Bei der Implementierung des dritten Ressourcenobjektes 11 ist jedoch berücksichtigt worden, dass das Förderband mehr als ein Werkstück transportieren kann. Folg-

lieh kann das zugehörige Verhaltensmodell auch die Wegstreckenänderung mehrerer Werkstücke berechnen.

In einem Programmfragment 12 des dritten Ressourcenobjektes 11 wird die Wegstrecke jedes Werkstücks analog zu der bezüglich FIG 1 beschriebenen Vorgehensweise berechnet. Um dies für jedes der Werkstücke durchführen zu können, wird ein Ar- ray sowohl für die Position als auch für die zurückgelegte Wegstrecke delta definiert, wobei jedes Array m Einträge be- sitzt und m die Anzahl der von dem Förderband zu transportierenden Werkstücke bezeichnet.

Durch die Verwendung eines Arrays als Variablentyp wird ermöglicht, innerhalb eines Simulationszykluses die zurückge- legte Wegstrecke aller m Werkstücke zu berechnen und zu speichern. Nach Ausführung des dritten Programmfragmentes 12 ist somit für jedes Werkstück j der Ausgangsposition pos[j] ein delta[j] auslesbar, wobei gilt mit j=l..m.

FIG 5 zeigt eine schematische Darstellung eines vierten in einem Engineeringsystem definierten Ressourcenobjektes 13, das einer vierten Komponente der zu simulierenden Automatisierungsanlage zugeordnet ist. Das vierte Ressourcenobjekt 13 ist analog zu dem zweiten Ressourcenobjekt aus FIG 2 einem Werkstück zugeordnet. Bei der Definition des vierten Ressourcenobjektes 13 ist jedoch der Fall betrachtet worden, dass das zugehörige Werkstück von mehreren Förderbändern der Anzahl k bewegt werden kann. Aufgrund dessen ist die Wegstrecke delta auch hier in Form eines Arrays definiert worden, denn die neue Position berechnet sich aus den inkrementellen Anteilen aller k Förderbänder.

Da das vierte Ressourcenobjekt 13 genau einem Werkstück zugeordnet ist, das auch nur genau eine Position einnehmen kann, ist die Position pos als skalare Variable definiert.

FIG 6 zeigt eine Prinzipdarstellung eines weiteren Simulationsprogramms 15 zur Simulation der Automatisierungsanlage.

Die Integration der Programmfragmente 12, 14 des dritten und vierten Ressourcenobjektes 11, 13 geschieht analog zu der in FIG 3 dargestellten Vorgehensweise. Neben den explizit dargestellten Programmfragmenten 12,14 des dritten und vierten Ressourcenobjektes 11,13 sind die Programmfragmente der übrigen k Förderbänder und m Werkstücke in das fertige Simulationsprogramm 15 integriert.

Um den Datenaustausch all dieser Programmfragmente 12,14 zu ermöglichen, werden global definierte Arrays 7

Werkstueck. Porti und Foerderband. Port2 deklariert. Die Wahl der Bezeichner geschieht analog zu der bereits unter FIG 3 erläuterten Vorgehensweise. In den global definierten Arrays können die innerhalb eines Simulationszykluses auszutauschen- den und von den Programmfragmenten berechneten Ausgangswerte abgelegt werden, ohne das diese während des besagten Zykluses überschrieben werden können.

Das mit den Figuren 4 bis 6 beschriebene Ausführungsbeispiel zeigt, dass die Erfindung eine sehr viel übersichtlichere Verknüpfung einzelner Verhaltensmodelle zur Simulation der Automatisierungsanlage erlaubt, als dies im Stand der Technik der Fall wäre. Gemäß dem Stand der Technik müssten in einer grafischen Benutzeroberfläche die Ports sämtlicher Werkstück- ressourcen mit den Ports sämtlicher Förderbänder verbunden werden, die am Transport der Werkstücke beteiligt sind. Es ist offensichtlich, dass die Fehlergefahr hierbei sehr hoch ist und eine sehr unübersichtliche Repräsentation des Anlagenmodells entsteht. Diese Nachteile werden mit der Erfindung effizient beseitigt. Ferner ermöglicht die Erfindung eine dynamische Instanziierung während des Simulationsablaufes. Beispielsweise können während der Simulation neue Instanzen eines Typs Werkstück erzeugt werden, dem das vierte Ressourcenobjekt 13 zugeordnet ist.