PatentDe  


Dokumentenidentifikation DE102004019371B4 13.04.2006
Titel Verfahren zur Wiederherstellung eines Betriebszustands eines Systems
Anmelder Siemens AG, 80333 München, DE
Erfinder Freiberg, Klaus, 76771 Hördt, DE;
Graf, René. Dr., 76135 Karlsruhe, DE;
Laforsch, Jürgen, 76187 Karlsruhe, DE
DE-Anmeldedatum 21.04.2004
DE-Aktenzeichen 102004019371
Offenlegungstag 17.11.2005
Veröffentlichungstag der Patenterteilung 13.04.2006
Veröffentlichungstag im Patentblatt 13.04.2006
IPC-Hauptklasse G06F 11/00(2006.01)A, F, I, 20051017, B, H, DE
IPC-Nebenklasse G06F 9/48(2006.01)A, L, I, 20051017, B, H, DE   

Beschreibung[de]

Die Erfindung betrifft ein Verfahren zur Wiederherstellung eines Betriebszustands eines Systems gemäß den im Anspruch 1 angegebenen Maßnahmen.

Aus der US 4 959 774 ist ein Speichersystem mit einem Haupt- und einem Schattenspeicher bekannt, der Zugriffe auf den Hauptspeicher überwacht. Es sind Maßnahmen vorgesehen, welche bei einem Stromausfall einen Verlust der Daten im Hauptspeicher verhindern.

Bei Systemen, insbesondere bei Rechnern, besteht in der Regel die Forderung, dass sie nach einer Unterbrechung, wie beispielsweise nach einem Stromausfall, ihren Betrieb an der Stelle fortsetzen sollen, an der die Unterbrechung auftrat. Dies ist häufig sehr schwierig, da bei einer plötzlichen Unterbrechung nicht fest abgespeicherte, d. h. flüchtige Daten in der Regel verloren gehen. Um dies zu vermeiden, wird insbesondere bei Rechnern die Stromversorgung überwacht, um eine Unterbrechung der Stromversorgung rechtzeitig zu erkennen und entsprechende Sicherheitsmaßnahmen ergreifen zu können. Wird eine Unterbrechung der Stromversorgung festgestellt, wird eine so genannte Interruptroutine gestartet, mittels welcher alle wesentlichen flüchtigen Systemdaten gespeichert werden, wobei während der Ausführung der Interruptroutine die Energieversorgung des Rechners mittels eines entsprechenden Energiepuffers vorgenommen wird.

Sofern jede einzelne Task exakt an dem Befehl weiterläuft, an dem sie durch den Ausfall der Energieversorgung unterbrochen wurde, wird das betreffende System als wiederanlauffähig nach Energieunterbrechung bezeichnet. Hierzu müssen für alle Tasks aber nach dem Wiedereinschalten der Energieversorgung alle Speicherbereiche, Kontexthierarchien, Stacks und Prozessorregister den gleichen Inhalt haben wie zum Zeitpunkt der Unterbrechung der Energieversorgung.

Um dies zu erreichen, wird beispielsweise bei einer Unterbrechung der Stromversorgung ein Interrupt ausgelöst, der die jeweils laufende Task unterbricht. In der entsprechenden Interrupt-Service-Routine bleibt der Software nur eine kurze Zeit, um wichtige Informationen, die in einem flüchtigen Speicher liegen, in einen remanenten Speicher zu sichern. Das System wird hierdurch in einen eindeutigen Zustand gebracht. Dieser Vorgang wird regelmäßig als "Herunterfahren" bezeichnet.

Nachdem die Unterbrechung der Stromversorgung beendet ist, d. h. beim Wiedereinschalten des Rechners, läuft eine Firmware an, mittels welcher, soweit erforderlich, die Hardware initialisiert und anschließend festgestellt wird, dass eine Unterbrechung der Stromversorgung vorlag. Daraufhin werden die Speicher und Task-Kontexte aus den gesicherten Daten restauriert und, vereinfacht ausgedrückt, die Interrupt-Service-Routine fortgesetzt, die sich dann beendet und die Rechenleistung an die unterbrochene Task zurückgibt. Dieser Vorgang wird regelmäßig als "Wiederanlauf" bezeichnet.

