DE10335989B4

DE10335989B4 - Online-Änderungen von CIL-Code-Programmen für die Industrieautomatisierung

Info

Publication number: DE10335989B4
Application number: DE10335989.3A
Authority: DE
Inventors: Michael Petig; Hanno Lewandowski; Steffen Schlette
Original assignee: KW-SOFTWARE GmbH; KW Software GmbH
Current assignee: KW-SOFTWARE GmbH; KW Software GmbH
Priority date: 2003-08-01
Filing date: 2003-08-01
Publication date: 2019-07-11
Anticipated expiration: 2023-08-02
Also published as: US20050066320A1; US8108852B2; FR2858436B1; FR2858436A1; DE10335989A1; CN1580994A; CN100388193C; JP2008135049A; JP4836419B2; JP2005056415A; ITMI20041557A1

Abstract

Verfahren zum Bewirken einer Änderung im Prozessablauf einer Automatisierungseinrichtung während ein objektorientiertes Steuerprogramm zur Steuerung der Automatisierungseinrichtung von einem Laufzeitsystem ausgeführt wird, wobei das Steuerprogramm in Form eines Zwischencodes, der in Laufzeit in einen ausführbaren Maschinencode umgewandelt werden kann, in einem Speicher vorgehalten wird, umfassend- Bereitstellen eines geänderten Programms oder eines geänderten Programm-Moduls ebenfalls in Form eines Zwischencodes,- Vergleichen, durch das Laufzeitsystem, des Zwischencodes des geänderten Programms beziehungsweise des geänderten Programm-Moduls und des Zwischencodes des in Ausführung befindlichen Steuerprogramms zur Bestimmung der Änderungen,- Bewirken einer Änderung im Prozessablauf der Automatisierungseinrichtung durch Ändern des in Ausführung befindlichen Steuerprogramms, wobei das Durchführen der Änderungen innerhalb einer vorgegebenen Zeitdauer erfolgt, wobei die Zeitdauer in Abhängigkeit zumindest einer Reaktionszeit einer durch das Programm gesteuerten Automatisierungseinrichtung und/oder in Abhängigkeit zumindest eines Ausführungsintervalls des Programms festgelegt wird.

Description

