Funktionale Sicherheit im Software Defined Vehicle Wie Linux für sicherheitskritische Anwendungen nutzbar wird

Anbieter zum Thema

Elektrobit Automotive GmbH

MicroConsult Academy GmbH

emlix GmbH

Zentrale Rechner, Open Source und OTA-Updates verändern die funktionale Sicherheit im Software Defined Vehicle. Der Beitrag zeigt, wie Linux dennoch bis ASIL D nutzbar werden kann.

Die automobile Elektronik verändert sich derzeit grundlegend. Über viele Jahre war sie durch spezialisierte Steuergeräte, klar definierte Funktionsgrenzen und weitgehend statische Softwarearchitekturen geprägt. Mit dem Software Defined Vehicle (SDV) etabliert sich ein neues Leitbild – nicht nur als Vision, sondern zunehmend als reale Entwicklungs- und Serienarchitektur.

Zentrale Hochleistungsrechner ersetzen verteilte ECUs, Funktionen werden softwareseitig von der Hardware entkoppelt und über den gesamten Fahrzeuglebenszyklus hinweg weiterentwickelt. OEMs erwarten davon schnellere Innovationszyklen, bessere Skalierbarkeit und eine stärkere Differenzierung über Software.

Damit ändern sich jedoch auch die Voraussetzungen für funktionale Sicherheit. Während die Absicherung bislang häufig über physische Trennung erfolgte, müssen Safety-relevante Funktionen im SDV-Umfeld zunehmend auf gemeinsamen Plattformen – mit Komfort-, Infotainment- und perspektivisch auch KI-basierten Anwendungen koexistieren.

Damit stellt sich für die Branche eine zentrale Frage: Wie lässt sich funktionale Sicherheit bis ASIL D unter den Bedingungen des SDV zuverlässig, wirtschaftlich und langfristig absichern?

Funktionale Sicherheit wird zur Systemeigenschaft

In klassischen E/E-Architekturen war der Safety-Ansatz klar strukturiert: eine Funktion, ein Steuergerät, ein Safety Case. Die Trennung erfolgte über Hardware, Softwareänderungen waren selten, und der Nachweis nach ISO 26262 ließ sich vergleichsweise eindeutig führen. Die Systemgrenzen von Funktionen mit Safety-Anforderungen waren klar abgegrenzt, Hardware und Software wurden als Einheit betrachtet.

Im SDV gelten andere Rahmenbedingungen. Die Hardware wird als Plattform bereitgestellt, ohne die späteren Funktionen und deren spezifische Safety-Anforderungen vollständig zu kennen. Viel mehr wird die Rechenleistung, die früher auf viele einzelne ECUs verteilt war, in zentralen Einheiten gebündelt. CPU-Zeit, Speicher und Peripherie müssen sehr unterschiedliche Funktionen unterstützen, die teils stark voneinander abweichende Anforderungen an Sicherheit, Echtzeitverhalten und weitere Systemeigenschaften stellen.

Hinzu kommt, dass viele Funktionen und ihre spezifischen Anforderungen- zum Zeitpunkt der Architekturdefinition häufig nur teilweise bekannt sind und sich laufend verändern, um den sich weiterentwickelnden Ansprüchen der Endkunden gerecht zu werden.

Diese Faktoren zeigen: Funktionale Sicherheit ist nicht mehr allein eine Eigenschaft einzelner Funktionen oder Steuergeräte, sondern eine Systemeigenschaft der gesamten Plattform.

Open Source hält Einzug in Sicherheitssysteme

Parallel zu dieser architektonischen Verschiebung etabliert sich ein weiterer Markttrend, der lange als unvereinbar mit funktionaler Sicherheit galt: Open Source Software. In Bereichen wie Infotainment, Connectivity oder DevOps ist Open Source längst Standard. Im sicherheitskritischen Umfeld herrschte dagegen lange Skepsis. Genannt werden vor allem die hohe Komplexität, häufige Änderungen, unklare Verantwortlichkeiten sowie das Fehlen eines konformen Prozesses. Gleichzeitig zeigt der Blick in aktuelle Fahrzeugprogramme und OEM-Strategien, dass ein vollständiger Verzicht auf Open Source im SDV faktisch nicht mehr realistisch ist.

