Was beinhaltet die Norm zur funktionalen Sicherheit, ISO 26262?

Überblick

Mit der industrieweiten Anwendung von standardisierten Verfahren für das Entwerfen und Testen von Produkten werden Sicherheitspraktiken immer mehr reguliert. ISO 26262 soll den Bedarf nach einem automobilspezifischen internationalen Standard abdecken, der auf sicherheitskritische Komponenten ausgerichtet ist. ISO 26262 baut auf EC 61508 auf, dem allgemeinen funktionalen Sicherheitsstandard für elektrische und elektronische (E/E) Systeme. Dieses Paper deckt die Schlüsselkomponenten von ISO 26262 und Qualifizierungsanforderungen an Hardware und Software ab. Zusätzlich behandelt das Paper ISO-26262-Testprozesse und Tools, die ISO-26262-konform sind.

Inhalt

Hintergrund

Die zunehmende Komplexität in der Automobilindustrie resultiert in verstärkten Bemühungen, sicherheitskonforme Systeme zu schaffen. Beispielsweise werden in modernen Kraftfahrzeuge "by-wire"-Systeme wie "throttle-by-wire" eingesetzt. Das bedeutet, dass ein Sensor im Pedal ein Signal an eine elektronische Steuereinheit sendet, wenn der Fahrer das Gaspedal herunterdrückt. Diese Steuereinheit analysiert mehrere Faktoren wie Motorumdrehung, Fahrzeuggeschwindigkeit und Pedalposition. Daraufhin wird eine Anweisung an die Drosselklappe geschickt. Das Testen und Validieren von Systemen wie "throttle-by-wire"-Systemen stellt eine Herausforderung für die Automobilindustrie dar. ISO 26262 zielt darauf ab, einen einheitlichen Sicherheitsstandard für alle E/E-Systeme in Kraftfahrzeugen bereitzustellen.

Der ISO 26262 "Draft International Standard" (DIS) wurde im Juni 2009 veröffentlicht. Seitdem findet ISO 26262 immer mehr Anwendung in der Automobilindustrie. Da ISO 26262 als öffentlich anerkannter Standard verfügbar ist, wird er im Rechtsvollzug als neuester technischer "State-of-the-Art" behandelt. Das ist der höchste Entwicklungsstandard, dem ein Gerät oder ein Prozess zu einem gegebenen Zeitpunkt entsprechen kann. Nach deutschem Gesetz sind Automobilhersteller im Allgemeinen haftbar für Personenschäden, die durch Produktversagen oder -fehler verursacht wurden. Wenn der Produktfehler nicht mit Hilfe des technischen "State-of-the-Art"-Standards hätte festgestellt werden können, wird eine Haftung ausgeschlossen. [Deutsches Gesetz zur Produkthaftung (§ 823 Abs. 1 BGB, § 1 ProdHaftG)].

ISO 26262 bietet einen allgemeingültigen Standard zum Messen der Sicherheit eines Systems bei der Anwendung. Darüber hinaus wird ein allgemeingültiges Vokabular bereitgestellt, was die verständliche Bezugnahme auf einzelne Systemteile erleichtert. Dies ist mit anderen sicherheitskritischen Anwendungsbereichen abgestimmt, damit Sie mit Hilfe eines allgemeingültigen Standards messen können, wie sicher Ihr System ist.

Schlüsselkomponenten von ISO 26262

ISO 26262 verwendet ein System von Schritten zur Verwaltung von funktionaler Sicherheit und zur Regulierung der Produktentwicklung auf Systemebene, Hardware- und Softwareebene.

