DE4406924A1 - Verfahren zum synchronisierten Betrieb eines aus mehreren Rechnern bestehenden verteilten Datenverarbeitungssystems und Einrichtung zur Anwendung des Verfahrens - Google Patents

Description

Die Erfindung bezieht sich auf ein Verfahren nach dem Ober­ begriff des Patentanspruches 1 sowie auf eine Einrichtung zur Anwendung des Verfahrens.

Unter anderem aus der Firmendruckschrift der Siemens AG, Bestellnummer A19100-V100-B412-V1 aus dem Jahre 1992 ist es bekannt, für die Steuerung von Bahnanlagen durch elektroni­ sche Stellwerke eine Mehrzahl sog. Bereichsstellrechner vorzusehen, die dazu eingerichtet sind, ihnen fest zugeord­ nete Elemente der Bahnaußenanlage zu steuern und zu überwa­ chen. Neben diesen Bereichsstellrechnern gibt es noch eini­ ge zentrale Rechner zur Abarbeitung zentraler Aufgaben. Jeder Bereichsstellrechner besteht aus einem Doppelrechner­ system zur Aufdeckung eines möglichen Fehlverhaltens einer seiner Einzelrechner durch ständigen gegenseitigen Ver­ gleich der in die Datenverarbeitung einbezogenen Daten und durch Kontrolle der in seinen Speichern abgelegten Daten innerhalb vorgegebener maximaler Zeitspannen im Rahmen von Prüfroutinen. Gegebenenfalls sind auch noch Reserve-Be­ reichsstellrechner vorgesehen, die im Störungsfall die Funktion eines ausgefallenen Bereichsstellrechners wahrneh­ men können.

Zur Steuerung und Überwachung des Betriebsgeschehens dient eine Software, die zum Teil anwenderunabhängig ist und die Rechner in die Lage versetzt, als Stellwerk zu arbeiten und zum Teil bahnverwaltungsspezifisch ist und die logischen Stellwerksbedingungen der jeweiligen Bahnverwaltung bein­ haltet. Außerdem werden die Bereichsstellrechner in einer Aufrüstphase vor Betriebsbeginn über die von ihnen zu steu­ ernde Anlagenelemente und ihre Anordnung im Gleis unter­ richtet. Zum Abarbeiten von Stellwerksfunktionen rufen die Bereichsstellrechner in ihren Speichern hinterlegte Pro­ gramme z. B. für die Weichenstellung oder die Flanken­ schutzsuche ab und verknüpfen sie mit den jeweils in Frage kommenden anlagenspezifischen Daten, z. B. mit den Daten einer bestimmten Weiche oder den Daten der in die Flanken­ schutzsuche einzubeziehenden konkreten Fahrwegelemente.

Die Erstellung und die Prüfung dieser Software ist außeror­ dentlich zeit- und kostenaufwendig, weil sie regelmäßig in einer an die Betriebsweise von Rechnern angepaßten Program­ miersprache und nicht in einer problemorientierten Sprache erfolgt, welche das eigentliche Stellwerksgeschehen in einer für den Entwickler verständlichen Form beschreibt. Durch die Notwendigkeit, für diese Software einen Sicher­ heitsnachweis zu führen, vergrößern sich die Kosten und der Zeitaufwand für die Erstellung derartiger elektronischer Stellwerke erheblich.

Es ist deshalb bereits auch vorgeschlagen worden, die Steuerung eines komplexen Prozeßgeschehens wie z. B. eines Stellwerks durch endliche Automaten zu realisieren und damit eine übersichtlichere Darstellung zu erzielen. Die Beschreibung eines endlichen Automaten umfaßt seine mögli­ chen (endlich vielen) inneren Zustände, die Übergangs- und die Ausgabefunktion (Lexikon der Informatik und Datenverar­ beitung, Oldenbourg Verlag, 1991, 3. Auflage, Seiten 66 und 67). Aus den Zuständen und den Eingaben (Eingaben des Be­ dieners oder Meldungen von der Außenanlage) werden mit Hilfe der Übergangsfunktion neue Zustände und mittels der Ausgabefunktion Ausgaben an den Bediener und an den Prozeß berechnet. Eine konkrete Darstellung eines endlichen Auto­ maten wird als Automatentafel bezeichnet. In der nicht vorveröffentlichen europäischen Patentanmeldung 92250346 ist ein Verfahren angegeben, mit dessen Hilfe es möglich ist, auf übersichtliche und verständliche Weise eine Auto­ matentafel zur vollständigen Beschreibung des Zustandsüber­ gangs- und Ergebnisverhaltens eines komplexen Steuerungssy­ stems zu generieren. Dieses Steuerungssystem kann z. B. der eingangs eingeführte Bereichsstellrechner sein.

Jeder der Bereichsstellrechner führt überwiegend unabhängig von den anderen Bereichsstellrechnern bestimmte Transaktio­ nen aus. Unter einer Transaktion ist die Bearbeitung der Eingabe eines Bedieners oder einer Eingabe vom Prozeß her zu verstehen. Bei einer Transaktion werden aufgrund des bestehenden Zustandes des Automaten und der Eingabe ein neuer Zustand und gegebenenfalls Ausgaben berechnet.

