(R)Evolution der Automotive-Software-Architekturen

Seite: 4/4

Firmen zum Thema

Bedeutung der Funktionalen Sicherheit und IT Sicherheit

In den vorherigen Abschnitten wurde ein wichtiger Themenkomplex und Architekturtreiber nur am Rande berührt. Die Kombination aus Funktionaler Sicherheit und IT-Sicherheit. (Die englische Sprache unterscheidet den Sicherheitsbegriff deutlich besser durch die Worte Safety und Security.) Die Kombination dieser Anforderungen ist nach unserem Wissen in keinem anderen Industriezweig so ausgeprägt. Selbst in der Luftfahrt als auch im Schienenverkehr stellt sich eine andere Situation dar. In beiden genannten Industriezweigen besitzen nur geschultes Personal (z.B. Piloten, Lokführer, etc.) Zugang zu den zentralen Systemen der Fortbewegungsmittel. Im privaten PKW-Umfeld hat jedoch jeder Autobesitzer im Prinzip den physikalischen Zugang zu den Systemen.

Des Weiteren ergeben sich durch die zunehmenden Connectivity-Lösungen und Cloud-basierten Dienste eine größer werdende Angriffsfläche für Hacker. Hiermit erhöht sich deutlich die Gefahr für einen unberechtigten Zugang in die Computersysteme des Fahrzeuges, die es durch geeignete Security-Maßnahmen abzuwehren gilt.

Bildergalerie
Bildergalerie mit 7 Bildern

Auch die Lösungsansätze zur Funktionalen Sicherheit sehen in der Luftfahrt und Schienenverkehr anders aus als im PKW-Sektor. Aufgrund der vergleichsweise geringen Volumina an Flugzeugen und Schienenfahrzeuge und einem deutlich geringerem Commodity-Druck kommen in den erstgenannten Bereichen teilweise komplett redundante Systeme zum Einsatz. Außerdem werden Flugzeuge und Schienenfahrzeuge mit einer deutlich höheren Frequenz auf mögliche Fehler überprüft als PKW. Diesem Aspekt müssen Software-Architekturen durch entsprechende Safety- und Sicherheits-Konzepte Rechnung tragen.

Bei Fahrzeugrechnern mit Applikationen unterschiedlicher ASIL Level ist eine Separierung bzw. Virtualisierung der Anwendungsdomänen unter Verwendung von Hypervisortechnologien erforderlich. Dabei nimmt der Hypervisor eine zentrale Rolle im Software-System ein, da er die Hoheit über Rechnerressourcen besitzt, deren Allokation zu den unterschiedlichen Anwendungsfunktionen sicherstellt und diese überwacht. Mit dieser zentralen Position des Hypervisors im System ergibt sich eine weitere zentrale Angriffsfläche für Software-Hacker. Aus diesem Grund müssen eingesetzte Hypervisor in besonderem Maße auf potentielle Security-Lücken überprüft werden.

Software-Architekturtreiber und ihre Dokumentation

In den vorhergehenden Abschnitten haben wir eine Reihe von Software-Architekturtreibern beschrieben, die mit der Einführung der Fahrzeugrechner massiv an Bedeutung gewinnen. Mit der steigenden Komplexität und Öffnung der Software-Systeme muss ein viel höheres Gewicht auf wohl durchdachte und mit allen relevanten Stakeholdern abgestimmte Software-Architekturen gelegt werden.

Die Fokussierung auf rein funktionalen Software-Aspekt ist bei weitem nicht ausreichend. Bild 6 gibt eine Übersicht der wesentlichen, domänenunabhängige Architekturtreiber für Mikroprozessor-basierte Fahrzeugrechner.

Im Rahmen des Architekturentwurfes muss sichergestellt werden, dass die nicht-funktionalen Treiber ausreichend berücksichtigt und nachvollziehbar dokumentiert werden. Insbesondere in einem zunehmend heterogenen und komplexer werdenden Software-Umfeld ist ein verstärkter Fokus auf Software-Architekturen von entscheidender Bedeutung. Ein Startpunkt für die den Architekturentwurf bietet der als arc42 bekannte Ansatz, welcher eine Strukturierungshilfe für Software-Architekturen darstellt und folgende Kapitel bzw. Architektursichten umfasst:

1. Einführung und Ziele: Wichtige Einflussfaktoren bzw. Kräfte, die auf die Software-Architektur einwirken. Insbesondere sind die Geschäftsziele zu benennen, die einen wesentlichen Einfluss auf die Software-Architektur haben.

