DE10040467A1 - Verfahren und Vorrichtung zur Koordinierung von Umschalt- und Ablösevorgängen zwischen Teilfunktionen - Google Patents

Abstract

Die Erfindung bezieht sich auf ein Verfahren und eine Vorrichtung zur Koordinierung von Umschalt- und Ablösevorgängen zwischen Teilfunktionen, die zusammen eine besserverfügbare Gesamtfunktionalität darstellen. Erfindungsgemäß wird von Beginn an die Umschaltung von wenigstens zwei Teilfunktionen unabhängig von deren tatsächlicher Gesamtaufgabe durchgeführt. Somit wird eine synchronisierte Ablösung der einen Funktion durch eine andere Funktion ermöglicht.

Description

In der Praxis besteht oft die Anforderung, die Verfügbarkeit von Funktionalitäten aus betriebstechnischen Gründen wie auch aus Gründen der Systemsicherheit zu erhöhen. Dies wird bei heutigen Systemen wegen deren hoher Komplexität in der Regel durch Redundierung der Funktionalität erzielt. In der Folge muss die Funktionalität in mehrere Teilfunktionen aufgeteilt werden, wobei sie entweder in sich ergänzende Anteile oder in einen dominanten und eine Anzahl überwachender Anteile zer­ legt werden kann. Mischformen innerhalb der Verteilungsstra­ tegie sind genauso üblich wie die parallele, doppelte Berech­ nung der Gesamtfunktionalität. Die Verteilung der Teilfunk­ tionen erfolgt innerhalb eines kapselnden Kommunikationsnetz­ werk, beispielsweise können die Teilfunktionen innerhalb ei­ ner Task, innerhalb eines Betriebssystems, auf einem Rechner, auf mehreren Rechnern mit einer Stromversorgung, auf mehreren Rechnern innerhalb eines unabhängigen Kommunikationsnetz­ werkes, u. v. m. ablaufen.

Unabhängig von der Zerlegung der Zielfunktion besteht das ei­ gentliche Redundanzproblem darin, dass man den nun verteil­ ten Funktionen ihren Arbeitsmodus einprägen muss. Dies soll mit mindestens ebenso hoher Verfügbarkeit geschehen, wie die Teilfunktionen selbst realisiert sind, d. h., dass die Redun­ dierung und Verteilung eines übergreifenden Zustandsautomaten für die Koordinierung der Ablösevorgänge durchzuführen ist, um die Synchronisation der Umschaltvorgänge in den Teilfunk­ tionen effizient, transparent und ohne zwischen-geschaltete Schichten ermöglichen zu können. Die Folge ist, dass Anteile des Zustandsautomaten genauso wie die Teilfunktionen über ein größeres kapselndes System verteilt sind und sich über die verbindenden Kommunikationsdienste abgeglichen bzw. synchro­ nisieren müssen.

Diese Problem wurde im Allgemeinen mit propietären Lösungen ohne übergreifendes Konzept gelöst. Die Redundanz wird in der Regel nachträglich in eine technische Lösung integriert. In der Folge werden Probleme, beispielsweise im Kontext des Da­ tenabgleichs zwischen den Applikationen durch sogenannte work-arounds propietär behoben, so dass ein anfangs transpa­ renter Ansatz mehr und mehr zur Spezialanwendung entartet. Die nachträgliche Redundierung von Systemen gelingt immer nur dann relativ problemlos, wenn es sich im weitgehend unabhän­ gige Syteme handelt. Man findet dann oft eine händische Um­ schaltung zwischen den Funktionen oder einen relativ rudimen­ tären Algorithmus für deren Aktivierung bzw. Koordinierung der Teilfunktionen. Eine solche Lösung erlaubt komplexes Zu­ sammenwirken zwischen den redundanten Funktionen nur noch eingeschränkt.

Ausgehend von der Beschreibung einer Master-Slave-Umschaltung für ein zentrales Steuergerät wird mit diesem Text eine all­ gemeinere Beschreibung für eine koordinierte Umschaltung zweier redundierter Funktionen, die sich jeweils in einem an­ deren Betriebsmodus befinden, vorgelegt.

Das betrachtete Szenario besteht aus redundant umschaltbaren Einheiten, beispielsweise einzelnen Geräten, die beide durch wenigstens ein Kommunikationssystem verbunden sind. Auf den Geräten laufen Instanzen desselben Funktionstyps ab. Die Funktion kann grundsätzlich ihre Aufgaben "aktiv", bzw. als "Master", oder "passiv", bzw. als "Slave", erfüllen. Im nor­ malen Betriebsfall, nach der Initialisierung und ohne Stö­ rung, ist eine Funktionsinstanz Master und die andere Slave. Der Slave läuft, sofern er verfügbar ist, als Teilnehmer der Kommunikation mit. Die Funktion im Slave-Zustand ist daher in der Lage, die Funktionsfähigkeit und Erreichbarkeit des Mas­ ter zu überwachen und bei Ausfällen oder Störungen selbst die Masterfunktionalität zu übernehmen, indem sie selbst in den Zustand des Masters wechselt. Dies setzt voraus, dass die an­ dere möglicherweise gestörte Funktion in den Slave-Zustand wechselt oder von der Kommunikation getrennt wird.

In den Fig. 1 bis 3 sind drei mögliche Umschaltungen darge­ stellt. Die Fig. 1 zeigt die Master-Slave-Umschaltung bei ei­ nem zentralen Steuergerät, die Fig. 2 zeigt eine Aktiv-Pas­ siv-Umschaltung bei einem Display und in der Fig. 3 ist eine abstrahierte verallgemeinernde Redundanzumschaltung veran­ schaulicht. Der Unterschied zu den Umschaltungen gemäß der Fig. 1 und 2 liegt darin, dass in der Ausführungsform gemäß der Fig. 3 nicht auf eine konkrete Ausführungsform der Kommu­ nikation Bezug genommen wird. In dieser abstrakten Sichtweise wird nur festgelegt, welche Auskünfte die Kommunikations­ dienste liefern müssen und welche Daten zwischen den Funk­ tionsinstanzen zur Realisierung der Umschaltung übertragen werden. Die Kommunikation kann dabei prinzipiell auch selbst redundant über mehrere Busse gleichzeitig erfolgen.

Die beiden Funktionsinstanzen umfassen die Funktionalität für Master- und Slave-Zustand sowie die Steuerung des Umschalt­ vorgangs. Daraus ergibt sich ein für die Funktionsinstanzen gleiches Verhalten. Unterschiede im Verhalten der Instanzen werden nur durch Berücksichtigung der Merkmale des jeweiligen Ablaufortes, z. B. Geräteadressen und andere Parameter festge­ legt. Im weiteren wird die jeweils andere Funktionsinstanz kurz als "Partner" bezeichnet, d. h. für Funktionsinstanz1 be­ zeichnet "Partner" die Funktionsinstanz2 und umgekehrt.

Das Redundanzkonzept kann sowohl für die Umschaltung der Ge­ räte insgesamt ("Geräteredundanz") verwendet werden als auch für eine "funktionsweise Redundanz", wie sie im weiteren be­ schrieben wird. Die Geräteredundanz ist dabei nur ein Fall der funktionsweisen Redundanz, indem die gesamte auf dem Ge­ rät ablaufende Funktionalität für die Umschaltung als eine einzige Funktion pro Gerät zu betrachten ist.

Das Ziel eines Redundanzkonzepts ist die Erhöhung der Verfüg­ barkeit (Fehlertoleranz) des Systems und damit die Verringe­ rung von Ausfällen der Funktionen. Die Fehleroffenbarung des Systems wird dadurch nicht erhöht, da nicht mehr Fehler er­ kannt werden als vorher.

Es gibt mehrere Ansätze, die Verfügbarkeit technischer Sys­ teme zu verbessern. Ein Weg besteht darin, ausgewählte An­ teile des Systems mehrfach, d. h. redundant auszuführen. Dabei muss unterschieden werden, ob die redundanten Funktionalitä­ ten unabhängig voneinander agieren können oder ob eine Syn­ chronisation der Abläufe sowie ggf. ein Abgleich der internen Zustände erfolgen müssen. Letzteres verkompliziert die Redun­ dierung in der Regel erheblich, so dass am Beginn einer Re­ dundanzdiskussion in jedem Falle die zweifelsfreie Klärung der Anforderungen stehen sollte.

Die Fig. 4 zeigt zunächst, wie durch die Redundierung von Hardware, beispielsweise für ein Ablaufumfeld, mit identi­ scher Software-Funktionalität eine höhere Verfügbarkeit er­ zielt werden kann. Auf diesem Wege gelingt es, den Ausfall eines der beiden Rechnersysteme mit hoher Wahrscheinlichkeit zu kompensieren.

Eine Abhängigkeit zwischen den redundierten Funktionen ist zunächst nicht zu erkennen. Fällt die eine Seite aus, über­ nimmt die andere ohne Vorkenntnisse nach einer gewissen Startverzögerung die Kontrolle. Systematische Fehler in der Software werden bei dieser Variante nicht berücksichtigt und haben in der Regel den Verlust der Gesamtfunktionalität zur Folge. Hier kann erst die typdiverse Realisierung der Funkti­ onalität selbst auf Basis einer detaillierten Spezifikation Abhilfe leisten.