Die Erfindung betrifft allgemein Automatisierungssysteme in der Industrie, und insbesondere Verfahren zur Änderung eines in Ausführung befindlichen objektorientierten Programms, insbesondere eines Programms zur Steuerung einer Automatisierungseinrichtung, sowie Laufzeitsysteme zur Ausführung von Steuerprogrammen in einer Steuereinheit einer Automatisierungseinrichtung.
Steuerungseinrichtungen werden zunehmend eingesetzt, um insbesondere großtechnische Prozesse oder Abläufe, etwa bei industrieller Herstellung oder Endmontage, zu steuern oder zu regeln. Ebenso werden sie zur Überwachung solcher weitestgehend automatisiert betriebenen Vorgänge wie auch zur Veranschaulichung des momentanen Prozeßstadiums benutzt.
Entsprechende Automatisierungseinrichtungen oder automatisierte Anlagen haben aufgrund des damit möglichen hohen Produktivitätsgrades eine herausragende Stellung in der industriellen Fertigung erlangt.
Aus „Dynamic linking of software components" von M. Franz, IEEE Computer Bd. 30, Nr. 3, März 1997, Seiten 74-81, sind verschiedene Varianten des dynamischen Linkens von Softwarekomponenten bekannt. Das .NET Compact Framework, welches ein Teil des .NET Frameworks und speziell für die Nutzung auf mobilen Endgeräten ausgerichtet ist, wird beispielsweise in „The .NET Compact Framework" von C. Neable, IEEE Pervasive Computing, Bd. 1, Nr. 4, Okt.-Dez. 2002, Seiten 84-87, beschrieben. Das .NET Compact Framework stellt eine Adaptionsschicht zur Unterstützung unterschiedlicher Betriebssysteme, sowie eine als CLR („common language runtime“) bezeichnete Laufzeitumgebung bereit, wobei die CLR dazu ausgebildet ist, mit Hilfe eines „just-in-time“-Kompilers (JIT) einen als MSIL („Microsoft Intermediate Language“) bezeichneten Zwischencode zu verarbeiten.
„Distributed computing in robotics and automation" von D. Brugali und M.E. Fayad, IEEE Transactions on Robotics and automation, Bd. 18, Nr. 4, August 2002, Seiten 409-420, gibt einen Überblick über verschiedene technologische Ansätze im Hinblick auf verteiltes Rechnen („Distributed Computing“) und deren Einsatz im Bereich der Roboter- und Automatisierungstechnik.
Der λ-Kalkül, welcher die formale Grundlage insbesondere funktionaler Programmiersprachen bildet, wird beispielsweise in „Dynamic rebinding for marshalling and update, with destruct-time λ" von G. Bierman G., M. Hicks, P. Sewell und K. Wansborough, Proceedings of the 8th ACM SIGPLAN International Conference on Functional Programming, 2003, Seiten 99 bis 110, beschrieben, wobei der Fokus auf verteilten ML-ähnlichen Programmiersprachen liegt.
In US 6 202 208 B1 wird ein Verfahren zum Ausführen eines Patches zum Modifizieren eines durch eine Java Virtual Machine ausgeführten Programms beschrieben, wobei zu diesem Zweck ein Patch erzeugt wird, welches die Programmänderungen umfasst, und das Patch bei laufendem Java-Programm angewandt wird.
Weitere Verfahren und Systeme zum Updaten von Softwarekomponenten sind beispielsweise aus US 2004/0107416 A1 , US 6 272 677 B1 , US 6 389 592 B1 , US 6 675 381 B1 , sowie aus US 6 691 080 B1 bekannt.
Um Produktivitätsausfälle zu vermeiden, muß das Steuerungsprogramm einer Automatisierungseinrichtung änderbar sein, ohne die Automatisierungseinrichtung anhalten oder in einen bestimmten Zustand bringen zu müssen.
Andernfalls müsste beispielsweise bei einer Verpackungsmaschine das gesamte Verpackungsmaterial sowie das zu verpackende Gut ausgeräumt werden, wenn der Bezug zwischen Steuerungsprogramm und dem aktuellen Inhalt der darin benutzten Variablen durch eine Programmänderung verloren geht und damit die Informationen über den aktuellen Prozeßzustand der Maschine nicht mehr verfügbar sind.
Damit ein geändertes Programm in jedem Zustand der Automatisierungseinrichtung übernommen werden kann, sind bestimmte Anforderungen zu erfüllen. Zum einen muß der Programmwechsel in Echtzeit erfolgen. Dies bedeutet, daß die festgelegten Reaktionszeiten beziehungsweise Ausführungsintervalle des Steuerungsprogramms nicht überschritten werden dürfen. Außerdem muß der aktuelle Zustand des Programms, insbesondere Daten, die beispielsweise Informationen über den aktuellen Prozesszustand der Automatisierungseinrichtung beinhalten, erhalten bleiben und von dem modifizierten Programm weiter verwendet werden.
Bei SPS-Steuerungen, wie sie in der Industrie-Automatisierung eingesetzt werden, sind heute schon verschiedene Programmiersysteme in der Lage, Programmänderungen durchzuführen, ohne daß die Programmausführung unterbrochen werden muß. Diese Funktionalität wird häufig als „Online-Programmierung“ bezeichnet. Bei diesen Systemen werden jedoch Verfahren angewendet, die eine enge Abstimmung von Programmiersystem und Laufzeitsystem der Steuerung verlangen. Das Programmiersystem verwaltet hierbei die Informationen über den Zustand des Programms vor der Änderung und leitet daraus die erforderlichen Maßnahmen ab, die zur Durchführung der Programmänderungen notwendig sind.
Derzeitige Programmiersysteme sind häufig durch zahlreiche Einschränkungen der Funktionalität gekennzeichnet. So wird beispielsweise der Echtzeitaspekt heute allgemein wenig berücksichtigt. Es wird vielmehr davon ausgegangen, das die Unterbrechungsdauer der Programmausführung unkritisch ist. Dies ist bei solchen Programmiersystemen gegeben, die nur Änderungen bezüglich der Programmbefehle zulassen, aber nicht Veränderungen an Variablenobjekten beziehungsweise an der Objektstruktur (Instanzierung) unterstützen. Bei anderen Systemen werden globale Datenobjekte verwendet, wobei der Anwender die Programmvariablen manuell adressiert. Hier ist der Anwender dafür verantwortlich, dass die Variablen nach den durchgeführten Programmänderungen ihren alten Inhalt behalten. Hauptnachteil solcher einfachen Programmiermodelle ist, das sie nicht objektorientiert sind und keine Datenkapselung ermöglichen.
Die Anforderungen an das verwendete Programmiersystem führen dazu, dass nur Programmierwerkzeuge verwendet werden können, die speziell für den Einsatz im Bereich industrieller Steuerungstechnik entwickelt wurden.
Der Erfindung liegt daher die Aufgabe zugrunde, einen konstruktiven Lösungsansatz anzugeben, wie bei einer weitgehenden oder sogar im wesentlichen vollständigen Reduzierung der bisherigen Einschränkungen der Funktionalität eines verwendeten Programmiersystems Änderungen an einem Steuerungsprogramm einer Automatisierungseinrichtung bei laufendem Prozess durchgeführt werden können. Insbesondere soll zur Änderung des Programms ein Programmierwerkzeug eingesetzt werden können, das nicht speziell für diesen Zweck angepasst ist.
Weitere Aufgabe der Erfindung ist es, einen Weg anzugeben, wie bei der Änderung eines in Ausführung befindlichen Steuerungsprogramms die Echtzeitanforderungen einer Automatisierungseinrichtung eingehalten werden können.
Die Aufgabe wird in überraschend einfacher Weise durch einen Gegenstand gemäß einem der anhängenden unabhängigen Ansprüche gelöst. Vorteilhafte Ausführungsformen und Weiterbildungen sind in den Unteransprüchen umschrieben.
Zunächst werden einige Begriffe definiert oder klargestellt, die für die gesamte Beschreibung und die Patentansprüche gültig sind.
In der objekt-orientierten Programmierung bezeichnet eine Klasse ein abstraktes Gebilde, das ein Objekt nachbildet. Ein Objekt ist eine Instanz einer Klasse, das heißt eine Abbildung im Speicher eines Rechnersystems, die nach der Vorlage der Klasse erzeugt wurde.
Eine Klasse kann verschiedene sogenannte Mitglieder haben. Hierzu gehören unter anderem Methoden und Felder der Klasse. Auch kann eine Unter-Klasse Mitglied einer Klasse sein.
Ein Stack bezeichnet einen reservierten Speicherbereich, in dem ein Programm Zustandsdaten zwischenspeichert. Als Heap wird ein für ein Programm reservierter Teil des Speichers bezeichnet, der zur temporären Aufnahme von Datenstrukturen dient, deren Existenz oder Größe sich vor dem Programmstart noch nicht festlegen läßt.
Das erfindungsgemäße Verfahren zur Änderung eines in Ausführung befindlichen objektorientierten Programms, insbesondere eines Programms zur Steuerung einer Automatisierungseinrichtung, wobei das Programm in Form eines Zwischencodes, der in Laufzeit in einen ausführbaren Maschinencode umgewandelt werden kann, in einem Speicher vorgehalten wird, umfasst das Bereitstellen eines geänderten Programms oder eines geänderten Programm-Moduls ebenfalls in Form eines Zwischencodes, das Vergleichen des Zwischencodes des geänderten Programms beziehungsweise des geänderten Programm-Moduls und des Zwischencodes des in Ausführung befindlichen Programms zur Bestimmung der Änderungen, sowie das Durchführen der Änderungen in dem in Ausführung befindlichen Programm.
Der große Vorteil dieses Verfahrens liegt darin, dass ein Programmierwerkzeug, das aus einem Quellcode einen Zwischencode generiert, keine zusätzlichen Informationen über die durchgeführten Programmänderungen erzeugen muss. Das Programmierwerkzeug benötigt daher keine zusätzlichen Funktionen zur Durchführung von Programmänderungen bei laufendem Prozeß, diese Aufgabe wird vom Laufzeitsystem, insbesondere einem eCLR-Laufzeitsystem (Embedded Common Language Runtime), übernommen. Hierdurch können Programmänderungen bei laufendem Prozeß auch von Programmierwerkzeugen unterstützt werden, die nicht speziell auf eine Anwendung im Bereich industrieller Steuerungstechnik hin entwickelt wurden.
Vorteilhaft wird als Zwischencode ein CIL- (Common Intermediate Language) beziehungsweise MSIL- (Microsoft Intermediate Language) Zwischencode verwendet. CIL und MSIL sind unterschiedliche Bezeichnungen des gleichen Zwischencodes. Der CIL-Zwischencode ist Bestandteil der .NET-Plattform von Microsoft^®. Der Vorteil des CIL-Zwischencodes liegt darin, dass dieser eine komplette Beschreibung für den Aufbau von Klassen enthält.
Bevorzugt erfolgt die Umwandlung eines Zwischencodes in ausführbaren Maschinencode mittels eines JIT- (Just in Time) Compilers, der ebenfalls Bestandteil der .NET-Plattform ist.
Besonders vorteilhaft umfasst das Durchführen der Änderungen des in Ausführung befindlichen Programms das Erzeugen zumindest eines ersten Programmobjekts, das Kopieren von Daten, die in zumindest einem zweiten Programmobjekt enthalten sind, in das zumindest eine erste Programmobjekt, wobei das zumindest eine zweite Programmobjekt Bestandteil des in Ausführung befindlichen Programms ist, sowie das Umschalten von dem zumindest einen zweiten Programmobjekt auf das zumindest eine erste Programmobjekt als Bestandteil des in Ausführung befindlichen Programms.
Dies bietet den Vorteil, dass durch das Ausführen bestimmter Schritte des Verfahrens im Hintergrund die Programmänderung vorbereitet werden kann.
Weiterhin wird vorteilhaft zum Durchführen der Änderungen ein Änderungsprogramm generiert. Dies erfolgt in der Regel durch das Laufzeitsystem und dient einem organisierten automatischen Ablauf der für die Programmänderung erforderlichen Schritte. Zu diesem Zweck wird beispielsweise durch das Laufzeitsystem Zwischencode generiert, dieser mittels des JIT-Compilers in ausführbaren Maschinencode umgewandelt und automatisch ausgeführt.
Vorteilhaft wird nach Durchführen der Änderungen der von den nicht mehr verwendeten Programmobjekten reservierte Speicher freigegeben. Hierzu kann die als „Garbage Collection“ bezeichnete Funktionalität eines CLR-Laufzeitsystems eingesetzt werden.
Prozesse, die auf Automatisierungseinrichtungen ablaufen, sind in der Regel bestimmten Echtzeit-Anforderungen unterworfen. Auf Grundlage der einzuhaltenden Echtzeitkriterien wird in Abhängigkeit zumindest einer Reaktionszeit einer durch das Programm gesteuerten Automatisierungseinrichtung und/oder in Abhängigkeit zumindest eines Ausführungsintervalls des Programms eine maximale Zeitdauer festgelegt, die bei Durchführen der Änderungen nicht überschritten werden darf.
Zu diesem Zweck kann das Verfahren vorteilhaft umfassen, dass die für das Durchführen der Änderungen erforderliche Zeitdauer durch Simulation ermittelt wird.
Besonders vorteilhaft erfolgt das Durchführen der Änderungen in zumindest zwei Teilschritten, wobei im ersten Teilschritt vorbereitende Maßnahmen durchgeführt werden, beispielsweise das Erzeugen von Programmobjekten und das Kopieren von Daten, und im zweiten Teilschritt beispielsweise das Umschalten auf die neu erzeugten Programmobjekte erfolgt. Wenn während des ersten Teilschritts ein Ereignis im Ablauf des in Ausführung befindlichen Programms eintritt, durch das beispielsweise bereits kopierte Daten geändert werden könnten, kann der erste Teilschritt zu einem späteren Zeitpunkt wiederholt werden.
Wechselt das in Ausführung befindliche Programm zyklisch zwischen einem aktiven Zustand und einem Ruhezustand, was für Steuerungsprogramme die Regel ist, so kann das Verfahren vorteilhaft den Schritt des Berechnens zumindest eines Zeitpunktes umfassen, zu dem das Programm in den aktiven Zustand wechselt.
Ist auch die für das Durchführen der Änderungen erforderliche Zeitdauer bekannt, kann so für einen gegebenen Zeitpunkt ermittelt werden, ob die Änderungen unter Einhaltung festgelegter Echtzeitbedingungen einer Automatisierungseinrichtung durchgeführt werden können.
Die Erfindung umfasst weiterhin ein Laufzeitsystem zur Ausführung von Steuerprogrammen in einer Steuereinheit einer Automatisierungseinrichtung, ausgebildet zur Durchführung des beschriebenen Verfahrens, umfassend Mittel zum Lesen und Schreiben von Speicherinhalten, wobei die Steuereinheit einen adressierbaren Speicher aufweist, und ein Steuerprogramm in Form eines ersten Zwischencodes in einem ersten Speicherbereich abrufbar abgelegt ist, und zumindest Teile des ersten Zwischencodes während des in der Automatisierungseinrichtung ablaufenden Prozesses in ausführbare Steuerbefehle umgewandelt werden, die in einem zweiten Speicherbereich abgelegt werden, und das Laufzeitsystem auf das Bereitstellen eines zweiten Zwischencodes in einem dritten Speicherbereich anspricht und eine Änderung im Prozessablauf in der Automatisierungseinrichtung bewirkt.
Vorteilhaft wird die Änderung im Prozessablauf in der Automatisierungseinrichtung bewirkt durch das Selektieren zumindest eines Teilbereiches des dritten Speicherbereiches und zumindest einer Speichereinheit des zweiten Speicherbereiches, in dem die Startadresse eines Teilbereichs des zweiten Speicherbereiches gespeichert ist, durch einen Vergleich des im ersten Speicherbereich gespeicherten ersten Zwischencodes und des im dritten Speicherbereich gespeicherten zweiten Zwischencodes, das Umwandeln des in dem Teilbereich des dritten Speicherbereiches gespeicherten Zwischencodes in ausführbare Steuerbefehle, die in einem vierten Speicherbereich abgelegt werden, das Kopieren von Daten aus dem Teilbereich des zweiten Speicherbereiches in den Teilbereich des dritten Speicherbereiches, sowie das Speichern der Startadresse des vierten Speicherbereiches in der Speichereinheit des zweiten Speicherbereiches.
Bei dem Laufzeitsystem handelt es sich vorteilhaft um ein CLR-Laufzeitsystem, insbesondere ein eCLR- Laufzeitsystem, da ein solches Laufzeitsystem Funktionalitäten aufweist, die besonders geeignet sind, um die beschriebene Wirkungsweise zu erzielen.
Wie bereits bei der Beschreibung des erfindungsgemäßen Verfahrens erwähnt, wird als Zwischencode bevorzugt ein CIL-Zwischencode verwendet. Weiterhin umfasst das Laufzeitsystem zur Umwandlung eines Zwischencodes in ausführbare Steuerbefehle bevorzugt einen JIT-Compiler.
Um die Programmänderungen organisiert auszuführen, weist das Laufzeitsystem vorteilhaft Mittel zum Generieren, Speichern und Ausführen von Steuerbefehlen auf.
Bei Einsatz des Laufzeitsystems in Echtzeitumgebungen kann eine Änderung im Prozessablauf innerhalb einer vorgegebenen Zeitdauer bewirkt werden, wobei das Laufzeitsystem hierzu vorteilhaft ein Mittel zur Berechnung der zum Bewirken einer Änderung im Prozessablauf einer Automatisierungseinrichtung benötigten Zeitdauer umfasst.
Zur Einhaltung von Echtzeitbedingungen können außerdem die zum Bewirken einer Änderung im Prozessablauf einer Automatisierungseinrichtung ablaufenden Schritte ganz oder teilweise wiederholt werden.
Es liegt auch im Rahmen der Erfindung, ein Automatisierungssystem anzugeben, in dem das beschriebene Laufzeitsystem integriert ist und das zur Ausführung des beschriebenen Verfahrens geeignet ist.
Die Erfindung wird nachfolgend beispielhaft anhand bevorzugter Ausführungsformen und unter Bezugnahme auf die beigefügten Zeichnungen genauer beschrieben. Dabei bezeichnen gleiche Bezugszeichen in den Zeichnungen gleiche oder ähnliche Teile.
Es zeigen:

