-
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
Leitsystem 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
... else", "case",...).
-
Die zur Beschreibung der Softwarekonfiguration
eines Leitsystems verwendete Information ist durch ein geeignetes
Format gekennzeichnet, welches 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 wiederzuverwenden,
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 Wiederverwendung 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-/Softwarekonfiguration,
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 SoftwarekönfiguratiOn
nicht explizit dargestellt, sondern ist ein inhärentes Merkmal 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 Vorgehensweise 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 Aufgabe 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, wobei insbesondere eine
einfache Möglichkeit
der Überwachung
des Transformationsprozesses gegeben sein soll.
-
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 die erste Information
in eine neutrale Metabeschreibung übersetzt wird, die die Semantik
und das Echtzeitverhalten der ersten Information abbildet. 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 vernachlässigbares
Maß reduziert,
wobei die Transformation der ersten Information von verschiedenen
Leitsystemen unabhängig
von ihrem speziellen Aufbau, ihrer speziellen Konfiguration, ihrem
speziellen Verhalten erlaubt wird.
-
Eine bevorzugte Weiterbildung des
erfindungsgemäßen Verfahrens
sieht vor, dass die neutrale Metabeschreibung aus einer getrennten
Beschreibung der Syntax, der Semantik, und des Echtzeitverhaltens
des zu übersetzenden
Programms besteht.
-
Bei dem erfindungsgemäßen Verfahren
ist vorzugsweise weiterhin vorgesehen, dass die neutrale Metabeschreibung
eine nicht textbasierte Baumstruktur aufweist.
-
Im Zusammenhang mit dem erfindungsgemäßen Verfahren
wird weiterhin bevorzugt, dass die neutrale Metabeschreibung eine
gemeinsame und sprachenunabhängige
Beschreibung für
alle Programmiersprachen ist, die in dem ersten Leitsystem benutzt
werden. Auf diese Weise wird die Transformation der sich auf die
Hardware-/Software-Konfiguration
eines Leitsystems beziehende Information in einer konsistenten und vollständigen Weise
erlaubt, wobei gleichzeitig der Verlust von versteckten logischen
Verbindungen, die verschiedene Elemente des Hardware-/Software-Aufbaus
des Leitsystems verbinden, wie z.B. eine Ausführungsreihenfolge der Programme
und eine Priorisierung von Funktionen und/oder Teilen von Programmen,
auf einen vernachlässigbaren
Grund reduziert wird, da diese bei der Umsetzung in die dritte Information
durch deren Unabhängigkeit
automatisch aufgedeckt werden.
-
Das erfindungsgemäße Verfahren weist vorzugsweise
die folgenden Schritte auf:
- S1) Importieren
der ersten Information in eine computerisierte Umgebung,
- S2) Konvertieren der ersten Information in eine dritte Information
in einem neutralen Format zur Beschreibung der Programme eines Leitsystems,
- S3) Speichern der dritten Information in ein erstes Speichermittel,
welches in der computerisierten Umgebung enthalten ist; und
- S4) Auslesen der dritten Information aus dem ersten Speichermittel,
- S5) Konvertieren der verarbeiteten dritten Information in die
zweite Information, und
- S6) Exportieren der zweiten Information aus der computerisierten
Umgebung.
-
Hierdurch ist durch die Erfindung
ein Verfahren angegeben, welches mit vergleichsweise geringem Aufwand
in eine computerisierte Umgebung eingebunden werden kann, um das
Erhalten einer wenigstens teilweise automatischen Ausführung des
Verfahrens zu erlauben. Insbesondere erlaubt das Speichern der dritten Information
in das erste Speichermittel deren einfache Überprüfung, da dort das Echtzeitverhalten
unabhängig von
jeglichem Leitsystem dargestellt ist. Ein computerisiertes Werkzeug
nach dieser Erfindung führt
also eine indirekte Transformation der sich auf das Programm und
die betreffende Hardware-/Softwarekonfiguration des alten Leitsystems
beziehende Information durch.
-
Die Erfindung baut auf dem gattungsgemäßen Stand
der Technik dadurch auf, dass ein System ein Verfahren nach der
Erfindung implementiert.
-
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.
-
Die Übersetzung an sich basiert
vorteilhafter Weise auf einem Pipeline-Konzept, wie es z.B. in 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 beschrieben ist, welche hiermit durch Bezugnahme
in diese Anmeldung aufgenommen sind, wodurch die dort beschriebenen
Merkmale mit den hier beschriebenen in beliebiger Weise kombinierbar
sind.
-
Nach dem Verfahren nach dieser Erfindung
wird also 1. die sich auf den Programmcode des alten Leitsystems
beziehende Information in eine Information gewandelt, die ein "neutrales" Format aufweist,
und die 2. die Verhaltensinformation bezüglich der Hardware-/Software-Konfiguration
des alten Leitsystems in die neutrale Beschreibung aufgenommen.
Alle die Elemente des alten Programms sind in der Praxis während des Transformationsprozesses
in einem "neutralen" Format dargestellt,
welches vorzugsweise durch eine geeignete Syntax und eine geeignete
Semantik gekennzeichnet ist.
-
Es ist festzustellen, dass das neutrale
Format das vollständige
Programm und sein Verhalten beinhaltet. Auf diese Weise kann es
konvertiert und bearbeitet werden, wobei die Möglichkeiten der Änderung
des Programmverhaltens während
des Transformationsprozesses minimiert sind.
-
Auf diese Weise bezieht sich der
Transformationsprozess auf die gesamte sich auf das alte Programm beziehende
Information. Demzufolge ist die Konsistenz und Zuverlässigkeit
der Transformation notwendigerweise garantiert und das Bedürfnis eines
menschlichen Einschreitens ist effektiv minimiert. Tatsächlich ist
die manuelle Arbeit des Benutzers jetzt auf die Interaktion mit
der computerisierten Umgebung beschränkt, über die das Verfahren nach
dieser Erfindung eingebunden werden kann.
-
Diese Tatsache impliziert eine deutliche
Reduzierung der Aktualisierungskosten des Leitsystems.
-
Die Erfindung wird nun unter Bezugnahme
auf die beigefügten
Zeichnungen anhand einer beispielhaften bevorzugten Ausführungsform
beispielhaft erläutert,
die einen möglichen
Aufbau einer erfindungsgemäßen Metabeschreibung
beschreibt.
-
Es zeigen:
-
1 Phasen
der Transformation einer textbasierten Programmiersprache von einem
ersten Leitsystem in ein zweites Leitsystem,
-
2 ein
Blockdiagramm, das schematisch die Anpassung eines auf einem Leitsystem
A laufenden Programms in ein auf dem Leitsystem B laufendes Programm
zeigt,
-
3 ein
Beispiel für
das objektorientierte neutrale Metaformat nach der Erfindung,
-
4 den
funktionalen Aufbau der textuellen Programmiersprache TCL, beispielsweise
für das
Leitsystem „MOD",
-
5 Ausdrücke in TCL,
-
6 ein
Objektmodell der neutralen Schicht nach der Erfindung,
-
7 ein
Beispiel für
die Zuweisung a: = 2b + 3,
-
8 ein
Beispiel für
eine Definition,
-
9 Beispiele
für Darstellungen
von Funktionsaufrufen,
-
10 ein
Beispiel für
den Ausdruck sin(x)·(a:=
3) + b < 3,
-
11 ein
Beispiel einer for-Schleife,
-
12 ein
Beispiel einer if-Bedingung,
-
13 ein
Beispiel für
eine Aussage,
-
14 das
Eigenschaftskonzept nach der Erfindung,
-
15 das
unterschiedliche Verhalten einer while-Schleife abhängig von
ihrer Implementation in unterschiedlichen Zielsprachen.
-
1 zeigt
den zuvor beschriebenen Ablauf des Verfahrens nach der Erfindung
mit den Phasen S1 bis S6, die in ähnlicher Form auch in der Europäischen Patentanmeldung
EP-A-00 201 550.1 mit
der Veröffentlichungsnummer
EP 1 150 206 gezeigt und
beschrieben sind.
-
In einem ersten Schritt S1 wird die
erste Information in eine computerisierte Umgebung 4 importiert. Die
erste Information beschreibt zumindest die erste Softwarekonfiguration
sowie das Ausführungsverhalten des
ersten verteilten Leitsystems 1. Das Ausführungsverhalten
kann z.B. aus der ersten Softwarekonfiguration unter Beobachtung
des ersten Leitsystems abgeleitet werden. In einem nachfolgenden
zweiten Schritt S2 wird die erste Information in eine dritte Information
konvertiert, die ein neutrales Format zur Beschreibung der z.B. textbasierten
Programme sowie des Ausführungsverhaltens
eines Leitsystems aufweist. Die dritte Information wird in einem
dritten Schritt S3 in einem ersten Speicher 5 gespeichert,
woraus sie in einem vierten Schritt S4 ausgelesen wird, um in einem
fünften
Schritt S5 in die zweite Information konvertiert zu werden, bevor
die zweite Information in einem sechsten Schritt S6 aus der computerisierten
Umgebung exportiert wird. Die exportierte zweite Information beschreibt
hierbei die Softwarekonfiguration des zweiten Leitsystems 2.
-
Zwischen dem dritten Schritt S3 und
dem vierten Schritt S4 kann die sich in dem neutralen Format befindliche
Information einfach überprüft und/oder
verändert
werden, da sie außerhalb
jeglicher Echtzeitumgebung und unabhängig von jeglichem Leitsystem
zugänglich
ist.
-
Die 2 stellt
ein Blockdiagramm dar, welches schematisch die Grundelemente nach
der Erfindung sowie deren Zusammenspiel illustriert. Das erste Leitsystem 1 weist
wenigstens ein erstes Programm 1a auf, wovon der erste
Programmcode in wenigstens einem sich innerhalb oder außerhalb
des ersten Leitsystems 1 befindlichem zweiten Speicher 3 abgelegt
ist. Sowohl dieser erste Programmcode als auch dessen Ausführungsverhalten
in dem ersten Leitsystem 1 (dargestellt durch einen Pfeil
von dem ersten Leitsystem 1 zu dem Programmcode) wird in
das neutrale Format gewandelt bzw. transformiert und in dem ersten
Speicher 5 abgelegt. Danach wird der im neutralen Format
abgelegte Programmcode und dessen im neutralen Format abgelegtes
Ausführungsverhalten
in den zweiten Programmcode für
wenigstens ein zweites Programm 2a gewandelt bzw. transformiert,
wodurch das zweite Leitsystem 2 gesteuert wird, der zweiten
Programmcode wird in wenigstens einem sich innerhalb oder außerhalb
des zweiten Leitsystems 2 befindlichem dritten Speicher 6 abgelegt.
-
Erfindungsgemäß wird also ein erstes Programm 1a,
das auf einem ersten Leitsystem 1 läuft und in einer z.B. textbasierten
Programmiersprache oder einer Kombination von verschiedenen Programmiersprachen
codiert ist, unter Beibehaltung des Echtzeitverhaltens des ersten
Programms 1a, welches durch die Hardware-/Softwarekonfiguration
des ersten Leitsystems 1 bestimmt wird, in eine neutrale
Beschreibung, d.h. eine neutrale Metabeschreibung, gewandelt, bevor
es von dieser wiederum unter Beibehaltung des Echtzeitverhaltens
in ein zweites Programm 2a für ein zweites Leitsystem 2 gewandelt
wird.
-
Die neutrale
Metabeschreibung von textbasierten Sprachen
-
Die neutrale Metabeschreibung ist
keine weitere allgemeine textbasierte Beschreibung einer textbasierten
Sprache, sondern ist als sprachenunabhängiges allgemeines hierarchisches
Objektmodell aufgebaut. In 3 ist
beispielhaft die Transformation eines textbasierten Quellcodes 7 über die
als objektbasierte in Baumstruktur gehaltene neutrale Beschreibung 8 in
einen textbasierten Zielcode 9 gezeigt. Das erfindungsgemäße allgemeine
hierarchische Objektmodell repräsentiert
den funktionalen Aufbau des Laufzeitverhaltens von textbasierten
Sprachen. Es definiert nur den funktionalen Aufbau der textbasierten
Sprachen, nicht die Implementation selbst oder Dinge wie Datenbankzugriff,
Nachrichtenfenster usw. Das allgemeine hierarchische Objektmodell
für die
Darstellungen des funktionalen Aufbaus von textbasierten Sprachen
wird im Folgenden beschrieben. Das neutrale Modell wird auf die
für die
Repräsentation
einer textbasierten Sprache essentiellen Objekte reduziert, enthält aber
alle dem Verhalten des Programms entsprechenden Informationen und
dient als Ausgangsbasis für
eine weitere Transformation in ein auf dem zweiten Leitsystem laufendes
zweites Programm 2a, welches das selbe Laufzeitverhalten
wie das auf dem ersten Leitsystem laufende erste Programm 1a aufweist.
-
Prozedurale Programmiersprachen,
die auf Leitsystem-Einheiten von Leitsystemen laufen und in einer textbasierten
Sprachform geschrieben sind, bestehen aus einer Liste von Befehlen,
die von dem Betriebssystem des Leitsystems ausgeführt werden.
Beispiele für
solche Befehle sind:
- – Befehle zum Erhalten von
Information, z.B. aus einer bestimmten Informationsquelle
- – Befehle
zum Speichern/Schreiben von Information,
- – Funktionen,
wie z.B. arithmetische Funktionen,
- – bedingte
Schleifen ("while", "repeat until", ...),
- – unbedingte
Schleifen ("for
... times do", ...),
- – bedingte
Verzweigungen ("if
... else", "case", ...).
-
Um die neutrale Beschreibung zu erhalten,
müssen
alle Befehle der textbasierten Sprache klassifiziert werden. Typische
Befehlsklassen sind:
- – Zuweisungen (z.B. a: = 2b
+ 3),
- – Definitionen
(z.B. "#define TRUE
= 1"),
- – Funktionsaufrufe
(z.B. "Print LPT1", "hello world"),
- – Ausdrücke (z.B.
sin(x)·(a:
= 3) + b < 3),
- – Schleifen
(z.B. for I: = 1 to 10 step 1 do ...),
- – Bedingungen
(z.B. "if ... then", "if ... then ... else"),
- – Aussagen.
-
Im Folgenden wird die neutrale Metabeschreibung
eines Programms, welches in einer oder mehreren Programmiersprachen
geschrieben ist, beispielhaft mittels der textbasierten Sprache
TCL (Taylor Control Language) erläutert. Die Metabeschreibung
ist jedoch nicht auf die Darstellung mit TCL beschränkt, sondern
nach der Erfindung ein allgemeines und sprachenunabhängiges neutrales
Format. TCL ist eine strukturierte Programmiersprache, die dem ersten
Anschein nach sehr ähnlich
zu PASCAL ist. Zusätzlich
weist TCL einmalige Programmierstrukturen auf, die insbesondere
für die
Prozesssteuerung und Advant OCS (Open Control System)-Anwendungen
erstellt sind.
-
In TCL müssen alle ausführbaren
Aussagen mit Ausnahme von Aussagen, die innerhalb einer Unterroutine
auftreten, mittels einer STEP/ENDSTEP-Struktur begrenzt werden.
-
Durch die STEP/ENDSTEP-Struktur werden
TCL-Programme in identifizierbare Module unterteilt. Jeder Schritt
in einem TCL-Programm ist mit einem einmaligen benutzerdefinierten
Namen versehen. Die Schritte sind mit den Schritten eines SFC-Programms vergleichbar.
-
TCL bietet eine Hierarchie von Programmtypen,
die Ausführungen,
Prozeduren und Zeitabläufe
enthalten. Zeitabläufe
sind die oberste Schicht, welcher Prozeduren und Ausführungen
nachgeordnet sind.
-
Programmaufbau
-
Der funktionale Aufbau von TCL, wie
er in den 4 und 5 gezeigt ist, ist ähnlich zu
der Struktur der wohlbekannten Sprache "PASCAL", z.B. beschrieben in: Thomas L. Naps „Introduction
to Pascal", West
Wadsworth, ISBN: 0314932070, Januar 1986, und ist – wie diese – in der
Englischen Sprache gehalten, weswegen in den im folgenden beschriebenen
Figuren englische Fachbezeichnungen enthalten sind.
-
TCL bietet eine Hierarchie von Programmtypen
(Ausführungen,
Prozeduren und Zeitabläufen).
Ein TCL-Programm kann nur einem dieser Typen entsprechen, auch wenn
keine hierarchische Steuerung/Regelung nötig ist. Zeitabläufe sind
in der obersten Schicht angeordnet, der Prozeduren und Ausführungen
nachgeordnet sind.
-
4 zeigt
die Hierarchie von TCL 10. In der obersten Ebene existieren
ein Kopf „Head" 11 und
ein Körper „Body" 12. Dem
Kopf 10 sind ein Programmtyp „Program Type" 13, eine
Definition über
aufzunehmende Elemente „Include" 14 und
eine Variablendefinition „Var.
Def." 15 untergeordnet.
Dem Körper 12 ist
ein Schritt „Step" 16 untergeordnet,
dem eine Abfolge von Aussagen „StatementSequence" 17 untergeordnet
ist. Der Aussagenabfolge 17 sind Schleifen „Loop" 18, Bedingungen „Condition" 19, eine
Aussage „Statement" 20 und
ein Sprung „goto" 21 untergeordnet.
Die Schleifen 18 enthalten eine for-Schleife „for...downto(to)..do" 22 mit
einem Ausdruck „Expression" 25, der
eine Aussagenabfolge 17 nachfolgt, eine while-Schleife „while...do" 23 mit
einem Ausdruck 25, der eine Aussagenabfolge 17 nachfolgt,
und eine repeat-Schleife „repeat...until" 24 mit
einem Ausdruck 25, der eine Aussagenabfolge 17 nachfolgt.
Die Bedingungen 19 enthalten eine if-Bedingung „if then" 26 mit
einem Ausdruck 25, der eine Aussagenabfolge 17 und
ein Alternativzweig „else" 28 nachfolgt,
welcher mit einem Ausdruck 25 versehen ist und dem eine
Aussagenabfolge 17 nachfolgt, und eine case-Bedingung „case of 27 mit
einem Ausdruck 25, der eine Konstante „constant" 29 mit nachfolgender Aussagenabfolge 17 und
ein Alternativzweig „otherwise" 30 mit
nachfolgender Aussagenabfolge 17 untergeordnet sind.
-
Die 5 zeigt
den hierarchischen Aufbau des Ausdrucks „Expression" 25, dem
direkt Beziehungen „Relation" 31 und
ein einfacher Ausdruck „SimpleExpression" 32 untergeordnet
sind. Die Beziehungen 31 weisen einen kleiner-als-Operator „Less Than" 33, einen
größer-als-Operator „Greater
Than" 34,
einen kleiner-gleich-Operator „Less
Equal" 35,
einen größer-gleich-Operator „Greater
Equal" 36,
einen gleich-Operator „Equal" 37 und
einen ungleich-Operator „Unequal" 38 auf.
Der einfache Ausdruck 32 umfasst Additions-Operatoren „Add-Operator" 39 und
einen Term „Term" 40. Die
Additions-Operatoren 39 umfassen einen Plus-Operator „Plus" 41, einen
Minus-Operator „Minus" 42 und
einen Oder-Operator „Or" 43. Dem
Term 40 untergeordnet sind Multiplikations-Operatoren „Mul-Operator" 44 und
ein Faktor „Factor" 45. Die
Multiplikations-Operatoren 44 umfassen einen Multiplikations-Operator „Multiplication" 46, einen
Potenz-Operator „Power" 47, einen Divisions-Operator „Division" 48, einen
Modulo-Operator „Mod" 49 und
einen Und-Operator „And" 50. Der
Faktor 45 umfasst Zahlen „Number" 51 und eine Funktion „Function" 52. Die
Zahlen 51 bestehen aus Ganzzahlen „Integer" 53 und reellen Zahlen „Real" 54. Die
Funktion 52 besteht aus Argumenten „Arguments" 55, denen Ausdrücke „Expressions" 25 untergeordnet
sind.
-
Die angegebenen Hierarchien sind
beispielhaft zur Verdeutlichung der Strukturen gewählt und
nicht abschließend
aufgeführt.
-
"Receipts" sind innerhalb von
TCL-Programmen ein Mittel, um Daten zu speichern. Z.B. kann ein TCL-Receipt
verschiedene Einstellwerte, hohe/niedrige Grenzen und andere für ein oder
mehrere TCL-Programme benötigte
Daten halten, die den Zyklus einer speziellen Produktherstellung
steuern/regeln.
-
Die nachfolgende 6 zeigt eine Zusammenstellung von Klassen,
die zur Beschreibung der TCL-Sprache dienen. Alle Objektnamen, sind
mit textbasierten Sprachen assoziiert, weswegen sie die vorangestellten
Buchstaben "Txt" für Objekt
einer "textbasierten
Sprache" zeigen.
-
Einem Parse-Objekt „TxtParseObject" 56 sind
direkt ein Programm-Objekt „TxtProgram" 57, ein
Kopfbereich-Objekt „TxtHeader" 58, ein
Schlussbereich-Objekt „TxtFooter" 59, ein
Aufnahme-Objekt „TxtInclude" 60, ein
Wert-Objekt „TxtValue" 61, ein
Kommentar- Objekt „TxtComment 62,
ein Bezeichnungs-Objekt „TxtLabel" 63, ein
Definitions-Objekt „TxtDefinition" 64 und
ein Deklarations-Objekt „TxtDeclaration" 65, sowie
ein Ausdruck-Objekt „TxtExpression" 66, ein
Designator-Objekt „TxtDesignator" 67, ein
Operations-Objekt „TxtOperation" 68, ein
Schleifen-Objekt „TxtLoop" 69, ein
Bedingungs-Objekt „TxtCondition" 70, ein
Sprung-Objekt „TxtGoto" 71 und
ein Aussage-Objekt „TxtStatement 72 untergeordnet.
Dem Ausdruck-Objekt 66 ist ein Objekt für einen einfacher Ausdruck „TxtSimpleExpression" 73 nachgeordnet,
dem ein Term-Objekt „TxtTerm" 74 untergeordnet
ist, welchem ein Faktor-Objekt „TxtFactor" 75 folgt. Dem Faktor-Objekt 75 ist
ein Variablen-Objekt „TxtVariable" 76, ein
Funktionsaufruf-Objekt „TxtFunctionCall" 77 und
ein Zuweisungs-Objekt „TxtAssignment 78 nachgeordnet.
-
Das Variablen-Objekt 75 umfasst
ein Boolsches-Objekt „TxtBool" 79, ein
Ganzzahl-Objekt „TxtInterger" 80, ein
Reelzahl-Objekt „TxtReal" 81, ein
Textfeld-Objekt „TxtString" 82 und
ein Einhefts-Objekt „TxtUnit 83.
Dem Designator-Objekt 67 ist ein Identifikation-Objekt „TxtIdentifier" 84 und
ein Referenz-Objekt „TxtReference" 85 nachgeordnet.
Dem Operations-Objekt 68 ist ein Additions-Objekt „TxtAddition" 86, ein
Multiplikations-Objekt „TxtMultiplication" 87 und
ein Beziehung-objekt „TxtRelation" 88 nachgeordnet.
Dem Schleifen-Objekt 69 ist ein For-Objekt „TxtFor" 89, ein
While-Objekt „TxtWhile" 90 und
ein Repeat-Until-Objekt „TxtRepeatUntil" 91 nachgeordnet.
Dem Bedingungs-Objekt 70 ist ein If-Objekt „TxtIf" 92, ein
Schalt-Objekt „TxtSwitch" 93 und
ein Case-Objekt „TxtCase" 94 nachgeordnet.
Dem Aussage-Objekt 72 folgt ein Container-Objekt „TxtContainer" 95.
-
Die folgenden darstellenden Beispiele
erläutern
die neutrale Darstellung von Elementen textbasierter Programmiersprachen,
wobei die beigefügten
Figuren unterschiedliche Ansichten der beteiligten Verzweigungen
des neutralen Objektbaums, nämlich
auf der linken Seite den Objektaufbau der Verzweigung und auf der rechten
Seite den Inhalt der beteiligten Objekte zeigen. Die Objekte sind
zum einfacheren Verständnis
teilweise in ihrer oben und in den Figuren angegebenen englischen
Bezeichnung belassen.
-
Beispiel für eine Zuweisung
-
Die Zuweisung „a:= 2b + 3" kann durch das TxtAssignment-Objekt 78 dargestellt
werden, das einen Designator, d.h. eine TxtVariable 76,
und einen Ausdruck, d.h. TxtExpression 66 verwendet, wie
es in der 7 links gezeigt
ist. Der Inhalt der Objekte ist hier für TxtAssignment 78 eine
Bezeichnung „assignment" 96, für TxtVariable 76 die
Bezeichnung „a" 97, und
für TxtExpression 66 die
Formel „2b
+ 3" 98.
-
Beispiel für eine Definition
-
Die Definition „#define TRUE = 1" kann durch ein TxtDefine-Objekt 64 dargestellt
werden, das einen Designator, d.h. eine TxtVariable 76,
und einen Ausdruck, d.h. TxtExpression 66 verwendet, wie
es in der 8 links gezeigt
ist. Der Inhalt der Objekte ist hier für TxtDefinition 64 eine
Bezeichnung „definition" 99, für TxtVariable 76 die
Bezeichnung „TRUE", und für TxtExpression 66 die
Konstante „1".
-
Beispiel für einen
Funktionsaufruf
-
Einen Funktionsaufruf kann durch
ein TxtFunctionCall-Objekt 77 dargestellt werden, das einen
TxtDesignator 67, d.h. die Benennung der Funktion, und
der Argumentenliste bestehend aus TxtExpression-Objekten 66 verwendet,
wie es in der 9 links
gezeigt ist. Das gezeigte Objekt ist für die Verwaltung von Funktionsaufrufen
zuständig.
-
Demzufolge wird mit TxtFunctionCall 77 ein „function
call" 102,
mit TxtDesignator 67 ein „designator" 103b, und
durch die Argumentenliste bestehend aus TxtExpression-Objekten 66 eine
Liste von Ausdrücken „expression
1" 104b ... „expression
n" 105b implementiert,
wie es in der 9 in der
Mitte gezeigt ist. Der Inhalt der Objekte ist hier für TxtFunctionCall 77 die
Bezeichnung function call 102, für TxtDesignator 67 die
Bezeichnung „print" 103a, für ein erstes
TxtExpression-Objekt 66 die Funktion „LPT1" 104a, und für ein zweites
TxtExpression-Objekt 66 der Term „Hallo World" 105a.
-
Beispiel für einen
Ausdruck
-
Dieses TxtExpression-Objekt 66 stellt
eine Beziehung zwischen zwei einfachen Ausdrücken dar, die durch ein erstes
und ein zweites jeweils untergeordnetes TxtSimpleExpression-Objekt 73 dargestellt
werden, die durch ein ebenfalls dem TxtExpression-Objekt 66 TxtRelation-Objekt 88 verknüpft sind.
Durch das TxtRelation-Objekt 88 ist
eine Beziehung 31 von der Art „<", „>", „≤", „≥", „=" oder „≠" dargestellt, wie
es in der 5 angegeben
ist. In der 10 sind
der Aufbau eines Ausdrucks und ein Beispiel für den Ausdruck „sin(x)∙(a: = 3)
+ b < 3" gezeigt. Demzufolge
ist in dem links gezeigten Aufbau dem ersten dem TxtExpression-Objekt 66 untergeordnetem
TxtSimpleExpression-Objekt 73 ein erstes TxtTerm-Objekt 74 untergeordnet,
dem ein erstes TxtFactor-Objekt 75, ein TxtMultiplication-Objekt 87,
und ein zweites TxtFactor-Objekt 75 nachgeordnet
sind. Dem ersten TxtFactor-Objekt 75 kann ein erstes TxtVariable-Objekt 76,
ein ersten TxtFunction-Objekt 77, ein erstes TxtAssignment-Objekt 78,
und ein erstes TxtExpression-Objekt 66 oder eine Kombination
davon nachgeordnet sein. Dem zweiten TxtFactor-Objekt 75 kann
ein zweites TxtVariable-Objekt 76,
ein zweiten TxtFunction-Objekt 77, ein zweites TxtAssignment-Objekt 78,
und ein zweites TxtExpression-Objekt 66 oder eine Kombination
davon nachgeordnet sein, dies ist jedoch nicht gezeigt. Dem TxtSimpleExpression-Objekt 73 ist
weiter ein TxtAddition-Objekt 86 und ein zweites TxtTerm-Objekt 74 untergeordnet,
dem ein nicht gezeigtes drittes TxtFactor-Objekt 75, das
eine Konstante definiert nachgeordnet sind. Dem zweiten TxtSimpleExpression-Objekt 73 ist
ein nicht gezeigtes viertes TxtTerm-Objekt 74 untergeordnet, dem
ein nicht gezeigtes fünftes
TxtFactor-Objekt 75, das eine Konstante definiert nachgeordnet
sind.
-
Die rechts dargestellte Implementation
der Objekte mit deren Inhalt ist hier für TxtExpression 66 die Implementation „expression" 25, für das erste
TxtSimpleExpression-Objekt 73 die Implementation „simple
expression" 32,
für das
erste TxtTerm-Objekt 74 die Implementation „term" 40, für das erste
TxtFactor-Objekt 75 die Implementation „factor" 45, für das TxtMultiplication-Objekt 87 ein
Multiplikations-Operator 46,
für das
zweite TxtFactor-Objekt 75 die Implementation „factor" 45, für das dem
ersten TxtFactor-Objekt 75 nachgeordnete erste TxtFunction-Objekt 77 eine
Funktion „sin(x)" 106, für das dem
zweiten TxtFactor-Objekt 75 nachgeordnete zweite TxtAssignment-Objekt 78 eine
Zuweisung „a
:= 3" 107,
für das
TxtAddition-Objekt 86 ein Additions-Operator 41,
für das
zweite TxtTerm-Objekt 74 die Implementation „factor" 45 mit
der Konstanten „b" 108, für das TxtRelation-Objekt 88 ein
kleiner-als-Operator 33, für das zweite TxtSimpleExpression-Objekt 73 die Implementation „simple
expression" 32,
für das
nicht gezeigte vierte TxtTerm-Objekt 74 die Implementation „term" 40, und
für das
nicht gezeigte fünfte
TxtFactor-Objekt 75 die Implementation „factor" 45 mit der Konstanten „ 3" 109.
-
Beispiel für eine Schleife
-
Dieses Objekt deckt alle Typen von
for-Schleifen ab. Eine for-Schleife wird gekennzeichnet durch
- – einen
initialen Zähler
(Zuweisung)
- – einen
Schleifenzähler
(Ausdruck)
- – einen
Endzähler
(Zuweisung)
- – eine
Anweisung zum Inkrementieren oder Dekrementieren (Teil des obigen
Ausdrucks)
- - eine Aussage oder eine Folge von Aussagen.
-
Die in der
11 gezeigte Schleife zeigt eine neutrale
Darstellung von z.B. den folgenden Quellcodes:
-
Die Schleife kann durch ein TxtFor-Objekt 89 dargestellt
werden, das ein erstes TxtAssignment-Objekt 78, ein TxtExpression-Objekt 66,
ein zweites TxtAssignment-Objekt 78,
und ein TxtStatement-Objekt 72 verwendet, wie es in der 11 links gezeigt ist. Mit
dem TxtFor-Objekt 89 wird die Bezeichnung „for" 22, mit
dem ersten TxtAssignment-Objekt 78, eine „initialization" 110, mit
dem TxtExpression-Objekt 66 eine „condition" 19, mit dem zweiten TxtAssignment-Objekt 78 eine „incrementation" 111, und
mit dem TxtStatement-Objekt 72 „statement/s" 112 implementiert,
wie es in der 11 in
der Mitte gezeigt ist. Der in der 11 rechts
gezeigte Inhalt der Objekte bleibt hier für das TxtFor-Objekt 89 die
Bezeichnung „for" 22, und
ist für
die „initialization" 110 ein „assignment" 96 gemäß der obigen
Beschreibung mit einem TxtVariable-Objekt 76 mit der Bezeichnung „i" 113 und
einem TxtExpression-Objekt 66 mit der Konstanten „1" 114, für die „condition" 19 eine „expression" 25 mit
einer Konstanten „i" 115, einem
kleiner-gleich-Operator 35 und einer Konstanten „10" 116, für die „incrementation" 111 ein „assignment" 96 gemäß der obigen
Beschreibung mit einem TxtVariable-Objekt 76 mit der Bezeichnung „i" 117 und
einem TxtExpression-Objekt 66 mit
einer „expression" 25 mit
einer Konstanten „i" 118, einem
additions-Operator 41 und
einer Konstanten „1" 119, und
für die „statement/s" 112 ein „function
call" 102 gemäß der obigen
Beschreibung mit dem TxtDesignator 67 mit der Bezeichnung „format" 103c und
dem TxtExpression-Objekt 66 mit der Konstanten „1" 104c.
-
Beispiel für eine Bedingung
-
Programmkonstrukte, wie „if ...
then", „if ...
then ... else", „if ...
then ... else if",
etc. werden von diesem Objekttyp abgedeckt. Eine if-Bedingung ist
gekennzeichnet durch
- - einen Ausdruck
- - eine Aussage oder Folge von Aussagen
- – einen
optionalen else-Zweig mit einer zugeordneten Aussage oder Sequenz
von Aussagen
- – "elseif"-Konstrukte müssen in
eingebundene "if
... then ... else"-Bedingungen
gewandelt werden.
-
Die in der
12 gezeigte if-Bedingung ist eine neutrale
Beschreibung von z.B. den folgenden Quellcodes:
-
Die if-Bedingung kann durch ein Txtlf-Objekt 92 dargestellt
werden, das ein TxtExpression-Objekt 66, ein erstes TxtStatement-Objekt 72,
und ein zweites TxtStatement-Objekt 72 verwendet, wie es
in der 12 links gezeigt
ist. Mit dem TxtIf-Objekt 92 wird
die Bezeichnung „if" 26, mit
dem TxtExpression-Objekt 66 eine „condition" 19, ersten TxtStatement-Objekt 72 ein „true branch" 120, und
mit dem zweiten TxtStatement-Objekt 72 ein „false
branch" 121 implementiert,
wie es in der 12 in
der Mitte gezeigt ist. Der in der 12 rechts gezeigte
Inhalt der Objekte bleibt hier für
das TxtIf-Objekt 92 die Bezeichnung „if" 26, und für die „condition" 19 eine „expression" 25 mit
einer Konstanten „i" 122, einem
gleich-Operator 37 und einem Term „true" 123, für den „true branch" 120 ein „assignment" 96 gemäß der obigen
Beschreibung mit einem TxtVariable-Objekt 76 mit der Bezeichnung „a" 124 und
einem TxtExpression-Objekt 66 mit der Konstanten „1" 125, und
für den „false branch" 121 ein „assignment" 96 gemäß der obigen
Beschreibung mit einem TxtVariable-Objekt 76 mit der Bezeichnung „a" 126 und
einem TxtExpression-Objekt 66 mit der Konstanten „2" 127.
-
Beispiel für eine Aussage
-
Dieses in der 13 gezeigte Aussage-Objekt 72 stelle
eine einfache Programmaussage dar, die ein Bezeichnungs-Objekt 63,
sowie ein Aufnahme-Objekt 60, ein Definitions-Objekt 64,
ein Deklarations-Objekt 65, ein Schleifen-Objekt 69,
ein Funktionsaufruf-Objekt 77, ein Zuweisungs-Objekt 78,
ein Entscheidungs-Objekt „TxtDecision" 128, und
ein Container-Objekt 95, etc. enthalten kann. Zusätzlich kann
zu jedem Aussage-Objekt 72 ein Kommentar-Objekt 62 assoziiert
sein.
-
Eigenschaftskonzept
zur Beschreibung des Verhaltens
-
Die neutrale Beschreibung nach dieser
Erfindung stellt nicht nur die Struktur und funktionale Beschreibung
des Quellprogramms dar, sondern zusätzlich die systemspezifischen
Merkmale oder Details, z.B. das Laufzeitverhalten einer Schleife,
oder eine Beschreibung der unterschiedlichen Komponenten einer Bedingung
(z.B. if-Aussage
oder else-Aussage). Dieses Eigenschaftskonzept erlaubt es, jedem
Objekt in dem neutralen Objektmodell individuelle Verhaltenseigenschaften
zuzufügen
oder diese zu ändern.
Diese Eigenschaften können
die notwendige Information außerhalb
oder um den Code beinhalten.
-
Eine Eigenschaft besteht z.B. aus
den folgenden vier Komponenten:
-
- – Eigenschaftstyp,
- – Eigenschaftsname,
- – Eigenschaftswert,
- – Eigenschaftswert
in Textform.
-
Eigenschaftstypen werden in dem Eigenschaftsobjekt
als statische Elemente definiert, um ein gemeinsames Verständnis der
Eigenschaften zu garantieren. Die 14 zeigt
das Eigenschaftskonzept für
das in der 11 beschriebene
TxtFor-Objekt 89, das ein erstes TxtAssignment-Objekt 78,
ein TxtExpression-Objekt 66, ein zweites TxtAssignment-Objekt 78,
und ein TxtStatement-Objekt 72 verwendet. Dem TxtFor-Objekt 89 selbst
ist sein Laufzeitverhalten „Runttime
behaviour" 129 als
Eigenschaft assoziiert, das erste TxtAssignment-Objekt 78 weist
die Eigenschaft Initialisierung „Initialization" auf, d.h. dessen
in der 11 gezeigte Implementation,
und das zweite TxtAssignment-Objekt 78 weist die Eigenschaft
Initialisierung „Iteration" auf, d.h. die in
der 11 gezeigte Implementation
von „incrementation", d.h. die Eigenschaften
der Zuweisungs-Objekte 78 spezifizieren die Zuweisung als
Initialisierung oder als Iteration.
-
Der Hauptvorteil dieses Konzeptes
ist eine strikte Trennung zwischen der funktionalen Strukturbeschreibung
des Quellprogrammcodes (Semantik des Programmcodes) und der Darstellung
des Laufzeitverhaltens des Quellcodes, welcher von der Umgebung
des Regelungs- oder Steuerungssystems des Quellsystems abhängt, in
der neutralen Schicht für
textbasierte Sprachen.
-
Beispiele der Eigenschaften,
hier sprachspezifische Eigenschaften
-
Die 15 zeigt
den Quellcode einer While-Schleife in einer beliebigen Quellsprache 130,
hier in Pascal, und dessen Übersetzung
oder Darstellung in zwei unterschiedlichen Zielsprachen um das mögliche Laufzeitverhalten
der originalen Schleifendefinition in dem Quellsystem zu beschreiben.
Die Beispiele für
die beliebigen Zielsprachen sind eine erste Zielsprache 131 Structured
Text (ST) und eine zweite Zielsprache 132 Sequence Function
Charts (SFC), wie sie in IEC611131 definiert sind. Dieses Beispiel
zeigt, dass jede Zielimplementation einer While-Schleife ein individuelles
Laufzeitverhalten aufweisen kann, welches sich von dem Laufzeitverhalten
des Quellsystems unterscheiden kann. Demzufolge ist es notwendig,
dass diese Laufzeitaspekte während
der Übersetzung
berücksichtigt
werden.
-
Wie in 15 gezeigt,
ist die Schleife bei einer ST-Implementierung 131 nicht
unterbrechbar, d.h. die Schleifeniteration muss beendet werden,
bevor die Ausführung
des Codes durch das System gestoppt werden kann, da die Schleife
nur aus einer einzigen Anweisung besteht. Im Gegensatz dazu kann
die SFC-Implementation 132 nach jedem Iterationsschritt 133 von
dem System unterbrochen werden, da nach jedem Iterationsschritt
eine Bedingung abgefragt wird, nämlich
entweder eine erste Bedingung 134 für das Schleifenende oder eine
zweite Bedingung 135 für
das fortführen
der Schleife. Demzufolge ist es notwendig, die Information des Laufzeitverhaltens
des Quellsystems als Eigenschaft zu speichern, die dem die While-Schleife
repräsentierenden
Knoten zugewiesen wird, denn sonst kann nicht garantiert werden,
dass das Laufzeitverhalten des übersetzten
Codes im Zielsystem das gleiche ist, wie das Laufzeitverhalten des
Originalcodes im Quellsystem.
-
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.
-
- 1
- erstes
Leitsystem
- 1a
- erstes
Programm
- 2
- zweites
Leitsystem
- 2a
- zweites
Programm
- 3
- zweiter
Speicher
- 4
- computerisierte
Umgebung
- 5
- erster
Speicher
- 6
- dritter
Speicher
- 7
- Quellcode
- 8
- objektbasierte
in Baumstruktur gehaltene neutrale Beschreibung
- 9
- Zielcode
- 10
- TCL-Definition
- 11
- Kopf „Head"
- 12
- Körper „Body"
- 13
- Programmtyp „Program
Type"
- 14
- Definition über aufzunehmende
Elemente „Include"
- 15
- Variablendefinition „Var. Def."
- 16
- Schritt „Step"
- 17
- Abfolge
von Aussagen „StatementSequence"
- 18
- Schleifen „Loop"
- 19
- Bedingungen „Condition"
- 20
- Aussage „Statement"
- 21
- Sprung „goto"
- 22
- for-Schleife „for...downto(to)..do"
- 23
- while-Schleife „while...do"
- 24
- repeat-Schleife „repeat...until"
- 25
- Ausdruck „Expression"
- 26
- if-Bedingung „if then"
- 27
- case-Bedingung „case of"
- 28
- Alternativzweig „else"
- 29
- Konstante „constant"
- 30
- Alternativzweig „otherwise"
- 31
- Beziehungen „Relation"
- 32
- einfacher
Ausdruck „SimpleExpression"
- 33
- kleiner-als-Operator „Less Than"
- 34
- größer-als-Operator „Greater
Than"
- 35
- kleiner-gleich-Operator „Less Equal"
- 36
- größer-gleich-Operator „Greater
Equal"
- 37
- gleich-Operator „Equal"
- 38
- ungleich-Operator „Unequal"
- 39
- Additions-Operatoren „Add-Operator"
- 40
- Term „Term"
- 41
- Plus-Operator „Plus"
- 42
- Minus-Operator „Minus"
- 43
- Oder-Operator „Or"
- 44
- Multiplikations-Operatoren „Mul-Operator"
- 45
- Faktor „Factor"
- 46
- Multiplikations-Operator „Multiplication"
- 47
- Potenz-Operator „Power"
- 48
- Divisions-Operator „Division"
- 49
- Modulo-Operator „Mod"
- 50
- Und-Operator „And"
- 51
- Zahlen „Number"
- 52
- Funktion „Function"
- 53
- Ganzzahlen „Integer"
- 54
- reelle
Zahlen „Real"
- 55
- Argumente „Arguments"
- 56
- Parse-Objekt „TxtParseObject"
- 57
- Programm-Objekt „TxtProgram"
- 58
- Kopfbereich-Objekt „TxtHeader"
- 59
- Schlussbereich-Objekt „TxtFooter"
- 60
- Aufnahme-Objekt „TxtInclude"
- 61
- Wert-Objekt „TxtValue"
- 62
- Kommentar-Objekt „TxtComment"
- 63
- Bezeichnungs-Objekt „TxtLabel"
- 64
- Definitions-Objekt „TxtDefinition"
- 65
- Deklarations-Objekt „TxtDeclaration"
- 66
- Ausdruck-Objekt „TxtExpression"
- 67
- Designator-Objekt „TxtDesignator"
- 68
- Operations-Objekt „TxtOperation"
- 69
- Schleifen-Objekt „TxtLoop"
- 70
- Bedingungs-Objekt „TxtCondition"
- 71
- Sprung-Objekt „TxtGoto"
- 72
- Aussage-Objekt „TxtStatement"
- 73
- Objekt
für einen
einfacher Ausdruck „TxtSimpleExpression"
- 74
- Term-Objekt „TxtTerm"
- 75
- Faktor-Objekt „TxtFactor"
- 76
- Variablen-Objekt „TxtVariable"
- 77
- Funktionsaufruf-Objekt „TxtFunctionCall"
- 78
- Zuweisungs-Objekt „TxtAssignment"
- 79
- Boolsches-Objekt „TxtBool"
- 80
- Ganzzahl-Objekt „TxtInterger"
- 81
- Reelzahl-Objekt „TxtReal"
- 82
- Textfeld-Objekt „TxtString"
- 83
- Einhefts-Objekt „TxtUnit"
- 84
- Identifikation-Objekt „TxtIdentifier"
- 85
- Referenz-Objekt „TxtReference"
- 86
- Additions-Objekt „TxtAddition"
- 87
- Multiplikations-Objekt „TxtMultiplication"
- 88
- Beziehung-Objekt „TxtRelation"
- 89
- For-Objekt „TxtFor"
- 90
- While-Objekt „TxtWhile"
- 91
- Repeat-Until-Objekt „TxtRepeatUntil"
- 92
- If-Objekt „TxtIf
- 93
- Schalt-Objekt „TxtSwitch"
- 94
- Case-Objekt „TxtCase"
- 95
- Container-Objekt „TxtContainer" 95
- 96
- assignment
- 97
- a
- 98
- 2b+3
- 99
- definition
- 100
- TRUE
- 101
- 1
- 102
- function
call
- 103a
- print
- 103b
- designator
- 103c
- format
- 104a
- LPT1
- 104b
- expression
1
- 104c
- i
- 105a
- „Hallo
World"
- 105b
- expression
n
- 106
- sin(x)
- 107
- a:=
3
- 108
- b
- 109
- 3
- 110
- initialization
- 111
- incrementation
- 112
- statement/s
- 113
- i
- 114
- 1
- 115
- i
- 116
- 10
- 117
- i
- 118
- i
- 119
- 1
- 120
- true
branch
- 121
- false
branch
- 122
- i
- 123
- true
- 124
- a
- 125
- 1
- 126
- a
- 127
- 2
- 128
- Entscheidungs-Objekt „TxtDecision"
- 129
- Laufzeitverhalten „Runtime
behaviour"
- 130
- while-Schleife
in Quellsprache Pascal
- 131
- while-Schleife
in erster Zielsprache ST
- 132
- while-Schleife
in zweiter Zielsprache SFC
- 133
- Iterationsschritt
- 134
- erste
Bedingung
- 135
- zweite
Bedingung