Damit die beiden redundanten Funktionen bei deren Wirkungen nach außen, z. B. beim Schreiben auf gemeinsame Datensenken am Prozess, nicht kollidieren, wird eine der beiden als führend ausgezeichnet und die andere in einen alternativen Betriebs­ zustand, z. B. einen Standby-Modus, versetzt. Man spricht hierbei vom Master- und vom Slave-Zustand, wobei dies nicht bedeutet, dass der Slave keine oder nur niederpriore Aufgaben übernimmt. So kann, wie in Fig. 4 skizziert, beispielsweise die Überwachung des Kommunikationskanals zwischen den redun­ danten Funktionen und der Funktionstüchtigkeit des Redundanz­ partners von der Funktion im Slave-Zustand durchgeführt wer­ den. Sie kann dann - genauso wie der Master - bei Erkennen eines Mangels geeignete Maßnahmen bis hin zur Systemabschal­ tung einleiten. Auch ist es denkbar, dass sich Master- und Slave-Zustand bei identischer Funktionalität nur darin unter­ scheiden, wer von beiden welche Datensenken bedienen darf.

In der Fig. 5 hat die Kommunikationsschicht eine Rückwirkung auf die Zielfunktion, worin exemplarisch zum Ausdruck kommen soll, dass für die Erfüllung der Master- wie auch der Slave- Funktionalität u. U. die einwandfreie Funktion externer Kompo­ nenten vorausgesetzt werden muss. Der Einfachheit halber wird für diese Rückwirkung hier - wie an späteren Stellen auch - ein boolesches Signal eingeführt und mit einem Namen verse­ hen. Explizite Benennungen in den Bildern orientieren sich an weiter hinten beschriebenen Lösungsvarianten und werden an späterer Stelle näher erläutert.

Neben der konkreten Zielfunktion bedarf es zusätzlich noch einer Steuereinheit, die den redundierten Funktionen ihren jeweiligen Betriebszustand konsistent einprägt. Die Strate­ gie, die Übernahme der Master-Funktionalität angesichts eines erkannten Fehlers auf Initiative des Slave auszuführen, liegt zwar nahe, sollte jedoch aus zweierlei Gründen nicht verfolgt werden. Zum einen kann der Master - im besonderen bei dessen Fehlfunktion - von außen nicht zuverlässig dahingehend beein­ flusst werden, seine Aufgabe regulär zu beenden und vollstän­ dig an den Slave abzutreten. Hier besteht potentiell das Ri­ siko für den unerwünschten Master/Master-Zustand der Funk­ tion, bei dem beide Realisierungen versuchen, auf den Prozess u. U. konträr und damit fehlerhaft einzuwirken. Zum zweiten hat ein Fehlverhalten des Slave oder der Slave-nahen Kommuni­ kationsbestandteile zur Folge, dass der Master ohne Not abge­ schaltet wird und hiermit die Gesamtfunktionalität riskiert wird.

Diese Überlegungen lassen sich verallgemeinern und machen deutlich, dass jedwede Umschaltungsstrategie aus einer ein­ zelnen Funktion heraus - egal ob aus Master, Slave oder einer beliebigen externen Funktion - kritisch einzustufen ist, da diese keine angemessene Störfestigkeit besitzt und einen neuen Flaschenhals in Sachen Verfügbarkeit darstellt. Ange­ messen erscheinen auch hier die Redundierung der Umschalt­ funktion und deren Verteilung auf die zwei Plattformen in Form zweier möglichst unabhängige Funktionsinstanzen. Jetzt kann die Umschaltinstanz auch sehr eng an die Zielfunktion angebunden werden, wodurch eine sehr spezifische Fehlerin­ terpretaion für eine effiziente Umschaltstrategie möglich wird. Die Umschaltfunktionalität sollte wegen der zentralen und übergreifenden Bedeutung einmalig konzipiert, implemen­ tiert und als transparenter Dienst zur Verfügung gestellt werden.

Trotz dieses vielversprechenden Lösungsansatzes ist das Prob­ lem, dass die führende Funktion einer Umschaltaufforderung u. U. nicht mehr nachkommen kann und deshalb der Master/Mas­ ter-Konflikt auftreten kann, noch ungelöst. Der Ansatz, bei derartigem, unspezifischem Fehlerverhalten des Masters auf die Funktionsübernahme durch den Slave grundsätzlich zu ver­ zichten, ist zwar zuverlässig, führt jedoch die Redundierung der Funktion in vielen Fällen ad absurdum, da man zu einem großen Teil genau wegen dieser Fehler genötigt ist, Redundanz einzuführen. Der Wunsch nach Vermeidung des Master/Master- Konfliks bei gleichzeitig effizienter Fehlerkompensation durch Umschaltung auf ein redundantes System scheint nur ein­ geschränkt erfüllbar zu sein und erfordert die Diskussion des Master/Master-Konflikts bei der konkreten Anwendung.

Ein besser geeigneterer Ansatz besteht darin, den Master nach Ausbleiben seiner Umschaltung von seinem Umfeld zu isolieren, d. h. die Kommunikation mit seinen Datensenken zu unterbinden. Man vermeidet dadurch nicht den Master/Master-Konflikt son­ dern begrenzt seine Auswirkungen.

Die Fig. 6 zeigt die Einbettung der redundierten Zielfunktion in das Umfeld der Umschaltung, die aus den zwei verteilten Umschaltinstanzen und einer überwachten Kommunikation für den Austausch der inneren Zustände und die Synchronisation der Abläufe besteht.

Weiterhin kann man in dieser Fig. 6 eine bidirektionale Ver­ bindung erkennen, über die die Umschaltlogik der Zielfunktion eine bevorstehende Umschaltung ankündigt. Hiermit wird der Zielfunktion ermöglicht, den Umschaltvorgang aufhalten und kritische Operationen konsistent zu Ende bringen zu können. Erst nach Beendigung der Umschaltung in der Zielfunktion darf auch die Umschaltinstanz die Umschaltung logisch beenden und in einen stationären Zustand übergehen.

Aus den Anmerkungen im voranstehenden Beschreibungsteil zum abgeleiteten Funktionsprinzip einer Umschaltung können für einen minimalen Zustandsautomaten einer Umschaltinstanz erste Anforderungen bzw. Charakteristika abgeleitet werden:

Es gibt mindestens zwei stabile Arbeitszustände, in denen sich dieser Automat befinden kann, den Master- und den Slave- Zustand. Außerdem gibt es zwei Umschaltphasen, während der u. U. mehrere Zustände durchlaufen werden.

Der Erfindung liegt nun die Aufgabe zugrunde, ein Verfahren und eine Vorrichtung zur Koordinierung von Umschalt- und Ab­ lösevorgängen zwischen Teilfunktionen, die zusammen eine bes­ serverfügbare bzw. fehlersichere Gesamtfunktionalität dar­ stellen, anzugeben.

Erfindungsgemäß wird diese Aufgabe dadurch gelöst, dass von Beginn an die Umschaltung von mehreren Teilfunktionen unab­ hängig von deren tatsächlicher Gesamtaufgabe betrachtet wird. Die Gesamtfunktionalität bzw. die redundanten Teilfunktionen sind von untergeordneter Bedeutung.

Der erfindungsgemäße Ansatz ermöglicht die synchronisierte Ablösung der einen Funktion durch die andere bzw. den geord­ neten Tausch der Rollen. Die Umschaltung kann auf Funktiona­ litäten in Form von einzelnen Software-Applikationen angewen­ det werden, die als funktionsspezifische Instanziierung be­ zeichnet wird, jedoch auch auf eine komplette Hardware mit unterlagerten Software-Modulen, die als gerätespezifische Instanziierung bezeichnet wird. Das erfindungsgemäße Verfah­ ren kann bei allen Redundanzproblemen zielführend eingesetzt werden.

Als Vorrichtung zur Koordinierung von Umschalt- und Ablöse­ vorgängen zwischen Teilfunktionen, die zusammen eine besser­ verfügbare bzw. fehlersichere Gesamtfunktionalität darstellt, ist ein verteilter, applikationsnaher Zustandsautomat vorge­ sehen.

Zur weiteren Erläuterung der Erfindung wird auf die Zeichnung Bezug genommen, in der mehrere Ausführungen der erfindungs­ gemäßen Vorrichtung zur Koordinierung von Umschalt- und Ablö­ sevorgängen zwischen Teilfunktionen, die zusammen eine bes­ serverfügbare bzw. fehlersichere Gesamtfunktionalität darstel­ len, schematisch veranschaulicht sind.

Fig. 1 zeigt eine bekannte Master-Slave-Umschaltung bei einem zentralen Steuergerät, in der

Fig. 2 ist eine Aktiv-Passiv-Umschaltung bei einem Display veranschaulicht, die

Fig. 3 stellt eine abstrahierte Redundanzumschaltung dar, die

Fig. 4 zeigt die Redundierung von Hardware mit identischer Software-Funktionalität, in der

Fig. 5 ist eine vorteilhafte Ausführungsform der Ausfüh­ rungsform gemäß Fig. 4 dargestellt, wobei in der

Fig. 6 eine weitere Ausführungsform der Redundierung von Hardware gemäß Fig. 4 veranschaulicht ist, die

Fig. 7 zeigt ein Blockschaltbild einer erfindungsgemäßen Vorrichtung, wobei in der

Fig. 8 eine verbesserte Ausführungsform der Vorrichtung nach Fig. 7 dargestellt ist, die

Fig. 9 zeigt eine Struktur gemäß Fig. 6, die erfindungsge­ mäß erweitert worden ist, in der

Fig. 10 sind Signale, Ergebnisse und Aktionen einer Funktionsinstanz mit Umschaltung, Überwachung und Kommunikation dargestellt, die