1: eine schematische Darstellung der Metadaten und der Code-Repräsentaion einer Assembly,
2: schematisch die Modifizierung von Feldern einer Klasse, und
3: ein Prioritäts-Zeit-Diagramm mehrerer Tasks eines laufenden Programms, sowie eines Tasks zur Durchführung von Änderungen an diesem Programm.

Im folgenden Ausführungsbeispiel des erfindungsgemäßen Verfahrens kommt ein eCLR-Laufzeitsystem zum Einsatz, das zur Ausführung von Programmen auf Basis des im ECMA-Standard (European Computer Manufacturers Association) spezifizierten CIL-Zwischencodes dient. Ein eCLR-Laufzeitsystem verwendet Spezifikationen der Common Language Infrastructure (CLI) der .NET-Plattform von Microsoft^®.
Durch das betrachtete eCLR-Laufzeitsystem wird das Ändern eines Steuerprogramms einer Automatisierungseinrichtung bei laufendem Prozess ermöglicht. Ein Steuerprogramm, das in Form von CIL-Zwischencode vorliegt, setzt sich in der Regel aus einzelnen Modulen (Assemblies) zusammen, die ebenfalls jeweils CIL-Zwischencode enthalten. Das Ändern des Steuerprogramms erfolgt daher im wesentlichen durch Übernehmen und Aktivieren einer oder mehrerer geänderter Assemblies.
Zunächst werden die Änderungen im Quellcode des Programms beziehungsweise der zu ändernden Assemblies durchgeführt. Der Quellcode kann in unterschiedlichen Programmiersprachen vorliegen, beispielsweise in C# oder in einer der IEC61131-Spezifikation entsprechenden Programmiersprache. Aus dem geänderten Quellcode wird mittels eines Programmierwerkzeuges ein CIL-Zwischencode generiert. Hierzu kann jedes Programmierwerkzeug geeignet sein, das CIL-Zwischencode erzeugen kann.
Der CIL-Zwischencode aller geänderten Assemblies wird nun in das eCLR-Laufzeitsystem geladen.
Im nächsten Schritt analysiert das eCLR-Laufzeitsystem die neu geladenen CIL Zwischencode-Module und vergleicht diese mit dem sich aktuell in Ausführung befindlichen Programm. Hierbei werden alle vorhandenen Unterschiede detektiert. Ermöglicht wird dies dadurch, dass der CIL-Zwischencode eine komplette Beschreibung für den Aufbau von Klassen enthält. Hierzu gehören die Methoden sowie die Felder einer Klasse.
Es wird dann die Aktualisierung des Programms vorbereitet. Hierbei wird vom eCLR-Laufzeitsystem selbst Programmcode generiert, der die einzelnen Maßnahmen zur Übernahme organisiert. Hierzu gehört insbesondere das Übernehmen aller vorhandenen Daten, die auch in dem geänderten Programm verwendet werden. Des weiteren werden neue Daten initialisiert. Teil des generierten Programmcodes sind sogenannte Kopier-Konstruktoren und Delta-Konstruktoren.
Für jede geänderte Klasse wird ein Kopier-Konstruktor und ein Delta-Konstruktor erzeugt. In einem weiteren Schritt werden die Objekte der geänderten Klasse mittels des New-Operators erzeugt. Dann wird der Delta-Konstruktor ausgeführt. In diesem Schritt werden alle zusätzlichen neuen Mitglieder der Klasse erzeugt und/oder initialisiert. Im nächsten Schritt kopiert der Kopier-Konstruktor die aktuellen Werte der Objekte der alten Klasse. Schließlich werden alle Referenzen von den alten Objekten auf die neuen Objekte umgeschaltet. Für diesen Schritt der Ausführung wird das Steuerprogramm für eine kurze Zeitdauer blockiert.
Das eCLR-Laufzeitsystem hat die Kontrolle über die Referenzen eines Programms, auch als verwaltete Daten bezeichnet. Eine Referenz wird auf dem Heap gespeichert, auf dem Stack gibt es einen Verweis auf die Speicheradresse im Heap. Die Erstellung und Freigabe, die Speicherbeschaffung und der Zugriff auf Mitglieder einer Klasse wird über Zeiger organisiert.
Jede Assembly umfasst sogenannte Metadaten, auf die in Laufzeit zugegriffen werden kann.
1 zeigt die Abhängigkeiten 41 zwischen Metadaten 21 bis 24, 31 und 32 und Code-Repräsentation 11 bis 14 einer Assembly. Jede Assembly enthält Informationen über Klassen, in 1 beispielhaft mit X und Y bezeichnet, sowie deren Felder 31, 32 und Methoden 21 bis 24. Diese Informationen sind Bestandteil der Metadaten einer Assembly. Die Methoden und Felder einer Klasse weisen ebenfalls Abhängigkeiten 42 auf. Wenn eine Assembly in das eCLR-System geladen wird, wird der entsprechende Zwischencode mittels des JIT-Compilers in ausführbaren Maschinencode umgewandelt. Jede Methode einer Klasse wird repräsentiert durch einen kontinuierlichen Code-Block 11 bis 14 im verwalteten Code-Heap des Speichers. Alle erforderlichen Informationen über die Klassen und Methoden, beispielsweise welche Methode zu welcher Klasse gehört oder die Signaturen der Methoden, sind in einem statischen Datenbereich, dem Metadaten-Workspace, gespeichert. Bei Ausführung des Code-Blocks 12, der eine Methode 22 der Klasse X repräsentiert kann beispielsweise auch ein Zugriff 43 auf eine Methode 24 der Klasse Y erfolgen.
Jede Assembly besteht aus einer oder mehreren Klassen. Wenn nun eine Assembly geändert beziehungsweise ausgetauscht werden soll, werden zunächst die Unterschiede zwischen korrespondierenden Klassen der in Ausführung befindlichen und der geänderten Assembly bewertet. Hierbei werden verschiedene Fälle berücksichtigt.
Der erste Fall ist der, dass beide Klassen die gleichen Methoden und Felder beinhalten und auch der Zwischencode identisch ist. Dies kann beispielsweise mittels einer CRC-Prüfung des Codes geprüft werden. Da keine Änderungen des Zwischencodes vorliegen, sind in diesem Fall keine weiteren Schritte durchzuführen.
Im zweiten Fall beinhalten beide Klassen die gleichen Methoden und Felder, wobei eine oder mehrere Methoden der Klasse der geänderten Assembly einen im Vergleich zu der entsprechenden Klasse der in Ausführung befindlichen Assembly geänderten Zwischencode aufweisen. In diesem Fall wird für eine geänderte Methode eine Kompilierung durchgeführt und der Zeiger auf den so erzeugten Code dem Deskriptor der ursprünglichen Methode zugewiesen. Das Umschalten erfolgt in diesem Fall sehr schnell, da nur ein Zeigerelement zugewiesen wird.
Im dritten Fall beinhalten beide Klassen nicht die gleichen Methoden. Dies kann der Fall sein, wenn die geänderte Klasse eine zusätzliche Methode aufweist, eine in der ursprünglichen Klasse vorhandene Methode nicht mehr aufweist oder die beiden Klassen Methoden unterschiedlicher Signatur aufweisen. In diesem Fall kann es erforderlich sein, eine Methode zu löschen. Es wird dann eine Prüfung durchgeführt, um festzustellen, ob die zu löschende Methode nach Ausführen aller Änderungen einen Verweis in den aktiven Code beinhaltet. Folgendes Beispiel soll dies veranschaulichen. Betrachtet werden zwei Assemblies A und B, wobei Assembly A die Klasse X beinhaltet und Assembly B die Klasse Y. Die Methode X::process() ruft die Methode Y::process() auf. Wird nun die Methode process() der Klasse Y gelöscht, so werden zusätzlich entsprechende Änderungen in der Methode X::process() durchgeführt. In diesem Zusammenhang kann es auch notwendig sein, mehr als eine Assembly gleichzeitig zu ändern.
Im vierten Fall unterscheidet sich zumindest ein Feld der beiden Klassen. In diesem Fall werden Änderungen an den Objekten durchgeführt. Hier wird zunächst eine Prüfung bezüglich gelöschter Felder durchgeführt, die entsprechend der im dritten Fall beschriebenen Prüfung erfolgt. Wenn alle Änderungen zulässig sind, wird ein Kopier-Konstruktor generiert.
Im folgenden wird prinzipiell erklärt, wie eine geänderte Klasse die Mitglieder des ursprünglichen Klassentyps übernimmt. In der Regel erfolgt dies mit Kopier-Konstruktoren. Ein Kopier-Konstruktor ist eine spezielle Funktion, die alle Klassen-Mitglieder kopiert, die sowohl in dem alten als auch in dem neuen Klassentyp enthalten sind.
Um zu entscheiden, ob ein Klassenmitglied in beiden Klassen enthalten ist, lassen sich drei Fälle unterscheiden.
Sind die Namen und Datentypen der Klassenmitglieder identisch, so sind die Klassenmitglieder identisch. Dieser erste Fall beschreibt eine starke Beziehung zwischen den Klassenmitgliedern. Alle Klassenmitglieder, auf die dieser Fall zutrifft, werden vom Kopier-Konstruktor 1 zu 1 kopiert.
Sind nur die Namen der Klassenmitglieder identisch und der Datentyp ist ein elementarer Datentyp, so besteht eine schwache Beziehung zwischen den Klassenmitgliedern. Alle Klassenmitglieder, auf die dieser Fall zutrifft, werden kopiert und transformiert, beispielsweise vom Datentyp byte zum Datentyp int.
Trifft weder der erste noch der zweite Fall zu, werden die Klassenmitglieder als nicht identisch und damit ohne Beziehung zueinander angenommen. Diese Klassenmitglieder werden vom Kopier-Konstruktor nicht behandelt.
In 2 ist dies nochmals beispielhaft dargestellt. Die Klassenmitglieder a, b und d einer ersten Klasse 51 sind mit den Klassenmtgliedern a, b und d einer geänderten Klasse 52 identisch und werden vom Kopier-Konstruktor kopiert, in X durch Pfeile mit Bezugszeichen 61 bis 63 dargestellt. Das Klassenmitglied c der Klasse 51 hat den identischen Namen wie das Klassenmitglied c der Klasse 52, weist aber einen anderen Datentyp auf. Zwischen den beiden mit c bezeichneten Klassenmitgliedern besteht eine schwache Beziehung. Bei Kopieren des Klassenmitglieds c wird daher auch eine Transformation ausgeführt 64. Die Klassenmitglieder e, f und g haben keine Beziehung zueinander und werden daher vom Kopier-Konstruktor nicht behandelt.
Der Kopier-Konstruktor berücksichtigt nur nicht-statische Klassenmitglieder, da statische Klassenmitglieder nur eine Repräseritierung pro Klassentyp und nicht pro Instanz aufweisen.
Der Zugriff auf die Metadaten des ursprünglichen und eines geänderten Klassentyps ermöglicht es dem eCLR-Laufzeitsystems, Unterschiede zwischen Klassentypen zu analysieren und einen dem Klassentyp entsprechenden Kopier-Konstruktor zu generieren. Ein Beispiel für einen Kopier-Konstruktor in Form von Zwischencode ist nachfolgend angegeben.


 .method public hidebysig instance void copyctor(...)
 ldarg.0
 ldarg.1
 ldfld int32 Application.Test2/* 02000005 */::x1/* 04000022 */
 stfld int32 Application.Test1/* 02000006 */::x1/* 04000025 */
 ldarg.0
 ldarg.1
 ldfld char Application.Test2/* 02000005 */::x2 /* 04000023 */
 stfld int32 Application.Test1/* 02000006 */::x2/* 04000026 */
 ldarg.0
 ldarg.1
 ldfld int32 Application.Test2/* 02000005 */::x3/* 04000024 */
 stfld int32 Application.Test1/* 02000006 */::x3/* 04000027 */
 ret

