-
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.
-
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 kann 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 werden, die bei
Durchführen
der Änderungen
nicht überschritten
werden darf.
-
Zu
diesem Zweck kann das Verfahren vorteilhaft umfassen, dass die für das Durchführender Ä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,
insbesondere 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äsentierung
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.
-
-
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, uintl6, 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
-
-
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.
-
-
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.
-
-
-
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 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 P1, 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.
