Startseite > Automotive > Software + Tools > Alles sicher?

Safety-/Security-Software-Architekturen

Alles sicher?

4. Juli 2016, 11:05 Uhr | Von Rudolf Grave und Alexander Much

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Sichere Mehrkern-Systeme

Zeitgleich werden nicht nur mehr, sondern auch rechenintensivere Funktionen entwickelt, die deutlich höhere Anforderungen an die benötigte Rechenleistung im Fahrzeug stellen. Ähnlich wie bei Rechnern im IT-Umfeld werden daher zunehmend Multicore-Systeme statt einzelner Prozessoren eingesetzt. Das hat direkte Auswirkungen auf die Software-Architekturen, denn bestehende Software-Systeme wurden häufig speziell für Einzelprozessoren entwickelt und optimiert und können die zusätzliche Rechenleistung nur unzureichend nutzen. Mehrkernsysteme erlauben auch eine Konsolidierung der Anzahl von Steuergeräten im Fahrzeug, was Einsparungen bei Leistungsaufnahme und Gewicht ermöglichen kann. Diese „Domain Controller“-Systeme übernehmen oft viele Funktionen einer Domäne, wie Antriebsstrang oder Innenraum. Das hat Auswirkungen auf die Anforderungen an die funktionale Sicherheit: Ist auch nur eine der konsolidierten Funktionen sicherheitsrelevant, dann muss es auch das Gesamtsystem sein.

Von "Fail-Silent" zu "Fail-Operational"

Die meisten Systeme im Automobil sind traditionell nicht „Fail-Silent“, also nicht ausfallsicher entwickelt; der sichere Zustand – „Safe State“ – besteht oft in der Deaktivierung der Funktion oder Funktionsgruppe. Der Fahrer wird informiert, aber die Fahrt kann – je nach Sicherheitsrelevanz des ausgefallenen Systems – nicht fortgesetzt werden. Das ist für Hersteller wie für Kunden ärgerlich, aus Sicht der funktionalen Sicherheit dagegen oft der bewusst gewählte sichere Zustand. Je mehr fahrdynamische Aufgaben die Systeme jedoch übernehmen, desto weniger ist das einfache Abschalten einer Funktion möglich und der Ausfall selbst wird als sicherheitsrelevant eingestuft. Der Übergang ist fließend, aber spätestens für das autonome Fahren müssen Systeme ausfallsicher, also „Fail-Operational“, entwickelt werden: Das System muss trotz Fehlerfall zumindest eine eingeschränkte Funktionalität ermöglichen. Es darf beispielsweise nicht einfach während der Fahrt abschalten, sondern muss mindestens langsam ausrollen und an einem sicheren Ort zum Stillstand kommen können. Diese Zuverlässigkeit (Reliability) von Systemen stellt eine weitere Herausforderung dar, sowohl für die System- als auch für die Software-Entwicklung und die daraus resultierenden Software-Architekturen.

Das vernetzte Auto und Informationssicherheit

Informationssicherheit ist schon seit Längerem in der Automobilentwicklung relevant. So gehören Systeme wie eine Wegfahrsperre, sichere elektronische Schlüssel oder das abgesicherte Speichern des Kilometerstandes bereits zur Grundausstattung. Doch die zunehmende Vernetzung der Fahrzeuge stellt die Industrie vor neue Herausforderungen. Bei vielen Herstellern sind inzwischen Online-Angebote verfügbar, die Fahrzeugdiagnose kann teilweise aus der Ferne durchgeführt werden, Verkehrsinformationen werden in Echtzeit übermittelt und das Kartenmaterial für das Navigationssystem wird automatisch aktualisiert. Gemäß der Grundregel der IT, „Was verbunden ist, das wird von Hackern angegriffen“, rücken die Systemaspekte Informationssicherheit (Security) und Datenschutz (Privacy) auch in der Automobilindustrie stärker in den Vordergrund. Die ersten erfolgreichen Angriffe auf Systeme über Remote-Zugriff oder das Internet wurden mittlerweile veröffentlicht und haben eine breite Reaktion hervorgerufen. Als Antwort darauf wurde Anfang dieses Jahres von der SAE ein Handbuch für die Entwicklung informationssicherer Systeme veröffentlicht [1]. Das Handbuch beschreibt sowohl Prozesse als auch Methoden und ist vom Lebenszyklus her von der ISO 26262 abgeleitet. Es ist selbst allerdings kein Standard, aber in dem Dokument werden wesentliche Bemühungen wie Forschungsprogramme oder bisherige Standards und Publikationen zusammengefasst. Insofern ist es ein wertvoller Beitrag und kann als ein Einstiegspunkt für die Einführung von Prozessen und Methoden dienen.