Die Erfassung eines Systemzustands bzw. die Speicherung der relevanten Systemdaten ist häufig nur mit sehr großem Aufwand bzw. manchmal gar nicht zu realisieren. Dies ist insbesondere dann der Fall, wenn Softwarepakete Dritter verwendet werden, die die Eigenschaft der Wiederanlauffähigkeit nicht aufweisen oder sich nur mit unverhältnismäßigem Aufwand nachbessern ließen. Des Weiteren ist ein Wiederanlauf häufig nicht möglich, weil Hardware vorhanden ist, welche bei einer Unterbrechung der Stromversorgung Registerinhalte verliert, und die entsprechende Software dies nicht kompensieren kann.

Es ist Aufgabe der Erfindung, ein Verfahren zur Wiederherstellung eines Betriebszustands eines Systems derart auszubilden, dass nicht wiederanlauffähige Programmteile in ein insgesamt wiederanlauffähiges System integriert werden können.

Diese Aufgabe wird durch die im Anspruch 1 angegebenen Maßnahmen gelöst. Vorteilhafte Weiterbildungen der Erfindung ergeben sich aus den Unteransprüchen.

Kritisch bedeutet hierbei, dass die Befehlsfolge bzw. ein entsprechendes Softwarepaket selbst nicht wiederanlauffähig ist oder auf Hardware zugreift, die ihren Speicherinhalt bei einer Unterbrechung verliert, wie beispielsweise Prozessorregister.

Dadurch, dass die zweiten flüchtigen Zustandsdaten jeweils zu Beginn einer kritischen Befehlsfolge gesichert werden, ergibt sich in vorteilhafter Weise die Möglichkeit, das System und insbesondere den von der kritischen Befehlsfolge abhängigen Systemteil jederzeit in den Zustand versetzen zu können, in dem es bzw. er sich vor Beginn der Abarbeitung der kritischen Befehlsfolge befunden hat. Tritt während der Abarbeitung einer kritischen Befehlsfolge beispielsweise eine Unterbrechung der Stromversorgung auf, werden die von der unkritischen Befehlsfolge abhängigen flüchtigen Zustandsdaten des Systems auf herkömmliche Weise gesichert und nach Beendigung der Unterbrechung wieder hergestellt. Da die von der kritischen Befehlsfolge abhängigen Zustandsdaten des Systems beim Eintritt der Unterbrechung systembedingt nicht gesichert werden konnten, können diese nicht wieder hergestellt werden. Da jedoch die von der kritischen Befehlsfolge abhängigen flüchtigen Zustandsdaten vor Beginn der Abarbeitung der kritischen Befehlsfolge gesichert wurden, können diese Zustandsdaten des Systems wieder in den Zustand gebracht werden, den sie vor Beginn der Abarbeitung der kritischen Befehlsfolge hatten.

Der Betrieb des Systems kann daher an der Stelle fortgesetzt werden, an der die kritische Befehlsfolge beginnt.

Das erfindungsgemäße Verfahren könnte als Enter-Exit-Verfahren bezeichnet werden, da es immer dann relevant wird, wenn ein kritischer Softwareabschnitt betreten wird (Enter) und später wieder verlassen wird (Exit). Ein Enter-Punkt stellt jeweils den Beginn eines kritischen Abschnitts dar, der Exit-Punkt dessen Ende. In jeder Task kann an beliebig vielen Stellen ein Enter-Punkt definiert werden. Hierbei ist jedoch darauf zu achten, dass die Definitionen nicht geschachtelt werden. D. h., innerhalb eines kritischen Abschnitts dürfen zwar untergeordnete, d. h. geschachtelte Programmabschnitte abgearbeitet werden, ein kritischer Abschnitt darf jedoch nur in derselben Ebene verlassen werden, in der er betreten wurde. Mit anderen Worten, ein Exit-Punkt muss in derselben Programmebene liegen wie der zugehörige Enter-Punkt.

