Produktentwicklung & Technisches Sicherheitskonzept nach ISO 26262

ISO 26262 Teil 4 behandelt die Produktentwicklung auf Systemebene. Dabei wird nach dem bekannten V-Modell vorgegangen. Die Hardwareentwicklung und die Softwareentwicklung werden jeweils in Teil 5 und 6 behandelt. Das Item ist auf Systemebene in handhabbare Subsysteme zu zerlegen im Rahmen einer iterativen, verteilten Entwicklung. Ein technisches Sicherheitskonzept nach ISO 26262 bildet den Kern dieser Phase. Es beschreibt die technischen Maßnahmen welche aus dem funktionalen Sicherheitskonzept nach ISO 26262 Teil 3 ableitbar sind.

Der Normteil “4” zur Funktionalen Sicherheit nach ISO 26262 ist im Beuth-Verlag hier verfügbar.

Die Systementwicklung ist in die folgenden Phasen aufgeteilt:

  • 4-5: Initiation of product development at the system level
  • 4-6: Specification of th technical safety specification
  • 4-7: System-Design
  • 4-8: Item integration and testing
  • 4-9: Safety validation
  • 4-10: Functional safety assessment
  • 4-11: Release for production

Teil 4-5 beinhaltet die Planung aller Sicherheitsaktivitäten und die der einzelnen Subphasen. Es kann Teil des Projektmanagements sein.

Teil 4-6 ist eng verknüpft mit Teil 4-7. Dabei werden technische Sicherheitsanforderungen (T-S-Req) ermittelt, die Systemarchitektur erstellt und die T-S-Req in der Architektur allokiert. Eine Dekomposition nach Teil 9-5 kann in Betracht gezogen werden, wenn die T-S-Req Teil 9-6 erfüllt.

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

Ein Technisches Sicherheitskonzept lässt sich klassisch als Mehrebenenkonzept iterativ entwickeln oder nach den Grundsätzen der Grundsicherheitsnorm IEC 61508 Teil 2. Darunter finden Sich Maßnahmen zum Erkennen und zur Beherschung von Hardwarefehlern- und Ausfällen sowie die Vermeidung von systematischen Fehlern. Insbesondere stellt sich auch für den Softwareteil das Thema “systematische Eignung” nach IEC 61508 Teil 3 im Technischen Sicherheitskonzept.

Technisches Sicherheitskonzept nach ISO 26262

Dabei werden nun Sicherheitsmechanismen (SM), Fehlertoleranzmerkmale und Redundanzmechanismen (RM) als T-S-Req spezifiziert und das Systemdesign auf systematische Fehler anhand qualitativer induktiver und deduktiver Analysemethoden (z.B. für ASIL C: FTA/FMEA) untersucht. Eine Inspection, eine Simulation und die angefertigten Analysen sind z.B. zur Verifikation des Systemdesigns nach ASIL C notwendig. Es ist von Vorteil, verschiedene µC-Architekturen und FPGA Architekturen zu kennen. Nur so lassen sich spätere kostspielige Änderungen verhindern. Weiterhin sind die Metrikzielwerte (SPFM/LFM) zu spezifizieren und die Fehlerraten und Diagnosedeckungsgrade (DC) für latente Fehler und Restfehler festzulegen. Dies wird insbesondere für den Systemlieferanten eine bedeutende Spezifikation sein. Ich empfehle Ihnen eine erste Iteration der Metriken auf Schätzwerte durchzuführen, bevor Sie Teil 5 angehen. Eine grobe FTA mit CutSet sollte zur Schätzung komplexer Vorhaben reichen. Währenddessen kann die Methode zur Evaluation der Veletzung von Sicherheitszielen durch zufällige Hardwarefehler festgelegt werden.

Es empfiehlt sich ein ausgeprägtes Wissen über die verwendete Technologien und Möglichkeiten vorzuhalten.

Beispiel: Regelkreis

Ein Regelsystem, egal ob es Teil eines Fahrerassistenzsystems, eines E-Antriebsystems oder eines aktiven Fahrwerks ist, sollte immer vollständig betrachtet werden. Neben standardmäßigen Vorgehen wie der Polvorgabe der geschlossenen Übertragungsfunktion, der Reglerauslegung nach dem Betrags- oder symetrischen Optimum (BO/SO) oder ggf. Beobachterstrukturen im Zustandraum, ist die Regekreisstabilität bei Fehlfunktionen von Bauelementen wie Sensoren oder Aktoren in den oben genannten Analysemethoden zu betrachten. Schließlich kann Instabilität sehr weitreichende Folgen haben. Eine Verschiebung des Drehwinkels um einige Grad durch Fehlfunktion des Sensors kann bei einer feldorientierten Regelung im Feldschwächebetrieb zu einen signifikant ungewünschten Drehmoment führen.

Insofern spart ein technisches SIcherheitskonzept nach ISO 26262 mit Weitsicht einiges an Ressourcen. Weiterhin sei z.B. ein Optokoppler genommen. Dieser hat ein ausgeprägtes Alterungsverhalten, sodass die Regelkreisstabilität oder Reaktionszeit sich im Laufe der Zeit verschlechtert, durch zunehmendes Tiefpassverhalten. Ein Selbsttest der Regelschleife im Rahmen der Wartung in der Werkstatt kann Abhilfe schaffen und die Wahrscheinlichkeitswerte für die PMHF aufbessern um die Zielwerte leichter zu erreichen.

Die Struktur und Dekomposition

Aus sicherheitstechnischer Sicht kann von einem Element keine 100% Sicherheit erwartet werden. Dies hat mehrere Gründe. Zum einen können Bauteile ausfallen zum anderen können systematische Fehler enthalten sein und unentdeckt bis zum Schadensfall in der Architektur schlummern. Daher ist es üblich, je nach Systemcharakteristik ein- oder mehrkanalige Strukturen im technischen Sicherheitskonzept umzusetzen. Ab ASIL C mit Fail-Operational-Charakteristik können mehrkanalige Systeme relevant werden. Die IEC 61508 verwendet das Prinzip der Hardwarefehlertoleranz (HFT) in Teil 2.

Ein technisches Sicherheitskonzept nach ISO 26262 Teil 4 enthält fast immer eine Dekomposition. Dies ist die strukturelle Zerlegung der bestimmungsgemäßen Funktion in Teilfunktionen unterschiedlicher Sicherheitskritikalität. Oft ist die Dekomposition im 3 Ebenekonzept die Zerlegung bzw. Aufteilung der bestimmungsgemäßen Funktion in Funktion und Überwachungsfunktionen. Dabei sind Wechselwirkungsfreiheit und Unabhängigkeit entscheidende Merkmale. Räumliche, zeitliche und technologische Diversität sind meist erforderlich. Dabei werden oft Partitionen in einem Gesamtsystem mit höchsten ASIL gebildet und in dieser Architektur dann Bereiche unterschiedlicher “Integrität” gebildet. Ein sehr aufwendiges Verfahren.

Die Dekomposition dient nicht dazu, den ASIL des Top-Level-Sicherheitsziels zu reduzieren! Oft wird dies versucht und es droht fast immer der Zusammenbruch des Safety-Cases im Assessment.