Executive Summary Funktionale Sicherheit ISO ZVEI UG2 Adhoc AG Funktionale Sicherheit ISO 26262

Transkript

1 Executive Summary Funktionale Sicherheit ISO ZVEI UG2 Adhoc AG Funktionale Sicherheit ISO Fachverband Electronic Components and Systems

2 Impressum Executive Summary Funktionale Sicherheit ISO ZVEI UG2 Adhoc AG Funktionale Sicherheit ISO Herausgeber: ZVEI Zentralverband Elektrotechnik- und Elektronikindustrie e.v. Fachverband Electronic Components and Systems Lyoner Str Frankfurt am Main Telefon: Fax: zvei-be@zvei.org Verantwortlich: Dr. Stefan Gutschling Redaktion: Stefan Kriso Christopher Temple Berthold Arends Pierre Metz Bernd Enser Robert Bosch GmbH Freescale Halbleiter Deutschland GmbH Marquardt GmbH Brose Fahrzeugteile GmbH Co. KG SANMINA-SCI Germany GmbH Foto: ZVEI Zentralverband Elektrotechnik- und Elektronikindustrie e.v. Juni 2012 Alle Rechte, insbesondere das Recht der Vervielfältigung und Verbreitung sowie der Übersetzung vorbehalten. Kein Teil des Werkes darf in irgendeiner Form (Druck, Fotokopie, Mikrofilm oder ein anderes Verfahren) ohne schriftliche Genehmigung des ZVEI reproduziert oder unter Verwendung elektronischer Systeme vervielfältigt oder verbreitet werden. 2

3 Inhaltsverzeichnis Was ist funktionale Sicherheit nach ISO 26262?... 4 Wie wird funktionale Sicherheit nach ISO erlangt?... 5 Einige Anmerkungen zur ISO

4 Was ist funktionale Sicherheit nach ISO 26262? Die ISO setzt einen Fokus auf die funktionale Sicherheit elektrischer bzw. elektronischer (E/E)- Systeme in Fahrzeugen. Funktionale Sicherheit nach ISO betrifft jedes System, welches elektrische / elektronische / elektromechanische Komponenten beinhaltet. Die Systembetrachtung umfasst dabei Aktuatorik, Sensorik und Steuerungselektronik. Industrielle Systeme im Allgemeinen werden durch die IEC abgedeckt, wobei weitere sektorspezifische Normen für Eisenbahntechnik, Flugzeugtechnik etc. existieren. Die ISO stellt die sektorspezifische Ableitung der IEC für die Automobilbranche dar. Bei der funktionalen Sicherheit ( functional safety ) geht es um die Vermeidung von unvertretbaren Verletzungsrisiken ( absence of unreasonable risk ) für Personen, hervorgerufen durch mögliche Fehlfunktionen dieser E/E-Systeme. Die funktionale Sicherheit ist demnach eine Systemeigenschaft. Die bekannten aktiven und passiven Sicherheitssysteme grenzen sich dahingehend ab, dass es sich bei der aktiven Sicherheit primär um die proaktive Unfallvermeidung (durch das Fahrvermögen des Fahrzeugführers, aber auch elektronische Systeme wie ACC, ABS, ESP etc.) und bei der passiven Sicherheit um das reaktive Mindern von Unfallfolgen, wenn es bereits zu einem Unfall gekommen ist, handelt (z.b. Sicherheitsgurte, aber auch elektronische Systeme wie Airbags, Gurtstraffer etc.) Die elektronischen Systeme für aktive und passive Sicherheit müssen selbst funktional sicher sein, da Fehlfunktionen dieser Systeme selbst auch wieder zu Personengefährdungen führen könnten. Primär werden bei der funktionalen Sicherheit Gefährdungen betrachtet, die von zufälligen Hardwareausfällen ( random HW faults ) sowie von systematischen Fehlern ( systematic faults ) bei der Systemauslegung, bei der HW oder SW Entwicklung oder in der Fertigung bis hin zur Inbetriebnahme, Reparatur und Ausmusterung des Systems ausgehen. Die ISO umfasst hierzu 10 Teile mit ungefähr 750 Klauseln auf ca. 450 Seiten, die sich unter anderem mit dem Systementwurf, der Hardware, der Software und den begleitenden Entwicklungsprozessen auseinandersetzen. Eine zentrale Rolle fällt hierbei dem Sicherheitslebenszyklus ( safety lifecycle ) zu. Der Sicherheitslebenszyklus regelt die Identifikation, Konstruktion, Überprüfung und Bewertung der verschiedenen Maßnahmen in kausaler Abfolge im Rahmen des branchenüblichen V-Modells. Der Begriff der Funktionalen Sicherheit ist nicht zu verwechseln oder gar gleichzusetzen mit Produkteigenschaften wie Zuverlässigkeit ( reliability ), Verfügbarkeit ( availability ) und Schutz vor vorsätzlicher Gefährdung und Bedrohung von Menschen und Sachwerten ( security ) 1. Zuverlässigkeit beschreibt die Wahrscheinlichkeit, mit der ein System in einem Zeitintervall seine zugewiesene Funktion erfüllt. Verfügbarkeit beschreibt den prozentuellen Anteil an Zeit, in der das System über die gesamte Lebensdauer betrachtet mit seiner zugewiesenen Funktion einsetzbar ist 2. 1 In der deutschen Sprache wird oft sowohl für safety als auch für security der Begriff Sicherheit verwendet, der die Unterscheidung dieser unterschiedlichen Eigenschaften leider wesentlich erschwert. Aus diesem Grund wird meistens in Fachkreisen auf die englischen Begriffe zurückgegriffen. 2 Dies wird im Rahmen des Arbeitskreises Robustness Validation der ZVEI detailliert betrachtet. 4