Der ISO 26262-Standard bietet Richtlinien und Empfehlungen für den gesamten Produktentwicklungsprozess, von der konzeptuellen Entwicklung bis hin zur Außerbetriebnahme. Es wird dargelegt, wie ein akzeptabler Risikolevel für ein System oder eine Komponente bestimmt wird, und wie der Testprozess dokumentiert wird. Zusammenfassend bietet ISO 26262:

  • einen Sicherheitslebenszyklus für Kraftfahrzeuge (Management, Entwicklung, Produktion, Betrieb, Service, Außerbetriebnahme) und unterstützt die notwendigen Aktivitäten während dieser Lebenszyklusphasen
  • einen kraftfahrzeugspezifischen, risikobasierten Ansatz zum Bestimmen von Risikoklassen (automobile Sicherheits-Integritätslevel, ASILs)
  • Bestimmen der notwendigen Sicherheitsanforderungen zum Erreichen eines annehmbaren Restrisikolevels mit Hilfe von ASILs
  • Anforderungen an Validierungs- und Bestätigungsmaßnahmen zum Erreichen eines ausreichenden Sicherheitslevels

Sicherheitslebenszyklus für Automobile

ISO 26262 umfasst zehn Bände. Die Norm ist auf serienproduzierte Fahrzeuge ausgelegt und enthält Abschnitte speziell für Automobile. Beispielsweise enthält Abschnitt 7 des ISO 26262 spezifische Sicherheitsanforderungen für Produktion, Betrieb, Service und Außerbetriebnahme.

Der ISO 26262-Sicherheitslebenszyklus für Automobile beschreibt den gesamten Produktlebenszyklus. Dazu gehören die Notwendigkeit eines Managers für den Bereich Sicherheit, das Entwerfen eines Sicherheitsplans und das Implementieren von Maßnahmen wie Sicherheitsprüfung, Sicherheits-Audit und -Beurteilung. Diese Anforderung sind zum Einsatz bei der Entwicklung von E/E-Systemen und -Elementen vorgesehen.

Dieses Dokument beschränkt sich hauptsächlich auf den Lebenszyklusabschnitt der Entwicklung. Der Abschnitt zur Entwicklung in ISO 26262 umfasst das Definieren des Systems, den Systementwurf, die funktionale Sicherheitsbeurteilung und Sicherheitsprüfung.

Sicherheitsintegritätslevel für Automobile (ASIL)

ASIL ist eine Schlüsselkomponente der ISO- 26262-Compliance. ASIL wird zu Beginn des Entwicklungsprozesses festgelegt. Die geplanten Funktionen des Systems werden hinsichtlich möglicher Gefahren analysiert. Beim Anwenden des ASIL-Sicherheitsstandards wird die Frage gestellt: "Was passiert mit dem Fahrer und betroffenen Personen in der Umgebung, wenn ein Fehler auftritt?"

Die Einschätzung dieses Risikos, auf dem ASIL beruht, basiert auf einer Kombination von Faktoren. Dazu gehören eine Einschätzung dazu, wie der Fahrer dem Fehler ausgesetzt ist, die potentielle Kontrolle, die ein Fahrer beim Eintreten des Fehlers hat, und der Schweregrad des Ausgangs, sollte ein kritisches Ereignis eintreten. ASIL beschränkt sich auf Schäden, die der Fahrer und andere Straßenbenutzer davontragen können, und spricht die im System eingesetzten Technologien nicht an.

Jeder Sicherheitsanforderung wird ein ASIL-Sicherheitsintegritätslevel von A, B, C oder D zugewiesen, wobei D die wichtigsten sicherheitskritischen Prozesse abdeckt und die strengsten Testrichtlinien anwendet. Der ISO-26262-Standard identifiziert die Mindesttestanforderungen abhängig vom ASIL der Komponente. Dies hilft dabei, die Methoden zu bestimmen, die für das Testen verwendet werden müssen. Nach Bestimmen des ASILs wird ein Sicherheitsziel für das System formuliert. Damit wird das Systemverhalten festgelegt, das für einen sicheren Betrieb notwendig ist.

