-
Die vorliegende Offenbarung betrifft ein computerimplementiertes Verfahren und eine Steuervorrichtung zur Steuerung einer Einheit eines Automotivesystems, wobei die elektrische/elektronische Architektur des Automotivesystems eine erste Steuereinheit, eine zweite Steuereinheit und die zusteuernde Einheit aufweist. Die erste Steuereinheit, die zweite Steuereinheit sind beispielsweise elektrische Steuereinheiten (ECU). Zur Steuerung der Einheit, die bspw. ein Aktor oder ein Sensor ist, wird ein Softwarecluster, welches in einer der Steuereinheiten ausgeführt wird, herangezogen.
-
Aktuelle Entwicklungen in der Automobilbranche wie etwa umfangreiche Fahrassistenzsysteme führen zu einem exponentiellen Wachstum des Softwareumfangs in elektronischen Steuergeräten. AUTOSAR Classic beschreibt für solche elektronische Steuergeräte eine standardisierte Softwarearchitektur. In herkömmlichen Softwarearchitekturen muss die gesamte Software einer elektrischen Steuereinheit als gesamtheitliches und geschlossenes Element erstellt werden, was neben langen Bauzeiten auch eine starke Abhängigkeit aller Softwarekomponenten untereinander zur Folge hat. Mit der Einführung des AR Flex Konzepts bietet AUTOSAR Classic nun eine Möglichkeit zur Aufteilung der Gesamtsoftware in einzelne Teilkomponenten. Dabei wird die Applikationsebene einer ECU Software in möglichst unabhängige Softwarecluster (SWCL) aufgeteilt. Alle Softwarecluster stellen getrennte Komponenten dar, welche separat voneinander gebaut und geladen werden können. Neben der Softwarearchitektur befindet sich auch die elektrische/elektronische Architektur eines Automotivesystems in einem tiefgreifenden Wandel. Um den steigenden Bedarf an Rechenleistung in einem Automotivesystem zu erfüllen ohne dabei die Komplexität der E-/E Architektur zur erhöhen, wird diese zunehmend zentralisiert. Mehrere domänenspezifische Steuergeräte werden hierzu zu wenigen hoch performanten Fahrzeugservern (Vehicle Servern) und Mastercontrollern zusammengefasst. Der Fokus der Vehicle Server liegt auf hoher Rechenleistung. Die Mastercontroller hingegen werden unter anderem beispielsweise für Regelungsaufgaben eingesetzt. Die beiden unterschiedlichen Architekturen von Fahrzeugservern und Mastercontrollern beeinflussen auch die verwendbare Softwarearchitektur. Für eine optimale Nutzung der Ressourcen eines Fahrzeugservers, wurde die AUTOSAR Adaptive Architektur entworfen. Dies ermöglicht die AUTOSAR konforme Entwicklung von Software auf einem POSIX basierten Betriebssystem.
-
Bei herkömmlichen Automotivesystemen wird bspw. eine Einheit wie ein Aktor oder ein Sensor mittels einer spezifischen, dafür vorgesehenen Steuereinheit gesteuert, welche wiederum die entsprechende Software hierzu ausführt. Um eine Redundanz bei sicherheitskritischen Einheiten des Automotivesystems herzustellen, werden herkömmlich beispielsweise mehrere nebeneinander angeordnete Hardwarekomponenten verbaut, die jeweils die entsprechende Einheit im Fehlerfall eines Steuergeräts steuern können und so das ausgefallene Steuergerät ersetzen können.
-
Die Aufgabe der vorliegenden Offenbarung ist es, ein Verfahren und eine Vorrichtung zu schaffen, mit dem bzw. mit der eine vorteilhaft einfache und zuverlässige Steuerung einer Einheit eines Automotivesystems ermöglicht wird.
-
Die Aufgabe wird gelöst durch ein computer-implementiertes Verfahren bzw. eine Steuerungsvorrichtung aufweisend die Merkmale der unabhängigen Patentansprüche. Vorteilhafte Ausgestaltungen der vorliegenden Offenbarung sind in den abhängigen Ansprüchen angegeben.
-
Gemäß der vorliegenden Offenbarung weist ein computerimplementiertes Verfahren zur Steuerung einer Einheit eines Automotivesystems die nachfolgend aufgezählten Schritte auf. Eine elektrische/elektronische Architektur des Automotivesystems weist eine erste Steuereinheit, eine zweite Steuereinheit und die zu steuernde Einheit auf. Die zweite Steuereinheit ist mittels eines primären Softwareclusters dazu ausgebildet die Einheit zu steuern. In anderen Worten, das primäre Softwarecluster wird auf dem zweiten Steuergerät ausgeführt, wodurch die zu steuernde Einheit des Automotivesystems gesteuert wird. Gemäß der vorliegenden Offenbarung ist die erste Steuereinheit dazu ausgebildet, mittels eines Backup-Softwareclusters im Fehlerfall der zweiten Steuereinheit die Steuerung der Einheit zu übernehmen. In anderen Worten kann mittels des Backup-Softwareclusters, welches auf der ersten Steuereinheit ausgeführt wird, auch die Steuerung der Einheit übernommen werden. Die Verfahrensschritte sind:
- - Erkennen, dass die Steuerung der Einheit mittels des primären Softwareclusters fehlerhaft und/oder defekt ist. Gemäß diesem Verfahrensschritt wird bspw. während des Betriebs des Automotivesystems erkannt, dass die Steuerung der Einheit mittels des primären Softwareclusters auf der zweiten Steuereinheit fehlerhaft und/oder defekt ist. Dementsprechend funktioniert die Steuerung der Einheit mittels der zweiten Steuereinheit nicht ordnungsgemäß.
- - Ansteuern der zweiten Steuereinheit mittels der ersten Steuereinheit, wodurch die zweite Steuereinheit in einen Fail-Silent-Zustand versetzt wird und keine potentiell fehlerhaften Daten mehr sendet. Gemäß diesem Verfahrensschritt wird, nachdem erkannt wurde, dass die Steuerung der Einheit mittels des primären Softwareclusters fehlerhaft und/oder defekt ist, die fehlerhafte zweite Steuereinheit durch die Ansteuerung mittels der ersten Steuereinheit in den Fail-Silent-Zustand versetzt, wodurch keine fehlerhaften Steuerungsdaten an die zu steuernde Einheit des Automotivesystems mehr gesendet werden und/oder keine fehlerhaften Daten mehr an andere Komponenten des Automotivesystems mehr gesendet werden. Der Fail-Silent-Zustand dient dementsprechend dazu, eine potentielle Fehlerfortpflanzung innerhalb des Automotivesystems zu verhindern und gleichzeitig das fehlerhafte zweite Steuergerät in einen Ruhezustand zu versetzen. Gemäß einer Ausführungsform ist der Fail-Silent-Zustand eingeleitet, indem die entsprechenden Empfänger (bspw. ETH-Transceivers) abgeschaltet werden.
- - Steuern der Einheit mittels des Backup-Softwareclusters der ersten Steuereinheit, wodurch die Funktionalität der Einheit aufrechterhalten bleibt. Gemäß diesem Verfahrensschritt wird anschließend die Steuerung der zu steuernden Einheit des Automotivesystems durch die erste Steuereinheit, dabei insbesondere durch das Backup-Softwarecluster, welches auf der ersten Steuereinheit zur Steuerung der Einheit ausgeführt wird, sichergestellt. Dementsprechend kann mittels des Backup-Softwareclusters die Funktionalität der zu steuernden Einheit aufrechterhalten bleiben.
-
Gemäß der vorliegenden Offenbarung kann dementsprechend die Steuerung der Einheit mittels des Backup-Softwareclusters der ersten Steuereinheit sichergestellt werden, selbst wenn die Steuerung der Einheit mittels des primären Softwareclusters der zweiten Steuereinheit fehlerhaft und/oder defekt ist. Dementsprechend kann eine Redundanz innerhalb des Automotivesystems zur Steuerung der Einheit aufgebaut werden ohne zusätzliche Hardwarekomponenten verbauen zu müssen, sondern lediglich mittels einer Anordnung eines Backup-Softwareclusters in einer weiteren bereits vorhandenen Steuereinheit innerhalb des Automotivesystems. Gemäß der vorliegenden Offenbarung kann demgemäß eine vorteilhafte einfache und redundante Steuerung der Einheit des Automotivesystems bspw. mittels des AR Flex Konzepts von AUTOSAR Classic realisiert werden. Die Redundanz kann selbst dann realisiert werden, wenn die erste und die zweite Steuereinheit auf unterschiedlichen Hardware- und Software-Architekturen basieren.
-
Gemäß einer Ausführungsform weist die elektrische- / elektronische- Architektur des Automotivesystems zudem eine dritte Steuereinheit auf, die dazu ausgebildet ist Steuerbefehle für Steuerung der Einheit von der ersten Steuereinheit oder der zweiten Steuereinheit zu empfangen und wobei die Steuerung der Einheit via die dritte Steuereinheit ausgeführt wird. Die dritte Steuereinheit kann gemäß einer Ausführungsform als virtuelle Applikation in der ersten oder der zweiten Steuereinheit implementiert sein. Gemäß einer weiteren Ausführungsform kann die dritte Steuereinheit als physische zusätzliche Steuereinheit verbaut sein. Die dritte Steuereinheit kann beispielsweise Steuerbefehle von der ersten oder der zweiten Steuereinheit empfangen, diese in ein für die zu steuernde Einheit ausführbare Sprache zu übersetzen, und dementsprechend di zu steuernde Einheit anzusteuern. Die dritte Steuereinheit kann diesbezüglich als Vermittler zwischen der ersten oder der zweiten Steuereinheit und der zu steuernden Einheit angesehen werden. Mittels der dritten Steuereinheit kann dementsprechend eine Vielzahl von unterschiedlichen zu steuernden Einheiten angesteuert werden.
-
Gemäß einer Ausführungsform ist die erste Steuereinheit ein Mastercontroller, die zweite Steuereinheit ein Fahrzeugserver und die dritte Steuereinheit eine Zonensteuereinheit. Der Fahrzeugserver weist gemäß einer Ausführungsform eine vorteilhaft hohe Rechenleistung auf. Der Mastercontroller ist bspw. gemäß einer Ausführungsform dazu ausgebildet, insbesondere Regelungsaufgaben innerhalb des Automotivesystems zu übernehmen und die Zonensteuereinheit ist dazu ausgebildet für eine speziell vordefinierte Zone innerhalb des Automotivesystems spezielle Steuerungen von wenigen vordefinierten Einheiten wie bspw. Aktoren und/oder Sensoren zu übernehmen.
-
Gemäß einer Ausführungsform weist die erste Steuereinheit einen Microcontroller auf und die zweite Steuereinheit einen Microprozessor auf. Die erste Steuereinheit ist bspw. als Mastercontroller insbesondere für Regelungsaufgaben vorgesehen und weist einen Microcontroller auf, sodass der Mastercontroller die notwendigen Eigenschaften zur Ausführung von Regelungsaufgaben vorteilhaft ausführen kann. Die zweite Steuereinheit ist gemäß einer Ausführungsform als Fahrzeugserver ausgebildet und weist einen Microprozessor auf, der die notwendigen Eigenschaften aufweist, um die Aufgaben des Fahrzeugservers zu übernehmen. Der Microcontroller weist Kompatibilitätsvorteile auf, da herkömmliche Automotivesoftware für Microcontroller basierte Steuergeräte entworfen wurde. Zudem sind Microcontroller kontengünstiger. Außerdem kann Software, welche für einen Microcontroller entworfen wurde, höhere Echtzeitanforderungen aufweisen. Microprozessoren weisen eine höhere Rechenleistung auf und können POSIX basierte Betriebssystem ausführen, deren Verwendung die Kompatibilität von Software zu anderen Systemen erhöht.
-
Gemäß einer Ausführungsform wird von der zweiten Steuereinheit während des Betriebs ein Heartbeat-Signal kontinuierlich oder zyklisch an die erste Steuereinheit gesendet, wobei die erste Steuereinheit erkennt, dass die Steuerung der Einheit mittels der zweiten Steuereinheit fehlerhaft oder defekt ist, wenn das Heartbeat-Signal ausbleibt oder fehlerhaft ist. In anderen Worten, die zweite Steuereinheit sendet das Heartbeat-Signal kontinuierlich oder zyklisch an die erste Steuereinheit, um dessen volle Funktionsfähigkeit an die erste Steuereinheit mitzuteilen. Sobald innerhalb der zweiten Steuereinheit ein Fehler oder Defekt auftritt, erfolgt eine Unterbrechung des Heartbeat-Signals, wodurch entsprechend das Heartbeat-Signal nicht die erste Steuereinheit erreicht. Dementsprechend kann die erste Steuereinheit erkennen, dass die zweite Steuereinheit fehlerhaft und/oder defekt ist, wodurch weitere Schritte zur Steuerung der zu steuernden Einheit des Automotivesystems eingeleitet werden können. Mittels des Heartbeat-Signals ist es dementsprechend vorteilhaft einfach zu erkennen, ob die zweite Steuereinheit, welche im Normalbetrieb die Steuerung der zu steuernden Einheit des Automotivesystems übernimmt, ordnungsgemäß funktioniert. Gemäß einer Ausführungsform wird das Heartbeat Signal jede Millisekunde oder jede zehn Millisekunden von der zweiten Steuereinheit gesendet. Ein Millisekundenbetrag zwischen einer und zehn Millisekunden ist ebenso denkbar.
-
Gemäß einer Ausführungsform wird die dritte Steuereinheit von der ersten Steuereinheit angesteuert, alle von der zweiten Steuereinheit erhaltene Datenpakete auszufiltern und nicht weiterzuleiten, sobald erkannt wird, dass die Steuerung der Einheit mittels der zweiten Steuereinheit fehlerhaft oder defekt ist. Bleibt bspw. das Heartbeat-Signal der zweiten Steuereinheit aus, wird dementsprechend die dritte Steuereinheit von der ersten Steuereinheit derart angesteuert, dass alle Datenpakete, welche von der zweiten Steuereinheit an die dritte Steuereinheit gesendet werden, herauszufiltern bzw. nicht weiterzuleiten. Dementsprechend wird sichergestellt, dass gegebenenfalls fehlerhafte Datenpakete von der zweiten Steuereinheit nicht zur Steuerung der zu steuernden Einheit des Automotivesystems herangezogen werden, sondern dass die Steuerung mittels des Backup-Softwareclusters auf der ersten Steuereinheit übernommen wird und dementsprechend sichergestellt wird, dass ein funktionierendes Softwarecluster die Steuerung der zu steuernden Einheit übernehmen kann und nicht von fehlerhaften Daten von der zweiten Steuereinheit gesteuert wird.
-
Gemäß einer Ausführungsform wird die Steuerung der Einheit via die erste Steuereinheit mittels des Backup-Softwareclusters durchgeführt. Das Backup-Softwarecluster gemäß AR Flex Konzept in AUTOSAR Classic ist das redundante Softwarecluster zu dem primären Softwarecluster, welches auf der zweiten Steuereinheit im Normalbetrieb der zweiten Steuereinheit zur Steuerung der Einheit herangezogen wird. Ist allerdings das primäre Softwarecluster fehlerhaft oder ist die zweite Steuereinheit defekt oder fehlerhaft, wird gemäß dieser Ausführungsform die Steuerung der Einheit via die erste Steuereinheit mittels des Backup-Softwareclusters durchgeführt. Gemäß einer weiteren Ausführungsform werden Daten, welche für die Steuerung der Einheit benötigt werden, und welche im Normalbetrieb an die zweite Steuereinheit übermittelt werden, an die erste Steuereinheit übermittelt, sodass das Backup-Softwarecluster eine ordnungsgemäße Steuerung der Einheit des Automotivesystems vornehmen kann. Gemäß einer weiteren Ausführungsform wird eine Synchronisation zwischen dem primären Softwarecluster und dem Backup-Softwarecluster vorgenommen, sodass eine vorteilhafte Steuerung der zu steuernden Einheit realisiert werden kann.
-
Gemäß einer Ausführungsform wird die zu steuernde Einheit mittels einer Service Discovery mit der ersten Steuereinheit verbunden, sobald erkannt wird, dass die Steuerung der Einheit mittels der zweiten Steuereinheit fehlerhaft oder defekt ist. Gemäß einer weiteren Ausführungsform wird die dritte Steuereinheit mittels einer Service Discovery mit der ersten Steuereinheit verbunden, sobald erkannt wird, dass die Steuerung der Einheit mittels der zweiten Steuereinheit fehlerhaft oder defekt ist. Die Service Discovery bezeichnet eine automatische Erkennung von Diensten in einem Rechnernetz. Das „Scalable service Oriented MiddlewarE over IP (SOME/IP)“ ermöglicht eine Service-orientierte Übertragung von Information. Service Discovery Protokoll kommuniziert die Verfügbarkeit von funktionalen Entitäten, welche Services genannt werden, im Automotivesystem. Der Service sendet zyklisch „Service Offer“ Nachrichten an das gesamte Netz (Broadcast). Ein oder mehrere Clients erhalten dieses Service Offer und prüfen, ob sie sich mit diesem Service verbinden wollen. Falls ja, sendet der Client eine Subscribe Nachricht an den Sender (Unicast), welcher wiederum mit einem Acknowledge antwortet. Anschließend wartet der Client auf Events vom Server. Die Service Discovery ist vorteilhaft weit verbreitet und standardisiert und sowohl in AUTOSAR Classic als auch in AUTOSAR Adaptive verfügbar.
-
Gemäß einer Ausführungsform wird das Ansteuern der zweiten Steuereinheit mittels der ersten Steuereinheit zur Versetzung der zweiten Steuereinheit in den Fail-Silent-Zustand mittels eines Paketfilters durchgeführt. Gemäß dieser Ausführungsform werden dementsprechend alle Ein- und Ausgabedaten der zweiten Steuereinheit herausgefiltert, sodass die fehlerhafte zweite Steuereinheit innerhalb des Automotivesystems nicht zu einer Fehlerfortpflanzung und zu einer fehlerhaften Datenübertragung führt. Gemäß dieser Ausführungsform werden alle Datenpakete mit der zweiten Steuereinheit (Vehicle Server) als Absender oder Empfänger nicht weitergeleitet oder verarbeitet. Dementsprechend befindet sich die (defekte) zweite Steuereinheit sich in einem definierten und sicheren Zustand und der/die Fehler der zweiten Steuereinheit beeinträchtigen nicht das restliche System.
-
Gemäß einer Ausführungsform ist die zu steuernde Einheit ein Aktor, ein zu überwachender Sensor oder eine andere zu steuernde Einheit eines Automotivesytems oder eine Kombination daraus. Die zu steuernde Einheit ist bspw. eine elektrische Maschine, ein Generator, ein Drucksensor, ein Temperatursensor, ein Antriebsstrang oder ein Teil eines Antriebsstrang oder eine andere zu steuernde Einheit des Automotivesystems.
-
Gemäß einer Ausführungsform weist das Automotivesystem zusätzlich eine Überwachungseinheit auf, die dazu ausgebildet ist, zu überwachen, ob die zu steuernde Einheit mittels des Backup-Softwareclusters der ersten Steuereinheit ordnungsgemäß gesteuert wird. Gemäß dieser Ausführungsform wird dementsprechend mittels der Überwachungseinheit überwacht, ob dem Fehlerfall der zweiten Steuereinheit die Steuerung der zu steuernden Einheit mittels des Backup-Softwareclusters ordnungsgemäß funktioniert. Die Überwachungseinheit kann gemäß einer Ausführungsform bspw. innerhalb der ersten Steuereinheit ausgebildet sein, die Überwachungseinheit kann gemäß einer weiteren Ausführungsform als separate Steuereinheit in dem Automotivesystem verbaut sein, oder gemäß einer weiteren Ausführungsform kann die Überwachungseinheit auch lediglich ein weiteres Softwarecluster, welches explizit zur Überwachung ausgebildet ist, innerhalb der ersten Steuereinheit ausgeführt werden.
-
Gemäß einem weiteren Aspekt der vorliegenden Offenbarung wird eine Steuervorrichtung zur Steuerung einer Einheit eines Automotivesystems offenbart, wobei eine elektrische/elektronische Architektur des Automotivesystems eine erste Steuereinheit, eine zweite Steuereinheit und die zu steuernde Einheit aufweist, wobei die zweite Steuereinheit mittels eines primären Softwareclusters dazu ausgebildet, die Einheit zu steuern und wobei die erste Steuereinheit mittels eines Backup-Softwareclusters dazu ausgebildet ist, im Fehlerfall der zweiten Steuereinheit die Steuerung der Einheit zu übernehmen, wobei die Steuervorrichtung dazu ausgebildet ist, eines der vorgenannten Verfahren auszuführen. Die Steuervorrichtung gemäß diesem Aspekt kann aus der ersten Steuereinheit, der zweiten Steuereinheit und der dritten Steuereinheit bestehen bzw. diese aufweisen und/oder zusätzliche Steuereinheiten aufweisen. Die Steuervorrichtung gemäß diesem Aspekt kann gemäß einer weiteren Ausführungsform als Teil einer zusätzlichen Steuereinheit innerhalb des Automotivesystems verbaut sein.
-
Ausführungsbeispiele und Weiterbildungen des Verfahrens und der Vorrichtung gemäß der vorliegenden Offenbarung sind in den Figuren dargestellt und werden anhand der nachfolgenden Beschreibung näher erläutert.
-
Es zeigen:
- 1 eine schematische Darstellung einer E-E-Architektur eines Automotivesystems gemäß einer ersten Ausführungsform,
- 2 eine schematische Darstellung einer E-E-Architektur eines Automotivesystems gemäß einer zweiten Ausführungsform,
- 3 eine schematische Darstellung einer E-E-Architektur eines Automotivesystems gemäß einer dritten Ausführungsform,
- 4 eine schematische Darstellung einer E-E-Architektur eines Automotivesystems gemäß einer vierten Ausführungsform,
- 5 eine schematische Darstellung eines Verfahrensablaufs zur Steuerung einer Einheit gemäß einer ersten Ausführungsform.
-
Die 1 zeigt eine E-E/ Hardware-Architektur eines Automotivesystems 100. Das Automotivesystem 100 weist einen ersten Fahrzeugserver 110, und einen zweiten Fahrzeugserver 120 auf. Der erste Fahrzeugserver 110 und der zweite Fahrzeugserver 120 können gemäß dieser Ausführungsform miteinander kommunizieren. Dies ist mit der gestrichelten Linie zwischen dem ersten Fahrzeugserver 110 und dem zweiten Fahrzeugserver 120 schematisch dargestellt. Das Automotivesystem 100 gemäß dieser Ausführungsform weist zusätzlich einen ersten Mastercontroller 130 und einen zweiten Mastercontroller 140 auf. Die Mastercontroller 130, 140 können jeweils untereinander und zusätzlich mit jeweils einem der Fahrzeugserver 110, 120 kommunizieren. Der erste Mastercontroller 130 kann gemäß dieser Ausführungsform mit dem ersten Fahrzeugserver 110 kommunizieren und der zweite Mastercontroller 140 kann gemäß dieser Ausführungsform mit dem zweiten Fahrzeugserver 120 kommunizieren. Dem ersten Mastercontroller 130 sind gemäß dieser Ausführungsform zusätzlich ein erster Sensor 132 und ein Aktor 134 zugeordnet. Der erste Mastercontroller 130 ist dazu ausgebildet, den ersten Sensor 132 zu steuern bzw. dessen Sensordaten zu verarbeiten. Zusätzlich ist der erste Mastercontroller 130 dazu ausgebildet den ersten Aktor 134 zu steuern. Dem zweiten Mastercontroller 140 sind eine elektrische Steuereinheit 142, ein zweiter Sensor 144 und ein zweiter Aktor 146 zugeordnet. Der zweite Mastercontroller 140 ist dazu ausgebildet, die erste elektrische Steuereinheit zu steuern bzw. dessen Daten zu empfangen und weiterzuverarbeiten. Zusätzlich ist der zweite Mastercontroller 140 dazu ausgebildet, Sensordaten des zweiten Sensors 144 zu empfangen und weiter zu verarbeiten und ggf. den zweiten Sensor 144 zu steuern. Zusätzlich ist der zweite Mastercontroller gemäß dieser Ausführungsform 140 dazu ausgebildet, den zweiten Aktor 146 zu steuern. Das Automotivesystem 100 weist gemäß dieser Ausführungsform zusätzlich eine erste Zonensteuereinheit 150, eine zweite Zonensteuereinheit 160 und eine achte Zonensteuereinheit 170 auf. In der 1 ist schematisch dargestellt, dass zusätzliche Zonensteuereinheiten verbaut werden können. Die erste Zonensteuereinheit 150, die zweite Zonensteuereinheit 160 und die weiteren Zonensteuereinheiten bis zur achten Zonensteuereinheit 170 können miteinander kommunizieren.
-
Gemäß der Ausführungsform, welche in der 1 dargestellt ist, ist die erste Zonensteuereinheit 150 mit dem ersten Fahrzeugserver 110 und dem ersten Mastercontroller 130 verbunden. Zusätzlich ist schematisch dargestellt, dass die weiteren Zonensteuereinheiten ebenso mit dem ersten Mastercontroller 130 und dem ersten Fahrzeugserver 110 und dem zweiten Fahrzeugserver 120 verbunden sein können bzw. sind. Der ersten Zonensteuereinheit 150 ist gemäß dieser Ausführungsform ein dritter Aktor 152 zugeordnet. Die erste Zonensteuereinheit 150 ist dementsprechend dazu ausgebildet, den dritten Aktor 152 anzusteuern. Der zweiten Zonensteuereinheit 160 ist ein dritter Sensor 162 und eine zweite elektrische Steuereinheit 164 zugeordnet. Die zweite Zonensteuereinheit 160 ist dementsprechend gemäß einer Ausführungsform bspw. dazu ausgebildet, die Sensordaten des Drittsensors 162 zu empfangen und weiterzuleiten und ggf. den dritten Sensor 162 zu steuern. Zusätzlich ist die zweite Zonensteuereinheit 160 dazu ausgebildet, die zweite elektrische Steuereinheit 164 anzusteuern bzw. deren Daten zu empfangen und weiterzuleiten. Der achten Zonensteuereinheit 170 sind gemäß dieser Ausführungsform ein vierter Sensor 172 und ein vierter Aktor 174 zugeordnet. Die achte Zonensteuereinheit ist dazu ausgebildet den vierten Sensor 172 zu steuern bzw. dessen Sensordaten zu empfangen und zu verarbeiten und weiterzuleiten. Die achte Zonensteuereinheit 170 ist zusätzlich dazu ausgebildet den vierten Aktor 174 zu steuern bzw. dessen Steuerung umzusetzen.
-
Die 2 zeigt ein E-E/Hardware-Architekturdetail 200 des Automotivesystems 100 aus 1. Dabei ist der erste Fahrzeugserver 110, der erste Mastercontroller 130, die erste Zonensteuereinheit 150 und der dritte Aktor 152 dargestellt. Wie aus 2 ersichtlich, ist der erste Fahrzeugserver 110 dazu ausgebildet, den dritten Aktor 152 über die erste Zonensteuerung 150 zu steuern. Als Backup ist der erste Mastercontroller 130 dazu ausgebildet, den dritten Aktor 152 über die erste Zonensteuereinheit 150 zu steuern. Der erste Fahrzeugserver 110 weist ein primäres Softwarecluster 210 zur Steuerung des Aktors 152 auf. Der erste Mastercontroller 130 weist ein Backup-Softwarecluster 220 zur Steuerung des Aktors 152 auf, wenn das primäre Softwarecluster 210 nicht zur Steuerung des dritten Aktors 152 herangezogen werden kann. Sowohl der erste Fahrzeugserver 110 als auch der erste Mastercontroller 130 weisen einen Fehler OP Agenten 230 auf. Der Fehler OP Agent 230 (Fail Operational Agent) kümmert sich um alle Aufgaben, die für die Widerherstellung des Systems erforderlich sind. Insbesondere um die Überwachung, Fail Silent und Start des Backup Softwareclusters.
-
Der Fehler OP Agent 230 ermöglicht es, dass alle Aufgaben, die für den Widerherstellungsprozess benötigt werden in einer Software Komponente gesammelt sind. Die eigentliche Funktionalität (primär und Backup Softwarecluster) kann gemäß einer Ausführungsform auch unabhängig von dem Fehler OP Agent 230 ausgeführt werden.
-
Die 3 zeigt einen ersten Netzwerkaufbau 300 zwischen dem ersten Fahrzeugserver 110, dem ersten Mastercontroller 130 und dem dritten Aktor 152. Dabei sind die unterschiedlichen Komponenten mittels einer Ethernet- oder einer CAN - Verbindung 310 miteinander verbunden.
-
Die 4 zeigt einen zweiten Netzwerkaufbau 400 zwischen dem ersten Fahrzeugserver 110, dem ersten Mastercontroller 130 und dem dritten Aktor 152. Die Verbindung zwischen den einzelnen Komponenten gemäß des zweiten Netzwerkaufbaus 400 ist mittels einer CAN oder LIN Verbindung 410 realisiert. In der 4 sind zusätzlich schematisch Input Daten 420 dargestellt, welche von dem dritten Aktor 152 an den ersten Fahrzeugserver 110 und/oder an den ersten Mastercontroller 130 geschickt werden. Sowohl in 3 als auch in 4 ist das primäre Softwarecluster des ersten Fahrzeugservers 110 schematisch dargestellt. In 4 ist zusätzlich ein PWM Signal 430, welches über eine CAN Verbindung von dem ersten Fahrzeugserver 110 oder von dem ersten Mastercontroller 130 an den dritten Aktor 152 geschickt werden kann, schematisch dargestellt. Der Netzwerkaufbau 400 oder der Netzwerkaufbau 300 kann gemäß dem Verfahren der vorliegenden Offenbarung zur Steuerung der zu steuernden Einheit herangezogen werden. Das Verfahren gemäß der vorliegenden Offenbarung ist demgemäß flexibel auf verschiedene Architekturen einsetzbar. Dadurch können Kostenvorteile realisiert werden, da CAN oder LIN Architekturen kostengünstiger sind als ETH Architekturen. Zudem ist ETH ein relativ aufwendiges Protokoll, welches eine vergleichsweise leistungsstarke Rechnerhardware voraussetzt. CAN oder LIN Architekturen können mit günstiger Hardware realisiert werden.
-
Die 5 entspricht in ihrem schematischen Aufbau der 2, zusätzlich zeigt die 5 jedoch ein Ablaufdiagramm 500 des Verfahrens gemäß der vorliegenden Offenbarung. In einem ersten Schritt 510, wird von dem ersten Mastercontroller 130 erkannt, dass der erste Fahrzeugserver 110 seine Aufgaben zur Steuerung des dritten Aktors 152 nicht korrekt oder nicht ordnungsgemäß ausführt. Ein simples Monitoring kann gemäß einer Ausführungsform mittels eines sog. Heartbeat-Signals realisiert werden, welches der erste Fahrzeugserver 110 zyklisch an den ersten Mastercontroller 130 sendet. Durch das Ausbleiben des Heartbeat-Signals erkennt der erste Mastercontroller 130 ein Fehlverhalten des Fahrzeugservers 110.
-
Mittels des zweiten Schritts 520 ist in dem Ablaufdiagramm 500 schematisch dargestellt, dass der erste Mastercontroller 130 dafür sorgt, dass sich der erste Fahrzeugserver 110 in einen Fail Silent Modus schaltet und sich dementsprechend fail silent verhält und keine potentiell fehlerhaften Daten mehr sendet. Dazu weist der erste Mastercontroller 130 die erste Zonensteuereinheit 150 zusätzlich dazu an, alle Datenpakete, welche von dem ersten Fahrzeugserver 110 gesendet werden, herauszufiltern und nicht weiterzuleiten, wodurch dementsprechend die Steuerung des dritten Aktors 152 durch den fehlerhaften ersten Fahrzeugserver 110 bzw. durch die fehlerhafte primäre Softwarecluster 210 unterbunden ist.
-
In einem dritten Schritt 530 des Ablaufdiagramms 500 ist schematisch dargestellt, dass der erste Mastercontroller 130 die kritische Funktionalität des dritten Aktors 152 fortführt. Hierzu wird das Backup-Softwarecluster 220 des ersten Mastercontrollers von einen sog. Hot Standby Status in einen aktiven Modus versetzt. Dies bedeutet, dass das Backup-Softwarecluster 220 des ersten Mastercontrollers 130 durchgehend ausgeführt wird und dementsprechend die gleichen Eingabewerte wie das primäre Softwarecluster 210 des ersten Fahrzeugservers 110 erhält. Lediglich die Ausgabe des Backup-Softwareclusters 210 wird außerhalb des Fehlerfalls nicht an dritten Aktor 152 weitergeleitet. Um die sicherheitskritische Funktion durch den ersten Mastercontroller 130 fortzusetzen, reicht somit eine Aktivierung der Ausgabe des Backup-Softwareclusters 220 aus.
-
In einem vierten Schritt 540 ist in dem Ablaufdiagramm 500 schematisch dargestellt, dass der dritte Aktor auch die Ausgabe des Backup-Softwareclusters 220 empfangen muss. Hierzu ist es notwendig, dass sich das Backup-Softwarecluster 220 mithilfe einer Service Discovery mit der ersten Zonensteuereinheit 150 Mastercontroller 130 verbindet, damit er über diesen den Aktor 152 ansteuern kann. Durch die Service Discovery wird das System so umkonfiguriert, dass der dritte Aktor 152 mit dem Backup-Softwarecluster 220 des ersten Mastercontrollers 130 Daten austauschen kann. War die Service Discovery erfolgreich, ist die Funktion des dritten Aktors 152 mittels des Backup-Softwareclusters 220 auf dem ersten Mastercontroller 130 wiederhergestellt und das Automotivesystem 100 funktioniert wieder einwandfrei.