5 Die ISO selbst ist keine Zertifizierungsnorm und umfasst deshalb keine Klauseln, um Zertifizierungen oder Zertifizierungsumfänge zu regeln. Aus Sicht der Norm besteht keine Notwendigkeit, Systeme, Komponenten oder Prozesse gegen diese zu zertifizieren, noch ist diese Norm unmittelbar Kfz-zulassungsrelevant. Die Erfahrung in der Umsetzung der ISO zeigt für manche Anwender der Norm einen Wert in der externen Begutachtung ( assessment ) und auch Zertifizierung ( certification ). Die inhaltlichen Umfänge dieser Überprüfungen werden zurzeit von den jeweils zertifizierenden Häusern festgelegt. Aus juristischer Sicht bringt die ISO keine unmittelbare Veränderung der Rechtslage. Es gilt weiterhin die Produkthaftung und die Sachmängelhaftung. Für weitere juristische Aspekte wie zum Beispiel der Beweislastumkehr sei auf einschlägige juristische Veröffentlichungen verwiesen. Im Allgemeinen werden fachliche Normen als relevant bei der Beurteilung des Stands der Wissenschaft & Technik betrachtet, und so fällt natürlich der ISO ein mittelbarer juristischer Stellenwert zu. Um der automobilen Zulieferstruktur gerecht zu werden, beinhaltet die ISO Anforderungen zur Regelung der sicherheitsrelevanten Verantwortlichkeiten bei verteilter Entwicklung. Hierfür dient das Development Interface Agreement (DIA), das die explizite detaillierte Abstimmung zwischen den beteiligten Unternehmen an ihren Schnittstellen adressiert. Wie im nächsten Abschnitt ausgeführt wird, ist nämlich eine alleinige generelle Forderung des Kunden an seinen Zulieferer nach einer "ISO konformen Arbeitsweise" oder die alleinige Nennung einer bestimmten Sicherheitsklassifizierung keinesfalls ausreichend. Eine explizite Abstimmung auf technischer Ebene insbesondere der Sicherheitsziele, deren Sicherheitsklassifizierung, der umzusetzenden Sicherheitsmaßnahmen usw. ist also unabdingbar, um ein sicheres Produkt über Zuliefergrenzen hinweg zu entwickeln. Wie wird funktionale Sicherheit nach ISO erlangt? Am Anfang des Sicherheitslebenszyklus ( safety lifecycle ) steht die Definition des zu betrachtenden Systems auf Fahrzeugebene ( item ). Zur Illustration sei hier ein Airbagsystem genannt. Als nächsten Schritt gilt es nun, eine Gefahrenanalyse und Risikobewertung ( hazard analysis and risk assessment ) für das zu betrachtende System durchzuführen. Eine mögliche Gefahr eines Airbagsystems wäre das unbeabsichtigte Auslösen des Airbags. Nun gilt es ein entsprechendes Sicherheitsziel ( safety goal ) für jede Gefahr zu benennen. Im Falle des Beispiels wäre ein Sicherheitsziel, das unbeabsichtigte Auslösen des Airbags zu unterbinden. Typischerweise wird an dieser Stelle eine größere Menge an Sicherheitszielen identifiziert. Dann erfolgt die Klassifizierung eines jeden Sicherheitszieles entweder nach QM oder nach einer von vier möglichen Sicherheitsklassen, die in der Norm als Automotive Safety Integrity Level (ASIL) bezeichnet und mit ASIL A bis ASIL D unterschieden werden. Die Einstufung QM drückt aus, dass bei der Realisierung des entsprechenden Sicherheitszieles ein übliches Qualitätsmanagementsystem, z.b. gemäß ISO/TS 16949, und die Berücksichtigung etablierter Standards wie z.b. Automotive Spice ausreichend ist und darüber hinaus keine ergänzenden Anforderungen aus der ISO gestellt werden müssen. Die nächst höhere Einstufung ASIL A nach ISO kennzeichnet die geringste Sicherheitsklassifizierung, ASIL D die höchste. Der ASIL wird mit Hilfe einer in der 5