Fig. 11 zeigt einen Zustandsgraphen für die Umschaltung des Funktionstyps, in der

Fig. 12 ist ein Szenario mit mehreren unabhängigen Funktionsinstanzen dargestellt, und in

Fig. 13 ist ein Zustandsgraph dargestellt, der Subzustände von Master- und Slave-Zustand des Graphen der Fig. 11 angibt.

In der Fig. 7 ist ein Blockschaltbild eines Zustandsautomaten näher dargestellt. Zunächst gibt es zwei Gründe, den Master- Zustand zu verlassen und eine Umschaltung einzuleiten: Zum einen kann dies eine erkannte innere Fehlfunktion oder das Fehlen einer wichtigen externen Voraussetzung, wie z. B. ein Schaden an einer externen Komponente, bewirken. Der Master ist unter diesen Umständen nicht mehr "Master-fähig". Unter der Voraussetzung, dass die Kommunikation zwischen den Um­ schaltinstanzen steht und die Partnerinstanz ihrerseits Mas­ ter-fähig ist, kann der zweite Grund eintreten, nämlich die gesteuerte externe Umschaltanforderung. Sie wird ausgelöst, um z. B. Loadbalancing zu realisieren oder die Master-Funktio­ nalität der redundanten Realisierung zu testen.

Nach Verstreichen der Dauer, die eine Nachricht zur Partner­ instanz benötigt, verzweigt der Automat aus dem Vorberei­ tungszustand in den Umschaltzustand , in dem die Um­ schaltanforderung an die Zielfunktion ausgegeben wird. Die Umschaltung kann jetzt nicht mehr aufgehalten werden. Nach der Quittung von Seiten der Zielfunktion schaltet der Automat in den stabilen Slave-Zustand .

Bei einer länger anhaltenden Störung der Partnerkommunikation verlässt der Automat den Slave-Zustand und meldet im nächsten Zustand zunächst seinen Umschaltwunsch an die Um­ schaltinstanz des Partners. Wird während einer Wartezeit keine Masteranforderung der des Partners und auch kein Funk­ tionsverlust in der eigenen Instanz erkannt, signalisiert der Automat im nächsten Schritt die nachfolgende, unbedingte Umschaltung an den Umschaltpartner. Anderenfalls kehrt der Automat zurück in den Slave-Zustand . Im Vorbereitungszu­ stand wird wieder für die Dauer einer Telegrammlaufzeit gewartet oder, wenn die andere Instanz in der Zwischenzeit in den Master-Zustand geschaltet haben sollte, in den Slave-Zu­ stand zurückverzweigt. Im regulären Folgeschritt wird der Umschalt-Request an die Zielfunktion ausgegeben und nach Vollzug in den Master-Zustand verzweigt.

In der Fig. 8 ist eine verbesserte Ausführungsform eines Zu­ standsautomaten näher dargestellt. Bei dieser Ausführungsform sind bereits mehr als die zwingend erforderlichen Kanten ein­ gezeichnet. Basierend auf der Strategie, den Master/Master- Zustand so unwahrscheinlich wie möglich zu machen, gibt es aus vielen Zuständen Wege vorzugsweise zurück zum Slave-Zu­ stand, jedoch nicht unkontrolliert hin zum Master-Zustand.

Um auf einen Master-Ausfall schneller reagieren, d. h. den Partner in den Masterzustand überführen zu können, bedarf es im Blockschaltbild des Zustandsautomaten gemäß Fig. 8 zusätz­ licher Transitionswege.

Zum einen wird jetzt versucht, schneller vom Slave- und den Masteranforderungszustand zu verzweigen, wenn bei ste­ hender Kommunikation der Partner entweder gestört oder sich nicht im Master-Zustand bzw. einem Master-Vorzustand befindet. Andererseits verzweigt der Master-Zustand bei erkanntem Mas­ ter/Master-Konflikt ohne weitere Verzögerungen durch einen Vorbereitungszustand in den Slave-Status.

In den Erläuterungen zur Fig. 7 werden externe Bedingungen für die Master-Fähigkeit einer Funktion angesprochen. Um diese Statussignale auf die Umschaltlogik aufschalten zu kön­ nen, bedarf es der Erweiterung der Fig. 5. Außerdem zeigen weitere Überlegungen, dass eine Voreinstellung der Umschalt­ logik bei Anlauf bzw. Abbruch der Kommunikation zwischen den Instanzen sinnvoll sein kann. Auch hierfür soll in der Struk­ tur der Fig. 5 ein zusätzlicher Eingang vorgehalten werden. Die Fig. 9 zeigt die erweiterten Strukturen.

Die Umschaltung gemäß dieser Fig. 9 verfügt jetzt zusätzlich über einen Eingang (M_Able), der die Master-Fähigkeit auf Ba­ sis diverser, funktionspezifischer externer Bedingungen, z. B. als Signal ExtOk, signalisiert. Die Verfügbarkeit der Funk­ tion selbst wird hiervon getrennt in die Umschaltinstanz ein­ gespeist (F_Ok) und kann von der Funktion sowie alternativ von einem externen Überwachungsdienst (Watchdog) bedient wer­ den. Die Umschaltung besitzt jetzt außerdem die Möglichkeit zur Voreinstellung des Automaten (Signal M_Dflt) und die Um­ schaltanforderung (z. B. als Signal M_Dwn). Ein interner Zu­ stand, der logisch aus den Fehlereingängen der Umschaltin­ stanz hervorgeht, kodiert die Master-Fähigkeit des Gesamtkom­ plexes und könnte für die Freischaltung der Kommunikation der Zielfunktion verwendet werden.

Die beschriebene Umschaltlogik kann funktionsspezifisch, d. h. mehrmals pro Gerät instanziiert werden oder auch gerätespezi­ fisch, d. h. nur einmal pro Gerät. Bei gerätespezifischer Ver­ wendung werden u. U. mehrere Zielfunktionen mit der zentralen Umschaltung verkettet und in der Folge der Umschaltvorgang von mehreren Zielfunktion beeinflusst bzw. verzögert. Die Freischaltung u. U. mehrerer Kommunikationskanäle aus dieser einen Umschaltinstanz gestaltet sich schwierig. Bei funkti­ osspezifischer Instanziierung kann ein globales Ereignis sehr wohl alle Instanzen dazu auffordern, eine Umschaltung der Zielfunktionen einzuleiten, doch laufen jetzt die Vorgänge asynchron und quasiparallel ab. Erst wenn alle Umschaltin­ stanzen den Vollzug melden, kann die Geräteumschaltung abge­ schlossen werden.

Die gefundene Redundanzrealisierung zeichnet sich durch fol­ gende Eigenschaften und Attribute aus:

• - Zunächst wird die einfache Redundierung unterstützt, wobei durch "hierarchische" Kaskadierung das Konzept auf Mehr­ fachredundanz aufgeweitet werden könnte. Alternativ kann durch Erweiterung des Zustandsgraphen und der Schnittstel­ len das Konzept auf "flache Mehrfachredundanz" erweitert werden.
• - Die Kommunikationsdienste liefern Informationen über die Erreichbarkeit des Partners (PComOk). Beim MVB wird dies über die Einbeziehung der Sinktime-Supervision erreicht. Bei TCP/IP-Kommunikation erfolgt dies in der Regel über eine Überwachung der Kommunikation auf Applikationsebene (z. B. als mitlaufendes "ping" oder die Übertragung dynami­ sierter Signale).
• - Eine als gestört erkannte Zielfunktion wechselt in den Slave-Zustand. Dieser Zustand bleibt bestehen, bis der Fehler behoben ist.
• - Die Umschaltung verfügt über Schnittstellen, über die ex­ terne Bedingungen für die Funktionstüchtigkeit der Ziel­ funktion eingebracht werden können.
• - Die Umschaltung übernimmt die komplette Ablaufsteuerung eines Umschaltvorgangs und stellt die relevanten Zustände in beiden Instanzen konsistent zur Verfügung.
• - Der Master/Master-Konflikt sollte auf Kosten eines kurz­ zeitigen Slave/Slave-Zustands vermieden werden. In der Re­ alität muss diese Forderung u. U. abgeschwächt werden. Die führende Instanz samt Zielfunktion schaltet im Idealfall immer zuerst in den Slave-Zustand oder wird von Überwa­ chungsmedien deaktiviert bevor die Partnerinstanz die Mas­ ter-Umschaltung startet.
• - Die Umschaltung kann auf der Seite der führenden Instanz von außen angestoßen werden. Die Umschaltung erfolgt nur, wenn die Slave-Instanz master-fähig ist.

Das Konzept berücksichtigt in dieser Fassung die Umschaltung nur zweier redundanter Funktionsinstanzen in zwei möglichen Betriebszuständen (ein "Master" und ein "Slave"). Dies sind die stabilen Zustände im normalen Betriebsfall, d. h. sie wer­ den nur bei einer expliziten Umschaltung/Abschaltung oder Fehlerfällen verlassen. Weiterhin gilt nur noch der Zustand "Abgeschaltet" als stabiler Zustand. Bei der Umschaltung der Funktionalität und bei Störungen kann eine Funktion noch meh­ rere Zwischenzustände durchlaufen, bis sie in einen anderen stabilen Zustand übergeht. Solche Zustände dienen dazu, die Umschaltung zwischen Master und Slave zwischen den verschie­ denen Funktionsinstanzen zu synchronisieren.