Die Gründe dafür sind strukturell:

• die Softwarekomplexität zentraler Fahrzeugrechner lässt sich ohne Open-Source-Ökosysteme kaum beherrschen;

• proprietäre Insellösungen skalieren weder wirtschaftlich noch organisatorisch; und

• die Teilnahme an offenen Ökosystemen ist inzwischen zu einem unausweichlichen Mandat geworden.

Die entscheidende Frage lautet daher nicht mehr, ob Open Source eingesetzt wird, sondern wie.

Linux und funktionale Sicherheit - ein Widerspruch?

Linux spielt in dieser Diskussion eine Schlüsselrolle. Als Betriebssystem ist es leistungsfähig, hardwareunabhängig, breit unterstützt und in vielen Industrien etabliert. Gleichzeitig wurde Linux nicht mit dem Ziel entwickelt, sicherheitskritische Anforderungen nach ISO 26262 zu erfüllen. Der entscheidende Punkt ist jedoch: Linux ist kein monolithisches Produkt, sondern ein Baukasten. Selbst wenn eine Qualifikation nach ISO 26262 für einen speziellen Anwendungsfall gelingen sollte, lässt die hohe Konfigurierbarkeit und Modularität keinen universellen Schluss auf die generelle Eignung für Safety-Anwendungen zu.

Elektrobit verfolgt mit EB corbos Linux for Safety Applications einen Ansatz, bei dem nicht eine nachträgliche Absicherung von Linux im Vordergrund steht, sondern die frühzeitige Definition und klare Abgrenzung eines Safety-relevanten Systems. Das funktioniert in der Praxis wie folgt:

1. Klare Partitionierung und Mixed-Criticality-Ansatz: Eine zentrale Voraussetzung für funktionale Sicherheit im SDV ist die saubere Trennung unterschiedlicher Software-Kritikalitäten. Dafür werden etablierte Mechanismen moderner SoCs genutzt.

Safety-relevante Linux-Anwendungen laufen in einem technisch abgegrenzten Rahmen, mit klaren Ressourcen- und Zuständigkeitsgrenzen. Auf diese Weise wird physische Trennung durch deterministische Software-Isolation ersetzt. Gleichzeitig bleibt diese Trennung für Integratoren transparent. Aus ihrer Perspektive unterschieden sich Safety-Anwendungen und andere Anwendungen kaum – in beiden Fällen handelt es sich um Linux-Anwendungen.

Praktisch wird das mithilfe von SoC gestützter Isolation realisiert, die über die vom Linux-Kernel bereitgestellten Mechanismen hinausgeht. Diese Mechanismen arbeiten auf Hypervisor-Ebene und sind vollständig vom Linux Kernel getrennt.

2. Definierter, qualifizierter Linux‑Safety‑Scope:

Der Safety-Scope wird vollständig analysiert, getestet und dokumentiert - einschließlich der Traceability bis auf Anforderungsebene. Das Ergebnis ist ein objektiv bewertbarer Safety-Baustein, der projektübergreifend eingesetzt werden kann.

3. Beherrschtes Änderungs‑ und Update‑Modell: Damit funktionale Sicherheit im SDV praxistauglich bleibt, müssen Softwareänderungen möglich sein - ohne den Safety-Case jedes Mal neu aufzubauen.

Dafür ist eine klare Trennung zwischen sicherheitsrelevanten Änderungen, die formell bewertet werden müssen, und Aktualisierungen außerhalb des Safety-Scopes erforderlich. So werden Over-the-Air-Updates nicht ausgeschlossen, sondern in kontrollierter Weise abgesichert. Für OEMs ist das ein wesentlicher Faktor, um SDV-Konzepte industriell umzusetzen.

Innovate Your Software – for a Smarter Future

