-
Die vorliegende Erfindung betrifft ein Verfahren zum Bestimmen einer E/E-Architektur eines Fahrzeugs, insbesondere eines autonom fahrenden Fahrzeugs, ein Fahrzeug mit einer auf diese Weise bestimmten E/E-Architektur, sowie eine Recheneinheit und ein Computerprogramm zu dessen Durchführung.
-
Hintergrund der Erfindung
-
E/E-Architekturen (Elektrisch/Elektronische-Architektur für moderne Fahrzeuge, insbesondere autonom fahrende Fahrzeuge, sind aufgrund der Anzahl der beteiligten Steuergeräte und Sensoren und der zu berücksichtigenden Kombinationen in der Regel sehr komplex. Insbesondere autonom fahrende Fahrzeuge sollten so selten wie möglich in degradierte Zustände übergehen und sollten im degradierten Zustand immer noch über alle Fähigkeiten verfügen, die erforderlich sind, um eine sichere Stoppposition (sicher) zu erreichen.
-
Offenbarung der Erfindung
-
Erfindungsgemäß werden ein Verfahren zum Bestimmen einer E/E-Architektur eines Fahrzeugs, ein Fahrzeug mit einer solchen E/E-Architektur sowie eine Recheneinheit und ein Computerprogramm zu dessen Durchführung mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.
-
Die Erfindung beschäftigt sich mit E/E-Architekturen (oder auch nur Architekturen) von Fahrzeugen, insbesondere autonom (oder automatisiert) fahrenden Fahrzeugen, und zwar insbesondere deren Bestimmung. Unter der E/E-Architektur eines Fahrzeugs ist die Konvergenz von Elektronikhardware, Netzwerkkommunikation, Softwareanwendungen und Verkabelung zu einem integrierten System - bzw. dieses integrierte System - zu verstehen, das eine ständig wachsende Zahl von Fahrzeugfunktionen in den Bereichen Fahrzeugsteuerung, Karosserie und Sicherheit, Infotainment, aktive Sicherheit und andere Komfort-, Bequemlichkeits- und Konnektivitätsfunktionen beinhaltet. Dies gilt umso mehr für autonom fahrende Fahrzeuge mit immer mehr dieser Funktionen oder Funktionalitäten. Das Bestimmen einer E/E-Architektur bedeutet also, zu bestimmen, welche Steuergeräte oder sonstige Recheneinheiten und dergleichen in welcher Art zueinander angeordnet und verbunden werden. Dabei geht es z.B. darum, welche Steuergeräte gemeinsam oder getrennt mit elektrischer Energie versorgt werden, welche Steuergeräte in Kommunikationsverbindung stehen, und auch wie, also z.B. über welche Art von Kommunikationsverbindung (z.B. LIN, CAN, Flexray, Ethernet). Allgemein kann also die Einbindung der Steuergeräte und/oder Sensoren - oder allgemein von Recheneinheiten - in ein Bordnetz (elektrisches- und/oder Datenbordnetz) des Fahrzeugs umfasst sein. Auch können ggf. Gateways (zur Kommunikation) an bestimmten Positionen vorgesehen werden.
-
Wie schon erwähnt, sind E/E-Architekturen für moderne Fahrzeuge, insbesondere autonom fahrende Fahrzeuge, aufgrund der hohen Anzahl der Recheneinheiten wie z.B. Steuergeräte und/oder Sensoren und der zu berücksichtigenden Kombinationen meist sehr komplex. Insbesondere autonom fahrende Fahrzeuge sollten so selten wie möglich in degradierte Zustände übergehen und sollten im degradierten Zustand immer noch über alle Fähigkeiten verfügen, die erforderlich sind, um eine sichere Stoppposition (sicher) zu erreichen.
-
Aufgrund der Vielzahl von möglichen Fehlerkombinationen, die beim Betrieb eines Fahrzeugs mit vielen Recheneinheiten auftreten können, ist es nicht immer möglich, innerhalb einer vorgegebenen Projektzeit eine E/E-Architektur zu erstellen, die die Anzahl von Fehlern, die den Ausfall mehrerer Recheneinheiten zur Folge haben (sog. ‚common cause‘-Fehler), minimal oder zumindest gering zu halten, und bei der (möglichst) wenige und sinnvolle Übergänge in einen degradierten Zustand (Degradationszustand) auftreten.
-
Im Rahmen der Erfindung wird eine Möglichkeit vorgeschlagen, besonders schnell eine E/E-Architektur für ein Fahrzeug zu bestimmen bzw. zu finden, die hinsichtlich der bzw. in Bezug auf die Degradationszustände optimiert ist.
-
Dabei wird von mehreren Domänen und mehreren Recheneinheiten, insbesondere Steuergeräten und/oder Sensoren, des Fahrzeugs ausgegangen; ggf. können die Domänen auch zunächst bestimmt werden. Die mehreren Domänen sind z.B. Lenkung, Bremsen, Umfelderfassung (z.B. Erfassung der Umgebung des Fahrzeugs mittels Sensoren) sowie Trajektorienberechnung (z.B. Berechnung von Fahrstrecken, insbesondere bei autonom fahrenden Fahrzeugen). Insbesondere bei autonom fahrenden Fahrzeugen sind dabei solche Domänen relevant, die für ein sicheres Fahren nötig sind; diese sind z.B. die eben erwähnten. Allerdings können natürlich weitere Domänen einbezogen werden.
-
Es folgt dann ein Zuordnen von Funktionalitäten der Domänen zu den Recheneinheiten, die die Funktionalitäten implementieren sollen. So kann z.B. die Funktionalität ‚Betätigen der Vorderradbremsen‘, welche zur Domäne ‚Bremsen‘ gehört, im Steuergerät ‚ESP‘ implementiert sein. Dann wird diese Funktionalität dem Steuergerät ‚ESP‘ zugeordnet. Es sei jedoch erwähnt, dass eine Funktionalität auch in verschiedenen Recheneinheiten implementiert sein kann. Vorzugsweise wird für wenigstens eine der mehreren Domänen also auch eine redundante Implementierung einer Funktionalität der Domäne bestimmt, oder es wird ggf. zunächst entschieden, ob dies erwünscht ist. Z.B. kann entschieden werden, ob die Funktionalität ‚Betätigen der Vorderradbremsen‘ in zwei oder ggf. mehr verschiedenen Steuergeräten implementiert werden sollte oder ist. Das Vorsehen solcher Redundanzen kann insbesondere in Abhängigkeit vom Automatisierungsgrad des Fahrzeugs, von Sicherheitszielen beim Fahrzeug oder auch standardmäßigen Verwendungen erfolgen.
-
Es wird dann eine initiale E/E-Architektur mit den mehreren Recheneinheiten bestimmt. Dies kann z.B. das Bestimmen einer Einbindung der mehreren Recheneinheiten in ein Bordnetz des Fahrzeugs, das Bestimmen von Kommunikationsverbindungen zwischen den mehreren Recheneinheiten, und das Bestimmen von Positionen von Gateways in der E/E-Architektur umfassen. Hierbei kommt es zunächst insbesondere nur darauf an, eine grundsätzlich funktionsfähige E/E-Architektur zu finden, vorzugsweise (noch) ohne besondere Berücksichtigung von Wechselwirkungen zwischen den Recheneinheiten oder Einflüssen auf Degradationszustände.
-
Weiterhin werden dann Verfügbarkeitszustände für jede der mehreren Domänen bestimmt, und zwar in Abhängigkeit von zumindest einer Verfügbarkeit eines jeden der mehreren Steuergeräte. Die Verfügbarkeitszustände können für jede der mehreren Domänen z.B. die Zustände ‚verfügbar‘, ‚teilweise verfügbar‘ (bzw. ‚eingeschränkt verfügbar‘), und ‚nicht verfügbar‘ umfassen. Hierzu ist anzumerken, dass Steuergeräte Aktoren für die Ausführung einer Funktionalität typischerweise direkt ansteuern und bei einem etwaigen Ausfall eines Aktors entsprechend einen eingeschränkten Verfügbarkeitszustand ausgegeben können.
-
Die Verfügbarkeitszustände können außerdem z.B. in Abhängigkeit von einer Verfügbarkeit eines Bordnetzes des Fahrzeugs, sowie einer Verfügbarkeit von Kommunikationsverbindungen zwischen den mehreren Recheneinheiten bestimmt werden. Die Verfügbarkeit einer Recheneinheit kann wiederum basierend auf deren Gesundheitszustand (‚health state‘) angegeben werden. In einem einfachen Beispiel kann der Gesundheitszustand entweder „funktionsfähig‟ (z.B. logisch 1) oder ‚nicht funktionsfähig‘ (logisch 0) sein. Wenn der Gesundheitszustand einer Recheneinheit ‚funktionsfähig‘ ist, ist diese Recheneinheit z.B. verfügbar, sie kann also ihre Funktionalitäten bereitstellen.
-
Die Verfügbarkeit der Recheneinheiten hat dann wiederum Auswirkung auf die Verfügbarkeitszustände der Domänen. Wenn z.B. eine von drei Recheneinheiten, die einer bestimmten Domäne angehören, nicht verfügbar bzw. ‚nicht funktionsfähig‘ ist, so wird diese Domäne nicht den Verfügbarkeitszustand ‚verfügbar‘ haben können, aber z.B. ‚teilweise verfügbar‘. Wenn eine bestimmte Funktionalität wie ‚Betätigung der Vorderradbremse‘ nicht mehr verfügbar ist, die Funktionalität ‚Betätigung der Hinterradbremse‘ aber schon noch, dann hat z.B. die Domäne ‚Bremsen‘ den Verfügbarkeitszustand ‚teilweise verfügbar‘. Wenn hingegen auch die Funktionalität ‚Betätigung der Hinterradbremse‘ nicht mehr verfügbar ist, wird die Domäne ‚Bremsen‘ den Verfügbarkeitszustand ‚nicht verfügbar‘ haben oder haben müssen. Auf diese Weise haben die Verfügbarkeiten der einzelnen Recheneinheiten Einfluss auf die Verfügbarkeitszustände der Domänen.
-
Eine beispielhafte Festlegung der Verfügbarkeitszustände kann wie folgt sein: „verfügbar‟ (oder „voll verfügbar‟), wenn alle Komponenten bzw. Recheneinheiten, die die eine Funktionalität dieser Domäne implementieren, sich in einem fehlerfreien Gesundheitszustand befindet oder jede Recheneinheit etwaige vorhandene Fehler intern behandeln kann (wenn also keine Systemreaktion erforderlich ist);
„teilweise verfügbar‟, wenn eine ausreichende Anzahl an Recheneinheiten bzw. Komponenten vorhanden ist, um das Fahren mit Einschränkungen zu gewährleisten (z.B. wenn die Steuergeräte für bei Lenk-/Brems-/Rechensystem ‚funktionsfähig‘ sind, manche Sensoren aber ausgefallen sind); ‚nicht verfügbar‘, wenn gar keine Steuergeräte verfügbar sind, die diese Funktionalitäten der Domäne implementieren (oder alle im Fehlerzustand sind).
-
Es folgt dann das Bestimmen von Degradationszuständen des Fahrzeugs, die in Abhängigkeit von den Verfügbarkeitszuständen der mehreren Domänen einzunehmen sind. Mit anderen Worten wird bestimmt, in welchen Degradationszustand (oder Rückfallmodus) übergangen werden soll, wenn z.B. der Verfügbarkeitszustand einer Domäne nicht mehr auf ‚verfügbar‘ ist.
-
Beispielsweise kann ein Degradationszustand sein: Halte am Straßenrand in einer sicheren Halteposition. Dieser soll eingenommen werden, wenn eine Domäne wie ‚Lenken‘ oder ‚Bremsen‘ nur noch ‚teilweise verfügbar‘ ist. Ein anderer Degradationszustand kann sein: Stoppe sofort in der eigenen Fahrspur. Dieser soll z.B. eingenommen werden, wenn eine Domäne ‚nicht verfügbar‘ ist oder wenn mehrerer Domänen wie ‚Lenken‘ oder ‚Bremsen‘ nur noch ‚teilweise verfügbar‘ sind.
-
Daraufhin werden für jeden der Degradationszustände mögliche Verfügbarkeitszustände für jede der mehreren Domänen bestimmt, d.h. es wird für jeden Degradationszustand, wenn dieser eingenommen würde, bestimmt, welche Domänen dann noch ‚verfügbar‘ oder zumindest ‚teilweise verfügbar‘ sind, oder welche ‚nicht verfügbar‘ sind.
-
Wie bereits erwähnt, werden die Domänen bzw. deren Funktionalitäten durch bestimmte Recheneinheiten implementiert. Die Systemreaktion im eingenommenen Degradationszustand (Degradationsansatz) wird also auf Recheneinheiten abgebildet, die im Degradationszustand noch verfügbar sind. Dabei ist bekannt, welche Recheneinheiten zur Umsetzung eines Degradationsansatzes bzw. zur Einnahme eines Degradationszustands benötigt werden. Damit kann z.B. ein Degradationsansatz ‚Letzten Lenkwinkel halten und bremsen‘ ermöglicht werden, wenn mindestens ein Bremssystem und ein Lenksystem vorhanden sind.
-
Es folgt dann ein Optimieren der initialen E/E-Architektur durch Variieren der E/E-Architektur, um eine in Bezug auf die Degradationszustände optimierte E/E-Architektur zu erhalten. Dies kann z.B. in Bezug auf eine möglichst geringe Anzahl an Degradationszuständen, die einzunehmen sind, sowie für die beste bzw. bestmögliche Systemreaktion im Degradationszustand optimiert werden, d.h. es sollen Degradationszustände erhalten werden, die einen möglichst geringen Einfluss auf das Fahrverhalten des Fahrzeugs haben.
-
Beim Optimieren der initialen E/E-Architektur auf eine möglichst geringe Anzahl an Degradationszuständen, die einzunehmen sind, können z.B. die Gesundheitszustände, die zunächst alle auf „funktionsfähig‟ (logisch 1) initialisiert werden können, nacheinander (einzeln) auf ‚nicht funktionsfähig‘ (logisch 0) gesetzt werden, werden die jeweils anderen auf ‚funktionsfähig‘ verbleiben. Dies zeigt die Auswirkungen des einzelnen Fehlers einer Recheneinheit auf die Domänen und deren Verfügbarkeitszustände und identifiziert mögliche (einzelne) Fehler, die den Ausfall mehrerer Recheneinheiten zur Folge haben (‚common cause‘-Fehler). Insbesondere kann es wichtig sein zu prüfen, ob ein solcher Fehler, also eine gemeinsame Ursache für mehrere Ausfälle, zum vollständigen Verlust einer Domäne (d.h. zu Verfügbarkeitszustand ‚nicht verfügbar‘) führt. Typischerweise können in E/E-Architekturen gemeinsame Fehler auftreten aufgrund von suboptimaler Zuordnung von Recheneinheiten zum bzw. Einordnung in das Bordnetz, ungenügender Bus-Kommunikation (z.B. ist Steuergerät an nur einem Kommunikationsbus angeschlossen, wobei mehrere notwendig wären; oder es ist an einen falschen Kommunikationsbus angeschlossen), sowie aufgrund der Nutzung von Gateways.
-
Wenn die Änderung eines der Gesundheitszustände zu einer Nichtverfügbarkeit oder einem Ausfall einer der Domänen geführt hat, kann derjenige Teil der E/E-Architektur (näher) überprüft werden, der diese Domäne bzw. die ihr zugeordneten Recheneinheiten enthält, und die erforderlichen Änderungen können an der E/E-Architektur vorgenommen werden. So kann z.B. für ein Bordnetz geprüft werden, welche Recheneinheiten daran angeschlossen sind und die Recheneinheiten können neu zugeordnet werden. Es kann auch die Logik bei der Bestimmung der Verfügbarkeitszustände geändert werden, und es können die Auswirkungen davon auf die Systemdegradation geprüft werden (Ziel ist es, die Anzahl der häufigen Ursachen bzw. Fehler und Degradationszustände zu reduzieren). Die Änderung der Logik beschreibt grundsätzlich notwendige Änderungen der E/E-Architektur.
-
Beim Optimieren der initialen E/E-Architektur auf Degradationszustände, die einen möglichst geringen Einfluss auf das Fahrverhalten des Fahrzeugs haben, können die Systemreaktion im eingenommenen Degradationszustand auf dabei noch verfügbare Recheneinheiten abgebildet werden. Durch Änderung bzw. Variation der Gesundheitszustände kann analysiert werden, welche Kombinationen zu den schlechtesten Degradationszuständen bzw. Degradationsansätzen führen; durch Änderung der Logik und damit der E/E-Architektur kann dies optimiert werden. So ist z.B. ein Halt am Straßenrand in einer sicheren Halteposition möglich, wenn das ESP und eines der Lenksysteme verfügbar sind, ebenso ist z.B. der Halt am Straßenrand in einer sicheren Halteposition möglich, wenn eines der Bremssysteme und eines der Lenksysteme verfügbar sind. Außerdem ist z.B. ein sofortiges Stoppen (Anhalten) in der eigenen Fahrspur möglich, wenn mindestens eines der Bremssysteme verfügbar ist.
-
Auf diese Weise kann, insbesondere automatisiert, besonders schnell und einfach eine E/E-Architektur für ein Fahrzeug bestimmt oder gefunden werden, die zu möglichst wenig oder wenig einschränkenden Degradationszuständen führt.
-
Ein erfindungsgemäßes Rechensystem, z.B. ein Computer, ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen.
-
Die Erfindung betrifft außerdem ein Fahrzeug, insbesondere ein autonom fahrendes Fahrzeug, mit einer E/E-Architektur, die mit einem erfindungsgemäßen Verfahren bestimmt worden ist.
-
Auch die Implementierung eines erfindungsgemäßen Verfahrens in Form eines Computerprogramms oder Computerprogrammprodukts mit Programmcode zur Durchführung aller Verfahrensschritte ist vorteilhaft, da dies besonders geringe Kosten verursacht, insbesondere wenn ein ausführendes Steuergerät noch für weitere Aufgaben genutzt wird und daher ohnehin vorhanden ist. Schließlich ist ein maschinenlesbares Speichermedium vorgesehen mit einem darauf gespeicherten Computerprogramm wie oben beschrieben. Geeignete Speichermedien bzw. Datenträger zur Bereitstellung des Computerprogramms sind insbesondere magnetische, optische und elektrische Speicher, wie z.B. Festplatten, Flash-Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) ist möglich. Ein solcher Download kann dabei drahtgebunden bzw. kabelgebunden oder drahtlos (z.B. über ein WLAN-Netz, eine 3G-, 4G-, 5G- oder 6G-Verbindung, etc.) erfolgen.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
-
Die Erfindung ist anhand eines Ausführungsbeispiels in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben.
-
Kurze Beschreibung der Zeichnungen
-
- 1 zeigt schematisch ein Fahrzeug mit einer E/E-Architektur, die mit einem erfindungsgemäßen Verfahren in einer bevorzugten Ausführungsform bestimmbar ist.
- 2 zeigt schematisch einen Ablauf eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform.
-
Ausführungsform(en) der Erfindung
-
In 1 ist schematisch ein Fahrzeug 100 mit einer E/E-Architektur 102 dargestellt, die mit einem erfindungsgemäßen Verfahren in einer bevorzugten Ausführungsform bestimmbar ist. Ein Ablauf eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform ist in 2 gezeigt. Beide Figuren sollen nachfolgend übergreifend beschrieben werden.
-
Das Fahrzeug 100 soll beispielhaft verschiedene Recheneinheiten aufweisen. Eine als ESP-Steuergerät ausgebildete Recheneinheit 110 ist vorgesehen, um Bremsaktoren 111 und 112 für die Vorderachse und 113 und 114 für die Hinterachse anzusteuern. Denkbar ist, dass die Bremsaktoren für Vorder- und Hinterachse zwar von einem gemeinsamen ESP-Steuergerät angesteuert werden, allerdings mit getrennten Endstufen.
-
Eine als Lenkungssteuergerät ausgebildete Recheneinheit 120 ist vorgesehen, um einen Lenkaktor 121 für die Vorderachse bzw. die Vorderräder anzusteuern. Eine als Umfelderfassungssteuergerät ausgebildete Recheneinheit 130 ist vorgesehen, um Informationen von beispielhaft vier Kameras oder anderen Umfelderfassungssensoren 131, 132, 133 und 134 zu erhalten und damit die Umgebung zu erkennen.
-
Weiterhin soll für das Fahrzeug eine Batterie 150 zur Strom- bzw. Energieversorgung eines Bordnetzes 151 vorgesehen sein, sowie ein Bus- oder Kommunikationssystem 141, in dem z.B. auch ein Gateway 140 vorgesehen sein kann.
-
Das Fahrzeug 100 soll mehrere Domänen aufweisen, die verschiedene Fahrzeugfunktionalitäten repräsentieren. Beispielhaft sollen dies die Domänen Bremsen 104, Lenkung 105 und Umfelderfassung 106 sein. Denkbar wäre z.B. auch noch eine Domäne Trajektorienberechnung. Diese Domänen können z.B. zunächst in einem Schritt 200 bestimmt werden, d.h. es kann z.B. geprüft werden, welche Domänen das Fahrzeug haben soll, um ein ordnungsgemäßes autonomes Fahren zu ermöglichen.
-
Zur Bestimmung einer finalen bzw. optimierten E/E-Architektur, z.B. unter Verwendung eines Rechensystems 190, kann dann, in einem Schritt 210, ein Zuordnen von Funktionalitäten 212 der Domänen 104, 105, 106 zu den Recheneinheiten, die die Funktionalitäten implementieren sollen, erfolgen. Im Beispiel der
1 kann z.B. eine Funktionalität ‚Betätigen der Vorderradbremsen‘ sowie die Funktionalität ‚Betätigen der Hinterradbremsen‘ der Domäne ‚Bremsen‘ 104 dem ESP-Steuergerät zugeordnet werden. Dies ist beispielhaft nachfolgend dargestellt.
| Domäne | Funktionalität 212 | Steuergerät |
| Lenkung | Lenkung linkes Rad | Lenkungssteuergerät |
| Lenkung | Lenkung rechtes Rad | Lenkungssteuergerät |
| Bremsen | Betätigen der Vorderradbremsen | ESP |
| Bremsen | Betätigen der Hinterradbremsen | ESP |
| Umfelderfassung | Umfelderfassung vorne | Umfelderfassungssteuergerät |
| Umfelderfassung | Umfelderfassung hinten | Umfelderfassungssteuergerät |
-
In einem Schritt 220 folgt dann ein Bestimmen einer initialen E/E-Architektur mit den mehreren Recheneinheiten, also z.B. die in 1 gezeigte E/E-Architektur.
-
Dies kann z.B. das Bestimmen einer Einbindung der Steuergeräte 110, 120, 130 sowie ggf. der Sensoren 131 bis 134 in das Bordnetz 150 des Fahrzeugs umfassen, also insbesondere zu Energieversorgung. Dies kann auch das Bestimmen bzw. Festlegen von Kommunikationsverbindungen 141 zwischen den mehreren Steuergeräten bzw. Sensoren, sowie das Bestimmen der Position z.B. des Gateways 140 (sowie auch die Prüfung und Einbindung ggf. weiterer Gateways) in der E/E-Architektur umfassen.
-
Zum Bestimmen von Verfügbarkeitszuständen für jede der mehreren Domänen kann zunächst, in einem Schritt 224, eine Initialisierung der Gesundheitszustände der Steuergeräte mit ‚funktionsfähig‘ bzw. logisch 1 erfolgen, wie nachfolgend gezeigt:
| Domäne | Steuergerät | Gesundheitszustand |
| Lenkung | Lenkungssteuergerät | 1 |
| Bremsen | ESP | 1 |
| Umfelderfassung | Umfelderfassungssteuergerät | 1 |
-
Die Verfügbarkeit der Recheneinheiten bzw. Steuergerät hängt von deren Gesundheitszustand ab und hat dann wiederum Auswirkung auf die Verfügbarkeitszustände der Domänen. Wenn z.B. eine von drei Recheneinheiten, die einer bestimmten Domäne angehören, nicht verfügbar bzw. ‚nicht funktionsfähig‘ (logisch 0) ist, so wird diese Domäne nicht den Verfügbarkeitszustand ‚verfügbar‘ haben können, aber z.B. ‚teilweise verfügbar‘.
-
Weiterhin kann dann, in einem Schritt 230, ein Bestimmen der Verfügbarkeitszustände 232 für jede der mehreren Domänen 104, 105, 106 in Abhängigkeit von zumindest einer Verfügbarkeit eines jeden der mehreren Steuergeräte 110, 120, 130, ggf. auch der Sensoren 131 bis 134, erfolgen. Dies kann basierend auf dessen Gesundheitszustand erfolgen, wie nachfolgend beispielhaft gezeigt:
| Verfügbarkeitszustand 232 | Gesundheitszustand Recheneinheit | Verfügbarkeit Bordnetz | Verfügbarkeit Komm. | Wert |
| Lenkung ‚verfügbar‘ | 1 | 1 | 1 | 1 |
| Lenkung ‚teilweise verfügbar‘ | 0 | 0 | 0 | 0 |
| Lenkung ‚nicht verfügbar‘ | 0 | 0 | 0 | 0 |
| Bremsen ‚verfügbar‘ | 1 | 1 | 1 | 1 |
| Bremsen ‚teilweise verfügbar‘ | 0 | 0 | 0 | 0 |
| Bremsen „nicht verfügbar‟ | 0 | 0 | 0 | 0 |
| Umfelderfassung ‚verfügbar‘ | 1 | 1 | 1 | 1 |
| Umfelderfassung ‚teilweise verfügbar‘ | 0 | 0 | 0 | 0 |
| Umfelderfassung ‚nicht verfügbar‘ | 0 | 0 | 0 | 0 |
-
Wenn also z.B. das ESP-Steuergerät ‚funktionsfähig‘ (Gesundheitszustand auf logisch 1), das Bordnetz ‚verfügbar‘ ist (logisch 1) und die Kommunikation ‚verfügbar‘ ist (logisch 1), kann der Verfügbarkeitszustand der Domäne Bremsen auf ‚verfügbar‘ (Wert logisch 1 in der betreffenden Zeile) gesetzt werden. Wenn z.B. das ESP-Steuergerät ‚nicht funktionsfähig‘ (Gesundheitszustand auf logisch 0) wäre, müsste auch der Verfügbarkeitszustand der Domäne Bremsen auf ‚nicht verfügbar‘ oder ggf. ‚teilweise verfügbar‘ gesetzt werden.
-
Als nächstes kann dann, in einem Schritt 240, ein Bestimmen von Degradationszuständen 242, 244 des Fahrzeugs erfolgen, die in Abhängigkeit von den Verfügbarkeitszuständen 232 der mehreren Domänen einzunehmen sind. In einem Schritt 250 kann dann ein Bestimmen, für jeden der Degradationszustände, von möglichen Verfügbarkeitszuständen für jede der mehreren Domänen, erfolgen.
-
Beispielhaft sind nachfolgend zwei Degradationszustände ‚Halt am Straßenrand in einer sicheren Halteposition‘ 242 und ‚sofortiges Stoppen (Anhalten) in der eigenen Fahrspur‘ 244 gezeigt, deren Einnehmen von den Verfügbarkeitszuständen 232 der mehreren Domänen abhängt. Dabei soll der betreffende Degradationszustand dann einzunehmen sein, wenn die betreffenden Verfügbarkeitszustände vorliegen (mit logisch 1 bezeichnet).
| Verfügbarkeitszustand 232 | 242 | 244 |
| Lenkung ‚verfügbar‘ | 1 | 0 |
| Lenkung ‚teilweise verfügbar‘ | 0 | 0 |
| Lenkung ‚nicht verfügbar‘ | 0 | 1 |
| Bremsen ‚verfügbar‘ | 1 | 1 |
| Bremsen ‚teilweise verfügbar‘ | 1 | 1 |
| Bremsen „nicht verfügbar‟ | 0 | 0 |
| Umfelderfassung ‚verfügbar‘ | 1 | - |
| Umfelderfassung ‚teilweise verfügbar‘ | 1 | - |
| Umfelderfassung ‚nicht verfügbar‘ | 0 | - |
-
Anhand obiger Tabelle ist z.B. zu sehen, dass der Degradationszustand 242 nur dann eingenommen werden kann, wenn die Lenkung ‚verfügbar‘ ist. Wenn die Lenkung nur noch ‚teilweise verfügbar‘ oder ‚nicht verfügbar‘ ist, kann dieser Degradationszustand nicht eingenommen werden, da nicht mehr zur Seite gefahren werden kann. Hingegen kann der Degradationszustand 244 noch eingenommen werden, wenn die Lenkung ‚nicht verfügbar‘ ist. Der Verfügbarkeitszustand der Umfelderfassung ist für den Degradationszustand 244 z.B. irrelevant.
-
Es folgt dann, in einem Schritt 260, ein Optimieren der initialen E/E-Architektur durch Variieren der E/E-Architektur, um eine in Bezug auf die Degradationszustände optimierte E/E-Architektur zu erhalten. Dies kann z.B. in Bezug auf eine möglichst geringe Anzahl an Degradationszuständen erfolgen, die einzunehmen sind, sowie für die beste bzw. bestmögliche Systemreaktion im Degradationszustand, d.h. es sollen Degradationszustände erhalten werden, die einen möglichst geringen Einfluss auf das Fahrverhalten des Fahrzeugs haben.
-
Anhand der obigen Erläuterungen ist ersichtlich, dass durch Variation der E/E-Architektur die Änderung des Gesundheitszustands einer Recheneinheit andere Auswirkungen auf die einzelnen Verfügbarkeitszustände und damit auf die Degradationszustände hat oder zumindest haben kann.