Gemäß dem erfindungsgemäßen Verfahren wird an einem aktuellen Enter-Punkt der Kontext der laufenden Task gesichert, so dass ein definierter Wiederaufsetzpunkt mit allen Prozessorregistern und Programmzählern existiert. Am Exit-Punkt wird diese Kontextinformation wieder freigegeben, da die Task nicht mehr auf kritische Adressen zugreift und somit wiederanlauffähig ist. Tritt während der Abarbeitung der kritischen Befehlsfolge eine Unterbrechung auf, so wird die Software nicht befehlsgranular an dem Unterbrechungspunkt fortgesetzt, sondern an dem für diesen Abschnitt definierten Enter-Punkt, da durch die Sicherung des Kontexts am Enter-Punkt hierfür noch eine konsistente Speicher- und Registersicht vorliegt.

Vor der Abarbeitung der kritischen Befehlsfolge wird festgestellt, ob eine Unterbrechung vorlag, wobei im Falle einer Unterbrechung zunächst durch die kritische Befehlsfolge veränderte und nicht gesicherte Zustandsdaten an einen definierten Zustand angepasst werden. D. h., wird vor Abarbeitung einer kritischen Befehlsfolge festgestellt, dass eine Unterbrechung nicht vorlag, werden die zweiten flüchtigen Zustandsdaten gesichert und die kritische Befehlsfolge abgearbeitet. Wird jedoch festgestellt, dass eine Unterbrechung vorlag, müssen durch die kritische Befehlsfolge veränderte, nicht gesicherte Zustandsdaten vor der Abarbeitung der kritischen Befehlsfolge zunächst an einen definierten Zustand angepasst werden. Es wird somit eine Korrekturroutine, d. h. eine Aufräum-Funktion aufgerufen, die alle im kritischen Abschnitt veränderten Variablen und Ressourcen in einen definierten Zustand bringt.

In vorteilhafter Weise wird die Anpassung der nicht gesicherten Zustandsdaten an einen definierten Zustand, d. h. die Ausführung der Korrekturroutine als kritische Befehlsfolge behandelt. Hierdurch ist gewährleistet, dass bei Beginn der Korrekturroutine am aktuellen Enter-Punkt der Kontext der laufenden Task gesichert wird, wodurch eine während der Durchführung der Korrekturroutine auftretende erneute Unterbrechung ebenfalls abgesichert ist.

Als sehr vorteilhaft hat sich eine Ausführungsform der Erfindung herausgestellt, bei welcher gewährleistet ist, dass bei vollständig zu durchlaufenden untergeordneten unkritischen Befehlsfolgen wie beispielsweise eine Listenverwaltung, welche innerhalb einer kritischen Befehlsfolge angeordnet sind, durch eine Unterbrechung während der Abarbeitung der vollständig zu durchlaufenden Befehlsfolge keine Inkonsistenzen entstehen. Dies könnte einerseits durch eine Interruptsperre erreicht werden, welche bewirkt, dass die Interrupt-Service-Routine, mittels welcher flüchtige Systemdaten bei einer Unterbrechung gesichert werden, zeitverzögert ausgeführt wird. Da wegen der begrenzten Energie, welche nach einer Unterbrechung der Stromversorgung in der Regel nur noch zur Verfügung steht, die Zeit für die Ausführung der Interrupt-Service-Routine begrenzt ist, lässt sich die Ausführung der Interrupt-Service-Routine aber nur um eine sehr begrenzte Zeit verschieben.