Lassen Sie uns zur Veranschaulichung ein Scheibenwischersystem betrachten. Die Sicherheitsanalyse bestimmt den Effekt, den ein Verlust der Scheibenwischerfunktion auf die Sicht des Fahrers haben kann. Der ASIL ist einen Leitfaden für das Auswählen angemessener Methoden zum Erreichen einen bestimmten Integritätslevels für das Produkt. Dieser Leitfaden soll eine Ergänzung zu den aktuellen Sicherheitsverfahren bieten. Automobile werden derzeit unter Einhaltung hoher Sicherheitsvorgaben hergestellt, und mit ISO 26262 sollen einige Verfahren industrieweit standardisiert werden.

Qualifizierung von Hardwarekomponenten

Die Hardwarequalifizierung soll aufzeigen, wie sich eine Komponente in das Gesamtsystem einfügt, und soll darüber hinaus Fehlerarten beurteilen. Für Hardware-Grundkomponenten kann eine Standard-Qualifizierung verwendet werden. Komplexere Teile erfordern eine Beurteilung durch ASIL-Zerlegung und -Tests. Hardwarekomponenten werden normalerweise durch das Testen der Komponente unter verschiedenen Umgebungs- und Betriebsbedingungen qualifiziert. Die Testergebnisse werden dann mit verschiedenen numerischen Methoden analysiert und in einem Qualifizierungsbericht unter Einbeziehung der Testverfahren, Voraussetzungen und Eingangskriterien vorgestellt.

Qualifizierung von Softwarekomponenten

Das Qualifizieren von Softwarekomponenten umfasst Aktivitäten wie das Bestimmen funktionaler Anforderungen, des Ressourcenverbrauchs und das Vorhersagen von Softwareverhalten in Fehler- und Überlastungssituationen. Dieser Prozess wird durch den Einsatz von qualifizierter Software bei der Entwicklung einer Anwendung stark vereinfacht. Qualifizierte Softwarekomponenten sind im allgemeinen etablierte Produkte, die über verschiedene Projekte hinweg wiederverwendet werden und die Bibliotheken, Betriebssysteme, Datenbanken und Treibersoftware beinhalten.

Für die Qualifizierung einer Softwarekomponente erfordert der Standard Tests unter normalen Betriebsbedingungen sowie Tests unter Hinzufügen von Fehlern in das System, um zu bestimmen, wie es auf abnormale Eingänge reagiert. Softwarefehler wie Runtime- und Datenfehler werden analysiert und während des Entwicklungsprozesses angesprochen.

"Proven in Use Argument" hinsichtlich der Betriebsbewährtheit

Hardware- und Softwarekomponenten können die Compliance mit ISO-26262-Anforderungen durch das “Proven in Use”-Argument nachweisen. Diese Klausel findet Anwendung, wenn eine Komponente bereits in anderen Anwendungen ohne Auffälligkeiten verwendet wurde. ISO 26262 findet auch auf ältere Systeme Anwendung, die schon länger erfolgreich im Einsatz sind. Oft macht es keinen Sinn, einen Standard auf ein System anzuwenden, das schon in Millionen von Fahrzeugen eingesetzt wurde. Beispielsweise wurden manche Systeme in heutigen Automobilen bereits unter Anwendung hoher Sicherheitsstandards hergestellt, und das schon vor Inkrafttreten von ISO 26262. In Real-World-Anwendungen haben diese sicherheitskritischen Komponenten ein verlässliches Verhalten bewiesen. Verlässliche Systeme, die unverändert schon früher in Fahrzeugen verwendet wurden, können auch später noch ISO-26262-zertifiziert werden. Durch die Kombination von zertifizierbaren Komponenten aus ähnlichen Anwendungen und aus älteren Anwendungen, die sich weitgehend und schon länger im Einsatz befinden, wird die Komplexität des Gesamtsystems reduziert.

Anwendung auf vorhandene Prozesse

