G&R Analysis &
High level Safety requirements

Durch eine Gefahren & Risiko Analyse (G&R Analyse) werden basierend auf mögliche UseCase Szenarien die Auswirkung einer gefährlichen Situation in Abhängigkeit von der Schwere der Auswirkungen (Severity), der Dauer oder Häufigkeit dieser Situation (Exposure) sowie deren Beherrschbarkeit (Controllability) analysiert und daraus dessen ASIL abgeleitet. Je höher der ASIL (A-D), desto höher sind die Anforderungen bezogen auf die Wahrscheinlichkeit des zu vermeidenden Hazards. Technisch gesehen, desto kleiner muss die Summe der Restfehlerrate aller beteiligten Komponenten bezüglich einer Verletzung des jeweiligen Sicherheitsziels (Safety Goal) sein.
Als Basis Safety Requirements sind unter anderen zu definieren:
- das Sicherheitsziel (SG);
- der sichere Zustand (Safe State);
- die Zeit (FTTI) in der der Safe State erreicht werden soll;
- die Fehlerreaktion;
- die Randbedingungen (Constraints);
- die Rücknahme des Fehlers (bzw. die Fehlerheilung);
sowie weiterer Sicherheits- & Qualitätsanforderungen mit Bezug zum Sicherheitsziel.

Safety Audit

Zu Beginn vor einer Beauftragung wird der Kunde ein Safety Audit durchführen, um sich ein Bild über den Stand der Prozesse der Funktionalen Sicherheit sowie deren Übereinstimmung nach ISO 26262 zu machen. Ab einem höheren ASIL wird ein Safety Audit ohnehin gefordert.

Die DIA (Development Interface Agreement) oder auch Leistungsschnittstellenvereinbarung genannt, alternativ auch Bestandteil der SLA (Service Level Agreement) regelt zwischen Kunden und Supplier und Sub-Supplier wer für was verantwortlich ist und wer an wem (wann) wie bereit stellt bzw. liefert. Die DIA ist ein dynamisches Dokument und kann sich im Laufe des Projekts ändern und muß entsprechend angepasst werden. Die einzelnen Punkte sollte auch im SafetyPlan an den entsprechenden Stellen referenziert und gemanagte werden.

Safety Work products

Alle sicherheits-relevanten Arbeitsprodukte, die als Ergebnisse (Prozess-Outputs) der in der ISO 26262 geforderten Prozesse werden im SafetyPlan gemanagte.
Diese werden als Templates oder mit Anleitungen und Checklisten für das Projekt bereitgestellt und supported.
Begleitend werden entsprechende Reviews, CM-Reviews, Inspections, Assessments bzw. Phasenreviews durchgeführt.
Auch welche Dokumente SafetyCase relevant sind und welche nicht SC-relevant sind.

Dependent Failure analysis (DFA)

Bei der DFA Analyse werden abhängige Fehlerausfälle wie Cascading Failure (CCF), Common Cause Failure (CCF) bzw. Common Mode Failure (CCM) bezüglich einer möglichen SG Verletzung betrachtet. Darunter zählen unter weiteren:
- gemeinsame (externe) Ressourcen / Informationen;
- homogene und diversitäre Redundanzen;
- Funktionen, die mehrfach in identischen HW & SW implementiert wurde;
- Safety Measures (SM) und Monitoring Funktionen;
- Kopplungen zwischen HW Komponenten;
- Abgrenzungen von Funktionen und SW-Elementen;
- Gemeinsame Umgebungseinflüsse ..usw..
Das Ziel der DFA ist es Interferenzfreiheit nachzuweisen und durch Maßnahmen die kausale Abhängigkeiten von Fehlern zu eliminieren oder zu mindern.

Process excerpt: 2-6 Safety Management

Auszug eines Safety Management Prozesses aus der ISO 26262: 2-6 Safety Management.
Mittig der Safety-Prozess (Safety Management during Concept Phases & Product development).
Eingehende Informationen (Work Products) = eingehende Pfeile; ausgehende Pfeile = Process-Outcomes (WP’s).

Ableitung der requirements aus der FMEA

Auszug einer Cross-Table aus der FMEA-Analyse mit über 350-Fehlermodes mit den zugehörenden Fehler-Vermeidungsmechanismen: (Failure Reaction (FR) bzw. der Prevention actions (FP)) und den Fehler-Erkennungsmechanismen: Failure Detection (FD) bzw. der Detection actions.
Das sind die aus einer Sicherheitsanalyse (FMEA) zusätzlich ermittelten und umzusetzenden Sicherheitsanforderungen.

Safety Processes

Als Voraussetzung für eine sicherheitsorientierte Entwicklung in der Automotive Domain ist das Vorhandenseins der Safety-Prozesse und Etablierung einer Safety Culture (siehe oben) sowie die Bereitstellung der benötigten Templates, Checklisten, Normen, Review-Checklisten, vordefinierte Arbeitsdokumente (WP’s), Anleitungen und Regularien sowie die oben aufgeführten Supporting- & Safety-oriented Analysis Prozesse.
Weitere Voraussetzungen sind ein vitales Quality Management System (IATF 16949/ISO 9000) und idealerweise Prozesse in Anlehnung nach Automotive SPICE.

