DE102017106087A1

DE102017106087A1 - Fehlertoleranz-muster und schaltprotokoll für mehrere hot- und cold-standby-redundanzen

Info

Publication number: DE102017106087A1
Application number: DE102017106087.1A
Authority: DE
Inventors: Soheil Samii; Thomas E. Fuhrman; Massimo Osella
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2016-03-23
Filing date: 2017-03-21
Publication date: 2017-09-28
Also published as: US9952948B2; US20170277607A1; CN107229221A

Abstract

Ein Verfahren zur fehlertoleranten Controller-Bereitschaft. Ausführen von Funktionen durch einen ersten Controller, der in einem Primärstatusmodus arbeitet. Betreiben eines zweiten Controllers in einem Hot-Standby-Status-Modus und Spiegeln des ersten Controllers durch die Ausführung von Funktionen, für den Betrieb als redundante Controller. Betreiben in einem Cold-Standby-Status-Modus von mindestens einem Backup-Controller unter normalen Betriebsbedingungen. Der zweite Controller wird rekonfiguriert, während er unter normalen Betriebsbedingungen vom Hot-Standby-Status-Modus zum primären Standby-Status-Modus arbeitet, wenn im ersten Controller ein Fehler auftritt. Rekonfigurieren des mindestens einen Backup-Controllers, der unter normalen Betriebsbedingungen vom Cold-Standby-Statusmodus in den Hot-Standby-Statusmodus arbeitet, um als redundanter Controller als Reaktion auf die Rekonfiguration des zweiten Controllers vom Hot-Standby-Statusmodus zum Primärstatusmodus zu arbeiten.

Description