Primär umfasst ein Kopier-Konstruktor die zwei Zwischencode-Befehle ldfld (load field) und stfld (store field). Dieses Befehlspaar wird verwendet für Felder, die sich in ihren Datentypen nicht unterscheiden. Eine schwache Beziehung zwischen den Feldern wird angenommen, wenn sich die Datentypen unterscheiden, aber den folgenden elementaren Datentypen angehören: bool, int8, uint8, int16, uint16, int32, uint32, int64, uint64, real32, real64. In diesen Fällen kann es erforderlich, Operatoren wie beispielsweise conv.i4 (int32) oder conv.r4 (real32) zu verwenden, um Klassenmitglieder mit schwacher Beziehung zu transformieren.

Das folgende in Form von Zwischencode angegebene Beispiel konvertiert das Feld X1 einer Klasse von Datentyp int zu Datentyp real:


 ldfld X::X1 // int datatype
 conv.r4
 stfld X*::X1 // real datatype

Das eCLR-Laufzeitsystem wandelt den Kopier-Konstruktor mittels des JIT-Compilers in ausführbaren Maschinencode um. Der nachfolgend angegebene Intel-basierte Assembler-Code könnte zum Beispiel das Ergebnis der Umwandlung eines Kopier-Konstruktors sein.


 mov esi dword ptr [ebp+8] ; source object
 mov edi dword ptr [ebp+12] ; destination object
 mov eax dword ptr [esi+4] ; x1 (old class)
 mov dword ptr [di+8], eax ; x1 (new class)