Domäne Funktionale Sicherheit

Die Funktionale Sicherheit muß, da sie als Querschnittsfunktion fungiert organisatorisch unabhängig implementiert innerhalb der Organisation sein, so wie es für das Qualitätsmanagement gefordert ist.

SafetyPlan

Der SafetyPlan ist der Projektplan für die Umsetzung aller für das Projekt safety-relevanten Anforderungen der Funktionalen Sicherheit nach ISO 26262. Verantwortlich für die Umsetzung ist der für das Projekt verantwortliche Safety Manager. Dieser managet unter anderem:
- alle relevanten umzusetzenden ISO 26262 Anforderungen;
- alle zu erstellenden sicherheits-relevanten Arbeitsprodukte;
- den Status der Umsetzung sowie den Verantwortlichen;
- was im SafetyPlan Projekt-relevant getailored wurde;
- beinhaltet den Verifikationsplan;
- den Verifikationsstatus und Umsetzungsstand der WP’s;
- welche Dokumente einem CM-Review zu unterziehen ist;
- welche Dokumente Bestandteil des Safety Case sind;
- den Status der Umsetzung der ref. DIA-Anforderung;
- den Status der Validierung;
- spezifische Filter-Ansichten, ISO 26262-Chapter, WP’s.;
- evtl. Terminplanung für die Umsetzung der WP’s;
- evtl. Std.-Aufwand für die Umsetzung der WP’s;
- Referenz zu den Anforderungen in der ISO 26262;
- evtl. ISO 26262 Abdeckungs-CrossMatrix;
- evtl. beinhaltet den Safety Case;
- evtl. beinhaltet das Dokumentenmanagement für sicherheits-relevante Dokumente.
Der SafetyPlan wird mit allen beteiligten Schnittstellen, sowie dem Kunden abgestimmt.

FSC

Das funktionale Sicherheitskonzept (FSC)stellt auf hoher und abstrakter Ebene das generelle Sicherheitskonzept als Gesamtübersicht dar. Es umfasst den Beauftragungsumfang, was ist in scope und was ist out-of scope; es beinhaltet mehr oder weniger detailliert das System mit den Komponenten und Sub-Komponenten bzw Funktionen / Features;
es allokiert den jeweiligen ASIL und zeigt in einer zweiten Sicht (oder Layer) die allokierten Sicherheitsziele und Haupt-Safety Requirements (in abstrakter Darstellung) sowie die High-Level Safety Measures oder -Requirements (ebenfalls in abstrakter Darstellung) als Konzept.
Das Sicherheitskonzept kann bei komplexen Systemen auch in mehreren Teil-FSC’s unterteilt werden, benötigt dann aber eine übergeordnete Gesamtansicht.
Das FSC, sowie die erstellten Safety Requirements (FSR) sind dann die Eingangs-Informationen für die technische Umsetzung und Spezifikation innerhalb des technischen Sicherheitskonzept (TSC), wo die Anforderungen weiter verfeinert und detailliert werden.

Safety Life-cycle

Auszug eines Safety Life-Cycle über die verschiedenen Entwicklungsaktivitäten sowie der erstellten sicherheits-relevanten Arbeitsprodukten.

Safety Culture

Eine Functional Safety Kultur beinhaltet unter anderem:
- Bekenntnis des Managements zum Status der Funktionalen Sicherheit innerhalb der Organisation;
- die Zielstellung der Organisation bezüglich Functional Safety;
- die Entwicklung und Management des Sicherheitsplans für Functional Safety;
- Beschreibung und Einhaltung der Functional Safety-Prozesse;
- die Bereitstellung und Zuordnung aller benötigten Ressourcen die für die Umsetzung der Funktionalen Sicherheit benötigt werden;
- die permanente Weiterqualifikation der Personen, die in Functional Safety bezogenen Aktivitäten längs des Lebenszyklus involviert sind;
- die Beschreibung und Zuordnung der benötigten Rollen;
- die Sicherstellung der geforderten Unabhängigkeit derer, die für die Ausführung der Safety-Prozesse gefordert werden;
- die Beschreibung und Umsetzung eines effektiven Kommunikationsprozesses;
- die Definition und Umsetzung von Verifikations- & Validierungsprozesse;
- die Beschreibung und Umsetzung eines wirksamen Eskalationsprozesses.

=> Jede nicht definierte oder nicht vollständig umgesetzte Anforderung der ISO 26262, dies gilt auch in Bezug auf die Absicherung der Safety-Sicherheitsmaßnahmen gegen potentiellen Cyberangriffen, stellt nicht nur eine Abweichung zu den Anforderungen der ISO 26262 dar, sondern ist damit auch eine potentielle Fehlerquelle und dadurch auch ein offener Angriffspunkt für eine mögliche spätere straf- bzw. zivilrechtliche Untersuchung im Schadensfall.