Eine der größten Herausforderungen beim Implementieren eines neuen Standards wie ISO 26262 ist dessen Anwendbarkeit auf bereits vorhandene Prozesse. Normalerweise wird ein neuer Standard zunächst an Pilotprojekten getestet, um die Implementierung des Standards und die Auswirkungen auf derzeit verwendete Prozesse zu sehen. Die Ergebnisse für ISO 26262 haben so weit gezeigt, dass der Standard gut auf aktuelle Sicherheitskonzepte in der Branche anwendbar ist. Unternehmen können schon jetzt die Vorteile der Risikoevaluierung und des Durchführens einer Gefahrenanalyse zu einem frühen Zeitpunkt im Entwicklungsprozess sowie von Tests über den gesamten Entwicklungsprozess hinweg erkennen.

Für Unternehmen, die 26262 implementieren möchten, ist es wichtig, die Notwendigkeit der folgenden Schritte zu verstehen: Durchführen einer Risikoanalyse früh im Entwicklungsprozess, Einrichten entsprechender Sicherheitsanforderungen und ein Erfüllen dieser Anforderungen mit Hilfe von Tests während des Entwicklungsprozesses.

Qualifizierung von Test-Tools

Das Testen ist während der Entwicklung unter ISO 26262 eine kritische Komponente. Sicherheitskritische Systeme müssen in Testszenarien ordnungsgemäß reagieren und innerhalb bestimmter Sicherheitsgrenzen arbeiten, während sie verschiedenen Umgebungen und menschlichen Eingaben ausgesetzt sind. Qualitativ hochwertige Testsysteme können dazu beitragen, die Leistung eines Produkts zu verbessern, Qualität und Zuverlässigkeit zu erhöhen und Rückgaberaten zu verringern. Es wird geschätzt, dass die durch einen Fehler entstehenden Kosten 10mal geringer sind, wenn der Fehler bereits während der Produktion gefunden wird und nicht erst, wenn das Produkt auf dem Markt ist. Und die Kosten sind wiederum 10mal geringer, wenn der Fehler schon während des Entwurfs gefunden wird, und nicht erst während der Produktion. Durch die gewonnenen Daten lassen sich Fehler in Produkten frühzeitig erkennen oder Verfahren sukzessive verbessern, was eine Wertsteigerung für Ihr Unternehmen bedeutet. Das Fördern von Innovationen in diesem Bereich durch die Einführung neuer Technologien und optimaler Vorgehensweisen kann zu deutlichen Effizienzsteigerungen und Kostensenkungen führen. Meistens steht der Systementwurf im Vordergrund und die zugrundeliegenden Software-Tools werden leicht übersehen. Diese Tools spielen jedoch beim Garantieren der Sicherheit des Endnutzers eine wichtige Rolle.

Mit ISO 26262 wird anerkannt, dass durch die Verwendung erprobter und gebräuchlicher Software-Tools die Aktivitäten und Aufgaben zur Entwicklung von elektrischen, elektronischen und Softwarekomponenten, die sicherheitskritische Funktionen bieten, vereinfacht oder automatisiert werden. Bevor wir auf die Details des Tool-Qualifizierungsprozesses eingehen, wollen wir einen wichtigen Teil der Tool-Qualifizierung, den "Tool Confidence Level" definieren.

Tool Confidence Level

Basierend auf den Eingaben und Ausgaben des Tools werden typische oder Referenz-Anwendungsfälle entwickelt. Die Analyse dieser Anwendungsfälle ermöglicht das Bestimmen vom "Tool Confidence Level" (TCL). Mit Hilfe von TCL und ASIL wird der Qualifizierungslevel festgelegt, der für das Software-Tool benötigt wird. Zwei spezifische Bereiche werden zum Bestimmen des Confidence-Levels geprüft:

  • die Wahrscheinlichkeit eines fehlerhaften Software-Tools mit entsprechenden fehlerhaften Ausgaben, welche zu einem Verstoß gegen die Sicherheitsanforderungen an das Produkt oder die zu entwickelnde Komponente führen können
  • die Wahrscheinlichkeit, dass solche Fehler in der Ausgabe gefunden oder von vorneherein verhindert werden