Falls ein Feld einen geänderten Datentyp aufweist, der nicht einem elementaren Datentypen angehört, sind zwei Fälle zu unterscheiden.

Ist der Basistyp „System.object“, so wird das Objekt vom eCLR-Laufzeitsystem selbst aktualisiert. Ist der Basistyp „System.Valuetype“, so enthält der Kopier-Konstruktor Code zur Ausführung des Kopier-Konstruktors dieser geänderten Klasse.

Das folgende Beispiel demonstriert die hierarchische Struktur eines Kopier-Konstruktors für den Fall, dass Unter-Klassen einer Klasse geändert werden.

 C#
 struct S { int x1; int x2;} 

 class X {
      int x1;
      S s1;
 }

IL code copy constructor X::copyctor :
 - - - - - - - - - - - - - - - - - - - - - - - - -
 ldfld X::X1 // int datatype
 stfld X*::X1
 ldflda X::s1
 ldflda X*::s1
 call S::copyctor

In diesem Fall wird der Zwischencode-Befehl ldflda (load address of field) zum Laden der Adressen der Unter-Klassen verwendet, um den entsprechenden Kopier-Konstruktor dieses Klassentyps aufzurufen.

Nach Umwandlung aller Kopier-Konstruktoren in ausführbaren Maschinencode sammelt das eCLR-Laufzeitsystem alle Referenzen zu geänderten Klassen, für die Kopier-Konstruktoren erzeugt wurden. Solche Referenzen können beispielsweise für statische Referenzen im globalen Datenraum lokalisiert sein oder für Unter-Klassen im lokalen Call-Stack oder in anderen Objekten. Wenn eine Liste aller Objekt-Referenzen generiert wurde, werden die geänderten Objekte vom eCLR-Laufzeitsystem unter Verwendung des New-Operators neu erzeugt. Nach Erzeugen und Initialisieren der Objekte erfolgt das Kopieren. Jetzt erhalten alle neuen Objekte durch den Kopier-Konstruktor den N aktuellen Inhalt der alten Objekte.