In vorteilhafter Weise werden daher erfindungsgemäß beim Eintritt einer Unterbrechung während der Abarbeitung der untergeordneten unkritischen Befehlsfolge flüchtige Zustandsdaten gesichert und nach der Unterbrechung wieder hergestellt sowie die Abarbeitung der untergeordneten unkritischen Befehlsfolge fortgesetzt. D. h., die untergeordnete Befehlsfolge wird nach der Unterbrechung befehlsgranular fortgesetzt.

Hierzu wird zu Beginn der untergeordneten Befehlsfolge eine Disable-Enter-Funktion aufgerufen, welche bewirkt, dass nach einer Unterbrechung, welche bei der Abarbeitung einer innerhalb einer kritischen Befehlsfolge angeordneten untergeordneten unkritischen Befehlsfolge auftrat, das Programm nicht am Enter-Punkt fortgesetzt wird, sondern zunächst an der Stelle, an der es unterbrochen wurde. D. h., die betreffende Task läuft wie jede andere unkritische Task befehlsgranular an. Nachdem die untergeordnete Befehlsfolge durchlaufen wurde, wird eine Enable-Enter-Funktion aufgerufen. Diese Funktion bewirkt, dass das Programm dann in der üblichen erfindungsgemäßen Weise am Enter-Punkt fortgesetzt wird. Durch die Funktionen Disable-Enter und Enable-Enter wird sowohl die Konsistenz im untergeordneten unkritischen Programmteil gewahrt, als auch die Inkonsistenz im darumliegenden kritischen Programmteil ausgeschlossen.

Mittels des erfindungsgemäßen Verfahrens lassen sich in vorteilhafter Weise beliebige Softwarekomponenten in eine Firmware integrieren, da sie keinen Randbedingungen für einen Wiederanlauf genügen müssen. Der Wiederaufsetzpunkt vor dem Aufruf der Enter-Funktion und deren erneutes Durchlaufen erlauben auch die korrekte Behandlung wiederkehrender, hochfrequenter Netzausfälle, bei denen die Aufräum-Funktion mehrfach gestartet werden muss, bis alle Ressourcen freigegeben sind. Betriebssystem-Ressourcen werden korrekt behandelt, da ihr Zustandsvektor um den Enter-Status erweitert wurde. Wird die Enter-Funktion vor Eintritt der Produktivschleife einer Task aufgerufen, ist es möglich, diese Task mittels des erfindungsgemäßen Verfahrens vollständig neu zu starten. Eine gegebenenfalls erforderliche Konsistenzsicherung in bestimmten kritischen Softwareabschnitten ist durch das vorübergehende Stilllegen des definierten Wiederaufsetzpunktes realisierbar.

Weitere Einzelheiten, Merkmale und Vorteile der vorliegenden Erfindung ergeben sich aus der nachfolgenden Beschreibung eines besonderen Ausführungsbeispiels unter Bezugnahme auf die Zeichnung.

Es zeigen:

1 eine schematische Darstellung eines Ablaufplans einer ersten Ausführungsform eines erfindungsgemäßen Verfahrens und

2 eine schematische Darstellung eines Ablaufplans einer zweiten Ausführungsform eines erfindungsgemäßen Verfahrens.

Wie 1 entnommen werden kann, wird nach dem Start 1 eines Systems zunächst unkritische Software 2 ausgeführt. Nach dem Abarbeiten der unkritischen Software 2 wird kritische Software 3 abgearbeitet. Im Anschluss an die Abarbeitung der kritischen Software 3 wird wiederum unkritische Software 4 abgearbeitet, bis das Ende 5 erreicht wird. Die unkritische Software 2 ist dadurch gekennzeichnet, dass sie wiederanlauffähig ist. D. h., bei einer Unterbrechung der Abarbeitung der unkritischen Software 2 werden mittels einer Interruptroutine alle wesentlichen flüchtigen Systemdaten gespeichert, so dass sie nach der Unterbrechung wieder hergestellt werden können.