Zusätzlich zu den im vorigen Abschnitt genannten allgemeinen Eigenschaften werden die folgenden Voraussetzungen gemacht:

• - Eine Funktionsinstanz findet die jeweils andere eindeutig über die Identifikation der Ablauforte. Es ist keine wei­ tere Funktion oder separate Kommunikation für das Auffin­ den des Partners nötig, wie z. B. ein separater Nameserver. Beim zentralen Steuergerät mit MVB-Bus als Kommunikations­ system erfolgt diese Kommunikation beispielsweise über ge­ rätespezifische MVB-Ports. Bei Anzeigesystemen können über den MVB-Bus ebenfalls gerätespezifische Ports verwendet werden und über TCP/IP die IP-Adressen der Geräte und feste Portadressen.
• - Während des eigentlichen Funktionswechsels zwischen Mas­ ter- und Slave-Zuständen ist die Funktion für einige Zeit nicht über die Kommunikation erreichbar. Während dieser Zeit konfiguriert die Funktion ihre Kommunikation soweit um, dass sie anschließend in ihrem neuen Zustand voll er­ reichbar ist. Die Partnerbeziehung zwischen den beiden Funktionsinstanzen ändert sich dadurch nicht. Es muss aber im allgemeinen angenommen werden, dass die Kommunikation der beiden Instanzen während der Umschaltung zeitweise nicht möglich ist. Gegebenenfalls könnte auch noch eine weitere Instanz zur Überwachung dieses Umschaltvorgangs verwendet werden. Ein Beispiel für die Nichterreichbarkeit während einer Umschaltung ist bei der MVB-Kommunikation die Zeit für das Umladen der NSDB in einer Geräteanschal­ tung bzw. das Umschalten aller nötigen Ports, um im neuen Zustand voll kommunikationsfähig zu sein. Bei TCP/IP sind entsprechend Zeiten für den Verbindungsabbau und Aufbau und die nicht echtzeitfähige Übertragung zu berücksichti­ gen.
• - Es gibt eine Überwachung der Funktionsfähigkeit ("Funkti­ onsüberwachung") der einzelnen Funktionsinstanzen. Die Funktionsfähigkeit ist abfragbar, sowohl durch die Funkti­ onsinstanz selbst als auch durch den Partner, unter der Voraussetzung, dass die Kommunikation zu ihm funktioniert.
• - Zu der Funktionsüberwachung existiert auch noch eine Über­ wachung der Kommunikation zum jeweiligen Partner, siehe Fig. 9 bzw. Fig. 6.
• - Störungen des Systems und der Kommunikation können zu je­ dem beliebigen Zeitpunkt, d. h. in jedem beliebigen Zustand erfolgen. Die Störungen werden unterschieden nach:
  • - Störungen der Kommunikation zum Partner. Diese werden von Kommunikationsdiensten überwacht und den Funktionen mitgeteilt.
  • - Erkannte lokale Störungen der Funktionsinstanz, diese werden von der Überwachung erkannt und gemeldet.
  • - Störungen, die nicht erkannt werden oder temporäre Aus­ fälle, die von den Überwachungsdiensten nicht erkannt werden. Dies kann z. B. ein temporärer Ausfall von Kommu­ nikationshardware sein oder ein zu langes Verdrängen ei­ nes benötigen Prozesses bei Nicht-Echtzeit-Betriebssys­ temen.
• - Die Situation "Master-Master", d. h. beide Funktionsinstan­ zen befinden sich im Master-Zustand, gilt als kritisch aber nicht vollständig vermeidbar. Hier kann man wahlweise so verfahren, dass die Wahrscheinlichkeit für einen Mas­ ter-Master-Konflikt auf Kosten der Verfügbarkeit verrin­ gert wird oder umgekehrt.
• - Defekte Kommunikationsanschaltungen werden abgeschaltet und stören die Kommunikation anderer Teilnehmer nicht wei­ ter.
• - Für ein funktionsfähiges System wird ein Master benötigt. Eine Funktionsinstanz im Slave-Zustand muss versuchen, so schnell wie möglich in den Master-Zustand zu wechseln, wenn sie den Ausfall des Masters erkennt oder einen er­ folglosen Versuch des Partners, Master zu werden.
• - Zur Auflösung von Konflikten, die entstehen, wenn beide Funktionsinstanzen versuchen, in den Master-Zustand zu wechseln, existiert eine Vorgabe (z. B. ein "Default-Zu­ stand"), die jede Funktionsinstanz ermitteln kann. Die Vorgabe ist so definiert, das danach nur eine Funktionsin­ stanz Master wird und die andere Slave. Sie muss ohne zu­ sätzliche Kommunikation mit dem Partner ermittelbar sein.

Über die Kommunikationsschnittstelle wird folgende Informa­ tion übermittelt und abgefragt:

• - Funktionsüberwachung für jede Instanz einschließlich ihrer relevanten Hard- und Software, soweit möglich (z. B. Busan­ schaltungen, Treiber, relevante Prozesse und Threads, . . .).
• - Anforderungen und Synchronisationssignale für Zustands­ übergänge.
• - Statusinformation über die aktuellen Zustände der verfüg­ baren Instanzen.
• - Erreichbarkeit des Partners.

Weitere Schnittstellen werden durch Ereignisse und Aktionen definiert, die asynchron von der Funktion, der Umschaltung oder extern ausgelöst werden. Diese können, durch Signale re­ alisiert werden, müssen es jedoch nicht. Zusätzlich existie­ ren noch Zeitvorgaben für Reaktionen und Antworten verfügba­ rer Teilnehmer und die Erkennung von Ausfällen. Diese hängen von den jeweiligen Kommunikationssystemen und der Hard- und Softwareausstattung der Geräte ab, auf denen die Funktionsin­ stanzen ablaufen. Bei der Funktionsüberwachung und der Über­ wachung der Kommunikation, wird davon ausgegangen, dass diese lediglich boolesche Angaben liefert, ob die Funktion unge­ stört ist oder ob Kommunikation erfolgen kann. Wie diese An­ gaben selbst gewonnen werden, ist für die Umschaltung der Zu­ stände nicht relevant. Die Aussage "gestört" oder "nicht ge­ stört" kann dabei selbst wieder Ergebnis eines eigenen Kommu­ nikations- und Rechenvorgangs sein, der für den Umschaltvor­ gang nicht weiter betrachtet werden muss.

In Anlehnung an das Konzept des zentralen Steuergerätes wer­ den die folgenden Signale definiert, die jede Funktionsin­ stanz ihrem Partner liefert. Damit wird die oben beschriebene Schnittstelle in minimal nötiger Form realisiert. Die Defini­ tion der Schnittstelle erfolgt in der Form von Signalen, die von der Kommunikation übertragen werden und lokalen Signale. Es werden die folgenden Signale pro Funktionsinstanz benö­ tigt:

• - boolean M_Stat: "Master-State/Master-Zustand"
  Angabe, welchen Zustand diese Instanz aktuell hat; true bedeutet, dass ein Master-Zustand vorliegt; false bedeutet Slave-Zustand.
• - boolean M_Req: "Master-Request/Master-Anforderung"
  Wird true, wenn diese Instanz Master werden will und es noch nicht vollständig ist.
• - boolean M_Pre: "Pre-Master/Unmittelbar vor dem Übergang in den Master"
  Das Setzen von M_Pre ist die Bekanntmachung, dass die Funktionsinstanz unmittelbar im nächsten Schritt in den Master-Zustand übergehen wird. Da die Funktionsinstanz während der eigentlichen Umschaltung überhaupt nicht oder nicht vollständig erreichbar ist (weder als Master noch als Slave) wird dieses Signal benötigt, um der anderen Funktionsinstanz vorher mitzuteilen, dass diese Übergang nun erfolgen wird.

Damit erhält die andere Funktionsinstanz den Hinweis, dass die nun folgende Nicht-Erreichbarkeit des Partners die Folge einer Umschaltung ist.

• - Lokal: boolean F_Ok: "Function ok/Funktion nicht ge­ stört"
  Funktionsüberwachungsangabe für diese Funktion. Die Funk­ tionstüchtigkeit der Instanz wird überwacht. Im allge­ meinsten Fall durch eine weitere Funktion "Funktionsüber­ wachung", die unabhängig abläuft und das Ergebnis der Überprüfung signalisiert. Die Erkennung einer Störung kann so prinzipiell in jedem Zustand erfolgen und wird durch das Signal F_Ok angezeigt. Bei der Erkennung einer Störung wird F_Ok auf false gesetzt, solange bis die Störung er­ kennbar vorüber ist. Das Signal F_Ok ist für die Funkti­ onsinstanzen nur lesbar und es beinhaltet nicht die Er­ reichbarkeit anderer Kommunikationsteilnehmer bzw. das globale Funktionieren der Kommunikation.

Die Angabe der Funktionsüberwachung wird für die Master- Slave-Umschaltung nur lokal ausgewertet und nicht zum Partner übertragen. Wenn zusätzlich zur Master-Slave-Umschaltung noch ein konsistenter Abgleich von Daten zwischen beiden Funktionsinstanzen erfolgen soll, wird dieses Signal auch vom Partner benötigt und ist nicht mehr lokal.

• - Lokal: boolean M_Dflt: "Master-Default/Vorzugsmaster"
  Festlegung, ob diese Instanz der Funktion bei gleichen vorliegenden Master-Anforderungen Vorrang erhält.

