DE69424565T2 - Fehler-betriebssichere/fehler tolerante computerbetriebsmethode - Google Patents

Fehler-betriebssichere/fehler tolerante computerbetriebsmethode

Info

Publication number
DE69424565T2
DE69424565T2 DE69424565T DE69424565T DE69424565T2 DE 69424565 T2 DE69424565 T2 DE 69424565T2 DE 69424565 T DE69424565 T DE 69424565T DE 69424565 T DE69424565 T DE 69424565T DE 69424565 T2 DE69424565 T2 DE 69424565T2
Authority
DE
Germany
Prior art keywords
computing
iop
computing elements
elements
ces
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69424565T
Other languages
English (en)
Other versions
DE69424565D1 (de
Inventor
D. Bissett
D. Fiorentino
M. Glorioso
T. Mccauley
D. Mccollum
A. Tremblay
Mario Troiani
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Marathon Technologies Corp
Original Assignee
Marathon Technologies Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Marathon Technologies Corp filed Critical Marathon Technologies Corp
Application granted granted Critical
Publication of DE69424565D1 publication Critical patent/DE69424565D1/de
Publication of DE69424565T2 publication Critical patent/DE69424565T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1658—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/04—Generating or distributing clock signals or signals derived directly therefrom
    • G06F1/14—Time supervision arrangements, e.g. real time clock
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1629—Error detection by comparing the output of redundant processing systems
    • G06F11/1641—Error detection by comparing the output of redundant processing systems where the comparison is not performed by the redundant processing components
    • G06F11/1645—Error detection by comparing the output of redundant processing systems where the comparison is not performed by the redundant processing components and the comparison itself uses redundant hardware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1675—Temporal synchronisation or re-synchronisation of redundant processing components
    • G06F11/1683—Temporal synchronisation or re-synchronisation of redundant processing components at instruction level
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1675—Temporal synchronisation or re-synchronisation of redundant processing components
    • G06F11/1687—Temporal synchronisation or re-synchronisation of redundant processing components at event level, e.g. by interrupt or result of polling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1675—Temporal synchronisation or re-synchronisation of redundant processing components
    • G06F11/1691—Temporal synchronisation or re-synchronisation of redundant processing components using a quantum
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/181—Eliminating the failing redundant component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2002—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant
    • G06F11/2005—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant using redundant communication controllers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2017—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where memory access, memory control or I/O control functionality is redundant
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1629—Error detection by comparing the output of redundant processing systems
    • G06F11/1641—Error detection by comparing the output of redundant processing systems where the comparison is not performed by the redundant processing components
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/183—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits by voting, the voting not being performed by the redundant components
    • G06F11/184—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits by voting, the voting not being performed by the redundant components where the redundant components implement processing functionality
    • G06F11/185—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits by voting, the voting not being performed by the redundant components where the redundant components implement processing functionality and the voting is itself performed redundantly

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Hardware Redundancy (AREA)
  • Multi Processors (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Description

    Hintergrund der Erfindung
  • Die Erfindung bezieht sich auf störungsfeste und störungstolerante Rechenverfahren und -apparaturen.
  • Störungsfeste Computersysteme sind in der Lage, ihren Betrieb auch im Falle von Hardwareausfällen aufrecht zu erhalten. Derartige Systeme arbeiten entweder in einem Verfügbarkeitsmodus oder einem Integritätsmodus, jedoch nicht in beiden. Ein System ist "verfügbar", wenn ein Hardwareausfall keine unakzeptablen Verzögerungen in Hinblick auf den Nutzerzugang verursacht und das im "Verfügbarkeitsmodus" arbeitende System derartig konfiguriert ist, daß es - wenn möglich - "online" bleibt, sollte es mit einem Hardware Fehler konfrontiert werden. Ein System besitzt Datenintegrität, wenn ein Hardwareausfall keine Datenverluste oder Datenbeschädigungen verursacht und das im "Integritätsmodus" arbeitende System derartig konfiguriert ist, daß Datenverluste oder -beschädigungen vermieden werden, selbst wenn das System dazu "offline" gehen muß.
  • Störungstolerante Systeme beanspruchen sowohl Verfügbarkeit als auch Integrität. Ein störungstolerantes System bleibt verfügbar und behält seine Datenintegrität, wenn es mit einem einzelnen Hardwareausfall und in einigen Fällen mit mehreren Hardwareausfällen konfrontiert wird.
  • Katastrophentolerante Systeme gehen noch einen Schritt weiter als störungstolerante Systeme und setzen voraus, daß ein Verlust einer Computer-Installation bei Naturkatastrophen oder bei durch menschliches Versagen verursachten Katastrophen nicht die Systemverfügbarkeit insgesamt unterbricht oder es zu Datenverlusten oder -beschädigungen kommt.
  • Die bisherigen Fehler-Toleranz-Verfahren enthalten einen Software-Checkpoint/Restart, Dreifach Modular Redundanz und "Pair and Spare"-Systeme.
  • Checkpoint/Restart-Systeme verwenden zwei oder mehrere Rechenelemente, welche asynchron arbeiten und verschiedene Anwendungen ausführen können. Jede Anwendung speichert periodisch ein Bild des Zustandes des Rechenelements auf welchem sie läuft. (ein sog. Checkpoint). Wenn ein Fehler in einem Rechenelement entdeckt wird, wird der "Checkpoint" dazu verwendet, die Anwendung auf einem anderen Rechenelement neu zu starten (-oder auf dem selben Rechenelement, sobald der Fehler behoben ist). Um ein Checkpoint-Restart-System einsetzen zu können, muß jede Anwendung und/oder das Betriebssystem dahingehend modifiziert werden, daß regelmäßige Zwischenspeicherungen des Systemzustandes erfolgen. Zusätzlich muß das System "datensicherungs"-fähig sein. (D. h. es muß in der Lage sein, die Wirkungen jeglicher Rechen-Operationen, die aus dem neuzustartenden "Checkpoint" folgen, rückgängig zu machen.)
  • Bei Dreifach-Modular-Redundanz Systemen läuft die selbe Anwendung auf drei Rechenelementen, die in einem "Zyklus für Zyklus" Blockierschritt betrieben werden. Sämtliche Rechenelemente sind mit dem Baustein einer Abstimm-Schaltung verbunden, welche die Ausgangswerte (d. h. der Memory Interfaces) der drei Rechenelemente vergleicht und, wenn alle Ausgangswerte übereinstimmen, mit der normalen Operation fortfährt. Wenn einer der Ausgangswerte abweicht, fährt die Abstimm-Schaltung das Rechenelement herunter, welches den abweichenden Ausgangswert produziert hat. Die Abstimm-Schaltung, die zwischen den Rechenelementen und dem Speicher positioniert ist, hat entscheidenden Einfluß auf die Systemgeschwindigkeit.
  • "Pair and Spare" - Systeme enthalten zwei oder mehrere Paare von Rechenelementen, auf denen die selbe Anwendung läuft und die in einem "Zyklus für Zyklus" Blockierschritt gesteuert werden. Ein Controller überwacht die Ausgangswerte (d. h. die Memory Interfaces) von jedem der paarweise angeordneten Rechenelemente. Wenn der Ausgangswert abweicht, werden beide paarweisen Rechenelemente heruntergefahren.
  • Hinsichtlich der Synchronisation von Rechenelementen beschreibt die US-A-4 937 741 ein System zum Synchronisieren einer Vielzahl von in Gruppen organisierten redundanten Prozessoren. Diese Prozessoren werden jedesmal resynchronisiert, sobald ein Prozeßrahmen, der eine vordefinierte Anzahl an Bearbeitungsereignissen umfaßt, abgeschlossen ist. Während der Synchronisation führen die Prozessoren untereinander interaktive Konsistenz-Austausche hinsichtlich der gegenseitigen internen Taktwerte durch, so daß jeder Prozessor den jeweiligen Mittelwert als neuen Taktwert zu Beginn des nächsten Prozeßrahmens zur Grundlage machen kann.
  • Aus der EP-A-0 327 083 ist ein Synchronisationsverfahren für Rechenelemente eines Prozeßsteuer-Systems bekannt, wobei ein zen traler Taktwert periodisch über den System-BUS zu den Rechenelementen gesendet wird.
  • Die EP-A-0 372 580 offenbart die Synchronisation von Prozessoren eines lose verbundenen Dreifach-Modular-Redundanz Systems. Ereignisse, wie beispielsweise Memory-Abfragen, werden erkannt und vorgelagerte CPUs werden solange blockiert, bis alle die Funktion simultan ausführen.
    • Zusammenfassung der Erfindung
  • Gemäß der Erfindung wird ein störungsfestes oder störungstolerantes System durch die Nutzung von mindestens zwei Rechenelementen ("CEs") geschaffen, die asynchron in Echtzeit (d. h. von Zyklus zu Zyklus) und synchron in den sog. Zwischen-Zeiten operieren. Die CEs werden in den Zwischen-Zeiten synchronisiert, welche oft genug auftreten, so daß die Anwendungen, die auf den entsprechenden CEs laufen, nicht divergieren, aber es gestattet ist, daß diese asynchron zwischen den Zwischen-Zeiten laufen. Beispielsweise könnten die CEs einmal pro Sekunde synchronisiert werden und ansonsten asynchron laufen. Da die CEs zu jeder Zwischen-Zeit resynchronisiert werden, sagt man, die CEs operieren im sog. Zwischen-Zeit Blockierschritt.
  • In besonderen Anwendungsformen, sind die Zwischen-Zeiten als die Zeiten definiert, in denen die CEs I/O Operationen anfordern. In diesen Anwendungsformen werden die CEs nach jeder I/O Operation synchronisiert und laufen zwischen den I/O Operationen asynchron. Dieses Verfahren ist anwendbar bei Systemen in welchen mindestens zwei ansynchrone Rechenelemente, auf denen die selbe Anwendung läuft, ständig I/O Anfragen in der selben Reihenfolge generieren. Dieses Verfahren kann ferner auf Resynchronisationen im Anschluß an lediglich solche I/O Anfragen, die die Rechenumgebung modifizieren (d. h. die "Schreibanfragen"), beschränkt sein.
  • Die Zwischenzeit-Synchronisation entsprechend der Erfindung wird erreicht durch die Nutzung einer gepaarten Modular-Redundanz Architektur, welche für Anwendungen und die Software des Betriebssytems transparent ist. Im Rahmen dieser Architektur ist jedes Rechenelement gepaart mit einem Controller, auch bekannt als ein I/O Prozessor ("IOP"). Die IOPs führen jede I/O Anfrage aus, die von einem Rechenelement gestellt oder zu einem solchen weitergeleitet wird, spüren Hardwarefehler auf und synchronisieren die Rechenelemente miteinander im Anschluß an jede I/O Operation. In Systemen in welchen I/O Anfragen nicht mit zufriedenstelleneder Häufigkeit ergehen, synchronisieren die IOPs die CEs periodisch in Übereinstimmung mit sogenannten Quantenunterbrechungen, erzeugt von Inter- Processor-Zwischenverbindungsmodulen (IPI), die mit den CEs verbunden sind.
  • In einer anderen besonderen Ausführungsform der Erfindung werden die CEs anders als beim Synchronisieren basierend auf jeder einzelnen I/O Operation, auf der Grundlage eines Fensters von I/O Operation synchronisiert. In diesem Verfahren wird eine Liste von I/O Operationen für jedes CE beibehalten und die CEs werden synchronisiert, wann immer ein gemeinsamer Eintrag in allen Listen erscheint. Dieses Verfahren gestattet eine Flexibilität in Hinblick auf die Reihenfolge in welcher die I/O Anfragen generiert werden.
  • In einer weiteren exemplarischen Ausführungsform der Erfindung werden die CEs entweder basierend auf vom Betriebssystem periodisch generierten Signalen oder basierend auf hardware-generierten Unterbrechungen synchronisiert. So ist beispielsweise beim hardewaregenerierten Unterbrechungsverfahren ein Prozessor von jedem Rechenelement für die Erzeugung einer Unterbrechung aller N Zyklen modifiziert, während die CEs in Abhängigkeit zu diesen Unterbrechungen synchronisiert werden.
  • Die primären Komponenten eines gepaarten Modular-Redundanz Systems enthalten Software, "off-the-shelf" IOPs, "off-the-shelf" CEs und Paare speziell zugeschnittener IPI Module, welche in den Expansions-Slots des IOP's und des CEs stecken und über ein Kabel miteinander zusammengeschaltet sind. Redundante I/O-Geräte können mit einem oder mehreren der Rechenelemente oder IOPs verbunden werden, redundante I/O bereitzustellen und um bestimmte Merkmale anzubieten, wie beispielsweise volume shadowing von Code-Massenspeicher-Einrichtungen. Ein gepaartes Modular-Redundanz System kann jedes I/O-Gerät versorgen, das kompatibel mit einem Prozessor ist, der als ausführender IOP des Systems genutzt wird.
  • Die gepaarte Modular-Redundanz Anordnung benötigt ein Minimum an Nutzersoftware und Hardware um mindestens zwei kombinierte "offthe-shelf" Rechenelemente in Gang zu setzen für die Einbindung in störungsfeste oder -tolerante Systeme, die mit dem Industriestandard entsprechender Betriebssoftware laufen, wie z. B. Windows NT, DOS, OS/2 oder UNIX und unmodifizierten Anwendungen. Damit kann die Architektur sowohl die hohen Kosten, als auch die geringe Flexiblität der gewerblich geschützen Betriebsysteme, Anwendungen und Prozessorgestaltungen in der Art und Weise ihrer bisherigen Nutzung vermeiden.
  • Ein weiterer Vorteil der gepaarten Modular-Redundanzarchitektur dieser Erfindung ist, daß sie einen gewissen Grad an Software-Störungstoleranz bietet. Die Mehrheit der Softwarefehler ist nicht algorithmischer Art. Stattdessen werden die meisten Fehler durch die Asynchronität zwischen dem Rechenelement und den I/O Geräten verursacht, was in Laufzeitbedingungen mündet. Durch eine Entkopplung der I/O-Anfragen von den Rechenelementen reduziert die gepaarte Modular-Redundanzarchitektur in entscheidender Weise die Anzahl sog. "Huisenbugscher" Software-Fehler, die aus jener Asynchronität resultieren.
  • Die Erfindung ist in Anspruch 1 beschrieben.
  • Besonders günstige Ausführungen der Erfindung enthalten ferner die im folgenden aufgelisteten Merkmale. Zusätzlich zu den I/O- Anfragen können Quantenunterbrechungen die ausgewählten Signale sein. Die Rechenelemente zählen entweder die ausgeführten Anweisungen oder die Zyklen des Taktgebers, wie beispielsweise der Systemuhr oder der BUS-Uhr oder der I/O-Uhr und erzeugen Quantenunterbrechungen wann immer eine vordefinierte Anzahl an Anweisungen oder Zyklen erfolgt. Wenn sowohl, die I/O-Anfragen, als auch die Quantenunterbrechungen, als die ausgewählten Signale benutzt werden, zählen die Rechenelemente die Anzahl der Anweisungen oder Zyklen, die ohne eine I/O-Anfrage erfolgen. Beispielsweise könnte ein Rechenelement derartig programmiert sein, daß es Quantenunterbrechungen erzeugt, wann immer es 100 Zyklen lang arbeitet, ohne eine I/O-Anfrage zu erzeugen.
  • In einer Ausführungsform, werden die Anweisungen gezählt, indem ein Zähler mit einem vorbestimmten Wert geladen wird, wobei der Zähler mit der I/O Anfrage gestartet wird, der Wert des Zählers heruntergezählt wird und ein Quantenunterbrechungssignal signalisiert wird, wenn der Wert des Zählers Null erreicht. Bei einem anderen Verfahren werden Fehlersuch-Features des Prozessors ausgenutzt um die Qunatenunterbrechungen zu erzeugen.
  • Zur Fehlererkennung werden die ausgewählten Signale und die Begleitdaten - falls vorhanden - verglichen. Wenn diese nicht übereinstimmen, wird ein Signal erzeugt, welches das Auftreten eines Fehlers anzeigt.
  • In einigen Ausführungsformen warten die Rechenelemente auf Zeitabgleichssignale, indem sie mit ihren Operationen pausieren, nachdem das ausgewählte Signal produziert wurde. Die Rechenelemente nehmen ihre Operationen nach dem Empfang des Zeitabgleichsignals wieder auf.
  • Um Probleme zu vermeiden, die aus den asynchronen Aktivitäten der Rechenelemente folgen könnten, werden diese asynchronen Aktivitäten eingestellt. Die Funktionen der asynchronen Aktivitäten werden dann wieder ausgeführt, wenn ein ausgewähltes Signal erzeugt wird. So werden beispielsweise normale "Speicher-Refresh" Funktionen deaktiviert und an ihrer Stelle jedesmal "Burst-Memory-Refreshes" ausgeführt, sobald ein ausgewähltes Signal - wie z. B. eine I/O- Anfrage, oder eine Quantenunterbrechung erzeugt wird.
    • Kurzbeschreibung der Zeichnungen
  • - Fig. 1 ist ein Blockdiagramm eines teilweise störungsfesten Systems.
  • - Fig. 2 ist ein Blockdiagramm der Systemsoftware des Systems aus Fig. 1.
  • - Fig. 3 ist einen Ablaufplan des von einem IOP-Monitor der Systemsoftware genutzen Verfahrens nach Fig. 2.
  • - Fig. 4 ist ein Blockdiagramm eines IPI-Moduls des Systems aus Fig. 1.
  • - Fig. 5 ist eine Zustandsübergangstabelle des Systems aus Fig. 1.
  • - Fig. 6 ist ein Blockdiagramm eines fehlertoleranten Systems.
  • - Fig. 7 zeigt ein Blockdiagramm eines gegliederten störungsfesten Systems.
  • - Fig. 8 ist ein Blockdiagramm eines störungstoleranten Systems.
  • - Fig. 9 ist ein Ablaufplan eines Fehlerdiagnoseverfahrens, das durch die IOPs des Systems nach Fig. 8 genutzt wird.
  • - Fig. 10 ist ein Blockdiagramm eines katastrophentoleranten Systems.
    • Beschreibung der bevorzugten Ausführungsformen
  • Wie in Fig. 1. dargestellt, enthält ein störungsfestes System 10 einen I/O-Prozessor ("IOP") 12 und zwei Rechenelemente ("CEs") 14a, 14b (gemeinsam bezeichnet als CEs 14). Da das System 10 nur einen einzelnen IOP 12 enthält, kann es sich nach einem Fehler im IOP 12 nicht wiederherstellen und ist deshalb nicht vollständig störungsfest.
  • IOP 12 enthält zwei Inter-Prozessor-Zwischenverbindungsmodule (IPI) 16a, 16b, die entsprechend mit korrespondierenden IPI Modulen 18a, 18b der CEs 14 über Kabel 20a, 20b verbunden sind. Das IOP 12 enthält außerdem einen Prozessor 22, ein Speichersystem 24, zwei Festplattenlaufwerke 26,28 und ein Netzanschlußgerät 30. Auf ähnliche Weise enthält jedes CE 14 einen Prozessor 32, ein Speicherystem 34 und eine Stromversorgung 36. Separate Stromversorgungen 36 werden benutzt, um die Störungsfestigkeit im Falle eines Stromversorgungsausfalles sicherzustellen. Die Prozessoren 32a, 32b sind insoweit "identisch", als daß für jede Instruktion, die für eine Ausführung durch den Prozessor 32a benötigte Anzahl der Zyklen mit der Anzahl der für eine Ausführung derselben Instruktion durch den Prozesser 32b benötigten Zyklen übereinstimmt. In der dargestellten Ausführungsform werden in System 10 auf Intel 486 Standard basierende Motherboards für die Prozessoren 22, 32 und 4 MB Speicherkapazität für jedes der Speichersysteme 24,34 verwendet.
  • Auf IOP 12 und CEs 14 läuft unmodifizierte System- und Anwendungssoftware, wobei die Festplatte 26 als Bootdisk für den IOP und die Festplatte 28 als Bootdisk für die CEs 14 verwendet wird.
  • In wirklich störungsfesten oder -toleranten Systemen, die mindestens 2 IOPs enthalten, würde auch jede Festplatte doppelt vorhanden sein.
  • Bei der dargestellten Ausführungsform wird als Betriebssystem für den IOP 12 und die CEs 14 DOS verwendet. Jedoch können auch andere Betriebssysteme zum Einsatz kommen. Außerdem kann auf dem IOP 12 ein anderes Betriebssystem laufen, als auf den CEs 14. So kann beispielsweise auf IOP 12 Unix laufen, während auf den CEs 14 DOS läuft. Dieses Verfahren ist vorteilhaft, weil es den CEs gestattet, von Betriebssystemen auf die Peripherie-(Geräte) zuzugreifen, wel ches diese Peripherien-(Geräte) nicht unterstützt. Läuft auf den CEs 14 beipielsweise ein Betriebssystem, welches keine CD-ROM-Laufwerke unterstützt und läuft dafür aber auf dem IOP ein Betriebssystem, das dieses kann, so können die CEs auf das CD-ROM Laufwerk zugreifen, indem sie I/O Anfragen ausgeben, die zu denjenigen identisch sind, die z. B. für Festplattenzugriffe genutzt werden. Der IOP 12 würde dann die Übersetztung der I/O Anfrage in eine für den CD-ROM Zugriff geeignete Anfrage durchführen.
  • In Bezug auf Fig. 2 enthält das System 10 eine spezialisierte Systemsoftware 40 welche das Booten und Synchronisieren der CEs 14 kontrolliert, die lokale Zeit in den CEs ausschaltet, alle I/O- Anfragen von den CEs 14 zum IOP 12 für die Ausführung umleitet und die Ergebnisse der I/O Anfragen - sofern vorhanden - vom IOP zu den CEs zurückführt.
  • Die Systemsoftware 40 enthält zwei Sätze von auf ROM basierenden IPI BIOS 42, welche jeweils im IPI Modul 18 eines CE 14 angeordnet sind. Die IPI BIOS 42 werden bei Aktivitäten in Bezug auf das Hochfahren und Synchronisieren benutzt. Wenn ein CE 14 hochgefahren wird, ersetzen die IPI BIOS 42 die I/O Unterbrechungsadressen in der BIOS Unterbrechungstabelle mit Adressen, die von CE Treibern 44 kontrolliert werden. Die Unterbrechungsadressen, die ersetzt werden, enthalten jene, die den Videobetrieb, den Fixed-Disc-Betrieb, den seriellen Kommunikationsbetrieb, den Keyboardbetrieb und den Tageszeitbetrieb umfassen.
  • Die IPI BIOS 42 schalten auch den normalen Memory-Refresh aus, um sicherzustellen, daß jeglicher Memory-Refresh welcher sich auf die Anzahl der Zyklen, während derer ein CE 14 eigentlich arbeitet, auswirkt, durch die Systemsoftware kontrolliert werden kann. Der Memory-Refresh wird benötigt, um die Speicherintegrität beibehalten zu können. Bei bekannten Refresh-Verfahren wird der Speicher periodisch erneuert, wobei je ein Speicherblock am Ende einer Refresh- Periode erneuert ist. Die Dauer der Refresh-Periode ist so ausgewählt, daß der ganze Speicher innerhalb des Refresh-Limits des Speichers erneuert wird. Wenn ein Speicher beispielsweise 256 Blöcke und ein 8 ms Refresh-Limit hat, dann ist folglich die Refresh-Periode 31.25 us (8 ms / 256).
  • In der beschriebenen Ausführungsform, schaltet das IPI BIOS 42 den Memory-Refresh dadurch aus, daß ein vom Intel 486 Motherboard Benutzer Zähler gesetzt wird, um den Memory-Refresh in einem Modus zu steuern, was eine Steuereingabe zum Zähler erfordert, um diesen auf Vorwärtszählen zu schalten. Da der Steuereingang typischerweise mit der Stromversorgung verbunden ist, verändert sich dieser Steuereingang niemals und der Zähler ist wirksam ausgeschaltet.
  • Die zwei CE-Treiber 44 der Systemsoftware 40 führen den Memory- Refresh durch stoßartiges Erneuern von mehreren Speicherblöcken bei jeder Generierung einer I/O-Anfrage oder einer guantenunterbrechung durch. Die CE-Treiber 44 sind auf der CE Boot-Diskette 28 gespeichert und werden durch die CEs 14 gestartet. Zusätzlich zur Durchführung der stoßartigen Speichererneuerung fangen die CE-Treiber die I/O-Anfragen an das System BIOS ab und leiten diese durch die IPI Module 18 zur Ausführung weiter an den IOP 12. Die CE-Treiber 44 antworten auch auf die Unterbrechungsanfragen der IPI Module 18, schalten die Systemuhr aus und kontrollieren -basierend auf Informationen von der IOP Kontrolleinrichtung 48 - die Tageszeit der CEs 14.
  • Ein auf der IOP Boot-Disk 26 befindlicher IOP-Treiber 46, der vom IOP 12 gestartet wird, reagiert auf die I/O-Anfragen von den CEs 14 indem er diese zur Verarbeitung an einen IOP-Monitor 48 umleitet damit die Ergebnisse vom IOP-Monitor 48 verarbeitet und an die CEs 14 übertragen werden können. Der IOP Treiber kommuniziert mit dem CE Treiber mittels eines Paket-Protokolls.
  • Der IOP-Monitor 48 ist auf der Boot-Diskette 26 plaziert und wird vom IOP 12 gestartet. Der IOP-Monitor 48 kontrolliert das System 10 und führt die aktuellen I/O Anfragen durch, um die Ergebnisse zu produzieren, die vom IOP-Treiber 46 zu den CEs 14 übertragen werden.
  • Die Systemsoftware 40 umfaßt auch die Konsolensoftware 49, die auf dem IOP 12 läuft und die Nutzerkontrolle des Systems 10 ermöglicht. Über die Konsolensoftware 49 kann ein Nutzer Resets, Boots und Synchronisationen einer CE 14 vornehmen. Der Nutzer kann darüber hinaus eine oder beide CEs 14 auf ein automatisches Booten (autoboot) und/oder ein automatisches Synchronisieren (Autosync) schalten, nachdem ein Reset durchgeführt wurde, oder nach einem Startup. Die Fähigkeit, jede CE 14 kontrollieren zu können, ist sowohl während des normalen Betriebes, als auch zu Testzwecken nützlich. Mittels der Konsolensoftware 49 kann der Nutzer das System 10 auch entweder in einen Integritätsmodus, in welchem der IOP-Monitor 48 beide CEs 14 herunterfährt, sobald sie mit einem nicht kompensierbaren Fehler konfrontiert wird, in einen ersten Verfügbarkeitsmodus, in welchem der IOP-Monitor 48 die CE 14a ausschaltet, wenn sie mit einem nicht kompensierbaren Fehler konfrontiert wird, oder in einen zweiten Verfügbarkeitsmodus, in welchem der IOP-Monitor 48 die CE 14b ausschaltet, wenn sie mit einem nicht kompensierbaren Fehler konfrontiert wird, versetzen. Schließlich ermöglicht es die Konsolensoftware 49 dem Nutzer, den Systemstatus des Systemes 10 abzufragen. In einer alternativen Ausführungsform könnte die Konsolensoftware 49 auch einen separaten Prozessor nutzen, der mit dem IOP 12 kommuniziert.
  • Auf jedem CE 14 läuft eine Kopie der gleichen Anwendung und des gleichen Betriebssystems, das auch auf dem anderen CE 14 läuft. Darüber hinaus sind auch die Inhalte des Speichersystems 34a und 34b die gleichen und die Operationsumgebung der CEs 14 ist bei jedem Synchronisationstakt die gleiche. Folglich sollte der IOP- Monitor 48 auch identische Sequenzen der I/O -Anfragen von den CEs 14 erhalten.
  • Fig. 3 zeigt die Prozesse des IOP-Monitors 48 und überwacht die I/O-Anfragen gemäß einer Prozedur 100. Zu Beginn wartet der I/O Monitor 48 auf eine I/O Anfrage von einem der CEs 14 (Schritt 102). Nach dem Empfang eines I/O Paketes von - beispielsweise - CE 14b, wartet der IOP-Monitor 48 entweder auf eine I/O Anfrage von CE 14a, oder auf das Ende der Timout-Periode (Schritt 104). Da das System 10 mit dem DOS Betriebssystem arbeitet, welches die Ausführung einer Anwendung während einer I/O-Anfrage anhält, wird gewährleistet, daß der IOP-Monitor 48 keine I/O Anfrage von CE 14b empfängt, während sie auf eine Anfrage von CE 14a wartet (Schritt 104).
  • Als nächstes prüft der IOP-Monitor 48, ob die Timeout-Periode beendet ist (Schritt 106). Falls nicht, d. h. wenn also ein I/O- Anfragepaket von CE 14a eingetroffen ist, vergleicht der IOP- Monitor 48 die Prüfsummen der Pakete (Schritt 108) und bearbeitet die I/O-Anfrage, wenn die Prüfsummen übereinstimmen (Schritt 110). Nach der Bearbeitung der I/O-Anfrage gibt der IOP Monitor eine Anfrage zur System BIOS des IOP 12 in Bezug auf die aktuelle Tageszeit ab (Schritt 112).
  • Nach dem Empfang der Tageszeit assembliert die IOP Kontrolleinrichtung 48 ein IPI Paket, welches die Tageszeit und - falls vorhanden - die Ergebnisse der I/O Anfragen enthält (Schritt 114), und sendet dieses IPI Paket an den IOP Treiber 46 (Schritt 116) zur weiteren Übertragung an die CEs 14. Wenn die CEs 14 das IPI Paket empfangen, verwenden sie die übertragene Tageszeit, um ihre lokale Taktgeber zu aktualisieren, welche ansonsten - wie schon beschrieben - ausgeschaltet sind.
  • Wie von DOS vorausgesetzt, wird die Ausführung in den CEs 14 ausgesetzt bis der IOP-Monitor 48 die Ergebnisse der I/O Anfrage durch den IOP Treiber 46 zurückgibt. Da, bevor die Ausführung wieder aufgenommen wird, die Tageszeiten beider CEs 14 auf einen gemeinsamen Wert (die übertragene Tageseit des IPI Pakets) hin aktualisiert werden, können die CEs in zeitlicher Synchronistaion mit der übertragenen und als Zwischen-Zeit bezeichneten Tageszeit gehalten werden. Wenn ein multi-task mäßig operierendes System in Betrieb wäre, würde eine Ausführung in den CEs 14 nicht ausgesetzt werden, während die IOP Kontrolleinrichtung 48 die I/O Anfrage durchführt. Stattdessen würde die Arbeit in den CEs 14 nur bis zum Empfang einer Bestätigung ausgesetzt werden, welcher anzeigt, daß der IOP-Monitor 48 damit begonnen hat, die I/O Anfrage zu bearbeiten (Schritt 110). Die Bestätigung enthielte dann die Tageszeit und würde von den CEs 14 dazu verwendet werden, um ihren lokalen Taktgeber zu aktualisieren.
  • Nach dem Senden des IPI Pakets zum IOP Treiber 46 prüft der IOP Monitor 48, ob beide CEs 14 online sind (Schritt 118) und wartet, falls dem so ist, auf eine weitere I/O Anfrage von einem der CEs 14 (Schritt 102).
  • Wenn die Timeout-Periode beendet ist (Schritt 106), schaltet die IOP Kontrolleinrichtung 48 das CE 14 ab, welches nicht geantwortet hat (Schritt 119) und bearbeitet die I/O Anfrage (Schritt 110).
  • Wenn es eine Abweichung zwischen der Prüfsumme der Pakete von den CEs 14 gibt (Schritt 108), prüft der IOP-Monitor 48, ob sich das System 10 im Verfügbarkeitsmodus oder im Integritätsmodus befindet. (Schritt 120).
  • Falls das System 10 im Verfügbarkeitsmodus operiert, schaltet der IOP-Monitor 48 das passende CE 14 aus, basierend auf dem gewählten Verfügbarkeitsmodus (Schritt 122) und bearbeitet die I/O-Anfrage (Schritt 110). Danach prüft der IOP-Monitor 48, ob beide CEs 14 online sind (Schritt 118) und wartet dann auf eine I/O Anfrage von dem CE 14, das online ist, vorausgesetzt, das ausgeschaltete CE 14 wurde nicht repariert oder reaktiviert (Schritt 124). Da das System 10 nicht länger störungsfest ist, wenn eine I/O Anfrage empfangen wird, bearbeitet der IOP- Monitor 48 unverzüglich die I/O Anfrage (Schritt 110).
  • Wenn das System 10 im Integritätsmodus arbeitet, wenn eine Abweichung entdeckt wird, wird der IOP-Monitor 48 beide CEs ausschalten (Schritt 126) und stoppt die Abarbeitung (Schritt 128).
  • Wie weiter in Fig. 1 und 2 dargestellt, führt die System-BIOS, sobald eine Anwendung oder das Betriebssystem von beispielsweise CE 14a einen Nicht-I/O Aufruf an die System-BIOS tätigt, die Anfrage aus und führt die Ergebnisse zurück zu der Anwendung, ohne dabei die Systemsoftware 40 anzusprechen. Gleichwohl unterbricht der CE Treiber 44a die I/O Anfrage, wenn die Anwendung oder das Betriebssytem einen I/O BIOS Aufruf tätigen. Nachdem Abfangen der I/O Anfrage paketiert der CE Treiber 44a die I/O Anfrage in ein IPI Paket und übermittelt das IPI Paket an den IOP 12.
  • Wenn das IPI Modul 16a des IOP 12 die Übertragung eines IPI Pakets von CE 14a registriert, generiert es eine Unterbrechung am IOP Treiber 16. Der IOP Treiber liest daraufhin das IPI Paket.
  • Wie bereits oben erläutert, antwortet der IOP-Monitor 48 den IPI Paketen von CE 14a entsprechend der Prozedur 100. Wie auch schon aufgezeigt, überträgt der IOP Treiber 46 schließlich ein IPI Paket, welches die Ergebnisse der I/O Anfrage und die Tageszeit enthält zu den CEs 14, vorausgesetzt, es treten keine Hardwarefehler auf.
  • Die IPI Module 18 der CEs 14 empfangen das IPI Paket vom IOP 12. Die CE Treiber 44 entpacken das IPI Paket, aktualisieren die Tageszeit der CEs 14 und geben die Kontrolle der CEs 14 zurück an die auf den CEs 14 laufende Anwendung, oder das Betriebssystem.
  • Wenn keine I/O Anfrage innerhalb eines vorgegeben Zeitrotervalls erfolgt, generiert das IPI Modul 18 eines CE 14 eine sogenannte Quantenunterbrechung, welche den CE Treiber 44 der CEs 14 anspricht. In Erwiderung dessen, erzeugt der CE Treiber 44 ein Quantenunterbrechungs-IPI-Paket und überträgt dieses zum IOP 12. Der IOP-Monitor 48 behandelt das Quantenunterbrechungs-IPI-Paket als ein, IPI Paket ohne eine I/O Anfrage. Folglich registriert der IOP-Monitor 48 das hereinkommende Quantenunterbrechungspaket (Schritt 102, Fig. 3) und veranlaßt eine Anfrage an die System BIOS des IOP 12 nach der aktuellen Tageszeit (Schritt 112, Fig. 3), wenn ein passendes Quantenunterbrechungs-IPI-Paket vom anderen CE 14 empfangen wird (Schritte 104, 106 und 108, Fig. 3), veranlaßt eine Anfrage an die System BIOS von IOP 12 nach der geltenden Tageszeit (Schritt 112, Fig. 3). Der IOP-Monitor 48 packt dann die aktuelle Tageszeit in ein Quanten-Antwort-IPI-Paket (Schritt 114, Fig. 3), welches der IOP Treiber 46 dann zu den CEs 14 sendet (Schritt 116, Fig. 3). Die CE Treiber 44 reagieren ihrerseits auf das Quanten-Antwort-IPI-Paket, indem sie die Tageszeit aktualisieren und die Kontrolle über die CEs 14 an die auf den CEs 14 laufende Anwendung oder das Betriebssystem zurückgeben.
  • Falls der IOP-Monitor 48 kein Quantenunterbrechungs-IPI-Paket vom anderen CE 14 innerhalb einer vordefinierten Timeout-Periode empfängt (Schritt 106, Fig. 3), reagiert der IOP-Monitor 48 indem er das nicht antwortende CE 14 abschaltet.
  • Wie in Fig. 1 gezeigt, stellen die IPI Module 16, 18 und die Kabel 20 die gesamte Hardware bereit, die erforderlich ist, um ein störungsfestes System herzustellen, das von auf Intel 486 Standard basierenden Motherboards für die Implementierung der Prozessoren 22, 32 verwendet wird. Ein IPI Modul 16 und ein IPI Modul 18, welche unter Verwendung identischer Boarde implementiert sind, führen jeweils gleiche Funktionen aus.
  • Wie in Fig. 4 dargestellt, enthält ein IPI Modul 18 eine Kontrollschaltung 50, die I/O-Anfragen und -Antworten zwischen dem System BUS des Prozessors 32 eines CE 14 und einer parallelen Schnittstelle 52 des IPI Moduls 18 überträgt. Die parallele Schnittstelle 52 kommuniziert ihrerseits über ein Kabel 20 mit einer parallelen Schnittstelle auf einem IPI-Modul 16. Die parallele Schnittstelle 52 umfaßt einen 16 Bit Datenausgangs-Anschluß 54, einen 16 Bit Dateneingangs-Anschluß 56 und einen Steuerungsanschluß 58. Das Kabel 20 ist dahingehend konfiguriert, daß der Datenausgangs-Anschluß 54 mit dem Daten-Eingangs-Anschluß des IPI Moduls 16 verbunden ist, der Dateneingangs-Anschluß 56 mit dem Datenausgangs-Anschluß des IPI Moduls 16 und der Steuerungsanschluß 58 mit dem Steuerungsanschluß des IPI Moduls 16 verbunden ist. Der Steuerungsanschluß 58 führt ein Handshake-Protokoll zwischen dem IPI Modul 18 und dem IPI Modul 16 aus.
  • Die Kontrollschaltung 50 ist auch mit einem IPI BIOS ROM 60 verbunden. Beim Startup überträgt die Kotrollschaltung 50 das IPI BIOS 42 (Fig. 2), den Inhalt des IPI BIOS ROM 60 über den System BUS des Prozessors 32 zum Prozessor 32.
  • Ein ebenfalls auf dem IPI Modul 18 befindlicher QI-Zähler 62 generiert Quantenunterbrechungen, wie oben erläutert. Der QI-Zähler 62 enthält einen Takteingang 64, der mit der Systemuhr des Prozessors 32 verbunden ist und einen Steuereingang 66, der mit der Kontrollschaltung 50 verbunden ist. Der Steuereingang 66 wird zur Aktivierung und Rücksetzung des Zählerwertes des QI-Zählers 62 verwendet. Wenn der QI-Zähler 62 aktiviert ist, verringert er den Zählerwert um jeweils eins pro Zyklus der Systemuhr des Prozessors 32. Sobald der Zählerwert 0 erreicht, erzeugt der QI-Zähler eine Quantenunterbrechung, die - wie bereits erläutert - den CE Treiber 44 aktiviert (Fig. 2).
  • Der CE Treiber 44 deaktiviert den QI-Zähler 62 am Anfang einer jeden I/O-Übertragung. Der CE Treiber 44 deaktiviert den QI-Zähler 62 durch eine I/O-Schreibanforderung an einer ersten Adresse, bekannt als die QI-Deaktivierungsadresse. Die Kontrollschaltung 50 erkennt die I/O-Schreibanforderung und deaktiviert den QI-Zähler 62 über den Steuereingang 66. Da dieser besondere I/O-Schreibvorgang allein für Kontrollzwecke gedacht ist, leitet ihn die Kontrollschaltung 50 nicht zur parallelen Schnittstelle 52. Am Schluß jeder I/O Übertragung setzt der CE Treiber 44 den QI-Zähler 62 zurück und aktiviert diesen mittels einer I/O-Schreibanforderung an einer zweiten Adresse, bekannt als QI-Aktivierungsadresse. Die Kontrollschaltung 50 reagiert durch Zurücksetzen und Aktivieren des QI- Zählers 62.
  • In einer alternativen Anwendung werden Quantenunterbrechungen durch die Nutzung der Fehlersuchfunktion oder anderer Features, die im Prozessor 32 verfügbar sind, erzeugt. Einige für gewöhnlich erhältliche Prozessoren enthalten Fehlersuch- oder Fangstellen- Anweisungen, die Fehler durch die Übertragung der Steuerung des Prozessors auf ein festgelegtes Programm nach dem Ablauf einer ausgewählten Anzahl von auf die Fangstellen-Anweisung folgenden weiteren Anweisungen, abfangen. Bei diesem Verfahren veranlaßt der CE Treiber 44 jedesmal, wenn er die Kontrolle des Prozessors an die Anwendung oder das Betriebssytem zurückgibt, eine Fangstellen-Anweisung, um anzuzeigen, daß die Kontrolle des Prozessors 32 zum CE Treiber 44 nach dem Ablauf von beispielsweise 300 Anweisungen gegeben werden soll. Nachdem der Prozessor 32 die aufgezeigten 300 Anweisungen abgeschlossen hat, führt die Fangstellen-Anweisung zur Rückgabe der Kontrolle des Prozessors 32 an den CE Treiber 44. Für den Fall, daß eine I/O-Anfrage den CE Treiber 44 vor dem Abschluß 44 der aufgezeigten Anzahl an Anweisungen aktiviert, veranlaßt der CE Treiber 44 eine Anweisung, die die Fangstellen-Anweisung aufhebt.
  • Das IPI-Modul 18 wird auch dazu verwendet, um ein off-line-CE 14 zu aktivieren. Wie noch aufzuzeigen sein wird, wird der Inhalt des Speichersystems 34 des aktiven CE 14 in das Speichersystem des 34 des offline-CE 14 kopiert, bevor das offline-CE 14 aktiviert wird. Um die Auswirkungen dieses Kopiervorgangs am aktiven CE 14 zu minimieren, ist es dem Prozessor 32 des aktiven CE 14 gestattet weiterzuarbeiten und der Speicher wird nur in solchen Zyklen kopiert, in denen der System BUS des Prozessors 32 des aktiven CE 14 nicht benutzt wird.
  • Um den Prozessor 32 in die Lage zu versetzen, weiterzuarbeiten, während der Speicher kopiert wird, legt das IPI Modul 18 die Speicherschreibvorgänge durch den Prozessor 32 in Adressen ab, die bereits zum off-line-CE 14 kopiert wurden. Um dies durchzuführen, regelt die Kontrollschaltung 50 den System BUS und speichert - falls der Prozessor 32 an einer Speicheradresse schreibt, die bereits kopiert wurde - diese Adresse in einem FIFO 68. Sobald der Speichertransfer abgeschlossen, oder der FIFO 68 voll ist, werden die Inhalte der Speicherstellen zusammen mit den im FIFO 68 abgelegten Speicheradressen zum off-line-CE 14 kopiert und der FIFO 68 entleert. Bei anderen Anwendungen ist der FIFO 68 dahingehend modifiziert, daß er sowohl die Speicheradressen, als auch die Inhalte der mit den Adressen zusammengeschlossenen Speicherstellen oder die Blockadressen der Speicherblocks, zu denen die geschriebenen Speicheradressen gehören, ablegt.
  • Das IPI Modul 18 kümmert sich auch um Nicht-BIOS-I/O-Anfragen.
  • In manchen Computer Systemen ist das BIOS zu langsam, um effektiv I/O-Operationen durchzuführen, wie z. B. Videoanzeigen. Als Ergebnis gestatten es einige weniger strukturierte oder weniger disziplinierte Betriebssysteme, wie etwa DOS oder UNIX den Anwendungen, das BIOS zu überlisten und Nicht-BIOS-I/O Anfragen durch das direkte Lesen von oder Schreiben in den Adressen, die mit I/O Geräten verbunden sind, durchzuführen. Diese Nicht-BIOS-I/O-Anfragen, die nicht durch das Ändern der Systemunterbrechungstabelle abgefangen werden können, so wie dies beispielsweise im Zusammenhang mit I/O-Disk Lese- und Schreibvorgängen erfolgt, sind für ein System, in welchem die Synchronisation eine enge Kontrolle der I/O-Schnittstellen verlangt, problematisch.
  • Um dieses Problem zu beheben, und um sicherzustellen, daß selbst Nicht-BIOS-I/O-Anfragen durch den IOP 12 isoliert und verwaltet werden können, enthält das IPI Modul 18 virtuelle I/O-Geräte, die die Hardwareschnittstellen physischer I/O-Geräte nachahmen. Diese virtuellen I/O-Geräte umfassen ein virtuelles Display 70 und ein virtuelles Keyboard 72. Falls nötig, können auch andere virtuelle I/O-Geräte, wie z. B. eine virtuelle Maus, oder virtuelle serielle und parallele Anschlüsse verwendet werden.
  • In der Praxis überwacht die Kontrollschaltung 50 den System BUS in bezug auf Lese- oder Schreiboperationen, die an Adressen gerichtet sind, die mit Nicht-BIOS-I/O-Anfragen an System-I/O-Geräten verbunden sind. Sobald die Kontrollschaltung 50 solch eine Operation entdeckt, speichert die Kontrollschaltung die für eine Rekonstruktion der Operation am entsprechenden virtuellen Gerät notwendigen Information. So legt die Kontrollschaltung 50 beispielsweise, wenn sie eine an die mit dem Display 70 verbundene Adresse gerichtete Schreiboperation registriert, die für eine Rekonstruktion dieser Operation am virtuellen Display 70 erforderlichen Informationen ab. Jedes mal, wenn eine BIOS-I/O-Anfrage oder eine Quantenunterbrechung auftritt, scannt der CE Treiber 44 die virtuellen I/O Geräte und stellt - wenn die virtuellen Geräte nicht leer sind - die in den virtuellen Geräten abgelegten Informationen in einem IPI-Paket zusammen und schickt dieses zum IOP 12. Dieser behandelt das Paket unter Nutzung des oben erörterten Verfahrens 100 wie eine BIOS-I/O- Anfrage. Wenn die Kontrollschaltung 50 einen an ein virtuelles I/O- Gerät adressierten Lesevorgang registriert, assembliert die Kontrollschaltung 50 die Leseanfrage in einem IPI Paket zur Weiterverarbeitung durch IOP 12. Der IOP 12 behandelt das IPI-Paket wie eine Standard-BIOS-I/O-Anfrage.
  • Wie in Fig. 5 gezeigt, operiert jedes CE 14 ständig in einem von acht Zuständen und das System 10 - da es nur eine limitierte Anzahl an zulässigen Zustands-Kombinationen gibt - ständig in einem von 14 Zuständen. Die Haupt-CE-Operationszustände sind OFFLINE, RTB (bereit zum Booten), BOOTING, ACTIVE, RTS (bereit zum Synchronisieren), WAITING, M_SYNC (Synchronisieren als Master) und S_SYNC (Synchronisieren als Slave). Die IOP-Kontrolleinrichtung 48 verändert die Operationszustände der CEs 14 basierend auf dem Status des Systemes 10 und der Nutzerkommandos von der Konsolensoftware 49. 2 Über die Konsolensoftware kann ein Nutzer ein CE 14 jederzeit zurücksetzen. Wann immer ein Nutzer ein CE 14 zurücksetzt, oder eine Störung im CE 14 auftritt, läßt die IOP-Kontrolleinrichtung 48 das CE 14 in den OFFLINE-Zustand wechseln.
  • Beim Startup operiert das System 10 mit beiden CEs 14b OFFLINE (Zustand 150). Das System 10 arbeitet in den oberen Zuständen der Fig. 5 (Zustände 152-162), wenn das CE 14a vor CE 14b zu arbeiten anfängt und in den unteren Zuständen (Zustände 166-176), wenn GE 14b zuerst den Betrieb aufnimmt. Wenn beide CE 14 simultan zu operieren beginnen, wird dasjenige CE 14 als zuerst operierendes behandelt, welches als erstes von der IOP-Kontrolleinrichtung 48 erkannt wird.
  • Wenn ein CE 14 durch eine Boot-Anfrage anzeigt, daß es bereit zum booten ist, wechselt der Zustand des CE 14 zu RTB, sofern das CE 14 nicht auf Autoboot gesetzt ist, oder zu BOOTING, sofern es auf Autoboot gesetzt ist. Falls z. B. CE 14a eine Bootanfrage veranlaßt, wenn beide CEs 14 OFFLINE sind, und CE 14a ist nicht auf Autoboot gesetzt, dann wechselt der Zustand von CE 14a über zu RTB (Zustand 152). Danach wartet der IOP-Monitor darauf, daß der Nutzer über die Konsolensoftware 49 das CE 14a bootet. Sobald der Nutzer das CE 14a bootet, wechselt der Zustand von CE 14a über zu BOOTING (Zustand 154). Wenn der Nutzer das CE 14a zurücksetzt, wechselt der Zustand des CE 14a über zu OFFLINE (Zustand 150).
  • Falls beide CEs 14 offline sind, wenn CE 14a eine Boot-Anfrage und CE 14a auf Autoboot gesetzt ist, wechselt der Zustand von CE 14a über zu BOOTING (Zustand 154). Falls CE 14a erfolgreich bootet, wechselt der Zustand von CE 14a über zu ACTIVE (Zustand 156).
  • Wenn CE 14a ACTIVE ist und CE 14b eine Boot-Anfrage ausgibt, oder wenn CE 14b bereits eine Boot-Anfrage ausgegeben hat, während der Zustand von CE 14a gerade von OFFLINE zu ACTIVE wechselte (Zustände 152-156), wechselt der Zustand von CE 14b über zu RTS (Zustand 158) sofern CE 14b auf Autosynchronisation gesetzt ist und anderenfalls zu WAITING (Zustand 160). Falls der Zustand von CE 14b zu RTS wechselt, wartet die IOP-Monitor auf den Nutzer, um ein Synchronisations-Kommando anzugeben. Sofern der Nutzer ein solches Kommando veranlaßt, wechselt der Zustand von CE 14b über zu WAITING. (Zustand 160).
  • Wenn sich CE 14b im WAITING-Zustand befindet, kopiert der IOP- Monitor 48 die Inhalte des Speichersystems 34a von CE 14a in das Speichersystem 34b von CE 14b. Sobald der Speichertransfer abgeschlossen ist, wartet der IOP-Monitor 48 auf CE 14a, um eine Quantenunterbrechung oder ein I/O-Anfrage-IPI-Paket zu übertragen. Nach dem Erhalt eines solchen Pakets wechselt der IOP-Monitor 48 den 1 Zustand von CE 14a zu M SYNC und den Zustand von CE 14b zu S_SYNC (Zustand 162) und synchronisiert die CEs 14. Diese Sysnchronisation reagiert auf jede Speicherveränderung, die aufgetreten ist, während der IOP- Monitor 48 auf CE 14a wartete, um eine Quantenunterbrechung oder ein I/O Anfrage-IPI-Paket zu übertragen. Nach der Beendigung der Synchronisation, wechseln die Zustände beider CEs 14 über zu ACTIVE (Zustand 164) und das System 10 kann als vollständig betriebsbereit angesehen werden.
  • In einer alternativen Anordnung wartet der IOP-Monitor 48 nicht auf den Abschluß des Speichertransfers bevor sie den Zustand des CE 14a in M_SYNC und den Zustand von CE 14b in S_SYNC (162) ändert. Stattdessen macht der IOP-Monitor 48 diese Statusänderung erst nach dem Erhalt eines IPI-Pakets von CE 14a und führt den Speichertransfer als Teil des Synchronisationsprozesses durch.
  • Ähnliche Zustandsübergänge treten auf, wenn CE 14b als erstes eine Boot-Anfrage veranlaßt. Vorausgesetzt, CE 14b ist nicht auf Autoboot gesetzt, geht CE 14b folglich von OFFLINE (Zustand 150) über zu RTC (Zustand 166) über zu BOOTING (Zustand 168) über zu ACTIVE (Zustand 170). Ist CE 14b auf ähnliche Weise erst einmal ACTIVE, geht CE 14a - und vorausgesetzt es ist nicht auf Autosync gesetzt - vom OFFLINE (Zustand 170) entsprechend über zu RTS (Zustand 172) über zu WAITING (Zustand 174) über zu S SYNC (Zustand 176) über zu ACTIVE (Zustand 164).
  • Wie in Fig. 6 dargestellt, beinhaltet ein fehlerfestes System 200 zwei IOPs 202 und zwei CEs 204. Jedes CE 204 ist über eine IPI Karte 206 und ein Kabel 208 mit jeweils einer IPI Karte 210 der IOPs 202 verbunden. Die IOPs 202 sind redundant über IPI Karten 210 und Kabel 212 miteinander verbunden. Da jede Komponente des Systems 200 eine redundante Backup-Komponente hat, ist dieses Sytem vollkommen fehlerfest. In einer alternativen Anwendung können die Kabel 208 und 210 durch ein Paar lokaler Rechnernetze ausgetauscht werden, mit welchen jeder IOP 202 und jedes CE 204 verbunden sind. Tatsächlich können lokale Rechnernetze immer Kabelverbindungen ersetzen.
  • Das System 200 ist dahingehend unabhänging von Betriebssystem und Anwendungssoftware, dahingehend, als daß es keiner Modifikationen am Betriebssystem, oder der Anwendungssoftware bedarf, damit diese laufen. Jedes einzelne Harwareteil kann ohne eine Betriebsunterbrechung aufgewertet oder repariert werden. Daher kann bei einem sequentiellen Ersetzen eines jeden Hardwareteils, wobei es dem System 200 gestattet ist, nach jeder Entfernung eine Synchronisation durchzuführen, die Hardware in ihrer Gesamtheit ersetzt werden, ohne daß es zu einer Betriebsunterbrechung kommt. Auf ähnliche Weise kann die Software auf dem System 200 mit minimalen Betriebsunterbrechungen aufgewertet werden. (d. h., daß während dem Software-Upgrade die Anwendung für eine akzeptable Zeitperiode von z. B. 2 Sekunden nicht verfügbar sein wird). Vor dem Hintergrund der Verfügbarkeit kann auch Katastrophentoleranz erlangt werden, indem man jedes IOP/CE Paar an separaten Orten plaziert und sie über Kommunikationsverbinungen zusammenschließt.
  • Wie in Fig. 7 dargestellt, enthält ein gegliedertes, störungsfestes Hochleistungssystem 220 zwei Systeme 200, deren IOPs 202 über IPI-Module durch Kabel 222 miteinander verbunden sind. Das System 220 nutzt eine gegliederte Rechnerumgebungssoftware, um durch das Laufenlassen separater Teile der Anwendung auf jedem der Systeme 200, die Hochleistung zu erreichen. Das System 220 ist störungstolerant und bietet die Fähigkeit sowohl Hardware- als auch Software-Upgrades ohne eine Betriebsunterbrechung durchzuführen.
  • Wie in Fig. 8 gezeigt, beinhaltet ein störungstolerantes System 230 drei IOPs (232, 234 und 236) und drei CEs (238, 240 und 242).
  • Über IPI-Module 244 und Kabel 246 ist jeder IOP mit einem IOP-Modul 244 eines jeden der anderen IOPs verbunden. Über IPI-Module 248 und Kabel 250 ist jedes CE mit einem IPI Modul 244 von einem der IOPs verbunden, wobei CE 238 mit den IOPs 232 und 234, CE 240 mit den IOPs 232 und 236 und CE 242 mit den IOPs 234 und 236 verbunden ist. Ebenso wie das System 200, gestattet das System 230 Hardware-Upgrades und Software-Upgrades mit nur minimaler Betriebsunterbrechung.
  • Wie aus einem Vergleich der Fig. 7 und 8 hervorgeht, sind die CEs und IOPs der Systeme 200 und 300 identisch konfiguriert. Als eine Folge davon bedarf es bei einer Aufstockung des störungsfesten Systems 200 zu einem störungstoleranten System 230 keines Hardwareaustausches und beschränkt sich auf den einfachen Vorgang des Hinzufügens eines weiteren CE/IOP Paares, des Verbindes der Kabel und der Anpassung der Systemsoftware. Diese Modularität ist ein wichtiges Merkmal der erfindungsgemäßen Paar-Modular-Redundanz Anordnung.
  • Da die Komponenten des Systems 230 dreifach redundant sind, ist das System 230 eher dazu fähig, die Quelle einer Hardwarestörung zu identifizieren, als dies beim System 10 der Fall ist. Während somit das System 10 einfach eines oder beide der CEs 14 ausschaltet, sobald ein Fehler registriert wird, bietet das System 230 einen höheren Grad an Fehlerdiagnose.
  • Wie in Fig. 9 aufgezeigt, führt jedes der IOP (232, 234 und 236) des Systems 230 die Fehlerdiagnose in Übereinstimmung mit einem Verfahren 300 aus. Zuerst prüft jeder IOP (232, 234, 236) die Hauptfehler wie z. B. Leistungsverlust, gebrochene Kabel und nicht funtionstüchtige CEs oder IOPs, wobei bekannte Techniken, wie beispielsweise Leistungsmessung, Kabelmessung und Protocol Timeouts (Schritt 302) verwendet werden. Wenn eine solche Störung auftritt, schaltet jeder IOP das fehlerhafte Gerät und wenn nötig das gesamte System aus.
  • Nach der Prüfung der Hauptfehler, wartet jeder IOP darauf, IPI Pakete (d. h. Quantenunterbrechungen oder I/P Anfragen) von den zwei CEs, mit denen er verbunden ist, zu erhalten (Schritt 304). So wartet IOP 232 beispielsweise darauf, IPI-Pakete von den CEs 238 und 240 zu erhalten. Nach dem Erhalt der IPI-Pakete von den beiden verbundenen CEs, übermittelt jeder IOP die Prüfsummen ("CRCs") dieser IPI-Pakete zu den anderen zwei IOPs und wartet auf den Empfang der CRCs dieser anderen beiden IOPs (Schritt 306).
  • Nach dem Erhalt der CRCs von den anderen beiden IOPs, generiert jeder IOP eine 3 · 3 Matrix in welcher jede Spalte einem CE, jede Zeile einem IOP und jeder Eintrag einer CRC der CEs, die von den entsprechenden IOP's empfangen wurden entspricht. So generiert IOP 232 beispielsweise die folgende Matrix.
  • Nach dem Generieren der Matrix summiert IOP 232 die Einträge in jeder Zeile und jeder Spalte der Matrix. Falls die drei Zeilensummen und die drei Spaltensummen jeweils übereinstimmen (Schritt 302), dann gibt es keine Störung und der IOP 232 prüft erneut auf Hauptfehler.
  • Falls aber entweder die drei Zeilensummen oder die drei Spaltensummen voneinander abweichen (Schritt 310), dann vergleicht der IOP 232 die CRC-Einträge in jeder der Matrixspalten. Wenn die zwei CRC Einträge in jeder Matrixspalte übereinstimmen (Schritt 312), dann diagnostiziert der IOP 232, daß eine CE-Störung aufgetreten ist und schaltet das CE korrespondierend zu der Spalte, in welcher die Summe nicht gleich den Summen der anderen Spalten ist, ab (Schritt 314).
  • Wenn die CRC Einträge in einer oder mehreren der Matrixspalten nicht übereinstimmen (Schritt 312), dann bestimmt der IOP 232, wie viele der Spalten abweichende Einträge enthalten. Falls die Matrix nur eine Spalte mit nicht übereinstimmenden Einträgen enthält (Schritt 315), dann diagnostiziert der IOP 232, daß die Leiterbahn zwischen dem IOP, entsprechend der Matrixzeilensumme, die von den übrigen Matrixzeilensummen abweicht und dem CE entsprechend der Matrixspalte, die nicht übereinstimmende Einträge hat, gestört ist und deaktiviert diese Leiterbahn (Schritt 316). Für Diagnosezwecke umfaßt die Leiterbahn das IPI-Modul 244 im IOP, das IPI-Modul 248 im CE und das Kabel 250.
  • Falls die Matrix mehr als eine Spalte mit nicht übereinstimmenden Einträgen enthält (Schritt 314), bestätigt der IOP 232, daß eine Matrixzeilensumme ungleich zu den übrigen Matrixzeilensummen ist, diagnostiziert eine IOP-Störung und schaltet den der Matrixzeilensumme, die von den übrigen abweicht, entsprechenden IOP ab (Schritt 318).
  • Sofern der IOP nach dem Diagnostizieren und dem Verbuchen ent weder einer CE-Störung (Schritt 314), einer Leiterbahnstörung (Schritt 316) oder einer IOP-Störung (Schritt 318), feststellt, daß das System 300 noch immer genügend störungsfreie Hardware enthält, um arbeitsfähig zu bleiben, prüft der IOP 232 nochmals auf Hauptfehler (Schritt 302). Da das System 230 dreifach redundant ist, kann das System 230 weiterarbeiten, selbst wenn einige Komponenten ausgefallen sind. Um beispielweise in einem Verfügbarkeitsmodus weiter operieren zu können, benötigt das System 230 lediglich ein einzelnes funktionierendes CE, einen einzelnen funktionierenden IOP und eine funtionstüchtige Leiterbahn zwischen beiden.
  • Mittels dem Verfahren 300, kann jeder IOP (232, 234, 236) jede einzelne Störung in einem vollständig arbeitsfähigem System 230 oder in einem System 230, in welchem ein Element (d. h. ein CE, ein IOP oder eine Leiterbahn) zuvor ausgeschaltet wurde, korrekt diagnostizieren. In einem System 230, in welchen ein Element ausgeschaltet wurde, verbucht jeder IOP die CRCs, die wegen dem ausgeschalteten Element nicht empfangen wurden, mittels Nutzung von Werten, die im Vergleich zu tatsächlich empfangenen CRCs als korrekt erscheinen.
  • Das Verfahren 300 ist nicht abhängig von einer besonderen Anordnung oder Schaltverbindung der CEs oder IOPs. Um entsprechen zu funktionieren, erfordert das Verfahren 300 lediglich, daß der Output eines jeden CEs direkt von mindestens zwei IOPs überwacht wird. Daher kann das Verfahren 300 bei einem System angewendet werden, das jede Art von Schaltverbindungsmechanismen nutzt und erfordert keine Punkt zu Punkt Verbindung zwischen den CEs und den IOPs. Beispielsweise könnten die CEs und die IOPs auch mit mindestens zwei lokalen Rechnernetzen verbunden sein. Bei einer alternativen Anwendungen können, statt dem Summieren der CRC-Werte in den Zeilen und Spalten der Matrix, diese Werte auch einfach verglichen werden, und diejenigen Zeilen oder Spalten, in welchen die Einträge nicht übereinstimmen, können mit einer Übereinstimm/Abweich- Kennzeichnung versehen werden.
  • Eine vereinfachte Version des Verfahrens 300 kann in einem System 200 eingesetzt werden. Bei diesem Verfahren generiert jeder IOP 202 des Systems 200 eine 2 · 2 Matrix in welcher jede Spalte mit einem CE 204 und jede Zeile mit einem IOP 202 korrespondiert.
  • Nach dem Generieren der Matrix fügt jeder IOP 202 eine Abweich- Kennzeichnung in jede Zeile oder Spalte, in welcher die zwei Einträge abweichen.
  • Sofern es keine solchen Abweich-Kennzeichnungen gibt, arbeitet das System 200 korrekt.
  • Wenn keine Zeile und beide Spalten Abweich-Kennzeichnungen aufweisen, dann wurde ein IOP 202 gestört. In Abhängigkeit vom Operationsmodus des Systems 200 schaltet ein IOP 202 dann den anderen IOP 202 oder das ganze System 200 ab. Der abzuschaltende IOP 202 wird basierend auf vom Nutzer bereitgestellten Parametern ausgewählt, ähnlich wie in den zwei Verfügbarkeitsmodi, die in System 10 verwendet werden.
  • Wenn beide Zeilen und keine Spalte Abweich-Kennzeichnungen aufweisen, dann wurde ein CE 204 gestört. In diesem Fall reagieren die IOPs 202, indem sie ein CE 204 abschalten, falls das System 200 im Verfügbarkeitsmodus arbeitet, oder fahren das System 200 herunter, falls das System 200 im Integritätsmodus arbeitet. Wenn beide Zeilen und eine Spalte Abweich-Kennzeichnungen aufweisen, dann wurde eine der Leiterbahnen zwischen den IOPs 201 und dem CE 204 entsprechend der abweichenden Spalte gestört. Je nach Operationsmodus des Systems 200 schalten die IOPs 202 entweder das CE 204 mit der fehlerhaften Leiterbahn ab oder fahren das ganze System 200 herunter. Wenn beide Zeilen und beide Spalten Abweich-Kennzeichnungen aufweisen, dann exisiert eine multiple Störung und die IOPs 202 fahren das System 200 herunter. Wenn eine Zeile und beide Spalten Abweich-Kennzeichnungen aufweisen, dann wurde der der Abweichung entsprechende IOP 202 gestört. In Abhängigkeit vom jeweiligen Operationsmodus des Systems 200 schalten der andere IOP 202 entweder den fehlerhaften IOP 202 ab oder fährt das System 200 herunter.
  • Wenn eine Zeile und eine Spalte Abweich-Kennzeichnungen aufweisen, dann wurde die Leiterbahn zwischen dem der abweichenden Zeile entsprechenden IOP 202 und dem der abweichenden Spalte entsprechenden CE 204 gestört. In Abhängigkeit vom Operationsmodus des Systems 200 verbuchen die IOPs 202 die fehlerhafte Leiterbahn entweder in zukünftigen Prozessen, oder fahren das System 200 herunter.
  • Wie in Fig. 10 dargestellt, umfaßt eine Ausführugsform eines katastrophentoleranten Systems 260 zweifehlertolerante Systeme 230, die an voneinander entfernten Orten angeordnet sind und über Kommunikationsverbindungen 262, wie z. B. Ethernet oder Glasfaser, zusammengeschlossen sind und miteinander in einem Zwischen-Zeit-Blockierschritt operieren. Um einen Zwischen-Zeit- Blockierschritt zu erhalten, werden alle IPI-Pakete zwischen den störungstoleranten Systemen 230 übertragen. Wie das System 220, gestattet auch das System 260 Hard- und Software-Upgrades ohne eine Betriebsunterbrechung.
  • Wie gezeigt, erlaubt die gepaarte Modular-Redundanz Architektur die Stufen der Störungsfestigkeit und Störungstoleranz durch die Verwendung von CEs, die asynchron in Echtzeit operieren und von IOPs kontrolliert werden, damit sie synchron in der Zwischen-Zeit operieren, zu variieren. Diese Architektur ist einfach und kostengünstig und kann mit minimalem Aufwand erweitert oder aufgerüstet werden.

Claims (16)

1. Verfahren zum Synchronisieren von wenigstens zwei Rechenelementen in einem Computersystem, umfassend die wenigstens zwei Rechenelemente und wenigstens einen Controller, wobei jedes der Rechenelemente Taktgeber enthält, die zu den Taktgebern der anderen Rechenelemente asynchron arbeiten, wobei das Verfahren folgende Schritte umfasst:
Auswahl eines oder mehrerer Signale aus der Signalfolge, die durch die Rechenelemente erzeugt worden sind;
Überwachung der Rechenelemente, um die Erzeugung eines ausgewählten Signales durch eines der Rechenelemente zu erkennen;
Abwarten auf die Erzeugung eines ausgewählten Signales durch ein anderes Rechenelement nach der Erkennung eines ausgewählten Signales durch eines der Rechenelemente;
dadurch gekennzeichnet, daß
Abgleichsignale von wenigstens einem Controller zu jedem der Rechenelemente nach dem Empfang von ausgewählten Signalen von allen Rechenelementen gesendet werden; und
die Takte der Rechenelemente werden basierend auf den Zeitabgleichsignalen abgeglichen;
die ausgewählten Signale enthalten I/O-Anforderungen;
wenn ein ausgewähltes Signal eine I/O-Anforderung enthält, wird eine I/O-Anforderung an wenigstens einen der Controller gesendet, um eine I/O-Antwort zu erzeugen; und
wenn das ausgewählte Signal eine I/O-Anforderung enthält, wird jedes Abgleichsignal mit der I/O-Anforderung übertragen.
2. Verfahren nach Anspruch 1 weiterhin umfassend die Schritte der Ausbildung eines störungsfesten Rechners aus den wenigstens zwei Rechenelementen und dem wenigstens einen Controller.
3. Verfahren nach Anspruch 1 oder 2, wobei die Auswahlschritte den Schritt der Auswahl von Quantenunterbrechungen und I/O- Anforderungen als die ausgewählten Signale umfassen.
4. Verfahren nach Anspruch 1 oder 2, wobei die Auswahlschritte den Schritt der Auswahl von Quantenunterbrechungen als eines der ausgewählten Signale umfassen.
5. Verfahren nach Anspruch 4, weiterhin umfassend den Schritt der Erzeugung von Quantenunterbrechungen in jedem Rechenelement durch Zählung der Taktzyklen in den Rechenelementen.
6. Verfahren nach Anspruch 5, wobei der Schritt der Zählung der Taktzyklen die Zählung der Zyklen eines ausgewählten Zyklus der Systemuhr, einer I/O-Uhr und einer BUS-Uhr umfasst.
7. Verfahren nach Anspruch 5, weiterhin umfassend die Schritte:
Laden eines Zählers in jedem der Rechenelemente mit einem vorgegebenen Wert;
Versorgen des Zählers in jedem der Rechenelemente mit einer I/O-Anforderung;
Verringerung des Betrages des Zählers während eines Taktzyklus in jedem der Rechenelemente; und
Signalisieren eines Quanteninterruptes von einem Rechenelement, wenn der Wert des Zählers des Rechenelementes null erreicht.
8. Verfahren nach Anspruch 4, weiterhin umfassend den Schritt der Erzeugung des Quanteninterruptes durch Zählen der ausgeführten Anweisungen in jedem Rechenelement.
9. Verfahren nach Anspruch 4, weiterhin umfassend den Schritt der Verwendung von Elementen zur Fehlerbeseitigung in jeden Rechenelement um Quanteninterrupte zu Erzeugen.
10. Verfahren nach einem der vorhergehenden Ansprüche, weiterhin umfassend den Schritt des Unterhaltens einer Liste der ausgewählten Signale für jedes Rechenelement, die durch das Rechenelement erzeugt wurden, wobei die Abgleichsignale übertragen werden, wenn die Listen für jedes Rechenelement einen gemeinsamen Zugriff enthalten.
11. Verfahren nach einem der vorhergehenden Ansprüche, weiterhin umfassend die Schritte:
Vergleich der ausgewählten Signale, die durch die Rechenelemente erzeugt wurden und der Daten die möglicherweise zu den ausgewählten Signalen gehören, und
Signalisierung, daß ein Fehler eingetreten ist, wenn die ausgewählten Signale oder die zugehörigen Daten nicht zusammenpassen.
12. Verfahren nach einem der vorhergehenden Ansprüche, weiterhin umfassend die Schritte: Stoppen der Arbeit jedes Rechenelementes nachdem dieses Rechenelement ein ausgewähltes Signal erzeugt, und Fortsetzen der Arbeit eines Rechenelementes bei Empfang eines Update-Signales durch das Rechenelement.
13. Verfahren nach einem der vorhergehenden Ansprüche, weiterhin umfassend den Schritt der Fortsetzung der Opera tion eines Rechenelementes nach der Erzeugung des ausgewählten Signales.
14. Verfahren nach einem der vorhergehenden Ansprüche, weiterhin umfassend die Schritte:
Verhindern von asynchronen Aktivitäten der Rechenelemente; und
Durchführung der Funktion der asynchronen Aktivitäten in einem Rechenelement wenn das Rechenelement ein ausgewähltes Signal erzeugt.
15. Verfahren nach Anspruch 14 wobei der Sperrschritt den Schritt des Sperrens der normalen Speicher-Refreshfunktion umfasst und der Ausführschritt den Schritt der Durchführung eines stoßartigen Speicher-Refreshes umfasst, wenn das ausgewählte Signal erzeugt wird.
16. Verfahren nach Anspruch 15 wobei der Sperrschritt weiterhin die Schritte umfasst:
Setzen eines Zählers, der bei normalen Refresh-Funktionen verwendet wird in einen Modus, der ein Eingangssignal für eine Torschaltung zur Änderung erfordert und
Verbinden der Torschaltung mit einer stabilisierten Spannung.
DE69424565T 1993-12-01 1994-11-15 Fehler-betriebssichere/fehler tolerante computerbetriebsmethode Expired - Lifetime DE69424565T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15978393A 1993-12-01 1993-12-01
PCT/US1994/013350 WO1995015529A1 (en) 1993-12-01 1994-11-15 Fault resilient/fault tolerant computing

Publications (2)

Publication Number Publication Date
DE69424565D1 DE69424565D1 (de) 2000-06-21
DE69424565T2 true DE69424565T2 (de) 2001-01-18

Family

ID=22574001

Family Applications (3)

Application Number Title Priority Date Filing Date
DE69435090T Expired - Fee Related DE69435090T2 (de) 1993-12-01 1994-11-15 Rechnersystem mit Steuereinheiten und Rechnerelementen
DE69424565T Expired - Lifetime DE69424565T2 (de) 1993-12-01 1994-11-15 Fehler-betriebssichere/fehler tolerante computerbetriebsmethode
DE69435165T Expired - Lifetime DE69435165D1 (de) 1993-12-01 1994-11-15 Fehlerbetriebssichere/Fehlertolerante Computerbetriebsmethode

Family Applications Before (1)

Application Number Title Priority Date Filing Date
DE69435090T Expired - Fee Related DE69435090T2 (de) 1993-12-01 1994-11-15 Rechnersystem mit Steuereinheiten und Rechnerelementen

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE69435165T Expired - Lifetime DE69435165D1 (de) 1993-12-01 1994-11-15 Fehlerbetriebssichere/Fehlertolerante Computerbetriebsmethode

Country Status (6)

Country Link
US (4) US5600784A (de)
EP (4) EP0986008B1 (de)
AU (4) AU680974B2 (de)
CA (1) CA2177850A1 (de)
DE (3) DE69435090T2 (de)
WO (1) WO1995015529A1 (de)

Families Citing this family (127)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5838894A (en) * 1992-12-17 1998-11-17 Tandem Computers Incorporated Logical, fail-functional, dual central processor units formed from three processor units
US5978565A (en) * 1993-07-20 1999-11-02 Vinca Corporation Method for rapid recovery from a network file server failure including method for operating co-standby servers
CA2177850A1 (en) * 1993-12-01 1995-06-08 Thomas Dale Bissett Fault resilient/fault tolerant computing
SE506739C2 (sv) * 1995-09-29 1998-02-09 Ericsson Telefon Ab L M Drift och underhåll av klockdistributionsnät med redundans
US5819020A (en) * 1995-10-16 1998-10-06 Network Specialists, Inc. Real time backup system
FR2748136B1 (fr) * 1996-04-30 1998-07-31 Sextant Avionique Module electronique avec architecture redondante pour controle d'integrite du fonctionnement
US5793943A (en) * 1996-07-29 1998-08-11 Micron Electronics, Inc. System for a primary BIOS ROM recovery in a dual BIOS ROM computer system
US5790397A (en) 1996-09-17 1998-08-04 Marathon Technologies Corporation Fault resilient/fault tolerant computing
TW355762B (en) * 1996-12-26 1999-04-11 Toshiba Co Ltd Checkpoint rollback I/O control device and I/O control method
US5892897A (en) * 1997-02-05 1999-04-06 Motorola, Inc. Method and apparatus for microprocessor debugging
US6161202A (en) * 1997-02-18 2000-12-12 Ee-Signals Gmbh & Co. Kg Method for the monitoring of integrated circuits
US7389312B2 (en) 1997-04-28 2008-06-17 Emc Corporation Mirroring network data to establish virtual storage area network
US5896523A (en) * 1997-06-04 1999-04-20 Marathon Technologies Corporation Loosely-coupled, synchronized execution
US5983371A (en) * 1997-07-11 1999-11-09 Marathon Technologies Corporation Active failure detection
FR2767935B1 (fr) * 1997-09-04 1999-11-12 Bull Sa Procede pour synchroniser un systeme informatique et systeme informatique ainsi synchronise
US6289022B1 (en) * 1997-10-21 2001-09-11 The Foxboro Company Methods and systems for fault-tolerant data transmission
JP2001523855A (ja) 1997-11-14 2001-11-27 マラソン テクノロジーズ コーポレイション 故障回復／耐故障計算機
US6185662B1 (en) 1997-12-22 2001-02-06 Nortel Networks Corporation High availability asynchronous computer system
US6374364B1 (en) 1998-01-20 2002-04-16 Honeywell International, Inc. Fault tolerant computing system using instruction counting
DE19815263C2 (de) * 1998-04-04 2002-03-28 Astrium Gmbh Vorrichtung zur fehlertoleranten Ausführung von Programmen
US6138198A (en) * 1998-06-15 2000-10-24 Sun Microsystems, Inc. Processor bridge with dissimilar data registers which is operable to disregard data differences for dissimilar data write accesses
US6141718A (en) * 1998-06-15 2000-10-31 Sun Microsystems, Inc. Processor bridge with dissimilar data registers which is operable to disregard data differences for dissimilar data direct memory accesses
US6247143B1 (en) 1998-06-30 2001-06-12 Sun Microsystems, Inc. I/O handling for a multiprocessor computer system
US20020153283A1 (en) * 1998-12-28 2002-10-24 Arthur W Chester Gasoline sulfur reduction in fluid catalytic cracking
US6974787B2 (en) 1998-08-31 2005-12-13 Exxonmobil Corporation Gasoline sulfur reduction in fluid catalytic cracking
US6321279B1 (en) * 1998-09-14 2001-11-20 Compaq Computer Corporation System for implementing intelligent I/O processing in a multi-processor system by redirecting I/O messages to a target central processor selected from the multi-processor system
US6219828B1 (en) * 1998-09-30 2001-04-17 International Business Machines Corporation Method for using two copies of open firmware for self debug capability
WO2000036492A2 (en) * 1998-12-18 2000-06-22 Triconex Corporation Method and apparatus for processing control using a multiple redundant processor control system
US7803267B2 (en) * 1998-12-28 2010-09-28 W. R. Grace & Co.-Conn. Gasoline sulfur reduction in fluid catalytic cracking
US6430639B1 (en) 1999-06-23 2002-08-06 Advanced Micro Devices, Inc. Minimizing use of bus command code points to request the start and end of a lock
US6324692B1 (en) * 1999-07-28 2001-11-27 Data General Corporation Upgrade of a program
US6735716B1 (en) * 1999-09-27 2004-05-11 Cisco Technology, Inc. Computerized diagnostics and failure recovery
FR2803057B1 (fr) * 1999-12-22 2002-11-29 Centre Nat Etd Spatiales Systeme informatique tolerant aux erreurs transitoires et procede de gestion dans un tel systeme
AU2001293360A1 (en) * 2000-04-13 2001-10-30 Stratus Technologies International, S.A.R.L. Method and system for upgrading fault-tolerant systems
US6633996B1 (en) 2000-04-13 2003-10-14 Stratus Technologies Bermuda Ltd. Fault-tolerant maintenance bus architecture
US6691257B1 (en) 2000-04-13 2004-02-10 Stratus Technologies Bermuda Ltd. Fault-tolerant maintenance bus protocol and method for using the same
US6820213B1 (en) 2000-04-13 2004-11-16 Stratus Technologies Bermuda, Ltd. Fault-tolerant computer system with voter delay buffer
US6708283B1 (en) 2000-04-13 2004-03-16 Stratus Technologies, Bermuda Ltd. System and method for operating a system with redundant peripheral bus controllers
US6735715B1 (en) 2000-04-13 2004-05-11 Stratus Technologies Bermuda Ltd. System and method for operating a SCSI bus with redundant SCSI adaptors
US6687851B1 (en) 2000-04-13 2004-02-03 Stratus Technologies Bermuda Ltd. Method and system for upgrading fault-tolerant systems
US6691225B1 (en) 2000-04-14 2004-02-10 Stratus Technologies Bermuda Ltd. Method and apparatus for deterministically booting a computer system having redundant components
US6813721B1 (en) 2000-09-20 2004-11-02 Stratus Computer Systems, S.A.R.L. Methods and apparatus for generating high-frequency clocks deterministically from a low-frequency system reference clock
US6718474B1 (en) 2000-09-21 2004-04-06 Stratus Technologies Bermuda Ltd. Methods and apparatus for clock management based on environmental conditions
EP1225741B1 (de) * 2000-10-30 2007-08-22 Siemens Aktiengesellschaft Hochgeschwindigkeitsverbindung für eingebettete Systeme in einem Rechnernetzwerk
US7225467B2 (en) 2000-11-15 2007-05-29 Lockheed Martin Corporation Active intrusion resistant environment of layered object and compartment keys (airelock)
US7213265B2 (en) * 2000-11-15 2007-05-01 Lockheed Martin Corporation Real time active network compartmentalization
US6801876B2 (en) * 2000-12-08 2004-10-05 Caterpillar Inc Method and apparatus of managing time for a processing system
GB2370380B (en) 2000-12-19 2003-12-31 Picochip Designs Ltd Processor architecture
EP1231537A1 (de) * 2001-02-09 2002-08-14 Siemens Aktiengesellschaft Automatische Inbetriebnahme eines Clustersystems nach einem heilbaren Fehler
US6766479B2 (en) 2001-02-28 2004-07-20 Stratus Technologies Bermuda, Ltd. Apparatus and methods for identifying bus protocol violations
US7065672B2 (en) * 2001-03-28 2006-06-20 Stratus Technologies Bermuda Ltd. Apparatus and methods for fault-tolerant computing using a switching fabric
US6928583B2 (en) * 2001-04-11 2005-08-09 Stratus Technologies Bermuda Ltd. Apparatus and method for two computing elements in a fault-tolerant server to execute instructions in lockstep
US6996750B2 (en) * 2001-05-31 2006-02-07 Stratus Technologies Bermuda Ltd. Methods and apparatus for computer bus error termination
JP2004046455A (ja) * 2002-07-10 2004-02-12 Nec Corp 情報処理装置
JP3982353B2 (ja) * 2002-07-12 2007-09-26 日本電気株式会社 フォルトトレラントコンピュータ装置、その再同期化方法及び再同期化プログラム
JP2004046599A (ja) 2002-07-12 2004-02-12 Nec Corp フォルトトレラントコンピュータ装置、その再同期化方法及び再同期化プログラム
EP1398699A1 (de) * 2002-09-12 2004-03-17 Siemens Aktiengesellschaft Verfahren zur Ereignissynchronisation, insbesondere für Prozessoren fehlertoleranter Systeme
US20070061884A1 (en) * 2002-10-29 2007-03-15 Dapp Michael C Intrusion detection accelerator
US7146643B2 (en) * 2002-10-29 2006-12-05 Lockheed Martin Corporation Intrusion detection accelerator
US20040083466A1 (en) * 2002-10-29 2004-04-29 Dapp Michael C. Hardware parser accelerator
US7080094B2 (en) * 2002-10-29 2006-07-18 Lockheed Martin Corporation Hardware accelerated validating parser
US7507686B2 (en) * 2002-12-03 2009-03-24 W. R. Grace & Co. - Conn. Gasoline sulfur reduction in fluid catalytic cracking
GB2396446B (en) * 2002-12-20 2005-11-16 Picochip Designs Ltd Array synchronization
US7320084B2 (en) * 2003-01-13 2008-01-15 Sierra Logic Management of error conditions in high-availability mass-storage-device shelves by storage-shelf routers
US7467326B2 (en) * 2003-02-28 2008-12-16 Maxwell Technologies, Inc. Self-correcting computer
CN100470480C (zh) * 2003-02-28 2009-03-18 洛克希德马丁公司 分析程序加速器装置以及更新其的方法
US20050010811A1 (en) * 2003-06-16 2005-01-13 Zimmer Vincent J. Method and system to support network port authentication from out-of-band firmware
US20050039074A1 (en) * 2003-07-09 2005-02-17 Tremblay Glenn A. Fault resilient/fault tolerant computing
US7146530B2 (en) * 2003-07-18 2006-12-05 Hewlett-Packard Development Company, L.P. Targeted fault tolerance by special CPU instructions
DE102004005680A1 (de) * 2004-02-05 2005-08-25 Bayerische Motoren Werke Ag Vorrichtung und Verfahren zur Ansteuerung von Steuergeräten in einem Bordnetz eines Kraftfahrzeuges
US7321985B2 (en) * 2004-02-26 2008-01-22 International Business Machines Corporation Method for achieving higher availability of computer PCI adapters
DE102004011933B4 (de) * 2004-03-11 2008-04-10 Dr.Ing.H.C. F. Porsche Ag Stromabnahmeeinrichtung für ein spurgeführtes Spielfahrzeug
US8799706B2 (en) 2004-03-30 2014-08-05 Hewlett-Packard Development Company, L.P. Method and system of exchanging information between processors
US20050240806A1 (en) * 2004-03-30 2005-10-27 Hewlett-Packard Development Company, L.P. Diagnostic memory dump method in a redundant processor
US20060020852A1 (en) * 2004-03-30 2006-01-26 Bernick David L Method and system of servicing asynchronous interrupts in multiple processors executing a user program
US7426656B2 (en) * 2004-03-30 2008-09-16 Hewlett-Packard Development Company, L.P. Method and system executing user programs on non-deterministic processors
JP2006178616A (ja) * 2004-12-21 2006-07-06 Nec Corp フォールトトレラントシステム、これで用いる制御装置、動作方法、及び動作プログラム
JP4182948B2 (ja) * 2004-12-21 2008-11-19 日本電気株式会社 フォールト・トレラント・コンピュータシステムと、そのための割り込み制御方法
JP2006178636A (ja) * 2004-12-21 2006-07-06 Nec Corp フォールトトレラントコンピュータ、およびその制御方法
US7496787B2 (en) 2004-12-27 2009-02-24 Stratus Technologies Bermuda Ltd. Systems and methods for checkpointing
US7467327B2 (en) * 2005-01-25 2008-12-16 Hewlett-Packard Development Company, L.P. Method and system of aligning execution point of duplicate copies of a user program by exchanging information about instructions executed
US7328331B2 (en) * 2005-01-25 2008-02-05 Hewlett-Packard Development Company, L.P. Method and system of aligning execution point of duplicate copies of a user program by copying memory stores
JP3897046B2 (ja) * 2005-01-28 2007-03-22 横河電機株式会社 情報処理装置および情報処理方法
US7424641B2 (en) * 2005-04-06 2008-09-09 Delphi Technologies, Inc. Control system and method for validating operation of the control system
US7933966B2 (en) * 2005-04-26 2011-04-26 Hewlett-Packard Development Company, L.P. Method and system of copying a memory area between processor elements for lock-step execution
US7590885B2 (en) * 2005-04-26 2009-09-15 Hewlett-Packard Development Company, L.P. Method and system of copying memory from a source processor to a target processor by duplicating memory writes
US20070006166A1 (en) * 2005-06-20 2007-01-04 Seagate Technology Llc Code coverage for an embedded processor system
US20070038891A1 (en) * 2005-08-12 2007-02-15 Stratus Technologies Bermuda Ltd. Hardware checkpointing system
US7669073B2 (en) * 2005-08-19 2010-02-23 Stratus Technologies Bermuda Ltd. Systems and methods for split mode operation of fault-tolerant computer systems
JP4816911B2 (ja) * 2006-02-07 2011-11-16 日本電気株式会社 メモリの同期化方法及びリフレッシュ制御回路
US8032889B2 (en) * 2006-04-05 2011-10-04 Maxwell Technologies, Inc. Methods and apparatus for managing and controlling power consumption and heat generation in computer systems
US7549085B2 (en) * 2006-04-28 2009-06-16 Hewlett-Packard Development Company, L.P. Method and apparatus to insert special instruction
DE102006032726B4 (de) * 2006-07-14 2008-05-15 Lucas Automotive Gmbh Verfahren zum Synchronisieren von Komponenten eines Kraftfahrzeugbremssystems und elektronisches Bremssteuersystem
FR2912526B1 (fr) * 2007-02-13 2009-04-17 Thales Sa Procede de maintien du synchronisme d'execution entre plusieurs processeurs asynchrones fonctionnant en parallele de maniere redondante.
US20090076628A1 (en) * 2007-09-18 2009-03-19 David Mark Smith Methods and apparatus to upgrade and provide control redundancy in process plants
US8689224B2 (en) * 2007-09-26 2014-04-01 The Boeing Company Methods and systems for preserving certified software through virtualization
JP4468426B2 (ja) 2007-09-26 2010-05-26 株式会社東芝 高可用システム及び実行状態制御方法
GB2454865B (en) * 2007-11-05 2012-06-13 Picochip Designs Ltd Power control
US8255732B2 (en) * 2008-05-28 2012-08-28 The United States Of America, As Represented By The Administrator Of The National Aeronautics And Space Administration Self-stabilizing byzantine-fault-tolerant clock synchronization system and method
GB2466661B (en) * 2009-01-05 2014-11-26 Intel Corp Rake receiver
DE102009000045A1 (de) * 2009-01-07 2010-07-08 Robert Bosch Gmbh Verfahren und Vorrichtung zum Betreiben eines Steuergerätes
US20100229029A1 (en) * 2009-03-06 2010-09-09 Frazier Ii Robert Claude Independent and dynamic checkpointing system and method
WO2010103562A1 (ja) * 2009-03-09 2010-09-16 富士通株式会社 情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラム
GB2470037B (en) 2009-05-07 2013-07-10 Picochip Designs Ltd Methods and devices for reducing interference in an uplink
GB2470771B (en) 2009-06-05 2012-07-18 Picochip Designs Ltd A method and device in a communication network
GB2470891B (en) 2009-06-05 2013-11-27 Picochip Designs Ltd A method and device in a communication network
US20110078498A1 (en) * 2009-09-30 2011-03-31 United States Of America As Represented By The Administrator Of The National Aeronautics And Spac Radiation-hardened hybrid processor
US20110099421A1 (en) * 2009-09-30 2011-04-28 Alessandro Geist Radiation-hardened hybrid processor
GB2474071B (en) 2009-10-05 2013-08-07 Picochip Designs Ltd Femtocell base station
GB2482869B (en) 2010-08-16 2013-11-06 Picochip Designs Ltd Femtocell access control
ES2694803T3 (es) 2010-10-28 2018-12-27 Data Device Corporation Sistema, método y aparato para la corrección de errores en sistemas multiprocesador
US8443230B1 (en) * 2010-12-15 2013-05-14 Xilinx, Inc. Methods and systems with transaction-level lockstep
GB2489919B (en) 2011-04-05 2018-02-14 Intel Corp Filter
GB2489716B (en) 2011-04-05 2015-06-24 Intel Corp Multimode base system
GB2491098B (en) 2011-05-16 2015-05-20 Intel Corp Accessing a base station
US8966478B2 (en) 2011-06-28 2015-02-24 The Boeing Company Methods and systems for executing software applications using hardware abstraction
US8856590B2 (en) * 2012-01-07 2014-10-07 Compunetix, Inc. Reliable compute engine, method and apparatus
US9251002B2 (en) 2013-01-15 2016-02-02 Stratus Technologies Bermuda Ltd. System and method for writing checkpointing data
US9652338B2 (en) 2013-12-30 2017-05-16 Stratus Technologies Bermuda Ltd. Dynamic checkpointing systems and methods
WO2015102875A1 (en) 2013-12-30 2015-07-09 Stratus Technologies Bermuda Ltd. Checkpointing systems and methods of using data forwarding
ES2652262T3 (es) 2013-12-30 2018-02-01 Stratus Technologies Bermuda Ltd. Método de retardar puntos de comprobación inspeccionando paquetes de red
WO2016077570A1 (en) 2014-11-13 2016-05-19 Virtual Software Systems, Inc. System for cross-host, multi-thread session alignment
US20170322521A1 (en) * 2014-12-09 2017-11-09 General Electric Company Redundant ethernet-based control apparatus and method
US10025344B2 (en) 2015-04-21 2018-07-17 The United States Of America As Represented By The Administrator Of Nasa Self-stabilizing distributed symmetric-fault tolerant synchronization protocol
WO2019173075A1 (en) * 2018-03-06 2019-09-12 DinoplusAI Holdings Limited Mission-critical ai processor with multi-layer fault tolerance support
US10642826B1 (en) 2018-08-30 2020-05-05 Gravic, Inc. Mixed-mode method for combining active/active and validation architectures utilizing a check integrity module
US11899547B2 (en) 2021-11-30 2024-02-13 Mellanox Technologies, Ltd. Transaction based fault tolerant computing system

Family Cites Families (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3864670A (en) * 1970-09-30 1975-02-04 Yokogawa Electric Works Ltd Dual computer system with signal exchange system
US4228496A (en) * 1976-09-07 1980-10-14 Tandem Computers Incorporated Multiprocessor system
US4358823A (en) * 1977-03-25 1982-11-09 Trw, Inc. Double redundant processor
US4270168A (en) * 1978-08-31 1981-05-26 United Technologies Corporation Selective disablement in fail-operational, fail-safe multi-computer control system
DE2939935A1 (de) * 1979-09-28 1981-04-09 Licentia Patent-Verwaltungs-Gmbh, 6000 Frankfurt Sichere datenverarbeitungseinrichtung
US4342083A (en) * 1980-02-05 1982-07-27 The Bendix Corporation Communication system for a multiple-computer system
US4931922A (en) * 1981-10-01 1990-06-05 Stratus Computer, Inc. Method and apparatus for monitoring peripheral device communications
US4449182A (en) * 1981-10-05 1984-05-15 Digital Equipment Corporation Interface between a pair of processors, such as host and peripheral-controlling processors in data processing systems
US4634110A (en) * 1983-07-28 1987-01-06 Harris Corporation Fault detection and redundancy management system
US4531185A (en) * 1983-08-31 1985-07-23 International Business Machines Corporation Centralized synchronization of clocks
US4823256A (en) * 1984-06-22 1989-04-18 American Telephone And Telegraph Company, At&T Bell Laboratories Reconfigurable dual processor system
US4622667A (en) * 1984-11-27 1986-11-11 Sperry Corporation Digital fail operational automatic flight control system utilizing redundant dissimilar data processing
US4695945A (en) * 1985-02-28 1987-09-22 International Business Machines Corporation Processor I/O and interrupt filters allowing a co-processor to run software unknown to the main processor
AU606854B2 (en) * 1986-01-10 1991-02-21 Wyse Technology, Inc. Virtual peripheral controller
US4920481A (en) * 1986-04-28 1990-04-24 Xerox Corporation Emulation with display update trapping
US5062042A (en) * 1986-04-28 1991-10-29 Xerox Corporation System for managing data which is accessible by file address or disk address via a disk track map
US4812968A (en) * 1986-11-12 1989-03-14 International Business Machines Corp. Method for controlling processor access to input/output devices
US4807228A (en) * 1987-03-18 1989-02-21 American Telephone And Telegraph Company, At&T Bell Laboratories Method of spare capacity use for fault detection in a multiprocessor system
US4816989A (en) * 1987-04-15 1989-03-28 Allied-Signal Inc. Synchronizer for a fault tolerant multiple node processing system
US4910663A (en) * 1987-07-10 1990-03-20 Tandem Computers Incorporated System for measuring program execution by replacing an executable instruction with interrupt causing instruction
US4907228A (en) * 1987-09-04 1990-03-06 Digital Equipment Corporation Dual-rail processor with error checking at single rail interfaces
EP0306244B1 (de) * 1987-09-04 1995-06-21 Digital Equipment Corporation Fehlertolerantes Rechnersystem mit Fehler-Eingrenzung
EP0306211A3 (de) * 1987-09-04 1990-09-26 Digital Equipment Corporation Synchronisiertes Doppelrechnersystem
CA1320276C (en) * 1987-09-04 1993-07-13 William F. Bruckert Dual rail processors with error checking on i/o reads
US4916704A (en) * 1987-09-04 1990-04-10 Digital Equipment Corporation Interface of non-fault tolerant components to fault tolerant system
CA2003338A1 (en) * 1987-11-09 1990-06-09 Richard W. Cutts, Jr. Synchronization of fault-tolerant computer system having multiple processors
AU616213B2 (en) * 1987-11-09 1991-10-24 Tandem Computers Incorporated Method and apparatus for synchronizing a plurality of processors
DE3803525C2 (de) * 1988-02-05 1993-12-02 Licentia Gmbh Vorrichtung zum Betrieb von absoluten Echtzeituhren in einem eine Zentraluhr und Teilnehmer enthaltenden Prozeßsteuersystem
US4937741A (en) * 1988-04-28 1990-06-26 The Charles Stark Draper Laboratory, Inc. Synchronization of fault-tolerant parallel processing systems
US4965717A (en) * 1988-12-09 1990-10-23 Tandem Computers Incorporated Multiple processor system having shared memory with private-write capability
US5065310A (en) * 1989-05-10 1991-11-12 International Business Machines Corporation Reducing cache-reload transient at a context swap
US5048022A (en) * 1989-08-01 1991-09-10 Digital Equipment Corporation Memory device with transfer of ECC signals on time division multiplexed bidirectional lines
US5091847A (en) * 1989-10-03 1992-02-25 Grumman Aerospace Corporation Fault tolerant interface station
US5295258A (en) * 1989-12-22 1994-03-15 Tandem Computers Incorporated Fault-tolerant computer system with online recovery and reintegration of redundant components
US5327553A (en) * 1989-12-22 1994-07-05 Tandem Computers Incorporated Fault-tolerant computer system with /CONFIG filesystem
US5161156A (en) * 1990-02-02 1992-11-03 International Business Machines Corporation Multiprocessing packet switching connection system having provision for error correction and recovery
US5095423A (en) * 1990-03-27 1992-03-10 Sun Microsystems, Inc. Locking mechanism for the prevention of race conditions
US5155845A (en) * 1990-06-15 1992-10-13 Storage Technology Corporation Data storage system for providing redundant copies of data on different disk drives
US5261092A (en) * 1990-09-26 1993-11-09 Honeywell Inc. Synchronizing slave processors through eavesdrop by one on periodic sync-verify messages directed to another followed by comparison of individual status
US5226152A (en) * 1990-12-07 1993-07-06 Motorola, Inc. Functional lockstep arrangement for redundant processors
DE59108472D1 (de) * 1991-02-01 1997-02-20 Siemens Ag Verfahren für den fehlerbedingten Neustart eines Multiprozessorrechners eines Fernmeldevermittlungssystems
US5339404A (en) * 1991-05-28 1994-08-16 International Business Machines Corporation Asynchronous TMR processing system
US5222215A (en) * 1991-08-29 1993-06-22 International Business Machines Corporation Cpu expansive gradation of i/o interruption subclass recognition
US5251312A (en) * 1991-12-30 1993-10-05 Sun Microsystems, Inc. Method and apparatus for the prevention of race conditions during dynamic chaining operations
US5367639A (en) * 1991-12-30 1994-11-22 Sun Microsystems, Inc. Method and apparatus for dynamic chaining of DMA operations without incurring race conditions
US5448723A (en) * 1993-10-15 1995-09-05 Tandem Computers Incorporated Method and apparatus for fault tolerant connection of a computing system to local area networks
CA2177850A1 (en) * 1993-12-01 1995-06-08 Thomas Dale Bissett Fault resilient/fault tolerant computing

Also Published As

Publication number Publication date
EP0986007A3 (de) 2001-11-07
US5956474A (en) 1999-09-21
AU711435B2 (en) 1999-10-14
EP0974912A3 (de) 2000-07-19
DE69435090T2 (de) 2009-06-10
EP0986007A2 (de) 2000-03-15
WO1995015529A1 (en) 1995-06-08
CA2177850A1 (en) 1995-06-08
JP3679412B2 (ja) 2005-08-03
DE69435165D1 (de) 2008-12-18
AU4286597A (en) 1998-01-15
EP0986008B1 (de) 2008-04-16
AU4286497A (en) 1998-01-15
DE69435090D1 (de) 2008-05-29
AU711456B2 (en) 1999-10-14
EP0731945B1 (de) 2000-05-17
US6038685A (en) 2000-03-14
EP0986008A2 (de) 2000-03-15
JPH09509270A (ja) 1997-09-16
EP0974912A2 (de) 2000-01-26
DE69424565D1 (de) 2000-06-21
US5615403A (en) 1997-03-25
AU4286697A (en) 1998-01-15
AU680974B2 (en) 1997-08-14
AU711419B2 (en) 1999-10-14
EP0731945A1 (de) 1996-09-18
US5600784A (en) 1997-02-04
EP0974912B1 (de) 2008-11-05
EP0986008A3 (de) 2000-07-19
AU1182095A (en) 1995-06-19
EP0731945A4 (de) 1997-02-12

Similar Documents

Publication Publication Date Title
DE69424565T2 (de) Fehler-betriebssichere/fehler tolerante computerbetriebsmethode
DE69804489T2 (de) Verfahren zur erhaltung von synchronisierter ausführung bei fehler-betriebssicheren/ fehlertoleranten rechnersystemen
DE69027491T2 (de) Verfahren zur Softwarefehlerbehandlung
DE3853452T2 (de) Mehrfachverarbeitung mit hoher Verfügbarkeit.
DE3751600T2 (de) Dreifachredundantes fehlererkennungssystem und entsprechendes anwendungsverfahren.
DE60302184T2 (de) Fehlertolerantes Computersystem, Verfahren zur Resynchronisierung desselben und zugehöriges Resynchronisierungs-Programm
DE68928360T2 (de) Hochleistungsrechnersystem mit fehlertoleranter Fähigkeit; Verfahren zum Betrieb desselben
EP0306244B1 (de) Fehlertolerantes Rechnersystem mit Fehler-Eingrenzung
DE69316755T2 (de) Fehlertolerantes rechnersystem.
DE69032708T2 (de) Protokoll für Lese- und Schreibübertragungen
DE69907709T2 (de) Prozessüberwachung in einem rechnersystem
US20070043972A1 (en) Systems and methods for split mode operation of fault-tolerant computer systems
JPH01154240A (ja) 単一レールインターフェイスにエラーチェック機能を有する二重レールプロセッサ
JPH01154241A (ja) 同期二重コンピュータシステム
DE10231938A1 (de) Computersystem mit mehreren Sicherungs-Verwaltungsprozessoren zur Handhabung eines Ausfalls eines eingebetteten Prozessors
EP0286856B1 (de) Fehlertolerante Rechneranordnung
DE69032508T2 (de) Fehlertolerantes Rechnersystem mit Online-Wiedereinfügung und Abschaltung/Start
EP1537482B1 (de) Verfahren und schaltungsanordnung zur synchronisation synchron oder asynchron getakteter verarbeitungseinheiten
DE60303468T2 (de) Fehlertolerante Vorrichtung zur Informationsverarbeitung
DE68921334T2 (de) Gerät zur programmierten vorübergehenden Aufhebung des Prozessorbetriebs zum Wiederversuch, zur Rückgewinnung und zum Austesten.
DE69433947T2 (de) Festgekoppelte Dual-Steuermodule benutzendes fehlertolerantes Speichersteuergerät
DE10232919A1 (de) Computersystem mit Sicherungsverwaltung zur Handhabung eines eingebetteten Prozessorausfalls
DE69032865T2 (de) Gezielte Rücksetzungen in einem Datenprozessor
DE3789008T2 (de) Datenverarbeitungssystem mit einem durch ein Teilsystem zu Gunsten eines anderen Teilsystems erzeugten Bussteuerbefehl.
DE3751374T2 (de) Verfahren und Mechanismus zum unabhängigen Sicherstellungsmodustransfer für digitale Steuerprozessoren.

Legal Events

Date Code Title Description
8364 No opposition during term of opposition