DE10254530A1 - Verfahren und System zur wissensbasierten Transformation von textuellen Programmen, die sich auf die Softwarekonfiguration eines verteilten Leitsystems beziehen - Google Patents

Verfahren und System zur wissensbasierten Transformation von textuellen Programmen, die sich auf die Softwarekonfiguration eines verteilten Leitsystems beziehen Download PDF

Info

Publication number
DE10254530A1
DE10254530A1 DE2002154530 DE10254530A DE10254530A1 DE 10254530 A1 DE10254530 A1 DE 10254530A1 DE 2002154530 DE2002154530 DE 2002154530 DE 10254530 A DE10254530 A DE 10254530A DE 10254530 A1 DE10254530 A1 DE 10254530A1
Authority
DE
Germany
Prior art keywords
information
control system
description
software configuration
neutral
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE2002154530
Other languages
English (en)
Inventor
Peter Dr.-Ing. Bort
Luca Cavalli
Rainer Dr.-Ing. Drath
Alexander Dr.-Ing. Fay
Massimo Scarpellini
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ABB Research Ltd Switzerland
Original Assignee
ABB Research Ltd Switzerland
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ABB Research Ltd Switzerland filed Critical ABB Research Ltd Switzerland
Priority to DE2002154530 priority Critical patent/DE10254530A1/de
Publication of DE10254530A1 publication Critical patent/DE10254530A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44505Configuring for program initiating, e.g. using registry, configuration files

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Transformation einer ersten Information in einem ersten Format, die eine erste Softwarekonfiguration eines ersten verteilten Leitsystems (1) beschreibt, in eine zweite Information in einem zweiten Format, die eine zweite Softwarekonfiguration eines zweiten verteilten Leitsystems (2) beschreibt, wobei die erste Information in eine neutrale Metabeschreibung übersetzt wird, die die Semantik und das Echtzeitverhalten der ersten Information abbildet. DOLLAR A Weiterhin betrifft die Erfindung ein entsprechendes System.

Description

  • 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.
    Figure 00150001
  • 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:
    Figure 00210001
    Figure 00220001
  • 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:
    Figure 00230001
  • 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

Claims (6)

  1. Verfahren zur Transformation einer ersten Information in einem ersten Format, die eine erste Softwarekonfiguration eines ersten verteilten Leitsystems (1) beschreibt, in eine zweite Information in einem zweiten Format, die eine zweite Softwarekonfiguration eines zweiten verteilten Leitsystems (2) beschreibt, dadurch gekennzeichnet, dass die erste Information in eine neutrale Metabeschreibung übersetzt wird, die die Semantik und das Echtzeitverhalten der ersten Information abbildet.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die neutrale Metabeschreibung eine getrennte Beschreibung der Syntax, der Semantik, und des Echtzeitverhaltens des zu übersetzenden Programms beinhaltet.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die neutrale Metabeschreibung eine nicht textbasierte Baumstruktur aufweist.
  4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die neutrale Metabeschreibung eine gemeinsame und sprachenunabhängige Beschreibung für alle Programmiersprachen ist, die in dem ersten Leitsystem benutzt werden.
  5. Verfahren nach einem der vorhergehenden Ansprüche, gekennzeichnet durch die folgenden Schritte: S1) Importieren der ersten Information in eine computerisierte Umgebung, S2) Konvertieren der ersten Information 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.
  6. System zur Transformation einer ersten Information in einem ersten Format, die eine erste Softwarekonfiguration eines ersten verteilten Leitsystems (1) beschreibt, in eine zweite Information in einem zweiten Format, die eine zweite Softwarekonfiguration eines zweiten verteilten Leitsystems (2) beschreibt, dadurch gekennzeichnet, dass es ein Verfahren nach einem der vorhergehenden Ansprüche implementiert.
DE2002154530 2002-11-22 2002-11-22 Verfahren und System zur wissensbasierten Transformation von textuellen Programmen, die sich auf die Softwarekonfiguration eines verteilten Leitsystems beziehen Withdrawn DE10254530A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE2002154530 DE10254530A1 (de) 2002-11-22 2002-11-22 Verfahren und System zur wissensbasierten Transformation von textuellen Programmen, die sich auf die Softwarekonfiguration eines verteilten Leitsystems beziehen

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE2002154530 DE10254530A1 (de) 2002-11-22 2002-11-22 Verfahren und System zur wissensbasierten Transformation von textuellen Programmen, die sich auf die Softwarekonfiguration eines verteilten Leitsystems beziehen

Publications (1)

Publication Number Publication Date
DE10254530A1 true DE10254530A1 (de) 2004-06-03

Family

ID=32240285

Family Applications (1)

Application Number Title Priority Date Filing Date
DE2002154530 Withdrawn DE10254530A1 (de) 2002-11-22 2002-11-22 Verfahren und System zur wissensbasierten Transformation von textuellen Programmen, die sich auf die Softwarekonfiguration eines verteilten Leitsystems beziehen

Country Status (1)

