(R)Evolution der Automotive-Software-Architekturen

Seite: 3/4

Firmen zum Thema

Beispiel Verkehrsschildererkennung

Als Beispiel für eine Service-orientierte Kommunikation nehmen wir die automatische Schildererkennung. Wir gehen davon aus, dass eine im Fahrzeug vorhandene Kamera die Verkehrssituation und mit ihr auch Verkehrszeichen aufnimmt. Die Software im Fahrzeug detektiert und erkennt die Verkehrsschilder und stellt diese im Navigationsdisplay dar. Möglicherweise wird der Fahrer informiert, falls seine aktuelle Geschwindigkeit zu hoch ist.

Gehen wir nun davon aus, dass aus irgendeinem Grund (verschmutzte Kamera, technischer Defekt der Kamera, etc.) die Schilderinformation nicht mehr zur Verfügung steht. Anstatt nun keine Information in der Anzeige mehr bereitzustellen, können über eine Service-orientierte Architektur anstelle der fehlenden Kamerainformation, die Daten von einem Cloud-Dienst die lokalen Schilderinformationen bereitgestellt werden. Diese sind sicherlich von geringerer Qualität, da die Schilderinformation nicht überall tagesaktuell vorliegen. Selbst wenn die Verbindung zur Cloud nun zusammenbricht, besteht die Möglichkeit statische Schilderinformation von dem im Fahrzeug lokal vorhandenen Navigationssystem zu verwenden.

Bildergalerie
Bildergalerie mit 7 Bildern

Software-Architekturen, die auf Quality-of-Service Ansätzen aufbauen, sind für solche Lösungen wesentlich flexibler aufgestellt, da die Funktionen nicht mehr berücksichtigen müssen, aus welcher Quelle (auch nicht von welchem Rechner im Fahrzeug) die Daten stammen. Lediglich die Qualität der Daten muss berücksichtigt werden. Damit werden diese Funktionen auch leichter auf andere Rechner im Fahrzeug verschiebbar.

Eine wesentliche Rolle spielt in diesem Zusammenhang der sich aktuell in der Entwicklung befindliche Standard AUTOSAR Adaptive, der Standards für Schnittstellen für Mikroprozessor basierte Basis Software festlegt, die in Anwendungen mit besonderen Anforderungen bzgl. Funktionaler Sicherheit (ISO26262 mit zugehörigen ASIL Level) zum Einsatz kommen.

Einflüsse von Fremdsoftware auf die Basis-Software

In den vorhergehenden Abschnitten sind wir auf einen wesentlichen Aspekt der Software für zukünftige Fahrzeugrechner noch nicht eingegangen. Wer erstellt eigentlich die Software für die Mikroprozessor basierten Fahrzeugrechner? Wie bereits oben erwähnt steigt der Umfang der in den Fahrzeugrechnern realisierten Software um mehrere Zehnerpotenzen den Umfang der Mikrocontroller-Software.

Bei letzterer entwickelt in der Regel der Tier-1-Zulieferer die Software für die entsprechende Hardware. Dabei kommen auch zugekaufte Teile wie Automotive-spezifische Realzeit Betriebssysteme und Basis Software Stacks (z.B. AUTOSAR für Mikrocontroller) zum Einsatz. Auch OEMs stellen eigenen Funktionalitäten bei, die in die finale Software integriert werden. Im Prinzip gilt hierbei, dass alle Softwareanteile direkt aus der Automobilindustrie und ihren Zulieferern stammen und somit mit den besonderen Anforderungen bzgl. Funktionaler Sicherheit vertraut sind.

Große Zulieferer, wie Bosch, sind zudem in der Lage Komplettsysteme aus einer Hand zu entwickeln und zu liefern, also mit einer Entwicklungstiefe von 100 Prozent: das Realzeitbetriebssystem von der Bosch-Tochter ETAS, die Basis Software als In-house-Lösung einer Querschnittsabteilung für Software und die Anwendungssoftware durch den beauftragten Geschäftsbereich. Diese Situation ändert sich grundlegend beim Einsatz von Mikroprozessoren. Zum einen werden POSIX-konforme Betriebssysteme eingesetzt, die nicht durch deterministische Realzeitbetriebssysteme realisiert werden.