Obgleich jeder Bereichsstellrechner für die Steuerung und Überwachung eines ganz bestimmten Anlagenbereiches zustän­ dig und damit unabhängig von der Prozeßbearbeitung der anderen Bereichsstellrechner ist, ist es doch erforderlich, daß die Bereichsstellrechner untereinander zur Abarbeitung bestimmter Aufgaben Informationen austauschen. Dies ist z. B. erforderlich, wenn ein Zug aus dem einen in den ande­ ren Anlagenbereich überwechseln soll oder wenn Flanken­ schutzanforderungen aus einem Bereich an einen anderen gestellt werden müssen. Hierbei gibt es ein Problem: Selbst wenn sich die zugehörigen Rechner gegenseitig über ihre inneren Zustände unterrichten, werden sie zu jedem Zeit­ punkt einen unterschiedlichen Kenntnis stand aufweisen, weil einer der Rechner vor den anderen Rechnern über einen aktu­ elleren, von ihm erarbeiteten Zustand Bescheid weiß und erst danach an die Unterrichtung seiner Partner gehen kann. Da auf den verschiedenen Rechnern gleichzeitig Transaktio­ nen durchgeführt werden, muß dafür gesorgt werden, daß bei allen Rechnern nur solche Transaktionen zu neuen Zuständen beitragen und Ausgaben erzeugen, die nicht im Konflikt mit vorher von einem anderen Rechner zugelassenen Transaktionen stehen. Es darf also nicht vorkommen, daß eine Transaktion einen Zustand als Berechnungsgrundlage nimmt, der inzwi­ schen wegen einer Änderung durch eine andere Transaktion nicht mehr aktuell ist. Jeder Bereichsstellrechner hat eine Kopie des gesamten Systemzustands zur Verfügung. Aufgrund der unterschiedlichen Bearbeitungsstände können die Kopien jedoch voneinander abweichen.

Aufgabe der Erfindung ist es, ein Verfahren nach dem Ober­ begriff des Patentanspruches 1 sowie eine Einrichtung zur Anwendung dieses Verfahrens anzugeben, das gewährleistet, daß kein Rechner die Ergebnisse einer von ihm gegebenen­ falls aufgrund eines nicht mehr aktuellen Zustandswertes durchgeführten Transaktion zur Ausführung zuläßt, wenn einer der übrigen Rechner zuvor bereits den aktuelleren Zustandswert in eine Transaktion einbezogen hatte und diese Transaktion von diesem Rechner zugelassen wurde. Unter Elementen sind hier sowohl gegenständliche Elemente wie Weichen und Signale zu verstehen als auch funktionelle Elemente wie Fahrwegsuche und Zulassungsprüfung.

Die Erfindung löst diese Aufgabe durch die Anwendung der kennzeichnenden Merkmale des Patentanspruches 1; eine Ein­ richtung zur Anwendung dieses Verfahrens ist im Anspruch 7 bezeichnet.

Nach der Lehre der vorliegenden Erfindung kann zu einem bestimmten Zeitpunkt immer nur einer der Rechner bzw. Rech­ nersysteme des Datenverarbeitungssystems Ausgaben an den Prozeß bewerkstelligen und neue innere Zustände zulassen. Dadurch, daß dieser Rechner/Rechnersystem vor der Zulassung der von ihm berechneten Transaktionen prüft, ob die von ihm in die Transaktionen einbezogenen Zustandswerte verschieden sind von den entsprechenden Zustandswerten der zuvor zulas­ sungsberechtigten- Rechner und daß solche Transaktionen nicht zur Ausführung zugelassen werden, die nicht mehr aktuelle Teile des Systemzustands in die Transaktionen einbezogen haben, wird erreicht, daß bei allen Rech­ nern/Rechnersystemen trotz vorübergehend ungleichen Kennt­ nisstandes über die Zustandswerte des Systems nur Transak­ tionen mit aktuellen Zustandskomponenten zu Auswirkungen auf den Prozeß und die übrigen Rechner führen können. Das umlaufende Token dient zum einen dazu, die lokalen Zu­ standskopien der Rechner jeweils auf den neuesten Stand zu bringen und zum anderen dazu, die Konfliktprüfung durchfüh­ ren zu können.

Vorteilhafte Ausgestaltungen der Erfindung sind in den Unteransprüchen angegeben.

So sollen nach der Lehre des Anspruches 2 Änderungsmeldun­ gen nicht nur gegen die Zustandswerte der erfolgreich abge­ schlossenen Transaktionen, sondern auch gegen die Zustands­ werte der noch nicht beendeten Transaktionen geprüft wer­ den; dies hat den Vorzug, daß gerade bei langen Transaktio­ nen die Bearbeitung vorzeitig abgebrochen werden kann, wenn feststeht, daß in die Transaktionen nicht mehr aktuelle Zustandswerte einbezogen sind.