Country Link
DE (1) DE10254530A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2778413A1 (de) * 2013-03-15 2014-09-17 Kaeser Kompressoren SE R&I-Schema Eingabe für ein Verfahren zum Steuern und/oder Überwachen einer Kompressoranlage
CN105159251A (zh) * 2015-08-14 2015-12-16 中国神华能源股份有限公司 一种实现max1000+plus系统与maxdna系统兼容的电厂dcs系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1150205A1 (de) * 2000-04-28 2001-10-31 ABB Research Ltd. Computerisiertes Werkzeug zur Konvertierung von Hardware/Software konfigurationsbetreffende Information in einem verteilten Steuersystem

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1150205A1 (de) * 2000-04-28 2001-10-31 ABB Research Ltd. Computerisiertes Werkzeug zur Konvertierung von Hardware/Software konfigurationsbetreffende Information in einem verteilten Steuersystem

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
(www.findarticles,com) (recherchiert am 11.06.03) *
AHO,Alfred,V.,et.al.:Compilers, Addison-Wesley Publishing Company, 1986, S.48-49 *
AHO,Alfred,V.,et.al.:Compilers, Addison-Wesley Publishing Company, 1986, S.48-49;
WATERS,Richard,C.:Program Translation via Abstraction and Reimplementation.In:IEEE Transactions on Software Engineering,Vol.14,No.8,Aug. 1988,S.1207-1227 *
WATERS,Richard,C.:Program Translation via Abstraction and Reimplementation.In:IEEE Transactions on Software Engineering,Vol.14,No.8,Aug. 1988,S.1207-1227;
Westinghouse process control helps power plants upgrade their systems for increased efficiency and with less interim downtime, Business Wire, Pittsburgh, April 9, 2001,S.1-2 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2778413A1 (de) * 2013-03-15 2014-09-17 Kaeser Kompressoren SE R&I-Schema Eingabe für ein Verfahren zum Steuern und/oder Überwachen einer Kompressoranlage
WO2014140261A1 (de) * 2013-03-15 2014-09-18 Kaeser Kompressoren Se R&i- schema eingabe
US10202974B2 (en) 2013-03-15 2019-02-12 Kaeser Kompressoren Se P and I diagram input
CN105159251A (zh) * 2015-08-14 2015-12-16 中国神华能源股份有限公司 一种实现max1000+plus系统与maxdna系统兼容的电厂dcs系统
CN105159251B (zh) * 2015-08-14 2019-04-05 中国神华能源股份有限公司 一种实现max1000+plus系统与maxdna系统兼容的电厂dcs系统

Similar Documents

Publication Publication Date Title
EP1723513B1 (de) Verfahren zur konfiguration eines computerprogramms
DE60011479T2 (de) Xml-roboter
EP1034475B1 (de) Verfahren zum testen von systemkomponenten eines objektorientierten programms
DE602005005924T2 (de) Einheitliches Datenformat für Messgeräte
DE19960050A1 (de) Grafische Benutzerschnittstelle zur Entwicklung von Anwendungsbeispielen unter Verwendung einer Testobjektbibliothek
DE10308725A1 (de) System und Verfahren zum Verwalten und zum Austausch von Daten eines technischen Projektes, einer technischen Anlage sowie einzelner Anlagenkomponenten
EP1176482A1 (de) Verfahren und Computerprogramm zum Herstellen einer Regelung oder Steuerung
EP2439691A1 (de) Vorrichtung und Verfahren zum maschinellen Erstellen eines Prozessdiagramms
DE102004043788A1 (de) Programm Generator
DE69907714T2 (de) Komponentbasiertes quellcodegeneratorverfahren
EP1005215B1 (de) Verfahren und Vorrichtung zum Editieren von Konfigurationsdaten für Telekommunikationssysteme
DE19947892A1 (de) Verfahren zur Umsetzung von Schnittstellendefinitionen und Zwischenformattabelle dafür
EP0838054B1 (de) Verfahren und steuereinrichtung für eine graphische steuerung von abläufen in einem netzwerkmanagementsystem
EP1862901A1 (de) Eingabe von Programm-Anweisungen bei imperativen Programmiersprachen
DE10254530A1 (de) Verfahren und System zur wissensbasierten Transformation von textuellen Programmen, die sich auf die Softwarekonfiguration eines verteilten Leitsystems beziehen
DE4310615C2 (de) Entwurf elektrischer Vorrichtungen mit mehreren Entwurfswerkzeugen, die zumindest teilweise untereinander inkompatibel sind
EP0708941B1 (de) Verfahren zum test eines objektorientierten programms
EP0662226B1 (de) Verfahren zur bearbeitung eines anwenderprogramms auf einem parallelrechnersystem
EP1149353B1 (de) Verfahren zur übertragung von simulationsmodellen zwischen simulatoren
EP1004950B1 (de) Verfahren zur Programmierung eines Automatisierungssystems
DE10254532A1 (de) Verfahren und System zur wissensbasierten Transformation von textuellen Programmen, die sich auf die Softwarekonfiguration eines verteilten Leitsystems beziehen
DE10109876B4 (de) Verfahren und Einrichtung zum Datenmanagement
DE19828611C2 (de) Datenverarbeitungsvorrichtung und zugehöriges Verfahren
EP2085879A1 (de) Verfahren zum Betrieb eines Programmiergerätes, Computerprogramm zur Implementierung des Verfahrens und nach dem Verfahren arbeitendes Programmiergerät oder Programmiergeräte mit einem solchen Computerprogramm
EP1525530A2 (de) UMSETZEINRICHTUNG, AUTOMATISIERUNGSGERäT MIT EINER UMSETZEINRICHTUNG UND ENTWICKLUNGSUMGEBUNG MIT EINEM AUTOMATISIERUNGSGERäT MIT UMSETZEINRICHTUNG

Legal Events

Date Code Title Description
OM8 Search report available as to paragraph 43 lit. 1 sentence 1 patent law
8139 Disposal/non-payment of the annual fee