Bis zu diesem Zeitpunkt kann der Vorgang des Sammelns der Referenzen und des Erzeugens und Kopieren von Objekten wiederholt werden, falls das eCLR-Laufzeitsystem detektiert, dass ein dem zu ändernden Programm zugeordneter Thread während des Vorgangs aktiv geworden ist.

Danach erfolgt die kritische Phase des Änderns aller Referenzen, die nicht unterbrochen werden kann. In dieser Phase ist das zu ändernde Programm blockiert. Die für diesen Vorgang erforderlichen Zeigerzuweisungen und damit die erforderliche Zeitdauer hängt von der Anzahl der Objekt-Instanzen und deren Referenzen, sowie vom Umfang der Änderungen ab.

Nach erfolgtem Umschalten durch Ändern der Objekt-Referenzen kann das nunmehr geänderte Programm weiter ausgeführt werden. Die Blockierung der Threads wird aufgehoben. Eine weitere Funktion des eCLR-Laufzeitsystems ist es, die nicht mehr benötigten Speicherreservierungen freizugeben.

Weiterer Bestandteil der Erfindung ist ein Verfahren, welches die Einhaltung der für den Steuerungsprozess festgelegten Echtzeitkriterien bei der Durchführung von Programmänderungen sicherstellt. Steuerungsprogramme werden in der Regel zyklisch ausgeführt. Die Echtzeitkriterien sind durch die Ausführungsintervalle der Programme definiert, in denen die Eingänge gelesen, die Steuerungprogramme ausgeführt und die Ausgänge geschrieben werden.