HINTERGRUND DER ERFINDUNG
Eine Ausführungsform betrifft fehlertolerante Steuerungssysteme. Systeme, die Sicherheitsfunktionen bereitstellen, verwenden in der Regel redundante Controller, um die Sicherheit zu gewährleisten, indem sie Funktionen beenden, die einen Fehler oder einen Fehler erfahren haben. Wenn ein Fehler erkannt wird, wird der Controller abgeschaltet oder der Controller fällt stillschweigend aus, wenn keine Signale vom Controller erzeugt werden und ein sekundärer Controller neu konfiguriert wird, um der primäre Controller zu werden.
Einige Systeme versuchen, Steuersysteme zu implementieren, die ein fehlersicheres System verwenden, bei dem zusätzliche Controller verwendet werden, um sicherzustellen, dass ein sicherer Betrieb für eine Zeitdauer fortgesetzt werden kann, wie beispielsweise Dual-Duplex-Controller oder ein dreifacher modularer Redundanzansatz. In einem Dual-Duplex-Ansatz, wenn ein erster Controller ausfällt und still ausfällt, wird ein zweiter Controller aktiviert und alle Stellglieder schalten um, um sich auf Anfragen vom zweiten Controller zu verlassen. Im Gegensatz zu Softwarefehlern, bei denen ein Fehler in einem Controller im Duplikat-Controller vorhanden wäre, sind Hardwarefehler (z. B. Stromversorgungsfehler, Kurzschluss nach Massefehlern usw.) sind typischerweise unabhängig und es besteht die Wahrscheinlichkeit, dass der sekundäre Controller nicht denselben Hardwarefehler aufweist, der mit dem primären Controller aufgetreten ist und danach ordnungsgemäß arbeiten kann. In bestimmten Operationen ist die Aufrechterhaltung der Funktionalität eines Controllers entscheidend, wobei das System entweder eine sofortige Übernahme der primären Controller-Zuständigkeiten erfordert, oder wobei ein Controller für eine Zeitspanne funktionieren muss, bis ein anderer Controller zur Übernahme rekonfiguriert werden kann. Als Ergebnis nutzen Systeme mehrere Controller als Backup-Controller. Bestimmte kritische Funktionen müssen möglicherweise auf drei oder mehr Controller repliziert werden, damit das System mehr als einen Ausfall im gleichen Antriebs-/Betriebs-/Zündzyklus toleriert. Das Skalieren eines Dual-Duplex-Musters zur Handhabung von mehr als einem Ausfall ist möglicherweise nicht kostengünstig, da mehr als ein Controller-Fehler möglicherweise in einem gleichen Fahrzyklus toleriert werden muss. Wenn also zwei Controllerausfälle toleriert werden müssen, dann wären vier Controller erforderlich, wenn ein herkömmliches Dual-Duplex-Design verwendet wird. Erinnern Sie sich, dass ein Controller entweder zwei Prozessoren oder zwei Kerne beinhaltet, in denen Funktionen unabhängig und gleichzeitig auf einem entsprechenden Controller ausgeführt werden. Alternativ kann das Steuersystem einen Prozessor und ein unabhängiges Überwachungsmodul beinhalten als. Als Ergebnis würde jeder Controller dieselbe Funktion aufweisen, die von jedem Prozessor oder Kern innerhalb jedes Controllers ausgeführt wird. Infolgedessen, wenn ein Dual-Duplex-Design verwendet wird und zwei Controller-Ausfälle toleriert werden müssen, müssen drei Controller verwendet werden und eine gleiche Funktion wird gleichzeitig und unabhängig sechsmal ausgeführt, was zu einem kostspieligen und ineffizienten Verbrauch von Systemressourcen führt.
Für einen dreifachen modularen Redundanzansatz führen alle Controller die gleiche Funktion aus, aber dieses Muster skaliert nicht gut. Eine Formel zum Bestimmen der Anzahl an Einheiten, um die Anzahl der Fehler zu behandeln, ist 2N + 1, wobei N die Anzahl der Ausfälle ist. Um zwei Fehler zu behandeln, sind fünf Einheiten erforderlich.
ZUSAMMENFASSUNG DER ERFINDUNG
Ein Vorteil einer Ausführungsform ist eine Verringerung der Verarbeitungslast auf Controller, sodass Verarbeitungsressourcen für andere Operationen freigegeben werden können und eine Gesamtverarbeitungslast eines weiteren Controllers verringert werden kann. Durch die Festlegung eines Controllers als primären Controller, eines Controllers im Hot-Standby-Zustand und einen anderen Controller im Cold-Standby-Zustand sind nur zwei Controller erforderlich, um gleichzeitig eine Funktion auszuführen. Das hierin beschriebene Steuersystem und die hierin beschriebene Technik behalten einen Controller im Primärstatusmodus sowie einen Controller im Hot-Standby-Zustand dergestalt, dass, wenn ein primärer Controller ausfällt, stets ein Controller in demselben oder in einem ähnlichen Zustand wie der primäre Controller vorhanden ist und die Operationen des ausgefallenen primären Controllers sofort wieder aufnehmen kann. Als Ergebnis wird ein Backup-Controller im Cold-Standby-Status-Modus niemals direkt vom Cold-Standby-Status zum Primärstatus wechseln.
Eine Ausführungsform sieht ein Verfahren zur fehlertoleranten Controller-Bereitschaft vor. Die Funktionen werden von einem ersten Prozessor ausgeführt, während sie unter Nicht-Fehler-Betriebsbedingungen arbeiten. Der erste Controller arbeitet in einem Primärstatusmodus. Der primäre Controller gibt Steuersignale über ein Kommunikationsnetzwerk aus, um Steuerungsaktionen auszuführen. Der sekundäre Controller arbeitet unter normalen Betriebsbedingungen in einem Hot-Standby-Status. Der zweite Controller spiegelt den ersten Controller durch Ausführen von Funktionen, um als redundanter Controller zu arbeiten. Mindestens ein Backup-Controller, der in einem Cold-Standby-Status-Modus unter normalen Betriebsbedingungen arbeitet. Der zweite Controller wird rekonfiguriert, während er unter normalen Betriebsbedingungen vom Hot-Standby-Status-Modus zum primären Standby-Status-Modus arbeitet, wenn im ersten Controller ein Fehler auftritt. Der mindestens eine Backup-Controller, der unter normalen Betriebsbedingungen arbeitet, wird vom Cold-Standby-Status-Modus in den Hot-Standby-Status-Modus rekonfiguriert, um als redundanter Controller als Reaktion auf die Rekonfiguration des zweiten Controllers vom Hot-Standby-Statusmodus zum Primärstatusmodus zu arbeiten.
Ein fehlertolerantes Steuersystem beinhaltet einen ersten Controller, der in einem Primärstatusmodus arbeitet. Der erste Controller führt die Funktion aus und steuert die Funktionen von Geräten, während er unter Nicht-Fehler-Betriebsbedingungen arbeitet. Ein zweiter Controller arbeitet in einem Hot-Standby-Modus. Der zweite Controller spiegelt den ersten Controller wider, indem er als Backup-Controller arbeitet, der redundante Funktionen ausführt. Ein dritter Controller arbeitet in einem Cold-Standby-Statusmodus. Der dritte Controller arbeitet in einem Standby-Modus, der die Funktionen nicht ausführt. Der zweite Controller während des Betriebs unter normalen Betriebsbedingungen wird von einem Hot-Standby-Status-Modus zu einem primären Standby-Status-Modus rekonfiguriert, wenn ein Fehler im ersten Controller auftritt. Der dritte Controller wird, während er unter normalen Betriebsbedingungen betrieben wird, von einem Cold-Standby-Statusmodus zu einem Hot-Standby-Status-Modus rekonfiguriert, wenn der zweite Controller vom Hot-Standby-Status-Modus in den primären Standby-Status-Modus rekonfiguriert wird oder wenn ein Fehler im zweiten Controller auftritt, während der Betrieb im Hot-Standby-Modus erfolgt.
Ein fehlertolerantes Steuersystem beinhaltet einen ersten Controller, der in einem Primärstatusmodus arbeitet. Der erste Controller steuert die Funktionen von Geräten, während er unter Nicht-Fehler-Betriebsbedingungen arbeitet. Ein zweiter Controller arbeitet in einem Hot-Standby-Modus. Der zweite Controller spiegelt den ersten Controller wider, indem er als Backup-Controller arbeitet, der redundante Funktionen ausführt. Eine Vielzahl von Backup-Controllern arbeitet in einem Cold-Standby-Statusmodus. Jeder der Vielzahl von Backup-Controllern hat eine priorisierte Reihenfolge. Die Vielzahl von Backup-Controllern während des Betriebs in einem Cold-Standby-Modus führt die Funktionen nicht aus. Der zweite Controller während des Betriebs unter normalen Betriebsbedingungen wird von einem Hot-Standby-Status-Modus zu einem primären Standby-Status-Modus rekonfiguriert, wenn ein Fehler im ersten Controller auftritt. Der Operations-Backup-Controller mit der höchsten Priorität zwischen den mehreren Backup-Controllern wird von einem Cold-Standby-Status-Modus zu einem Hot-Standby-Status-Modus rekonfiguriert, wenn der zweite Controller vom Hot-Standby-Status-Modus zum primären Standby-Status-Modus rekonfiguriert wird oder wenn ein Fehler im zweiten Controller auftritt, während er im Hot-Standby-Statusmodus arbeitet.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist ein architektonisches Blockdiagramm eines exemplarischen integrierten Steuerungssystems.
2 ist eine anfängliche Konfiguration von Controllern, die in einem nicht fehlerhaften Zustand arbeiten.
3 veranschaulicht ein Beispiel eines fehlgeschlagenen primären Controllers und einer Rekonfiguration eines Backup-Controllers.
4 veranschaulicht ein Beispiel eines fehlgeschlagenen Backup-Controllers und eine Rekonfiguration eines nächsten Backup-Controllers.
5 veranschaulicht ein Beispiel für einen Ausfall eines anderen Backup-Controllers und eine Rekonfiguration eines Backup-Controllers.
6 stellt umfassendes Schaltflussdiagramm für ein exemplarisches Steuergerät mit drei Controllern.
7 zeigt exemplarische Rekonfigurationen des Master-Controllers und des Backup-Master-Controllers für den zentralen Ansatz.
8 zeigt exemplarische Rekonfigurationen des Master-Controllers und des Backup-Master-Controllers für den zentralen Ansatz.
AUSFÜHRLICHE BESCHREIBUNG
Die nachfolgende ausführliche Beschreibung dient lediglich zum besseren Verständnis der Ausführungsformen und ist nicht dazu bestimmt, die Ausführungsformen des hierin beschriebenen Gegenstands oder die Anwendung und Verwendungen dieser erwähnten Ausführungsformen zu beschränken. Jeder Gebrauch des Wortes „exemplarisch“ ist auszulegen als „dient als Beispiel, Sachverhalt oder zur Veranschaulichung“. Hierin beschriebene Anwendungen sind exemplarisch und nicht als bevorzugt oder vorteilhaft gegenüber anderen Anwendungen zu verstehen. Die Beschreibungen in diesem Dokument sind nicht als gebunden durch eine ausdrückliche oder implizierte Theorie zu verstehen, die vor dem vorstehenden Hintergrund, der ausführlichen Beschreibung oder den ausführlichen Beschreibungen, der Zusammenfassung oder der folgenden ausführlichen Beschreibung vorgestellt wird.
Die Techniken und Technologien können hierin in Bezug auf die funktionellen und/oder logischen Blockkomponenten beschrieben werden und unter Bezugnahme auf symbolische Darstellungen von Vorgängen, Programmverarbeitungen und Funktionen, die von verschiedenen Computerkomponenten oder Vorrichtungen durchgeführt werden können. Solche Vorgänge, Programme und Funktionen werden manchmal als Computer-ausgeführt, computerisiert, Software-implementiert oder Computer-implementiert bezeichnet. Es sollte beachtet werden, dass derartige Blockkomponenten aus einer beliebigen Anzahl an Hardware, Software und/oder Firmware-Komponenten aufgebaut sein können, die konfiguriert sind, um die spezifischen Funktionen auszuführen. So kann zum Beispiel eine Ausführungsform eines Systems oder einer Komponente verschiedene integrierte Schaltungskomponenten, beispielsweise Speicherelemente, digitale Signalverarbeitungselemente, Logikelemente, Nachschlagetabellen oder dergleichen einsetzen, die eine Vielzahl von Funktionen unter der Steuerung eines oder mehrerer Mikroprozessoren oder anderer Steuervorrichtungen durchführen können.
Wenn in Software oder Firmware implementiert, sind verschiedene Elemente der hierin beschriebenen Systeme im Wesentlichen die Codesegmente oder Anweisungen, die die verschiedenen Aufgaben ausführen. In bestimmten Ausführungsformen sind die Programm- oder Codesegmente auf einem materiellen, prozessorlesbaren Medium gespeichert, das jedes Medium sein kann, das Informationen speichern oder übertragen kann. Beispiele für nichtflüchtige, Prozessor-lesbare Medien beinhalten einen elektronischen Schaltkreis, einen Mikrocontroller, einen anwendungsspezifischen integrierten Schaltkreis (ASIC), ein Halbleiter-Speicherelement, einen ROM-Speicher, einen Flash-Speicher, einen löschbaren ROM-Speicher (EROM), eine Floppy-Disk, eine CD-ROM, eine optische Speicherplatte, eine Festplatte oder dergleichen.
Das hierin beschriebene System und die Methodik können verwendet werden, um Fehler in Controllern zu identifizieren, die Softwarefunktionen in Steuersystemen ausführen. Während der Ansatz und die Methodik im Folgenden in Bezug auf die in Fahrzeuganwendungen verwendeten Controller beschrieben werden, erkennt der Fachmann, dass eine Automobilanwendung lediglich exemplarisch ist und dass die hierin offenbarten Konzepte auch auf jedes andere geeignete Kommunikationssystem angewendet werden können, wie beispielsweise allgemeine industrielle Automatisierungsanwendungen, Fertigungs- und Montageanwendungen und Spiele.
Der Begriff „Fahrzeug“, wie hierin beschrieben, kann im weitesten Sinne so ausgelegt werden, dass er nicht nur einen PKW betrifft, sondern alle anderen Fahrzeuge, beinhaltet, ohne jedoch darauf beschränkt zu sein, Schienenverkehrssysteme, Flugzeuge, Geländesportfahrzeuge, Roboterfahrzeuge, Motorräder, LKW, Sportnutzfahrzeuge (SUV), Wohnmobile (RV), Wasserfahrzeuge, Luftfahrzeuge, landwirtschaftliche Fahrzeuge, selbstfahrende Fahrzeuge, gemeinsam genutzte Fahrzeuge und Baufahrzeuge.
In 1 ist ein architektonisches Blockdiagramm eines exemplarischen integrierten Steuersystems dargestellt. Derartige Steuersysteme werden oft zwei oder mehr Controller verwenden, sodass, wenn ein Hardwarefehler bei einem primären Controller auftritt, dann mindestens ein Backup-Controller leicht in die Lage versetzt werden kann, ein Merkmal des Steuersystems zu steuern oder eine Steuerung für eine begrenzte Funktionalität des Merkmals bereitzustellen Fehler.
In 1 beinhaltet das Steuersystem einen ersten Controller 12, einen zweiten Controller 14 und einen dritten Controller 15. Das hierin beschriebene exemplarische System ist fahrzeugbasiert, aber wie zuvor beschrieben, kann die Architektur auf Nicht-Fahrzeugsysteme anwendbar sein. Der erste Controller 12 ist als primärer Controller bezeichnet und beinhaltet einen Dual-Core-Prozessor, der einen ersten Kern 16 und einen zweiten Kern 18 zum Ausführen von primären Steuerungen verwendet. Der zweite Controller 14 ist ein Backup-Controller mit einem Dual-Core-Prozessor, der einen ersten Kern 19 und einen zweiten Kern 20 verwendet, der redundante Funktionen als den ersten Controller 12 ausführt. Der dritte Controller 15 ist auch ein Backup-Controller, der einen Dual-Core-Prozessor umfasst, der einen ersten Kern 21 und einen zweiten Kern 22 verwendet, der redundante Funktionen als den ersten Controller 12 ausführt. Alternativ kann jeder jeweilige Controller zwei Prozessoren verwenden, im Gegensatz zu Dual-Core-Prozessoren oder einem einzigen Prozessor mit einem unabhängigen Sicherheitsmonitor/-prüfer. Es versteht sich, dass die beispielhafte Architektur beispielhaft ist und die Verwendung der hierin beschriebenen Technik nicht auf Systeme beschränkt ist, bei denen der Controller Dual-Verarbeitungsansätze verwendet, um Fail-Silence zu implementieren. Zur Veranschaulichung hierin sind der erste Controller 12, der zweite Controller 14 und der dritte Controller 15 identisch mit derselben Hardware und derselben Software. Jedoch können bestimmte Vorrichtungen in der Architektur verschiedene Vorrichtungen, wie beispielsweise unterschiedliche Stromversorgungen, verwenden, so dass, wenn ein Fehler bei einem Steuergerät als Ergebnis einer Stromversorgung auftritt, der andere Controller nicht beeinflusst wird. Der erste Controller 12 wird als Master-aktiver Controller bezeichnet und empfängt Eingangssignale und führt auf der Grundlage der Eingangssignale Funktionen aus und gibt Steuersignale an die anderen Geräte über ein Kommunikationsnetzwerk 24 aus, wenn es sich in einem Betriebs- und Nicht-fehlgeschlagenen Zustand befindet. Der primäre Controller 12 arbeitet unter Nicht-Ausfall-Betriebsbedingungen (hierin als normale Betriebsbedingungen bezeichnet) und erzeugt und überträgt Steuersignale zum Steuern von Merkmalen einer Fahrzeugvorrichtung.
Der zweite Controller 14 und der dritte Controller 15, die als Backup-Controller arbeiten, empfangen Daten und führen Funktionen aus, aber die Ausgabesteuersignale werden von Geräten auf dem Steuersystem nicht genutzt, wenn der erste Controller 12 unter normalen Betriebsbedingungen arbeitet.
Der erste Controller 12, der zweite Controller 14 und der dritte Controller 15 kommunizieren über ein Kommunikationsnetzwerk 24. Es versteht sich, dass das Kommunikationsnetzwerk Kommunikationsbereichsnetz (CAN), CAN-FD, FlexRay, Switched Networking mit Ethernet, drahtlose Kommunikation oder mehrere Netzwerke mit Gates beinhalten kann, ist aber nicht darauf beschränkt. Die Forderung ist, dass jedes der Steuermodule und Sensoren/ Aktuatoren können miteinander verbunden. Der erste Controller 12, der zweite Controller 14 und der dritte Controller 16 nutzen das Kommunikationsnetzwerk 24 zum Empfangen und Versenden von Daten zwischen den Sensoren 26 und den Aktuatoren 28.
Die Sensoren 26 zum Senden von Statuszustand und Eingabesignale an die Controller. Wenn der erste Controller 12 die Eingabesignale von den Sensoren 26 empfängt, führt jeder Kern 16 und 18 des primären Controllers 12 gleichzeitig eine Softwarefunktion aus, die Eingabedaten verwendet. Der erste Controller 12 gibt ein Steuersignal auf der Grundlage der ausgeführten Funktion an die Aktuatoren 28 aus. Die Aktuatoren 28 weisen Vorrichtungen zur Betätigung eines Merkmals des Fahrzeugsystems auf. Typischerweise sind Merkmale, die entweder kritisch sind oder vom Fahrzeug benötigt werden, um wenigstens einen sicheren Betrieb des Fahrzeugs aufrechtzuerhalten. Derartige Steuervorrichtungen können, sind aber nicht beschränkt darauf, Bremssteuerungen und Lenksteuerungen beinhalten. Unter einer Fail-Operation-Bedingung ist die Funktionalität für kritische Vorrichtungen, obwohl begrenzt, aktiviert, um dem Fahrer zu ermöglichen, das Fahrzeug sicher zu betreiben, bis das Fahrzeug an einen Ort zur Inspektion gefahren werden kann oder das Fahrzeug in die Lage versetzen kann, eine sichere oder minimale Gefahr zu erreichen.
Der erste Controller 12 beinhaltet ein Vergleichsmodul 30, der zweite Controller 14 enthält ein Vergleichsmodul 32 und der dritte Controller 15 beinhaltet ein Vergleichsmodul 34. Jedes der jeweiligen Vergleichsmodule führt eine Vergleichsoperation zwischen den Ausgängen der jeweiligen Kerne innerhalb eines jeweiligen Controllers durch. Die Vergleichsoperation bestimmt, ob die Ergebnisse jeder ausgeführten Funktion von jedem Kern innerhalb des jeweiligen Controllers gleich oder ähnlich sind, da jeder Kern eine gleiche Funktion ausführt, die dieselben Eingabedaten verwendet. Es versteht sich, dass, obwohl eine gleiche/genaue Ausführung durch die Controller optimal wäre, die Ausführung der Controller nicht genau oder gleichzeitig sein muss. Ob die Zustände exakt übereinstimmen und gleich sind, hängt von der Synchronisation im System ab (z. B. ein globaler Begriff der synchronisierten Zeit und alle Controller haben die gleiche Kenntnis der „aktuellen“ Zeit und der Primär- und Hot-Standby-Funktion zur gleichen Zeit und mit den gleichen Eingaben). Es versteht sich jedoch, dass das System nicht vollständig mit dem exakt gleichen Zustand jederzeit zwischen dem primären und dem warmen Standby-Zustand synchronisiert werden kann und dass diese Technik für Systeme gilt, die eine unvollkommene Synchronisation beinhalten, die ähnliche, aber nicht identische/genaue Zustände aufweist. Wenn die Kerne ohne Fehler arbeiten, dann sollten die Ergebnisse gleich sein. Wenn sich die Ergebnisse unterscheiden, kann in diesem jeweiligen Controller ein Fehler vorliegen. Als Ergebnis benötigt jedes Vergleichsmodul zwei Eingaben, die die ausgeführten funktionalen Ergebnisse durch jeden Kern innerhalb des jeweiligen Controllers vergleichen, um zu ermitteln, ob ein Fehler in ihrem jeweiligen Controller aufgetreten ist. Die Ergebnisse werden über das Kommunikationsnetzwerk 24 an andere Geräte, wie beispielsweise andere Controller und Aktoren im Kommunikationsnetz 24, übertragen. Beide Controller können ein Fail-Silence-Decoder/Decider-Modul zur Überwachung von Fehlerzuständen in den anderen Controllern zur Rekonfiguration der Controller beinhalten, falls ein Fehler vorliegt.
Während der Zeit, in der der erste Controller 12 auf der Grundlage der Eingangsdaten Funktionen ausführt, spiegeln der zweite Controller 14 und der dritte Controller 15 den ersten Controller 12 und führen gleichzeitig die gleichen Funktionen auf der Grundlage der gleichen Daten aus. Dies wird als Redundanz bezeichnet. Der zweite Controller 14 und der dritte Controller 15 spiegeln den ersten Controller 12, indem er Funktionen in demselben Zustand wie der erste Controller 12 ausführt. Dies wird in dem Fall durchgeführt, dass, wenn ein Fehler im ersten Controller 12 auftritt, der zweite Controller 14 und der dritte Controller 15 bereit sein müssen, um die Operationen des ersten Controllers 12 sofort zu übernehmen. Um den Betrieb des ersten Controllers 12 sofort zu übernehmen, muss entweder der zweite Controller 14 oder der dritte Controller 15 in demselben Zustand sein wie der primäre Controller 12. Das heißt, einer der beiden Backup-Controller implementiert sein und gleichzeitig eine identische Funktionalität ausführen wie der erste Controller 12, um einen Controller-Ausfall im ersten Controller 12 zu tolerieren. Daher ist es von Bedeutung, dass einer der Controller kritische Software redundant ausführt, um zu identifizieren, wann ein Fehler in dem ersten Controller 12 auftritt, und um sofort die Controller-Operationen zu übernehmen, falls der primäre Controller ausfällt (d. h. fehlschlägt). Dies erfordert, dass der Backup-Controller in einem gleichen Zustand arbeitet, sodass keine Latenzzeit bei der Rekonfiguration des Backup-Controllers als primärer Controller vorhanden ist. Latenzen würden auftreten, wenn ein jeweiliger Backup-Controller nicht in demselben Zustand wie der primäre Controller arbeitet, wenn ein Fehler auftritt. Derartige Vorkommen würde erfordern, dass der Backup-Controller bestimmt, in welchem Zustand der primäre Controller in Betrieb ist, und dann beginnen, Funktionen auszuführen, um aufzuholen, wo der primäre Controller war, wenn der Fehler erkannt wurde. Eine derartige Verzögerung bei einer kritischen Operation (z. B. autonomer Fahrbetrieb) ist unerwünscht und kann zu einem unsicheren Betrieb führen, wenn der primäre Controller die Funktionalität nicht beibehalten kann, bis der Backup-Controller auf die Geschwindigkeit kommen kann und die Operationen übernehmen kann.
Die folgenden 2–5 werden ähnliche Elementnummern verwenden, wie in 1 für Konsistenzzwecke. Wie in 2 gezeigt, während das Steuersystem unter normalen Betriebsbedingungen arbeitet, arbeitet der erste Controller 12 im Primärstatusmodus (P), der zweite Controller 14 arbeitet unter dem Hot-Standby-Statusmodus (HS) und der dritte Controller 15 arbeitet unter Cold-Standby-Status-Modus (CS). Der dritte Controller 15, während er im Cold-Standby-Statusmodus (CS) arbeitet, ist nicht redundant im Sinne der nicht aktiven Spiegelung des ersten Controllers 12. Vielmehr kann der dritte Controller 15 bis zum Stillstand ruhen oder für eine andere Verwendung durch ein anderes System zugeteilt werden, wenn dies gewünscht wird, während die anderen Controllern unter normalen Betriebsbedingungen arbeiten. Als Ergebnis werden die Systemressourcen für eine effizientere Nutzung des dritten Controllers 15 gespeichert oder neu zugeordnet. Daher empfängt der erste Controller 12 Eingangssignale von den Sensoren 26 und führt aktiv Funktionen aus und liefert Steuersignale an die Aktuatoren 28 und andere Vorrichtungen in dem Steuersystem über das Kommunikationsnetzwerk 24, während der zweite Controller 14 in einem redundanten Modus arbeitet, der den ersten Controller 12 spiegelt. Wenn der erste Controller 12 oder der zweite Controller 14 einen Fehler aufweist, wird der dritte Controller 15 in einen anderen Statusmodus rekonfiguriert, wie nachfolgend erläutert wird.
3 veranschaulicht einen exemplarischen Zustand eines Fehlers, der in dem ersten Controller 12 auftritt, der ursprünglich als der primäre Controller vorgesehen ist. Wenn die Fehlerbedingung als kritisch bestimmt wird, wechselt der erste Controller 12 vorzugsweise in einen fehlersicheren Zustand, in dem keine Kommunikation vom ersten Controller 12 übertragen wird. Wenn der zweite Controller 14 feststellt, dass der erste Controller 12 fehlerhaft ist und sich im Fail-Silent-Modus befindet, wird der zweite Controller 14 als primärer Controller rekonfiguriert. Da sich der zweite Controller 14 im Hot-Standby-Status-Modus (HS) befindet, arbeitet der zweite Controller 14 im selben/ähnlichen Zustand, in dem der erste Controller 12 bei einem Fehler aufgetreten ist. Als Ergebnis kann der zweite Controller 14 rekonfiguriert werden, um sofort die Ausführung der Funktionen des primären Controllers zu übernehmen. Die Stellglieder 28 und andere Vorrichtungen auf dem Kommunikationsnetzwerk 24 identifizieren den zweiten Controller 14 als den primären Controller zum Empfangen von Steuersignalen daraus. Der erste Controller 12 tritt in einen fehlersicheren Modus ein und kommuniziert nicht mehr mit den Aktuatoren 28 und anderen Vorrichtungen.
Unter erneuter Bezugnahme auf 3, wird darauf, dass der erste Controller 12 fehlerhaft ist und in einen Fail-Silent-Modus eintritt und der zweite Controller 14 als primärer Controller rekonfiguriert wird, der dritte Controller 15 vom Cold-Standby-Statusmodus (CS) in den Hot-Standby-Statusmodus (HS) rekonfiguriert. Der dritte Controller 15 bestimmt dann den Zustand, in dem der zweite Controller 14, der nun als primärer Controller fungiert, in Betrieb ist und beginnt, den zweiten Controller 14 zum Ausführen von Funktionen zu spiegeln. Der dritte Controller 15 wird zu einem dedizierten Controller, indem er Funktionen redundant und gleichzeitig mit dem zweiten Controller 14 ausführt. Als Ergebnis wird der dritte Controller 15 zu einem aktiven Backup-Controller 15 des zweiten Controllers 14. Danach, sollte der zweite Controller 14, wie in 4 gezeigt, ausfallen, fällt der zweite Controller 14 stillschweigend aus, und der dritte Controller wird, wenn er den Fehler im zweiten Controller 14 erkennt, als primärer Controller (P) rekonfiguriert. Als Ergebnis werden der erste Controller 12 und der zweite Controller 14 im Wesentlichen aus dem Steuersystem genommen und der dritte Controller 15 übernimmt sofort Operationen und die Steuerung, die zuvor vom zweiten Controller 14 ausgeübt wurden.
5 ist ein Beispiel eines Fehlers, der in dem zweiten Controller 14 auftritt, der gegenwärtig in einem Hot-Standby-Statusmodus (HS) arbeitet. In 5 arbeiten der erste Controller 12 und der dritte Controller 15 unter normalen Betriebsbedingungen, und ein Fehler wird im zweiten Controller 14 erkannt. Der zweite Controller 14 wechselt in einen Fail-Silent-Modus. Wenn der erste Controller 12 ausfällt, während der dritte Controller 15 momentan im Cold-Standby-Statusmodus (CS) ist, würde es zu einer Verzögerung bei der Rekonfiguration des dritten Controllers 15 aus dem Cold-Standby-Statusmodus (CS) zu einem Primärstatusmodus (P) kommen. Da der dritte Controller 15 nicht den ersten Controller 12 spiegelt, muss der dritte Controller 15 den Zustand bestimmen, in dem der erste Controller 12 arbeitet, wenn der Fehler aufgetreten ist. Daher wäre eine Zeitspanne erforderlich, um den dritten Controller 15 neu zu konfigurieren, um Parameter einzustellen und denselben Zustand wie der erste Controller 12 einzugeben, wenn ein Fehler in dem ersten Controller 12 auftritt. Um sicherzustellen, dass es keine Latenz bei der Rekonfiguration des dritten Controllers 15 gibt, sollte diese Bedingung auftreten, sobald der Fehler in dem zweiten Controller 14 erkannt wird, wird der dritte Controller 15 zu einem Hot-Standby-Statusmodus (HS) rekonfiguriert. Es kann eine gewisse Zeit erforderlich sein, den dritten Controller 15 in diesen jeweiligen Statusmodus zu rekonfigurieren, diese Rekonfiguration wird jedoch durchgeführt, während der erste Controller 12 als primärer Controller unter normalen Betriebsbedingungen arbeitet. Nachdem der dritte Controller 15 erfolgreich in den Hot-Standby-Statusmodus (HS) rekonfiguriert worden ist, spiegelt der dritte Controller 15 den ersten Controller 12 redundant und gleichzeitig die gleichen Funktionen wie der erste Controller 12 aus.
6 veranschaulicht ein umfassendes Schaltungsdiagramm, das eine Kombination und Sequenzen zur Rekonfiguration jedes Status des Steuergeräts bereitstellt, wenn drei Controller verwendet werden.
In Block 40 arbeiten alle entsprechenden Controller unter normalen Betriebsbedingungen, in denen sich der erste Controller 12 im Primärstatusmodus (P) befindet, der zweite Controller 14 befindet sich im Hot-Standby-Statusmodus (HS) und der dritte Controller 15 ist im Cold-Standby Statusmodus (CS).
In Block 41 schlägt der erste Controller 12 fehl und der erste Controller 12 wechselt in einen Fail-Silent-Modus. Der zweite Controller 14 erkennt den Ausfall des ersten Controllers 12 und wird in Reaktion auf die Erkennung des Fehlers in den Primärstatusmodus (P) rekonfiguriert. Die Rekonfiguration ist sofort oder hat eine minimale Latenzzeit, da der zweite Controller 14 den ersten Controller 12 spiegelt. Zusätzlich wird der dritte Controller 15 vom Cold-Standby-Statusmodus (CS) in den Hot-Standby-Statusmodus (HS) rekonfiguriert, wobei der dritte Controller 15 den zweiten Controller 14 spiegelt.
In Block 42 wird nach der in Block 41 gezeigten Rekonfiguration ein Fehler in dem zweiten Controller 14 detektiert, und der zweite Controller 14 tritt in einen Fail-Silent-Modus ein. Der dritte Controller 15 erkennt den Ausfall des zweiten Controllers 14 und wird von dem Hot-Standby-Statusmodus (HS) zum Primärstatusmodus (P) als Reaktion auf die Erkennung des Fehlers rekonfiguriert. Die Rekonfiguration ist sofort oder hat eine minimale Latenz, da der dritte Controller 15 den zweiten Controller 14 spiegelt. Es sind keine Backup-Controller verfügbar, nachdem zwei der drei Controller ausfallen.
In Block 43 wird nach der in Block 41 gezeigten Rekonfiguration ein Fehler in dem dritten Controller 15 erkannt, und der dritte Controller 15 tritt in einen Fail-Silent-Modus ein. Sowohl der erste Controller 15 als auch der dritte Controller 15 gelangen in einen Fail-Silent-Modus. Der bereits im Primärstatusmodus (P) betriebene zweite Controller 14 fungiert weiterhin als primärer Controller. Es sind keine Backup-Controller verfügbar, nachdem zwei der drei Controller ausfallen.
Unter erneuter Bezugnahme auf Block 40 wird ein Fehler in dem zweiten Controller 14 erkannt, und das Flussdiagramm fährt mit Block 44 fort. Block 44 stellt die Rekonfiguration als Reaktion auf die zweite Steuerung 15 dar, die fehlerhaft ist, nachdem jeder der Controller unter normalen Betriebsbedingungen betrieben wurde. Der zweite Controller 14 fällt aus und tritt in einen Fail-Silent-Modus ein. Der erste Controller 12 arbeitet weiterhin als primärer Controller, da normale Betriebsbedingungen darin vorhanden sind. Der dritte Controller 15 erkennt den Ausfall des zweiten Controllers 14 und wird vom Cold-Standby-Statusmodus (CS) in den Hot-Standby-Statusmodus (HS) rekonfiguriert. Nach der Rekonfiguration spiegelt der dritte Controller 15 den ersten Controller 12.
In Block 45 wird nach der in Block 44 gezeigten Rekonfiguration ein Fehler im ersten Controller 12 erkannt, und der erste Controller 12 wechselt in einen Fail-Silent-Modus. Der dritte Controller 15 erkennt den Ausfall des ersten Controllers 12 und wird von dem Hot-Standby-Statusmodus (HS) zum Primärstatusmodus (P) als Antwort auf die Erkennung des Fehlers rekonfiguriert. Die Rekonfiguration erfolgt sofort, da der dritte Controller 15 den ersten Controller 14 spiegelt. Es sind keine Backup-Controller verfügbar, nachdem zwei der drei Controller ausfallen.
In Block 46 wird nach der in Block 44 gezeigten Rekonfiguration ein Fehler in dem dritten Controller 15 detektiert, und der dritte Controller 15 tritt in einen Fail-Silent-Modus ein. Sowohl der zweite Controller 14 als auch der dritte Controller 15 befinden sich nun im Fail-Silent-Modus. Der erste Controller 12, der bereits im Primärstatusmodus (P) arbeitet, fungiert weiterhin als primärer Controller. Es sind keine Backup-Controller verfügbar, nachdem zwei der drei Controller ausfallen.
Unter erneuter Bezugnahme auf Block 40 wird ein Fehler in dem dritten Controller 15 erkannt, und das Flussdiagramm fährt mit Block 47 fort. Der Block 47 veranschaulicht die Rekonfiguration in Reaktion auf den dritten Controller 15, der ausfällt, nachdem jeder der Controller unter normalen Betriebsbedingungen betrieben wurde. Der dritte Controller 14 fällt aus und tritt in einen Fail-Silent-Modus ein. Der erste Controller 12 arbeitet weiterhin als primärer Controller, da normale Betriebsbedingungen darin vorhanden sind. Der zweite Controller 14 arbeitet weiterhin im Hot-Standby-Statusmodus (HS), da normale Betriebsbedingungen darin vorhanden sind.
In Block 48 wird nach der im Block 47 gezeigten Rekonfiguration ein Fehler im ersten Controller 12 erkannt und der erste Controller 12 wechselt in einen fehlersicheren Modus. Der zweite Controller 14 erkennt den Ausfall des ersten Controllers 12 und wird vom Hot-Standby-Statusmodus (HS) zum Primärstatusmodus (P) als Reaktion auf die Erkennung des Fehlers rekonfiguriert. Die Rekonfiguration ist augenblicklich, da der zweite Controller 14 den ersten Controller 12 spiegelt. Es sind keine Backup-Controller verfügbar, nachdem zwei der drei Controller ausfallen.
In Block 49 wird nach der im Block 47 gezeigten Rekonfiguration ein Fehler in dem zweiten Controller 14 detektiert, und der zweite Controller 14 tritt in einen Fail-Silent-Modus ein. Sowohl der zweite Controller 14 als auch der dritte Controller 15 befinden sich in einem Fail-Silent-Modus. Der erste Controller 12, der bereits im Primärstatusmodus (P) arbeitet, fungiert weiterhin als primärer Controller. Es sind keine Backups verfügbar, nachdem zwei der drei Controller ausfallen.
Es sollte verstanden werden, dass jede Menge von Backup-Controllern verwendet werden kann und dass der gewünschte Ansatz darin besteht, einen einzelnen primären Controller aufzuweisen, einen einzigen Backup-Controller, der im Hot-Standby-Statusmodus (HS) arbeitet, und einem oder mehreren Backup-Controllern, die im Cold-Standby-Statusmodus (CS) arbeiten, wobei die Backup-Controller, die im Cold-Standby-Statusmodus (CS) arbeiten, ruhen oder für andere Verarbeitungsressourcen verwendet werden können, bis ein Fehler auftritt und eine Rekonfiguration durch einen oder mehrere Controller erfolgt. Die Rekonfiguration erfolgt nach einem Controllerausfall, sodass einer der verbleibenden operativen Controller im Primärstatusmodus und ein anderer der verbleibenden operativen Controller in einem Hot-Standby-Modus arbeitet. Das heißt, eine Rekonfiguration in den Primärstatus ist nur mit einem Hot-Standby möglich, eine Rekonfiguration in den Hot-Standby-Modus ist nur mit einem Cold-Standby möglich.
Zwei alternative Ansätze zur Implementierung einer Rekonfiguration sind hier beschrieben. Der erste Ansatz ist ein dezentraler Ansatz und der zweite Ansatz ist ein zentraler Ansatz. Im dezentralisierten Ansatz implementiert jeder Controller die Logik, um den Ausfall eines anderen Controllers im System zu erkennen und gegebenenfalls den Primär- oder Hot-Standby-Status zu rekonfigurieren. Im zentralisierten Ansatz erkennt ein Master-Controller Ausfälle aller anderen Controller im System und bestimmt, welcher Controller den Primärstatus neu konfigurieren soll und welcher Controller den Hot-Standby-Status neu konfigurieren soll. Wenn diese Bestimmung durchgeführt wird, benachrichtigt der Master-Controller den jeweiligen Controller, um seinen Betriebszustand in den primären und den Hot-Standby umzuwandeln und zu ändern. Weiterhin überwacht in diesem zentralisierten Ansatz ein Backup-Master-Controller die Gesundheit des Master-Controllers und, falls der Master-Controller ausfällt, wird der Backup-Master Master-Controller und ordnet einen anderen Controller im System zu dem Backup-Master-Controller zu. Der Master-Controller kommuniziert seinen Status an den Backup-Master-Controller für Konsistenz.
Im Folgenden wird die Logik für den dezentralen Ansatz beschrieben, der für die Auswahl eines jeweiligen Primär- und/oder Backup-Controllers zur Rekonfiguration implementiert ist. Das heißt, wenn drei oder mehr Controller verwendet werden, muss jeder Controller seine Reihenfolge bestimmen, wann eine jeweilige Reihenfolge von einem Cold-Standby-Statusmodus (CS) zu einem Hot-Standby-Statusmodus (HS) und von einem Hot-Standby-Status wechselt der Modus (HS) in einen Primärstatusmodus (P).
Die Notationen für die folgende Beschreibung sind wie folgt. Angesichts einer Softwarekomponente der Funktion A, A wird ein Satz von Controllern zugeordnet Controller_A (die Anzahl der Controller ist bezeichnet mit N_Controllers_A und hängt von der Fehlertoleranz der Funktion A ab (z. B. N_Controller_A – 1 Ausfälle werden behandelt). Auch eine Eins-zu-Eins-Zuordnung zwischen Controller_A und {1, ..., N_Controller_A} ist gegeben und wird bezeichnet als Order_A. Order_A (Controllerx) = 1 bedeutet beispielsweise A ausgeführt auf Controllerx während des normalen, störungsfreien Betriebs. In einem anderen Beispiel bedeutet Order_A (Controllerx) = 3, dass A die zweite Sicherung ist und erst nach zwei Controller-Ausfällen primär sein wird. Der Modus von A auf einem gegebenen Controller Controllerx (d. h. der zu dem Satz von Controllern gehört Controllers_A) ist bezeichnet mit Modus (A, Controllerx) und ist ein Wert in der Menge (Primär, Hot, Cold}. Darüber hinaus weist jeder Controller Controllerx, der zu Controller_A gehört, die Fähigkeit auf, einen Ausfall aller anderen Controller in Controller_A zu erkennen. Während dieses Beispiels wird der Controller als Failing-Fail-Silent beschrieben und die hierin beschriebene Technik gilt für Systeme, bei denen Controller nicht stillschweigend ausfallen, sondern in denen Controller Ausfälle durch andere Mechanismen erkennen können, um so Controllerausfälle zu erkennen. Es sollte auch verstanden werden, dass diese Technik auf mehr als eine Funktion erweitert werden kann. Wenn beispielsweise eine andere Funktion hinzugefügt wird (z. B. Funktion B), werden die Werte den Variablen Controllers_B, N_Controllers_B, und Order_B zugeordnet. Infolgedessen kann eine beliebige Anzahl an Funktionen unterstützt werden, indem nur die Bereitstellung von Werten Controllers_X, N_Controllers_Xi, und Order_X für jede hinzugefügte Funktion X bereitgestellt wird. Die von den Controllern gepflegten Zustandsvariablen für die Funktion A, entsprechend den nachfolgenden Beschreibungen für den dezentralisierten und zentralisierten Ansatz, müssen für jede neue Funktion repliziert werden X. Bemerkenswerte Beispiele für derartige Zustandsvariablen für jede Funktion X sind Modus (X, Controllerx), Num_Controller_Failures_X, Num_HigherPrio_Controller_Failures_X, Operational_Controllers_X, und OperationalOrder_X.
Anfänglich werden, wenn jeder der Controller (z. B. ECUs) unter normalen Betriebsbedingungen betrieben wird, die folgenden Anfangsparameter in jedem Controller eingestellt Controllerx:

Modus (A, Controllerx) = Primär wenn Order_A (Controllerx) = 1
Modus (A, Controllerx) = Hot, wenn Order_A (Controllerx) = 2
Modus (A, Controllerx) = Cold, wenn Order_A (Controllerx) > 2
Zähler Num_Controller_failures_A initialisiert zu 0
Zähler Num_HigherPrio_Controller_Failures_A initialisiert ist 0.

Jedem der Controller ist eine vorgegebene Prioritätsnummer zugeordnet (gegeben durch die Reihenfolge, Order_A) die verwendet wird, um zu bestimmen, ob ein jeweiliger Controller seinen Statusmodus ändern soll. So wird beispielsweise dem primären Controller ein Controller mit einer Prioritätsnummer gleich 1 zugeordnet. Ein Controller mit einer Prioritätsnummer gleich 2 ist der Backup-Controller im Hot-Standby-Status-Modus. Alle anderen Nummern mit einer Prioritätszahl größer als 2 sind Backup-Controller, die im Cold-Standby-Statusmodus arbeiten. Zusätzlich wird der Zähler für Gesamt-Controllerausfälle auf 0 gesetzt. Jeder Controller unterhält einen Prioritätsfehlerzähler, der die Controller mit Ausfällen verfolgt, deren Priorität größer ist als die des aktuellen Controllers, der den Vorgang derzeit verfolgt. Dieser Prioritätszähler wird auch auf null gesetzt. Vergegenwärtigen Sie sich, dass jeder Controller seine eigenen Zählungen der Gesamtzahl der Controller-Ausfälle und Controller-Ausfälle mit einer höheren Priorität als er selbst unterhält. Infolgedessen sollte die Zählung für die Anzahl der Gesamtausfälle für alle zu überwachenden Steuerungen gleich sein; jedoch variiert die Zählung für den ausgefallenen Controller mit einer Prioritätszahl größer als der Überwachungs-Controller Überwachungssteuerung.
Die folgende Logiksequenz beschreibt einen dezentralisierten Ansatz, bei dem jede der Logikfunktionen zur Bestimmung, wann ein Controller sich selbst rekonfigurieren soll, lokal von jedem Controller ausgeführt wird, bezeichnet als Controllerx, da jeder Controller die alle Controller-Ausfälle im Steuerungssystem kennt. In der Erkennung eines Fehlers in einem jeweiligen Controller für einen Satz von Controllern (dargestellt durch den Satz Controllers_A – {Controllerx}) mit zugeordneten Prioritäten wird die folgende Logik verwendet (der fehlgeschlagene Controller wird bezeichnet als Controller_failed):

(a) Steigerung Num_Controller_failures_A;
(b) Wenn zum ausgefallenen Controller Controller_failed, Order_A(Controller_failed) < Order_A (Controllerx), dann Steigerung Num_HigherPrio_Controller_Failures;
(c) Ist Order_A (Controllerx) – Num_HigherPrio_Controller_failures_A = 1, wird dann gesetzt auf Modus (A, Controllerx) bis primär;
(c) Ist Order_A (ECUx) – Num_HigherPrio_Controller_failures_A = 2, wird dann gesetzt auf Modus (A, Controllerx) bis Hot;
(e) Report Num_Controller_failures zur Anwendungsschicht.

In Schritt (a) wird bei Erkennung eines Fehlers die Gesamtzählung erhöht. Darüber hinaus wird auch der Controller ausgegeben.
In Schritt (b), wenn der Controller, der fehlgeschlagen ist, eine Prioritätsnummer aufweist, die kleiner ist als die Prioritätsnummer des Überwachungscontrollers, der die Zählung bestimmt (vergegenwärtigen Sie sich, dass alle Controller jeden dieser Schritte ausführen und ihre eigenen Zählungen beibehalten), erhöht diese Überwachungssteuerung eine höhere Priorität Ausfallzählung Das heißt, eine Prioritätszahl, die kleiner als eine andere Prioritätszahl ist, zeigt an, dass die erstere eine höhere Priorität hat (d. h. sie hat Vorrang in Bezug auf den Primär- oder Hot-Standby). Die höhere Prioritätsfehlerzählung unterstützt den aktuellen Controller bei der Identifizierung der Anzahl an Controllern, die noch unter normalen Betriebsbedingungen arbeiten, die eine höhere Priorität aufweisen (d. h. eine frühere Prioritätsreihenfolge) als die Überwachungssteuerung. Damit kann der Überwachungscontroller feststellen, ob er in den Hot Standby-Statusmodus (HS) oder den Primärstatusmodus (P) rekonfiguriert werden soll.
In Schritt (c) ist die Differenz zwischen der Prioritätsnummer des Überwachungscontrollers und der höheren Prioritätsfehlerzählung, wie sie vom aktuellen Controller aufrechterhalten wird, gleich 1, so wird der aktuelle Controller in den Primärstatusmodus (P) rekonfiguriert.
Ist die Zählung nicht gleich 1, so wird in Schritt (d) geprüft, ob die Differenz gleich 2 ist. Ist die Zählung gleich 2, so wird der Überwachungscontroller in den Hot-Standby-Statusmodus (HS) rekonfiguriert. Ist die Differenz größer als 2, bleibt der Überwachungscontroller im Cold-Standby-Statusmodus (CS).
In Schritt (e) wird der Anwendungsschicht eine Benachrichtigung über den Controller-Ausfall gemeldet. Darüber hinaus kann die Benachrichtigung in Form eines Berichts erfolgen, der erzeugt wird, oder ein Benutzer (z. B. Fahrer) kann durch eine Warnung (visuell, hörbar, haptisch) auf den Fehler hingewiesen werden, eine Telematiknachricht kann an einen Dritten weitergegeben werden, der Störungen auf dem Steuersystem überwacht, Registerwerte schreibt, um Informationen über den Fehler zu liefern, der für eine Softwareanwendung verfügbar ist, oder eine Nachricht, die über das Kommunikationsnetzwerk an andere Controller gesendet wird. Die korrekte Systemreaktion auf die Controller-Fehlermeldung ist anwendungsabhängig.
Im Folgenden wird ein zentraler Ansatz zur Ausführung der Logik zur Bestimmung einer sequentiellen Reihenfolge von Rekonfigurationscontrollern dargestellt. Für den zentralisierten Ansatz werden folgende zusätzliche Notationen und Annahmen angewandt:

(1) Eins-zu-Eins-Zuordnung Order_Master_Controllers von einem Satz von Controllern Master_Controllers (von Kardinalität N_Master_Controllers) zu {1, ..., N_Master_Controllers) (die inverse Zuordnung ist bezeichnet als Order_Master_ECUs’);
(2) Jeder Master-Controller Controller_m ist in der Lage, den Ausfall eines Controllers in der Vereinigung zu erkennen Controllers_A und Master_Controllers (mit Ausnahme von Controller_m selbst);
(3) Der aktuelle Master-Controller ist bezeichnet als Current_Master_Controller;
(4) Der aktuelle Backup--Master Controller ist bezeichnet als Current_Backup_Master_Controller.

Der Ansatz ist wie folgt: Die Variablen Current_Master_Controller und Current_Backup_Master_Controller, identifizieren den Master-Controller und den aktuellen Backup-Master-Controller zu jedem Zeitpunkt des Systembetriebs. Anfänglich, wenn keine Fehler/Ausfälle vorhanden sind, Current_Master_ist der Controller der gegebene Controller Order_Master_Controllers’(1) (d. h. die erste in der Reihenfolge). Der Current_Master_Controller macht die folgenden Initialisierungen (wenn keine Fehler/Ausfälle vorhanden sind) für jeden Controller Controllerx in dem Satz Controllers_A:

Modus (A, Controllerx) = primär wenn Order_A (Controllerx) = 1
Modus (A, Controllerx) = Hot, wenn Order_A (Controllerx) = 2
Modus (A, Controllerx) = Cold, wenn Order_A (Controllerx) > 2.

Zusätzlich werden für den Master-Controller die folgenden Anfangsparameter gesetzt, wenn im System keine Störungen/Fehler vorliegen:

Zähler Num_Contrller_Failures_A initialisiert zu 0;
Satz FailedControllers_A ist der leere Satz;
Initialisieren Num_Master_Controller_Failures = 0;
Initialisieren Current_Backup_Master_Controller = Order_Master_Controllers’(2).

Die Rekonfigurations-Subroutine (RS) wird wie folgt durch Current_Master_Controller bei der Fehlererkennung eines Controllers (bezeichnet mit Controller_failed) in dem Satz Controllers_A – {Current_Master_Controller}:
Die Rekonfigurations-Subroutine RS arbeitet wie folgt. Ein Zähler wird inkrementiert, um die Anzahl der Controller zu verfolgen, die während des Systembetriebs ausgefallen sind. Dieser Zähler berücksichtigt nur die Controller, die die Funktion A hosten. Danach wird die Reihenfolge des ausgefallenen Controllers auf der Grundlage der vorgegebenen statischen Rangfolge aufgezeichnet. Dann wird eine neue Prioritätsreihenfolge unter Berücksichtigung der verbleibenden Operationscontroller (d. h. der Reihenfolge, die verbleibt, nachdem der Controller ausgefallen ist) aufgebaut. Wenn der ausgefallene Controller im Primärstatusmodus betrieben wurde, wird dieser neu konstruierte Auftrag vom aktuellen Mastercontroller verwendet, um zu bestimmen, welcher Controller im Primärstatusmodus sein soll und welcher Controller im Hot Standby Modus sein soll. Wenn andererseits der ausgefallene Controller im Hot-Standby-Modus betrieben wurde, muss der Master-Controller nur den neu konstruierten Auftrag überprüfen, um den Controller zu ermitteln, der in den Hot-Standby-Modus gelangen soll. Nach diesen Bestimmungen wird der aktuelle Master-Controller die Anzahl der Controller-Ausfälle an die Applikationsschicht melden und dann die Zustandsvariablen an den aktuellen Backup-Master-Controller übermitteln. Diese letzte Kommunikation ist erforderlich, damit der aktuelle Backup-Master-Controller die Rolle als Master-Controller korrekt übernehmen kann, falls der aktuelle Master-Controller ausfällt. Diese Fehlermodi und Handhabung sind in den folgenden Abschnitten beschrieben.
Die normalen Betriebsbedingungen dar, die als der Master-Controller definiert sind, der fehlerfrei arbeitet und Störungen anderer Controller, die die Funktion A informiert andere Controller, wenn sie ihren Ausführungsmodus im Falle eines Controllerausfalls umschalten.
Zur Erkennung von Master-Controller- und Backup-Master-Controller-Ausfällen sorgen zusätzliche Routinen dafür, dass der aktuelle Backup-Master die Kontrolle übernimmt, falls ein aktueller Master-Controller ausfällt und auch, dass es immer mindestens einen Backup-Master-Controller bereit zu übernehmen, wenn ein jeweiliger Master-Controller ausfällt.
Die folgende Logik wird von Current_Master_Controller ausgeführt, um Backup-Master-Controller zu überwachen und Verantwortlichkeiten zwischen den Backup-Master-Controllern neu zuzuordnen. In Erkennung des Ausfalls eines Controllers im eingestellten Master_Controllers – (Current_Master_Controller}, wird folgende Logik angewendet:

(a1) Inkrementzähler Num_Master_Controller_Failures;
(a2) wenn der ausgefallene Controller Current_Backup_Master_Controller ist, dann Zuordnen von Current_Backup_Master_Controllerum als ersten operativen (d. h. nicht ausgefallenen) Controller im angeforderten Satz {Order_Master_Controllers’(Num_Master_Controller_Failures+2), Order_Master_Controllers’(Num_Master_Controller_Failures+3), ..., Order_Master_Controllers’(N_Master_Controllers)};
(a3) Kommunizieren zu Current_Backup_Master_Controller, den folgenden Zustand: Modus, Controllers_A, Order_A, Num_Controller_Failures, Num_Master_Controller_Failures.

In Schritt (a1) wird in Reaktion auf die Erfassung durch den aktuellen Master-Controller eines Fehlers eines Backup-Controllers die Gesamtzahl der Ausfälle von Master-Controllern innerhalb eines Zählers erhöht, der durch den aktuellen Master-Controller aufrechterhalten wird.
In Schritt (a2) wird eine Bestimmung durch den aktuellen Master-Controller vorgenommen, ob der Fehler im aktuellen Backup-Master-Controller passiert ist (Current_Backup_Master_Controller). Wenn ja, dann übergibt der aktuelle Master-Controller die Verantwortung des Backup-Master-Controllers einem nächsten Controller mit der nächsthöheren Priorität bei Backup-Master-Controllern. Dieser Controller ist jetzt der Current_Backup_Master_Controller.
In Schritt (a3) informiert der aktuelle Master-Controller den neuen aktuellen Backup-Master-Controller über den Wert der Zählung der Gesamtausfälle (Num_Master_Controller_Failures), da der neue aktuelle Backup-Master-Controller auch eine Zählung beibehalten muss, falls der Master-Controller ausfällt. Alle anderen Zustandsvariablen werden auch mitgeteilt.
Zusätzlich zu den aktuellen Master-Controller-Monitoring-Ausfällen aller Backup-Master-Controller muss der aktuelle Backup-Master-Controller den aktuellen Master-Controller für Ausfälle überwachen. Im Folgenden finden Sie eine Routine zur Erkennung eines Ausfalls des aktuellen (Current_Master_Controllers), der durch die Auswahl neuer Master- und Backup-Master-Controller ausgegeben wird. Die folgende Routine wird vom aktuellen Backup-Master-Controller bei Erkennung des Ausfalls von Current_Master_Controller angewendet:

(b1) Bezeichnet den ausgefallenen Controller durch Controller_failed = Current_Master_Controller, um der neue aktuelle Master-Controller zu werden
(b2) Inkrementzähler Num_Master_Controller_Failures;
(b3) Zuordnen Current_Backup_Master_Controller zum ersten operativen Controller im angeforderten Satz; Order_Master_Controllers’(Num_Master_Controller_Failures+2); Order_Master_Controllers’(Num_Master_Controller_Failures+3); Order_Master_Controllers’(N_Master_Controllers);
(b4) Rekonfigurations-Subroutine (RS) ausführen.

In Schritt (b1) wird eine Erkennung eines aktuellen Master-Controller-Fehlers erkannt und der aktuelle Backup-Master-Controller wird zum neuen Master-Controller. In Schritt (b2) wird in Reaktion auf eine Erfassung des ausgefallenen Master-Controllers der Zähler des Num_Master_Controller_Failures inkrementiert. Dies belegt die Anzahl der Master- und Backup-Master-Controller, die fehlgeschlagen sind. In Schritt (b3) wird der nächste operative (nicht fehlgeschlagene) Backup-Master-Controller in der vorgegebenen Vorrangreihenfolge zugeordnet, um die Rolle des aktuellen Backup-Master-Controllers zu übernehmen. In Schritt (b4) wird die Rekonfigurations-Subroutine ausgeführt, um sicherzustellen, dass eine entsprechende Rekonfiguration durchgeführt wird, falls der ausgefallene Controller die Funktion A im Primär, Hot- oder Cold-Standby-Modus gehostet hat, sowie um sicherzustellen, dass der neue Backup-Master-Controller den aktuellen Zustand des Master-Controllers empfängt.
7 zeigt exemplarische Rekonfigurationen des Master-Controllers und des Backup-Master-Controllers für den zentralen Ansatz. Wie in 7 gezeigt, in dem ersten Zeitintervall wird ein erster Controller der Hauptsteuerung bezeichnet durch M. zugewiesen. Der zweite Controller wird als der von BM bezeichnete Backup-Master-Controller bezeichnet.
Im zweiten Zeitintervall tritt ein Fehler in Bezug auf den aktuellen Backup-Master-Controller BM auf. Als Reaktion auf den Ausfall weist der Master-Controller M die Rolle des Backup-Master-Controllers dem nächsten Operationscontroller des geordneten Satzes zu. Der dritte Controller wird nun als neuer aktueller Backup Master Controller BM bezeichnet.
Im dritten Zeitintervall tritt ein Ausfall in Bezug auf den ersten Controller auf, der als Master-Controller M fungiert. In Reaktion auf den Master-Controller-Ausfall wird der dritte Controller, der als der aktuelle Backup-Master-Controller BM fungiert, rekonfiguriert, um als neuer Master-Controller P zu funktionieren. Zusätzlich wird dem nächsten Operationscontroller des geordneten Satzes der Backup-Controller der aktuelle Backup-Master-Controller BM zugeordnet. Dies kann für so viele Backup-Master-Controller, die im System verfügbar sind, fortsetzen.
8 veranschaulicht eine weitere exemplarische Rekonfiguration des Master-Controllers und des Backup-Master-Controllers für den zentralen Ansatz. In 8 wird im ersten Zeitintervall ein erster Controller dem mit M bezeichneten Mastercontroller zugeordnet. Der zweite Controller wird als Backup-Master-Controller bezeichnet und mit BM bezeichnet.
Im zweiten Zeitintervall tritt ein Fehler in Bezug auf den ersten Controller auf, der als Master-Controller M fungiert. Als Reaktion auf den Master-Controller-Fehler wird der zweite Controller, der als der aktuelle Backup-Master-Controller BM fungiert, rekonfiguriert, um als neuer Master-Controller M zu funktionieren. Zusätzlich wird der aktuelle Operationscontroller des geordneten Satzes der Backup-Master-Controller (d. h. der dritte Controller in diesem Beispiel) dem aktuellen Backup-Master-Controller BM zugeordnet.
Im dritten Zeitintervall tritt ein Fehler in Bezug auf den dritten Controller auf, der als der aktuelle Backup-Master-Controller BM arbeitet. Als Reaktion auf diesen Fehler wird der nächste Betriebscontroller des geordneten Satzes der Backup-Master-Controller (d. h. der vierte Controller) als der aktuelle Backup-Master-Controller BM rekonfiguriert. Dies kann so für viele Backup-Master-Controller, die im System verfügbar sind, fortgesetzt werden. Während bestimmte Ausführungsformen der vorliegenden Erfindung in Einzelheiten beschrieben wurden, werden Fachleute auf dem Gebiet, auf das sich diese Erfindung bezieht, verschiedene alternative Entwürfe und Ausführungsformen für die Durchführung der Erfindung erkennen, wie durch die folgenden Patentansprüche bestimmt.

Claims

Verfahren zur fehlertoleranten Controller-Bereitschaft, umfassend die Schritte: Ausführen von Funktionen durch einen ersten Prozessor, während er unter Nicht-Fehler-Betriebsbedingungen arbeitet, wobei der erste Controller in einem Primärstatusmodus arbeitet, wobei der primäre Controller Steuersignale über ein Kommunikationsnetzwerk ausgibt, um Steuerungsaktionen auszuführen; das Betreiben in einem Hot-Standby-Status-Modus durch einen zweiten Controller unter normalen Betriebsbedingungen, wobei der zweite Controller den ersten Controller durch Ausführen von Funktionen zum Betrieb als redundanten Controller widerspiegelt, Betreiben in einem Cold-Standby-Status-Modus durch mindestens einen Backup-Controller unter normalen Betriebsbedingungen; Rekonfigurieren des zweiten Controllers unter normalen Betriebsbedingungen vom Hot-Standby-Status-Modus zum primären Standby-Status-Modus, wenn im ersten Controller ein Fehler auftritt; Rekonfigurieren des mindestens einen Backup-Controllers, der unter normalen Betriebsbedingungen vom Cold-Standby-Statusmodus in den Hot-Standby-Statusmodus arbeitet, um als redundanter Controller als Reaktion auf die Rekonfiguration des zweiten Controllers vom Hot-Standby-Statusmodus zum Primärstatusmodus zu arbeiten.
Verfahren nach Anspruch 1, worin, falls irgendein jeweiliger Controller ausfällt, der jeweilige ausgefallene Controller in einen fehlersicheren Modus übergeht.
Verfahren nach Anspruch 1, ferner folgende Schritte umfassend: das Erfassen eines Fehlers im zweiten Controller, während des Betriebs im Hot-Standby-Statusmodus, worin der mindestens eine Backup-Controller vom Cold-Standby-Statusmodus in den Hot-Standby-Statusmodus rekonfiguriert wird, wenn ein Fehler im zweiten Controller auftritt.
Verfahren nach Anspruch 2, worin der mindestens eine Backup-Controller eine Vielzahl von Backup-Controllern beinhaltet, worin jede der Vielzahl von Backup-Controllern eine priorisierte Nummer aufweist.
Verfahren nach Anspruch 4, worin ein jeweiliger Backup-Controller mit einer höchsten Priorität unter den mehreren Backup-Controllern aus dem Cold-Standby-Statusmodus in den Hot-Standby-Statusmodus als Reaktion auf die Erkennung eines Fehlers in dem zweiten Controller rekonfiguriert wird.
Verfahren nach Anspruch 5, worin der jeweilige Backup-Controller, der so konfiguriert ist, dass er im Hot-Standby-Statusmodus arbeitet, rekonfiguriert wird, um im Primärstatusmodus zu arbeiten, wenn ein Fehler in einem aktuellen Controller erfasst wird, der im Primärstatusmodus arbeitet.
Verfahren nach Anspruch 6, worin ein nächster jeweiliger Backup-Controller, der im Cold-Standby-Statusmodus arbeitet, mit einer nächsthöheren Priorität unter den mehreren, unter normalen Betriebsbedingungen arbeitenden Backup-Controllern rekonfiguriert ist, um im Hot-Standby-Statusmodus zu arbeiten.
Verfahren nach Anspruch 7, worin das Beibehalten einer priorisierten Reihenfolge jeder der Vielzahl von Backup-Controllern auf einem dezentralisierten Ansatz basiert, worin jeder der Vielzahl von Backup-Controllern unabhängig bestimmt, ob eine Statusmodusänderung erforderlich ist.
Verfahren nach Anspruch 7, worin jede der Vielzahl von Backup-Controllern, die unabhängig ermitteln, ob die Statusmodusänderung erforderlich ist, unter Verwendung einer Priorisierungstechnik durchgeführt wird, die Priorisierungstechnik die folgenden Schritte umfasst: das Zuordnen einer ersten Priorisierungsnummer zu jedem Backup-Controller; das Erfassen eines Ausfalls eines Controllers durch jeden operativen Backup-Controller; das Ermitteln, ob eine aktuelle Priorisierungsnummer des ausgefallenen Controllers eine höhere Priorität hat als ein Überwachungs-Backup-Controller; das Inkrementieren eines Priorisierungsfehlerzählers für den Überwachungssicherungszähler in Reaktion auf den ausgefallenen Controller mit einer höheren Priorität als der Überwachungs-Backup-Controller; das Ermitteln, ob eine Differenz zwischen der zugeordneten Prioritätsnummer des Überwachungs-Backup-Controllers und einem Wert des Priorisierungs-Ausfallzählers gleich Eins ist; und das Ändern des Statusmodus des Überwachungs-Backup-Controllers in den Primärstatusmodus als Reaktion auf die Differenz gleich eins.
Verfahren nach Anspruch 7, worin das Beibehalten der priorisierten Anzahl jeder der Vielzahl von Backup-Controllern auf einem zentralisierten Ansatz basiert, worin der jeweilige Controller, der im Primärstatusmodus arbeitet, eine priorisierte Auflistung der Backup-Controller auf der Grundlage der ausgefallenen Controller aufrechterhält, wobei der jeweilige Controller, der im Primärstatusmodus arbeitet, festlegt, ob eine Statusmodusänderung für den jeweiligen Backup-Controller erforderlich ist, und worin eine Nachricht vom jeweiligen Controller, der im Primärstatusmodus arbeitet, an den jeweiligen Backup-Controller übermittelt wird, um von einem Cold-Standby-Statusmodus zu einem Backup-Standby-Statusmodus zu rekonfigurieren.