Dieses Signal, das nur innerhalb der jeweiligen Ablauforte sichtbar ist und nicht übertragen wird, abstrahiert von der genauen Prozedur, mit der die vorrangige Masterfunktion be­ stimmt wird. Es wird lediglich vorausgesetzt, dass dieser Wert bei einer der beiden Funktionsinstanzen true und bei der anderen false ist. Diese Vorgabe kann auch durch unterschied­ liche Timeout-Einstellungen beim Setzen der Master-Anfor­ derung realisiert werden.

• - Lokal: boolean M_Able: "Able for Master/Prinzipiell in der Lage, die Masterfunktionalität zu übernehmen"
  Mit diesem Signal teilt die Funktionsinstanz der Umschal­ tung mit, ob sie alle nötigen Ressourcen hat, um die Mas­ terfunktionalität zu übernehmen.

Zu den Ressourcen zählen sowohl lokale Dienste, die ein Mas­ ter unbedingt benötigt, als auch die störungsfreie Kommunika­ tion mit anderen Funktionen bzw. Geräten, die ein Master un­ bedingt erreichen muss. Beispielsweise kann eine Display- Funktion so realisiert werden, dass sie dieses Signal nur dann setzt, wenn sie das Master-ZSG und den Diagnose-Master erreicht. Da die benötigten Ressourcen von der konkreten Funktion abhängen, muss sie das M_Able-Signal für die Um­ schaltung erzeugen.

Dieses Signal ersetzt nicht das Signal F_Ok. Es beinhaltet es auch nicht. Da M_Able von der potentiell gestörten Funktions­ instanz selbst berechnet wird ist dieses Signal bei einer ge­ störten Funktion möglicherweise auch nicht korrekt. Deshalb liefert immer nur die Und-Verknüpfung F_Ok && M_Able die re­ levante Aussage "die Funktionsinstanz ist bereit, Master zu werden" für den Umschaltvorgang. Dabei sollte diese Und-Ver­ knüpfung nicht innerhalb der (potentiell gestörten) Funktion stattfinden. Deshalb ist das Signal M_Able nur ein lokales Datum, das die Funktionsinstanz dem Umschaltvorgang liefert.

Das Signal M_Able ist wesentlich, um sicherzustellen, dass eine Funktion nur dann in den Masterzustand gelangt und dort bleibt, wenn sie alle nötigen Voraussetzungen hat, die Mas­ terfunktionalität zu erfüllen. Damit sollte auch ein Mas­ ter/Master-Konflikt vermieden werden.

• - boolean M_Rdy: "Ready for Master/Bereit die Masterfunk­ tion zu übernehmen"
  Mit diesem Signal wird angezeigt, dass die zugehörige Funktionsinstanz bereit ist, die Masterfunktionalität zu übernehmen. Das bedeutet, dass die Funktion nicht gestört ist und sich in der Lage befindet, Masterfunktionalität zu übernehmen. Dieses Signal wird als die Und-Verknüpfung F_Ok && M_Able definiert.
• - Lokal: boolean PComOk: "Erreichbarkeit des Partners"
  Angabe, ob die Kommunikation zwischen der Funktionsinstanz und ihrem Partner funktioniert. Diese Überwachung kann je nach Kommunikationssystem und Kommunikationstopologie ver­ schieden realisiert werden.

Zur Schreibweise

Aus der Sicht einer Funktionsinstanz werden die eigenen Sig­ nale direkt benannt, also mit PComOk, M_Stat, F_Ok, M_Req und M_Dflt. Die von der anderen Funktionsinstanz empfangenen Sig­ nale werden mit "p." gepräfixt, d. h. p.M_Stat, p.M_Rdy, p.M_Pre und p.M_Req. Diese Signale machen nur Sinn, wenn die Kommunikation erkennbar funktioniert, d. h. PComOk den Wert true hat.

Zu den globalen Einstellungen gehören die Timeout-Vorgaben für die kommunizierten Signale, die Umschaltvorgänge und die Erkennung von Ausfällen. Die konkreten Werte für diese Time­ outs sind anhand der verwendeten Kommunikation, Applikatio­ nen, Gerätehardware und Betriebssysteme zu bestimmen. Bei nicht echtzeitfähigen Kommunikations- und Betriebssystemen, können die Timeouts nur so angegeben werden, das die jewei­ lige Situation mit ausreichend hoher Wahrscheinlichkeit er­ kannt wird. Die für die Redundanzumschaltung nötigen Timeouts werden bei den Übergängen im Zustandsgraph als Argumente zu den Ereignisnamen angegeben.

Zu den oben genannten Signalen werden in der Fig. 10 auch noch Ereignisse und Aktionen definiert. Die Information die oben als Signale definiert wurde, muss prinzipiell immer vor­ liegen und abfragbar sein. Die Ereignisse und Aktionen werden dagegen nur jeweils einmal ausgelöst.

• - MSWechsel: Ereignis für die externe Aufforderung zu einem Master-Slave-Wechsel. Der jetzige Master soll Slave werden und der jetzige Slave soll Master werden. Im Gegensatz zu Umschaltung und EndeUmsch dient dieses Ereignis nicht zur Abstimmung zwischen der Umschaltlogik und der Funktion (Fig. 10).
• - Umschaltung(GewünschterZustand): Aktion mit der die Funktion und die damit verbundene Kommunikation zum Wech­ sel in den gewünschten Zustand (Master oder Slave) aufge­ fordert wird.
• - EndeUmsch: Mit diesem Ereignis signalisiert die Funktion, dass der mit der Aktion Umschaltung ausgelöste Vorgang be­ endet ist, d. h. die Funktion und Kommunikation wurde er­ folgreich umgeschaltet.

Es wird davon ausgegangen, dass nach dem Auslösen der Um­ schaltung entweder das Ereignis EndeUmsch kommt oder von der Funktionsüberwachung eine Störung erkannt wird.

Zunächst werden alle internen Zustände einer Funktionsinstanz angegeben. Diese sind das Produkt der Betriebszustände mit den für die Umschaltung relevanten Störfällen. Stabile Zu­ stände der Funktionen sind:

• - Abgeschaltet:
  Gerät/Funktionsinstanz ist außer Betrieb.

Stabile Zustände im Betriebsfall:
1. Slave:
Funktion ist im Slave-Zustand.
2. Master:
Funktion ist im Master-Zustand.
Übergangszustände im Betriebsfall:
3. Hochlauf:
In diesem Zustand erfolgt die Initialisierung nach dem An­ schalten und der Aufbau der von da ab festen Kommunikati­ onsbeziehung zum Partner.
4. UmschaltungMaster:
Wartezustand; die Funktion schaltet in den Master-Zustand um und kann während dieser Zeit nicht kommunizieren.
5. UmschaltungSlave:
Wartezustand; die Funktion schaltet in den Slave-Zustand um und kann während dieser Zeit nicht kommunizieren.
6. VorbereitungMaster:
Vorstufe vor dem Übergang in den Master-Zustand, Anzeige der Mastersignale zur Bekanntmachung der nachfolgenden Um­ schaltung in den Master-Zustand.
7. VorbereitungSlave:
Vorstufe vor dem Übergang in den Slave-Zustand, Anzeige der Slavesignale zur Bekanntmachung der nachfolgenden Um­ schaltung in den Slave-Zustand.
8. PartnerMAÜberwachung:
Die Funktion hat den Versuch des Partners erkannt, in den Master-Zustand zu wechseln und überwacht dies. Gegebenen­ falls wird bei erkanntem Fehlschlagen dieses Versuchs selbst sofort ein Übergang in der Master-Zustand versucht. Dies ist eine Optimierung, damit möglichst schnell ein Master verfügbar ist.

Parallel und unabhängig zu den obigen Zuständen (außer "Abge­ schaltet") geben die folgenden Zustände die korrekte Arbeits­ weise der Funktionsinstanz und der von ihr unbedingt benötig­ ten Dienste wieder.
1. Funktionstüchtig:
Es liegen tatsächlich keine relevanten Störungen vor.
2. FunktionAusgefallen:
Die Funktion ist gestört und die Funktionsüberwachung hat keine Störung der Funktion erkannt. Es ist möglich, dass die Störung geht, bevor sie erkannt wird und somit nur temporär zu Verzögerungen oder zu falsch gesetzten Signa­ len führt.
3. ErkannteStörung:
Die Funktion ist gestört und die Funktionsüberwachung hat eine Störung der Funktion erkannt.

In vielen Fällen sind Zustände "ErkannteStörung" während des laufenden Betriebs nicht sofort sicher feststellbar. Durch Beobachtung wird dann zunächst nur ein Zustand FunktionAusge­ fallen erkannt und ErkannteStörung erst durch ein explizites Abschalten der vermeintlich nicht funktionsfähigen Einheit festgestellt. Der Zustand FunktionAusgefallen kann aber auch durch Verletzung von Zeitlimits, Störungen der Kommunikation oder anderer temporärer Fehler erreicht werden, ohne das dies von der Funktionsüberwachung als Störung bemerkt wurde. Dann wird eine Rückkehr zum Zustand Funktionstüchtig erfolgen, insbesondere bei nicht echtzeitfähigen Systemen. Dies ist der Grund für die Einführung des Zwischenzustands FunktionAusge­ fallen.

Für die Funktionsinstanz ergeben sich die tatsächlich mögli­ chen Zustände eigentlich aus dem Produkt der obigen acht Zu­ stände mit den drei Zuständen für die Funktionstüchtigkeit. Da die Unterscheidung der acht Zustände im Betriebsfall nur für die den Zustand Funktionstüchtig interessant ist, werden diese als Hierarchie unter dem Zustand Funktionstüchtig zu­ sammengefaßt. Die formale Produktbildung hätte sonst einen Graphen mit fünfundzwanzig Zuständen zur Folge.

