Architekturen und Degradationsmechanismen für verlässliches Verhalten im Fehlerfall

Auf alles vorbereitet sein

7. Juli 2015, 10:01 Uhr | Von Rudolf Grave und Alexander Much
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Funktionen über Steuergerätegrenzen verteilen

In der nächsten Generation der Fail-Operational-Steuergeräte wird die Ersatzfunktion nicht mehr auf dem gleichen Steuergerät integriert sein, sondern auf einem anderen Steuergerät im Netzwerk. Diese Architektur ermöglicht eine Funktionsmigration im Fall eines Hardware-Fehlers auf dem primären Steuergerät. Um redundante Aktuatoren und Sensoren auf jedem Steuergerät zu vermeiden, müssen qualifizierte Signale entweder durch intelligente Sensoren oder durch andere Steuergeräte auf den Datenbus gelegt werden. Aktuell wird beispielsweise die Fahrzeuggeschwindigkeit von verschiedenen Steuergeräten im Fahrzeug bereitgestellt.

Beispiel einer Fail-operational-Architektur über zwei Steuergeräte
Bild 4. Beispiel einer Fail-operational-Architektur über zwei Steuergeräte.
© Elektrobit

Bild 4 zeigt eine realisierbare Architektur. Die Funktion 1 ist im normalen Zustand auf Steuergerät 1 aktiv. Im Fehlerfall soll die Funktion auf Steuergerät 2 migriert werden. Je nachdem, ob sie im Cold oder Hot Standby läuft, müssen Partitionen gestartet werden. Im Bedarfsfall lassen sich weniger wichtige Funktionen, beispielsweise Funktion 4, abschalten. Das ermöglicht eine effiziente Ressourcennutzung, ohne Rechenleistung vorhalten zu müssen.

Zur Funktionsmigration zwischen den Steuergeräten gehört neben der eigenen Zustandsüberwachung die Beobachtung des Ersatzsteuergerätes. Das ist die Aufgabe des FailOp Manager. Die Herausforderungen bei diesem Design werden sein, eine schnelle Erkennung und Umschaltung sicherzustellen sowie zwei parallel aktive Funktionen (Split Brain) zu vermeiden.

 

Kasten: Luftfahrttaugliches Betriebssystem 

Embedded Office, Spezialist für Embedded-Systeme mit Schwerpunkt auf sicherheitskritischen Anwendungen, nimmt mit weiteren Partnern aus Industrie und Wissenschaft an dem vom Bundesministerium für Wirtschaft und Technologie (BMWi) geförderten vierten zivilen Luftfahrtforschungsprogramm (LUFO IV.4) teil. Dieses Forschungsprojekt soll die technologische Basis der Luftfahrtforschung in Deutschland festigen. Ziel des Projekts ist es, eine europäische Lösung eines zertifizierten Echtzeit-Betriebssystems für die Luftfahrtbranche zu finden, das für kleine und mittelständische Unternehmen finanziell tragbar und im Leistungsumfang attraktiv ist.

In Zusammenarbeit sollen die Projektpartner das Echtzeit-Betriebssystem in einem realistischen Anwendungsumfeld erproben und auswerten. Aufgabe von Embedded Office war es, das Echtzeit-Betriebssystem und das zugehörige Board Support Package (BSP) an die verwendeten Hardware-Plattformen anzupassen und das Software-Framework dafür zu erstellen und damit die Grundlage für den kommerziellen Einsatz zu legen.

Als Echtzeit-Betriebssystem diente der Echtzeitkernel µC/OS-II mit einer Partitionierungs-Erweiterung. Dieses System wurde schon bei verschiedenen Luftfahrtherstellern eingesetzt und zertifiziert. Als Hardware-Plattformen standen die Anwendungsprozessoren der i.IMX6-Serie von Freescale, PowerPC-Architekturen sowie die STM32-Mikrocon­troller von STMicroelectronis zur Verfügung. Für das BSP hat Embedded Office eine Software-Lifecycle-Dokumentation nach Luftfahrtstandard DO-178B/C erstellt und es in ein Safety-BSP überführt.  

Embedded Office GmbH & Co. KG www.embedded-office.de


 

Autonomes Fahren im Blick

Die aktuellen Fail-Safe-Architekturen ermöglichen nur teilautonomes Fahren. Im Fehlerfall erfordern sie menschliche Aufmerksamkeit und der Autofahrer ist nach wie vor Teil des Fahrzeugbetriebes. Durch die Kombination etablierter Konzepte aus anderen Branchen mit Automotive-Standards wie AUTOSAR lassen sich jedoch Lösungen finden, um hochverfügbare Steuergeräte zu entwickeln. Elektrobits Erfahrung aus einer Vielzahl von Projekten aus verschiedenen Domänen wie Fahrerassistenzsystemen, kombiniert mit Produkten wie EB tresos Safety OS, bilden die Basis dafür, ohne auf die Kompatibilität mit Standards wie AUTOSAR zu verzichten. Nur solche Steuergeräte werden den Grundstein für autonomes Fahren bilden können, weil sie eigenständig auf Fehler reagieren und einen Weiterbetrieb der Systeme ermöglichen.

 

Die Autoren

 

Dipl.-Ing. Rudolf Grave
 
studierte Elektrotechnik an der TU Hamburg-Harburg. Seit 2005 arbeitet er bei Elektrobit Automotive und betreut AUTOSAR-Projekte. Der Schwerpunkt liegt dabei auf den Themengebieten Multicore und funktionale Sicherheit.

rudolf.grave@elektrobit.com


Dipl.-Math. ­ Alexander Much
 
studierte Mathematik an den Universitäten Erlangen und Cambridge. Er arbeitete bei SuSE Linux als Entwickler und arbeitet seit 2004 bei der Elektrobit Automotive GmbH in Erlangen. Er ist SPICE Assessor, Safety Manager und ist bei EB zuständig für das Safety und Systems Engineering. 

alexander.much@elektrobit.com



  1. Auf alles vorbereitet sein
  2. Funktionen über Steuergerätegrenzen verteilen

Lesen Sie mehr zum Thema


Das könnte Sie auch interessieren

Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Elektrobit Automotive GmbH

Weitere Artikel zu Fahrzeugkomponenten

Weitere Artikel zu Funktionale Sicherheit/Safety