Konflikte, die die Zulassung bereits abgeschlossener Trans­ aktionen verhindern und zum Abbrechen nicht abgeschlossener Transaktionen führen sollen, sollen nach der Lehre des An­ spruches 3 dadurch erkannt werden, daß geprüft wird, ob die von den jeweils anderen Rechnern kommenden Änderungsmel­ dungen die gleichen Daten betreffen, auf die das jeweils betrachtete Rechnersystem zuvor bei der Abarbeitung der Transaktionen zugegriffen hat. Ist dies der Fall, so hat das Rechnersystem bei der Bearbeitung dieser Transaktionen nicht mehr aktuelle Zustandswerte berücksichtigt, so daß die Ergebnisse der Transaktionen für die Prozeßsteuerung nicht herangezogen werden dürfen.

Um sicherzustellen, daß Änderungsmeldungen auf dem Weg zwischen den einzelnen Rechnersystemen nicht unerkannt verloren gehen können, sieht Anspruch 4 vor, daß die Verar­ beitungsergebnisse erst nach Quittierung der Änderungsmel­ dungen durch ein in Fortschaltrichtung des Tokens folgendes Rechnersystem zur Ausführung zugelassen werden; beim Aus­ bleiben solcher Quittungsmeldungen können die Änderungsmel­ dungen erneut ausgegeben werden und/oder das Token wird an ein anderes Rechnersystem fortgeschaltet.

In aller Regel werden die Transaktionen so kurzzeitig sein, daß sie abgeschlossen sind bevor das Token einmal die Rech­ nersysteme des Datenverarbeitungssystems durchlaufen hat. Zeitlich lange Transaktionen werden bei erneuter Tokenzu­ weisung abgebrochen oder unterbrochen. Für die Behandlung solcher langen Transaktionen sieht Anspruch 5 vor, daß abgebrochenen Transaktionen Wertigkeiten zugeordnet werden, die bei jedem neuen Tokenempfang aufgewertet werden und daß beim Überschreiten eines vorgegebenen Wertes dieser Wertig­ keit die Ausführung dieser Transaktionen erzwungen wird, indem das Token vorübergehend festgehalten wird. Hierdurch wird sichergestellt, daß auch längerfristige Transaktionen in überschaubarer Zeit abgeschlossen werden können.

Eine andere Möglichkeit, lange Transaktionen auszuführen, besteht nach der Lehre des Anspruches 6 darin, die Transak­ tionen unterbrechbar auszuführen und die unterbrochenen Transaktionen jeweils gegen die aktuelle Version des mit dem Token übermittelten Systemzustands zu prüfen.

Die in Anspruch 7 angegebene Einrichtung zur Anwendung des Verfahrens beschreibt den Aufbau des Datenverarbeitungssy­ stems mit einer Punkt zu Punkt Verbindung der Rechner/Rech­ nersysteme, über die diese sich per broadcast mindestens vom Tokenempfang und seriell über die Änderungsmeldungen, die das Token beinhalten, unterrichtet. Diese Anordnung schafft die Möglichkeit, etwaige Konflikte zwischen den in Transaktionen berücksichtigten Zustandswerten und inzwi­ schen geänderten Zustandswerten des Systems zu erkennen und in ihrer Auswirkung unwirksam zu melden.

Anspruch 8 sieht vor, daß ein Rechnersystem, das einem in Fortschaltrichtung des Tokens zurückliegenden Rechnersystem die von diesem übermittelten Änderungen nicht innerhalb einer vorgegebenen Zeit quittiert, vom in Fortschaltrich­ tung des Tokens nachfolgenden Rechner/Rechnersystem von der Busbenutzung ausgeschlossen wird, wobei gemäß Anspruch 9 zum Wiederanlaufen des ausgefallenen Rechners/Rechnersy­ stems oder zur Eingliederung eines Ersatzrechners dieser sich bei seinem Nachfolger im Bussystem zu melden hat und von diesem mit den aktuellen Zustandswerten aufzurüsten ist.

Um Konflikte erkennen zu können, wird bei der Durchführung von Transaktionen gemäß Anspruch 10 jeweils ermittelt, welche Teile des Zustands in die Berechnung eingehen (Read­ set) und welche Teile verändert werden (Changeset). Bei jedem Tokenempfang prüft der Rechner, ob die ihm übermit­ telten Änderungen sich mit einem der Readsets überschnei­ den. Ist dies der Fall, dann hat er in seine Transaktionen Versionen von Zustandswerten einbezogen, die inzwischen nicht mehr aktuell sind und er hat die Freigabe dieser Transaktionen zu unterbinden bzw. bei noch nicht abge­ schlossenen Transaktionen die davon betroffenen Transaktio­ nen abzubrechen.

Die Unterteilung in gelesenen (Readset) und veränderten (Changeset) Teil des Zustandsraumes jedes Rechners/Rech­ nersystems soll gemäß Anspruch 11 für jede Transaktion gesondert festgelegt sein.