In den Zuständen werden jeweils die für die Umschaltung nöti­ gen Aktivitäten ausgeführt. Die Aktivitäten bestehen in allen Fällen aus dem korrekten Setzen der eigenen Signale, um dem Partner den eigenen Zustand und beabsichtigte Zustandsände­ rungen mitzuteilen sowie aus den nötigen Umschalt- und Initi­ alisierungsaktivitäten, die lokal für die Funktionsinstanz wirken.

Die Übergänge zwischen den Zuständen werden durch Ereignisse ausgelöst. Viele Übergänge sind dabei zusätzlich an Bedingun­ gen geknüpft, die anhand der Signale der Funktionsinstanz, der Kommunikation und des Partners definiert werden.

Die Ereignisse, die zu Zustandsübergängen führen, können durch das Ende von Aktivitäten, durch die Veränderung von Signalzuständen und durch Zeitbedingungen ausgelöst werden. Die Namen der Ereignisse, die durch die Veränderung von Sig­ nalzuständen heißen Trg (für "Trigger"). Wenn diese Signalzu­ stände für eine bestimmte Zeitdauer eintreten müssen, wird diese Zeit als Argument angegeben.

Erläuterungen zu Ereignisnamen:

• - Allgemein: Trg(t)[Bedingung] Ereignis, wenn für die Zeit t die Bedingung erfüllt wird. Für t = 0 bedeutet das, dass das Ereignis beim Eintreten der Bedingung sofort ausgelöst wird.
• - EndeUmsch:
  Die Funktion (und ihre Kommunikation) wurde vollständig für den Zustandswechsel umgestellt, siehe auch Abschnitt.
• - MSWechsel:
  Externes Ereignis, das beide Funktionsinstanzen auffor­ dert, Master- und Slave-Zustände zu tauschen, sofern mög­ lich, siehe auch Abschnitt.
• - Störung:
  Erkennung einer Störung durch die Funktionsüberwachung, als Aktion wird dabei das F_Ok-Signal auf false gesetzt.

Die verschiedenen Zeitparameter t_stat, t_anf und t_nok geben die Bedeutung der verschiedenen Timeouts an:

• - t_stat für das Erkennen eines Statuswechsels bei Partner.
• - t_anf für die Zeitdauer, die eine Funktion mit Master-An­ forderung warten muss, bis sie in den Zustand Vorberei­ tungMaster übergeht oder bis sie den Versuch abbricht, Master zu werden.
• - t_nok für die Zeitdauer, nach der der Partner als gestört angesehen wird.

Die in einer Realisierung tatsächlich gewählten Zeitdauern können bei Bedarf auch für dasselbe Auftreten eines Parame­ ters geringfügig unterschiedlich gewählt werden. So ist es bei einigen Implementierungen des Graphen sinnvoll, t_anf beim Zustandsübergang SlaveMitMasterAnforderung nach Funk­ tion(Slave) geringfügig größer zu wählen als den Wert für t_anf beim Zustandsübergang SlaveMitMasterAnforderung nach VorbereitungMaster, um diesem eindeutig Vorrang zugeben. Bei den Zustandsübergängen von VorbereitungMaster nach Umschal­ tungMaster und von VorbereitungSlave nach UmschaltungSlave wird im Graphen der Fig. 11 ein Timeout t_trans abgewartet, bis der Partner die Nachricht erhalten hat. Wenn bei einer speziellen Realisierung die Kommunikation zum Partner quit­ tierend erfolgt, ist es sinnvoller, anstelle eines Timeouts das Eintreffen der Quittung als Ereignis abzuwarten.

In der Hochlaufphase baut eine Funktionsinstanz zunächst die Kommunikation zum Partner auf und geht dann in den Slave-Zu­ stand über. Danach kann die Funktionsinstanz im Slavezustand selbst erkennen, ob sie Master werden muss und es kann - die­ ses Verhalten unterscheidet sich dann nicht mehr vom Verhal­ ten des Slaves im Betrieb. Der Slave-Zustand und der zugehö­ rige Zustand PartnerMAÜberwachung können nur verlassen wer­ den, wenn keine Störungen der Funktionsinstanz vorliegen. Eine Funktionsinstanz im Slave-Zustand kann selbst versuchen, Master zu werden, indem sie in den Zustand SlaveMitMasterAnf wechselt. Gründe dafür sind:

• - Eine Störung des Partners wurde erkannt.
• - Der Partner ist über die Kommunikation nicht erreichbar.
• - Der Partner ist nicht Master und versucht derzeit auch nicht es zu werden oder er versucht Master zu werden und hat dabei keinen Vorrang.

Wenn eine dieser Bedingungen eine vorgegebene Zeitdauer lang erkannt wird, geht die Instanz in den Zustand SlaveMitMaste­ rAnf über. Wenn die Funktionsinstanz im Slave-Zustand eine Master-Anforderung des Partners bemerkt, geht sie in den Zu­ stand PartnerMAÜberwachung über. Aus diesem Zustand kehrt sie wieder in den Slave-Zustand zurück, wenn sie erkennt, dass der Partner Master ist oder wird. Dies wird durch das Setzen des Master- oder Pre-Master-Signals des Partners erkannt. Da­ mit hat der Partner angezeigt, dass er sich nun im Zustand VorbereitungMaster befindet und im nächsten Schritt die Um­ schaltung in den Master-Zustand durchführen wird. Wenn jedoch eine solche Anzeige des Partners nach einer Timeoutzeit nicht vorliegt, muss die Funktionsinstanz davon ausgehen, dass der Versuch des Partners fehlgeschlagen ist, in den Master-Zu­ stand zu gelangen. Daraufhin versucht die Funktionsinstanz selber Master zu werden und geht vom Zustand PartnerMAÜberwa­ chung in den Zustand SlaveMitMasterAnf über, wenn sie selbst nicht gestört ist.

Im Zustand SlaveMitMasterAnf setzt die Funktionsinstanz selbst ihre Master-Anforderung. Wenn sie für eine bestimme Zeitdauer erkennt, dass der Partner nicht Master ist und auch keine vorrangige Master-Anforderung hat, geht sie in den Zu­ stand VorbereitungMaster über. Wenn sie aber eine Störung bei sich erkennt oder bemerkt, dass der Partner Master ist oder eine vorrangige Master-Anforderung hat, kehrt sie in den Slave-Zustand zurück. Im Zustand VorbereitungMaster setzt die Funktionsinstanz das Pre-Master-Signal und verweilt dort eine vorgegebene Zeitdauer, um dem Partner mitzuteilen, dass sie nun Master wird. Diese Signalisierung dient dazu den Übergang zum Master-Zustand besser abzusichern, da im nächsten Schritt die Umschaltung der Kommunikation erfolgt und die Funktions­ instanz eine Zeitlang nicht erreichbar ist. Wenn in diesem Zustand aber noch bemerkt wird, dass der Partner selbst das Master-Signal setzt, kehrt sie in den Slave-Zustand zurück, um einen Master-Master-Konflikt zu vermeiden. Im Normalfall (ohne Konflikt) geht die Funktionsinstanz durch den Zustand UmschaltungMaster, in dem keine Kommunikation möglich ist, in den Master-Zustand über, in dem sie dann als Master läuft und wieder kommunizieren kann.

Der Master-Zustand wird von der nicht gestörten Funktionsin­ stanz verlassen, wenn der Partner (der dann ja Master werden muss) erkennbar funktioniert und einer der folgenden Fälle eintritt:

• - Der Partner hat sein Master-Signal gesetzt und hat Vor­ rang.
  In dieser Konfliktsituation muss die Funktionsinstanz selbst Slave werden.
• - Der Partner hat Pre-Master-Signal gesetzt.
  Damit ist der Partner in den Zustand VorbereitungMaster gelangt. Unabhängig davon, ob die Funktionsinstanz selbst Vorrang hat, muss in den Slave-Zustand gewechselt werden, da ein Master-Master-Konflikt unmittelbar bevorsteht. Mög­ licherweise konnte der Partner den Master-Zustand dieser Funktion nicht erkennen und er wird den Konflikt nicht auflösen.
• - Der Partner hat sein Master-Signal gesetzt (und hat nicht Vorrang), läßt das Signal aber für eine Zeitdauer stehen. Es wird davon ausgegangen, dass der Partner nicht in der Lage ist, den Konflikt zu erkennen, denn sonst hätte er sein Master-Signal zurücknehmen müssen. (Möglicherweise ist die Kommunikation nur teilweise funktionstüchtig.) Deshalb wird nun selbst in den Slave-Zustand gewechselt, da davon ausgegangen wird, dass der Partner den Konflikt nicht aufzulösen kann.
• - Eine externe Aufforderung zum Master-Wechsel legt vor.

In diesen Fällen wird die Umschaltung in den Slave-Zustand eingeleitet, mit den entsprechenden Zwischenzuständen, analog zur Umschaltung in den Master-Zustand. Bei einer externen Aufforderung zum Master-Wechsel wird dem Partner der Wechsel zum Slave erst mitgeteilt, in den anderen Fällen wird davon ausgegangen, dass der Partner diese Mitteilung nicht benötigt und direkt in den Zustand UmschaltungSlave wechselt.

