DE102017116883A1 - Ununterbrochene Verfügbarkeit von Daten während eines Fehlers in einem redundanten Mikrocontrollersystem - Google Patents

Ununterbrochene Verfügbarkeit von Daten während eines Fehlers in einem redundanten Mikrocontrollersystem Download PDF

Info

Publication number
DE102017116883A1
DE102017116883A1 DE102017116883.4A DE102017116883A DE102017116883A1 DE 102017116883 A1 DE102017116883 A1 DE 102017116883A1 DE 102017116883 A DE102017116883 A DE 102017116883A DE 102017116883 A1 DE102017116883 A1 DE 102017116883A1
Authority
DE
Germany
Prior art keywords
processor
mcu
communication
source
control
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.)
Pending
Application number
DE102017116883.4A
Other languages
English (en)
Inventor
Vinod Shankar Naganathan
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.)
Steering Solutions IP Holding Corp
Original Assignee
Steering Solutions IP Holding 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 Steering Solutions IP Holding Corp filed Critical Steering Solutions IP Holding Corp
Publication of DE102017116883A1 publication Critical patent/DE102017116883A1/de
Pending legal-status Critical Current

Links

Images

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
    • 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/1608—Error detection by comparing the output signals of redundant hardware
    • G06F11/1625—Error detection by comparing the output signals of redundant hardware in communications, e.g. transmission, interfaces
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40169—Flexible bus arrangements
    • H04L12/40176—Flexible bus arrangements involving redundancy
    • 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
    • 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/202—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 processing functionality is redundant
    • G06F11/2038—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 processing functionality is redundant with a single idle spare processing component
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/88—Monitoring involving counting

Abstract

Es werden technische Lösungen zum Bereitstellen eines redundanten Prozessors beschrieben. Eine beispielhafte Verarbeitungseinheit enthält einen Quellenprozessor, der über eine erste Kommunikationsleitung mit einem Systemkommunikationsbus gekoppelt ist; einen Reserveprozessor, der über eine zweite Kommunikationsleitung mit dem Systemkommunikationsbus gekoppelt ist; und einen Kommunikationskanal zwischen Mikroprozessoren zur Kommunikation zwischen dem Quellenprozessor und dem Reserveprozessor. Der Reserveprozessor überwacht einen Fehler des Quellenprozessors, indem er die erste Kommunikationsleitung auf Kommunikationsbotschaften hin überwacht, die von dem Quellenprozessor übertragen werden. Der Reserveprozessor stellt einen Fehler des Quellenprozessors in Ansprechen darauf fest, dass die Kommunikationsbotschaften auf der ersten Kommunikationsleitung eine vorbestimmte Zeitdauerspanne lang fehlen. In Ansprechen auf einen Fehler des Quellenprozessors übernimmt der Reserveprozessor die Steuerung der Kommunikation der Verarbeitungseinheit, indem er eine Statusaktualisierung an den Kommunikationskanal zwischen Mikroprozessoren sendet.