Safety Assessment

Projektbegleitend soll ein Safety Assessment zeigen:
- das die erstellten Work Products und
- die Umsetzung der Prozesse die Anforderungen der ISO 26262 erfüllen;
- das die verwendeten Sicherheitsmaßnahmen angemessen und wirksam sind;
- ob der Projektstand zum Zeitpunkt des Assessments konform zur Planung ist.

Safety Manager

Der Safety Manager ist in all den aufgeführten Bereichen involviert und muß um seine Aufgaben mit Voraussicht zu erfüllen auch in all diesen Themen über Erfahrungen verfügen.
Der Safety Manager ist für die Gesamtumsetzung eines sicherheits-relevanten Projektes verantwortlich - dazu gehören unter anderem:
Die Erstellung der Safety-Prozesse nach ISO 26262 Konformität, die Vorbereitung und Durchführung von Safety Audits & Assessments unter Beachtung der geforderten Unabhängigkeit, die Erstellung und Pflege des SafetyPlans,
die Erstellung des FSC’s und der Sicherheitsarchitektur, die Definition/Umsetzung der Sicherheitsziele und der FSR, die Abstimmung der DIA, die Umsetzung der DFA-Analyse sowie des SafetyCase;
- der Safety Manager unterstützt die für die Umsetzung verantwortlichen System- SW- und HW- (Safety-) Engineer’s.
- er ist Verantwortlich für die Sicherheitsanalysen (FMEA, FTA, FMEDA, FMECA, FMVEA..;
- er ist dafür Zuständig, das die Kette der Funktionalen Sicherheit nicht beim Sub-Supplier unterbrochen wird;
- er stellt Sicher, dass die projektbegleitende Schulung und Training gesichert bleibt;
- er ist Ansprechpartner und Unterstützt an der Schnittstelle FuSi zur Produktion, zur QM/QA, beim IATF Audit,zur Schnittstelle AUTOMOTIVE SPICE;
- er ist Ansprechpartner und Initiator auch für die Bereiche “other Technologies & Processes” (G+R Analysis, Tool-, HW- & SW-Components Qualifications;
- er ist als Safety Manager auch dafür Verantwortlich, dass sein Sicherheitskonzept nicht nur gesichert gegen systematische und zufällige HW Fehler ist, sondern auch sicher gegen motivierte Cyberangriffe ist, die das Sicherheitskonzept aushebeln und somit das Sicherheitsziel verletzen;
- schlußendlich ist er auch dafür zuständig, dass nach SoP die Funktionale Sicherheit in den Bereichen Produktion, Operation, Service, Feldbeobachtung usw. bis zur Außerbetriebnahme fortgesetzt wird;
- und die sicherheits-relevante Dokumentation bis zu 15 Jahre nach EoP sicher verwahrt wird.

Safety Analysis

Die Sicherheitsanalyse (Safety Analysis) erfolgt in der Regel abhängig vom ASIL durch eine FMEA bzw. FTA / FMEDA.
Das Ziel ist es, die Wahrscheinlichkeit eines Personenschadens durch eine technische Fehlfunktion (Hazard) soweit zu minimieren, dass das Risiko eines solchen Fehlers gerade noch akzeptierbar (ALARP Prinzip) ist. Es gilt den Nachweis (Absence of unreasonable risk to hazard caused by malfunctioning behaviour of E/E/PE Systems) nach ISO 26262 zu erbringen.

Effort calculation

Die wirklichen Aufwände einer Neuentwicklung im Voraus abzuschätzen ist abhängig vom Entwicklungsumfang, der Komplexität des Entwicklungsgegenstandes und der Möglichkeit auf Ressourcen zurückzugreifen.
Mit Ressourcen ist gemeint, Wiederverwendung von Vorlagen, Work Product Templates, beschriebener Prozesse, Checklisten und Anweisungen, Erfahrung der Mitarbeiter usw. Zum Entwicklungsumfang gehören auch die Qualitätsanforderungen bezüglich des Projekts wie z.B.:
- Gibt es Sicherheitsanforderungen, wenn ja mit welcher ASIL Einstufung, welche Komplexität liegt vor (einfach, mittel oder komplex);
- sind die Prozesse für die Funktionale Sicherheit, bzw. ASPICE bzw. Cybersecurity bereits vollständig vorhanden dazu zählen auch die notwendigen Templates, Vorlagen, Beschreibungen, Qualifikationen usw..
- Bezüglich Automotive SPICE ist zu prüfen; wird nur eine ASPICE Konforme Entwicklung oder eine Entwicklung nach ASPICE, mit einem abschließenden externen Automotive-SPICE Assessment gefordert?
- Dasselbe gilt auch für Cybersecurity;
- Sind Aufwände für Cybersecurity und Safety auch nach Abschluss der Entwicklung zu betrachten?