Für die Abarbeitung der einzelnen Transaktionen führt jeder Rechner gemäß Anspruch 12 eine Liste, in der die nicht endgültig beendeten Transaktionen aufgeführt sind und in die er neue Transaktionen zur Ausführung einträgt. Diese Liste erleichtert ihm die zeitgerechte Abarbeitung der einzelnen anliegenden Aufträge.

Die Liste wird gemäß Anspruch 13 nach jedem Tokenempfang aktualisiert, indem die dann ausgeführten Transaktionen gelöscht werden sobald der jeweilige Nachfolgerechner im Bussystem den Erhalt der Änderungsmeldungen quittiert hat.

Die Erfindung ist nachstehen anhand eines in der Zeichnung dargestellten Ausführungsbeispieles näher erläutert.

Fig. 1 zeigt ein aus drei Rechnern/Rechnersystemen beste­ hendes Datenverarbeitungssystem mit umlaufendem To­ ken,

Fig. 2 illustriert den Ablauf des Verfahrens beim Empfang und Abschicken eines Tokens.

Fig. 1 zeigt ein aus drei Rechnern/Rechnersystemen RS1 bis RS3 bestehendes Datenverarbeitungssystem zur Steuerung und Überwachung eines an sich beliebigen Prozeßgeschehens, beispielsweise zur Steuerung des Eisenbahnbetriebs durch ein elektronisches Stellwerk mit mehreren Bereichsstell­ rechnern. Die Rechner/Rechnersysteme RS1 bis RS3 bilden dabei z. B. die Bereichsstellrechner, die auf bestimmte zugeordnete Elemente der Außenanlage einwirken. Die Steue­ rung in den Rechnern ist jeweils als endlicher Automat realisiert, der aus inneren Zuständen und Eingaben neue innere Zustände und Ausgaben bildet. Die Eingaben sind beispielsweise die Eingaben eines Bedienungsberechtigten oder die Eingaben einer Automatik, die bestimmte Bedie­ nungshandlungen vornimmt oder anreizt. Die Ausgaben sind Ausgaben an die Prozeßelemente der Außenanlage und Aufträge an andere Rechnersysteme. Jedes Rechnersystem besitzt Kenntnis über den Gesamtzustand, der allerdings nicht immer der aktuelle sein muß. Die Rechnersysteme unterrichten sich über ihre inneren Zustände mittels eines Datenverbindungs­ systems DVS, über das sie untereinander kommunizieren kön­ nen. Ein über dieses Datenverbindungssystem seriell umlau­ fendes Token gestattet den einzelnen Rechnersystemen u. a., bereits abgearbeitete Transaktionen zur Ausführung zuzulas­ sen. Jedes Rechnersystem informiert dabei mindestens seinen in Fortschaltrichtung des Tokens folgendes Nachbarrechner­ system von den Ergebnissen der von ihm zwischenzeitlich durchgeführten Transaktionen in Form von Änderungsmeldungen für bestimmte Zustandswerte. Erst nach der Übermittelung einer Quittung für den Empfang dieser Daten und des Tokens läßt das Rechnersystem die Ausführung der von ihm zwischen­ zeitlich erarbeiteten Transaktionen zu. Die Daten umfassen dabei nicht nur die vom Rechnersystem selbst gebildeten neuen Zustandsteile sondern auch die ihm von den im Token­ ring zurückliegenden übrigen Rechnersystemen übermittelten, in den einzelnen Rechnersystemen gegebenenfalls jeweils aktualisierten Zustandsteile. Stellt ein Rechnersystem nach Tokenempfang fest, daß die von ihm in seine zwar abge­ schlossenen aber noch nicht zugelassenen Transaktionen einbezogenen Zustandswerte abweichen von den ihm von seinem Vorgänger übermittelten aktuellen Zustandswerte, so erkennt es hieraus, daß die von ihm ermittelten Transaktionsergeb­ nisse auf veralteten, nicht mehr aktuellen Zustandswerten beruhten und es verwirft diese Transaktionsergebnisse bzw. es bricht diese Transaktionen ab und beginnt mit der erneu­ ten Ausführung der Transaktionen unter Zugrundelegung der ihm nun mitgeteilten aktuellen Zustandswerte der anderen Rechnersysteme. Das Token verbleibt jeweils nur für eine bestimmte festgelegte Zeit bei jedem der Rechnersysteme und wird dann zum folgenden Rechnersystem fortgeschaltet. Ge­ schieht dies aus irgendeinem Grunde nicht, so wird dies mindestens von dem in Fortschaltrichtung des Tokens folgen­ den Rechnersystem erkannt und dieses Rechnersystem kann bestimmte zuvor festgelegte Maßnahmen ergreifen, die z. B. darin bestehen können, den Vorgänger von der weiteren Da­ tenverarbeitung auszuschließen und/oder durch ein Reserve­ system zu ersetzen. Hierzu unterrichten sich die einzelnen Rechner untereinander per broadcast über den Tokenempfang, so daß jeder Rechner selbst überwachen kann, ob er von seinem Vorgänger im Ring rechtzeitig das Token erhalten hat. Hat das Rechnersystem seinen Vorgänger von der weite­ ren Kommunikation aus geschlossen, so fordert es von dem davorliegenden intakten Rechnersystem die aktuellen Ände­ rungsmeldungen der Zustandswerte an; es quittiert diesem auch die Änderungsmeldungen und den Erhalt des Tokens, damit die Transaktionsergebnisse beim Quittungsempfänger zur Ausführung zugelassen werden können.