Die kritische Software 3 ist dadurch gekennzeichnet, dass sie nicht wiederanlauffähig ist. D. h., bei einer Unterbrechung der kritischen Software 3 können nicht alle wesentlichen Systemdaten zum Zeitpunkt der Unterbrechung gespeichert werden, so dass sie nach der Unterbrechung nicht wieder herstellbar sind.

Vor Beginn der kritischen Software 3 wird eine Enter-Funktion 6 aufgerufen, welche bewirkt, dass der vollständige Kontext der Task sowie dessen Position im Call-Stack an dieser Stelle gesichert (Sicherung 7) wird. Nach der Sicherung 7 der genannten Systemdaten erfolgt eine Abfrage 8, ob ein Netzausfall (NAU) vorlag. Lag kein Netzausfall vor, wird die kritische Software 3 regulär abgearbeitet. Nach dem Abarbeiten der kritischen Software 3 wird eine Exit-Funktion 11 aufgerufen, durch die dem System mitgeteilt wird, dass der Bereich der kritischen Software 3 verlassen wurde. Dies bewirkt, dass bei einem danach auftretenden Netzausfall neben der regulären Interrupt-Service-Routine keine weiteren Sicherungsmaßnahmen durchgeführt werden müssen.

Tritt beim Abarbeiten der kritischen Software 3 ein Netzausfall auf, wird dies festgestellt, woraufhin das Programm nach Beendigung des Netzausfalls zu einem Wiederaufsetzpunkt 9 verzweigt, welcher vor dem Aufruf der Enter-Funktion 6 angeordnet ist. Somit erfolgt zunächst wiederum der Aufruf der Enter-Funktion 6, so dass der vollständige Kontext der Task sowie dessen Position im Call-Stack zu diesem Zeitpunkt erneut gesichert (Sicherung 7) wird. Bei der anschließenden erneuten Abfrage 8, ob ein Netzausfall vorlag, verzweigt das Programm dann zu einer Aufräum-Funktion 10. Die Aufräum-Funktion 10 bewirkt, dass alle im kritischen Abschnitt 3 veränderten Variablen und Ressourcen in einen definierten Zustand gebracht werden. Nach Durchlaufen der Aufräum-Funktion 10 verzweigt das Programm zum Aufruf der Exit-Funktion 11, wodurch dem System mitgeteilt wird, dass der Bereich der kritischen Software 3 verlassen wurde. Die kritische Software 3 wird dann erst beim nächsten regulären Durchlauf abgearbeitet. Die Aufräum-Funktion 10 könnte aber auch so ausgebildet sein, dass sie die Befehlsfolge der kritischen Software 3 enthält, wodurch die kritische Software 3 innerhalb der Aufräum-Funktion 10 abgearbeitet werden würde. Des Weiteren könnte das Programm nach Durchlaufen der Aufräum-Funktion 10 zum Eingang der kritischen Software 3 verzweigen, so dass die kritische Software 3 unmittelbar nach Durchlaufen der Aufräum-Funktion 10 abgearbeitet wird.

Die Abfrage 8, ob ein Netzausfall vorlag, entscheidet somit, ob der Bereich der kritischen Software 3 durchlaufen wird oder ob eine Unterbrechung während der vorhergehenden Abarbeitung der kritischen Software 3 stattgefunden hat, so dass nun aufgeräumt werden muss. So könnten beispielsweise Semaphoren freigegeben werden müssen, die während des Abarbeitens der kritischen Software 3 gesetzt wurden. Der Aufruf der Exit-Funktion 11 gibt den gespeicherten Kontext wieder frei (12), da dieser nicht mehr benötigt wird. Die vorstehend beschriebene Ablaufsequenz kann mehrfach hintereinander in einer Task vorkommen, in der sich kritische und unkritische Programmteile abwechseln.