Erreicht wird die Einhaltung der Echtzeitkriterien durch eine Unterteilung der Durchführung der Programmänderungen in eine Vorbereitungsphase und eine kritische Phase, wie bereits oben angedeutet. Um die Programmänderung erfolgreich durchzuführen, dürfen in beiden Phasen keine Programmbefehle des Steuerungsprogramm ausgeführt werden.

Die Vorbereitungsphase, die nahezu alle erforderlichen Maßnahmen zur Durchführung einer Programmänderung beinhaltet (ca. 99%), ist unterbrechbar und beliebig oft wiederholbar. In dem Fall, dass die Vorbereitungsphase durch die Ausführung eines Programmbefehls unterbrochen wird, kann diese zu einem beliebigen Zeitpunkt erneut von vorne begonnen werden.

Die kritische Phase beinhaltet die Aktivierung des neuen Programms. Die Aktivierung muß aus Konsistenzgründen für alle Programmobjekte gemeinsam erfolgen. Daher ist dieser Vorgang nicht unterbrechbar.

Die benötigte Zeitdauer für beide Phasen läßt sich erfindungsgemäß exakt ermitteln. Die Ausführungsdauer für die Durchführung einer Programmänderung muß auf jeden Fall kleiner sein als das kürzeste Ausführungsintervall eines Anwendungsprogramms. Typische Echtzeitanforderungen erfordern Zykluszeiten im Bereich von etwa 10 ms.

Die Zeitpunkte bis zur nächsten Aktivierung eines Programmzyklus lassen sich im voraus kalkulieren. Daher läßt sich für zyklisch ausgeführte Programme im Ruhezustand auch vorhersagen, wann die nächste Ausführung erfolgen wird.

Für ereignisgesteuerte Programme kann keine Vorhersage getroffen werden. Hier wirkt sich die Dauer der kritischen Phase auf den sogenannten Jitter aus. Tritt also in der kritischen Phase ein Ereignis ein, kann es erst frühestens nach Beendigung der kritischen Phase durch das entsprechend zugeordnete Programm bearbeitet werden. Ist der maximal tolerierte Jitter kleiner als die Ausführungsdauer für die kritische Phase einer Programmänderung, ist eine Programmänderung unter Einhaltung der so definierten Echtzeitkriterien nicht zu jedem Zeitpunkt möglich.

Der Ablauf ist in 3 beispielhaft in einem Prioritäts-Zeit-Diagramm dargestellt. Es ist die Aktivität verschiedener Tasks mit unterschiedlichen Prioritäten in Abhängigkeit der Zeit dargestellt. Wechselt ein Task in einen aktiven Zustand, so werden alle aktiven Tasks mit niedrigerer Priorität unterbrochen.

Der Task 73 ist der Haupt-Task des in Ausführung befindlichen Programms mit dem zugeordneten Programm-Modul P3. Die Ausführung dieses Tasks erfolgt periodisch mit einem Zeitintervall von 15 ms. Weitere Tasks des in Ausführung befindlichen Programms sind in diesem Beispiel ein weiterer periodischer Task 71 mit einem Zeitintervall von 10 ms und zugeordnetem Programm-Modul Pl, sowie ein ereignisorientierter Task 72 mit zugeordnetem Programm-Modul P2. Aufgrund von Echtzeitanforderungen weisen die dem in Ausführung befindlichen Programm zugeordneten Tasks die höchsten Prioritäten auf.

Die in 3 als Änderungs-Manager bezeichnet Komponente des eCLR-Laufzeitsystems organisiert die Programmänderungen. Der dem Änderungs-Manager zugeordnete Task 81 beziehungsweise 82 führt die Änderungen aus. In diesem Beispiel wird dieser Task 81 ein erstes Mal gestartet, nachdem der Haupt-Task 73 in einen Ruhezustand gewechselt ist. Während der Ausführung der Änderungen wird jedoch der Task 81 durch den aktiv werdenden Task 71 unterbrochen. Der Task 82 zur Durchführung der Änderungen wird daraufhin erneut gestartet, in diesem Beispiel zum nächsten Zeitpunkt, zu dem der Haupt-Task 73 wiederum in einen Ruhezustand wechselt. Der Task 82 wird durch keinen anderen Task unterbrochen, die Änderungen wurden daher erfolgreich durchgeführt. In diesem Beispiel wurde das Programm-Modul P3 geändert. Nach erfolgreicher Durchführung der Änderung wird das geänderte Programm-Modul P3* ausgeführt. Der Task 74 ist ein weiterer Task des eCLR-Systems, beispielsweise zur Kommunikation oder zum Debuggen.

Claims