Jedes Rechnersystem beinhaltet eine Liste, in der die von ihm bearbeiteten, aber noch nicht zur Ausgabe zugelassen Transaktionen aufgeführt sind und in die neue Transaktionen als Folge neuer Eingaben aufgenommen werden. Die abge­ schlossenen Transaktionen werden aus dieser Liste jeweils gelöscht, sobald das Rechnersystem im folgenden Umlauf das Token erhält und die Transaktionen zur Ausgabe zugelassen hat. Ferner weist jedes Rechnersystem einen Eingabespeicher zum Puffern der ihm zugeführten Eingaben auf. Die Listen und Speicher dienen dazu, die einzelnen Aufträge und Trans­ aktionen in der Reihenfolge ihres Eingangs zu bearbeiten.

Zeitaufwendige Transaktionen, die nicht während eines ein­ zigen Tokenumlaufs zum Ergebnis führen, können entweder unterbrechbar ausgeführt sein und führen dann in mehreren aufeinanderfolgenden Tokenzyklen zu einem Ergebnis oder aber sie werden abgebrochen und erneut in Bearbeitung ge­ nommen. Da dann mit erneutem Abbruch zu rechnen ist, werden diese abgebrochenen Transaktionen mit Wertigkeiten verse­ hen, die bei jedem Abbruch, d. h. jedem Tokenumlauf, aufge­ wertet werden, um beim Erreichen eines vorgebbaren Schwell­ wertes, der für die einzelnen Transaktionen unterschiedlich sein kann, die vollständige Ausgabe der Transaktion zu erzwingen. Dies wird erreicht durch Festhalten des Tokens über die ansonsten für die Ausführung der Transaktionser­ gebnisse und die Fortschaltung des Tokens erforderliche Zeitspanne hinaus. Dieser Vorgang muß mindestens dem in Fortschaltrichtung des Tokens folgenden Rechnersystem mit­ geteilt werden, damit dieses nicht aus dem Ausbleiben des Tokens auf eine Störung im zurückliegenden Rechnersystem schließt.

Nähere Einzelheiten über den Ablauf der Datenverarbeitung in einem Rechnersystem während einer Tokenzuweisung sind aus Fig. 2 erkennbar.

Fig. 2 zeigt schematisch die Abläufe innerhalb eines Rech­ ners/Rechnersystems RSn nach Tokenempfang. Zu diesem Zeit­ punkt oder kurz davor hat das Rechnersystem RSn von seinem Vorgänger im Tokenring die aktuellen Änderungsmeldungen empfangen, welche die aktuellen Zustandswerte dieses und der zuvor über das Token angesprochenen Rechnersysteme beinhalten. Diese aktuellen Zustandswerte hinterlegt das Rechnersystem RSu zunächst in einem Eingangsspeicher ESp und quittiert dem in Fortschaltung des Tokens zurückliegen­ den Rechnersystem den Empfang der Änderungsmeldungen über eine entsprechende Quittungsmeldung Qn-1. Diese Quittungs­ meldung kann die Änderungsmeldungen oder ein aus den Ände­ rungsmeldungen gebildetes Prüfwort enthalten, die es dem Vorgänger im Tokenring ermöglicht, festzustellen, ob die aktuellen Änderungsmeldungen bei dem betrachteten Rechner­ system richtig angekommen sind. Nach Empfang der Quittungs­ meldung Qu-1 werden die im zurückliegenden Rechnersystem zur Ausgabe anstehenden, bereits zugelassenen Transaktions­ ergebnisse ausgegeben.