Trat während der Abarbeitung der kritischen Software 3 ein Netzausfall auf, so läuft das System beim anschließenden Wiederanlauf nach der Initialisierung des Systems innerhalb der kritischen Software 3 nicht befehlsgranular in der unterbrochenen Task weiter, sondern es werden zuerst alle Tasks auf ihren Enter-Exit-Status hin untersucht. Ist eine Task zwischen Enter und Exit unterbrochen worden, so muss deren Call-Stack analysiert werden. Wurden innerhalb der kritischen Software 3 weitere Funktionsaufrufe vorgenommen, muss der Call-Stack rückgebaut werden, bis man wieder in der Funktion steht, in der Enter aufgerufen wurde. Daraufhin wird an diese Stelle im Call-Stack der gesicherte Kontext kopiert, so dass die Task exakt vor dem Enter-Aufruf steht mit allen Prozessorregisterinhalten. Nachdem diese Analyse für jede Task durchgeführt wurde, stehen alle Tasks entweder an dem unterbrochenen Befehl oder vor dem Aufruf der jeweiligen Enter-Funktion 6, weil die Unterbrechung in einem Bereich kritischer Software 3 stattfand. Erst wenn jede Task wieder in einem Bereich unkritischer Software 2, 4 steht, wird die jeweilige unterbrochene Task wie vorstehend beschrieben fortgesetzt.

Jede Task, die in einem Bereich kritischer Software 3 unterbrochen wurde, wird unmittelbar vor dem Aufruf der Enter-Funktion 6 fortgesetzt. Die Abfrage 8, ob ein Netzausfall vorlag, bewirkt, dass anschließend in die Aufräum-Funktion 10 verzweigt wird. Der erneute Aufruf der Enter-Funktion 6 bewirkt, dass auch die Aufräum-Funktion 10 vor einem weiteren Netzausfall geschützt ist und so sichergestellt wird, dass die Task in einen sicheren Zustand kommt. Denn tritt während der Ausführung der Aufräum-Funktion 10 erneut ein Netzausfall auf, verzweigt das Programm nach Beendigung des Netzausfalls erneut zu dem Wiederaufsetzpunkt 9, da die Exit-Funktion 11 noch nicht aufgerufen wurde. Da vor Beginn der Aufräum-Funktion 10 die Enter-Funktion 6 aufgerufen wurde, wurden die relevanten Systemdaten gespeichert, so dass das Auftreten eines Netzausfalls während der Durchführung der Aufräum-Funktion 10 genauso behandelt wird, wie das Auftreten eines Netzausfalls bei der Durchführung der kritischen Software 3.

Betriebssystem-Ressourcen, wie beispielsweise Semaphoren oder Events, müssen die Information bereitstellen, ob sie zwischen dem Aufruf der Enter-Funktion 6 und dem Aufruf der Exit-Funktion 11 besetzt bzw. freigegeben wurden und von welcher Task, so dass genau diese Task in ihrer Aufräumroutine den Zustand wieder herstellen kann, der vor dem Aufruf der Enter-Funktion 6 vorlag.

Die unkritische Software 2 kann eine Befehlsfolge aufweisen, mittels welcher Vorarbeiten zur Abarbeitung der kritischen Software 3 oder zur Vorbereitung des Aufrufs der Enter-Funktion 6 durchgeführt werden. Die kritische Software 3 kann beispielsweise eine Befehlsfolge enthalten, mittels welcher Daten aus einem Eingangs-/Ausgangs-Chip (IO-Chip) gelesen werden. Mittels der Aufräum-Funktion 10 können beispielsweise unvollständige Daten aufgeräumt werden.