Der Zustand Funktionstüchtig kann durch Ausfälle, Störungen oder Abschalten in jedem seiner Subzustände verlassen werden. Im Fall einer erkannten Störung wird ein Übergang in den Slave-Zustand eingeleitet. Wenn die Instanz zuvor bereits Slave war, geht sie direkt in den Slave-Zustand über. Andern­ falls wird erst durch den Übergang in den Zustand "Vorberei­ tungSlave" dem Partner das Umschalten signalisiert, so dass dieser schon vor der Umschaltung der Kommunikation erkennt, dass er selber Master werden muss. Bei einem Ausfall gibt es die Möglichkeit, dass dieser als Störung erkannt wird, was zum Übergang in den Zustand ErkannteStörung führt und die oben beschriebene Abfolge nach sich zieht. Wenn die Störung geht, bevor sie erkannt werden konnte, wird in den letzten aktiven Subzustand zurückgesprungen, aus dem der Zustand Funktionstüchtig verlassen wurde (dargestellt durch den Über­ gang in den Zustand H).

Aus der Beschreibung des Zustandsgraphen ergeben sich auch die folgenden Eigenschaften:

• - Ein Master-Master-Konflikt wird nicht prinzipiell verhin­ dert.
• - Wenn ein Master-Master-Konflikt erkannt wird, wird sofort in ein Master-Slave-Zustandspaar übergegangen, indem eine Instanz in den Slave-Zustand gebracht wird.
• - Eine Funktionsinstanz, die nicht Default-Master ist, wird Master, wenn der Default-Master zu lange nicht erreichbar ist (z. B. spätes Einschalten).
• - Allgemein hat eine Störung der Kommunikation bei zwei an­ sonsten funktionsfähigen Instanzen die Ausbildung zweier Master zur Folge.
• - Es wird nicht zwischen der Situation "eigener Sender ge­ stört" und "Empfang beim Partner gestört" unterschieden. Eine solche Unterscheidung könnte nur mit Hilfe anderer Kommunikationsteilnehmer unter Einbeziehung der Eigen­ schaften der Kommunikationssysteme und der Bustopologie geschehen. Wenn diese Fälle unterschieden werden, sollte die Situation "eigener Sender gestört" von der Funktions­ überwachung als Störung erkannt werden und damit der Über­ gang in den Zustand ErkannteStörung zur Folge haben.

Der Zustandsgraph nach Fig. 11 realisiert eine Strategie, die so bezeichnet werden kann:
"Versuche bei anhaltender Kommunikationsstörung zum Partner Master zu werden". Eine mögliche Alternative zum Vorgehen des Zustandsgraphen nach Fig. 11 besteht darin, bei Erkennung ei­ ner Kommunikationsstörung anhand der M_Dflt-Vorgabe zu ver­ fahren und somit eine Funktionsinstanz sicher in den Slave- Zustand zu bringen. Diese Strategie kann man kurz mit "Über­ gang in Default-Zustand bei anhaltender Kommunikationsstö­ rung" bezeichnen. Dadurch würde die Ausbildung zweier Master bei einer Kommunikationsstörung verhindert. Dafür kann aber in dem Fall, dass sowohl Kommunikation als auch Default-Mas­ ter gestört sind, der Default-Slave nicht mehr in den Master- Zustand gelangen. Für diese Alternative ist der Zustandsgraph in der Fig. 11 so zu modifizieren:

• 1. Übergang von Slave in SlaveMitMasterAnf mit Ereignis Trg(t_stat)[M_Rdy &&!PComOk] entfernen. Damit wurde er­ reicht, dass jede Funktionsinstanz im Slave-Zustand bei Kommunikationsstörung versucht, in den Master-Zustand zu gelangen.
• 2. Übergang von Slave in UmschaltungMaster mit Ereignis Trg(t_nok)[M_Rdy &&!PComOk && M_Dflt] hinzufügen. Damit wird der Default-Master im Fall der Kommunikationsstörung in den Master-Zustand gebracht.
• 3. Übergang von Master in UmschaltungSlave mit Ereignis Trg(t_nok)[!PComOk &&!M_Dflt) hinzufügen. Damit wird ein Nicht-Default-Master im Fall der Kommunikationsstörung in den Slave-Zustand gebracht.

Im allgemeinen hat dieses alternative Vorgehen eine geringere Verfügbarkeit zur Folge, da bei einer Kommunikationsstörung und einem ausgefallenem Default-Master keine Masterfunktiona­ lität mehr zur Verfügung steht. Daher ist es besser, das ur­ sprüngliche Vorgehen "Versuche bei anhaltender Kommunika­ tionsstörung Master zu werden" durch eine möglichst genaue Definition von M_Able einzuschränken. D. h. unabhängig von einer funktionierenden Partnerkommunikation sollte M_Able möglichst so genau definiert werden, dass zu jedem Zeitpunkt höchstens eine Funktionsinstanz Master werden kann oder zumindest so, dass die Wahrscheinlichkeit für ein gleich­ zeitiges M_Able beider Funktionsinstanzen möglichst gering ist.

Wie einleitend erwähnt, kann das Konzept sowohl für Master- Slave-Umschaltung eines gesamten Geräts als auch für die Um­ schaltung mehrerer voneinander unabhängiger Funktionen auf demselben Gerät eingesetzt werden.

Die Zustandswechsel einer Funktion zwischen Master- und Slave-Zuständen bedingen in nahezu allen Fällen auch eine Um­ schaltung der Kommunikationsbeziehungen: Eine Instanz, die in den Master-Zustand wechselt, muss ihre Kommunikation so um­ stellen, dass sie als Master erreichbar ist und allen anderen Kommunikationsteilnehmern die Daten liefert, die von einem Master erwartet werden. Daher ist eine dynamische Umschaltung der Kommunikationsbeziehungen einzelner Funktionsinstanzen auf demselben Gerät unabhängig voneinander nötig, wenn das Konzept funktionsweise angewandt werden soll.

Bei der TCN-Kommunikation ist diese Möglichkeit für Prozess­ variablen auf vielen Plattformen gegeben: Dort kann die Lese- und Schreibrichtung einzelner Ports dynamisch umgeschaltet werden. Damit kann jede Funktionsinstanz ihre eigene Umschal­ tung haben, die den Zustand der Funktion unabhängig und asyn­ chron zu den anderen Funktionen des Geräts umschalten kann. Ein Beispiel wird in der Fig. 12 gezeigt. Dort werden zwei redundante Funktionsinstanzen (Nr. 1 und 2) pro Gerät unab­ hängig voneinander und von unabhängig von weiteren Funktionen (Nr. 3 und 4) umgeschaltet. Dementsprechend ist die Umschalt­ logik, die den Zustandsgraphen der Fig. 10 realisiert, auch zweimal pro Gerät vorhanden: Einmal für die Instanz von Funk­ tion1 und einmal für Instanz von Funktion2. Die Umschaltlogi­ ken kommunizieren über die voran beschriebenen Signale mit­ einander. Dieser Teil der Kommunikation, in Fig. 12 als MSPorts bezeichnet, ist statisch und ändert sich bei einer Umschaltung nicht. Die Instanzen von Funktion1 bzw. Funktion2 können bei Zustandswechseln ihre Kommunikationsbeziehungen portweise umschalten: Die Schreibrichtungen von PortlM bzw. Port2M und Port2S werden bei den Umschaltungen nur für die Ports der umgeschalteten Funktion verändert. Damit kann Funk­ tion1 bzw. Funktion2 unabhängig von den anderen Funktionen eine Master-Slave-Umschaltung durchführen.

Voraussetzung an die Projektierung des Busses ist hierbei, dass die umzuschaltenden Ports den Funktionen pro Gerät ein­ deutig zugeordnet sind. D. h. ein Port, der wegen eines Zu­ standswechsels dynamisch umgeschaltet werden muss, darf nicht von zwei Funktionen gleichzeitig benutzt werden, wenn diese unabhängig voneinander umschaltbar sein sollen. Beispiels­ weise dürfen in Fig. 12 die Instanzen von Funktion1 nicht auf die Daten der zustandsabhängigen Ports der Instanzen von Funktion2 zugreifen (Port2M und Port2S).

Für TCN-Messages existiert in der derzeitigen Realisierung eine Umschaltmöglichkeit der Kommunikation nur geräteweise:

Da bei der Message-Adressierung die TCN-Teilnehmeradresse des Message-Empfängers (Servers) verwendet wird, kann eine Um­ schaltung der Message-Kommunikation nur geräteweise erfolgen - in der Regel durch Reinitialisierung der Busanschaltung des Geräts wobei die Teilnehmeradresse neu eingestellt wird. Bei dem Szenario der Fig. 12 könnten nur alle TCN-Funktionsadres­ sen für Hardware1 gleichzeitig umgeschaltet werden, d. h. für die Instanzen von Funktion1, Funktion2 und Funktion3 zusam­ men. Damit können die Instanzen von Funktion1 und Funktion2 ihre Messagekommunikation nicht mehr unabhängig voneinander umschalten. In diesem Fall kann nur Geräteredundanz reali­ siert werden.

Eine Beseitigung dieser heutigen Einschränkung ist durch die Änderung der lokalen Functiondirectories zur Laufzeit bei den MVB-Teilnehmern und beim Gateway bzw. durch ein Routen der Funktionsaufrufe über das Gateway denkbar. Diese Mechanismen sind aber nicht einfach zu realisieren.