Das Rechnersystem RSn vergleicht die übermittelten Ände­ rungsmeldungen daraufhin, ob sich darunter Daten befinden, die es für die seit der vorangegangenen Tokenzuweisung abgeschlossenen (aber noch nicht zur Ausführung zugelasse­ nen) oder in Angriff genommenen Transaktionen verwendet hat (Konfliktfall). Zu diesem Vergleich fragt das Rechnersystem in seinen Speichern Sp nach entsprechenden Daten nach. Der Speicher Sp beinhaltet für jede Transaktion T1 bis T3 un­ veränderbare Daten (Readset RS1 bis RS3), auf die während des Abarbeitens der betreffenden Transaktion zugegriffen wurde und veränderbare Daten (Changeset CS1 bis CS3), die durch die Transaktion verändert werden und neue geänderte Zustandswerte darstellen; jede der bearbeiteten Transaktio­ nen T1 bis T3 wurde durch eine zugehörige Eingabe i1 bis i3 initiiert. Um festzustellen, ob die ihm von dem in Fort­ schaltrichtung des Tokens zurückliegenden Rechnersystem übermittelten Änderungsmeldungen mit den Zustandswerten der von ihm seit der letzten Tokenzuweisung behandelten Trans­ aktionen T1 bis T3 kollidieren, prüft das Rechnersystem, ob die Änderungsmeldungen Daten beinhalten, die Daten in einem Readset einer der abgeschlossenen oder unterbrochenen Transaktionen betreffen. Ist dies der Fall, dann hat das Rechnersystem bei der Ausführung der betreffenden Transak­ tion Zustandswerte berücksichtigt, die nicht mehr aktuell sind, sondern während des vorangegangenen Tokenumlaufs durch irgendeines der vorangehenden Rechnersysteme verän­ dert worden sind. Damit darf die betreffende Transaktion nicht zur Ausführung zugelassen werden; sie ist vielmehr erneut zu berechnen und zwar unter Berücksichtigung der aktuellen Version der Zustandswerte. Eine solche abgewie­ sene Transaktion ist die Transaktion T2.

Für den Vergleich der Änderungsmeldungen mit den für die einzelnen Transaktionen verwendeten Zustandswerten hat das Rechnersystem die seit dem letzten Tokenempfang abgeschlos­ senen Transaktionen vom Ergebnis her zwischengespeichert und Read- und Changeset; diese Festlegung ist von Transak­ tion zu Transaktion verschieden. Jede Transaktion baut auf dem durch die vorangegangene Transaktion festgelegten Zu­ standsbild auf, so daß innerhalb des Rechnersystems auch bei jeder zweiten, dritten usw. Transaktion stets von einem aktuellen Zustandsbild des Rechnersystems ausgegangen wird.

Erkennt das Rechnersystem wie bei der Transaktion T2 in­ haltliche Abweichungen zwischen den ihm mitgeteilten Ände­ rungsmeldungen und den bei seinen abgeschlossenen oder noch in Bearbeitung begriffenen Transaktionen verwendeten Daten, so läßt es die zwischengespeicherten Transaktionsergebnisse bzw. Zwischenergebnisse nicht zur Ausführung zu und löscht sie. Andernfalls bereitet es die Ausgabe an den Prozeß bzw. die Weiterbearbeitung im Rechnersystem vor und sorgt dafür, daß die bislang im Eingabespeicher ESp anstehenden Ände­ rungsmeldungen des im Tokenring zurückliegenden Rechnersy­ stems vom eigenen Rechnersystem übernommen und nach Ab­ gleich mit seinen eigenen Änderungsmeldungen an das in Fortschaltrichtung des Tokens folgende Rechnersystem wei­ tergegeben werden. Der Abgleich der empfangenen mit den eigenen Änderungsmeldungen ist erforderlich, um festzustel­ len, ob einzelne der übermittelten Zustandswerte nicht vielleicht in der Zwischenzeit auch durch die vom Rechner­ system selbst ausgeführten Transaktionen geändert worden sind. Ist dies der Fall, so werden die entsprechenden vom zurückliegenden Rechnersystem stammenden Zustandswerte invertiert, weil sie nicht mehr aktuell sind. Die aktuelle Version der Änderungsmeldungen wird dann an das folgende Rechnersystem ausgegeben, das bei ordnungsgerechtem Empfang eine entsprechende Quittungsmeldung Qn+1 an das betrachtete Rechnersystem RSn zurückgibt. Nach einer Überprüfung der Quittungsmeldung mit den ausgesandten Änderungsmeldungen veranlaßt das Rechnersystem RSn die Ausgabe der Ergebnisse von zugelassenen Transaktionen an den Prozeß und an den Bediener.

Das Wirksamwerden der abgeschlossenen Transaktionen ist also davon abhängig, daß das Token und mit ihm die aktuel­ len Änderungsmeldungen an das folgende Rechnersystem fort­ geschaltet und dort ordnungsgerecht empfangen wurden. Un­ terbleibt die Quittung der übermittelten Änderungsmeldun­ gen, so werden Routinen durchgeführt, die diesen Fehlerfall behandeln.

Das Ausbleiben einer Quittungsmeldung kann zum erneuten Aussenden von Änderungsmeldungen führen, die verhindern sollen, daß Rechnersysteme nur wegen sporadisch auftreten­ der Übertragungsfehler aus dem Verarbeitungssystem ausge­ gliedert werden. Gegebenenfalls sind entsprechende Meldun­ gen für das erneute Ausgeben von Änderungsmeldungen an die übrigen Rechnersysteme aus zugeben, um diese davon zu unter­ richten, daß sich die Weitergabe des Tokens verzögert.

