ISO 26262 beschreibt, wie elektrische und elektronische Systeme im Fahrzeug entwickelt werden müssen, damit ihr Ausfall keine unvertretbare Gefährdung auslöst. Sie ist eine Prozessnorm über den gesamten Lebenszyklus: von der Gefährdungsanalyse in der Konzeptphase über Systemarchitektur, Hardware und Software bis zu Produktion, Service und Außerbetriebnahme.
Wer nach einer ISO-26262-Zertifizierung sucht, sucht dabei meist etwas, das so nicht existiert. Das ist keine Spitzfindigkeit, sondern die wichtigste Information für die Projektplanung.
Es gibt kein Unternehmenszertifikat nach ISO 26262
ISO 26262 ist keine Managementsystemnorm wie ISO 9001. Für sie existiert kein Zertifizierungsschema mit akkreditierten Zertifizierungsstellen, dreijährigem Zertifikat und jährlichen Überwachungsaudits. In der Akkreditierung hat ein solches Verfahren keine Entsprechung, weil es die dafür nötige Grundlage — ein normiertes, prüfbares Managementsystem mit definiertem Geltungsbereich — nicht gibt.
Der Grund liegt im Gegenstand. Funktionale Sicherheit lässt sich nicht am Unternehmen messen, sondern nur an einem konkreten Produkt in einem konkreten Fahrzeugkontext. Dieselbe Steuergerätesoftware kann in einem Fahrzeug eine hohe Sicherheitsanforderung tragen und im nächsten gar keine — abhängig davon, welche Funktion sie dort auslöst und was passiert, wenn sie ausfällt. Ein Zertifikat, das diese Frage offenlässt, sagt nichts aus.
Manche Anbieter stellen dennoch Dokumente aus, die wie Zertifikate aussehen. Prüfen Sie in solchen Fällen zwei Dinge: worauf sich die Bestätigung bezieht — ein Produkt, ein Prozess, eine Person — und wer sie ausgestellt hat. Die Auswahlkriterien aus der Übersicht zur Zertifizierungsstelle helfen dabei nur bedingt, weil hier gerade keine akkreditierte Stelle im üblichen Sinn tätig wird.
Welche Nachweise es stattdessen gibt
Vier Formen begegnen Ihnen in der Praxis, und sie werden regelmäßig verwechselt.
Die Beurteilung der funktionalen Sicherheit. Sie ist keine Kür, sondern eine Forderung der Norm selbst und muss durch eine ausreichend unabhängige Instanz erfolgen. Wie weit diese Unabhängigkeit reichen muss, steigt mit der Sicherheitseinstufung: von einer anderen Person über eine andere Organisationseinheit bis zu einer Instanz außerhalb des verantwortlichen Bereichs. Für die höheren Einstufungen ist die Beurteilung verbindlich, für die niedrigeren lässt sie sich reduzieren.
Konformitätsbestätigungen von Prüforganisationen. Technische Dienste und Prüfhäuser bewerten ein Produkt oder eine dokumentierte Entwicklungsvorgehensweise gegen die Norm und stellen darüber eine Bescheinigung aus. Sie hat Gewicht im Markt, ist aber eine Bestätigung des Prüfhauses und keine akkreditierte Zertifizierung.
Der Safety Case. Das ist der Nachweis, den Ihr Kunde tatsächlich sehen will: die geordnete Argumentation samt Arbeitsergebnissen, warum die Sicherheitsziele erfüllt sind. Er wird über das Projekt hinweg aufgebaut, nicht am Ende zusammengestellt.
Personenzertifikate. Sicherheitsingenieure lassen ihre Qualifikation prüfen und bescheinigen. Das ist ein Nachweis über einen Menschen, nicht über ein Produkt — und wird in Ausschreibungen gelegentlich so behandelt, als wäre es beides.
Aufbau der Norm
ISO 26262 ist aus der IEC 61508 hervorgegangen und deren Anpassung an die Fahrzeugentwicklung. Sie besteht aus zwölf Teilen: Vokabular, Management der funktionalen Sicherheit, Konzeptphase, Produktentwicklung auf System-, Hardware- und Softwareebene, Produktion und Betrieb, unterstützende Prozesse, sicherheitsbezogene Analysen, Anwendungshinweise, ein Teil zu Halbleitern und ein Teil zu Krafträdern.
Die zweite Fassung von 2018 hat den Anwendungsbereich über Pkw hinaus erweitert. Nutzfahrzeuge, Busse und Anhänger fallen seitdem darunter. Für Zulieferer, die bislang ausschließlich in den Nutzfahrzeugmarkt liefern, ist das der Punkt, an dem die Norm zum ersten Mal in Lastenheften auftaucht.
Wie die ASIL-Einstufung zustande kommt
Am Anfang steht die Gefährdungsanalyse und Risikobewertung. Für jede Betriebssituation wird gefragt, welche Fehlfunktion welche Gefährdung auslösen kann. Drei Größen werden dann bewertet: die Schwere des möglichen Schadens, die Häufigkeit, mit der die Situation überhaupt auftritt, und die Beherrschbarkeit durch Fahrer oder andere Verkehrsteilnehmer.
Aus der Kombination dieser drei Größen ergibt sich die Einstufung: QM oder ASIL A bis D, wobei D die höchste Anforderung trägt. Erfinden lässt sich diese Einstufung nicht — sie folgt aus einer festgelegten Zuordnung und ist im Streitfall genau dort nachvollziehbar.
Entscheidend für das Verständnis: Die Einstufung hängt am Sicherheitsziel, nicht am Bauteil. Ein Sensor ist nicht ASIL D. Das Sicherheitsziel, zu dem er beiträgt, kann es sein. Wer diesen Unterschied im Einkauf nicht mitdenkt, kauft Bauteile nach einem Etikett, das keine Aussage enthält.
Was ein Zulieferer ohne Kenntnis des Fahrzeugs bewerten kann
Genau dieser Punkt ist das Kernproblem der Zulieferkette. Ein Halbleiterhersteller oder ein Anbieter von Basissoftware kennt das Fahrzeug nicht, in dem sein Produkt landet, und kann deshalb keine Gefährdungsanalyse dafür führen.
Die Norm löst das über das Safety Element out of Context. Der Lieferant entwickelt sein Element auf Basis ausdrücklich formulierter Annahmen: welche Funktion es erfüllt, welche Sicherheitsanforderungen unterstellt werden, welche Aufgaben die Umgebung übernimmt und welche Einstufung angenommen wird. Diese Annahmen werden zusammen mit den Anwendungsbedingungen im Sicherheitshandbuch dokumentiert.
Der Integrator muss die Annahmen prüfen. Trifft eine nicht zu — weil die Diagnose im Steuergerät anders läuft als unterstellt oder ein Fehler dort nicht in der angenommenen Zeit erkannt wird —, trägt der Sicherheitsnachweis nicht mehr. Der häufigste Fehler in der Praxis ist, dass diese Prüfung ausbleibt und das Sicherheitshandbuch ungelesen abgelegt wird.
Wer welche Aufgabe übernimmt, hält das Development Interface Agreement fest. Es ist neben dem Safety Case das wichtigste Dokument der Zusammenarbeit und regelt Arbeitsteilung, Schnittstellen und Freigaben. Fehlt es, klärt sich die Verantwortungsfrage erst im Feld.
ISO 26262 und IATF 16949 ersetzen sich nicht
| ISO 26262 | IATF 16949 | |
|---|---|---|
| Frage | Führt ein Ausfall zu einer Gefährdung? | Erzeugt der Prozess die geforderte Qualität? |
| Gegenstand | Ein Produkt in einem Fahrzeugkontext | Ein Fertigungsstandort |
| Ergebnis | Safety Case, Beurteilung, Bestätigung | Zertifikat mit dreijährigem Zyklus |
| Prüfende | Unabhängige Instanz, Prüforganisation | Zugelassene Zertifizierungsstelle |
| Akkreditierung | Kein Schema | Ja, nach IATF-Regeln |
Beide Nachweise laufen nebeneinander. Die IATF 16949 ist für Serienlieferanten die Voraussetzung, überhaupt beauftragt zu werden. Der Sicherheitsnachweis nach ISO 26262 kommt für sicherheitsrelevante Elektronik obendrauf und wird produktbezogen verlangt. Welche Nachweise die Branche daneben noch fordert, ordnet die Übersicht zur Automobilindustrie ein.
SOTIF stellt eine andere Frage
ISO 21448 behandelt Gefährdungen, die entstehen, obwohl kein Bauteil ausfällt. Ein Kamerasystem erkennt ein Objekt bei Gegenlicht nicht. Ein Notbremsassistent reagiert auf eine Situation, für die er nicht ausgelegt wurde. Ein Fahrer benutzt eine Funktion vorhersehbar anders als vorgesehen. Nichts davon ist ein Fehler im Sinne der ISO 26262 — und trotzdem ein Sicherheitsproblem.
Je stärker eine Funktion auf Umfelderkennung beruht, desto mehr verschiebt sich das Risiko von der Fehlerseite auf die Leistungsseite. Für Fahrerassistenz und automatisiertes Fahren reicht ISO 26262 allein deshalb nicht aus. Beide Normen werden parallel angewendet, mit getrennten Argumentationen im selben Sicherheitsnachweis.
Woran es in der Praxis scheitert
Die Unabhängigkeit wird zu spät geplant. Wer erst kurz vor Projektende feststellt, dass die Beurteilung nicht durch den Entwicklungsleiter erfolgen darf, sucht Kapazität, die es intern nicht gibt.
Der Safety Case wird nachträglich geschrieben. Er ist eine Sammlung von Arbeitsergebnissen aus dem laufenden Projekt. Wer ihn am Ende rekonstruiert, produziert Dokumente ohne Spur im Projektverlauf — das fällt in jeder ernsthaften Beurteilung auf.
Die Werkzeuge werden vergessen. Compiler, Codegeneratoren und Testwerkzeuge brauchen eine Einstufung danach, ob ein Werkzeugfehler einen Fehler ins Produkt einbringen kann und ob er entdeckt würde. Erst daraus folgt, welcher Qualifizierungsaufwand nötig ist. Diese Bewertung wird regelmäßig übersehen und lässt sich rückwirkend nur mühsam nachholen.
QM wird als Entwarnung gelesen. Keine ISO-26262-Anforderung heißt nicht keine Anforderung. Die Funktion bleibt Gegenstand des Qualitätsmanagements und der kundenspezifischen Anforderungen des jeweiligen Herstellers.
Die Einstufung wird verhandelt. Sie ist das Ergebnis einer Analyse, kein Verhandlungsgegenstand zwischen Einkauf und Entwicklung. Eine nachträglich abgesenkte Einstufung ohne geänderte Analyse ist die Art von Entscheidung, die im Schadensfall sehr genau betrachtet wird. Was funktionale Sicherheit im Kern bedeutet, erklärt der Eintrag funktionale Sicherheit.