Lange, Ronald (Virchowstrasse 28 Fürth, D-90766, DE)
Langkafel, Dirk (Bergstrasse 15a Effeltrich, D-91090, DE)
Schneider, Karsten (Am Bohlenplatz 7 Erlangen, D-91054, DE)
Windl, Helmut (Föhrenstrasse 10 Bad Abbach, D-93077, DE)
Biehler, Georg (Schalkhausserstrasse 102a Nürnberg, D-90453, DE)
Leins, Ralf (Im Mahler 38 Ispringen, D-75228, DE)
Eckardt, Dieter (Ziehrer Strasse 8 Herzogenaurach, D-91074, DE)
Krämer, Manfred (Fliederweg 12a Wendelstein, D-90530, DE)
Becker, Norbert (Turmhügelweg 20a Erlangen, D-91058, DE)
Donner, Albrecht (Hauptstrasse 92 Markersdorf, D-09236, DE)
Diezel, Matthias (Gläsleinsackerweg 25 Nürnberg, D-90482, DE)
Lange, Ronald (Virchowstrasse 28 Fürth, D-90766, DE)
Langkafel, Dirk (Bergstrasse 15a Effeltrich, D-91090, DE)
Schneider, Karsten (Am Bohlenplatz 7 Erlangen, D-91054, DE)
Windl, Helmut (Föhrenstrasse 10 Bad Abbach, D-93077, DE)
Biehler, Georg (Schalkhausserstrasse 102a Nürnberg, D-90453, DE)
Leins, Ralf (Im Mahler 38 Ispringen, D-75228, DE)
Eckardt, Dieter (Ziehrer Strasse 8 Herzogenaurach, D-91074, DE)
Krämer, Manfred (Fliederweg 12a Wendelstein, D-90530, DE)
Becker, Norbert (Turmhügelweg 20a Erlangen, D-91058, DE)
Donner, Albrecht (Hauptstrasse 92 Markersdorf, D-09236, DE)
SIEMENS AKTIENGESELLSCHAFT (Postfach 22 16 34 München, D-80506, DE)
Ein derartiges Automatisierungssystem kommt insbesondere im Bereich der Automatisierungstechnik zum Einsatz. Ein derarti- ges Automatisierungssystem besteht in der Regel aus einer Vielzahl von einzelnen Automatisierungsobjekten, die häufig eine hohe Abhängigkeit des Automatisierungsobjekts vom je- weils verwendeten Engineeringsystem aufweisen.
Momentan gibt es zwei grundsätzliche Verfahren, die einge- setzt werden. Im ersten Verfahren, wird die Wiedergewinnung der Engineeringdaten aus der Anlage ausgeschlossen. Änderun- gen der Anlage sind nur über das Engineeringwerkzeug möglich.
Damit geben die Daten im Engineeringsystem stets den aktuel- len Stand wieder und die Notwendigkeit des Rückspielens der Information aus der Anlage entfällt. Diese Lösung besitzt die folgenden Nachteile : Starke Kopplung zwischen Runtime und Engineering : Das Engineeringsystem muß mit der Anlage ausgeliefert werden und auch vom Kunden extra bezahlt werden.
Anderungen in der Anlage können nicht nachvollzogen wer- den : Kommt es zu Änderungen in der Anlage, beispielsweise durch Austausch eines Geräts, können diese Änderungen nicht automatisch im Engineeringsystem nachvollzogen wer- den.
Hoher organisatorischer sufwand : Um die Engineeringdaten aktuell zu halten, müssen organisatorische Vorkehrungen getroffen werden, durch die sichergestellt wird, wie Ände- rungen in der Anlage in das Engineeringsystem eingebracht werden.
Der zweite Ansatz beruht auf einer Disassemblierung des Runtimecodes. Dabei wird der ausführbare Code der Runtimeob- jekte analysiert und in die Gegenstücke des Engineering über- setzt. Diese Lösung besitzt die folgenden Nachteile : Aufwendiges Verfahren : Die Analyse des Runtimecodes ist komplex und anfällig für Fehler.
Implementierungsabhängig : Die Implementierung der Rück- übersetzung ist stark abhängig von der Realisierung des Übersetzungsvorgangs. Änderungen des Übersetzungsvorgangs und vor allem des erzeugten Codes erzwingen die Anpassung der Implementierung des Rückübersetzungsvorgangs.
ES-Information nicht mehr eindeutig herstellbar : Da der Runtimecode sich auf einer semantisch niedrigeren Ebene befindet als die eigentliche Engineeringinformation, kann nicht gewährleistet werden, daß die Engineeringinformation sich exakt rekonstruieren läßt.
Das der Erfindung zugrunde liegende Problem besteht darin, daß die in einer Anlage enthaltenen Informationen automatisch in ein Engineeringsystem zurückgespielt und dort wieder be- nutzt werden können, beispielsweise um Änderungen in der An- lage zu projektieren.
Diese Aufgabe wird durch das im Anspruch 1 angegebene Verfah- ren gelöst.
Dabei werden die Objekte des Engineering und der Runtime wer- den durch ein einheitliches Objektmodell beschrieben. Dadurch läßt sich die Entsprechung zwischen Engineeringobjekten und Runtimeobjekten auf Objektebene festlegen und es tritt kein Informationsverlust durch die Abbildung auf. Zusätzlich kann eine direkte Kommunikation zwischen Engineering-und Runtime- objekten stattfinden, was bei der Realisierung des Verfahrens ausgenutzt werden kann.
Der Zusammenhang zwischen einem Engineeringobjekt und seinem Runtimgegenstück ist in Bild 1 beschrieben. Das Engineering- objekt ESO besitzt einen direkten Verweis, RTO Ref, auf seine
Runtimeentsprechung RTO. Dies ist möglich, da zum Zeitpunkt des Engineering die Runtimeobjekte verfügbar sind (oder wer- den). Das Runtimeobjekt RTO besitzt keinen direkten Verweis auf das dazugehörige Engineeringobjekt. Dies ist notwendig, um eine Trennung des Engineering-und Runtimesystems zu er- möglichen. Statt dessen enthält das Objekt RTO einen identi- fizierenden Bezeichner, ESO Typ ID, auf den Typ des Engineeringobjekts, ESO Typ. Damit können dann benötigte In- stanzen des ESO Typs durch das RTO erzeugt werden.
Bezogen auf ein Runtimeobjekt RTO läuft das Verfahren zur Wiederherstellung der Engineeringinformation folgendermaßen ab : 1. Bekommt ein Runtimeobjekt den Auftrag seine Engineeringin- formation wiederherzustellen, so wendet es sish zuerst dann an den Typ seines Engineeringobjekts mit dem Auftrag eine neue Instanz eines Engineeringobjekts zu erzeugen.
2. Bei der neu erzeugten Instanz trägt das Runtimeobjekt ei- nen Verweis auf sich selbst ein und beauftragt das neue Engineeringobjekt seine Daten (die des Runtimeobjekts) auszulesen.
3. Das neue Engineeringobjekt liest nun die Informationen aus dem Runtimeobjekt und trägt bei sich die entsprechende En- gineeringinformation ein.
Im folgenden wird die Erfindung anhand der in den Figuren dargestellten Ausführungsbeispiele näher beschrieben und er- läutert.
Es zeigen : FIG 1 ein Übersichtsbild zur Kennzeichnung der Beziehun- gen zwischen Engineeringobjekten und Runtimeobjek- ten, FIG 2 eine beispielhafte Objektsicht einer Anlage, FIG 3 eine Veranschaulichung zum Erzeugen von Geräte- repräsentanten im Engineering,
FIG 4 eine beispielhafte Darstellung zur Erzeugung der Automatisierungsobjekte in den Geräterepräsentanten und FIG 5 einen Aufbau der vorhandenen Kommunikationsbezie- hungen im Engineering.
Das Verfahren zur Wiedergewinnung der Engineeringinformation aus der Anlage läuft in drei Schritten ab : <BR> <BR> <BR> <BR> Wiederherstellung der Geräterepräsentanten<BR> <BR> <BR> <BR> <BR> <BR> Wiederherstellung der Reprasentanten der Automatisierungs- objekte im Engineering Wiederherstellung der Kommunikationsbeziehungen zwischen den Repräsentanten der Automatisierungsobjekte Das Verfahren wird im folgenden für die vollständige Wieder- gewinnung der Engineeringinformation beschrieben. Es läßt sich aber genauso zur Aktualisierung bereits bestehender En- gineeringinformation, d. h. als Deltaverfahren, nutzen. Im weiteren wird das gesamte Verfahren mit Upload bezeichnet.
In Bild 2 sind exemplarisch die beteiligten Objekte aufge- führt. Auf den zwei Geräten, RG1 und RG2, laufen jeweils zwei Automatisierungsobjekte. Die Automatisierungsobjekte RA01 und RA02 laufen auf RG1, RA03 und RA04 auf RG2. Kommunikations- verbindungen sind durch Linien symbolisiert. Insgesamt exi- stieren also zwei geräteinterne und zwei gerateubergreifende Kommunikationsbeziehungen.
1. Wiederherstellung der Geräterepräsentanten Der Beginn des Uploads wird aus einem Softwaresystem heraus angestoßen. Dabei kann es sich um ein Engineeringsystem oder ein beliebiges anderes System, das Engineeringinformation be- nötigt, handeln. Ein Beispiel hierfür ist ein System zur Pa- rametrierung der Anlage. Der Einfachheit halber wird im fol- genden immer von einem Engineeringsystem gesprochen.
Im ersten Schritt werden alle Geräte aufgefordert ihre Reprä- sentation im Engineering zu erzeugen. Dazu liefert. jedes Ge- rat einen Identifier des Typs seines Engineeringgegenstücks zurück. Das Engineeringsystem erzeugt dann die entsprechenden
Objekte und trägt bei jedem Geräterepräsentanten den Verweis auf das konkrete Gerät ein. Mittels des Verweise liest jeder Geräterepräsentant dann die relevanten Daten"seines"Geräts aus.
Bild 3 veranschaulicht das eben Beschriebene. Die Geräte der Anlage, hier RG1 und RG2, erhalten die Aufforderung zum Upload durch das Engineeringsystem. Sie liefern dann jeweils die Identifier der Typen der Engineeringrepräsentanten zu- rück. Das Engineeringsystem erzeugt für die entsprechenden Typen die Instanzen G1 und G2. Diese lesen dann aus den Ge- räten RG1 und RG2 die relevanten Engineeringinformation aus.
2. Wiederherstellung der Automatisierungsobjekte Im Enginee- ring Im zweiten Schritt werden die Repräsentanten der Automatisie- rungsobjekte im Engineering erzeugt. Über das ihm zugeordnete Gerät fordert jeder Geräterepräsentant die Automatisierungs- objekte seines Geräts auf, ihre Entsprechungen im Engineering zu erzeugen. Dazu liefert jedes Automatisierungsobjekt den Identifier des Typs seines Engineeringrepräsentanten zurück.
Im Engineeringsystem werden dann wieder die entsprechenden Objekte erzeugt und mit einem Verweis auf ihren Partner in der Runtimeumgebung versehen. Danach fragt jedes Automatisie- rungsobjekt im Engineering die relevanten Daten seines Part- ners ab.
Das Ergebnis dieses Vorgangs ist in Bild 4 zu sehen. Der Repräsentant G1 fragt von dem Gerät RG1 die Automatisierungs- objekte RA01 und RA02 ab. Dies werden dann von G1 zum Upload aufgefordert und liefern die Identifier der Typen von A01 und A02 zurück. Mittels dieser Information werden im Engineering die Instanzen A01 und A02 erzeugt. Diese erhalten dann eine Referenz auf ihre Runtimependants RA01 und Rua02 werden schließlich dem Geräterepräsentanten G1 zugeordnet. Dadurch ist die Information über die Gerätezuordnung der Automatisie- rungsobjekte wieder verfügbar. Anschließend lesen A01 und A02 aus RA01 und RA02 die für das Engineering relevanten Informa- tionen heraus.
3. Wiederherstellung der Kommunikationsbeziehungen zwischen den Automatisierungsobjekten im Engineering Im letzten Schritt werden die Kommunikationsbeziehungen zwi- schen den Automatisierungsobjekten wiederhergestellt. Dazu fragt jeder Geräterepräsentant das ihm zugeordnete Gerät nach seinen Kommunikationsbeziehungen. Das Gerät liefert dann eine Liste mit sowohl den geräteinternen als auch geräteübergrei- fenden Kommunikationsbeziehungen zurück. Ein Eintrag dieser Liste besteht aus Quelle und Senke der Kommunikationsbezie- hung. Quelle und Senke werden jeweils durch ein 3-Tupel aus dem Identifier des physikalischen Geräts, dem Identifier des Automatisierungobjekts und dem Identifier des Ein-bzw. Aus- gangs beschrieben.
Im Engineeringsystem werden die Einträge der Liste in Verwei- se auf die Ein-und Ausgänge der Repräsentanten der Automati- sierungsobjekte umgesetzt. Dazu wird die Information aus den bereits erzeugten Objekten (die Verweise der Engineering- repräsentanten auf ihre Runtimegegenstücke) benutzt. An- schließend wird dann die Verbindung im Engineeringsystem auf- gebaut.
Eine effiziente Realisierung dieses Schritts wird darauf ach- ten, da$ die vom jeden Gerät erzeugte Liste mit Kommunika- tionsverbindungen nur solche enthält, bei denen das Gerät im Identifier der Quelle (alternativ der Senke) auftaucht. Des weiteren wird ein effektives Verfahren die in den Schritten 1 und 2 aufgebauten Beziehungen zwischen Engineeringrepräsen- tanten und Runtimegegenstücken zwischenspeichern, um so den Suchaufwand in Schritt 3 zu minimieren.
Bild 5 zeigt nun das Ergebnis des letzten Schritts. G1 hat von RG1 die Kommunikationsbeziehungen abgefragt. Dabei wurden die Beziehung zwischen RA01 und RA02, RA01 und RA03 sowie zwischen RA02 und RA04 zurückgeliefert. Die Verbindungen wer- den dann im Engineering umgesetzt, beispielsweise die Verbin-
dung zwischen RA01 und RA03 wird zu der Verbindung zwischen A01 und A03.
Sowohl die Objekte des Engineeringsystems als auch des Run- timesystems beruhen auf dem gleichen, ausführbaren Objektmo- dell. Durch die Verwendung des gleichen Modells ist eine di- rekte Interaktion auf Modellebene (Datenaustausch und Kom- munikation) zwischen den Engineering-und Runtimeobjekten möglich. Des weiteren wird über die definierte Zuordnung zwi- schen den Objekten des Engineering und der Runtime eine ein- deutige Abbildung definiert, die unabhängig von der Implemen- tierung der Objekte ist.
Dadurch ergeben sich für das Verfahren folgende Vorteile : Trennung von Engineering und Runtime möglich : Änderungen müs- sen nicht notwendigerweise mit dem Engineeringwerkzeug durch- geführt. Bei Bedarf können die Änderungen jederzeit in das Engineeringsystem eingespielt werden.
Einfaches Verfahren : Durch die Festlegung des Verfahrens auf Ebene expliziter Modelle läßt sich das Verfahren generell be- schreiben und wird so zuverlässiger.
Einfache und vollständige Abbildung : Zwischen den Runtime- und Engineeringobjekten besteht eine fest definierte Bezie- hung, die ein vollständiges Wiederherstellen der Engineering- information ermöglicht.
Stabil gegen Implementierungsänderungen : Die Implementierung der Runtime-und Engineeringobjekte kann ausgewechselt wer- den, ohne daß dies Einfluß auf die Abbildung und damit die Realisierung des Verfahrens hat.
Werkzeugübergreifend : Der Uploadmechanismus kann auch durch andere Werkzeuge und nicht nur durch das Engineeringsystem benutzt werden.