ISO 26262 und funktionale Sicherheit

Moderne Fahrzeuge sind weit mehr als mechanische Konstrukte mit elektrischer Assistenz. Hier entscheidet Software potentiell über Leben und Tod. Das startet bereits bei Antiblockiersystemen, elektronischen Stabilitätsprogrammen, automatischen Notbremssystemen bis hin zur Lenkkraftunterstützung. Alle Funktionen werden durch Embedded-Software gesteuert, die unter realen Betriebsbedingungen zuverlässig und fehlertolerant funktionieren muss. Die Norm, die diesen Anforderungen einen verbindlichen, international anerkannten Rahmen gibt, heißt ISO 26262. Sie ist aus dem modernen Automotive-Engineering nicht mehr wegzudenken.

1. Was ist ISO 26262?

ISO 26262 ist der internationale Standard für funktionale Sicherheit elektrischer und elektronischer Systeme in Straßenfahrzeugen. Er wurde erstmals 2011 veröffentlicht, 2018 in einer grundlegend überarbeiteten zweiten Edition erweitert und deckt seitdem auch Motorräder, Nutzfahrzeuge und Halbleiter-Komponenten ab. Die Norm leitet sich aus dem generischen Sicherheitsstandard IEC 61508 ab, ist jedoch konsequent auf die spezifischen Anforderungen, Entwicklungsprozesse und Gefährdungsszenarien der Automobilindustrie zugeschnitten.

Funktionale Sicherheit meint dabei nicht die allgemeine Betriebssicherheit eines Fahrzeugs, sondern die Abwesenheit unvertretbarer Risiken, die durch Fehlfunktionen elektrischer oder elektronischer Systeme entstehen können. Die Norm beschreibt einen vollständigen Sicherheitslebenszyklus: von der Konzeptphase und Gefährdungsanalyse über Systementwurf, Hardware- und Softwareentwicklung bis hin zu Produktion, Betrieb und Außerbetriebnahme.

2. Das ASIL-Konzept

Das zentrale Klassifizierungsmodell der ISO 26262 ist das Automotive Safety Integrity Level, kurz ASIL. Es beschreibt, welches Maß an Risikominderung für eine gegebene Sicherheitsanforderung erforderlich ist.

Die Skala reicht von QM (Quality Management, kein spezifischer Sicherheitsanspruch) über ASIL A und ASIL B bis zu ASIL C und ASIL D, dem höchsten Integritätsniveau. Letzteres findet sich in Systemen, deren Ausfall unmittelbar zu schwerwiegenden oder tödlichen Verletzungen, so zum Beispiel eine Bremsteuerung. Die Einstufung ergibt sich nicht aus subjektiver Einschätzung, sondern aus einer methodisch strukturierten Hazard Analysis and Risk Assessment (HARA), die Schwere eines möglichen Schadens (Severity), Auftrittswahrscheinlichkeit (Exposure) und Beherrschbarkeit durch den Fahrer (Controllability) systematisch bewertet.

3. Kernprinzipien der ISO 26262: Was die Norm wirklich fordert

Die ISO 26262 ist ein Prozessrahmen, der durchgängig in der Entwicklung gelebt werden muss. Zu den wichtigsten Kernprinzipien gehören:

Sicherheitslebenszyklus-Management: Sicherheit beginnt nicht beim ersten Code-Commit. Die Norm verlangt, dass Sicherheitsaspekte bereits in der frühesten Konzeptphase adressiert werden. Das beinhaltet die Definition eines Safety Concepts, die Ableitung funktionaler Sicherheitsanforderungen (FSR) und technischer Sicherheitsanforderungen (TSR) sowie deren lückenlose Rückverfolgbarkeit.

Unabhängige Sicherheitsvalidierung: ISO 26262 fordert eine funktionale Unabhängigkeit zwischen Entwicklung und Sicherheitsvalidierung. Das bedeutet in der Praxis, dass Entwickler nicht ihre eigene sicherheitskritische Arbeit abschließend validieren dürfen. Safety-Reviews, unabhängige Audits und die Einbindung eines Functional Safety Managers sind keine optionalen Best Practices, sondern normative Anforderungen.