Der "Tool Confidence Level" wird in TCL1, TCL2, TCL3 oder TCL4 unterteilt, wobei TCL4 das niedrigste Konfidenzniveau bezeichnet und TCL1 das höchste.

Der Tool-Qualifizierungsprozess

Bevor ein Tool die Qualifikationen nach ISO 26262 erfüllt, muss es vielen Anforderungen entsprechen. Beispielsweise muss der Sicherheits-Integritätslevel (ASIL) bereits bestimmt worden sein. Für das Tool muss ein Benutzerhandbuch vorhanden sein, eine eindeutige Identifizierung und Versionsnummer, eine Beschreibung der Funktionen, des Installationsvorgangs und der Umgebung (um nur einige Anforderungen zu nennen). ISO 26262 erfordert für die Tool-Qualifizierung die folgenden Dokumente:

  • Software-Tool-Qualifizierungsplan
  • Software-Tool-Dokumentation
  • Software-Tool-Klassifizierungsanalyse
  • Software-Tool-Qualifizierungsbericht

Software-Tool-Qualifizierungsplan

Der Software-Tool-Qualifizierungsplan (STQP) wird früh im Entwicklungslebenszyklus der sicherheitsrelevanten Komponente erstellt. Hierbei wird sich auf zwei Bereiche konzentriert: die Planung für die Qualifizierung eines Software-Tools und eine Auflistung der Anwendungsfälle, die zeigen, dass dem Tool das erforderliche Konfidenzniveau zugeordnet wurde.

Der STQP muss Elemente wie eine einzigartige Identifizierung und Versionsnummer des Software-Tools enthalten sowie Anwendungsfälle, die Umgebung, ein Beschreibung, das Benutzerhandbuch und eine vordefinierte ASIL.

Software-Tool-Klassifizierungsanalyse

Der Hauptzweck der Software-Tool-Klassifizierungsanalyse (STCA) ist das Bestimmen des Konfidenzniveau. Der TCL ermittelt sich aus zwei Hauptgrößen. Die erste ist der Tool Impact (TI). Die zweite ist die Tool Error Detection (TD). Basierend auf diesen zwei Komponenten wird der entsprechende TCL gewählt.

TI1 bzw. TI2 bezeichnen die zwei Klassen des Tool Impacts. TI0 wird gewählt, wenn argumentiert wird, dass das nicht funktionierende Software-Tool unter keinen Umständen eine Sicherheitsanforderung verletzen kann. In allen anderen Fällen wird TI2 gewählt.

Beispielsweise verursacht eine Software einen Tippfehler in der Dokumentation für eine Softwarefunktion. Dies kann zwar lästig sein, verletzt jedoch die getesteten Sicherheitsanforderungen nicht. Daraus würde ein Tool Impact von TI1 resultieren. Wenn das Tool einen Fehler erzeugt, durch den sich das Verhalten des Systems ändern könnte, wird TI2 gewählt.

Die Tool Error Detection wird unterteilt in TD1 bis TD4. TD1 wird bei einem hohen Grad von Konfidenz in die Fähigkeit des Tools zur Feststellung eines Fehlers gewählt, während TD3 bei einem niedrigen Konfidenzgrad gewählt wird. Oft ist dies der Fall, wenn der Fehler nur zufällig festgestellt werden kann.

Ein Software-Tool kann beispielsweise ein Entwurfsmodell auf Fehler überprüfen. In diesem Fall wird eine statische Analyse des Modells durchgeführt. Obwohl eine statische Analyse nützlich ist, findet diese nicht alle möglichen Verstöße im Modell. Außerdem ist es wichtig, festzustellen, dass damit nicht impliziert wird, dass das Modell nicht korrekt ist. Es bedeutet lediglich, dass zusätzliche Tests erforderlich sind. Dieses Szenario resultiert in einem "mittleren" Konfidenzniveau von TD2.

 

 

