Verfahren und System zur Transformation von Programmen, die sich auf die Softwarekonfiguration eines verteilten Leitsvstems beziehen
Beschreibung
Die Erfindung betrifft ein Verfahren und ein System zur Transformation einer ersten Information in einem ersten Format, die eine erste Softwarekonfiguration eines ersten verteilten Leitsystems beschreibt, in eine zweite Information in einem zweiten Format, die eine zweite Softwarekonfiguration eines zweiten verteilten Leitsystems beschreibt, insbesondere für den Fall, dass die erste Information in einer textbasierten Programmiersprache vorliegt.
Verteilte Leitsysteme bzw. verteilte Steuerungs- und/oder Regelungssysteme werden nach dem Stand der Technik häufig eingesetzt, um Industrieprozesse zu steuern und/oder zu regeln. Insbesondere werden Leitsysteme für den Zweck geschaffen, die diesen Industrieprozessen innewohnende verteilte Struktur über eine physische Verteilung von Leitsystem-Einheiten bzw. Steuerungs-/Regelungs-Einheiten zu erfassen und zu beherrschen, wobei die Leitsystem-Einheiten miteinander kommunizieren und Daten und/oder Information austauschen können.
Ein Leitsystem kann die vom jeweiligen Prozess erhaltenen Daten und/oder Informationen erfassen und Anweisungssignale an Steuereinheiten abgeben, die den Prozess beeinflussen und seinen physikalischen Ablauf bestimmen können, damit die Einhaltung bestimmter benötigter Merkmale garantiert bzw. gewährleistet wird.
Ein Leitsystem wird normaler Weise durch explizite Information in Bezug auf seine besondere Hardware-/Softwarekonfiguration beschrieben, z.B. durch Daten, Parameter, Programmbeschreibungen oder Ähnliches. Diese Information enthält bzw. beinhaltet normaler Weise:
a. Information in Bezug auf die Anzahl, die Art und die Konfiguration der in dem Le'rtsystem enthaltenen Leitsystem-Einheiten, und/oder b. Information über die Anzahl, die Art und die Konfiguration der an die Leitsystem- Einheiten angeschlossenen Eingabe-/Ausgabe- (E/A) Karten, und/oder c. Information über die Anzahl, die Art und die Konfiguration der spezifischen Mittel, die zum Aufbau einer Kommunikationsverbindung zwischen den Leitsystem-Einheiten verwendet werden, und/oder d. Information über die Anzahl, die Art und den Aufbau der Mittel, die zur Steuerung der Leitsystem-Einheiten verwendet werden, und/oder e. Information über das Verhalten der Leitsystem-Einheiten, welche im Allgemeinen die Programme, die auf den Leitsystem-Einheiten des Leitsystems ablaufen, und andere Randparameter umfasst, wie z.B. die Durchlaufzeiten (Zykluszeiten) der Programme, und/oder f. Informationsetiketten, die zur Identifikation der verschiedenen Elemente eines Leitsystems verwendet werden.
Diese Erfindung bezieht sich auf die unter e. der obigen Liste beschriebene Information, insbesondere die Programme.
Die auf den Leitsystem-Einheiten des Leitsystems ablaufenden Programme bzw. Programmkomponenten sind sehr oft prozedurale Programme, die in einer textbasierten Sprache vorliegen und aus einer Liste von Befehlen bestehen, welche von dem . .
Betriebssystem des Leitsystems ausgeführt werden. Beispiele solcher Befehle oder Aussagen sind:
- Befehle zum Erhalten von Information, z.B. aus einer spezifischen Informationsquelle,
- Befehle zum Speichern und/oder Schreiben von Information,
- Funktionen, wie z.B. arithmetische Funktionen,
- bedingte Schleifen ("while", "repeat until"...),
- unbedingte Schleifen ("for ... times do", ...),
- bedingte Verzweigungen ("if ... eise", "case", ...).
Die zur Beschreibung der Softwarekonfiguration eines Leitsystems verwendete Information ist durch ein geeignetes Format gekennzeichnet, weiches mit einem geeigneten Aufbau und einer geeigneten Semantik versehen ist. Der Ausdruck "Aufbau" und der Ausdruck "Semantik" beschreiben jeweils einen Satz von Regeln zur Kodifizierung und einen Satz funktioneller Beziehungen und Regeln, die ein Informationsformat kennzeichnen.
Die in einem Leitsystem erreichbare bzw. ausführbare Funktionalität wird in erster Linie durch die in den Programmen des Leistsystems angegebenen bzw. niedergeschriebenen Befehle (= die Semantik) bestimmt, welche durch Experten bei der Programmierung an ein bestimmtes Leitsystem angepasst wird, d.h. an die charakteristischen Merkmale der Betriebssysteme eines Leitsystems. Dies umfasst die Möglichkeit von Unterbrechungen (Interrupts), die Ausführungsprioritäten etc., ist aber nicht darauf beschränkt. Diese Information ist im Allgemeinen nicht explizit in der Softwarekonfiguration beschrieben, sondern ein der Ausführungsphilosophie des jeweiligen Leitsystems und seinen Betriebssystemen inhärentes Merkmal.
Mit dem Fortschreiten der Technologie kann ein Leitsystem veralten oder, allgemeiner, es kann das Bedürfnis zur Steuerung eines bestimmten Industrieprozesses mit einem anderen Leitsystem entstehen, welches mit einer leistungsfähigeren Hardware und/oder Software versehen ist. In diesem Fall ist es nötig, das neue Leitsystem zu installieren und zu konfigurieren, und den technischen Ablauf der Prozesssteuerung wieder zu starten.
Um die Kosten der Aktualisierung des Leitsystems zu minimieren, wird die sich auf die Softwarekonfiguration des alten Leitsystems beziehende Information im Allgemeinen wieder verwendet. Dieses Vorgehen impliziert es, technische Lösungen wiederzuver- wenden, die oft schon während einer langen Zeit der Steuerung durch das alte Leitsystem getestet wurden und demzufolge einen hohen Grad von Zuverlässigkeit der Prozesssteuerung sichern.
Es ist offensichtlich, dass diese technischen Lösungen auf jeden Fall verbessert werden könnten. Der Aufwand der Aktualisierung des alten Leitsystems wird bei der Wieder-
Verwendung der Softwarekonfiguration des alten Leitsystems im Vergleich mit dem Aufwand zur Neugenerierung der die Softwarekonfiguration des neuen Leitsystems betreffenden Information jedoch auf jeden Fall reduziert.
Allerdings besteht aufgrund der Tatsache, dass das Leitsystem physikalisch ausgetauscht wird, unglücklicherweise nur eine geringe Möglichkeit, die sich auf die Softwarekonfiguration des alten Leitsystems beziehende Information so wie sie ist, d.h. unverändert, wiederzuverwenden, obwohl das Prozessverhalten dem Grunde nach gleich bleibt.
Durch die Inkompatibilität zwischen der Softwarekonfiguration für das neue Leitsystem und der Softwarekonfiguration für das alte Leitsystem ist zur Konfiguration des neuen Leitsystems eine von Experten durchzuführende Überarbeitung der sich auf die Softwarekonfiguration des alten Leitsystems beziehenden Information erforderlich.
Eine herkömmliche Vorgehensweise zur Ausführung dieser Konfiguration ist es, Abbildungstabellen zu verwenden, die es erlauben, logische Verknüpfungen zwischen den Elementen des alten Leitsystems und den Elementen des neuen Leitsystems aufzubauen. In der Praxis stellen diese Abbildungstabellen eine Richtlinie dar, wodurch das Erzeugen der Elemente der Konfiguration des neuen Leitsystems auf Grundlage der Elemente der Konfiguration des alten Leitsystems erlaubt bzw. ermöglicht wird. Neben einer völlig manuellen Vorgehensweise verwenden einige Verfahren nach dem Stand der Technik computerisierte Werkzeuge. Diese computerisierten Werkzeuge zielen darauf ab, die manuelle Transformation bzw. Umwandlung mittels einer automatischen Transformation der sich auf die Eingangs-/Ausgangs-Konfiguration des alten Leitsystems beziehenden Information zu beschleunigen.
In der EP-A-00 201 534.5, der EP-A-00 201 535.2, der EP-A-00 201 536.0, der EP-A-00 201 549.3, und der EP-A-00 201 550.1 werden ein Verfahren und ein sich darauf beziehendes Werkzeug beschrieben, die eine automatisierte Übersetzung oder Transformation erlauben, welche einige Nachteile der manuellen oder halbautomatischen zu der Zeit bekannten (Anmeldetag 28.04.2000) Vorgehensweisen beseitigt und welche für die
Übersetzung von Hardware/Software-Information der Konfiguration von Leitsystemen als nächstliegender Stand der Technik betrachtet werden können.
Jedoch liefern die in diesen Patentanmeldungen beschriebenen Verfahren zur Transformation einer ersten Information in einem ersten Format, die eine erste Softwarekonfiguration eines ersten verteilten Leitsystems beschreibt, in eine zweite Information in einem zweiten Format, die eine zweite Softwarekonfiguration eines zweiten verteilten Leitsystems beschreibt, z.B. das in der EP-A-00 201 550.1 beschriebene Verfahren, immer noch unbefriedigende Ergebnisse. Das in den angegebenen Patentanmeldungen beschriebene Verfahren basiert auf der Analyse und Transformation von Information, die die Hardware-/Softwarekonfiguration eines Leitsystems beschreibt. Diese Information wird außerhalb des computerisierten Werkzeugs dargestellt und in dieses importiert. Ein Hauptgrund für das unbefriedigende Ergebnis der in den angegebenen Patentanmeldungen beschriebenen Verfahren ist es, dass die Funktion eines Leitsystems nicht nur von der Information bestimmt wird, die die Hardware-/Softwarekonfι- guration, wie sie z.B. in der EP-A-201 534.5 beschrieben ist, explizit beschreibt, sondern, wie zuvor angegeben, auch durch die kennzeichnenden Merkmale der Betriebssysteme des Leitsystems, wie beispielsweise die Nutzung von bevorrechtigtem (präemptivem) oder nicht bevorrechtigtem (nicht präemptivem) Multitasking, das Abfragen von Ereignissen, die Abarbeitung iterativer Schleifen oder die Abarbeitung von Unterbrechungen, bestimmt wird. Diese Information ist in der Softwarekonfiguration nicht explizit dargestellt, sondern ist ein inhärentes Merkmai des Leitsystems und der darin verwendeten Betriebssysteme. Deswegen kann diese Information durch die in den angegebenen Patentanmeldungen beschriebene Vorgehensweise nicht berücksichtigt werden.
Wird die in den zuvor genannten Patentanmeldungen beschriebene Vorgehen sweise verwendet, so wird ein konvertiertes Programm erzeugt, das von Experten umfangreich manuell überarbeitet werden muss, damit bei der Prozesssteuerung auf dem neuen Leitsystem kein unterschiedliches oder sogar fehlerhaftes Verhalten hervorgerufen wird.
Das konvertierte Programm der Softwarekonfiguration kann ein textbasiertes Programm sein. Die US 5,842,204 und die US 5,768,546 beschreiben den Stand der Technik für
die Übersetzung von textbasierten Programmen. Diese Patente beschreiben zwei Verfahren, um Computersprachen von einem Quellsystem in die eines Zielsystems zu übersetzen. Der Hauptgrund, dass die in diesen beiden Patenten angegebenen Verfahren unzufriedenstellende Ergebnisse erzielen bzw. nicht verwendet werden können, ist, dass die Verfahren für Standardcomputerprogramme konzipiert sind, hier also keine textbasierten Programme für Leitsysteme berücksichtigt werden, die spezielle Charakteristiken und Funktionalitäten aufweisen, welche in normalen bzw. herkömmlichen Computern nicht existieren. Ein weiterer Grund für unzureichende Ergebnisse der in diesen Patenten beschriebenen Verfahren ist, dass keine Echtzeitumgebungen berücksichtigt werden können, was für Leitsysteme sehr wichtig ist. Ein weiterer Nachteil ist, dass durch die in den beiden Patenten beschriebenen Verfahren keine Übersetzung auf Grundlage einer wissensbasierten Vorgehensweise durchgeführt wird. Eine solche wissensbasierte Vorgehensweise ist flexibler, als eine fest-codierte Übersetzung, wie sie beispielsweise in den beiden Patenten beschrieben ist, und erlaubt bzw. ermöglicht das für die Übersetzung benötigte Wissen leichter zu sammeln und freier zu erweitern.
Zusätzlich zu den zuvor angegebenen Patenten existiert ein weiterer bedeutender Gesichtspunkt der textbasierten Übersetzung, der durch die EP 0 539 120 B1 beschrieben wird. Dieses Patent kann als Stand der Technik für die textbasierte Übersetzung auf Grundlage eines unabhängigen Baummodells erachtet werden. Das beschriebene Verfahren übersetzt das textbasierte Programm unter Berücksichtigung eines Baummodells, welches durch Parsen erzeugt wurde. Das beschriebene Verfahren liefert gute Ergebnisse bei der Übersetzung von textbasierten Sprachen, es basiert aber ebenfalls nicht auf einer Wissensbasis. Weiter werden auch hier nicht die speziellen Charakteristiken und Funktionalitäten von textbasierten Programmen in einem spezifischen Leitsystem berücksichtigt und auch auf die Merkmale von Echtzeitumgebungen, die für die in Leitsystemen ausgeführten textbasierten Programme wichtig sind, wird nicht eingegangen.
Der Erfindung liegt die A u f g a b e zugrunde, ein verbessertes Verfahren und System zur Transformation einer ersten Information in einem ersten Format, die eine erste Softwarekonfiguration eines ersten verteilten Leitsystems beschreibt, in eine
zweite Information in einem zweiten Format, die eine zweite Softwarekonfiguration eines zweiten verteilten Leitsystems beschreibt anzugeben, wodurch insbesondere der Aufwand zur manuellen Nachbearbeitung einer computerisiert gewandelten Information verringert oder vermieden wird.
Diese Aufgabe wird durch ein Verfahren sowie ein System zur Transformation einer ersten Information in einem ersten Format, die eine erste Softwarekonfiguration eines ersten verteilten Leitsystems beschreibt, in eine zweite Information in einem zweiten Format, die eine zweite Softwarekonfiguration eines zweiten verteilten Leitsystems beschreibt, mit den Merkmalen der unabhängigen Ansprüche gelöst.
Vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung ergeben sich aus den abhängigen Ansprüchen.
Die Erfindung baut auf dem gattungsgemäßen Stand der Technik dadurch auf, dass bei einem Verfahren das Laufzeitverhalten der ersten Softwarekonfiguration auf dem ersten Leitsystem erfasst und bei der Transformation in die zweite Information derart berücksichtigt wird, dass das zweite Leitsystem mit der zweiten Information ein zu dem ersten Leitsystem mit der ersten Information gleiches Laufzeitverhalten aufweist. Nach der Erfindung wird Information verwendet, die bis heute nicht beachtet wurde: Das Laufzeitverhalten, gleichwertig auch als Ausführungsverhalten oder Echtzeitverhalten bezeichnet, des ersten Leitsystems, z.B. über die implizite Information von intrinsischen oder inhärenten Merkmalen, die nach dieser Erfindung explizit beschrieben werden können und z.B. über eine Leitsystem-spezifische Wissensbasis zur Verfügung gestellt werden können. Durch die Verwendung dieser Information werden die zuvor beschriebenen Nachteile auf ein vemachlässigbares Maß bzw. einen vernachlässigbaren Grad reduziert.
Dabei kann die Softwarekonfiguration für ein Leitsystem in vorteilhafter Weise mittels einer Kombination einer oder mehrerer textbasierter oder nicht textbasierter Programmiersprachen dargestellt werden.
Weiter kann das Laufzeitverhalten für das erste Leitsystem in vorteilhafter Weise mittels einer Kombination einer oder mehrerer textbasierter oder nicht textbasierter Programmiersprachen dargestellt werden. Insbesondere bei der gleichzeitigen Darstellung auch der Softwarekonfiguration für ein Leitsystem, insbesondere für das erste Leitsystem, ergibt sich hier eine besonders einfache Möglichkeit der Darstellung.
Im vorstehend erläuterten Zusammenhang kann in vorteilhafter Weise weiterhin vorgesehen sein, dass jede textbasierte oder nicht textbasierte Programmiersprache nicht objektorientiert, sondern funktional, prozedural aufgebaut ist und auf bedingten oder unbedingten Anweisungen basiert.
Bei dem erfindungsgemäßen Verfahren ist vorzugsweise weiterhin vorgesehen, dass das Ausführungsverhalten des ersten Leitsystems über intrinsische Merkmale erfasst und/oder dargestellt wird, insbesondere über
- die Verwendung von bevorrechtigtem oder nicht bevorrechtigtem Multitasking,
- aufruf- oder ereignisgetriebener Signalisierung,
- der Verwaltung und Ausführung von iterativen Schleifen, sowie der Möglichkeit, Schleifen zu unterbrechen und Wiedereinstiegspunkte.
Diese intrinsischen Merkmale können erfindungsgemäß mit weiteren intrinsischen oder inhärenten Merkmalen erweitert werden, die sich auch direkt auf das/ verwendete erste und/oder zweite System beziehen können, z.B. einer System- und/oder Programmiersprachenspezifischer Abarbeitung von bedingten Anweisungen oder Aussagen.
Eine bevorzugte Weiterbildung des erfindungsgemäßen Verfahrens sieht vor, dass das Ausführungsverhalten des ersten Leitsystems über implizit in dessen Softwarekonfiguration gegebene Beziehungen erfasst wird. Hierdurch wird das Ausführungs- oder Laufzeitverhalten indirekt, aber in besonders einfacher Weise erlangt, da keine Analyse des ersten Leitsystems selbst, sondern nur eine Analyse der dieses steuernden Softwarekonfiguration hinsichtlich des Ausführungs- oder Laufzeitverhaltens des ersten Leitsystems notwendig ist. Alternativ kann natürlich auch eine Untersuchung des Ausführungs- oder Laufzeitverhaltens des ersten Leitsystems direkt erfolgen, d.h. z.B. über
eine Beobachtung der Aktionen des Leitsystems unter Berücksichtigung der Softwarekonfiguration.
Im Zusammenhang mit dem erfindungsgemäßen Verfahren wird weiterhin bevorzugt, dass das Ausführungsverhalten des ersten Leitsystems unter Verwendung von wenigstens einer Wissensdatenbank in die zweite Information gewandelt wird, wobei die wenigstens eine Wissensdatenbank wenigstens auf das erste Leitsystem zugeschnitten ist. Hierdurch kann ein Expertenwissen vorteilhaft für viele Transformationsprozesse zur Verfügung gestellt werden.
Bei dem erfindungsgemäßen Verfahren ist vorzugsweise weiterhin vorgesehen, dass Elemente der ersten Softwarekonfiguration über einen Satz Übersetzungsregeln in Elemente der IEC61131-Sprachen abgebildet werden. Die IEC61131 Sprachen, insbesondere die textbasierte Sprache IEC61131 Structured Text (ST) und IEC61131 Sequential Function Chart (SFC), eignen sich besonders für eine plattformunabhängige, d.h. neutrale Darstellung von Programmiersprachen. Eine nach der Erfindung in diese neutrale Darstellung gewandelte Softwarekonfiguration kann besonders einfach überprüft und/oder zur Emulation eines Leitsystems verwendet werden, sowie auch aus dieser neutralen Darstellung besonders einfach in die zweite Softwarekonfiguration gewandelt werden.
Weiter ist bei dem erfindungsgemäßen Verfahren vorzugsweise weiterhin vorgesehen, dass das Ausführungsverhalten von Elementen der ersten Softwarekonfiguration in Elemente der zweiten Softwarekonfiguration und/oder deren Anordnung darin abgebildet werden. Erfindungsgemäß kann unter Berücksichtigung des Ausführungsverhaltens in vorteilhafter Weise auf die bekannten Übersetzungsverfahren zurückgegriffen werden, z.B. auf die in der Beschreibungseinleitung genannten.
Bei dem erfindungsgemäßen Verfahren können dynamische Programmsteuerparameter, die die Ausführung der ersten Softwarekonfiguration in dem ersten Leitsystem leiten, in vorteilhafter Weise in Elemente der zweiten Softwarekonfiguration und/oder deren Anordnung abgebildet werden. Durch eine solche Abbildung erfolgt eine besonders einfache Umwandlung bzw. Transformation, insbesondere wenn dies nicht
direkt, sondern über die zuvor beschriebene neutrale Schicht erfolgt, da dann bei der Transformation aus der neutralen Schicht nur einzelne Elemente und keine Programmsteuerparameter berücksichtigt werden müssen.
Weiter kann die ersten Softwarekonfiguration vorzugsweise so in eine neutrale Schicht abgebildet werden, die unterschiedliche ein Ausführungsverhalten nachbildende Zustände aufweist, dass dort die erste Softwarekonfiguration sowie deren Ausführungsverhalten in dem ersten Leitsystem nachgebildet werden. Auf diese Weise ist eine Emulation des Ausführungsverhaltens in einfacher Weise möglich, so dass dieses durch einen Experten nur nachgeprüft und ggf. in dessen Abweichungen überarbeitet werden muss.
Dabei kann die neutrale Schicht in vorteilhafter Weise auf einem erweiterten Zustandsmodell basieren, welches einen Grundzustand, einen Haltzustand, einen aktiven Zustand, und einen ausgeschalteten Zustand aufweist, wobei Übergänge
- von dem ausgeschalteten Zustand mittels eines "An"-Befehls in den Grundzustand,
- von dem Grundzustand entweder mittels eines "Aus"-Befehls in den Auszustand oder mittels eines "Starf-Befehls in den aktiven Zustand,
- von dem aktiven Zustand entweder mittels eines "Stop"-BefehIs in den Grundzustand oder mittels eines "Halt"-Befehls in den Haltzustand, und
- von dem Haltzustand entweder mittels eines "Stop"-Befehls in den Grundzustand oder mittels eines "Weiter'-Befehls in den aktiven Zustand vorgesehen sind, und wenigstens zu Elementen der Softwarekonfiguration des ersten Leitsystems gewandelte Elemente in dem aktiven Zustand implementiert werden. Durch dieses erweiterte Zustandsmodell kann erfindungsgemäß jedes Ausführungsverhalten in ausreichender Weise von einem ersten Leitsystem auf ein zweites Leitsystem umgesetzt werden. Es können entweder ganze Programme der Softwarekonfiguration des ersten Leitsystems oder auch nur Teile davon mittels des erweiterten Zustands- modells dargestellt werde, d.h. das erweiterte Zustandsmodell ist durch eine Ineinan- derverschachtelung skalierbar.
Die Erfindung baut auf dem gattungsgemäßen Stand der Technik weiterhin dadurch auf, dass ein System das Laufzeitverhalten der ersten Softwarekonfiguration auf dem ersten Leitsystemerfasst und bei der Transformation in die zweite Information derart berücksichtigt, dass das zweite Leitsystem mit der zweiten Information ein zu dem ersten Leitsystem mit der ersten Information gleiches Laufzeitverhalten aufweist. Dadurch ergeben sich die im Zusammenhang mit dem erfindungsgemäßen Verfahren erläuterten Vorteile in gleicher oder ähnlicher Weise, weshalb zur Vermeidung von Wiederholungen auf die entsprechenden Ausführungen verwiesen wird.
Gleiches gilt sinngemäß für die folgenden bevorzugten Ausführungsformen des erfindungsgemäßen Systems, wobei auch bezüglich der durch diese Ausführungsformen erzielbaren Vorteile auf die entsprechenden Ausführungen im Zusammenhang mit dem erfindungsgemäßen Verfahren verwiesen wird.
Dabei kann das System die Softwarekonfiguration für ein Leitsystem in vorteilhafter Weise mittels einer Kombination einer oder mehrerer textbasierter oder nicht textbasierter Programmiersprachen darstellen.
Weiter kann das System das Laufzeitverhalten für das erste Leitsystem in vorteilhafter Weise mittels einer Kombination einer oder mehrerer textbasierter oder nicht textbasierter Programmiersprachen darstellen.
Im vorstehend erläuterten Zusammenhang kann in vorteilhafter Weise weiterhin vorgesehen sein, dass darin jede textbasierte oder nicht textbasierte Programmiersprache nicht objektorientiert, sondern funktional, prozedural aufgebaut ist und auf bedingten oder unbedingten Anweisungen basiert.
Bei dem erfindungsgemäßen System ist vorzugsweise weiterhin vorgesehen, dass es das Ausführungsverhalten des ersten Leitsystems über intrinsische Merkmale erfasst und/oder dargestellt, insbesondere über
- die Verwendung von bevorrechtigtem (präemptivem) oder nicht bevorrechtigtem (nicht präemptivem) Multitasking,
- aufruf- oder ereignisgetriebener Signalisierung,
- der Verwaltung und Ausführung von iterativen Schleifen, sowie
- der Möglichkeit, Schleifen zu unterbrechen und Wiedereinstiegspunkte.
Eine bevorzugte Weiterbildung des erfindungsgemäßen Systems sieht vor, dass es das Ausführungsverhalten des ersten Leitsystems über implizit in dessen Softwarekonfiguration gegebene Beziehungen erfasst.
Im Zusammenhang mit dem erfindungsgemäßen System wird weiterhin bevorzugt, dass es das Ausführungsverhalten des ersten Leitsystems unter Verwendung von wenigstens einer Wissensdatenbank in die zweite Information wandelt, wobei die wenigstens eine Wissensdatenbank wenigstens auf das erste Leitsystem zugeschnitten ist.
Bei dem erfindungsgemäßen System ist vorzugsweise weiterhin vorgesehen, dass es Elemente der ersten Softwarekonfiguration über einen Satz Übersetzungsregeln in Elemente der IEC61131-Sprachen abbildet.
Weiter ist bei dem erfindungsgemäßen System vorzugsweise weiterhin vorgesehen, dass es das Ausführungsverhalten von Elementen der ersten Softwarekonfiguration in Elemente der zweiten Softwarekonfiguration und/oder deren Anordnung darin abbildet.
Das erfindungsgemäße System kann dynamische Programmsteuerparameter, die die Ausführung der ersten Softwarekonfiguration in dem ersten Leitsystem leiten, in vorteilhafter Weise in Elemente der zweiten Softwarekonfiguration und/oder deren Anordnung abbilden.
Weiter kann das erfindungsgemäße System in vorteilhafter Weise die erste Softwarekonfiguration so in eine neutrale Schicht abbilden, die unterschiedliche ein Ausführungsverhalten nachbildende Zustände aufweist, dass dort die erste Softwarekonfiguration sowie deren Ausführungsverhalten in dem ersten Leitsystem nachgebildet werden.
Dabei kann die neutrale Schicht in dem erfindungsgemäßen System in vorteilhafter Weise auf einem erweiterten Zustandsmodell basieren, welches einen Grundzustand,
einen Haltzustand, einen aktiven Zustand, und einen ausgeschalteten Zustand aufweist, wobei Übergänge
- von dem ausgeschalteten Zustand mittels eines "An"-Befehls in den Grundzustand,
- von dem Grundzustand entweder mittels eines "Aus"-Befehls in den Auszustand oder mittels eines "Starf-Befehls in den aktiven Zustand,
- von dem aktiven Zustand entweder mittels eines "Stop"-Befehls in den Grundzustand oder mittels eines "Half-Befehls in den Haltzustand, und
- von dem Haltzustand entweder mittels eines "Stop"-Befehls in den Grundzustand oder mittels eines "Weiter"-Befehls in den aktiven Zustand vorgesehen sind, und wenigstens zu Elementen der Softwarekonfiguration des ersten Leitsystems gewandelte Elemente in dem aktiven Zustand implementiert werden.
Ein Computerprogramm, das die Merkmale des erfindungsgemäßen Verfahrens aufweist und durch geeignete Hardware ausgeführt wird, führt zu einer bevorzugten Ausführungsform des erfindungsgemäßen Systems. Ein Computerprogramm, insbesondere ein auf einen Datenträger gespeichertes Computerprogramm, das die Merkmale des erfindungsgemäßen Verfahrens aufweist, wird daher ausdrücklich in den Offenbarungsgehalt der vorliegenden Anmeldung einbezogen.
Nach der Erfindung kann die erste Softwarekonfiguration des ersten Leitsystems in die zweite Softwarekonfiguration für das zweite Leitsystem unterschiedlicher Art oder unterschiedlichen Typs übersetzt werden.
Sowohl die erste Konfiguration für das erste Leitsystem als auch die zweite Konfiguration für das zweite Leitsystem sind vorgesehen, den selben Industrieprozess zu steuern oder regeln, indem kontinuierliche Steuerung/Regelung, diskrete Steuerung/Regelung, Batches und Sequenzen verwaltet werden. Die zweite Softwarekonfiguration soll mit dem zweiten Leitsystem in Bezug auf die erste Softwarekonfiguration mit dem ersten Leitsystem dasselbe oder ein verbessertes Verhalten erzeugen. Demzufolge muss die zweite Softwarekonfiguration unabhängig von der verwendeten Sprache mit dem zweiten Leitsystem auch dasselbe funktionale Verhalten und Ausführungsverhalten zeigen, wie die erste Softwarekonfiguration mit
den ersten Leitsystem, was nach der Erfindung gewährleistet oder zumindest besser unterstützt ist.
Das automatische, vorzugsweise computerisierte Werkzeug nach der Erfindung kann die Merkmale der in den EP-A-00 201 534.5, der EP-A-00 201 535.2, der EP-A-00 201 536.0, der EP-A-00 201 549.3, und der EP-A-00 201 550.1 beschriebenen Werkzeuge aufweisen, welche hiermit durch Bezugnahme in diese Anmeldung aufgenommen sind, wodurch die dort beschriebenen Merkmale mit den hier beschriebenen in beliebiger Weise kombinierbar sind. Somit kann das erfindungsgemäße Werkzeug alle relevanten Gesichtspunkte der Konfiguration eines Leitsystems unabhängig von der Komplexität oder der Anzahl von Leitsystem-Einheiten und verwendeten Programmiersprachen verwalten. Weiter kann das computerisierte Werkzeug die Verknüpfungen zwischen den unterschiedlichen Gesichtspunkten verwalten und es ist leicht erweiterbar, um neue Arten von Leitsystemen sowohl als Quelle oder auch als Ziel erfassen zu können.
Nach dieser Erfindung kann zusätzlich das Ausführungsverhalten von syntaktischen Elementen, wie z.B. Aussagen, Schlüsselwörtern und graphischen Elementen, der textbasierten und/oder nicht textbasierten Sprache der Quelle in syntaktische Elemente, wie z.B. Aussagen, Schlüsselwörter und graphische Elemente, der textbasierten und/oder nicht textbasierten Sprache des Ziels zugeordnet werden.
Weiter können nach dieser Erfindung zusätzlich die sich auf die Laufzeit beziehenden Programmsteuerparameter abgebildet werden, die die Ausführung der Programme in der Echtzeitumgebung von Leitsystem-Einheiten des Leitsystems verwalten können.
Die Erfindung wird nun unter Bezugnahme auf die beigefügten Zeichnungen anhand einer bevorzugten Ausführungsform beispielhaft erläutert, bei der insbesondere ein in einer textbasierten Sprache vorliegendes Programm in eine nicht-textbasierte Darstellung in der neutralen Ebene gewandelt bzw. transformiert wird.
Es zeigen:
Figur 1 ein beispielhaftes Diagramm der Wirkweise des Werkzeugs nach der
Erfindung;
Figur 2 einen Zustandsgraphen von Programmen in der textbasierten Sprache
TCL (Taylor Control Language);
Figur 3 einen Zustandsgraphen von Programm in einer neutralen Schicht;
Figur 4 ein SFC-Programm des Zustandsgraphen in der neutralen Schicht;
Figur 5 eine Einbindung des konvertierten Quellenprogramms in den in der in Fig.
4 gezeigten Zustandsgraphen;
Figur 6 einen Aufbau der konvertierten Programme in dem Zielsystem; und
Figur 7 eine SFC-Übersetzung eines Programmablaufs, der durch eine eine strukturierte Programmiersprache vorgegeben ist.
Figur 1 gibt einen ergebnisorientierten Überblick über die Funktionsweise eines erfindungsgemäßen Systems. In der Fig. 1 sind die textbasierten und nicht textbasierten Sprachen beispielhaft mittels der textbasierten Sprache IEC61131 Structured Text (nämlich ST) und der nicht textbasierten Sprache IEC61131 Sequential Function Chart (nämlich SFC) erläutert. Die Erfindung ist jedoch allgemein zu sehen und sprachenunabhängig. Es ist gezeigt, dass die Programme eines ersten Leitsystems 1 , nämlich ein SFC-Programm 1a und ein textbasiertes Programm 1b, durch eine Übersetzung in Programme eines zweiten Leitsystems 2, nämlich in ein textbasiertes Programm 2a und ein SFC-Programm 2b, gewandelt bzw. transformiert werden.
Das beschriebene Werkzeug führt also die Konvertierung der Konfigurationsinformation des ersten Leitsystems aus dem Format, das sich auf das Entwicklungswerkzeug des ersten Leitsystems bezieht, in ein Format und einen Aufbau durch, welcher sich auf das zweite Leitsystem beziehen.
Die Transformation einer solchen Konfiguration umfasst es bzw. beinhaltet, die Art und Anzahl von Leitsystem-Einheiten in dem Leitsystem, die Art, Anzahl und Einstellungen von E/A-Schnittstellen, die zur Kommunikation mit dem Prozess an die verschiedenen Leitsystem-Einheiten des Leitsystems angeschlossen sind, die benötigten Kommunikationsstrecken zwischen Leitsystem-Einheiten und einem übergeordneten Überwachungsmittel des Leitsystems, die in unterschiedlichen Sprachen (nicht textbasiert und/oder textbasiert) geschriebenen das Verhalten des Leitsystems definierenden Programme, und die Daten und Zeitbeziehungen zwischen den verschiedenen Programmen zu erfassen.
Alle Beziehungen, die in beliebiger Art zwischen Elementen der Konfiguration bestehen, werden ebenfalls in der zur Transformation benutzten Information vorgesehen, die von dem Übersetzungswerkzeug verwendet wird. Die von dem Übersetzungswerkzeug verwendete Information über das erste Leitsystem ist konzeptionell äquivalent zu dessen Konfigurationsinformation, ist aber in einem Format dargestellt, auf welches das Werkzeug einfach zugreifen kann und welches das Werkzeug einfach verwalten kann.
Der Hauptaspekt dieses Konfigurationswerkzeugs ist es, dass die Übersetzung aus textbasierten und/oder nicht textbasierten Programmiersprachen in andere textbasierte und/oder nicht textbasierte Programmiersprachen, wie z.B. IEC61131SFC und/oder ST erfolgt, wobei das Laufzeitverhalten berücksichtigt wird. Diese Programmiersprachen werden normaler weise verwendet, Abfolgen und Batches zu verwalten, obwohl sie ebenfalls für kontinuierliche und diskrete Steuerungen oder Regelungen verwendet werden könnten. Im Folgenden wird die Übersetzung von textbasierten und nicht textbasierten Sprachen beispielhaft lediglich anhand der Übersetzung einer textbasierten Sprache in eine nicht textbasierte Sprache wie IEC61131SFC dargestellt. Die Vorgehensweise nach der Erfindung ist jedoch allgemein und von den verwendeten Sprachen unabhängig, wie es in der Fig. 1 angedeutet ist, die ein vereinfachtes Ablaufdiagramm des Werkzeugs ergebnisorientiert darstellt.
Der textbasierte Code, wie alle anderen Programme in der Leitsystem-Einheit, wird mit einer bestimmten, dem entsprechenden Task zugeordneten Rate ausgeführt. Weiter kann eine Interaktion mit dem Rest der Programme der Leitsystem-Einheit stattfinden.
Jede Aussage oder jedes Schlüsselwort der textbasierten Sprache weist ein wohldefiniertes funktionales und Ausführungsverhalten auf. Die textbasierte Sprache des Ziels, in diesem Fall SFC und ST, weist unterschiedliche syntaktische und semantische Elemente auf, um dasselbe Verhalten zu erzeugen. Demzufolge muss die Übersetzungseinheit einen Satz von Übersetzungsregeln aufweisen, die die Elemente der textbasierten Sprache der Quelle auf die Elemente der Sprachen des Ziels abbilden, z.B. der IEC61131 -Sprachen, die auch für die nach der Erfindung vorteilhafter Weise vorgesehene neutrale Schicht verwendet werden können.
Die Übersetzung umfasst also zwei wichtige Teile:
1. Das Ausführungsverhalten der Schlüsselworte und Aussagen der textbasierten Sprache der Quelle muss auf die Aussagen, Schlüsselworte und graphischen Elemente der SFC- und ST-Sprachen abgebildet werden.
2. Die dynamischen Programmsteuerparameter, wie z.B. Zustand, Status, Modus, die die Ausführung des Programms leiten, müssen abgebildet werden.
A) Abbildung der sich auf die Ausführungszeit beziehenden Programmsteuerparameter, wie Zustand, Status, Modus
In den textbasierten Sprachen der Quelle können die sich auf die Ausführungszeit beziehenden Programmsteuerparameter, wie Zustand, Status und Modus, die die Ausführung des Programms beeinflussen, über die Ausführung von Aussagen manipuliert werden.
Eine Manipulation dieser Parameter bietet die Mittel, um
- ein Programm zu aktivieren, abzubrechen oder in einen Pausenzustand zu versetzen (Zustand),
- unnormale Bedingungen zu definieren, detektieren und zu verwalten (Status), und
- ein Verfahren der schrittweisen Ausführung zu steuern (Modus).
In der Fig. 2 ist die textbasierte Sprache TCL (Taylor Control Language) beispielhaft dargestellt, in der Programme drei Zustände aufweisen: inaktiv, aktiv und pausierend. Die Erfindung ist jedoch nicht auf die Darstellung von TCL beschränkt, sondern ermöglicht eine allgemeine und sprachunabhängige Darstellung.
Die Fig. 2 zeigt, dass ein Programm von einem inaktiven Zustand 3 über eine Aktivierung in einen aktiven Zustand 4 überführt werden kann, von welchem es über eine Beendigung oder einen Abbruch wiederum in den inaktiven Zustand 3 versetzt werden kann oder alternativ über einen Pausenbefehl in einen Pausenzustand 5 versetzt werden kann. Aus dem Pausenzustand 5 kann das Programm über einen Abbruch in den inaktiven Zustand 3 oder über einen Wiederaufnahmebefehl wieder zurück in deήi aktiven Zustand 4 versetzt werden.
In TCL existieren drei Arten der Manipulation des Zustands, Status und Modus in Programmen:
1. Demand, d.h. ein (direkter, unbedingter) Befehl, der einen Übergang von Zustand, Status oder Modus hervorruft, z.B.: Activate ('POWERUP', 3);
2. Event, d.h. eine EVENT/ENDEVENT-Struktur definiert ein Ereignis in einem TCL- Programm; diese wird verwendet, um spezifische Bedingungen zu definieren, entsprechend der einer oder mehrere Zustands-, Status- und/oder Modusübergänge erfolgen.
3. Time, d.h. Zustands-, Status- und Modusübergänge können in TCL-Programmen über Zeitablauffunktionen manipuliert werden.
Um in einem IEC61131 -basierten Zielsystem das Laufzeitverhalten eines TCL-Pro- gramms (und all der anderen Programmiersprachen für ein Leitsystem) zu emulieren, ist es nötig, die unterschiedlichen in dem Quellsystem möglichen Zustände eines TCL- Programms nachzubilden. Demzufolge wurde nach einer bevorzugten Ausführungsform der Erfindung auf Grundlage des TCL-Zustandsmodells ein erweitertes Zustandsmodell entwickelt, welches auch für andere textbasierte Sprachen, die in einer Quelle verwen-
det werden können, für die Darstellung von unterschiedlichen Zuständen eines allgemeinen Programms in einer neutralen Schicht verwendet werden kann. Durch diese neutrale Darstellung wird bei der Übersetzung von dem Quell- in das Zielsystem ein Zwischen seh ritt realisiert.
Dieses erweiterte Zustandsmodell nach einer vorteilhaften Weiterbildung der Erfindung ist in der Fig. 3 gezeigt und weist einen Grundzustand 6, einen Haltzustand 7, einen aktiven Zustand 8, und einen ausgeschalteten Zustand 9 auf. Von dem ausgeschalteten Zustand 9 kann ein Programm mittels eines "An-"Befehls in den Grundzustand 6 überführt werden, von dem es mittels eines "Aus"-Befehls wieder in den Auszustand 9 überführt werden kann. Ein Programm kann von dem Grundzustand 6 mittels eines "Starf-Befehls in den aktiven Zustand 8 überführt werden und von dem aktiven Zustand 8 mittels eines "Stop"-Befehls in den Grundzustand 6 zurückversetzt werden. Aus dem aktiven Zustand 8 kann ein Programm mittels eines "Hal '-Befehls in den Haltzustand 7 versetzt werden, von dem es entweder mittels eines "Stop"-Befehls in den Grundzustand 6 oder mittels eines "Weiter'-Befehls in den aktiven Zustand 8 versetzt werden kann.
Um dieses Zustandsmodell in einem IEC61131 -basierten Zielsystem zu implementieren, ist es nötig, einen Coderahmen um den zugrunde liegenden Quellcode zu erstellen. Die Fig. 4 zeigt, wie dieser Code mit SFC realisiert werden kann. Dieser Coderahmen, hier ein SFC-Rahmen, kann die in der Fig. 3 gezeigten unterschiedlichen Programmzustände emulieren.
Von einem SFC-BaseState-Zustand 10, der dem Grundzustand 6 entspricht, kann das Programm entweder nach Erfüllung der Bedingung T_off 11 in einen SFC-Down- Zustand 12, der dem Auszustand 9 entspricht, oder unter Erfüllung der Bedingung T_start 13 in einen SFC-Active-Zustand 14 verzweigen, der dem Aktivzustand 8 entspricht. Aus dem SFC-Down-Zustand 12 kann das Programm unter der Bedingung T_on 15 wieder in den SFC-BaseState-Zustand 10 versetzt werden. Aus dem SFC- Active-Zustand 14 kann das Programm entweder unter der Bedingung TA__stop 16 in den SFC-BaseState-Zustand 10 oder unter der Bedingung TJialt 17 in einen SFC-Halt- Zustand 18 verzweigen, der dem Haltzustand 7 entspricht. Aus dem SFC-Halt-Zustand
18 kann das Programm entweder unter der Bedingung Th_Stop 19 in den SFC- BaseState-Zustand 10 oder unter der Bedingung T_CONTINUE 20 in den SFC-Active- Zustand 14 verzweigen.
Nach einer weiteren bevorzugten Ausgestaltung der Erfindung wird ein gewandeltes Quellprogramm in dem SFC-Active-Zustand 14 des SFC-Rahmens platziert, wie es beispielhaft für ein ebenfalls in SFC gewandeltes oder übersetztes Quellprogramm 21 in der Fig. 5 gezeigt ist.
Für den Fall, dass kein Programm aktiv ist, wird das ganze Untersystem in eine Art Basiszustand oder grundlegenden Zustand gesetzt. Zusätzlich kann festgelegt sein, dass nur ein Programm gleichzeitig ausgeführt werden kann. Dieses Verhalten kann mittels eines einfachen SFC-Rahmens mit einem Grundlegenden Zustand und parallelen Phasen für jedes gewandelte Quellprogramm emuliert werden. Die Fig. 6 zeigt, wie die gewandelten Quellprogramme (SFC und/oder ST) nach einem solchen Schema implementiert werden könnten. Aus dem grundlegenden Zustand 22 kann in verschiedene Programme verzweigt werden, z.B. in ein erstes Programm 23, das dem in der Fig. 5 gezeigten gewandelten Quellprogramm 21 im SFC-Code entspricht, in ein zweites textbasiertes Programm 24, oder in ein drittes Programm 25, das wiederum dem in der Fig. 5 gezeigten gewandelten bzw. transformierten Quellprogramm 21 entspricht. Nach Abarbeitung eines dieser Programme wird wieder der grundlegende Zustand 22 erreicht.
B) Abbildung des Ausführungsverhaltens der syntaktischen Elemente einer textbasierten und/oder nicht textbasierten Sprache
Das Ausführungsverhalten eines syntaktischen Elements einer textbasierten und/oder nicht textbasierten Sprache bezieht sich darauf, wie die Leitsystem-Einheit dieses syntaktische Element ausführt. Z.B. kann das syntaktische Element eine normale Aussage sein, die in einem Task zusammen mit anderen Aussagen vollständig in einer Durchlaufzeit des Tasks, z.B. in einem dem Task zugeordneten CPU-Zeitschlitz, ausgeführt wird. Es gibt aber auch andere Aussagen, die für eine bestimmte Zeit oder auf eine bestimmte Eingabe aus dem Feld warten müssen, wodurch ihre Ausführung
sich über mehr als eine Durchlaufzeit erstreckt, d.h. in mehreren aufeinanderfolgenden dem Task zugeordneten Zeitschlitzen der CPU.
Die Analyse der textbasierten Sprachen ergibt, dass die folgenden syntaktischen Elemente existieren:
- Normale Aussage (normal_statement): Die Ausführungszeit einer normalen Aussage hängt nur von der CPU-Zeit ab und ist immer gleich.
- Unterbrechbare Aussage (break_statement): Die Ausführungszeit einer unterbrechbaren Aussage hängt von ihrer funktionalen Definition ab. Unterbrechbar bedeutet, dass die Ausführung in einer bestimmten Durchlaufzeit angehalten wird und in der nächsten Durchlaufzeit weitergeführt wird.
Mit Hilfe dieser Ausführungsmerkmale kann das Ausführungsverhalten des textbasierten Quellprogramms auf das Zielprogramm abgebildet werden. Das bedeutet, dass die folgenden beispielhaft dargestellten Verfahrensschritte nur notwendig sind, wenn zwischen den betrachteten Elementen des Quellsystems und des Zielsystems ein unterschiedliches Laufzeitverhalten besteht.
Im Folgenden wird die Übersetzung einer for-Schleife beschrieben, die einen unterbrechbaren Ausführungszweig enthält, nämlich einen if-then-Zweig, und aus der nachfolgend beschrieben strukturierten Programmiersprache in die in der Fig. 7 gezeigte IEC61131-SFC übersetzt wird.
normal_statement1 for J = 0 TO 15
{ normal_statement2 if(if_condition1)
{ normal_statement3 break_statement1 normal_statement4
} eise
{ normal_statement5
} normal_statement6
} normal_statement7
Die unterbrechbare Aussage, hier break_statement1 , kann eine Aussage sein, die darauf wartet, dass eine digitale Eingabe des zugeordneten Feldes wahr wird. Auf diese Weise kann es sein, dass das Programm an dieser Stelle länger als eine Durchlaufzeit warten muss. Das bedeutet, dass die SU-Einheit, in der dieses Programm abläuft, die Ausführung dieses Programms in dieser Durchlaufzeit beendet (eine Art Bevorrechtigung) und in der nächsten Durchlaufzeit weitergeführt. Ist die digitale Eingabe des Feldes jetzt noch nicht wahr geworden, so wird die Ausführung dieses Programms wiederum beendet und in der darauffolgenden Durchlaufzeit weitergeführt, und so weiter.
Die Ausführung in dem Quellsystem geschieht folgendermaßen:
- Vor der for-Schleife wird die erste normale Aussage normal_statement1 ausgeführt.
- In der for-Schleife wird zunächst die zweite normale Aussage normal_statement2 ausgeführt, bevor die Verzweigung auf Grundlage einer Bedingung if_condition1 erfolgt. Die for-Schleife wird in der gleichen Durchlaufzeit ausgeführt, wenn eine normale Verzweigung auftritt, d.h. wenn die Bedingung if_condition1 nicht gegeben ist und somit der else-Zweig mit der fünften normalen Aussage normal_statement5 ausgeführt wird.
- Die for-Schleife wird bei Auftreten des unterbrechbaren Zweiges, d.h. wenn die Bedingung if_condition1 gegeben ist, an der Stelle gestoppt, an der die Unterbrechungsanweisung besteht, d.h. nach der Ausführung der dritten normalen Aussage normal__statement3 bei der unterbrechbaren Aussage break_statement1 , und nächstes Mal von dieser Stelle wieder gestartet. Die Wartezeit hängt von der Art der Unterbrechungsanweisung und den zugeordneten Parametern ab, z.B. kann für eine bestimmte Zeit gewartet werden, öder es kann darauf gewartet werden, dass ein bestimmter Zustand wahr wird.
- Nach der Unterbrechungsanweisung wird die im unterbrechbaren Zweig vorgesehene nächste vierte normale Anweisung normal_statement4 erst nach der durch die Unterbrechungsanweisung spezifizierten Zeit ausgeführt.
- Nach der Verzweigung wird in der selben Durchlaufzeit die sechste normale Aussage normal_statement6 ausgeführt.
- Nach der for-Schleife wird ebenfalls in der selben Durchlaufzeit die siebte normale Aussage normal_statement7 ausgeführt.
Bei der Analyse des Codes der strukturierten Programmiersprache ist festzustellen, dass es einen Ausführungspfad gibt, der nur aus normalen Anweisungen besteht, und einen Ausführungspfad, der eine Unterbrechungsanweisung enthält. Da wenigstens ein normaler Pfad enthalten ist, muss die Schleife kontinuierlich so oft wie möglich in einer Durchlaufzeit abgearbeitet werden, z.B. wie oben angegeben vollständig einschließlich der vor- und nachstehenden ersten und siebten normalen Aussagen normal__statement1 und normal_statement7, wenn die Durchlaufzeit lang genug ist.
Die Fig. 7 zeigt eine mögliche Lösung in dem Zielsystem. Aufgrund des unterbrechbaren Ausführungspfades ist der Ablauf in vier Schritte geteilt und die for-Schleife ist in
eine while-Schleife übersetzt. Die for-Schleife wird zu einer while-Schleife, da die in ST und SFC vorgesehene for-Schleife keine Boolesche Bedingung erlaubt, sondern nur die Deklaration der ersten und letzten Indizes, d.h. des Startwerts und des Endwerts der Schleife. Deshalb muss die Schleife alternativ gestoppt werden, wenn die Unterbrechungsanweisung auftreten kann, welche dann in dem nächsten Schritt ausgeführt wird.
Nach einem ersten Schritt S1 , der lediglich die erste normale Aussage normal_statement1 enthält, um den nächsten Schritt nicht zu komplizieren, erfolgt bei Erfüllung einer ersten Programmbedingung 26 TRUE, die immer gegeben ist, ein zweiter Schritt S2. Der Nachteil daran ist, dass die Ausführung stoppt, nachdem die Anweisung abgearbeitet wurde.
Der zweite Schritt S2 enthält die while-Schleife in ihrem normalen Zweig vollständig und setzt in ihrem unterbrechbaren Zweig lediglich eine allgemeine Unterbrechungsbedingung, die zu einem Übergang in einen nächsten Schritt führt der die Unterbrechungsanweisung sowie den Code enthält, der nach der Unterbrechungsanweisung ausgeführt werden soll (siehe Schritt S3). Der sich innerhalb der while-Schleife befindliche Code ist in Bezug auf den Quellcode etwas abgeändert, um dasselbe Verhalten zu garantieren.
Insbesondere wird im zweiten Schritt S2 zunächst die allgemeine Unterbrechungsbedingung break_path definiert auf nicht gegeben, d.h. false, gesetzt, wonach die while- Schleife unter den Bedingungen der Schleifenvariablen, hier J<= 5, und der nicht gegebenen allgemeinen Unterbrechungsbedingung ausgeführt wird. In der while- Schleife wird zunächst die zweite normale Aussage normal__statement2 ausgeführt, bevor die Bedingung if_condition1 geprüft wird. Bei gegebener Bedingung if_condition1 wird innerhalb der Bedingung if_condition1 die dritte Aussage normal_statement3 ausgeführt und die allgemeine Unterbrechungsbedingung break_path auf gegeben, d.h. true, gesetzt. Bei nicht gegebener Bedingung if_condition1 wird innerhalb der Bedingung if_condition1 die fünfte normale Aussage normal_statement5 ausgeführt. Nach der Bedingung if_condition1 wird bei nicht gegebener allgemeiner Unterbrechungsbedingung break_path die sechste normale Aussage normal_statement6, sowie eine Inkrementierung der Schleifenvariablen ausgeführt, bevor die while-Schleife beendet wird.
Nach dem zweiten Schritt S2 erfolgt abhängig von der allgemeinen Unterbrechungsbedingung und der Schleifenbedingung entweder ein dritter Schritt S3 oder ein vierter Schritt S4. Der dritte Schritt S3 erfolgt bei einer gegebenen zweiten Programmbedingung 29, wenn die Schleifenbedingung gegeben ist und die allgemeine Unterbrechungsbedingung gegeben ist. Der vierte Schritt S4 erfolgt bei einer gegebenen dritten Programmbedingung 27, wenn die Schleifenbedingung nicht gegeben ist und die allgemeine Unterbrechungsbedingung nicht gegeben ist.
In dem dritten Schritt S3 erfolgt zunächst bei nicht gegebener allgemeiner Unterbrechungsbedingung eine Überprüfung der Unterbrechungsbedingung check__break_statement1 , wobei der allgemeinen Unterbrechungsbedingung break_path1 das negierte Überprüfungsergebnis zugewiesen wird. Danach erfolgen die innerhalb der Schleife nachfolgenden Aussagen, nämlich die vierte normale Aussage normal_statement4 und die sechste normale Aussage normal_statement6, sowie eine Inkrementierung der Schleifenvariablen. Nach dem dritten Schritt S3 erfolgt bei einer gegebenen vierten Programmbedingung 30, dass die allgemeine Unterbrechungsbedingung nicht gegeben ist, ein Sprung zum zweiten Schritt S2.
In dem vierten Schritt S4 wird die nach der Schleife angegebene siebte normale Aussage normal_statement7 ausgeführt, wonach bei Erfüllung einer fünften Programmbedingung 28 true, die immer gegeben ist, der zuvor beschriebene Teil der strukturierten Programmiersprache vollständig abgearbeitet ist.
Das Verhalten dieser Sequenz ist sehr nahe an der Quellsequenz, mit den folgenden
Ausnahmen:
- Zwischen der ersten normalen Anweisung normal_statement1 und dem zweiten Schritt S2, in dem die Übersetzung der for-Schleife implementiert ist, liegt die Beendigung einer Durchlaufzeit und die Zuteilung der nächsten Durchlaufzeit. Bei dem Quellcode werden die erste normale Anweisung und der erste Schleifendurchlauf der for-Schleife in derselben Durchlaufzeit durchgeführt. Um hier näher am Quellcode zu sein, können der erste und der zweite Schritt S1 und S2 auch zusammengefasst werden.
- Nach der Unterbrechungsanweisung stoppt die Ausführung, d.h. der dritte Schritt S3 wird der aktive Schritt. Erst in der nächsten Durchlaufzeit wird die allgemeine Unterbrechungsbedingung (break_path1) in die nicht gespeicherte Aktion berechnet. Wenn dies in derselben Durchlaufzeit wahr wird, werden die Anweisungen in der Aktion beim Verlassen ausgeführt. In derselben Durchlaufzeit kehrt die Verarbeitungsfolge in den zweiten Schritt S2 zurück. Das Problem liegt darin, dass bei unmittelbarem Wahrwerden der Unterbrechungsbedingung in Bezug auf das Quellsystem eine Durchlaufzeit verloren geht.
Diese Lösung ist skalierbar, in anderen Worten ist es möglich, die Anzahl von Alternativverzweigungen durch die Implementierung eines ähnlichen Musters zu erhöhen, wenn mehr unterbrechbare Ausführungszweige vorgesehen werden müssen. Die check_break_statement1 -Anweisung ist ein Ausdruck oder eine Funktion, die den Zustand der Unterbrechungsanweisung überprüft.
Die bevorzugte Ausführungsform des beschriebenen Werkzeugs sieht wie folgt aus:
1. Ein PC, auf dem ein geeignetes multitaskingfähiges System mit einer graphischen Benutzeroberfläche läuft, die vorzugsweise die Möglichkeit zum öffnen eines oder mehrerer Fenster hat.
2. Eine in Java realisierte virtuelle Maschine, die an das Betriebssystem angepasst ist, und verwendet wird, die Kernfunktionalität des beschriebenen Übersetzungswerkzeugs auszuführen.
3. Ein geeignetes Mittel, auf erste und zweite Leitsystemdaten zuzugreifen. Ein solcher Zugriff auf Leitsystemdaten wird für die Konfiguration des ersten Leitsystems meistens lesend und für die Konfiguration des zweiten Leitsystems meistens schreibend erfolgen.
4. Ein geeigneter Computer, der auch der unter 1. genannte sein kann oder an diesen angeschlossen ist, der einen geeigneten Ansc luss an die Datenbank mit
graphischen Layouts hat, sowie verwendet wird, die Repräsentationsinformation für die Graphen zu generieren, die der Benutzer während oder nach der Übersetzung sehen möchte.
Die in der vorstehenden Beschreibung, in den Zeichnungen sowie in den Ansprüchen offenbarten Merkmale der Erfindung können sowohl einzeln als auch in beliebiger Kombination für die Verwirklichung der Erfindung wesentlich sein.
Bezugszeichenliste
erstes Leitsystem a SFC-Programm im ersten Leitsystem b textbasiertes Programm im ersten Leitsystem zweites Leitsystem a textbasiertes Programm im zweiten Leitsystem b SFC-Programm im zweiten Leitsystem Inaktiver TCL-Zustand Aktiver TCL-Zustand TCL-Pausenzustand Grundzustand im erweiterten Zustandsmodell Haltzustand im erweiterten Zustandsmodell Aktiver Zustand im erweiterten Zustandsmodell Auszustand im erweiterten Zustandsmodell 0 SFC-BaseState-Zustand 1 Bedingung T_off 2 SFC-Down-Zustand 3 Bedingung T_start 4 SFC-Active-Zustand 5 Bedingung T_on 6 Bedingung Ta_Stopp 7 Bedingung T ialt 8 SFC-Halt-Zustand 9 Bedingung Th_Stopp 0 Bedingung T_continue 1 In SFC übersetztes Quellprogramm 2 Grundlegender Zustand 3 Programml 4 Programm2 5 Programm3 6 erste Programmbedingung 7 dritte Programmbedingung 8 fünfte Programmbedingung
zweite Programmbedingung vierte Programmbedingung