6 Norm enthaltenen Zuordnungstabelle für jedes Sicherheitsziel festgelegt. Hierbei werden jeweils 3 Parameter bewertet. Diese sind die Exposition ( exposure ), d.h. wie häufig befindet sich das Fahrzeug in einer Situation, in der eine Gefährdung von beteiligten Personen wie Fahrer, Insassen oder von weiteren Verkehrsteilnehmern auftreten kann, die Beherrschbarkeit ( controllability ), d.h. wie gut kann ein Verletzen des Sicherheitszieles durch die beteiligten Personen beherrscht werden der Schweregrad ( severity ), der die Schwere der Auswirkung quantifiziert, der durch das Verletzen des Sicherheitszieles entstehen kann Das unbeabsichtigte Auslösen des Airbags wird typischerweise mit ASIL D klassifiziert. Die Umsetzung der Sicherheitsziele muss entsprechend des klassifizierten ASIL s erfolgen. Das bedeutet, dass zur Vermeidung systematischer Fehler geeignete Prozesse und Methoden anzuwenden und zur Beherrschung von technischen Fehlern entsprechende zusätzliche Anforderungen an das Produkt zu implementieren sind. Dies geschieht zunächst durch die Definition eines funktionalen Sicherheitskonzeptes ( functional safety concept ). Im Falle des Beispiels könnte dies ein Redundanzkonzept bestehend aus einem Steuerkanal und einem unabhängigen Überwachungskanal sein. Der Airbag wird nur gezündet, wenn beide Kanäle in Übereinstimmung sind. Als nächstes erfolgt die technische Konkretisierung im Rahmen des technischen Sicherheitskonzepts ( technical safety concept ). Im Falle des Beispiels könnte man eine Sicherheitsarchitektur mit ausreichend unabhängigen Sensoren definieren, wobei jeder Kanal unabhängig den Zündkreis freigeben muss, um das funktionale Sicherheitskonzept zu realisieren. Hierbei können auch Sicherheitsmaßnahmen vorgesehen werden, die außerhalb des E/E Systems realisiert werden (z.b. durch mechanische Vorkehrungen). Die Realisierung dieser Maßnahmen ist jedoch nicht Teil der Einflusssphäre der ISO Hierfür sind entsprechende Normen zu berücksichtigen. Nun erfolgt die Ableitung der sicherheitsbezogenen Anforderungen an die Hardware ( hardware safety requirements ) und an die Software ( software safety requirements ) aus dem technischen Sicherheitskonzept. Hierbei spielen besonders die Erreichung bzw. Bewahrung ausreichender Unabhängigkeiten in redundanten Systemstrukturen ( dependent failure avoidance ), die Erzielung bestimmter Metriken zur Beurteilung von Hardware ( single point fault metric, latent fault metric ) eine große Rolle. Nach der Systemintegration erfolgt die sicherheitsbezogene Validierung ( safety validation ), die sicherheitsbezogene Begutachtung ( functional safety assessment ) und die Freigabe zur Produktion ( release for production ), wobei sich die konkreten Forderungen der ISO an der jeweiligen ASIL Klassifizierung der Sicherheitsziele orientieren. Der Einfluss der Norm erstreckt sich auch über die Produktion und den Betrieb bis hin zur Außerbetriebnahme des Systems im Feld. Hier ist gerade das Airbagbeispiel anschaulich, da es auch am Ende des Produktlebenszyklus nicht zu einer unerwünschten Auslösung des Airbags kommen darf. 6