Die Erfindung zeigt, wie in einem größeren Rechnerver­ bundsystem, dessen Rechner oder Rechnersysteme weitgehend unabhängige Prozesse steuern und überwachen, aber gelegent­ lich auch Daten untereinander auszutauschen haben, eine Prozeßsteuerung auf dem jeweils aktuellen Datenstand mög­ lich ist. Sie geht dabei von der optimistischen Annahme aus, daß alle eingeleiteten Transaktionen auch ausführbar sind und verhindert die Zulassung der abgeschlossenen Transaktionen dann, wenn sich zeigt, daß die in die Ergeb­ nisse einbezogenen Zustandswerte tatsächlich nicht den aktuellen Systemzustand darstellen. Da jedes Rechnersystem auf dem aktuellen Zustandsbild der vorangehenden Rechner aufbaut, ist die Ausgabe der Transaktionsergebnisse durch die einzelnen Rechner davon abhängig gemacht, daß die aktu­ ellen Daten aller dieser Rechner, soweit sie benötigt wer­ den, in die Ergebnisbildung eingeflossen sind. Durch die serielle Arbeitsweise der Rechnersysteme mit der laufenden Aktualisierung der Zustandswerte wird erreicht, daß keine der zuvor in einem Rechnersystem ermittelten Transitionser­ gebnisse zur Ausführung gelangt, wenn es auf tatsächlich nicht mehr aktuellen Zustandswerten beruht.

Claims (13)

1. Verfahren zum synchronisierten Betrieb eines aus mehre­ ren Rechnern oder Rechnersystemen bestehenden verteilten Datenverarbeitungssystems, dessen Rechner/Rechnersysteme eine ihnen zugeordnete Steuerung nach dem Konzept des end­ lichen Automaten realisieren und bei dem die einzelnen Rechner/Rechnersysteme weitgehend unabhängig voneinander ihnen zugewiesene Aufgaben in gegebenenfalls mehreren Transaktionen bearbeiten und untereinander über mindestens ein Bussystem mit seriell umlaufendem Token kommunizieren, das das geordnete Zusammenwirken der Rechner steuert,
dadurch gekennzeichnet,

• - daß von den Rechnern/Rechnersystemen alle sich bei einer Aufgabenbearbeitung ändernden Zustandswerte der Rech­ ner/Rechnersysteme auf das Bussystem geschaltet und alle jeweils von den übrigen Rechnern/Rechnersystemen aufge­ schalteten, sich seit dem vorangegangenen Tokenumlauf ge­ änderten Zustandswerte dieser Rechner/Rechnersysteme vom Bus abgegriffen und gespeichert werden, sobald das umlau­ fende Token bei dem betreffenden Rechner/Rechnersystem empfangen wird,
• - daß in den Rechnern/Rechnersystemen jeweils unter Beach­ tung ihres Kenntnisstandes über den Systemzustand die ihnen jeweils zugewiesenen Aufgaben bearbeitet und die jeweiligen Verarbeitungsergebnisse zwischengespeichert werden,
• - daß in den Rechnern/Rechnersystemen bei Empfang des Tokens die ihnen jeweils übermittelten Änderungsmeldungen der anderen Rechner/Rechnersysteme auf etwaige Konflikte mit den von ihnen bei der vorangegangenen Aufga­ benbearbeitung berücksichtigten Zustandswerten geprüft und im Konfliktfall die Ausgabe der zwischengespeicherten Verarbeitungsergebnisse gesperrt bzw. bei nicht vor­ handenen Konflikten die Verarbeitungsergebnisse minde­ stens mittelbar zur Ausführung zugelassen werden.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Änderungsmeldungen in den Rechnern/Rechnersystemen sowohl gegen die Zustandswerte der während des letzten Tokenumlaufs erfolgreich abgeschlossenen Transaktionen als auch gegen die noch nicht abgeschlossenen Transaktionen geprüft werden, wobei beim Feststellen eines Konfliktfalles die davon betroffenen Transaktionen verworfen werden und daß anschließend eine erneute Bearbeitung dieser Transak­ tionen unter Verwendung der aktuellen Version der inneren Zustände der Rechner/Rechnersysteme sowie der Meldungen und Aufträge erfolgt.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß ein Konfliktfall dadurch definiert ist, daß ein Rech­ ner/Rechnersystem bei einer Transaktion auf solche Speicher für Zustandswerte zugegriffen hat, für die mit dem Token Änderungen gemeldet werden.

4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Verarbeitungsergebnisse zwischengespeichert werden und daß die zwischengespeicherten Verarbeitungsergebnisse erst nach Quittierung der Änderungsmeldungen durch einen in Fortschaltrichtung des Tokens folgenden Rechner/Rechnersy­ stem zur Ausführung ausgegeben werden.

5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß den einzelnen Transaktionen bestimmte Wertigkeiten zugeordnet werden, die bei jedem Abbruch einer Transaktion infolge Tokenempfangs um einen vorgebbaren Betrag oder Anteil erhöht werden und daß beim Überschreiten eines vor­ gegebenen Wertes dieser Wertigkeit die Ausführung der Transaktion bis zu ihrem Ende durch vorübergehendes Fest­ halten des Tokens erzwungen wird.

6. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Transaktionen unterbrechbar ausgeführt und bei Tokenempfang vor ihrem Abschluß unterbrochen werden, und daß die unterbrochenen Transaktionen bei jedem Tokenempfang auf etwaige Konflikte zu den inzwischen eingegangenen Ände­ rungsmeldungen überprüft werden.

7. Einrichtung zur Anwendung des Verfahrens nach Anspruch 1, dadurch gekennzeichnet, daß Verbindungen (DVS) zwischen jedem Rechner/Rechnersystem (RS1) zu jedem anderen Rechner/Rechnersystem ((RS2/RS3) bestehen, über die die Rechner/Rechnersysteme das Token zusammen mit den aktualisierten Änderungsmeldungen umlau­ fend von Rechner/Rechnersystem zu Rechner/Rechnersystem fortschalten und über die sie sich gegenseitig per broad­ cast mindestens von der Weitergabe des Tokens unterrichten und den Erhalt des Tokens quittieren.

8. Einrichtung nach Anspruch 7, dadurch gekennzeichnet, daß die maximale Verweildauer des Tokens bei einem Rech­ ner/Rechnersystem begrenzt ist und daß ein Rechner/Rech­ nersystem (RS1) dann, wenn er/es feststellt, daß entweder sein Vorgänger (RS3) in Fortschaltrichtung des Tokens das Token nicht rechtzeitig weitergegeben hat, das Token von dessen Vorgänger (RS2) anfordert oder aber wenn die Quittung für den Empfang der Änderungsmeldungen ausbleibt, er dem auf den ausgefallenen Rechner/Rechnersystem (RS3) in Fortschaltung folgenden Rechner/Rechnersystem (RS2) das Token zuweist und daß der Rechner/das Rechnersystem (RS1) und/oder der vor dem ausgefallenen Rechner/Rechnersystem (RS3) gelegene Rechner/Rechnersystem (RS2) den ausgefal­ lenen Rechner/Rechnersystem fortan von der Busbenutzung ausschließt.

9. Einrichtung nach Anspruch 8, dadurch gekennzeichnet , daß zum Wiederanlaufen eines ausgefallenen Rechners/Rech­ nersystems (RS3) oder zum Anlaufen eines Ersatzrechners/Er­ satzrechnersystems dieser sich bei dem in Fortschaltrich­ tung des Tokens folgenden Rechner/Rechnersystem (RS1) meldet und daß dieser (RS1) dem ausgefallenen Rechner/Rech­ nersystem die aktuelle Version des Systemzustands übermit­ telt und ihn ggf. in Abstimmung mit dem vor dem ausgefalle­ nen Rechner/Rechnersystem gelegenen Rechner/Rechnersystem (RS2) wieder als seinen Vorgänger im Bussystem akzeptiert.

10. Einrichtung nach Anspruch 7, dadurch gekennzeichnet, daß die Datenbereiche, auf die ein Rechner/Rechnersystem (RSn) bei einer bestimmten Transaktion Zugriff hat, nach Abschluß der jeweiligen Transaktion aufgeteilt werden in einen Readset (RS), auf den der Rechner/Rechnersystem lesend zugegriffen hatte und in einen Changeset (CS), den der Rechner/Rechnersystem verändern hat und daß zum Fest­ stellen von Konflikten jeder Rechner/Rechnersystem jeden Readset jeder seit der letzten Prüfung abgeschlossenen oder unterbrochenen Transaktion mit den ihm über die Änderungs­ meldungen (Än) aktualisierten Changesets der anderen Rechner/Rechnersysteme auf unterschiedliche Dateninhalte überprüft.

11. Einrichtung nach Anspruch 10, dadurch gekennzeichnet, daß die Rechner/Rechnersysteme nach jeder Transaktion den individuellen Readset (RS1 bis RS3) und den Changeset (CS1 bis CS3) der Transaktion (T1 bis T3) bestimmen, die betref­ fenden Daten selektieren und bis zur Zulassung des jeweili­ gen Verarbeitungsergebnisses abspeichern.

12. Einrichtung nach Anspruch 7, dadurch gekennzeichnet, daß jeder Rechner/Rechnersystem eine Liste aufweist, in der die von ihm bearbeiteten, aber noch nicht endgültig beende­ ten Transaktionen aufgeführt sind und daß er neue Transak­ tionen an des Ende der Liste setzt.

13. Einrichtung nach Anspruch 12, dadurch gekennzeichnet, daß jeder Rechner/Rechnersystem auf den Erhalt einer Quittung von einem Nachbarrechner für den Empfang des Tokens die Eintragung der Transaktionen in seiner Liste löscht, sobald die betreffenden Transaktionen zugelassen oder abgewiesen sind und die Liste bereithält zur Aufnahme neuer durch Eingaben initiierter Transaktionen in der Reihenfolge ihres Eintreffens.