Verfahren zum Bewirken einer Änderung im Prozessablauf einer Automatisierungseinrichtung während ein objektorientiertes Steuerprogramm zur Steuerung der Automatisierungseinrichtung von einem Laufzeitsystem ausgeführt wird, wobei das Steuerprogramm in Form eines Zwischencodes, der in Laufzeit in einen ausführbaren Maschinencode umgewandelt werden kann, in einem Speicher vorgehalten wird, umfassend - Bereitstellen eines geänderten Programms oder eines geänderten Programm-Moduls ebenfalls in Form eines Zwischencodes, - Vergleichen, durch das Laufzeitsystem, des Zwischencodes des geänderten Programms beziehungsweise des geänderten Programm-Moduls und des Zwischencodes des in Ausführung befindlichen Steuerprogramms zur Bestimmung der Änderungen, - Bewirken einer Änderung im Prozessablauf der Automatisierungseinrichtung durch Ändern des in Ausführung befindlichen Steuerprogramms, wobei das Durchführen der Änderungen innerhalb einer vorgegebenen Zeitdauer erfolgt, wobei die Zeitdauer in Abhängigkeit zumindest einer Reaktionszeit einer durch das Programm gesteuerten Automatisierungseinrichtung und/oder in Abhängigkeit zumindest eines Ausführungsintervalls des Programms festgelegt wird.
Verfahren nach Anspruch 1, wobei als Zwischencode ein CIL- oder MSIL-Zwischencode verwendet wird, der eine im wesentlichen komplette Beschreibung für den Aufbau von Klassen enthält.
Verfahren nach einem der vorstehenden Ansprüche, wobei die Umwandlung eines Zwischencodes in ausführbaren Maschinencode mittels eines JIT-Compilers erfolgt.
Verfahren nach einem der vorstehenden Ansprüche, wobei das Durchführen der Änderungen die Schritte umfasst: - Erzeugen zumindest eines ersten Programmobjekts, - Kopieren von Daten, die in zumindest einem zweiten Programmobjekt enthalten sind, in das zumindest eine erste Programmobjekt, wobei das zumindest eine zweite Programmobjekt Bestandteil des in Ausführung befindlichen Programms ist, sowie - Umschalten von dem zumindest einen zweiten Programmobjekt auf das zumindest eine erste Programmobjekt als Bestandteil des in Ausführung befindlichen Programms.
Verfahren nach einem der vorstehenden Ansprüche, wobei für das Durchführen der Änderungen automatisch ein Änderungsprogramm generiert wird.
Verfahren nach einem der vorstehenden Ansprüche, wobei nach Durchführen der Änderungen der von den nicht mehr verwendeten Programmobjekten reservierte Speicher freigegeben wird.
Verfahren nach einem der vorstehenden Ansprüche, wobei die für das Durchführen der Änderungen erforderliche Zeitdauer durch Simulation ermittelt wird.
Verfahren nach einem der vorstehenden Ansprüche, wobei das Durchführen der Änderungen zumindest zwei Teilschritte umfasst, von denen zumindest ein Teilschritt wenigstens einmal wiederholt wird.
Verfahren nach Anspruch 8, wobei das Wiederholen des zumindest einen Teilschritts in Abhängigkeit vom Eintreten eines festgelegten Ereignisses im Programmablauf erfolgt.
Verfahren nach einem der vorstehenden Ansprüche, wobei das in Ausführung befindliche Programm zyklisch zwischen einem aktiven Zustand und einem Ruhezustand wechselt und das Verfahren den Schritt des Berechnens zumindest eines Zeitpunktes umfasst, zu dem das Programm in den aktiven Zustand wechselt.
Laufzeitsystem zur Ausführung von Steuerprogrammen in einer Steuereinheit einer Automatisierungseinrichtung, ausgebildet zur Durchführung eines Verfahrens nach einem der vorstehenden Ansprüche, umfassend Mittel zum Lesen und Schreiben von Speicherinhalten, wobei die Steuereinheit einen adressierbaren Speicher aufweist, und ein Steuerprogramm in Form eines ersten Zwischencodes in einem ersten Speicherbereich abrufbar abgelegt ist, und zumindest Teile des ersten Zwischencodes während des in der Automatisierungseinrichtung ablaufenden Prozesses in ausführbare Steuerbefehle umgewandelt werden, die in einem zweiten Speicherbereich abgelegt werden, und das Laufzeitsystem auf das Bereitstellen eines zweiten Zwischencodes in einem dritten Speicherbereich anspricht und eine Änderung im Prozessablauf in der Automatisierungseinrichtung bewirkt, wobei das Laufzeitsystem zum Vergleichen des ersten und zweiten Zwischencodes ausgebildet ist.
Laufzeitsystem nach Anspruch 11, ferner dadurch gekennzeichnet, dass die Änderung im Prozessablauf in der Automatisierungseinrichtung bewirkt wird durch - Selektieren zumindest eines Teilbereiches des dritten Speicherbereiches und zumindest einer Speichereinheit des zweiten Speicherbereiches, in dem die Startadresse eines Teilbereichs des zweiten Speicherbereiches gespeichert ist, durch einen Vergleich des im ersten Speicherbereich gespeicherten ersten Zwischencodes und des im dritten Speicherbereich gespeicherten zweiten Zwischencodes, - Umwandeln des in dem Teilbereich des dritten Speicherbereiches gespeicherten Zwischencodes in ausführbare Steuerbefehle, die in einem vierten Speicherbereich abgelegt werden, - Kopieren von Daten aus dem Teilbereich des zweiten Speicherbereiches in den Teilbereich des dritten Speicherbereiches, - Speichern der Startadresse des vierten Speicherbereiches in der Speichereinheit des zweiten Speicherbereiches.
Laufzeitsystem nach Anspruch 11, wobei das Laufzeitsystem ein CLR-System, insbesondere ein eCLR-System ist.
Laufzeitsystem nach einem der Ansprüche 11 bis 13, wobei der Zwischencode ein CIL- oder MSIL-Zwischencode ist, der eine komplette Beschreibung für den Aufbau von Klassen enthält.
Laufzeitsystem nach einem der Ansprüche 11 bis 14, wobei das Laufzeitsystem zur Umwandlung eines Zwischencodes in ausführbare Steuerbefehle einen JIT-Compiler umfasst.
Laufzeitsystem nach einem der Ansprüche 11 bis 15, umfassend ein Mittel zum Generieren, Speichern und Ausführen von Steuerbefehlen.
Laufzeitsystem nach einem der Ansprüche 11 bis 16, das eine Änderung im Prozessablauf einer Automatisierungseinrichtung innerhalb einer vorgegebenen Zeitdauer bewirkt.
Laufzeitsystem nach einem der Ansprüche 11 bis 17, umfassend ein Mittel zur Berechnung der zum Bewirken einer Änderung im Prozessablauf einer Automatisierungseinrichtung benötigten Zeitdauer.
Laufzeitsystem nach einem der Ansprüche 11 bis 18, wobei die zum Bewirken einer Änderung im Prozessablauf einer Automatisierungseinrichtung ablaufenden Schritte ganz oder teilweise wiederholt werden.
Automatisierungssystem, umfassend ein Laufzeitsystem nach einem der Ansprüche 11 bis 19, geeignet zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 10.