7 Einige Anmerkungen zur ISO Ein Aspekt der ISO 26262, der häufig missverstanden wird, ist die ASIL Klassifizierung. Bei der ASIL Klassifizierung ist wesentlich, dass die Sicherheitsziele bewertet werden und nicht das System! Hierbei ist auch zu beachten, dass ein System üblicherweise eine ganze Reihe an Sicherheitszielen erfüllen muss. Leider hat sich in der Praxis eine Sprachregelung auch unter Experten eingefunden, bei der die bedeutendste ASIL Klassifizierung auf das System übertragen wird. So spricht man z.b. beim Airbagsystem landläufig oft von einem ASIL-D System, unabhängig davon, dass auch ein Airbagsystem viele weitere Sicherheitsziele unterschiedlicher ASIL Klassifizierungen Genüge tun muss. Bei einer reinen Nennung der ASIL Klassifizierung ist es ohne Kenntnis des funktionalen und technischen Sicherheitskonzeptes unmöglich, detailliertes Wissen über die Anforderungen an konkrete Komponenten innerhalb des Systems zu erlangen. Der oft genutzte Sprachgebrauch einer ASIL-X Komponente ist also sinnentfremdet. Durch die Tatsache, dass die Ermittlung des ASIL für etwaige Sicherheitsziele typischerweise auf Gesamtfahrzeugebene erfolgt und unabhängig von der konkreten Implementierung des Systems ist, ist es sinnvoll, dass der Fahrzeughersteller die Sicherheitsziele zusammen mit den dazugehörigen ASIL seinen Zulieferern vorgeben sollte. Dies kann im Rahmen eines DIA geregelt werden. Ist dies nicht der Fall, z.b. bei einer Plattformentwicklung des Zulieferers, so hat dieser bzgl. der Sicherheitsziele und der zugehörigen ASILs Annahmen zu treffen, die dann der Kunde (OEM) bei der Integration des Systems zu validieren hat. Die Norm stellt hierfür im informativen Band 10 das Konzept des "Safety Element out of Context" (SEooC) vor. Die Autoren der Norm haben großen Wert darauf gelegt, die Norm möglichst generisch zu halten. Die Norm selber schreibt zum Beispiel bestimmte Eigenschaften und Kriterien vor, die im Rahmen des funktionalen und technischen Sicherheitskonzeptes in Abhängigkeit der ASIL Klassifizierung erfüllt werden müssen, greift aber in die Wahl eines konkreten Sicherheitskonzeptes nicht ein. Eine Stärke dieses Ansatzes ist, dass dieser keine unnötigen und unter Umständen auch willkürlichen Einschränkungen auferlegt und somit auch die Langlebigkeit der Norm sicherstellt. Eine Folge ist, dass das Wissen um die Definition eines geeigneten Sicherheitskonzeptes anderwärtig erworben werden muss, und dass natürlich eine große Anzahl unterschiedlicher Sicherheitskonzepte für dieselben Sicherheitsziele möglich sind. Ein häufig diskutierter Aspekt der ISO ist der zusätzliche Aufwand, der vermeintlicher weise durch die Norm erzeugt wird. Hierzu sei angemerkt, dass die Norm erwartet, dass der hinter den Forderungen stehende Sinn revisionsfähig erfüllt wird. Somit ist die Norm bei ausreichender Begründung flexibel hinsichtlich gerechtfertigter Abweichungen. Im Grunde kann man erwarten, dass in der Einführungsphase ein erhöhter Aufwand bei der Einbindung des Sicherheitslebenszyklus in den Entwicklungsfluss anfallen kann. Die technischen Aufwände sind im Wesentlichen der funktionalen Sicherheit des Systems und nicht der Norm geschuldet. Nicht unterschätzt werden sollten die Aufwände bei der sicherheitsbezogenen Validierung. Diese sind zwar ebenfalls mehr der funktionalen Sicherheit des Systems als der Norm geschuldet, gewinnen aber durch den strengen Nachweisaspekt der Norm deutlich an Stellenwert. Nach der Freigabe der normativen Teile der ISO als internationaler Standard im November 2011 steht einer erfolgreichen Umsetzung nichts im Wege. 7

8 ZVEI Zentralverband Elektrotechnik- und Elektroindustrie e.v. Fachverband Electronic Components and Systems (ECS) Lyoner Straße Frankfurt am Main, Deutschland Telefon: Fax: zvei-be@zvei.org