Tool Error Detection

TD1

TD2

TD3

Tool Impact

TI1

TCL1

TCL1

TCL1

TI2

TCL1

TCL2

TCL3

Nachdem der "Tool Impact" (TI) und die "Tool Error Detection" (TD) bestimmt wurden, wird ein Wert von TCL 1 bis TCL 3 vergeben, abhängig vom Konfidenzniveau. Manchmal können verschiedene Anwendungsfälle in mehreren TCLs resultieren. In einem solchen Fall wird der höchste TCL verwendet. Der Benutzer muss für jedes Software-Tool die Tool-Klassifizierung durchführen.  

Software-Tool-Dokumentation

Zum Sicherstellen der ordnungsgemäßen Verwendung des Tools müssen einige Informationen bereitgestellt werden.

  • Beschreibung von Funktionen
  • Beschreibung des Installationsvorgangs
  • Benutzerhandbuch
  • Betriebsumgebung
  • Erwartetes Verhalten unter außergewöhnlichen Bedingungen

Software-Tool-Qualifizierungsbericht

Der Software-Tool-Qualifizierungsbericht enthält die Ergebnisse und Belege hinsichtlich der abgeschlossenen Tool-Qualifizierung und erfüllten Anforderungen. Jegliche Fehlfunktionen oder fehlerhaften Ausgaben während der Validierung sollten hier analysiert und dokumentiert sein.

Erhöhte Konfidenz resultierend aus vergangenem Einsatz

Ein wichtiger Aspekt der Tool-Qualifizierung ist das Konzept erhöhter Konfidenz, die aus vorherigem Einsatz resultiert. Wenn die Erfüllung der Qualifizierungsanforderungen für ein Tool bereits demonstriert wurde, wird keine weitere Qualifizierung benötigt. Daraus können dramatische Einsparungen von Kosten und Zeit über den gesamten Entwicklungsprozess hinweg resultieren. Qualifizierungsanforderungen müssen jedoch für jedes sicherheitsrelevante Produkt bzw. jede Komponente demonstriert werden, bevor diese in der Entwicklung des Produkts verwendet werden kann. Für jedes Tool muss dazu nachgewiesen werden, dass:

  • es zuvor für denselben Zweck in einem vergleichbaren Anwendungsfall eingesetzt wurde
  • die Spezifikationen des Tools unverändert sind
  • für das zuvor entwickelte sicherheitskritische Produkt keine Verstöße gegen Sicherheitsanforderungen vorliegen.

Beispielsweise wurde Test-Tool "A" für das Validieren von Anforderungen an die ECU (Engine Control Unit) von Fahrzeug "X" verwendet Wenn Test-Tool "A" nicht verändert wurde und in der Vergangenheit alle Sicherheitsanforderungen erfüllte, kann es zum Validieren der ECU von Fahrzeug "Y" verwendet werden, vorausgesetzt, die ECU von Fahrzeug "Y" wird auf eine vergleichbare Art wie die in Fahrzeug "X" verwendet.

Nächste Schritte

Auf der Seite Best Practices for Testing Safety Compliant Systems erfahren Sie, wie Testwerkzeuge von National Instruments für das Testen von sicherheitskritischen Komponenten verwendet werden können. Verfahren wie "Model-in-the-loop"-Tests und "Hardware-in-the-loop"-Tests während des Entwicklungsprozesses werden hier beschrieben. Darüber hinaus werden die Vorteile der Wiederverwendung von Komponenten und die resultierende Effizienzsteigerung behandelt.

Zusätzliche Informationsquellen

NI Best Practices for Testing Safety Compliant Systems

Einführendes Video zur ISO-26262-Qualifizierung