Es kann der Bedarf bestehen, die Funktionsinstanzen in ihren Master- und Slave-Zuständen "einzufrieren", so dass sie nicht mehr auf Signale reagieren und Umschaltvorgänge durchführen. Diese Erweiterung kann dadurch vorgenommen werden, indem ein weiteres boolesches Signal F_MSDisable eingeführt wird, für dessen Dauer die Umschaltung verhindert wird. Die Negation dieses Signals wird mit allen Bedingungen, die aus Master- und Slave-Zuständen herausführen, Und-verknüpft. Ein solches Einfrieren von Zuständen kann beispielsweise zur Unterstüt­ zung von Inbetriebsetzung und Test sinnvoll sein.

In vielen Fällen ist eine Synchronisation der Master-Slave- Umschaltung mit einem Abgleich von Daten oder anderen Zustän­ den von Master und Slave nötig. Dies können sowohl persis­ tente Datenhaltungen, wie z. B. Archive für Meldungen oder Diagnoseereignisse sein, als auch transiente Daten, wie z. B. die Liste der anzeigten Meldungen in einem Meldefenster des B Im ersten Fall ist bei einer Umschaltung die Speicherung der Daten in Dateien oder Datenbanken zu abzu­ gleichen, so dass der Archivstand des neuen Masters nach er­ folgter Umschaltung dem des vorherigen Masters entspricht. Im zweiten Fall müssen die Anzeigestände in den Fenstern abge­ glichen werden, so dass nach der Umschaltung die Fenster des neuen aktiven Displays denselben Stand von Meldungen anzei­ gen, wie die des vorher aktiven Displays. Synchronisieren be­ deutet dabei, dass für den Umschaltvorgang definiert werden muss, unter welchen weiteren Bedingungen die Umschaltung er­ folgen darf und an welchen Stellen des Zustandsgraphen Master und Slave zwingend abgeglichen sein müssen.

Dieses Verhalten wird durch den Zustandsgraphen der Fig. 13 beschrieben, der Subzustände von Master- und Slave-Zustand des Graphen der Fig. 11 angibt. Dabei wird anhand zweier Sig­ nale, die die Konsistenz der Daten zwischen Master und Slave beschreiben, eine Umschaltung verzögert, bis die nötigen Ab­ gleichvorgänge ausgeführt werden konnten. Erkennbar ist dies in der Fig. 13 an den Start- und Endzuständen. Bei Eintritt in die dort gezeigten Subzustände werden zunächst Abgleichvor­ gänge ausgeführt oder störungsbedingte Inkonsistenzen er­ kannt. Ein Austritt aus der Subzustandsfolge über den Endzu­ stand ist nur im abgeglichenen Zustand möglich.

Signale zum Abgleich, pro Funktionsinstanz:

• - boolean FFCons: "Function-Function consistent/Funktions­ instanzen konsistent"
  Die Stände der beiden Funktionsinstanzen sind konsistent, es ist kein Abgleich nötig.
• - boolean FFBack: "Function-Function back/Funktionsinstanz zurück"
  Der Stand dieser Instanz liegt hinter der anderen zurück.

Es wird offen gelassen, ob diese Signale lokal sind, zwischen den Instanzen kommuniziert werden oder global sind, d. h. von einer zentralen Instanz an beide Partner kommuniziert werden.

Außerdem werden die folgenden Signale benötigt, die bereits für die Umschaltung definiert wurden, siehe Abschnitt:

• - Lokal: boolean FFOk: Die funktionierende Datenaustausch zum Partner ist notwendige Bedingung für die konsistente Ausführung von Aktionen in beiden Instanzen und Abgleich­ vorgänge.
• - boolean F_Ok: Für die Umschaltung reichte es aus, wenn die Signale der Funktionsüberwachung nur lokal verfügbar wa­ ren. Für den Abgleich müssen die Signale auch über die Kommunikation übertragen werden, da für den Abgleich nur die Funktionsfähigkeit des Partners relevant ist und nicht nur seine Fähigkeit, Master zu werden, wie beim Umschalt­ vorgang. Dieses Signal ist, wie PComOk, eine notwendige Bedingung für Konsistenz und Abgleich.

Die obigen Angaben können beispielsweise so realisiert wer­ den, dass FFCons und FFBack den Stand der bereits geschriebe­ nen Daten wiedergibt. Generell besteht die Möglichkeit der Verlagerung des Abgleichvorgangs in die Funktion selbst, so dass diese im Hinblick auf die Umschaltung immer abgeglichen erscheint. In diesem Fall hat aber die Funktion selbst dafür zu sorgen, dass ihre Daten ohne Verzögerung über den Um­ schaltvorgang hinweg konsistent auf beiden Rechnern vorlie­ gen.

Eine Realisierung des in dargestellten Graphen hat die fol­ genden Konsequenzen für den Umschaltvorgang:

• - Verzögerung einer Umschaltung, die explizit veranlaßt wurde, bis ein vollständiger Datenabgleich erfolgt ist.
• - Verzögerung einer Umschaltung, wenn ein Abgleich nötig ist und keine Störung vorliegt.
• - Der Graph der Fig. 13 beschreibt nur eine allgemeine, mi­ nimale Lösung. Bei konkreten Anforderungen an Umschaltzei­ ten, Konsistenz, Vollständigkeit und Sicherheit der Daten­ haltung ist zu prüfen, ob dieser eine Lösung darstellt oder ob die Anforderungen überhaupt erfüllbar sind.

Die Verlagerung des Abgleichvorgangs in die Funktion selbst kann eine Lösung sein, wenn die Sicherheit und Vollständig­ keit der Datenhaltung nicht im Vordergrund steht.

Derzeit sinnvolle Erweiterungsmöglichkeiten des Konzeptes sind an den folgenden Stellen erkennbar:

• - Sicherung bei temporären Ausfällen durch Übergänge in de­ finierte Zustände.
• - Erkennung und Verhinderung von Buskonflikten.
• - Genaue Abbildung des Konzepts auf TCP-Kommunikation.
• - Allgemeines Konzept zur Überwachung. Definition allgemei­ ner Schnittstellen für Überwachung und Umschaltung.

Die Erweiterungen werden bei Bedarf als Ergänzungen zur Be­ schreibung der Zustandsgraphen aufgenommen in nachfolgenden Versionen dieses Dokumentes definiert.

Im folgenden werden die Signale des Konzeptes des zentralen Steuergerätes und des erfindungsgemäßen Redundanzkonzeptes ge­ genübergestellt. Diese Signale sind unterteilt in Bussignale und lokale Signale.

Bussignale

lokale Signale

Das Konzept des zentralen Steuergerätes unterscheidet sich vom erfindungsgemäßen Redundanzkonzept in folgenden Punkten:

• - Der Zustand PartnerMAÜberwachung und die mit ihm verbunde­ nen Übergänge sind bei der ZSG-Umsetzung nicht vorhanden. Beim ZSG-Konzept wird davon ausgegangen, dass keine ungül­ tigen Signale gesendet werden. Ist der Partner noch kommu­ nikationsfähig, so wird er die Master-Anforderung bei er­ kanntem Fehler zurückziehen. Eine zeitliche Überwachung des Master-Anforderungssignals vom Partner mit Timeout ist deshalb nicht notwendig.
• - Übergang von SlaveMitMasterAnf nach VorbereitungMaster: bei der ZSG-Umsetzung kann nur dann in den Zustand Vorbe­ reitungMaster gewechselt werden, wenn die Partner-Master­ anforderung nicht gesetzt ist, d. h. der Nicht-Defaultmas­ ter muss seine Masteranforderung erst zurückziehen. Bei dem Redundanzkonzept darf der Defaultmaster trotz gesetz­ ter Partner-Masteranforderung in den Zustand Vorbereitung- Master übergehen. Der Übergang lautet bei der Umsetzung des Konzeptes zentrales Steuergerät Trg(t_anf)[M_Rdy && (PComOk && (p.M_Stat || p.M Req))].

Der Zustand FunktionAusgefallen ist beim Konzept zentrales Steuergerät praktisch nicht vorhanden. Treten beim Konzept zentrales Steuergerät Fehler auf (z. B. Ausfall der Kommunika­ tionsbaugruppe, Zeitscheibenüberlauf, . . .), so werden diese aufgrund der Systemkonzeption (Echtzeit-Betriebssystem, Watchdogs) auch erkannt. Im Fehlerfall wird somit nach Er­ kannteStörung übergegangen. Anschließend wird abgeschaltet oder ein Reset ausgelöst. Die Übergänge von ErkannteStörung nach Funktion (Slave) bzw. VorbereitungSlave sind somit für das ZSG praktisch nicht relevant.

Claims (4)

1. Verfahren zur Koordinierung von Umschalt- und Ablösevor­ gängen zwischen wenigstens zwei Teilfunktionen, die zusammen eine besserverfügbare Gesamtfunktionalität darstellen, wobei von Beginn an die Umschaltung von wenigstens zwei Teilfunk­ tionen unabhängig von deren tatsächlicher Gesamtaufgabe durchgeführt wird.

2. Vorrichtung zur Koordinierung von Umschalt- und Ablöse­ vorgängen zwischen wenigstens zwei Teilfunktionen, die zusam­ men eine besserverfügbare Gesamtfunktionalität darstellen, wobei diese Vorrichtung als verteilter, applikationsnaher Zu­ standsautomat ausgebildet ist.

3. Verwendung des Verfahren nach Anspruch 1 auf Funktiona­ litäten in Form von einzelnen Software-Applikationen.

4. Verwendung des Verfahrens nach Anspruch 1 auf eine kom­ plette Hardware mit unterlagerten Software-Modulen.