Fehlermodellierung und Diagnosedeckung: Auf Systemebene müssen potenzielle Hardware-Fehler (Random Hardware Failures) modelliert und quantitativ bewertet werden. Metriken wie die Probabilistic Metric for Random Hardware Failures (PMHF) und die Diagnostic Coverage (DC) geben Aufschluss darüber, ob ein System die geforderten Sicherheitsziele zuverlässig einhält. Für Software gelten darüber hinaus spezifische Anforderungen hinsichtlich Codequalität, Komplexitätsbeschränkungen und Testabdeckung je nach ASIL-Stufe.

4. Warum Embedded-Entwickler ISO 26262 beherrschen müssen

Die Frage, warum ein Embedded-Entwickler im Automotive-Umfeld ISO 26262 kennen muss, lässt sich einfach beantworten: weil jede Entscheidung auf Implementierungsebene sicherheitsrelevante Konsequenzen haben kann. Wer Interrupt-Handler schreibt, Speicherbereiche verwaltet, Kommunikationsstack-Konfigurationen vornimmt oder Timing-Verhalten analysiert, agiert in einem Raum, in dem die Norm konkrete Anforderungen stellt.

Konkret bedeutet das: Embedded-Entwickler müssen verstehen, welches ASIL ihrer Komponente zugeordnet ist, welche Coding Guidelines (etwa MISRA-C oder AUTOSAR C++14) dafür gelten, welche Testabdeckungsgrade (MC/DC für ASIL C und D) nachgewiesen werden müssen und wie Anforderungen an Speicherschutz, Stack-Überwachung und Watchdog-Mechanismen technisch umgesetzt werden. Wer diese Zusammenhänge nicht versteht, kann keine sicherheitskonforme Software schreiben.

Darüber hinaus wird die Kenntnis von ISO 26262 zunehmend zu einem Wettbewerbsfaktor im Freelance-Markt und bei der Besetzung von Festanstellungen. Tier-1-Zulieferer und OEMs setzen in Ausschreibungen voraus, dass Entwickler nicht nur mit der Norm vertraut sind, sondern nachweislich in normenkonformen Entwicklungsumgebungen gearbeitet haben.

5. Herausforderungen der ISO 26262 in der Praxis

Die Anwendung der ISO 26262 im realen Entwicklungsalltag ist anspruchsvoll. Die Norm schreibt vor, was erreicht werden muss, überlässt aber dem Entwicklungsteam weitgehend das wie. Das eröffnet Spielraum für pragmatische Lösungen, erfordert aber gleichzeitig tiefgreifendes Verständnis der Sicherheitsziele hinter den Anforderungen.

6. ISO 26262 und die Zukunft: SOTIF, Cybersecurity und autonomes Fahren

ISO 26262 bildet heute die Grundlage eines wachsenden Ökosystems sicherheitsrelevanter Normen im Automobilbereich. ISO 21448 (SOTIF) ergänzt ISO 26262 um Aspekte, die entstehen, wenn ein System zwar fehlerfrei im technischen Sinne arbeitet, aber dennoch in bestimmten Situationen ein inakzeptables Risiko erzeugt. ISO/SAE 21434 wiederum adressiert Cybersecurity und stellt sicher, dass fahrzeugseitige Systeme nicht nur gegenüber technischen Ausfällen, sondern auch gegenüber gezielten Angriffen resilient sind.

Für Entwickler, die an hochautomatisierten Fahrfunktionen (SAE Level 3 und höher) arbeiten, ist das Zusammenspiel dieser Normen heute unverzichtbares Fachwissen. Die Anforderungen an Systemarchitektur, Testumfang und Prozessreife steigen mit dem Grad der Automatisierung exponentiell.

7. Kompetenz, die zählt: Unser Ansatz zu funktionaler Sicherheit

Wir wissen, dass ISO 26262 kein Thema ist, das man mit oberflächlicher Normenkenntnis abhandeln kann. Wir verstehen die Norm nicht als bürokratische Auflage, sondern als technisches Handwerkszeug für die Entwicklung zuverlässiger, zertifizierbarer Systeme.

Wenn Sie Entwicklungskapazitäten für sicherheitskritische Automotive-Projekte suchen, sprechen Sie uns an. Wir freuen uns auf den fachlichen Austausch und darauf, gemeinsam mit Ihnen die richtigen Lösungen zu entwickeln.