2. Randbedingungen: Technische und organisatorische Randbedingungen, Konventionen, Tools, Stakeholder etc.

3. Kontextabgrenzung: Fachlicher und technischer Kontext, externe Schnittstellen, etc.

4. Lösungsstrategie: Überblick über Architektur-relevante, grundlegende Entscheidungen und Lösungsansätze (z.B. Verwendung zugekaufter Software versus eigener Programmierung).

5. Komponentensicht (Bausteinsicht): Überblicksbild der ersten Ebenen (hierarchisch) des zu entwerfenden Systems, inkl. Zusammenhänge und Abhängigkeiten der Bausteine untereinander.

6. Dynamische Laufzeitsicht: Beschreibung (z.B. als Laufzeitszenarien inklusive Latenzzeiten) der Bausteine wie sie sich während der Laufzeit verhalten (d.h. Prozesse, Tasks, Aktivitäten, Interruptaufrufe, etc.).

7. Verteilungssicht: Oberste Ebene von Hardware und technischer Infrastruktur mit der Beschreibung, wo welche Teilfunktion abzulaufen hat. Dies ist besonders wichtig für verteilte Anwendungen, z.B. Software-Lösungen die nicht auf einen Prozessor beschränkt sind (Multi-Prozessorlösungen, Connectivity-Lösungen, Zuordnung zu unterschiedlichen virtuellen Maschinen etc.)

8. Querschnittliche Konzepte: Umfangreicher Abschnitt der technische Konzepte beschreibt (z.B. Ablaufsteuerung, Fehlerbehandlung, Logging, Parallelisierung, Bedienoberflächen (UX) und vieles mehr).

9. Entwurfsentscheidungen: Wesentliche Entwurfsentscheidungen mit Gründen

10. Qualitätsszenarien: Beschreibung von Grenz- bzw. Stressszenarien und dem erwarteten Verhalten des Systems (z.B. unter definiert hoher Belastung von Kommunikationsbussen)

11. Risiken und technische Schulden: Dokumentiert Risiken aus SW-Architektursicht, die z.B. auch in das Risikomanagement des Projekts übernommen werden müssen

12. Glossar

In der praktischen Umsetzung von Architekturbeschreibung ist es eine große Herausforderung, die unterschiedlichen Sichten aktuell und konsistent zu halten, da diese oft über mehrere Dokumente und Tools verteilt erstellt werden. Aus diesem Grund wurde in Bosch eine entsprechendes arc42-Profile für das Software-Architekturtool Rhapsody der Firma IBM erstellt. Das Rhapsody-Profile unterstützt Architekten im Entwurf und Pflege konsistenter Architekturen und ihren Sichten.

Das Profil steht auf den arc42 Internetseiten zum Download zur Verfügung.

Zusammenfassung

In den vorhergehenden Kapiteln sind wir auf die disruptiven Änderungen in der Software-Entwicklung der Automobilindustrie eingegangen. Mit dem Einzug von Mikroprozessor-basierten Rechnerplattformen im Fahrzeug findet eine Leistungsexplosion hinsichtlich Speicher, Rechenleistung und Konnektivität statt, die völlig neue Lösungsräume für bisher nicht betrachtete Problemstellungen bietet.

Diese Leistungsexplosion geht einher mit

  • einem extremen Anstieg der Software-Komplexität hinsichtlich unterschiedlicher Arten von Software,
  • unterschiedlicher, aufeinander treffender Entwicklungsmethoden,
  • bei einem gleichzeitigen Anstieg der beteiligten Softwarelieferanten, deren Software-Komponenten in Fahrzeugrechnern integriert werden müssen und dabei Anforderungen zur Funktionalen Sicherheit und Security abdecken.

Diese Situation kann nur mit einem starken Fokus auf Software-Architekturen und deren relevanten Architektursichten beherrscht werden. Dies ist die Herausforderung der sich die gesamte Automobilindustrie aktuell stellt.

Dieser Beitrag stammt aus dem Tagungsband des Embedded Software Engineering Kongress 2017. Vielen Dank für die freundliche Genehmigung der Autoren für die Publikation.

* Dr.-Ing. Zerfowski ist im Corporate Sector Automotive System Integration für die strategische Ausrichtung der Software-Themen im Automotive-Bereich der Firma Bosch verantwortlich. Mit diesem Vortrag gewann er den Speaker Award als Newcomer auf dem ESE Kongress 2017.

* Niranjan SK arbeitet im Corporate Sector Automotive System Integration und an der unternehmensweiten Etablierung von Software-Architekturvorgehensweisen bei der Robert Bosch GmbH.

(ID:45549478)