Die in 2 dargestellte Ausführungsform unterscheidet sich von der in 1 dargestellten Ausführungsform lediglich dadurch, dass innerhalb der kritischen Software 3 eine unkritische Befehlsfolge (konsistente Software) 3a angeordnet ist, welche vollständig durchlaufen werden muss, damit keine Inkonsistenzen entstehen. Um dies zu gewährleisten, ist vor der konsistenten Software 3a eine Disable-Enter-Funktion 13 angeordnet. Durch die Disable-Enter-Funktion 13 wird bewirkt, dass bei Beendigung eines Netzausfalls, der während der Abarbeitung der konsistenten Software 3a und somit innerhalb der Abarbeitung der kritischen Software 3 auftritt, nicht zum Wiederaufsetzpunkt 9 verzweigt wird. Solange die Disable-Enter-Funktion 13 aktiv ist, wird die konsistente Software 3a, da diese unkritisch ist und somit die betreffenden Systemdaten mittels der Interrupt-Service-Routine wieder restauriert werden, befehlsgranular fortgesetzt.

Nach Beendigung der konsistenten Software 3a wird eine Enable-Enter-Funktion 14 aufgerufen, welche die Disable-Enter-Funktion 13 wieder aufhebt. Im Anschluss an den Aufruf der Enable-Enter-Funktion 14 erfolgt eine Abfrage 15, ob während der Abarbeitung der konsistenten Software 3a ein Netzausfall aufgetreten ist. Ist dies der Fall, wird zum Wiederaufsetzpunkt 9 verzweigt und der Netzausfall wie zu 1 beschrieben behandelt. Ist während der Abarbeitung der konsistenten Software 3a kein Netzausfall aufgetreten, wird die Abarbeitung der kritischen Software 3 fortgesetzt.

Die kritische Software 3 kann beispielsweise einen Zugriff auf Hardware enthalten. Die konsistente Software 3a könnte dann beispielsweise eine Befehlsfolge zur Speicherverwaltung sein. Nach dem Durchlaufen der Abfrage 15, ob während der Abarbeitung der konsistenten Software 3a ein Netzausfall aufgetreten ist, könnten dann weitere Hardware-Zugriffe erfolgen.


Anspruch[de]
  1. Verfahren zur Wiederherstellung eines Betriebszustands eines Systems nach einer Unterbrechung des Betriebs, mit wenigstens einer unkritischen Befehlsfolge und wenigstens einer kritischen Befehlsfolge, welche abgearbeitet werden, wobei erste flüchtige Zustandsdaten beim Abarbeiten der unkritischen Befehlsfolge bei Eintritt der Unterbrechung gesichert werden und nach dem Ende der Unterbrechung wieder hergestellt werden und zweite flüchtige Zustandsdaten beim Abarbeiten der kritischen Befehlsfolge bei Eintritt der Unterbrechung nicht gesichert werden, wobei die zweiten flüchtigen Zustandsdaten zu Beginn der kritischen Befehlsfolge gesichert werden und die zweiten flüchtigen Zustandsdaten gegebenenfalls nach einer während der Abarbeitung der kritischen Befehlsfolge aufgetretenen Unterbrechung wieder hergestellt werden und die kritische Befehlsfolge nach dem Ende der Unterbrechung von Beginn an abgearbeitet wird, wobei vor der Abarbeitung der kritischen Befehlsfolge festgestellt wird, ob eine Unterbrechung vorlag, und im Falle einer Unterbrechung zunächst durch die kritische Befehlsfolge veränderte, nicht gesicherte Zustandsdaten an einen definierten Zustand angepasst werden.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Anpassung der nicht gesicherten Zustandsdaten als kritische Befehlsfolge behandelt wird.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass innerhalb der kritischen Befehlsfolge eine untergeordnete unkritische Befehlsfolge abgearbeitet wird, wobei beim Eintritt einer Unterbrechung während der Abarbeitung der untergeordneten unkritischen Befehlsfolge flüchtige Zustandsdaten gesichert und nach dem Ende der Unterbrechung wieder hergestellt werden sowie die Abarbeitung der untergeordneten unkritischen Befehlsfolge fortgesetzt wird.
Es folgen 2 Blatt Zeichnungen






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

  Patente PDF

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com