Description

  • QUERVERWEISE AUF VERWANDTE ANMELDUNGEN
  • Diese Patentanmeldung beansprucht die Priorität der vorläufigen US-Patentanmeldung mit der Seriennummer 62/367,791, die am 28. Juli 2016 eingereicht wurde und hier durch Bezugnahme vollständig mit aufgenommen ist.
  • HINTERGRUND
  • Die vorliegende Anmeldung betrifft allgemein eine Prozessorarchitektur und insbesondere das Ermöglichen einer ununterbrochenen Verfügbarkeit von Daten während eines Fehlers in einem redundanten auf Mikrocontrollereinheiten (MCU) beruhenden System.
  • Zunehmende Anforderungen an die Fahrzeugsicherheit treiben die Systemredundanz voran, um höhere Sicherheitsniveaus zu erreichen. Redundanz wird typischerweise durch ein Ausweiten eines Steuerungssystems erzielt, bis zu dem Ausmaß, dass es redundante Mikrocontroller aufweist. Jedoch bringt die Verwendung eines Systems mit redundanten Mikrocontrollern viele Komplexitäten in den Betrieb des Fahrzeugs ein, welche eine Kommunikation innerhalb des Fahrzeugs unter Verwendung eines Netzwerkbusses umfassen, etwa eines Controllerbereichsnetzwerkbusses (CAN-Busses) wie z. B. eines öffentlichen CAN-Busses.
  • Typischerweise sind 2 MCUs mit dem öffentlichen CAN-Bus mit mehreren Architekturen verbunden, um die Daten zu übermitteln, die jede der MCUs kommuniziert. Bei einem oder mehreren Beispielen sind beide MCUs mit 2 verschiedenen CAN-Bussen verbunden und die gleichen Informationen werden ständig über beide Busse gesendet. In diesem Fall wird es kein Problem geben, wenn eine der MCUs ausfällt, da CAN-Informationen an dem anderen CAN-Bus redundant zur Verfügung stehen. Aber in diesem Fall wird die Busbandbreite aufgrund der Redundanz in CAN-Botschaften nicht optimal genutzt. Entsprechend wird bei einer anderen Herangehensweise von den beiden MCUs eine MCU als Reserve für die andere MCU verwendet. Die Reserve-MCU sendet CAN-Botschaften, falls bei der anderen MCU ein Fehler auftritt. Folglich wird eine geeignete Methodik benötigt, um einen MCU-Fehler und/oder einen Fehler bei einer MCU-CAN-Schnittstelle zu identifizieren und um die Reserve-MCU unmittelbar zu aktivieren, damit sie die Steuerung des CAN-Busses übernimmt. Die hier aufgeworfenen technischen Probleme umfassen eine robuste Detektion eines CAN-Fehlers, ein reibungsloses und schnelles Umschalten des CAN-Busses und ein reibungsloses Zurückgeben der CAN-Bussteuerung an die ursprüngliche MCU. Zudem muss sichergestellt werden, dass die beiden MCUs nicht miteinander kommunizieren.
  • ZUSAMMENFASSUNG
  • Es werden technische Lösungen beschrieben, damit ein System mit einer Mikrocontrollereinheit (MCU-System) in einem Fahrzeug eine robuste, effiziente und konsistente Detektion eines Kommunikationsfehlers bereitstellen kann. Die technischen Lösungen ermöglichen ferner eine reibungslose und schnelle Übernahme der Kommunikationssteuerung durch eine Reserve-MCU in Ansprechen auf eine Fehlerbedingung einer Quellen-MCU. Die technischen Lösungen ermöglichen ferner eine reibungslose Rückgabe der Steuerung der Kommunikationssteuerung an die Quellen-MCU nach einer Fehlerbehebung.
  • In Übereinstimmung mit einer oder mehreren Ausführungsformen wird eine Verarbeitungseinheit zum Bereitstellen eines redundanten Prozessors bereitgestellt, wobei die Verarbeitungseinheit einen Quellen-Prozessor enthält, der mit einem Systemkommunikationsbus über eine erste Kommunikationsleitung gekoppelt ist; einen Reserve-Prozessor, der mit dem Systemkommunikationsbus über eine zweite Kommunikationsleitung gekoppelt ist; und einen Kommunikationskanal zwischen Mikroprozessoren zur Kommunikation zwischen dem Quellen-Prozessor und dem Reserve-Prozessor. Der Reserve-Prozessor überwacht den Quellen-Prozessor auf Fehler hin, indem er die erste Kommunikationsleitung auf Kommunikationsbotschaften hin überwacht, die von dem Quellen-Prozessor übertragen werden. Der Reserve-Prozessor stellt einen Fehler des Quellen-Prozessors in Ansprechen darauf fest, dass die Kommunikationsbotschaften auf der ersten Kommunikationsleitung eine vorbestimmte Zeitdauer lang fehlen. In Ansprechen auf einen Fehler des Quellen-Prozessors übernimmt der Reserve-Prozessor die Steuerung der Kommunikation der Verarbeitungseinheit, indem er eine Statusaktualisierung an den Kommunikationskanal zwischen Mikroprozessoren sendet.
  • In Übereinstimmung mit einer oder mehreren Ausführungsformen umfasst ein Verfahren für eine ununterbrochene Kommunikation von Daten von einem Verarbeitungssystem, dass von einem zweiten Prozessor ein erster Prozessor auf Fehler hin überwacht wird, indem eine erste Kommunikationsleitung, die dem ersten Prozessor zugeordnet ist, auf Kommunikationsbotschaften hin überwacht wird, die von dem ersten Prozessor übertragen werden. Das Verfahren umfasst ferner, dass von dem zweiten Prozessor der Fehler des ersten Prozessors in Ansprechen darauf festgestellt wird, dass die Kommunikationsbotschaften auf der ersten Kommunikationsleitung eine vorbestimmte Zeitdauer lang fehlen. Das Verfahren umfasst ferner, dass in Ansprechen auf den Fehler des ersten Prozessors die Steuerung der Kommunikation des Verarbeitungssystems von dem zweiten Prozessor übernommen wird, indem er eine Statusaktualisierung an einen Kommunikationskanal zwischen Mikroprozessoren zwischen dem ersten Prozessor und dem zweiten Prozessor sendet.
  • In Übereinstimmung mit einer oder mehreren Ausführungsformen wird ein Computerprogrammprodukt bereitgestellt, das ein nicht vorübergehendes Computerspeichermedium enthält, welches von einem Computer ausführbare Anweisungen enthält, wobei die von einem Computer ausführbaren Anweisungen, wenn sie von einem Verarbeitungssystem ausgeführt werden, veranlassen, dass das Verarbeitungssystem: durch einen zweiten Prozessor des Verarbeitungssystems einen ersten Prozessor des Verarbeitungssystems auf Fehler überwacht, indem eine erste Kommunikationsleitung, die dem ersten Prozessor zugeordnet ist, auf Kommunikationsbotschaften hin überwacht wird, die von dem ersten Prozessor übertragen werden; durch den zweiten Prozessor den Fehler des ersten Prozessors in Ansprechen darauf feststellt, dass die Kommunikationsbotschaften auf der ersten Kommunikationsleitung eine vorbestimmte Zeitdauer lang fehlen; und in Ansprechen auf den Fehler des ersten Prozessors durch den zweiten Prozessor die Steuerung der Kommunikation des Verarbeitungssystems übernommen wird, indem eine Statusaktualisierung an einen Kommunikationskanal zwischen Mikroprozessoren zwischen dem ersten Prozessor und dem zweiten Prozessor gesendet wird.
  • Diese und andere Vorteile und Merkmale werden sich aus der folgenden Beschreibung besser ergeben, wenn sie in Verbindung mit den Zeichnungen gelesen wird.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Der Gegenstand, der als die Erfindung betrachtet wird, wird speziell dargelegt und in den Ansprüchen am Ende der Beschreibung separat beansprucht. Die vorstehenden und weitere Merkmale und Vorteile der Erfindung ergeben sich aus der folgenden genauen Beschreibung, wenn sie in Verbindung mit den beiliegenden Zeichnungen gelesen wird, in denen:
  • 1 eine beispielhafte Ausführungsform eines Fahrzeugs mit einem Lenkungssystem veranschaulicht;
  • 2 ein beispielhaftes System mit redundanten Mikrocontrollereinheiten (MCU-System) in Übereinstimmung mit einer oder mehreren Ausführungsformen veranschaulicht;
  • 3 ein Flussdiagramm für ein beispielhaftes Verfahren zum Starten des MCU-Systems in Übereinstimmung mit einer oder mehreren Ausführungsformen veranschaulicht;
  • 4 ein Flussdiagramm für ein beispielhaftes Verfahren in Übereinstimmung mit einer oder mehreren Ausführungsformen veranschaulicht, bei dem eine Quellen-MCU eine Reserve-MCU auffordert, die Steuerung einer CAN-Kommunikation zu übernehmen;
  • 5 ein Flussdiagramm für ein beispielhaftes Verfahren in Übereinstimmung mit einer oder mehreren Ausführungsformen veranschaulicht, bei dem eine Quellen-MCU aufgefordert wird, die Steuerung einer CAN-Kommunikation freizugeben;
  • 6 ein Flussdiagramm für ein beispielhaftes Verfahren zum Behandeln eines Busunterbrechungs-Szenarios durch eine Quellen-MCU eines redundanten MCU-Systems in Übereinstimmung mit einer oder mehreren Ausführungsformen veranschaulicht;
  • 7 ein Flussdiagramm für ein beispielhaftes Verfahren für ein Busunterbrechungsbehebungs-Ereignis in Übereinstimmung mit einer oder mehreren Ausführungsformen veranschaulicht; und
  • 8 eine beispielhafte Datenstruktur für Statusinformationen einer Kommunikation zwischen Mikrocontrollern in Übereinstimmung mit einer oder mehreren Ausführungsformen darstellt.
  • GENAUE BESCHREIBUNG
  • Die Begriffe Modul und Teilmodul bezeichnen, so wie sie hier verwendet werden, eine oder mehrere Verarbeitungsschaltungen, etwa eine anwendungsspezifische integrierte Schaltung (ASIC), eine elektronische Schaltung, einen Prozessor (gemeinsam genutzt, dediziert, oder Gruppe) mit Speicher, der ein oder mehrere Software- oder Firmwareprogramme ausführt, eine kombinatorische Logikschaltung und/oder andere geeignete Komponenten, welche die beschrieben Funktionalität bereitstellen. Wie festzustellen ist, können die nachstehend beschriebenen Teilmodule kombiniert und/oder weiter unterteilt werden.
  • Mit Bezug nun auf 1 ist eine beispielhafte Ausführungsform eines Fahrzeugs 10, das ein Lenkungssystem 12 enthält, dargestellt. In verschiedenen Ausführungsformen enthält das Lenkungssystem 12 ein Lenkrad 14, das mit einem Lenkwellensystem 16 gekoppelt ist, welches eine Lenksäule, eine Zwischenwelle und die notwendigen Gelenke enthält. Bei einer beispielhaften Ausführungsform ist das Lenkungssystem 12 ein EPS-System, das ferner eine Lenkungsassistenzeinheit 18 enthält, welche mit dem Lenkwellensystem 16 des Lenkungssystems 12 und mit Spurstangen 20, 22 des Fahrzeugs 10 gekoppelt ist. Alternativ kann die Lenkungsassistenzeinheit 18 den oberen Abschnitt des Lenkwellensystems 16 mit dem unteren Abschnitt dieses Systems koppeln. Die Lenkungsassistenzeinheit 18 enthält beispielsweise einen (nicht gezeigten) Lenkungsmechanismus mit einer Zahnstange und einem Ritzel, der durch das Lenkwellensystem 16 mit einem Lenkungsaktormotor 19 und einem Getriebe gekoppelt sein kann. Wenn ein Fahrzeugbediener im Betrieb das Lenkrad 14 dreht, stellt der Lenkungsaktormotor 19 die Unterstützung zum Bewegen der Spurstangen 20, 22 bereit, welche wiederum Lenkungsachsschenkel 24 bzw. 26 bewegt, die jeweils mit Straßenrädern 28, 30 des Fahrzeugs 10 gekoppelt sind.
  • Wie in 1 gezeigt ist, enthält das Fahrzeug 10 ferner verschiedene Sensoren 31, 32, 33, welche beobachtbare Bedingungen des Lenkungssystems 12 und/oder des Fahrzeugs 10 detektieren und messen. Die Sensoren 31, 32, 33 erzeugen Sensorsignale auf der Grundlage der beobachtbaren Bedingungen. Bei einem Beispiel ist der Sensor 31 ein Drehmomentsensor, der ein eingegebenes Fahrerlenkraddrehmoment (HWT) erfasst, das von dem Bediener des Fahrzeugs 10 auf das Lenkrad 14 aufgebracht wird. Auf dieser Grundlage erzeugt der Drehmomentsensor ein Fahrerdrehmomentsignal. Bei einem weiteren Beispiel ist der Sensor 32 ein Motorwinkel- und Geschwindigkeitssensor, der einen Drehwinkel sowie eine Drehgeschwindigkeit des Lenkungsaktormotors 19 erfasst. Bei noch einem weiteren Beispiel ist der Sensor 32 ein Lenkradpositionssensor, der eine Position des Lenkrads 14 erfasst. Der Sensor 33 erzeugt auf dieser Grundlage ein Lenkradpositionssignal.
  • Ein Steuerungsmodul 40 empfängt das eine oder die mehreren Sensorsignale, die von den Sensoren 31, 32, 33 eingegeben werden, und es kann andere Eingaben empfangen, etwa ein Fahrzeuggeschwindigkeitssignal 34. Das Steuerungsmodul 40 erzeugt ein Befehlssignal zum Steuern des Lenkungsaktormotors 19 des Lenkungssystems 12 auf der Grundlage einer oder mehrerer der Eingaben und ferner auf der Grundlage der Lenkungssteuerungssysteme und Verfahren der vorliegenden Offenbarung. Die Lenkungssteuerungssysteme und Verfahren der vorliegenden Offenbarung wenden eine Signalaufbereitung auf ein Steuerungssignal an, das verwendet werden kann, um Aspekte des Lenkungssystems 12 durch die Lenkungsassistenzeinheit 18 zu steuern.
  • Bei einem oder mehreren Beispielen ist das Steuerungsmodul 40 eine ECU, die mit einem Echtzeitbetriebssystem (RTOS) betrieben wird. Es sei darauf hingewiesen, dass, obwohl hier ein Lenkungssystem 12 dargestellt ist, das von einer ECU betrieben wird, die hier beschriebenen technischen Lösungen auf verschiedene andere Szenarien angewendet werden können, etwa in anderen ECUs, die andere Komponenten des Fahrzeugs 10 betreiben, unter anderem beispielsweise eine Kraftmaschine, ein Abgassystem, ein Reifendrucküberwachungssystem und ein Infotainment-System. Des Weiteren ist die Anwendbarkeit der technischen Lösungen nicht auf ein Fahrzeug beschränkt, stattdessen auf jedes andere Gebiet, bei dem ein Mikrocontroller verwendet wird, etwa medizinische Geräte, Industriemaschinen und dergleichen. Speziell sind die hier beschriebenen technischen Lösungen auf eine Mikrocontrollereinheit (MCU) anwendbar, die zwei oder mehr Mikrocontroller enthält, die verwendet werden, um Redundanz bereitzustellen.
  • 2 veranschaulicht ein beispielhaftes redundantes MCU-System 200 in Übereinstimmung mit einer oder mehreren Ausführungsformen. Das dargestellte MCU-System 200 ist im Kontext des Fahrzeugs 10 dargestellt, wobei eine Kommunikation zu/von der MCU-Architektur 200 unter Verwendung eines oder mehrerer Controllerbereichsnetzwerksbusse (CAN-Busse) ausgeführt wird. Ferner werden in der dargestellten MCU-Architektur 200 zwei Mikrocontroller verwendet, um Redundanz bereitzustellen. Es sei erwähnt, dass das MCU-System 200 in anderen Implementierungen zusätzliche Mikrocontroller enthalten kann. Die MCUs des MCU-Systems 200 sind intern durch eine Kommunikation zwischen Mikrocontrollern (IMC) verbunden, um Informationen untereinander gemeinsam zu nutzen, etwa Statusinformationen.
  • In dem dargestellten Beispiel agiert eine MCU-2 220 als Reserve für die MCU-1 210 und umgekehrt, bei einem Fehler in der CAN-Kommunikation. Entsprechend empfangen andere Knoten, die über den CAN-Bus verbunden sind, weiterhin Informationen von der MCU-Architektur 200 (das heißt, die Verfügbarkeit von Daten für die anderen Knoten wird sichergestellt). Typischerweise wird die MCU, die eine CAN-Kommunikation in einem speziellen Bus besitzt, als Quellen-MCU bezeichnet, und die MCU, die eine Reserve für die CAN-Kommunikation bereitstellt, wird als Reserve-MCU bezeichnet. Eine Quellen-MCU von einem Bus wird als Reserve-ECU für den anderen Bus agieren.
  • Beispielsweise wird in 2 ein erster Fall betrachtet, bei dem die MCU-1 210 die Quellen-MCU ist, die eine Kommunikation über einen CAN-Bus-1 215 besitzt, und die MCU-2 220 ist die Reserve-MCU für die Kommunikation, die sie über einen CAN-Bus-2 225 empfängt. In einem anderen Fall ist die MCU-2 220 die Quellen-MCU, die eine Kommunikation über den CAN-Bus-2 225 besitzt, und die MCU-1 210 ist die Reserve-MCU für eine Kommunikation, die über den CAN-Bus-1 215 empfangen wird. Der CAN-Bus-1 215 und der CAN-Bus-2 225 sind mit entsprechenden öffentlichen CAN-Bussen verbunden, einem öffentlichen CAN-Bus-1 217 und einem öffentlichen CAN-Bus-2 227.
  • Die CAN-Kommunikation kann aufgrund eines Fehlers gestoppt werden, etwa aufgrund eines Problems mit einem CAN-Sender/Empfänger, eines Ausschaltens einer MCU, eines Rücksetzens einer MCU aufgrund eines Fehlers, einer lokalen Unterbrechung einer CAN-Busleitung an der MCU, eines Kurzschlusses in einer CAN-Busleitung lokal an der MCU, eines anwendungsspezifischen Abschaltens der CAN-Kommunikation und dergleichen. Es versteht sich, dass das Vorstehende nur ein paar Beispiele sind, und dass die CAN-Kommunikation durch andere Fehler unterbrochen werden kann.
  • Die hier beschriebenen technischen Lösungen ermöglichen das Detektieren eines CAN-Fehlers, das Bereitstellen einer Reserve-CAN-Kommunikation, und das Zurückgeben der Steuerung des CAN-Busses an die Quellen-MCU bei Behebung des Fehlers. Die technischen Lösungen ermöglichen ferner das Sicherstellen, dass es keinen Fall gibt, bei dem alle MCUs des MCU-Systems 200 die gleiche CAN-Botschaft kommunizieren. Mit Bezug auf 2 beispielsweise können die zwei MCUs des MCU-Systems 200 die gleiche Botschaft zumindest in den folgenden Fällen kommunizieren. Zum Beispiel kann eine verzögerte CAN-Kommunikation in der Quellen-MCU bei der Reserve-MCU als ein MCU-Fehler detektiert werden. Zudem oder alternativ kann eine Busunterbrechung während der Behebung in der Quellen-MCU als Fehler bei der Reserve-MCU detektiert werden. Zusätzlich oder alternativ kann, wenn die Quellen-MCU zurückgesetzt wird, was zu einer Zeitspanne ohne CAN-Kommunikation führt, die Reserve-MCU dies als einen CAN-Busfehler ansehen. Es sei erwähnt, dass in den vorstehenden Beispielen die Quellen-MCU die MCU-1 210 sein kann und die Reserve-MCU die MCU-2 220 sein kann oder umgekehrt. Die hier beschriebenen technischen Lösungen überwinden diese Szenarien und ermöglichen eine ununterbrochene Verfügbarkeit von Daten während eines Fehlers in einem redundanten MCU-System 200.
  • Bei einem oder mehreren Beispielen ermöglichen die technischen Lösungen das Identifizieren eines Stoppens einer CAN-Kommunikation in dem redundanten MCU-System 200. In der folgenden Beschreibung wird die MCU-1 210 als Quellen-MCU betrachtet und die MCU-2 220 ist die Reserve-MCU, wobei darauf hingewiesen wird, dass das gleiche in dem Fall zutrifft, bei dem die MCU-2 220 als Quellen-MCU agiert und die MCU-1 210 die Reserve-MCU ist. Das Stoppen der CAN-Kommunikation kann beispielsweise unter Verwendung von drei Parametern identifiziert werden. Der erste Parameter kann das Fehlen eines CAN-Telegramms [engl.: frame] auf dem CAN-Bus von der Quellen-MCU sein. Der zweite Parameter kann eine MCU-Statusinformation sein, die zwischen den MCUs des MCU-Systems 200 über die IMC 230 übermittelt wird. Der dritte Parameter kann ein Fehler in einer CAN-Übertragung, der bei der Quellen-MCU detektiert wird/eine Busunterbrechung bei der Quellen-MCU sein.
  • Die Quellen-MCU führt beispielsweise unter anderem zumindest die folgenden Operationen aus. Die Quellen-MCU prüft eine Bestätigung der erfolgreichen Übertragung für jedes Telegramm, das sie überträgt. Nach n aufeinanderfolgenden fehlenden Übertragungsbestätigungen überträgt die Quellen-MCU eine Statusinformation über den Kommunikationskanal 230 zwischen Mikrocontrollern, um der Reserve-MCU anzuzeigen, dass sie die CAN-Kommunikation übernehmen soll. Hier ist n eine vorbestimmte ganze Zahl, etwa 5, 10 oder eine beliebige andere. Zu diesem Zeitpunkt stoppt die Quellen-MCU die Übertragung. Alle CAN-Botschaften, welche von der Quellen-MCU übertragen werden sollen, werden von der Quellen-MCU als ausstehend (und als von der Reserve-MCU zu übertragen) markiert. Im Fall, dass die Empfangsfähigkeit der Quellen-MCU ausgeschaltet ist, wird sie zu diesem Zeitpunkt bei der Quellen-MCU eingeschaltet.
  • Zusätzlich oder alternativ überträgt die Quellen-MCU bei Busunterbrechung eine Statusinformation über den Kommunikationskanal 230 zwischen Mikroprozessoren, um der Reserve-MCU anzuzeigen, dass sie die CAN-Kommunikation übernehmen soll. Zu diesem Zeitpunkt stoppt die Quellen-MCU die Übertragung. Alle CAN-Botschaften, die von der Quellen-MCU übertragen werden sollen, werden bei der Quellen-MCU als ausstehend und als von der Reserve-MCU zu übertragen markiert. Im Fall, dass die Empfangsfähigkeit ausgeschaltet ist, wird sie zu diesem Zeitpunkt bei der Quellen-MCU eingeschaltet.
  • Zusätzlich führt die Reserve-MCU unter anderem zumindest die folgenden Operationen aus. Alle CAN-Botschaften, die von der Quellen-MCU übertragen werden sollen, werden für die Reserve-MCU als Quellen- und ausstehende CAN-Botschaften konfiguriert. Bei einem oder mehreren Beispielen ist die Übertragung von Botschaften durch die Reserve-MCU anfänglich abgeschaltet. Wenn die Reserve-MCU m Mal eine Empfangs-Zeitüberschreitung der CAN-Botschaften von der Quellen-MCU erkennt, prüft die Reserve-MCU den Status der Quellen-MCU über den IMC-Kanal 230. Hier ist m eine vorbestimmte ganze Zahl, etwa 5, 10 oder dergleichen. Wenn die Statusinformationen von der Quellen-MCU verfügbar sind und wenn die Statusinformationen anzeigen, dass die CAN-Kommunikation der Quellen-MCU funktioniert, dann ergreift die Reserve-MCU keine Maßnahme, sondern zeigt der Quellen-MCU über den IMC 230 an, dass die Reserve-MCU die CAN-Botschaften nicht wahrgenommen hat. Zudem oder alternativ fordert die Reserve-MCU die Quellen-MCU auf, zu bestätigen, dass die Quellen-MCU gerade fehlerfrei arbeitet. Wenn die Quellen-MCU in Ansprechen darauf anzeigt, dass die CAN-Kommunikation ohne jeden Fehler arbeitet, dann folgert die Reserve-ECU, dass es eine Verzögerung bei der Übertragung von der Quellen-MCU oder auf dem Bus gibt. Alternativ nimmt die Reserve-MCU an, dass die CAN-Leitung fehlerhaft ist, und zeigt keinerlei Fehler an, sondern setzt das Pollen nach CAN-Botschaften fort. Alternativ nimmt die Reserve-MCU an, dass die CAN-Übertragung aufgrund einer anwendungsbasierten Abschaltung der CAN-Übertragung bei der Quellen-MCU abgeschaltet wurde, zum Beispiel durch ein auf einer Diagnose basierendes Abschalten der CAN-Kommunikation.
  • Wenn alternativ die Statusinformationen von der Quellen-MCU nicht zur Verfügung stehen, dann nimmt die Reserve-MCU an, dass die Quellen-MCU heruntergefahren wurde oder zurückgesetzt wird. Folglich übernimmt die Reserve-MCU die Steuerung des CAN-Busses. Die Reserve-MCU informiert die Quellen-MCU über den IMC 230, dass die Reserve-MCU die CAN-Steuerung übernommen hat.
  • Im Fall, dass die Statusinformationen von der Quellen-MCU zur Verfügung stehen und wenn die Statusinformationen ferner anfordern, dass die Reserve-MCU die CAN-Kommunikation übernehmen soll, übernimmt die Reserve-MCU die Steuerung des CAN-Busses und informiert die Quellen-MCU über den IMC 230, dass sie die CAN-Steuerung übernommen hat.
  • Zusätzlich oder alternativ prüft die Reserve-MCU die Statusinformationen über IMC und wenn die Quellen-MCU eine Übernahme des Busses anfordert, dann übernimmt die Reserve-MCU die Steuerung des CAN-Busses und aktualisiert die IMC-Informationen, dass sie die CAN-Steuerung übernommen hat.
  • Alle von der Quellen-MCU übertragenen CAN-Botschaften sind so konfiguriert und markiert, dass sie der Quellen-MCU gehören und CAN-Botschaften sind, die von der Reserve-MCU empfangen werden sollen. Anfänglich ist die Übertragungsfähigkeit der Reserve-MCU abgeschaltet. Sobald Unterstützung durch die Reserve angefordert wird, werden alle CAN-Botschaften zur Übertragung aktiviert oder unmittelbar gestartet. Das Empfangen der Botschaften wird unmittelbar gestoppt.
  • Die hier beschriebenen technischen Lösungen ermöglichen ferner einen Handshake zwischen der Quellen-MCU und der Reserve-MCU, um eine konsistente Übergabe von Verantwortlichkeiten für CAN-Kommunikationen zwischen den beiden MCUs sicherzustellen. Beispielsweise stellt der Handshake sicher, dass nach einer Fehlerbehebung die Steuerung des CAN-Busses an die Quellen-MCU zurückgegeben wird.
  • Es werden als Beispiel die folgenden vier Fälle betrachtet, bei denen die Steuerung des Kommunikationsbusses an die Quellen-MCU zurückgegeben werden muss; Fall 1: Behebung einer Busunterbrechung bei der Quellen-MCU; Fall 2: Neustart nach einem Zurücksetzen der Quellen-MCU; Fall 3: Anwendungsbasiertes Wiedereinschalten der CAN-Kommunikation von der Quellen-MCU; und Fall 4: Fehlerbehebung bei der Quellen-MCU.
  • Im Fall 1 der Behebung einer Busunterbrechung beispielsweise sendet die Quellen-MCU nach Behebung der Busunterbrechung einen Status über den IMC 230, um die Steuerung der CAN-Kommunikation zurückzuerhalten. Die Quellen-MCU wartet auf eine Rückmeldung über den IMC 230, die bestätigt, dass die Reserve-MCU die Übertragung gestoppt hat. Wenn die Quellen-MCU aktualisierte IMC-Informationen empfängt, dann fährt die Quellen-MCU mit dem Warten fort, bis sie eine Bestätigung von der Reserve-MCU empfängt. Die Quellen-MCU empfängt ferner die CAN-Kommunikation, die von der Reserve-MCU gesendet wird.
  • Tabelle 1 veranschaulicht die verschiedenen Fälle und Operationen, die in diesen Fällen von der Quellen-MCU ausgeführt werden. Tabelle 1
    Verfügbarkeit des IMC-Signals IMC-Status CAN-Empfangsstatus Maßnahme Erklärung
    NEIN X KEINE CAN-Botschaften Übernimmt die Steuerung. Aktualisiert IMC-Status durch Anzeige, dass Steuerung übernommen wurde Dies ist ein Fall, bei dem die Reserve-MCU heruntergefahren ist oder nicht kommunizieren konnte
    NEIN X CAN-Botschaften wahrgenommen Wartet, bis CAN-Botschaften gestoppt sind Dies ist ein Fall, bei dem die IMC-Leitung deaktiviert ist
    JA Reserve hat Steuerung KEINE CAN-Botschaften Wartet, bis Reserve-MCU Steuerung freigibt Dies ist ein Fall, bei dem die Quellen-MCU einen Fehler noch nicht vollständig behoben hat
    JA Reserve hat Steuerung CAN-Botschaften wahrgenommen Wartet, bis Reserve-MCU Steuerung freigibt Normaler Fehlerbehebungsfall
    JA Reserve hat Steuerung freigegeben/hat die Steuerung nicht KEINE CAN-Botschaff Übernimmt Steuerung. Aktualisiert IMC-Status durch Anzeige, dass Steuerung übernommen wurde Normaler Fehlerbehebungsfall
    JA Reserve hat Steuerung freigegeben/hat die Steuerung nicht CAN-Botschaften wahrgenommen Wartet, bis CAN-Botschaften gestoppt sind Dies kann ein Übergangsfall oder ein Fehlerszenario sein
  • Ferner wird der Fall 2 eines Neustarts der Quellen-MCU nach einem Zurücksetzen betrachtet. Beim Starten setzt die Quellen-MCU die Empfangsfähigkeit ihrer CAN-Botschaften auf aktiviert und das Übertragen auf deaktiviert. Die Quellen-MCU liest die IMC-Statusinformationen und den Status der CAN-Empfangsaktivität und handelt wie in Tabelle 2. Tabelle 2
    Verfügbarkeit des IMC-Signals IMC-Status CAN-Empfangsstatus Maßnahme Erklärung
    NEIN X KEINE CAN-Botschaften Übernimmt Steuerung. Aktualisiert IMC-Status durch Anzeige, dass Steuerung übernommen wurde Normaler Startfall
    NEIN X CAN-Botschalten wahrgenommen Fordert Freigabe der Steuerung an. Wartet, bis CAN-Botschaften gestoppt sind Dies ist ein Fall, bei dem die IMC-Leitung deaktiviert ist.
    JA Reserve hat Steuerung KEINE CAN-Botschaften Fordert Freigabe der Steuerung an. Wartet, bis Reserve-MCU die Steuerung freigibt Dies ist ein Fall, bei dem die Quellen-MCU einen Fehler noch nicht vollständig behoben hat
    JA Reserve hat Steuerung CAN-Botschalten wahrgenommen Fordert Freigabe der Steuerung an. Wartet, bis Reserve-MCU die Steuerung freigibt Normaler Fehlerbehebungsfall.
    JA Reserve hat Steuerung freigegeben/hat die Steuerung nicht KEINE CAN-Botschaften Übernimmt Steuerung. Aktualisiert IMC-Status durch Anzeige, dass Steuerung übernommen wurde. Normaler Startfall
    JA Reserve hat Steuerung freigegeben/hat die Steuerung nicht CAN-Botschalten wahrgenommen Fordert Freigabe der Steuerung an. Wartet, bis CAN-Botschalten gestoppt sind Dies könnte ein Übergangsfall oder ein Fehlerszenario sein
  • Es wird ferner der Fall 3 einer anwendungsbasierten Reaktivierung einer CAN-Kommunikation von der Quellen-MCU betrachtet. Bei einem oder mehreren Beispielen versetzt die Quellen-MCU auf eine anwendungsbasierte Deaktivierungsanforderung hin alle ihre CAN-Botschaften in einen ausstehend-Modus. In diesem Fall kann es sein, dass die Reserve-MCU die Steuerung der CAN-Kommunikation nicht übernommen hat. Jedoch kann die Quellen-MCU nochmals prüfen, dass dies der Fall ist, bevor sie die Kommunikation aktiviert. Die Quellen-MCU liest die IMC-Statusinformationen und den Status der CAN-Empfangsaktivität und handelt wie in Tabelle 3. Tabelle 3
    Verfügbarkeit des IMC-Signals IMC Status CAN-Empfangsstatus Maßnahme Erklärung
    NEIN X KEINE CAN-Botschaften Übernimmt Steuerung. Aktualisiert IMC-Status durch Anzeigen, dass Steuerung übernommen wurde IMC-Leitung könnte möglicherweise fehlerhaft sein oder die Reserve-MCU ist heruntergefahren oder fehlerhaft
    NEIN X CAN-Botschaften wahrgenommen Fordert Freigabe der Steuerung an. Wartet bis CAN-Botschaften gestoppt sind Dies ist ein Fall, bei dem die IMC-Leitung abgeschaltet ist. Dies ist ein Fehlerfall, bei dem die Reserve-MCU die Steuerung übernommen hat, als sie es nicht sollte. Die Quellen-MCU kann bei Bedarf einen Fehler signalisieren.
    JA Reserve hat Steuerung KEINE CAN-Botschaften Fordert Freigabe der Steuerung an. Wartet, bis Reserve-MCU die Steuerung freigibt Dies ist ein Fehlerfall, bei dem die Reserve-MCU die Steuerung übernommen hat, als sie es nicht sollte. Die Quellen-MCU kann bei Bedarf einen Fehler signalisieren.
    JA Reserve hat Steuerung CAN-Botschaften wahrgenommen Fordert Freigabe der Steuerung an. Wartet, bis Reserve-MCU Steuerung freigibt Dies ist ein Fehlerfall, bei dem die Reserve-MCU die Steuerung übernommen hat, als sie es nicht sollte. Die Quellen-MCU kann bei Bedarf einen Fehler signalisieren
    JA Reserve hat Steuerung freigegeben/hat die Steuerung nicht KEINE CAN-Botschaften Übernimmt Steuerung. Aktualisiert IMC-Status durch Anzeigen, dass Steuerung übernommen wurde Normaler Fall.
    JA Reserve hat Steuerung freigegeben/hat die Steuerung nicht CAN-Botschaften wahrgenommen Fordert Freigabe der Steuerung an. Wartet, bis CAN-Botschaften gestoppt sind Dies ist ein Fehlerfall, bei dem die Reserve-MCU die Steuerung übernommen hat, als sie es nicht sollte. Die Quellen-MCU kann bei Bedarf einen Fehler signalisieren.
  • In dem Fall 4 einer Fehlerbehebung arbeiten die Quellen-MCU und die Reserve-MCU ähnlich wie in dem Fall der Behebung einer Busunterbrechung (Tabelle 1).
  • Des Weiteren im Fall, dass mehrere MCUs einen Fehler aufweisen, beispielsweise, wenn die beiden MCUs des MCU-Systems 200 Probleme in jeweiligen CAN-Kommunikationsbussen erkennen, meldet eine oder melden beide MCUs einen Fehler. Wenn beispielsweise ein IMC-Statussignal von der Quellen-MCU der Reserve-MCU anzeigt, dass sie die Steuerung des CAN-Kommunikationsbusses übernehmen soll, und wenn die Reserve-MCU bei der Übernahme der Steuerung erkennt, dass ihre eigene Übertragung auf dem Kommunikationsbus nicht erreichbar ist, oder wenn die Reserve-MCU eine Busunterbrechung detektiert, dann gibt die Reserve-MCU die Steuerung des Kommunikationsbusses frei und meldet einen Fehler. Bei einem oder mehreren Beispielen stößt auch die Quellen-MCU auf das Detektieren der Steuerungsfreigabe durch die Reserve-MCU hin eine Fehlermeldung an. Das Melden des Fehlers durch eine der MCUs umfasst das Senden einer Kommunikationsbotschaft, die den Fehler anzeigt.
  • 3 veranschaulicht ein Flussdiagramm für ein beispielhaftes Verfahren zum Starten des MCU-Systems 200 in Übereinstimmung mit einer oder mehreren Ausführungsformen. Die nachstehende Beschreibung erfolgt im Kontext des MCU-Systems 200, das mit zwei MCUs ausgestattet ist, jedoch sei angemerkt, dass das Verfahren auf ein MCU-System 200 mit zusätzlichen MCUs angewendet werden kann. Zu Beginn deaktiviert das MCU-System 200 das Übertragen von beiden MCUs, der MCU-1 210 und der MCU-2 220, wie bei 310 gezeigt ist. Das Deaktivieren des Übertragens umfasst das Platzieren oder Markieren der CAN-Botschaften so, dass sie von beiden MCUs empfangen werden können. Es wird in Betracht gezogen, dass die MCU-1 210 beim Starten als Quellen-MCU und die MCU-2 220 als Reserve-MCU gestartet werden soll.
  • Die Quellen-MCU prüft den IMC-Kanal 230 auf IMC-Statusinformationen, um festzustellen, ob die MCU-1 210 als Quellen-MCU eingerichtet wurde und die MCU-2 220 als Reserve-MCU eingerichtet wurde. Bei einem oder mehreren Beispielen prüft die MCU-1 210, ob die IMC-Statusinformationen der MCU-1 210 gültig sind, wie bei 320 gezeigt ist. Wenn die Statusinformationen gültig sind, prüft die MCU-1 210 ferner, ob die Statusinformationen die MCU-1 210 als die Quellen-MCU anzeigen, wie bei 330 gezeigt ist. Wenn die MCU-1 210 beispielsweise als Quellen-MCU eingerichtet ist, zeigen die IMC-Statusinformationen an, dass die CAN-Botschaften des MCU-Systems 200 von der MCU-1 210 gesteuert werden.
  • Wenn die IMC-Statusinformationen anzeigen, dass die MCU-2 220 die CAN-Botschaften des MCU-Systems 200 steuert, sendet die MCU-1 210 eine Aufforderung an die MCU-2 220, dass sie auf die Steuerung der CAN-Kommunikation des MCU-Systems 200 verzichten soll, wie bei 335 gezeigt ist. Wenn die IMC-Statusinformationen alternativ anzeigen, dass die MCU-1 210 als Quellen-MCU des MCU-Systems 200 ausgestaltet ist, prüft die MCU-1 210, ob gerade CAN-Botschaften durch die MCU-2 220 übertragen werden, wie bei 340 gezeigt ist.
  • Wenn die MCU-2 220 gerade Botschaften überträgt, während die MCU-1 210 als Quellen-MCU eingerichtet ist, wird eine Fehlermeldung erzeugt und gemeldet, wie bei 345 gezeigt ist. Wenn alternativ keine Botschaften von der MCU-2 220 wahrgenommen werden, übernimmt die MCU-1 210 die Steuerung der CAN-Botschaften des MCU-Systems 200 und aktualisiert die IMC-Statusinformationen, um anzuzeigen, dass die Steuerung übernommen wurde, wie bei 350 gezeigt ist.
  • Ferner prüft die MCU-1 210 in dem Fall, dass festgestellt wurde, dass die IMC-Statusinformationen ungültig sind, den CAN-Bus auf Botschaften, die von der MCU-2 220 gesendet wurden, wie bei 325 gezeigt ist. Wenn die MCU-2 220 gerade keinerlei CAN-Botschaften sendet, übernimmt die MCU-1 210 die Steuerung der CAN-Kommunikation und aktualisiert die IMC-Statusinformationen, um anzuzeigen, dass die Steuerung übernommen wurde, wie bei 350 gezeigt ist. Wenn die MCU-2 220 alternativ gerade CAN-Botschaften sendet, sendet die MCU-1 210 eine Aufforderung an die MCU-2 220, auf die Steuerung der CAN-Kommunikation zu verzichten, wie bei 335 gezeigt ist.
  • Nach dem Senden der Aufforderung an die MCU-2 220, auf die Steuerung der CAN-Kommunikation zu verzichten, überwacht die MCU-1 210 den CAN-Bus, um den Status der Botschaften zu prüfen, die gerade von der MCU-2 220 gesendet werden, wie bei 360 gezeigt ist. Die MCU-1 210 prüft, ob die MCU-2 220 nicht auf die Steuerung verzichtet, wenn sie das Senden von CAN-Botschaften innerhalb einer vorbestimmten Zeitüberschreitungszeitspanne seit dem Senden der Anforderung zum Verzichten auf die Steuerung nicht stoppt, wie bei 355 gezeigt ist. Wenn die MCU-2 220 beispielsweise auch nach der Zeitüberschreitungszeitspanne Botschaften sendet, meldet die MCU-1 210 einen Fehler, wie bei 345 gezeigt ist.
  • Wenn die MCU-2 220 alternativ das Senden von CAN-Botschaften innerhalb der Zeitüberschreitungszeitspanne stoppt, stellt die MCU-1 210 sicher, dass die IMC-Statusinformationen anzeigen, dass auf die Steuerung der CAN-Kommunikation verzichtet wurde, wie bei 370 gezeigt ist. Wenn die IMC-Statusinformationen immer noch anzeigen, dass die MCU-2 220 auf die Steuerung der CAN-Kommunikation nicht verzichtet hat, gibt die MCU-1 210 ein Fehlersignal aus, wie bei 345 gezeigt ist. Wenn die Statusinformationen alternativ anzeigen, dass die MCU-2 220 auf die Steuerung der CAN-Kommunikation verzichtet hat, übernimmt die MCU-1 210 die Steuerung der CAN-Botschaften des MCU-Systems 200 und aktualisiert die IMC-Statusinformationen, um anzuzeigen, dass die Steuerung übernommen wurde, wie bei 350 gezeigt ist.
  • 4 veranschaulicht ein Flussdiagramm für ein beispielhaftes Verfahren, bei dem eine Quellen-MCU anfordert, dass eine Reserve-MCU die Steuerung der CAN-Kommunikation übernehmen soll, in Übereinstimmung mit einer oder mehreren Ausführungsformen. Es wird der Fall betrachtet, bei dem in dem MCU-System 200 die MCU-1 210 die Quellen-MCU ist und die MCU-2 220 die Reserve-MCU ist. Die MCU-1 210 überwacht Übertragungsbestätigungen jedes Mal, wenn die MCU-1 210 eine CAN-Botschaft überträgt. Bei einem oder mehreren Beispielen prüft die MCU-1 210, ob für mindestens eine vorbestimmte Anzahl von aufeinander folgenden Übertragungen keine Übertragungsbestätigung empfangen wurde, wie bei 410 gezeigt ist. Wenn die Übertragungsbestätigung empfangen wird, setzt die MCU-1 210 den Betrieb als Quellen-MCU fort.
  • Alternativ fordert in dem Fall, dass die Bestätigung für mindestens die vorbestimmten aufeinanderfolgenden Übertragungen nicht empfangen wurde, die MCU-1 210 die MCU-2 220 über den IMC 230 auf, die Steuerung der CAN-Kommunikationen zu übernehmen, wie bei 420 gezeigt ist. Ferner stoppt die MCU-1 210 die Übertragung von CAN-Botschaften über den CAN-Bus-1 215, wie bei 430 gezeigt ist. Das Stoppen der Übertragung umfasst ferner, dass die CAN-Botschaften von der MCU-1 210 als ausstehend markiert werden, wie bei 440 gezeigt ist.
  • 5 veranschaulicht ein Flussdiagramm für ein beispielhaftes Verfahren zum Anfordern, dass eine Quellen-MCU die Steuerung der CAN-Kommunikation freigeben soll, in Übereinstimmung mit einer oder mehreren Ausführungsformen. Es wird wieder der Fall betrachtet, bei dem in dem MCU-System 200 die MCU-1 210 die Quellen-MCU ist und die MCU-2 220 die Reserve-MCU ist. Die Reserve-MCU, in diesem Fall die MCU-2 220 überwacht die CAN-Kommunikationen, die von der Quellen-MCU gesendet werden, in diesem Fall von der MCU-1 210. Die MCU-2 220 prüft, um festzustellen, ob eine CAN-Botschaft von der Quellen-MCU für eine Zeitspanne über einem vorbestimmten Schwellenwert nicht übertragen wurde, wie bei 510 gezeigt ist. Wenn das Übertragen von Botschaften durch die MCU-1 210 gemäß dem vorbestimmten Schwellenwert arbeitet, fährt die MCU-2 220 mit dem Betrieb als Reserve-MCU fort. Wenn alternativ eine Zeitspanne zwischen zwei aufeinanderfolgenden Übertragungen von der MCU-1 210 über der vorbestimmten Zeitspanne liegt, zum Beispiel 1 Sekunde, 100 Millisekunden oder dergleichen, prüft die MCU-2 220 den IMC-Status an der MCU-1 210 über den IMC 230, wie bei 520 gezeigt ist.
  • Wenn der IMC-Status der MCU-1 210 über den IMC 230 ungültig ist, übernimmt die MCU-2 220 die Steuerung der CAN-Kommunikation, wie bei 530 gezeigt ist. Ferner aktualisiert die MCU-2 220 den IMC-Status, um anzuzeigen, dass die MCU-2 220 nun die Quellen-MCU des MCU-Systems 200 ist. Ferner startet die MCU-2 220 die Übertragung der CAN-Botschaften.
  • Wenn alternativ der IMC-Status der MCU-1 210 gültig ist, prüft die MCU-2 220, ob der IMC-Status eine Anforderung für die MCU-2 220 ist, die Steuerung der CAN-Kommunikation zu übernehmen, wie bei 525 gezeigt ist. Wenn dies zutrifft, übernimmt die MCU-2 220 die Steuerung der CAN-Kommunikation und aktualisiert den IMC-Status entsprechend, wie bei 530 gezeigt ist. Wenn der IMC-Status nicht anfordert, dass die MCU-2 220 die Steuerung der CAN-Kommunikation übernehmen soll, prüft die MCU-2 220, ob eine Anzahl von fehlerhaften Kommunikationen von der MCU-1 210 einen vorbestimmten Schwellenwert überschritten hat, wie bei 540 gezeigt ist. Beispielsweise verfolgt die MCU-2 220 eine Anzahl von Malen, in denen die Kommunikation von der MCU-1 210 die Zeit überschritten hat. Die MCU-2 220 inkrementiert einen Zähler jedes Mal, wenn die Kommunikation von der MCU-1 210 die Zeit überschritten hat.
  • Wenn der Fehlerschwellenwert nicht überschritten worden ist, wiederholt die MCU-2 220 das Verfahren und überwacht erneut eine Zeitüberschreitung der Kommunikation von der MCU-1 210, wie bei 510 gezeigt ist. Wenn der Fehlerschwellenwert stattdessen erreicht oder überschritten wurde, meldet die MCU-2 220 einen Fehler, wie bei 550 gezeigt ist.
  • 3 veranschaulicht ein Flussdiagramm für ein beispielhaftes Verfahren zum Starten einer MCU in einem redundanten MCU-System in Übereinstimmung mit einer oder mehreren Ausführungsformen. Es wird der Fall betrachtet, dass die MCU-1 210 des MCU-Systems 200 startet, wobei die MCU-2 220 als Quellen-MCU des Systems 200 agiert, während die MCU-1 210 neu gestartet wurde. Es sei erwähnt, dass das Verfahren bei anderen Beispielen in analoger Weise anwendbar ist, wenn die MCU-2 220 neu gestartet wird. In diesem Fall setzt die MCU-1 210 alle CAN-Botschaften auf ausstehend für sowohl die MCU-1 210 als auch die MCU-2 220, wie bei 310 gezeigt ist. Die MCU-1 210 prüft ferner, ob über den IMC 230 ein gültiger Status zur Verfügung steht, wie bei 320 gezeigt ist. Wenn der IMC-Status ungültig ist, überwacht die MCU-1 210, ob die MCU-2 220 gerade Botschaften über den CAN-Bus überträgt, wie bei 325 gezeigt ist. Zum Beispiel prüft die MCU-1 210 für eine vorbestimmte Zeitspanne, ob irgendwelche CAN-Botschaften gerade von der MCU-2 220 übertragen werden.
  • Wenn der IMC-Status ungültig ist und die MCU-2 220 gerade keinerlei CAN-Botschaften überträgt, übernimmt die MCU-1 210 die Steuerung der CAN-Kommunikationen des MCU-Systems 200, wie bei 350 gezeigt ist. Beispielsweise konfiguriert sich die MCU-1 210 selbst als die Quellen-MCU und aktualisiert den IMC-Status, um anzuzeigen, dass die MCU-1 210 die Quellen-MCU ist und die MCU-2 220 die Reserve-MCU ist. Ferner umfasst das Übernehmen der Steuerung das Aktualisieren des Status der CAN-Botschaften der MCU-1 210 auf übertragbar, während der Status von CAN-Botschaften bei der MCU-2 220 als ausstehend beibehalten wird.
  • Im Fall, dass der IMC-Status ungültig ist, und wenn die MCU-1 210 detektiert, dass die MCU-2 220 gerade Botschaften über den CAN-Bus sendet, sendet die MCU-1 210 eine Aufforderung an die MCU-2 220 auf die Steuerung zu verzichten, wie bei 335 gezeigt ist. Bei einem oder mehreren Beispielen wird die Aufforderung über den IMC-Kanal 230 gesendet. Nach dem Senden der Aufforderung fährt die MCU-1 210 mit dem Warten für eine vorbestimmte Zeitüberschreitungszeitspanne fort. Während der vorbestimmten Zeitüberschreitungszeitspanne überwacht die MCU-1 210, ob die MCU-2 220 das Senden von CAN-Botschaften gestoppt hat, wie bei 355 und 360 gezeigt ist. Wenn die MCU-2 220 das Senden der CAN-Botschaften stoppt, prüft die MCU-1 210, ob der IMC-Status so gesetzt wurde, dass er anzeigt, dass die Steuerung der Kommunikation von der MCU-2 220 freigegeben wurde, wie bei 370 gezeigt ist. Wenn der IMC-Status anzeigt, dass die Steuerung freigegeben worden ist, übernimmt die MCU-1 210 die Steuerung der CAN-Kommunikation des MCU-Systems 200, wie bei 350 gezeigt ist, und aktualisiert den IMC-Status entsprechend.
  • Wenn die MCU-1 210 feststellt, dass die MCU-2 220 das Senden von Botschaften gestoppt hat, nachdem sie die Aufforderung zum Verzichten auf die Steuerung empfangen hat, dass jedoch der IMC-Status nicht anzeigt, dass die Steuerung freigegeben wurde, meldet die MCU-1 210 einen Fehler, wie bei 345 gezeigt ist. Bei einem oder mehreren Beispielen wird der Fehler gemeldet, indem ein Kommunikationssignal an den zentralen Computer des Fahrzeugs und/oder an andere ECUs in dem Fahrzeug gesendet wird. Alternativ meldet die MCU-1 210 auch einen Fehler in dem Fall, dass die vorbestimmte Zeitüberschreitungszeitspanne abläuft, ohne dass die MCU-2 220 die Übertragung der CAN-Botschaften stoppt, wie bei 355 gezeigt ist.
  • Im Fall, dass der IMC-Status, den die MCU-1 210 beim Starten ermittelt hat, gültig ist, prüft die MCU-1 210 als weitere Alternative, ob der IMC-Status anzeigt, dass die MCU-2 220 als die Quellen-MCU des MCU-Systems 200 agiert, wie bei 330 gezeigt ist. Wenn der IMC-Status anzeigt, dass die MCU-2 220 als die Quellen-MCU des MCU-Systems 200 agiert, sendet die MCU-1 210 die Aufforderung zum Verzichten auf die Steuerung an die MCU-2 220, wie bei 335 gezeigt ist. Bei einem oder mehreren Beispielen wird die Aufforderung über den IMC-Kanal 230 gesendet. Die MCU-1 210 fährt nach dem Senden der Aufforderung fort, eine vorbestimmte Zeitüberschreitungszeitspanne zu warten. Während der vorbestimmten Zeitüberschreitungszeitspanne überwacht die MCU-1 210, ob die MCU-2 220 das Senden von CAN-Botschaften gestoppt hat, wie bei 355 und 360 gezeigt ist. Wenn die MCU-2 220 das Senden der CAN-Botschaften stoppt, prüft die MCU-1 210, ob der IMC-Status so eingestellt wurde, dass er anzeigt, dass die Steuerung der Kommunikation von der MCU-2 220 freigegeben wurde, wie bei 370 gezeigt ist. Wenn der IMC-Status anzeigt, dass die Steuerung freigegeben wurde, übernimmt die MCU-1 210 die Steuerung der CAN-Kommunikation des MCU-Systems 200, wie bei 350 gezeigt ist, und aktualisiert den IMC-Status entsprechend.
  • Wie zuvor im Fall des ungültigen IMC-Status beschrieben wurde, meldet in diesem Fall mit dem gültigen IMC-Status die MCU-1 210 einen Fehler, wie bei 345 gezeigt ist, wenn die MCU-1 210 feststellt, dass die MCU-2 220 das Senden von Botschaften gestoppt hat, nachdem sie die Aufforderung zum Verzichten auf die Steuerung empfangen hat, jedoch der IMC-Status nicht anzeigt, dass die Steuerung freigegeben wurde. In einem oder mehreren Beispielen wird der Fehler gemeldet, indem ein Kommunikationssignal an den zentralen Computer des Fahrzeugs und/oder an andere ECUs in dem Fahrzeug gesendet wird. Alternativ meldet die MCU-1 210 einen Fehler auch in dem Fall, dass die vorbestimmte Zeitüberschreitungszeitspanne abläuft, ohne dass die MCU-2 220 die Übertragung der CAN-Botschaften stoppt, wie bei 355 gezeigt ist.
  • Im Fall, dass der IMC-Status gültig ist, und wenn der IMC-Status nicht anzeigt, dass die MCU-2 220 die Quellen-MCU ist, überwacht die MCU-1 210 alternativ den CAN-Bus, um zu prüfen, ob die MCU-2 220 gerade CAN-Botschaften sendet, wie bei 340 gezeigt ist. Wenn die MCU-1 210 herausfindet, dass die MCU-2 220 gerade keine Botschaften sendet, übernimmt die MCU-1 210 die Steuerung und aktualisiert den IMC-Status, wie bei 350 gezeigt ist. Wenn die MCU-2 220 gerade Botschaften sendet und der IMC-Status anzeigt, dass die MCU-2 220 nicht die Quellen-MCU ist, meldet die MCU-1 210 den Fehler, wie bei 345 gezeigt ist.
  • 4 veranschaulicht ein Flussdiagramm für ein beispielhaftes Verfahren, bei dem eine MCU anfordert, dass eine Reserve-MCU die Steuerung der Kommunikation des MCU-Systems übernehmen soll, in Übereinstimmung mit einer oder mehreren Ausführungsformen. Zugunsten dieses Beispiels wird der Fall betrachtet, dass die MCU-1 210 die Quellen-MCU ist, welche die MCU-2 220 als Reserve-MCU auffordert, die Steuerung zu übernehmen. Es sei erwähnt, dass in anderen Beispielen die MCU-2 220 das Verfahren auf analoge Weise implementiert.
  • Die MCU-1 210 überwacht Übertragungsbestätigungsbotschaften, die in Ansprechen auf Übertragungen von CAN-Botschaften durch die MCU-1 210 empfangen werden, wie bei 410 gezeigt ist. Wenn die MCU-1 210 für eine vorbestimmte Anzahl von Malen, etwa n, keine Übertragungsbestätigung empfängt, nimmt die MCU-1 210 an, dass die CAN-Übertragung gerade einen Fehler/eine Störung aufweist. Bei einem oder mehreren Beispielen sind die vorbestimmten Male n aufeinanderfolgende Male. Wenn die MCU-1 210 nicht mindestens die vorbestimmte Anzahl von Übertragungsfehlern detektiert, fährt die MCU-1 210 mit dem Betrieb als die Quellen-MCU fort, wie bei 415 gezeigt ist.
  • Wenn die fehlerhaften Übertragungsbestätigungen für mindestens die vorbestimmte Anzahl von Malen detektiert werden, sendet die MCU-1 210 eine Aufforderung an die MCU-2 220 zum Übernehmen der Kommunikationssteuerung, wie bei 420 gezeigt ist. Bei einem oder mehreren Beispielen wird die Aufforderung über den IMC-Kanal 230 gesendet. Die MCU-1 210 stoppt ferner die Übertragung der CAN-Botschaften selbst, wie bei 430 gezeigt ist. Ferner setzt die MCU-1 210 alle Botschaften auf ausstehend, um die Übertragungen durch die MCU-2 220 zu überwachen, wie bei 440 gezeigt ist.
  • 5 veranschaulicht ein Flussdiagramm eines beispielhaften Verfahrens zum Auffordern, dass eine Quellen-MCU die Steuerung freigibt/darauf verzichtet, in Übereinstimmung mit einer oder mehreren Ausführungsformen. Es wird der Fall betrachtet, dass die MCU-1 210 als Quellen-MCU agiert und die Reserve-MCU, die MCU-2 220, die Aufforderung sendet. In anderen Beispielen kann die MCU-1 210 die Aufforderung auf analoge Weise senden. Die MCU-2 220 überwacht die Übertragungen durch die MCU-1 210, um sicherzustellen, dass das Übertragen funktioniert. Wenn die MCU-2 220 detektiert, dass für mindestens eine vorbestimmte Zeitdauer keine CAN-Botschaft von der MCU-1 210 gesendet wurde, stellt die MCU-2 220 fest, dass die MCU-1 210 möglicherweise einen Fehler aufweist, wie bei 510 gezeigt ist. Wenn keine derartige Bedingung detektiert wird, fährt die MCU-2 220 fort, als Reserve-MCU zu arbeiten und die Übertragung von der MCU-1 210 zu überwachen.
  • Wenn die Bedingung detektiert wird, prüft die MCU-2 220 den Status des MCU-Systems 200 auf dem IMC-Kanal 230, um zu prüfen, ob die MCU-1 210 einen Fehler angezeigt hat, wie bei 520 gezeigt ist. Wenn der Status ungültig ist, übernimmt die MCU-2 220 die Steuerung der CAN-Kommunikationen des MCU-Systems 200, wie bei 530 gezeigt ist. Wenn der IMC-Status alternativ gültig ist, prüft die MCU-2 220, was der IMC-Status anzeigt, wie bei 525 gezeigt ist. Wenn der IMC-Status anzeigt, dass die MCU-1 210 der MCU-2 220 anzeigt, dass sie die Steuerung übernehmen soll, übernimmt die MCU-2 220 die Steuerung der CAN-Kommunikation, wie bei 530 gezeigt ist. Bei einem oder mehreren Beispielen umfasst das Übernehmen der Steuerung das Aktualisieren des IMC-Status, um anzuzeigen, dass die MCU-2 220 die Quellen-MCU des MCU-Systems 200 ist. Ferner umfasst bei einem oder mehreren Beispielen das Übernehmen der Steuerung, dass das Übertragen der CAN-Botschaften eingeleitet wird und die CAN-Botschaften von der MCU-1 210 auf ausstehend und von der MCU-2 220 auf übertragbar gesetzt werden.
  • Wenn der IMC-Status alternativ keine Aufforderung dafür anzeigt, dass die MCU-2 220 die Steuerung übernehmen soll, inkrementiert die MCU-2 220 einen Fehlerzähler. Die MCU-2 220 führt den Fehlerzähler mit, um eine Anzahl von Malen zu überwachen, die die MCU-2 220 darauf wartet, dass die MCU-1 210 Botschaften über den CAN-Bus kommuniziert. Beispielsweise ermöglicht das Warten für eine vorbestimmte Anzahl von Malen, dass die MCU-2 220 das Übernehmen der Steuerung der CAN-Kommunikationen in dem Fall vermeidet, bei dem die MCU-1 210 neu gestartet wird oder durch eine anwendungsspezifische Verzögerung verzögert worden ist. Bis der Fehlerzähler den vorbestimmten Schwellenwert erreicht, fährt die MCU-2 220 mit dem Überwachen der Zeitüberschreitungen der MCU-1 210 fort. Wenn der Fehlerzähler den vorbestimmten Schwellenwert überschreitet, meldet die MCU-2 220 den Fehler, wie bei 550 gezeigt ist.
  • 6 veranschaulicht ein Flussdiagramm für ein beispielhaftes Verfahren zum Behandeln eines Busunterbrechungsszenarios durch eine Quellen-MCU eines redundanten MCU-Systems in Übereinstimmung mit einer oder mehreren Ausführungsformen. Wenn die MCU-1 210 die Quellen-MCU ist, überwacht die MCU-1 210, ob ein Busunterbrechungsereignis auftritt, wie bei 610 gezeigt ist. Das Busunterbrechungsereignis zeigt einen Fehler im CAN-Bus, in diesem Fall im Bus-1 215 an. Zum Beispiel kann das Busunterbrechungsereignis auftreten, wenn der CAN-Bus-1 215 einen Fehler aufweist, etwa eine Bruchstelle. In Ansprechen auf das Busunterbrechungsereignis sendet die MCU-1 210 eine Aufforderung an die Reserve-MCU, sagen wir die MCU-2 220, dass sie die Steuerung der CAN-Kommunikationen übernehmen soll, wie bei 620 gezeigt ist. Die MCU-1 210 sendet die Aufforderung über den IMC-Kanal 230. Beispielsweise wird die Aufforderung gesendet, indem der IMC-Status geändert wird, um anzufordern, dass die MCU-2 220 die Quellen-MCU wird. Ferner stoppt die MCU-1 210 das Senden der CAN-Übertragungen und setzt Botschaften auf ausstehend, wie bei 630 und 640 gezeigt ist. Bei einem oder mehreren Beispielen überwacht die MCU-1 210 den CAN-Bus und den IMC-Kanal 230, um sicherzustellen, dass die MCU-2 220 die Steuerung übernimmt. Im Fall, dass die MCU-2 220 die Steuerung nicht übernimmt und nicht mit dem Übertragen von Botschaften beginnt, meldet die MCU-1 210 einen Fehler. Es sei angemerkt, dass das vorstehende Beispiel zwar so beschrieben ist, dass es durch die MCU-1 210 implementiert wird, in anderen Beispielen jedoch die MCU-2 220 das Verfahren implementieren kann.
  • 7 veranschaulicht ein Flussdiagramm für ein beispielhaftes Verfahren für ein Busunterbrechungsbehebungsereignis in Übereinstimmung mit einer oder mehreren Ausführungsformen. Ein Busunterbrechungsbehebungsereignis tritt auf, wenn eine MCU einen Fehler/Ausfall des CAN-Busses behebt. Das folgende Beispiel ist so dargestellt, dass die MCU-1 210 das Verfahren implementiert, jedoch kann in anderen Beispielen die MCU-2 220 das Verfahren implementieren. Die MCU-1 210 überwacht den CAN-Bus-1 215, um zu ermitteln, ob ein Fehler behoben wurde. Im Fall, dass ein Busunterbrechungsbehebungsereignis identifiziert wird, sendet die MCU-1 210 eine Aufforderung an die MCU-2 220, die Steuerung der Kommunikation nicht zu übernehmen, wie bei 710 und 720 gezeigt ist. Die MCU-1 210 überwacht den CAN-Bus für eine vorbestimmte Zeitüberschreitungszeitspanne nach dem Senden der Aufforderung. um zu prüfen, ob die MCU-2 220 gerade CAN-Botschaften sendet, wie bei 730 und 740 gezeigt ist. Die MCU-1 210 setzt das Warten für mindestens die vorbestimmte Zeitüberschreitungszeitspanne in dem Fall fort, dass CAN-Botschaften von der MCU-2 220 detektiert werden, wie bei 730 und 740 gezeigt ist. Wenn die MCU-2 220 auch nach der Zeitüberschreitungszeitspanne CAN-Botschaften sendet, meldet die MCU-1 210 einen Fehler, wie bei 770 gezeigt ist.
  • Wenn die MCU-2 220 das Senden von CAN-Botschaften innerhalb der vorbestimmten Zeitüberschreitungszeitspanne seit Empfang der Aufforderung von der MCU-1 210 stoppt, prüft die MCU-1 210 den IMC-Status, wie bei 750 gezeigt ist. Wenn der IMC-Status anzeigt, dass die MCU-2 220 die Steuerung der CAN-Kommunikationen noch nicht freigegeben hat, meldet die MCU-1 210 den Fehler, wie bei 770 gezeigt ist. Wenn die MCU-2 220 die Steuerung freigegeben hat, übernimmt die MCU-1 210 die Steuerung der CAN-Kommunikation und aktualisiert den IMC-Status, um anzuzeigen, dass sie die Quellen-MCU ist, wie bei 760 gezeigt ist.
  • 8 stellt eine beispielhafte Datenstruktur 800 für IMC-Statusinformationen in Übereinstimmung mit einer oder mehreren Ausführungsformen dar. Bei einem oder mehreren Beispielen enthält die Datenstruktur 800 für den IMC-Status ein Feld zum Anzeigen, dass die Quellen-MCU die Steuerung des CAN-Busses-1 210 innehat. Die Datenstruktur 800 für den IMC-Status enthält ferner ein Feld zum Anzeigen, ob die Quellen-MCU die Steuerung des CAN-Busses-2 225 innehat. Die Datenstruktur 800 für den IMC-Status enthält ferner ein Feld, das anzeigt, ob die Reserve-MCU die Steuerung des CAN-Busses-1 215 innehat. Die Datenstruktur 800 für den IMC-Status enthält ferner ein Feld, das anzeigt, ob die Reserve-MCU die Steuerung des CAN-Busses-2 225 innehat.
  • Die Datenstruktur 800 für den IMC-Status enthält ferner ein Feld, das anzeigt, ob die Reserve-MCU gerade die Steuerung des CAN-Busses-1 215 anfordert. Die Datenstruktur 800 für den IMC-Status enthält ferner ein Feld, das anzeigt, ob die Reserve-MCU gerade die Steuerung des CAN-Busses-2 225 anfordert.
  • Die Datenstruktur 800 für den IMC-Status enthält ferner ein Feld, das anzeigt, dass die Quellen-MCU die Steuerung des CAN-Busses-1 210 ablehnt. Die Datenstruktur 800 für den IMC-Status enthält ferner ein Feld, das anzeigt, dass die Quellen-MCU die Steuerung des CAN-Busses-2 225 ablehnt.
  • Die Datenstruktur 800 für den IMC-Status enthält ferner ein Feld, das anzeigt, dass die Quellen-MCU gerade anfordert, dass die Reserve-MCU die Steuerung des CAN-Busses-1 215 übernehmen soll. Die Datenstruktur 800 für den IMC-Status enthält ferner ein Feld, das anzeigt, dass die Quellen-MCU gerade anfordert, dass die Reserve-MCU die Steuerung des CAN-Busses-2 225 übernehmen soll.
  • Die beispielhafte Datenstruktur 800 für den IMC-Status verwendet ein Bit für jedes Feld. Beispielsweise enthält die Datenstruktur 800 für den IMC-Status 10 Bits. Es sei jedoch angemerkt, dass in anderen Beispielen ein Feld der Datenstruktur 800 für den IMC-Status zusätzliche Bits, etwa ein Byte, ein Paar Bits oder eine beliebige andere Anzahl von Bits enthält. Obwohl die beispielhafte Datenstruktur spezielle Feldpositionen anzeigt, sei angemerkt, dass in anderen Beispielen sich die Feldpositionen, die verwendet werden, von denjenigen, die dargestellt sind, unterscheiden. In anderen Beispielen kann die Datenstruktur zusätzliche Felder zu den hier dargestellten enthalten.
  • Durch Implementieren der hier beschriebenen technischen Lösungen stellt ein redundantes MCU-System, etwa in einem Fahrzeug, eine robuste, effiziente und konsistente Detektion eines CAN-Fehlers bereit; eine reibungslose und schnelle Übernahme der Steuerung der CAN-Kommunikation durch eine Reserve-MCU in Ansprechen auf eine Fehlerbedingung einer Quellen-MCU; und eine reibungslose Rückgabe der Steuerung der CAN-Kommunikation an die Quellen-MCU nach einer Fehlerbehebung. In einem oder mehreren Beispielen wird das redundante MCU-System als Steuerungsmodul eines Servolenkungssystems oder eines beliebigen anderen Fahrzeugteilsystems verwendet. Obwohl die hier beschriebenen Ausführungsformen ein redundantes MCU-System in einem Lenkungssystem als beispielhafte Implementierungen verwendet, versteht es sich, dass das redundante MCU-System eine beliebige redundante Prozessorarchitektur sein kann, die eine Verarbeitungseinheit mit zwei oder mehr Prozessoren enthält, wobei ein erster Prozessor als ein primärer Prozessor verwendet wird und der andere Prozessor als Reserveprozessor verwendet wird, der im Fall eines Fehlers bei dem ersten Prozessor die Steuerung als primärer Prozessor übernimmt.
  • Die vorliegenden technischen Lösungen können ein System, ein Verfahren und/oder ein Computerprogrammprodukt auf einer beliebigen möglichen technischen Detailebene der Integration sein. Das Computerprogrammprodukt kann ein oder mehrere computerlesbare Speichermedien enthalten, die darin computerlesbare Programmanweisungen enthalten, um zu bewirken, dass ein Prozessor Aspekte der vorliegenden technischen Lösungen ausführt.
  • Das computerlesbare Speichermedium kann eine konkrete Vorrichtung sein, die Anweisungen zur Verwendung durch eine Anweisungsausführungsvorrichtung speichern und festhalten kann. Das computerlesbare Speichermedium kann beispielsweise eine elektronische Speichervorrichtung, eine magnetische Speichervorrichtung, eine optische Speichervorrichtung, eine elektromagnetische Speichervorrichtung, eine Halbleiterspeichervorrichtung oder eine beliebige geeignete Kombination aus den vorstehenden sein, ist aber nicht darauf beschränkt. Eine nicht umfassende Liste von spezielleren Beispielen für das computerlesbare Speichermedium umfasst die folgenden: eine tragbare Computerdiskette, eine Festplatte, einen Speicher mit wahlfreiem Zugriff (RAM), einen Festwertspeicher (ROM), einen löschbaren, programmierbaren Festwertspeicher (EPROM oder Flash-Speicher), einen statischen Speicher mit wahlfreiem Zugriff (SRAM), einen tragbaren Kompaktdisk-Festwertspeicher (CD-ROM), eine digitale versatile Disk (DVD), einen Speicherstick, eine Diskette, eine mechanisch kodierte Vorrichtung wie etwa Lochkarten oder erhöhte Strukturen in einer Rille mit darin aufgezeichneten Anweisungen, und eine beliebige geeignete Kombination der Vorstehenden. Ein computerlesbares Speichermedium darf, so wie der Begriff hier verwendet wird, nicht so aufgefasst werden, dass es vorübergehende Signale per se sind, etwa Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder andere Übertragungsmedien ausbreiten (z. B. Lichtimpulse, die durch ein Glasfaserkabel hindurchlaufen), oder elektrische Signale, die durch einen Draht übertragen werden.
  • Hier beschriebene computerlesbare Programmanweisungen können an jeweilige Berechnungs-/Verarbeitungsvorrichtungen von einem computerlesbaren Speichermedium heruntergeladen werden, oder über ein Netzwerk an einen externen Computer oder eine externe Speichervorrichtung, zum Beispiel über das Internet, ein lokales Netzwerk, ein Weitbereichsnetzwerk und/oder ein drahtloses Netzwerk. Das Netzwerk kann Kupferübertragungskabel, optische Übertragungsfasern, drahtlose Übertragung, Routers, Firewalls, Switches, Gateway-Computer und/oder Edge-Server umfassen. Eine Netzwerkadapterkarte oder eine Netzwerkschnittstelle in jeder Berechnungs-/Verarbeitungsvorrichtung empfängt computerlesbare Programmanweisungen von dem Netzwerk und leitet die computerlesbaren Programmanweisungen zur Speicherung in einem computerlesbaren Speichermedium innerhalb der jeweiligen Berechnungs-/Verarbeitungsvorrichtung weiter.
  • Computerlesbare Programmanweisungen zum Ausführen von Operationen der vorliegenden technischen Lösungen können Assembleranweisungen, Anweisungen einer Instruction-Set-Architektur (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmwareanweisungen, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen oder entweder Sourcecode oder Objectcode sein, der in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben ist, einschließlich einer objektorientierten Programmiersprache wie etwa Smalltalk, C++ oder dergleichen, und prozeduraler Programmiersprachen, etwa der ”C”-Programmiersprache oder ähnliche Programmiersprachen. Die computerlesbaren Programmanweisungen können vollständig auf dem Computer des Nutzers ausgeführt werden, teilweise auf dem Computer des Nutzers, als eigenständiges Softwarepaket, teilweise auf dem Computer des Nutzers und teilweise auf einem entfernten Computer oder vollständig auf dem entfernten Computer oder Server. Im letzteren Szenario kann der entfernte Computer mit dem Computer des Nutzers durch eine beliebige Art von Netzwerk verbunden sein, einschließlich eines lokalen Netzwerks (LAN) oder eines Weitbereichs-Netzwerks (WAN) oder die Verbindung kann zu einem externen Computer hergestellt werden (zum Beispiel durch das Internet unter Verwendung eines Internetserviceproviders). In einigen Ausführungsformen können elektronische Schaltungen, die beispielsweise Schaltungen mit programmierbarer Logik, im Feld programmierbare Gatearrays (FPGA) oder programmierbare Logikgatter (PLA) umfassen, die computerlesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der computerlesbaren Programmanweisungen verwenden, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden technischen Lösungen auszuführen.
  • Aspekte der vorliegenden technischen Lösungen sind hier mit Bezug auf Flussdiagrammveranschaulichungen und/oder Blockdiagramme von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten in Übereinstimmung mit Ausführungsformen der technischen Lösungen beschrieben. Es versteht sich, dass jeder Block der Flussdiagrammveranschaulichungen und/oder der Blockdiagramme und Kombinationen aus Blöcken in den Flussdiagrammveranschaulichungen und/oder Blockdiagrammen durch computerlesbare Programmanweisungen implementiert werden können.
  • Diese computerlesbaren Programmanweisungen können für einen Prozessor eines Universalcomputers, eines spezialisierten Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, sodass die Anweisungen, welche über den Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, Mittel zum Implementieren der Funktionen/Handlungen schaffen, die in dem oder den Blöcken der Flussdiagramme und/oder Blockdiagramme beschrieben sind. Diese computerlesbaren Programmanweisungen können auch in einem computerlesbaren Speichermedium gespeichert werden, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Vorrichtungen so lenken kann, dass sie auf eine spezielle Weise funktionieren, sodass das computerlesbare Speichermedium, das darin gespeicherte Anweisungen aufweist, einen Produktionsartikel umfasst, der Anweisungen enthält, welche Aspekte der Funktionen/Handlungen implementiert, die in dem oder den Blöcken der Flussdiagramme und/oder Blockdiagramme beschrieben sind.
  • Die computerlesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Vorrichtung geladen werden, um zu veranlassen, dass eine Folge von Betriebsschritten auf dem Computer, auf der anderen programmierbaren Vorrichtung oder auf der anderen Vorrichtung ausgeführt wird, um einen durch einen Computer implementierten Prozess zu erzeugen, sodass die Anweisungen, welche auf dem Computer, auf der anderen programmierbaren Vorrichtung oder auf der anderen Vorrichtung ausgeführt werden, die Funktionen/Handlungen implementieren, die in dem oder den Blöcken der Flussdiagramme und/oder Blockdiagramme beschrieben sind.
  • Die Flussdiagramme und Blockdiagramme in den Figuren veranschaulichen die Architektur, die Funktionalität und die Arbeitsweise von möglichen Implementierungen von Systemen, Verfahren und Computerprogrammprodukten in Übereinstimmung mit verschiedenen Ausführungsformen der vorliegenden technischen Lösungen. In dieser Hinsicht kann jeder Block in den Flussdiagrammen oder Blockdiagrammen ein Modul, ein Segment oder einen Abschnitt von Anweisungen repräsentieren, das/der eine oder mehrere ausführbare Anweisungen umfasst, um die beschriebenen logischen Funktionen zu implementieren. In einigen alternativen Implementierungen können die in den Blöcken erwähnten Funktionen in einer anderen Reihenfolge als in den Figuren beschrieben auftreten. Beispielsweise können zwei aufeinanderfolgend gezeigte Blöcke tatsächlich im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal in Abhängigkeit von der betroffenen Funktionalität in der umgekehrten Reihenfolge ausgeführt werden. Es sei auch erwähnt, dass jeder Block der Blockdiagramme und/oder der Flussdiagrammveranschaulichung und Kombinationen von Blöcken in den Blockdiagrammen und/oder Flussdiagrammveranschaulichungen durch auf spezieller Hardware basierte Systeme implementiert werden können, welche die beschriebenen Funktionen oder Handlungen ausführen oder Kombinationen aus Spezialhardware und Computeranweisungen ausführen.
  • Man kann sagen, dass eine zweite Aktion ”in Ansprechen auf” eine erste Aktion unabhängig davon erfolgt, ob die zweite Aktion direkt oder indirekt aus der ersten Aktion resultiert. Die zweite Aktion kann zu einem wesentlich späteren Zeitpunkt als die erste Aktion stattfinden und dennoch in Ansprechen auf die erste Aktion erfolgen. Analog kann man sagen, dass die zweite Aktion in Ansprechen auf die erste Aktion erfolgt, selbst wenn zwischen der ersten Aktion und der zweiten Aktion dazwischenliegende Aktionen stattfinden, oder sogar, wenn eine oder mehrere der dazwischenliegenden Aktionen direkt veranlassen, dass die zweite Aktion ausgeführt wird. Beispielsweise kann eine zweite Aktion in Ansprechen auf eine erste Aktion erfolgen, wenn die erste Aktion einen Merker setzt und eine dritte Aktion später die zweite Aktion immer dann einleitet, wenn der Merker gesetzt ist.
  • Zur Klärung der Verwendung der Ausdrücke ”mindestens einer von <A>, <B>, ... und <N>” oder ”mindestens einer von <A>, <B>, ... <N> oder Kombinationen daraus” oder ”<A>, <B>, ... und/oder <N>” und um hiermit die Öffentlichkeit zu informieren sind diese im breitest möglichen Sinn aufzufassen, wodurch beliebige andere hier im Vorstehenden oder hier im Nachstehenden implizierte Definitionen überschrieben werden, sofern nicht ausdrücklich das Gegenteil beschrieben wird, und sie bedeuten, dass ein oder mehrere Elemente aus der Gruppe gewählt werden, die A, B ... und N umfasst. Mit anderen Worten bedeuten die Ausdrücke eine beliebige Kombination aus einem oder mehreren der Elemente A, B, ... oder N einschließlich ein beliebiges Element alleine oder das eine Element in Kombination mit einem oder mehreren der anderen Elemente, welche außerdem in Kombination zusätzliche nicht aufgeführte Elemente umfassen können.
  • Es ist außerdem festzustellen, dass beliebige Module, Einheiten, Komponenten, Server, Computer, Endgeräte oder Vorrichtungen, die hier als Beispiele beschrieben sind und Anweisungen ausführen, computerlesbare Medien enthalten oder anderweitig darauf Zugriff haben können, etwa Speichermedien, Computerspeichermedien oder Datenspeichervorrichtungen (entfernbare und/oder nicht entfernbare), wie zum Beispiel magnetische Scheiben, optische Scheiben oder Bänder. Computerspeichermedien können flüchtige und nicht flüchtige, entfernbare und nicht entfernbare Medien enthalten, die in einem beliebigen Verfahren oder einer beliebigen Technologie zum Speichern von Informationen implementiert sind, etwa von computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen oder anderen Daten. Derartige Computerspeichermedien können Teil der Vorrichtung sein oder für diese zugänglich oder mit dieser verbindbar sein. Beliebige hier beschriebene Anwendungen oder Module können unter Verwendung von computerlesbaren/ausführbaren Anweisungen implementiert werden, die durch diese computerlesbaren Medien gespeichert oder anderweitig vorgehalten werden können.
  • Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden technischen Lösungen wurden zu Veranschaulichungszwecken präsentiert, sollen aber nicht umfassend sein oder auf die offenbarten Ausführungsformen beschränkt sein. Für den Fachmann auf dem Gebiet werden viele Modifikationen und Variationen offensichtlich sein, ohne den Umfang und den Geist der beschriebenen Ausführungsformen zu verlassen. Die hier verwendete Terminologie wurde gewählt, um die Prinzipien der Ausführungsformen, die praktische Anwendung oder die technische Verbesserung gegenüber Technologien auf dem Markt bestmöglich zu erläutern oder um zu ermöglichen, dass andere die hier offenbarten Ausführungsformen verstehen.

Claims (15)

  1. Verarbeitungseinheit zum Bereitstellen eines redundanten Prozessors, wobei die Verarbeitungseinheit umfasst: einen Quellenprozessor, der mit einem Systemkommunikationsbus über eine erste Kommunikationsleitung gekoppelt ist; einen Reserveprozessor, der mit dem Systemkommunikationsbus über eine zweite Kommunikationsleitung gekoppelt ist: und einen Kommunikationskanal zwischen Mikroprozessoren zur Kommunikation zwischen dem Quellenprozessor und dem Reserveprozessor; wobei der Reserveprozessor ausgestaltet ist, um: den Quellenprozessor auf einen Fehler hin zu überwachen, indem er die erste Kommunikationsleitung auf Kommunikationsbotschaften überwacht, die von dem Quellenprozessor übertragen werden; einen Fehler des Quellenprozessors in Ansprechen darauf festzustellen, dass die Kommunikationsbotschaften auf der ersten Kommunikationsleitung für eine vorbestimmte Zeitdauer fehlen; und in Ansprechen auf einen Fehler des Quellenprozessors die Steuerung der Kommunikation der Verarbeitungseinheit zu übernehmen, indem er eine Statusaktualisierung an den Kommunikationskanal zwischen Mikroprozessoren sendet.
  2. Verarbeitungseinheit nach Anspruch 1, wobei das Überwachen des Quellenprozessors auf den Fehler hin ferner umfasst, dass der Kommunikationskanal zwischen Mikroprozessoren auf eine Statusaktualisierung von dem Quellenprozessor hin überwacht wird, die einen Fehler anzeigt.
  3. Verarbeitungseinheit nach Anspruch 1, wobei die Statusaktualisierung anzeigt, dass der Reserveprozessor die Steuerung der Kommunikation für die Verarbeitungseinheit übernommen hat.
  4. Verarbeitungseinheit nach Anspruch 1, wobei der Reserveprozessor ferner ausgestaltet ist, um eine Fehlerbehebung durch den Quellenprozessor zu überwachen und um in Ansprechen darauf auf die Steuerung der Kommunikation der Verarbeitungseinheit zu verzichten.
  5. Verarbeitungseinheit nach Anspruch 4, wobei der Reserveprozessor die Fehlerbehebung des Quellenprozessors überwacht, indem er eine Aufforderung zum Verzichten auf die Steuerung über den Kommunikationskanal zwischen Mikroprozessoren überwacht.
  6. Verarbeitungseinheit nach Anspruch 4, wobei der Reserveprozessor ausgestaltet ist, um auf die Steuerung der Kommunikation für die Verarbeitungseinheit zu verzichten, indem er eine Statusaktualisierung über den Kommunikationskanal zwischen Mikroprozessoren sendet, wobei die Statusaktualisierung anzeigt, dass der Reserveprozessor die Kommunikation nicht mehr steuert.
  7. Verarbeitungseinheit nach Anspruch 1, wobei der Quellenprozessor ausgestaltet ist, um in Ansprechen auf einen Neustart: zu prüfen, ob der Reserveprozessor die Steuerung der Kommunikation der Verarbeitungseinheit innehat; in Ansprechen darauf, dass der Reserveprozessor die Kommunikation gerade steuert, eine Aufforderung an den Reserveprozessor zu senden, dass er auf die Steuerung der Kommunikation verzichten soll; und in Ansprechen darauf, dass der Reserveprozessor auf die Steuerung der Kommunikation verzichtet, die Steuerung der Kommunikation zu übernehmen.
  8. Verarbeitungseinheit nach Anspruch 7, wobei der Quellenprozessor ferner ausgestaltet ist, um nach dem Senden der Aufforderung an den Reserveprozessor zum Verzichten auf die Steuerung der Kommunikation eine vorbestimmte Zeitspanne lang zu warten.
  9. Verarbeitungseinheit nach Anspruch 7, wobei das Prüfen, ob der Reserveprozessor die Steuerung der Kommunikation innehat, umfasst, dass der Status von dem Kommunikationskanal zwischen Mikroprozessoren geprüft wird.
  10. Verfahren für eine ununterbrochene Datenkommunikation von einem Verarbeitungssystem, wobei das Verfahren umfasst, dass: ein erster Prozessor von einem zweiten Prozessor auf einen Fehler hin überwacht wird, indem eine erste Kommunikationsleitung überwacht wird, die dem ersten Prozessor zugeordnet ist, um Botschaften zu kommunizieren, die von dem ersten Prozessor übertragen werden; von dem zweiten Prozessor der Fehler des ersten Prozessors in Ansprechen darauf festgestellt wird, dass die Kommunikationsbotschaften auf der ersten Kommunikationsleitung eine vorbestimmte Zeitdauer lang fehlen; und in Ansprechen auf den Fehler des ersten Prozessors von dem zweiten Prozessor die Steuerung der Kommunikation des Verarbeitungssystems übernommen wird, indem eine Statusaktualisierung an einen Kommunikationskanal zwischen Mikroprozessoren zwischen dem ersten Prozessor und dem zweiten Prozessor gesendet wird.
  11. Verfahren nach Anspruch 10, wobei das Überwachen des ersten Prozessors auf den Fehler hin ferner umfasst, dass der Kommunikationskanal zwischen Mikroprozessoren von dem zweiten Prozessor auf eine Statusaktualisierung von dem ersten Prozessor hin überwacht wird, die einen Fehler anzeigt.
  12. Verfahren nach Anspruch 10, wobei die Statusaktualisierung anzeigt, dass der zweite Prozessor die Steuerung der Kommunikation für das Verarbeitungssystem übernommen hat.
  13. Verfahren nach Anspruch 10, das ferner umfasst, dass von dem zweiten Prozessor eine Fehlerbehebung des ersten Prozessors überwacht wird und in Ansprechen auf die Fehlerbehebung auf die Steuerung der Kommunikation des Verarbeitungssystems verzichtet wird.
  14. Verfahren nach Anspruch 13, wobei das Überwachen der Fehlerbehebung des ersten Prozessors umfasst, dass: von dem zweiten Prozessor eine Aufforderung von dem ersten Prozessor zum Verzichten auf die Steuerung überwacht wird, wobei die Aufforderung über den Kommunikationskanal zwischen Mikroprozessoren empfangen wird; und/oder von dem zweiten Prozessor eine Statusaktualisierung über den Kommunikationskanal zwischen Mikroprozessoren gesendet wird, wobei die Statusaktualisierung anzeigt, dass der zweite Prozessor die Kommunikation nicht mehr steuert.
  15. Verfahren nach Anspruch 10, das ferner umfasst, dass in Ansprechen auf die Behebung des Fehlers von dem ersten Prozessor ein Neustart ausgeführt wird, wobei das Neustarten umfasst, dass: von dem ersten Prozessor geprüft wird, ob der zweite Prozessor die Steuerung der Kommunikation des Verarbeitungssystems innehat; in Ansprechen darauf, dass der zweite Prozessor die Kommunikation gerade steuert, von dem ersten Prozessor eine Aufforderung an den zweiten Prozessor zum Verzichten auf die Steuerung der Kommunikation gesendet wird; und in Ansprechen darauf, dass der zweite Prozessor auf die Steuerung der Kommunikation verzichtet, von dem ersten Prozessor die Steuerung der Kommunikation übernommen wird.
DE102017116883.4A 2016-07-28 2017-07-26 Ununterbrochene Verfügbarkeit von Daten während eines Fehlers in einem redundanten Mikrocontrollersystem Pending DE102017116883A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662367791P 2016-07-28 2016-07-28
US62/367,791 2016-07-28

Publications (1)

Publication Number Publication Date
DE102017116883A1 true DE102017116883A1 (de) 2018-02-01

Family

ID=60951007

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102017116883.4A Pending DE102017116883A1 (de) 2016-07-28 2017-07-26 Ununterbrochene Verfügbarkeit von Daten während eines Fehlers in einem redundanten Mikrocontrollersystem

Country Status (3)

Country Link
US (1) US10521313B2 (de)
CN (1) CN107666423B (de)
DE (1) DE102017116883A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3626543A1 (de) 2018-09-18 2020-03-25 KNORR-BREMSE Systeme für Nutzfahrzeuge GmbH Schutzschaltung und verfahren zum schutz einer kraftfahrzeugstromversorgung

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111324494B (zh) * 2018-12-13 2023-08-25 中兴通讯股份有限公司 处理器控制方法、装置和存储介质
DE102019104948A1 (de) * 2019-02-27 2020-08-27 Zf Active Safety Gmbh Kommunikationssystem und Verfahren zur Kommunikation für ein Kraftfahrzeug
EP3726384B1 (de) * 2019-04-18 2022-01-05 Bayerische Motoren Werke Aktiengesellschaft Verfahren und system zur aufrechterhaltung der konsistenz von zuständen während einer ausfallbetriebssichere kontextumschaltung
DE102020118563A1 (de) * 2019-07-17 2021-01-21 Steering Solutions Ip Holding Corporation Middleware-system und -verfahren
EP3779699A1 (de) * 2019-08-16 2021-02-17 Aptiv Technologies Limited Verfahren zur kontrolle der programmausführung eines mikrosteuergeräts, externe vorrichtung, system und nichttransitorisches computerlesbares medium
CN113595753A (zh) * 2020-04-30 2021-11-02 北京达佳互联信息技术有限公司 通信方法及装置

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4455601A (en) * 1981-12-31 1984-06-19 International Business Machines Corporation Cross checking among service processors in a multiprocessor system
US5957985A (en) * 1996-12-16 1999-09-28 Microsoft Corporation Fault-resilient automobile control system
US6351829B1 (en) * 1998-10-28 2002-02-26 Honeywell Inc System and method for distinguishing a device failure from an inter-device communication failure
CN100407727C (zh) * 2004-01-18 2008-07-30 中兴通讯股份有限公司 一种基于消息的处理器间通信方法
US7734948B2 (en) * 2007-08-21 2010-06-08 International Business Machines Corporation Recovery of a redundant node controller in a computer system
JP5527270B2 (ja) * 2011-04-12 2014-06-18 株式会社デンソー 車載用電子制御装置
EP2525292A1 (de) * 2011-05-20 2012-11-21 ABB Technology AG System und Verfahren zur Verwendung von Redundanz eines Steuerungsvorgangs
CN104094577B (zh) * 2012-08-13 2017-07-04 统一有限责任两合公司 用于间接地评定活动实体的状态的方法和装置
DE102013201702C5 (de) * 2013-02-01 2017-03-23 Mtu Friedrichshafen Gmbh Verfahren und Anordnung zur Steuerung einer Brennkraftmaschine

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3626543A1 (de) 2018-09-18 2020-03-25 KNORR-BREMSE Systeme für Nutzfahrzeuge GmbH Schutzschaltung und verfahren zum schutz einer kraftfahrzeugstromversorgung
WO2020057988A1 (en) 2018-09-18 2020-03-26 Knorr-Bremse Systeme für Nutzfahrzeuge GmbH A protection circuitry and a method for protecting a vehicle power supply
US11787355B2 (en) 2018-09-18 2023-10-17 Knorr-Bremse Systeme Fuer Nutzfahrzeuge Gmbh Protection circuitry and a method for protecting a vehicle power supply

Also Published As

Publication number Publication date
US10521313B2 (en) 2019-12-31
US20180032413A1 (en) 2018-02-01
CN107666423B (zh) 2020-11-27
CN107666423A (zh) 2018-02-06

Similar Documents

Publication Publication Date Title
DE102017116883A1 (de) Ununterbrochene Verfügbarkeit von Daten während eines Fehlers in einem redundanten Mikrocontrollersystem
DE102017209721B4 (de) Vorrichtung für die Steuerung eines sicherheitsrelevanten Vorganges, Verfahren zum Testen der Funktionsfähigkeit der Vorrichtung, sowie Kraftfahrzeug mit der Vorrichtung
DE102014102582A1 (de) Fehlertolerantes Steuerungssystem
DE102018124499A1 (de) Dreifache Ausfallsicherheitsredundanz für Lenksysteme
DE102017106087A1 (de) Fehlertoleranz-muster und schaltprotokoll für mehrere hot- und cold-standby-redundanzen
DE102015221330A1 (de) Verfahren und Vorrichtung zum robusten Aktualisieren von Firmware eines Fahrzeuges über eine Luftschnittstelle
AT515454A2 (de) Verfahren zur Behandlung von Fehlern in einem zentralen Steuergerät sowie Steuergerät
DE102015110958A1 (de) Ausfallverwaltung in einem Fahrzeug
DE102018118568A1 (de) Redundante aktive steuerungssystemkoordination
EP3102475B1 (de) Ersatz-ressource für einen defekten rechnerkanal eines schienenfahrzeugs
EP3385934A1 (de) Vorrichtung für die steuerung eines sicherheitsrelevanten vorganges, verfahren zum testen der funktionsfähigkeit der vorrichtung, sowie kraftfahrzeug mit der vorrichtung
DE102018113330A1 (de) Bewertung einer Reihenfolge von Botschaften für ein redundantes Kommunikationssystem
DE102017202398A1 (de) Mikrocontroller und elektronische steuereinheit
DE112020005705T5 (de) Lenksteuervorrichtung und lenksteuerverfahren
DE102018220605B4 (de) Kraftfahrzeugnetzwerk und Verfahren zum Betreiben eines Kraftfahrzeugnetzwerks
DE112016006679B4 (de) Steuerungsvorrichtung und Recovery-Verarbeitungsverfahren für Steuerungsvorrichtung
DE112019007432B4 (de) Elektronische steuereinheit und programm
DE102009005266A1 (de) Anbindung eines Kommunikationscontrollers in Sicherheitsarchitekturen
DE102017119418A1 (de) Betriebssicheres systemkonstruktionsmuster basierend auf softwarecode-migration
EP1227406A1 (de) Transceiver mit Mitteln zum Fehlermanagement
DE102013202482A1 (de) Fehlersignalbehandlungseinheit, Gerät und Methode zur Ausgabe eines Fehlerzustandssignals
DE102019204176B4 (de) Schaltungsanordnung zum Verhindern der fehlerhaften Datenübertragung über eine Busschnittstelle
WO2018158039A1 (de) Umschaltung zwischen element-controllern im bahnbetrieb
DE102021124495A1 (de) Elektronische parkbremssteuervorrichtung und -verfahren
WO2011113405A1 (de) Steuergeräteanordnung

Legal Events

Date Code Title Description
R012 Request for examination validly filed