Des Weiteren werden auf Fahrzeugrechnern Hypervisor verwendet, um Virtualisierungsansätze zur Separierung von Anwendungen mit unterschiedlichen ASIL Level auf einem Rechner zu ermöglichen. Sowohl die POSIX-Betriebssysteme als auch die Hypervisor kommen nicht von klassischen Automobilzulieferern. Das Marktsegment dieser Software-Arten befindet sich aktuell in rasanter Entwicklung. Umso wichtiger ist es, dass die auf diesen Systemen aufbauenden Automotive-spezifischen Lösungen ausreichend gekapselt werden. Eine durchgängige Schichtenarchitektur für Fahrzeugrechner-Software wird zwingend erforderlich.

Bild 4 (siehe Bildergalerie) zeigt die Schichtenarchitektur des sogenannten Vehicle Run Time Environment (VRTE), welches in zukünftigen Fahrzeugrechnern verwendet wird. Die fünf Ebenen des VRTE stellen sukzessive Kapselungen

  • der Hardware-abhängigen Kapselungen
  • der Betriebssystem-spezifischen Software
  • der verwendeten Kommunikationskanäle (Abstraktion von CAN, FlexRay, Ethernet, etc.)
  • Computerspezifische Dienste (z. B. Rechnerdiagnose) und
  • Fahrzeugspezifische Dienste, die es auf heutigen Mikrocontroller ECUs nicht gibt (z. B. Life-Cycle Management)

Es ist hierbei anzumerken, dass die abgebildete Software keine monolithische Struktur darstellt, sondern ein System aus unterschiedlichen Softwarekomponenten unterschiedlichster Hersteller ist, die in einem gemeinsamen Framework integriert und für die Automobilindustrie seriengehärtet wird. Besondere Herausforderungen ergeben sich dabei für die Software-Integration und deren Absicherung, da neben nicht quelloffenen „3rd Party“ Komponenten auch Open Source Software (z.B. in verwendeten Betriebssystemen) eingesetzt werden müssen. Auch diese Aspekte müssen im Entwurf der Software-Architekturen berücksichtigt werden.

Einflüsse unterschiedlicher Arten von Software

In dem bisher Gesagten wurde stillschweigend davon ausgegangen, dass bei allem Komplexitätszuwachs, den die neuen Fahrzeugrechner mit sich bringen, sich an der eigentlichen Entwicklungsmethodik der Software-Ingenieure und Informatiker nichts ändern wird. Die Realität sieht jedoch völlig anders aus.

Die Software für „Deeply Embedded ECUs“ ist durch die in Bild 5 unten links (siehe Bildergalerie) angegebenen Elemente charakterisiert. Insbesondere ist zu erwähnen, dass die Entwicklungsprozesse stark durch das in der Automobilindustrie etablierte V-Model und Automotive SPICE (ASPICE) geprägt sind.

Mit den Fahrzeugrechnern werden neue Software-Arten eingeführt. Neben Betriebssystem die aus der IT-Welt stammen, kommen andere Programmiersprachen und Programmierparadigmen in die Automobilindustrie. Die klassische Lastenheft-getriebene, V-Model-basierte Entwicklungsmethodik trifft nun auf die agile, durch DevOps getriebene Entwicklungsansätze, die aus dem Umfeld der Internetentwicklungsplattformen kommen. In Bild 5 wird deutlich, dass die Fahrzeugrechner softwareseitig eine deutlich stärkere Überlappung mit den IT-Softwaremethoden besitzen. Zusätzlich drängen zunehmend Anwendungen aus den Smartphone Eco-Systemen ins Fahrzeug (Bild 5 unten rechts).

Zusammen mit dem in Bild 3 dargestelltem Trend zu cross-Domänen Architekturen ergibt sich die Notwendigkeit, Software-Architekturen übergreifend über unterschiedliche Software-Plattformen und Zielsystemen konsistent zu beschreiben und zu pflegen. Hier liegt eine besondere Herausforderung für die Automobilindustrie, deren Produkte im Vergleich zu den schnelllebigen Konsumerprodukten der IT-Welt deutlich längere Lebenszyklen durchlaufen und in der Regel deutlich höhere Anforderungen hinsichtlich Sicherheit erfüllen müssen.

Als Konsequenz des Gesagten ergibt sich, dass die Automobilindustrie eine deutlich größere Anzahl an Informatikern mit einer Vielzahl unterschiedlicher Software-Fähigkeiten benötigt und das zusätzlich zu den bereits vorhandenen Ingenieuren der regelungsbasierten embedded Welt.

(ID:45549478)