-
TECHNISCHES GEBIET
-
Die Erfindung betrifft allgemein ein Verfahren zur dynamischen Zuteilung einer Aufgabe und/oder von Daten/Signalinformationen in einer statisch zugeteilten und eingebetteten Softwarearchitektur eines Fahrzeugs.
-
HINTERGRUND
-
Eingebettete Softwarearchitekturen oder Plattformen (Middleware und Echtzeit-Betriebssysteme), die in der Kraftfahrzeugindustrie verwendet werden, wie etwa OSEK und AUTOSAR, werden zur Entwurfszeit mit einem festgelegten Satz von Betriebssystemaufgaben statisch konfiguriert. Alle Aufgaben, die jemals auf einem gegebenen Rechenhardwareknoten ausgeführt werden, werden zu dem Zeitpunkt zugeteilt, an dem das ausführbare Image gebaut (kompiliert und gelinkt) wird.
-
Softwarebasierte elektronische Steuersysteme werden in der Kraftfahrzeugindustrie zunehmend verwendet, um Merkmale der aktiven Sicherheit und des autonomen Fahrens zu steuern, welche die Bewegung und die dynamische Stabilität des Fahrzeugs beeinflussen. Da die Ebenen der Steuerungsintelligenz, des automatisierten Treffens von Entscheidungen und der in Software implementierten Steuerautorität über Stellglieder zusehends anwachsen, werden diese Steuersysteme immer kritischer. Die Software-, Hardware- und Systemarchitekturen dieser Steuersysteme müssen daher fehlertolerant sein und in einigen Fällen sogar bei Ausfall betriebsbereit bleiben. Dies erfordert, dass redundante Software, Rechenhardware, Sensoren, Stellglieder und Netzwerkkommunikationskomponenten so in das System eindesigned werden müssen, das, wenn eine Komponente ausfällt, eine andere Komponente zur Verfügung steht, um mit dem Bereitstellen einer sicheren Funktionalitätsebene fortzufahren, sei es in einem Modus mit voller Leistung oder in einem Modus mit verschlechterter Leistung.
-
Redundante Hardwarekomponenten müssen in das System statisch eindesigned werden, weil man zu einem Fahrzeug, das sich mitten in einem Fahrzyklus befindet, nicht einfach neue Hardware (Sensoren, Stellglieder, Rechner, Kommunikationsverbindungen, Kabelbäume) hinzufügen kann. Redundante Softwarekomponenten hingegen können im System entweder statisch oder dynamisch zugeteilt werden.
-
Jede der redundanten Instanziierungen der kritischen Software- und/oder Hardwarekomponenten muss zum Übertragen und/oder Empfangen von Daten und/oder Signalinformationen über das Fahrzeugnetzwerk hinweg in der Lage sein. Diese redundanten Instanziierungen der Software- und/oder Hardwarekomponenten, die koexistieren und ihre jeweiligen eigenen eindeutigen Ausgabesignale übertragen, erfordern eine Duplizierung von Netzwerksignalinformationen auf der Ebene des Datendictionary und das Verarbeiten/Wählen redundanter Meldungen an der Empfängerseite, wodurch die Netzwerkbandbreite, die Meldungspriorität und deren Zuteilung im Datendictionary erhöht werden. Außerdem wäre es aufgrund von Veränderungen beim Datendictionary notwendig, eine Skalierbarkeit einzuführen, um zusätzliche redundante Instanziierungen der kritischen Software zu erzeugen.
-
ZUSAMMENFASSUNG
-
Es wird ein Verfahren zum dynamischen Zuteilen entweder einer Aufgabe oder von Daten/Signalinformationen in einer statisch eingebetteten Architektur eines Fahrzeugs bereitgestellt. Das Verfahren umfasst, dass ein Systembetrieb analysiert wird, um eine fehlerhafte Komponente zu identifizieren, dass entweder eine Aufgabe, die von der identifizierten fehlerhaften Komponente ausgeführt wird, oder Daten/Signalinformationen, die mit der fehlerhaften Komponente verbunden sind, identifiziert wird bzw. werden und entweder die von der fehlerhaften Komponente ausgeführte Aufgabe oder die mit der fehlerhaften Komponente verbundenen Daten/Signalinformationen einer statisch zugeteilten und eingebetteten Reservekomponente neu zugeteilt wird bzw. werden. Die Aufgabe wird so neu zugeteilt, dass die Ausführung der neu zugeteilten Aufgabe für den zukünftigen Systembetrieb von der Reservekomponente erledigt wird. Die Daten/Signalinformationen werden so umgeleitet, dass Informationen über Eingabe- und Ausgabesignale für den zukünftigen Systembetrieb von der/für die Reservekomponente für die redundante Aufgabe bereitgestellt werden.
-
Ein System zum dynamischen Zuteilen entweder einer Aufgabe oder von Daten/Signalinformationen in einer statisch eingebetteten Architektur eines Fahrzeugs wird ebenfalls bereitgestellt. Das System umfasst ein Netzwerk und mehrere elektronische Steuereinheiten, die miteinander und mit dem Netzwerk in wirksamer Verbindung stehen. Jede der mehreren elektronischen Steuereinheiten enthält eine lokale Symptomsammelvorrichtung, und mindestens eine der mehreren elektronischen Steuereinheiten enthält ein Funktionszustands-Bestimmungsmodul. Das Funktionszustands-Bestimmungsmodul steht in wirksamer Verbindung mit den mehreren elektronischen Steuereinheiten und dem Netzwerk. Das Funktionszustands-Bestimmungsmodul ist ausgestaltet, um eine Fehlerbedingung unter Verwendung einer Ausgabe von den lokalen Symptomsammelvorrichtungen zu identifizieren und um Fehlerbedingungsinformationen an einen Rekonfigurationsmanager zu liefern. Der Rekonfigurationsmanager ist ausgestaltet, um eine Neuzuteilung einer Aufgabe und/oder von Daten/Signalinformationen, die mit der identifizierten Fehlerbedingung verbunden sind, auszulösen.
-
Folglich implementiert das Verfahren eine dynamische Neuzuteilung von Software und/oder Hardware (manchmal als eine dynamische Neukonfiguration bezeichnet) in Ansprechen auf eine identifizierte fehlerhafte Komponente auf einer existierenden eingebetteten Softwareplattform, die nur eine statische Zuteilung von Softwarekomponenten unterstützt, wodurch die Effizienz der Netzwerkarchitektur verbessert wird.
-
Die vorstehenden Merkmale und Vorteile und andere Merkmale und Vorteile der vorliegenden Erfindung ergeben sich leicht aus der folgenden genauen Beschreibung der besten Arten, um die Erfindung auszuführen, wenn sie in Verbindung mit den beiliegenden Zeichnungen gelesen wird.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
1 ist eine schematische Zeichnung eines Fahrzeugnetzwerkes.
-
2 ist ein Flussdiagramm, das die Arbeitsweise eines Rekonfigurationsmanagers des Fahrzeugnetzwerks zeigt.
-
3 ist eine schematische Zeichnung, die einen Rekonfigurations-Eventmanager zeigt, der eine Aufgabe einer Reservekomponente neu zuteilt.
-
4 ist ein Flussdiagramm, das die Arbeitsweise eines Rekonfigurations-Signalmanagers des Fahrzeugnetzwerks zeigt.
-
5 ist eine schematische Zeichnung, die eine Redundanz auf Netzwerkebene für die Neuzuteilung von Aufgaben zeigt.
-
6 ist eine schematische Zeichnung, die eine Redundanz auf der Ebene der elektronischen Steuereinheiten für die Neuzuteilung von Aufgaben zeigt.
-
GENAUE BESCHREIBUNG
-
Mit Bezug auf die Figuren, in denen gleiche Bezugszeichen in den verschiedenen Ansichten gleiche Teile bezeichnen, ist ein Fahrzeugnetzwerk in 1 allgemein bei 10 gezeigt. Beim Entwurf und der Implementierung eines dynamischen Softwarezuteilungsschemas auf einer Softwareplattform, die nur eine statische Softwarezuteilung unterstützt, müssen zwei Aspekte berücksichtigt werden. Der eine Aspekt dreht sich um den Steuerungsfluss, während sich der andere Aspekt mit dem Datenfluss beschäftigt. Der Steuerungsfluss beschäftigt sich damit, wie die Softwarekomponenten ausgelöst oder aktiviert werden, während sich der Datenfluss damit beschäftigt, wie die Eingaben und Ausgaben der Softwarekomponente mit dem Rest des Systems verbunden werden, sogar nachdem die Softwarekomponente zu einem anderen Rechenknoten bewegt (neu zugeteilt) wurde.
-
Der Steuerungsfluss des dynamischen Softwarezuteilungsschemas beschäftigt sich mit der Weise, in der die Ausführung von Softwarekomponenten ausgelöst oder aktiviert wird. Bei einer statisch zugeteilten und eingebetteten Netzwerkarchitektur müssen alle Aufgaben zum Zeitpunkt des Systembaus vorab so zugeteilt werden, wie es in einer statischen Aufgabentabelle angegeben ist. Beispielsweise gibt beim OSEK-Betriebssystem, das in der Kraftfahrzeugindustrie typischerweise verwendet wird, die OIL-(OSEK Implementation Language)-Konfigurationsdatei den vollständigen Satz von Aufgaben genau an, die während der gesamten Lebensdauer des Systems zur Ausführung an einem gegebenen Knoten verfügbar sein werden.
-
Hier wird ein Verfahren offenbart, das die dynamische Zuteilung von Softwareaufgaben in einer statisch zugeteilten Softwarearchitektur nachahmt. Das Verfahren umfasst, dass zunächst eine Sicherheitsanalyse durch Identifizieren zu berücksichtigender Fehler (ein Fehlermodell), eine Gefahrenanalyse und eine Risikobeurteilung durchgeführt werden. Für jede Gefahr wird in Abhängigkeit von ihrer Risikobeurteilung (Wahrscheinlichkeit und Schwere) ein Sicherheitsziel definiert, das die sichere Antwort oder Aktion auf die Gefahr angibt, sei es ein stiller Ausfall in einen sicheren Zustand oder das Fortsetzen des Betriebs mit verschlechterter oder voller Funktionalität. Als nächstes wird eine Systemredundanzarchitektur so entworfen, dass die definierten Sicherheitsziele enthalten sind. Die Redundanzarchitektur gibt die benötigten Redundanzebenen für Sensoren, Stellglieder, Rechner, Kommunikationskopplungen und Softwarekomponenten an. Danach wird ein Fehlermanagementschema entworfen, das aus einem Plan zur dynamischen Neuzuordnung oder Neukonfiguration besteht, für den Softwarekomponenten redundante Kopien aufweisen müssen, und bei dem diese redundanten Kopien in Ansprechen auf Fehlerereignisse oder Bedingungen im endgültigen System ausgeführt werden. Schließlich werden Instanzen jeder Softwarekomponente in diesem Plan einer Aufgabe an jedem Rechenknoten statisch zugeteilt, auf welchem sie gemäß dem Neukonfigurationsplan jemals laufen sollen. Außerdem wird ein Ereignis 42 des Betriebssystems für jede derartige Softwarekomponente statisch definiert und zugeteilt, welches als der Auslösemechanismus, der dieser Aufgabe entspricht, dienen wird.
-
Bei jeder elektronischen Steuereinheit (ECU) des Netzwerks 10, d. h. in jedem Rechenknoten, wird eine ”lokale Symptomsammelvorrichtung” verwendet, um Informationen lokal für den Knoten zu sammeln, die zum Bewerten des Funktionszustands des Gesamtsystems relevant sind. Diese Informationen von allen Knoten werden an ein oder mehrere ”Module zur Bestimmung des Funktionszustands des Systems” übertragen, welche den gesamten Satz von Symptomen beurteilen und feststellen, welche Fehlereignisse oder Bedingungen vorhanden sind. Zu Redundanzzwecken können mehrere Kopien dieses Moduls zur Bestimmung des Funktionszustands des Systems auf verschiedenen Knoten laufen und sie können miteinander in Verbindung stehen und sich untereinander auf den Funktionszustand des Gesamtsystems (Fahrzeugs) verständigen, das heißt, welche Komponenten fehlerhaft sind. Um diese Verständigung herzustellen, können sie ein Verständigungsprotokoll verwenden. Diese Informationen über Fehlerereignisse und -bedingungen auf Systemebene, über die man sich verständigt hat, werden an einen oder mehrere ”Rekonfigurationsmanager” an einzelnen Knoten im System gesendet, bei denen Entscheidungen getroffen werden, wie Softwarekomponenten und/oder Signal- oder Kommunikationsverbindungen dynamisch neu zugeteilt oder neu konfiguriert werden sollen. Nachdem diese Entscheidung darüber getroffen wurde, wo neue Softwarekomponenten zugeteilt werden müssen oder wo neue Kommunikationsverbindungen oder Signale zugeteilt werden müssen, werden diese Informationen entweder an einen ”Rekonfigurations-Eventgenerator” oder einen ”Rekonfigurations-Signalgenerator” an jedem Knoten weitergeleitet, an dem neue Softwarekomponenten oder die neuen Signal- oder Kommunikationsverbindungen zugeteilt werden müssen. Diese Ereignisse werden an eine Middleware 38 und Betriebssystemkomponenten weitergeleitet, welche eine dynamische Softwarezuteilung nachahmen, indem sie statisch vorhandene aber inaktive Softwarekomponenten an diesem Knoten initialisieren oder indem sie Kommunikationsverbindungen zwischen Komponenten herstellen.
-
Die in 1 gezeigte Netzwerkarchitektur auf Systemebene wird verwendet, um das vorstehend beschriebene dynamische Neukonfigurationsschema zu implementieren. Das Netzwerk 10 enthält eine erste elektronische Steuereinheit (ECU) 20 und eine zweite ECU 30a. Die erste ECU 20 und die zweite ECU 30a sind durch einen Netzwerkbus 28 derart verbunden, dass Informationen dazwischen übertragen und gemeinsam genutzt werden können. Die zweite ECU 30a ist einem ersten Sensor 14a und einem ersten Stellglied 16a zugeordnet und damit verbunden. Der erste Sensor 14a kann einen beliebigen Typ, Stil oder eine beliebige Art von Sensor zur Erfassung bestimmter benötigter Daten für die zweite ECU 30a umfassen. Das erste Stellglied 16a ist zur Steuerung einer spezifischen Operation des Fahrzeugs ausgestaltet und kann einen beliebigen geeigneten Typ von Stellglied umfassen. Die zweite ECU 30a steuert den Betrieb des ersten Stellglieds 16a. Die zweite ECU 30a umfasst eine erste lokale Symptomsammelvorrichtung 12a, welche die Daten vom ersten Sensor 14a empfängt und sammelt. Die erste lokale Symptomsammelvorrichtung 12a ist mit einer ersten Softwarekomponente 18a gekoppelt. Die erste Softwarekomponente 18a führt eine Systemoperation der zweiten ECU 30a aus. Beispielsweise kann die erste Softwarekomponente 18a eine Ausgabe berechnen, welche die zweite ECU 30a verwendet, um zu bestimmen, wann das erste Stellglied 16a betätigt werden soll.
-
Die erste ECU 20 ist einem zweiten Sensor 14b und einem dritten Sensor 14c zugeordnet und mit diesen verbunden. Der zweite Sensor 14b und der dritte Sensor 14c können einen beliebigen Typ, Stil oder eine beliebige Art von Sensor zum Erfassen bestimmter benötigter Daten für die erste ECU 20 umfassen. Außerdem ist die erste ECU 20 einem zweiten Stellglied 16b und einem dritten Stellglied 16c zugeordnet und damit verbunden. Das zweite Stellglied 16b und das dritte Stellglied 16c sind jeweils ausgestaltet, um eine spezifische Operation des Fahrzeugs zu steuern und können einen beliebigen geeigneten Typ von Stellglied umfassen. Die erste ECU 20 steuert den Betrieb des zweiten Stellglieds 16b und des dritten Stellglieds 16c. Die erste ECU 20 enthält eine zweite lokale Symptomsammelvorrichtung 12b, welche die Daten vom zweiten Sensor 14b und vom dritten Sensor 14c empfängt und sammelt. Die zweite lokale Symptomsammelvorrichtung 12b ist mit einer zweiten Softwarekomponente 18b gekoppelt. Die zweite Softwarekomponente 18b führt eine Systemoperation der ersten ECU 20 aus. Beispielsweise kann die zweite Softwarekomponente 18b eine Ausgabe berechnen, welche die erste ECU 20 verwendet, um zu bestimmen, wann das zweite Stellglied 16b und/oder das dritte Stellglied 16b betätigt werden sollen.
-
Die erste ECU 20 enthält ein Modul 22 zur Bestimmung des Funktionszustands des Systems. Das Modul 22 zur Bestimmung des Funktionszustands des Systems empfängt eine Ausgabe von der zweiten lokalen Systemsammelvorrichtung 12b intern und von der ersten lokalen Systemsammelvorrichtung 12a der zweiten ECU 30a durch den Netzwerkbus 28. Das Modul 22 zur Bestimmung des Funktionszustands des Systems analysiert die Ausgabe von der ersten lokalen Symptomsammelvorrichtung 12a und der zweiten lokalen Symptomsammelvorrichtung 12b, um festzustellen, ob eine oder mehrere Komponenten des Fahrzeugnetzwerks 10 fehlerhaft sind oder anderweitig nicht korrekt arbeiten. Beispielsweise kann das Modul 22 zur Bestimmung des Funktionszustands des Systems feststellen, dass die erste ECU 20 und/oder die zweite ECU 30a nicht korrekt funktionieren, dass die erste Softwarekomponente 18a und/oder die zweite Softwarekomponente 18b nicht korrekt funktionieren, dass der erste Sensor 14a, der zweite Sensor 14b und/oder der dritte Sensor 14c nicht korrekt funktionieren, oder dass eine Kommunikationsverbindung oder ein Signal zwischen zwei oder mehreren der verschiedenen Komponenten des Fahrzeugnetzwerks 10 nicht korrekt funktioniert.
-
Wenn das Modul 22 zur Bestimmung des Funktionszustands des Systems eine fehlerhafte Komponente identifiziert, dann benachrichtigt das Modul 22 zur Bestimmung des Funktionszustands des Systems einen Rekonfigurationsmanager 24. Der Rekonfigurationsmanager 24 stellt fest, welche Art von Komponente die identifizierte fehlerhafte Komponente ist, d. h. eine Hardwarekomponente wie etwa eine ECU oder ein Sensor, eine Softwarekomponente oder eine Kommunikationsverbindung oder ein Signal, das eine oder mehrere der verschiedenen Komponenten des Fahrzeugnetzwerks 10 verbindet. Nachdem der Rekonfigurationsmanager 24 festgestellt hat, welchen Typ von Komponente die fehlerhafte Komponente umfasst, stößt der Rekonfigurationsmanager 24 dann entweder einen Rekonfigurations-Signalmanager 32 oder einen Rekonfigurations-Eventmanager 36 an oder instruiert sie. Der Rekonfigurationsmanager 24 stößt den Rekonfigurations-Signalmanager 32 an, wenn die fehlerhafte Komponente als ein fehlerhafter Sensor oder eine fehlerhafte Kommunikationsverbindung identifiziert wurde. Der Rekonfigurationsmanager 24 stößt den Rekonfigurations-Eventmanager an, wenn die fehlerhafte Komponente eine Softwarekomponente ist. Wenn die fehlerhafte Komponente als eine ECU identifiziert wurde, dann kann der Rekonfigurationsmanager 24 sowohl den Rekonfigurations-Signalmanager 32 als auch den Rekonfigurations-Eventmanager 36 anstoßen. Der Rekonfigurations-Eventmanager 36 kann mit der Middleware 38 interagieren, um die Aufgabe neu zuzuteilen.
-
Mit Bezug auf 2 ist ein Flussdiagramm des Rekonfigurationsmanagers 24 gezeigt. Der Rekonfigurationsmanager 24 wird von dem Modul 22 zur Bestimmung des Funktionszustands des Systems über eine fehlerhafte Komponente benachrichtigt, was bei Block 100 angezeigt ist. Der Rekonfigurationsmanager 24 stellt dann fest, welchen Typ von Komponente die fehlerhafte Komponente umfasst, was durch Kästchen 105 angezeigt ist.
-
Wenn die fehlerhafte Komponente als eine Softwarekomponente identifiziert wird, was durch Kästchen 18 angezeigt ist, dann kann der Rekonfigurationsmanager 24 die Softwareaufgabe auf eine andere Implementierung der Softwareaufgabe neu zuteilen. Eine andere Implementierung der Softwareaufgabe umfasst, dass ein oder mehrere Softwarealgorithmen verwendet werden, um das gleiche Ergebnis wie die fehlerhafte Softwarekomponente zu erzielen. Nachdem der Rekonfigurationsmanager 24 bestimmt hat, welchen Reservesoftwarekomponenten 18 die Softwareaufgabe neu zugeteilt werden soll, identifiziert der Rekonfigurationsmanager 24 dann die spezifischen Softwareaufgaben, die angestoßen werden müssen, was durch Kästchen 130 angezeigt ist. Sobald die spezifischen Softwareaufgaben identifiziert worden sind, stößt der Rekonfigurationsmanager 24 den Rekonfigurations-Eventmanager 36 oder instruiert ihn, die Reservekomponente zu implementieren, d. h. die identifizierten Aufgaben zu implementieren, die abgeschlossen werden müssen, um die Softwareaufgabe von der fehlerhaften Softwarekomponente der Reservekomponente neu zuzuteilen, was durch Kästchen 135 angezeigt ist.
-
Wenn die fehlerhafte Komponente als ein fehlerhafter Sensor oder eine fehlerhafte Kommunikationsverbindung identifiziert wurde, was durch Kästchen 14 angezeigt ist, dann identifiziert der Rekonfigurationsmanager 24, welche Signale neu zugeteilt werden müssen, was durch Kästchen 120 angezeigt ist. Das fehlerhafte Signal oder die fehlerhafte Kommunikationsverbindung wird von der Reservekomponente neu zugeteilt. Wenn die fehlerhafte Komponente ein fehlerhaftes Signal oder eine fehlerhafte Kommunikationsverbindung ist, kann die Reservekomponente einen alternativen Sensor oder eine alternative ECU enthalten, welche zur Erzeugung der benötigten Informationen und zum Umleiten der Informationen an alle benötigten Knoten in der Lage ist. Nachdem der Rekonfigurationsmanager 24 identifiziert hat, welche Signale umgeleitet werden müssen, instruiert der Rekonfigurationsmanager 24 dann den Rekonfigurations-Signalmanager 32 oder stößt diesen an, um das Umleiten des fehlerhaften Signals oder der fehlerhaften Kommunikationsverbindung zu implementieren, was durch Kästchen 125 angezeigt ist.
-
Wenn die fehlerhafte Komponente als eine fehlerhafte ECU identifiziert wurde, was durch Kästchen 30 angezeigt ist, identifiziert der Rekonfigurationsmanager 24 dann die Softwarekomponenten der fehlerhaften ECU, die neu zugeteilt werden müssen. Der Rekonfigurationsmanager 24 kann auf eine Tabelle von Softwarekomponenten zugreifen, die in jeder ECU des Netzwerks 10 verfügbar sind, welche allgemein durch Kästchen 26 angezeigt ist, und er identifiziert, welcher ECU die kritischen Softwarekomponenten der fehlerhaften ECU neu zugeteilt werden sollen, was allgemein bei Kästchen 110 angezeigt ist. Sobald der Rekonfigurationsmanager 24 identifiziert hat, welcher ECU die kritischen Softwarekomponenten der fehlerhaften ECU zugeteilt werden sollen, kann der Rekonfigurationsmanager 24 dann Softwareaufgaben identifizieren, die abgeschlossen werden müssen, um die kritischen Softwarekomponenten zu implementieren, was durch Kästchen 130 angezeigt ist, und kann dann den Rekonfigurations-Eventmanager 36 anstoßen oder instruieren, um die identifizierten Aufgaben zu implementieren, die abgeschlossen werden müssen, um die Softwareaufgabe von der fehlerhaften ECU-Komponente neu zuzuteilen. Zusätzlich zur Neuzuteilung der Softwareaufgaben im Fall einer fehlerhaften ECU kann der Rekonfigurationsmanager 24 auch Signale oder Kommunikationsverbindungen identifizieren, was durch Kästchen 120 angezeigt ist, die hergestellt werden müssen, um zu ermöglichen, dass die Reservekomponenten die neu zugeteilten Softwareaufgaben abschließen. Der Rekonfigurationsmanager 24 instruiert dann den Rekonfigurations-Signalmanager 32 oder stößt diesen an, um das Umleiten der benötigten Signale oder Kommunikationsverbindung zu implementieren, was durch Kästchen 125 angezeigt ist.
-
Mit Bezug auf 3 werden die Details dessen, wie die Neukonfigurationsereignisse in den Komponenten der Middleware 38 und des Betriebssystems 42 verwendet werden, um eine dynamische Zuteilung in einer statisch zugeteilten Architektur nachzuahmen, unter Verwendung von AUTOSAR als Beispiel für eine statisch zugeteilte Softwarearchitektur gezeigt. In AUTOSAR werden Aufgaben von einem Betriebssystem 42 mithilfe einer statischen Plantabelle 44 statisch zugeteilt und statisch geplant. Der Körper 46 jeder Aufgabe, die vom Betriebssystem 42 geplant wird, steht jedoch unter der Kontrolle der Middleware-Schicht 38, welche RTE (Run-Time Environment) genannt wird. Lauffähige Entitäten (kurz ”Runnables” genannt) in Aufgaben werden von einer Plantabelle 48 auf zweiter Ebene innerhalb der RTE aufgerufen. Von dem Rekonfigurations-Eventgenerator erzeugte Ereignisse können entweder Runnables in der RTE-Plantabelle 48 oder Aufgaben in der Plantabelle 44 des Betriebssystems 42 auslösen. In beiden Fällen besteht die Idee darin, dass Aufgaben des Betriebssystems 42 oder Runnables der RTE zum Zeitpunkt des Systementwurfs und des Systembaus statisch zugeteilt worden sind, sie aber schlafen, bis das Auslöseereignis sie benachrichtigt, dass sie aktiviert werden sollen, wodurch das Endergebnis einer dynamischen Softwareneuzuteilung oder Neukonfiguration nachgeahmt wird.
-
Mit Bezug auf 4 ist ein Flussdiagramm des Rekonfigurations-Signalmanagers 32 gezeigt. Der Rekonfigurations-Signalmanager 32 wird über ein fehlerhaftes Signal oder eine fehlerhafte Kommunikationsverbindung benachrichtigt, was durch Kästchen 200 angezeigt ist. Der Rekonfigurations-Signalmanager 32 bestimmt dann, ob eine Neukonfiguration von Daten für das fehlerhafte Signal oder die fehlerhafte Kommunikationsverbindung möglich ist, was durch Kästchen 205 angezeigt ist. Wenn eine Neukonfiguration von Daten für das fehlerhafte Signal nicht möglich ist, dann sendet der Rekonfigurations-Signalmanager 32 ausfallsichere Werte für das fehlerhafte Signal oder die fehlerhafte Kommunikationsverbindung an das Netzwerk 10, was durch Kästchen 210 angezeigt ist. Wenn eine Neukonfiguration von Daten für das fehlerhafte Signal möglich ist, dann bestimmt der Rekonfigurations-Signalmanager 32 die Art der Redundanz im System, was allgemein bei 215 angezeigt ist. Die Feststellung, dass eine Redundanz auf Netzwerkebene existiert, ist bei 217 angezeigt. Die Feststellung, dass eine Redundanz auf ECU-Ebene existiert, ist bei 219 angezeigt.
-
Dann, wenn der Rekonfigurations-Signalmanager 32 feststellt, dass eine Redundanz auf Netzwerkebene existiert, kann der Rekonfigurations-Signalmanager 32 die Signalleitungstabelle neu konfigurieren, was allgemein bei 220 angezeigt ist. Die Signalleitungstabelle ist eine Tabelle, die angibt, wo jedes Signal hingeleitet wird und/oder woher es geleitet wird, und sie wird neu konfiguriert, um anzugeben, dass das Signal von der fehlerhaften Komponente nun von der Reservekomponente kommt. Mit Bezug auf 4 und 5 kann der in 1 gezeigte Rekonfigurations-Signalmanager 32 dann das Signal von der primären Softwarekomponente 18c, d. h. der fehlerhaften Softwarekomponente, deaktivieren und er kann das Signal von der Reservesoftwarekomponente 18d aktivieren, was allgemein bei Kästchen 225 angezeigt ist. Dies wird so durchgeführt, dass nur ein einziges genaues Signal über das Netzwerk 10 gesendet wird. Der Rekonfigurations-Signalmanager 32 kann dann dem Signal von der Reservekomponente Zeitverlaufsattribute des Netzwerks 10 zuordnen, was bei Kästchen 230 angezeigt ist. Der Rekonfigurations-Signalmanager 32 kann dann alle Signalempfänger über die Signalneukonfiguration benachrichtigen, d. h. dass das Signal nun von der Reservekomponente anstelle der primären oder fehlerhaften Komponente kommt, was bei Kästchen 235 angezeigt ist.
-
Mit Bezug auf 5 ist ein Beispiel der Redundanz auf der Ebene des Netzwerks 10 gezeigt. Die Redundanz auf der Ebene des Netzwerks 10 umfasst eine dritte ECU 30b und eine vierte ECU 30c. Die vierte ECU 30c enthält eine primäre Softwarekomponente 18c. Die dritte ECU 30b enthält eine Reservesoftwarekomponente 18d. Wenn die fehlerhafte Komponente als ein Signal von der primären Softwarekomponente 18c identifiziert wird, dann leitet der Rekonfigurations-Signalmanager 32 die Verantwortung für das Signal von der primären Softwarekomponente 18c auf die Reservesoftwarekomponente 18d um.
-
Wieder mit Bezug auf 4 kann der Rekonfigurations-Signalmanager 32 dann, wenn er feststellt, dass eine Redundanz auf ECU-Ebene existiert, die Signalleitungstabelle neu konfigurieren, was allgemein bei 240 angezeigt ist. Der Rekonfigurations-Signalmanager 32 kann dann die Reservekomponente verwenden, um das Signal zu berechnen, was bei Kästchen 245 angezeigt ist. Der Rekonfigurations-Signalmanager 32 kann dann das Signal von der primären Softwarekomponente 18c, d. h. der fehlerhaften Softwarekomponente, deaktivieren und er kann das Signal von der Reservesoftwarekomponente 18d aktivieren, was allgemein durch Kästchen 250 angezeigt ist. Dann kann der Rekonfigurations-Signalmanager 32 das Signal durch den Netzwerkbus 28 an das Netzwerk 10 sowie an andere interne ECU-Funktionen übertragen, was durch Kästchen 255 angezeigt ist. Die Frequenz der Signalübertragung (periodische Datenübertragung, periodisch basierend auf einem Ereignis, Veränderung bei Ereignisübertragung usw.) wird von dem Rekonfigurations-Signalmanager 32 gesteuert, der im Augenblick das Signal besitzt. Eine allgemeine Strategie zur impliziten Übertragung des Besitzes, z. B. über einen Timeout oder explizit, z. B. über Handshake-Signale kann über das Kommunikationsnetzwerk 10 ausgeführt werden.
-
Mit Bezug auf 6 ist ein Beispiel einer Redundanz auf ECU-Ebene gezeigt. Die ECU 30 enthält die erste Softwarekomponente 18a. Die erste Softwarekomponente 18a enthält eine primäre Aufgabe 90a, eine erste Reserveaufgabe 90b und eine zweite Reserveaufgabe 90c. Wenn identifiziert wird, dass das fehlerhafte Signal von der primären Aufgabe 90a der ersten Softwarekomponente 18a stammt, dann kann der Rekonfigurations-Signalmanager 32 die Softwareaufgabe auf die erste Reserveaufgabe 90b oder die zweite Reserveaufgabe 90c umschalten, wodurch das Signal von entweder der ersten Reserveaufgabe 90b oder der zweiten Reserveaufgabe 90c aktiviert wird und das Signal von der primären Aufgabe 90a deaktiviert wird.
-
Obwohl die besten Arten zum Ausführen der Erfindung im Detail beschrieben wurden, werden Fachleute auf dem Gebiet, das diese Erfindung betrifft, verschiedene alternative Konstruktionen und Ausführungsformen zum Umsetzen der Erfindung in die Praxis im Umfang der beigefügten Ansprüche erkennen.