Deutschlands Leitkongress der Embedded-Softwarebranche

Das Programm des ESE Kongress umfasst 96 Vorträge, 21 Seminare und 3 Keynotes. Seien Sie dabei, wenn sich die Embedded-Software-Community trifft, und nutzen Sie Diskussionen und Expertengespräche für einen ergiebigen Wissenstransfer und erfolgreiches Networken. Während der vier Kongresstage erwartet Sie zudem eine große Fachausstellung mit den führenden Firmen der Branche. Erfahren Sie alles über die neuesten Trends, Herausforderungen und Lösungen im Embedded Software Engineering, von KI, Safety und Security bis hin zu Management und Innovation.

Jetzt mehr erfahren und anmelden!

Verantwortung im Open-Source-Kontext

Ein häufiger Einwand gegen Open Source im Safety-Bereich ist die vermeintlich unklare Verantwortung. In der Praxis ist die Rollenverteilung jedoch eindeutig:

• die Open‑Source‑Community liefert den Code;

• der Systemintegrator verantwortet Auswahl, Qualifizierung und Pflege; und

• der OEM integriert das System in die Gesamtfahrzeugarchitektur.

Open Source wird in diesem Zusammenhang nicht als fertiges Produkt verstanden, sondern als technologische Grundlage, die erst durch definierte Prozesse, kontinuierliche Wartung und belastbare Nachweise für den Safety-Einsatz qualifiziert wird. Bei Bedarf lässt sich diese Basis um Safety-Bausteine ergänzen, die nach etablierten Verfahren der Softwareentwicklung und -pflege entwickelt und betreut werden.

Vorteile für OEMs und Tier‑1‑Firmen

Für Fahrzeughersteller und Systemzulieferer ergeben sich daraus konkrete Vorteile:

• Architekturspielraum für zentrale Rechnerplattformen;

• reduzierte Abhängigkeit von proprietären Einzelkomponenten;

• skalierbare Safety‑Konzepte über Fahrzeuglinien hinweg; und

• langfristige Wartbarkeit im SDV‑Lebenszyklus

Gerade im volumenstarken Marktsegment ist das ein wesentlicher Hebel für Kosten, Time‑to‑Market und technische Kontrolle.

Vergleichsanalyse

Programmiersprachen für Cybersecurity im Automotive-Kontext

Offene Standards

Wie der FACE-Standard modulare, offene und zukunftssichere Avioniksysteme ermöglicht

Funktionale Sicherheit muss softwarezentriert gedacht werden

Mit softwarezentrierten Fahrzeugarchitekturen verändern sich die Anforderungen an funktionale Sicherheit grundlegend. Sie bleibt unverzichtbar, ihre Umsetzung verlagert sich jedoch zunehmend von der Absicherung einzelner Komponenten hin zur systematischen Gestaltung ganzer Plattformen. Zentrale Rechner bündeln heute Funktionen mit unterschiedlichen Anforderungen an Kritikalität, Echtzeitverhalten und Änderbarkeit. Damit rückt weniger das einzelne Betriebssystem oder eine einzelne Softwarekomponente in den Mittelpunkt als vielmehr die Frage, wie sich sicherheitsrelevante Systembereiche eindeutig abgrenzen, Änderungen kontrolliert werden und sich Nachweise über den gesamten Lebenszyklus hinweg belastbar führen lassen. Unter diesen Bedingungen schließen sich Open Source und Safety nicht aus. Werden Architektur, Prozesse und Verantwortlichkeiten klar definiert, kann auch Linux zu einem stabilen Baustein moderner Safety-Plattformen werden. Entscheidend für die Sicherheit ist damit nicht das Betriebssystem allein, sondern ein konsequentes Systemengineering.

 (sg)

* Jens Petersohn verantwortet bei Elektrobit strategische Themen rund um Softwareplattformen, Software Defined Vehicles und funktionale Sicherheit. Er ist seit vielen Jahren in der automotive System- und Softwareentwicklung tätig.

(ID:50871053)