Transcription
Hans-Leo RossFunktionale Sicherheitim AutomobilISO 26262, Systemengineering aufBasis eines Sicherheitslebenszyklusund bewährten Managementsystemen
Hans-Leo RossFunktionale Sicherheit im AutomobilBleiben Sie auf dem Laufenden!Hanser Newsletter informieren Sie regelmäßigüber neue Bücher und Termine aus den ver schiedenen Bereichen der Technik. ProfitierenSie auch von Gewinnspielen und exklusivenLeseproben. Gleich anmelden unterwww.hanser-fachbuch.de/newsletter
Hans-Leo RossFunktionale Sicherheitim AutomobilISO 26262, Systemengineering auf Basiseines Sicherheitslebenszyklus undbewährten Managementsystemen
Bibliografische Information der Deutschen Nationalbibliothek:Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.ISBN 978-3-446-43632-9E-Book ISBN 978-3-446-43840-8Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werkberechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinneder Warenzeichen- und Markenschutzgesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.Alle in diesem Buch enthaltenen Verfahren bzw. Daten wurden nach bestem Wissen dargestellt. Dennoch sind Fehler nicht ganz auszuschließen.Aus diesem Grund sind die in diesem Buch enthaltenen Darstellungen und Daten mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autoren und Verlag übernehmen infolgedessenkeine Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die aufirgend-eine Art aus der Benutzung dieser Darstellungen oder Daten oder Teilen davon entsteht.Dieses Werk ist urheberrechtlich geschützt.Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches oderTeilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Einwilligung des Verlages inirgendeiner Form (Fotokopie, Mikrofilm oder einem anderen Verfahren), auch nicht für Zwecke derUnterrichtsgestaltung – mit Ausnahme der in den §§ 53, 54 URG genannten Sonderfälle –, reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. 2014 Carl Hanser Verlag München Wienwww.hanser-fachbuch.deLektorat: Dipl.-Ing.Volker HerzbergSeitenlayout und Herstellung: Der Buchmacher, Arthur Lenner, MünchenCoverconcept: Marc Müller-Bremer, Rebranding, München, GermanyTitelillustration: Frank Wohlgemuth, HamburgCoverrealisierung: Stephan RönigkDruck und Bindung: Kösel, KrugzellPrinted in Germany
Vorwort vom AutorDas vorliegende Buch ist ein Auszug aus mehr als 20 Jahren Berufserfahrungmit dem Thema Funktionssicherheit. Als ich mich 1992 als Diplom-Ingenieurins Berufsleben stürzte, war der Anlagenbau von verschiedenen Katastrophenwie Bhopal und Seveso geprägt. Das erste Regelwerk, das sich mit dem Thema Sicherheit beschäftigte, war die VDI/VDE-Richtlinie 2180 „Sicherung vonAnlagen der Verfahrenstechnik“ aus dem Jahr 1966, in der es nur um die reineAnlagensicherung ging. Im Jahr 1984 wurde die Richtlinie erweitert; man machtenun einen Unterschied zwischen Betriebs- und Sicherungseinrichtungen sowieÜberwachungs- und Schutzeinrichtungen. Danach erschien auch die DIN VDE31000 „Allgemeine Leitsätze für das sicherheitsgerichtete Gestalten technischerErzeugnisse“. Hier wurden die Zusammenhänge zwischen Risiko, Sicherheit undGefahr beschrieben und das Grenzrisiko wurde eingeführt. Zu dieser Zeit warennoch Maschinenstandards gültig, die die Nutzung von Mikrocontrollern für Sicherheitsaufgaben verboten. Es gab jedoch bereits einen akzeptierten Markt für Sicherheitssteuerungen. Verschiedene Normen und Standards definierten die Grundlagefür die Prüfung, Zertifizierung und Auslegung dieser Sicherheitssteuerungen. Siewurden in Anforderungsklassen (AK 1-8) gemäß der DIN V 19250 klassifiziert.Diese Norm war anwendungs- und technologieunabhängig und beschrieb anhandeines Risikographen ein qualitatives Verfahren zur Risikoabschätzung. 1990erschien die DIN V VDE 0801 „Grundsätze für Rechner in Systemen mit Sicherheitsaufgaben“. In der Revision von 1994 wurden Begriffe wie „betriebsbewährt“und der Einsatz einer „Betrachtungseinheit“ eingeführt. Als Antwort auf die unterschiedlichen Risiko- oder Anforderungsklassen kannte man aber weitgehendnur Redundanz. In der Mess- und Regelungstechnik wurden jedoch auch schondiversitäre Messprinzipien genutzt, um Gefahrenszenarien frühzeitig zu entdecken.Die technischen Regeln für Dampf oder Richtlinien für Druckbehälter schriebenschon die redundante Messung von Druck und Temperatur aus Sicherheitsgründen vor. Selbst das Wasserhaushaltsgesetz kannte die Begrenzung der Füllmengevon Behältern durch Vorschrift oder Regelung sowie die unabhängige Überfüll sicherung als Sicherheitsmaßnahme. Viele dieser Sicherheitsprinzipien waren inden Sicherheitsstandards der Anlagenbetreiber entstanden und dienten sogar als
VIVorwort vom AutorGrundlage für behördliche Genehmigungen. Als ich 1998 mit dem Vertrieb vonSicherheitssteuerungen begann, wurden besonders in England, den Niederlandenund Norwegen die Entwürfe der IEC 61508 diskutiert. Man kannte die skalierbareRedundanz und es wurde zwischen Redundanz für Sicherheit und Verfügbarkeitunterschieden. Mikro controller wurden auch im Lockstep-Prinzip gekoppelt undkonnten im laufenden Betrieb der Anlage den Programmablauf oder die Steuerungslogik ändern. Es waren Programmierprogramme verfügbar, die Sicherheitslogikzwischen einer definierten Laufzeitumgebung konfigurieren konnten.Mit der Veröffentlichung der IEC 61508 wurde ein Lebenszyklusansatz für Sicherheitssysteme vorgestellt. Weiter wurde die Prozessbetrachtung der Produktentwicklung und der Bezug zu den Qualitätsmanagementsystemen formuliert. Währendmeines Masterstudiums am Wirtschaftswissenschaftlichen Institut der UniversitätBasel durfte ich auch die Vorlesung von Professor Dr. Walter Masing genießen, derdie Qualitätsmanagementsysteme in Deutschland sehr geprägt hat. Die Einführungder Diagnose zur Sicherung der Funktion bzw. der elektrischen Trägersystemeder Funktion erweiterte den Gedanken der Sicherheitsarchitektur. 1998 durfteich in Birmingham das erste passive elektronische System vorstellen, welches bisSIL 4 gemäß IEC 61508 zertifiziert war. Nach der Vorgängerveranstaltung der safe tronic im Jahre 1999, die in den Räumlichkeiten des TÜV-Süd stattfand, war ichbei der Unterschrift des ersten Zertifikats für ein einkanaliges vollständig gemäßIEC 61508 entwickeltes Steuerungssystem dabei. Auf einer VDMA-Veranstaltungberichtete ich über die Erfahrung mit der IEC 61508 im Anlagenbau und derenEinfluss auf die Entwicklung von sicherheitsgerichteten Steuerungssystemen. DieMaschinenbauindustrie war damals noch sehr stark von Relaistechnik geprägt. Dassdie software-basierende Sicherheitstechnik diese Branche so schnell mit neuenLösungen und Systemen verändern würde, wollte damals kaum jemand glauben.Als ich 2001 die Leitung des Produktmanagements übernahm, galt es neue Anwendungen für neue Sicherheitssysteme zu finden. Ein weiterer Themenschwerpunktwurde die vernetzte Sicherheitstechnik, die bis dahin auf seriellen Datenbussenberuhte. Jetzt mussten verteilte und dezentrale Sicherheit sowie dynamische, situa tions- oder zustandsabhängige Sicherheitssysteme realisiert werden. Als Lösungkam nur noch Ethernet in Frage. Wichtig war hier, die vorhandene Datentechnikfür die Sicherheitstechnik handhabbar zu machen. Im Rahmen von Diplomarbeitenwurden Sicherheitssteuerungen in ganz Norwegen verteilt, die auf dem Datennetz der norwegischen Mineralölgesellschaft „Statoil“ sicherheitsrelevante Datenaustauschten. Die Erfahrungen mit Datenübertragung über Satelliten zwischenÖlplattformen und Landanlagen oder zwischen Norwegen und Deutschland undverschiedenen Lösungen zur Pipelineüberwachung über Funksysteme zeigte, dasssicherheitstechnische Datensysteme auch auf Basis von Ethernet realisierbar sind.
Vorwort vom Autor Durch die Veröffentlichung der IEC 61508 als DIN EN 61508 (VDE 0803) „Funktionale Sicherheit sicherheitsbezogener onischer Systeme“ im Jahre 2001 wurde die deutsche Automobilindustrie aufdas Thema aufmerksam. Öffentlicher Schriftverkehr zwischen dem VDA und denVDTÜVs führte zur Gründung des AK16 im FAKRA (Facharbeitskreis Automobil).Durch meinen Wechsel zu Continental Teves wurde ich 2004 Mitglied in diesemArbeitskreis. Noch im selben Jahr wurden die ersten Strukturen für die spätere ISO26262 entworfen und man nahm Kontakt zu weiteren Automobilnormungsgremienin anderen Ländern auf. Insbesondere mit Frankreich wurden konkrete Rahmenbedingungen für die Norm ausgearbeitet. Die erste Sitzung der ISO/TC22/SC03/WG16fand vom 31.10. bis 02.11.2005 in Berlin statt. Die Arbeitsgruppen aus Frankreichund Deutschland bildeten die größten Fraktionen neben anderen Ländervertretungenaus Japan, USA, Schweden, Großbritannien u.s.w. Bis zu diesem Zeitpunkt kursiertedie ISO 26262 unter dem Namen „FAKRA-Norm“. Die safetronic 2005 adressiertebereits die ersten Ideen der zukünftigen Automobilnorm und es wurden Vorträge zu„Best Practices“ und Methoden präsentiert. Die safetronic begleitete die Entwicklungder ISO 26262 bis zum heutigen Tag. Im November 2011 wurde die ISO 26262 als„Internationaler Standard“ veröffentlicht. Das Buch ist der Versuch all die Hintergrundinformationen, die in den ganzen Jahren gesammelt und hart erfahren wurden,zusammenzutragen. Weiter will das Buch die Idee der Sicherheitsarchitektur alsGrundlage für die Entwicklung von sicherheitsrelevanten Produkten näherbringen.Dankwort des AutorsDie vielen Diskussionen mit den Experten der internationalen Normierung, denKollegen, in den Arbeitskreisen, mit Hochschulen, bei Vorträgen sowie die Erkenntnisse aus Diplomarbeiten und Förderprojekten haben zu diesem Buch beigetragen.All den beteiligten Menschen möchte ich danken für die Leidenschaft, mit der siedas Thema Funktionssicherheit mit mir betrachtet haben. Neben all den Expertengilt der besondere Dank meiner Frau. Sie brachte viel Verständnis auf und gab mirden Freiraum dieses Buch zu schreiben.VII
InhaltVorwort vom Autor.VDer Autor. XIII1Einleitung. 11.1 Begriffe und Übersetzungen aus der ISO 26262. 21.2 Fehlerbegriffe der ISO 26262. 5 2Warum Funktionssicherheit im Automobil?. 72.1 Risiko, Sicherheit und Funktionssicherheit im Automobil. 82.2 Qualitätsmanagementsystem. 132.2.1 Qualitätsmanagementsysteme aus Sicht der ISO 26262. 192.3 Qualitätsvorausplanung. 202.4 Prozessmodelle. 232.4.1 V-Modelle. 242.4.2 Wasserfallmodell. 312.4.3 Spiralmodell. 322.5 Management der Funktionalen Sicherheit im Automobilund Sicherheitslebenszyklus.352.5.1 Sicherheitslebenszyklus für die Automobilentwicklung. 372.5.2 Sicherheitslebenszyklus gemäß ISO 26262. 393Systemengineering.433.1 Geschichtliche und philosophische Hintergründe.433.2 Technische Zuverlässigkeit.463.2.1 Grundlage der Zuverlässigkeit. 493.2.2 Zuverlässigkeit und Sicherheit.533.3 Architekturentwicklung.563.3.1 Stakeholder von Architekturen.583.3.2 Sichten einer Architektur. 623.3.3 Horizontale Abstraktionsebene.64
XInhalt3.4 Anforderungs- und Architekturentwicklung. 753.5 Anforderungs- und Designspezifikation.77 4Systemengineering zur Entwicklung von Anforderungen und Architektur.854.1 Funktionsanalyse.904.2 Gefahren- und Risikoanalyse. 944.2.1 Gefahren- und Risikoanalyse gemäß ISO 26262 .964.2.2 Sicherheitsziele.1044.3 Sicherheitskonzepte. 1074.3.1 Funktionales Sicherheitskonzept. 1104.3.2 Technisches Sicherheitskonzept. 1214.3.3 Mikrokontroller-Sicherheitskonzepte.1264.4 Systemanalysen.1304.4.1 Methoden zur Systemanalyse. 1314.4.2 Sicherheitsanalysen gemäß ISO 26262.1364.4.2.1 Fehlerpropagation. 1424.4.2.2 Fehlerpropagation in der Horizontalen undVertikalen. 1494.4.2.3 Induktive Sicherheitsanalyse.1534.4.2.4 Deduktive Sicherheitsanalyse.1564.4.2.5 Quantitative Sicherheitsanalysen. 1624.4.2.6 Architekturmetriken.1664.4.2.7 Top-Fehlermetrik (PMHF). 1704.4.2.8 Fehlermetriken bei Sensoren oder anderenKomponenten. 1744.4.2.9 Analyse der abhängigen Fehler(Analysis of dependent failures). 1764.4.2.10 Sicherheitsanalysen im Sicherheitslebenszyklus. 1824.5 Verifikation während der Entwicklung.1884.6 Produktentwicklung auf Systemebene. 1914.7 Produktentwicklung auf Komponentenebenen. 1954.7.1 Mechanikentwicklung. 1984.7.2 Elektronikentwicklung.2004.7.3 Softwareentwicklung.2055 ystemengineering in der Produkt realisierung. 215S5.1 Produktrealisierung. 2155.1.1 Produktdesign zur Realisierung. 2165.1.2 Mechanik. 216
Inhalt 5.1.3 Elektronik. 2185.1.4 Software. 218 6Systemintegration .2216.1 Verifikationen und Tests.2226.1.1 Grundlagen zu Verifikation und Test.2266.1.2 Verifikation basierend auf Sicherheitsanalysen.2286.1.3 Testmethoden.2326.1.4 Integration technischer Elemente.2336.2 Validierung.2356.3 Modellbasierende Entwicklung.2376.3.1 Modelle für die Funktionale Sicherheit.2406.3.2 Grundlage für Modelle.2436.3.3 Modellbasierende Sicherheitsanalyse.2446.4 Freigaben.2466.4.1 Prozessfreigaben.2476.4.2 Freigabe zur Serienproduktion.2497 estätigung der funktionalen Sicherheit.251B7.1 Reviews zur Bestätigung der Normerfüllung.2557.2 Prozessanalyse zur funktionalen Sicherheit.2567.3 Bewertung / Assessment der funktionalen Sicherheit.2607.4 Sicherheitsnachweis. 261Index.265XI
Der AutorHans-Leo Ross absolvierte sein Ingenieurstudium an derUni-GH-Paderborn. Für die Preussag-Noell-LGA Gastechnik plante und realisierte er sicherheitsrelevante Anlagenund Systeme für die Öl- und Gasindustrie sowie für Offshore- und Chemieanlagen. Für HIMA Paul Hildebrandtwar er für den Vertrieb von sicherheitsgerichteten Steuerungen in Großbritannien sowie Nord- und Osteuropazuständig, bevor er die Leitung des Produktmanagementsübernahm.Seit 2004 ist der Autor bei Continental Automotive tätig.Dort ist er für die Einführung der Funktionalen Sicherheitbei Continental verantwortlich und koordiniert alle täten.Er ist seit 2004 auch Mitglied im VDA AK 16 und leitet seit 2009 das deutsche Spiegelgremium zur ISO 26262, die heutige VDA-Arbeitsgruppe AK 26-01 (Grundlagender Funktionssicherheit für Straßenfahrzeuge). Weiter war er Gründungsmitgliedder WG 16 (ISO Gremium für die ISO 26262) und ist seitdem einer der deutschenExperten dieser internationalen Arbeitsgruppe. In den beiden Gremien wurden diewesentlichen Grundlagen für die Funktionale Sicherheit im Automobil erarbeitet.
1EinleitungDie ISO 26262 verändert zurzeit die Fahrzeugentwicklung in einer Form, wie mansich das vor 10 Jahren, als das Thema Funktionssicherheit in der Automobilindustriestärker in den Vordergrund getreten ist, nie hätte vorstellen können. Als sich Anfangdes 21. Jahrhunderts die ersten deutschen Arbeitskreise mit dem Thema beschäftigthatten und bereits 2005 die ersten internationalen Gremien dazu gebildet wurden,wollte man als Antwort auf die Frage nach der Produktsicherheit eine schlanke Lösung. In den Jahren bis zur endgültigen Veröffentlichung der ISO 26262 sind zehnBände mit etwa 1000 Anforderungen entstanden. In all diesen Jahren sind viel Wissen,Methodik und auch Lösungsansätze diskutiert worden, die nur in Fragmenten indie Norm als Anforderung, Hinweise (Notes) oder informative Kapitel eingeflossensind. Derzeit gibt es in jedem Land weitere Normvorhaben, die sich teilweise nur mitder Übersetzung der ISO 26262, aber auch mit der Methodenentwicklung zur ISO26262 beschäftigen. Die ISO 26262 wurde nicht als Richtlinie geschrieben, sondernsie stellt nur Anforderungen an Aktivitäten und Methoden, die bei den jeweiligenSicherheitsaktivitäten berücksichtigt werden sollen. Dabei hat man weitgehend daraufverzichtet anzugeben, wie man etwas im Sinne der Norm umsetzen muss. Dies hängtin erster Linie damit zusammen, dass ein Sicherheitsstandard weitgehend den Standder Technik widerspiegelt und somit solche Vorgaben oft nur für einen bestimmtenZeitausschnitt gültig sind. Welches Design als sicher bezeichnet werden kann oderwelche Methode sich als geeignet zeigt, stellt sich oft nur als ein kleines Zeitfensterdar. Sicherheitsdesign und auch Methoden zur Sicherheit sollen sich kontinuierlichweiterentwickeln und nicht durch Normen zum Stillstand gezwungen werden. DasBedürfnis nach einer Richtlinie ist sehr groß, aber auch dieses Buch, welches einenweiteren Einblick in die Hintergründe der Norm gewähren soll, hat nicht den Anspruch die korrekte Umsetzung der ISO 26262 wiederzugeben. Mit den Hinweisenzu den Methoden, die den Schwerpunkt dieses Buchs darstellen, kann allgemeinkeine einzige Anforderung der Norm erfüllt werden. Die Normerfüllung kann nurim Kontext der konkreten Produktentwicklung geschehen.Oft werden in der ISO 26262 verschiedene Anforderungen und Hinweise für denLeser recht komplex beschrieben. Diese Formulierungen sind Kompromisse, die die
21 EinleitungExperten, welche die Norm entwickelt haben, eingehen mussten. Daher sind alleÜbersetzungen in diesem Buch bereits mögliche Interpretationen, die unter einemanderen oder zukünftigen Kontext komplett anders interpretiert oder übersetzt werden können. Allen Lesern kann man nur den Hinweis geben, sich bei der Auslegungund Anwendung der Normen in der Praxis an die Texte der ISO 26262 zu halten. 1.1 egriffe und Übersetzungen aus derBISO 26262Die ISO 26262 wurde nur in englischer Sprache verfasst, selbst die übliche Übersetzung ins Französische wurde wegen indifferenter Nutzung von Begriffen nicht umgesetzt. Somit gilt für die ISO 26262 als eine der wenigen Normen auch der englischeText in Frankreich als normativ. Nur Japan hat indes eine japanische Übersetzungveröffentlicht. Dies war auch notwendig, da der typische Entwickler in Japan dochSchwierigkeiten hat, die englische Sprache zu lesen oder zu interpretieren. Für dieWorte Verifikation, Analyse, Untersuchung, Validation, Überprüfung gibt es nur einjapanisches Wort, daher müssen entsprechende Übersetzungshilfen her. Es wurdevon den japanischen Übersetzern versichert, dass der Inhalt sich nicht verfälschthätte. Aber selbst bei der Übersetzung ins Deutsche fällt es schwer, die richtigen Wortezu definieren. Begriffe wie Verifikation, Analyse und Validation werden hier gemäßISO 26262 benutzt. Die folgenden Begriffe aus dem Glossar der ISO 26262 wurdenin diesem Buch angepasst. Die in diesem Buch blau hinterlegten Kästen sind freieÜbersetzungen der ISO 26262, die aber dem Verständnis des Autors entstammen.Ganz freie Interpretationen, Meinungen oder gar Empfehlungen des Autors sind innormaler Schrift wie der allgemeine Text des Buches geschrieben. Wörtliche Zitatesind kursiv geschrieben.Bewertung (Assessment) der Funktionalen Sicherheit1.4 (Assessment)Untersuchung einer Eigenschaft eines Fahrzeugsystems (1.69) oder Elementes(1.32)Hinweis: Einen gewissen Grad der Unabhängigkeit (1.61) einer gewissen Parteioder Parteien, die ein Assessment durchführen, sollte für jedes Assessmentgewährleistet sein.
1.1Begriffe und Übersetzungen aus der ISO 26262Allgemein wird das Word „Assessment“ mit Beurteilung übersetzt. Die Untersuchung(examination) wird als Basis für eine Beurteilung (Assessment) gesehen. Wenn esum die Aktivität „Functional Safety Assesment“ gemäß der ISO 26262 geht, so wirdder Begriff „Assessment der Funktionalen Sicherheit“ benutzt.1.6 ASIL (Automotive Safety Integrity Level)ASIL bezeichnet eines von insgesamt vier Levels zur Vermeidung von nichttolerierbaren Restrisiken. Der ASIL verweist auf Sicherheitsmaßnahmen undnotwendige Anforderungen aus der ISO 26262 für das Fahrzeugsystem (Item,1.69) oder einzelne Elemente (1.32). Dabei steht ASIL D für das höchste undASIL A für das niedrigste Sicherheitslevel.Im Rahmen dieses Buches wird nur der Begriff „ASIL“ verwendet.Die ISO 26262 gibt bereits in Teil 10 eine Beschreibung der Elemente eines Fahrzeugsystems, wobei ein Element ein System, ein Subsystem (logisches oder technisches Element und damit auch eine Funktionsgruppe), eine Komponente, einHW-Bauelement oder eine SW-Unit sein W-BauelementSW-UnitBild 1.1 Elemente eines Fahrzeugsystems (Quelle: ISO 26262, Teil 10, Bild 3)Teil 1 der ISO 26262 wird unter 1.69 Fahrzeugsystem (Item) wie folgt beschrieben:3
41 Einleitung1.69 (Fahrzeugsystem, item)System (1.129) oder Feld von Systemen, welche eine Funktion auf Fahrzeugebene realisiert, auf welches die ISO 26262 angewendet werden soll.Item wird als Fahrzeugsystem übersetzt, wenn es sich im das konkrete „Item“ ausder ISO 26262 handelt. Historisch gesehen, sollte der Begriff „Betrachtungseinheit“für „Item“ verwendet werden, durch die Definition des Begriffes liegt der BegriffFahrzeugsystem näher. Ist dies wichtig, wird in Klammern der Begriff „Item“ ergänzt. Der Begriff „Feld von Systemen“ wird im Kapitel 4 kritisch hinterfragt, beieiner systematischen hierarchischen Gliederung sollte es sich um Systeme undzugeordnete Subsysteme handeln.Das Bild 3 (hier Bild 1.1) aus dem Teil 10 kann wie folgt aus dieser Definition abgeleitet werden:1. System (1.129) oder mehrere Systeme, die eine (oder mehrere) Funktion(en) aufFahrzeugebene realisieren, auf die die ISO 26262 angewendet werden.2. Ein System kann eine oder mehrere Funktionen realisieren, es kann aber aucheine Funktion auf mehreren Systemen realisiert werden.3. Ein Fahrzeugsystem besteht aus einem oder mehreren Systemen, wobei ein Systemaus mindestens einem Sensor, einer Verarbeitung und einem Aktuator besteht.Die ISO 26262 zieht in einer Note den Schluss, dass ein System mindestens dreiElemente haben sollte, jedoch wäre es denkbar, dass zum Beispiel ein Aktuatorin die Verarbeitungseinheit integriert wäre.4. Ein System kann in beliebige Subsysteme gegliedert werden, wobei laut ISO26262 die Systeme nicht hierarchisch gegliedert sein müssen. Handelt sich esum Systeme, die gemeinsam Funktionen mit höherem ASIL realisieren sollen,wird man wegen der Mehrfachfehlerbeherrschung eine eindeutige hierarchischeGliederung der Systeme definieren müssen.5. Ein System (oder Subsystem) besteht aus einer oder mehreren Komponenten.6. Die Komponenten bestehen aus (elektrischen) HW-Bauelementen (HW-Parts) oderaus SW-Units.Die Begriffe wie Modul, SW-Datei etc. werden in der ISO 26262 nicht definiert. Beiintegrierten Halbleitern wird man auch über Sub-Parts sprechen, damit sind logischeFunktionselemente gemeint, die bestimmte Funktionen und Sicherheitsmechanismeninnerhalb eines integrierten Halbleiters realisieren.
1.2 1.2Fehlerbegriffe der ISO 26262 Fehlerbegriffe der ISO 26262Die Norm gibt die Begriffe wie folgt in ihrem Band 1 vor:1.36 (Fehler, error)Abweichung zwischen einem ausgeführten, beobachteten oder gemessenenWert oder einer Bedingung (Zustand) und dem wahren, spezifizierten odertheoretisch korrekten Wert oder der Bedingung (Zustand).Hinweis 1: Ein Fehler (error) kann durch eine unvorhersehbare Betriebsbedingung oder durch eine Abweichung (fault, 1.42) im System (1.129), Subsystemoder in Komponenten (1.15) auftreten.Hinweis 2: Eine Abweichung (fault) kann selbst als ein Fehler innerhalb desbetrachteten Elementes interpretiert werden und schließlich als Ursache zueinem Ausfall (failure) führen.1.39 (Ausfall, failure)Die Fähigkeit, dass ein Element (1.32) eine geforderte Funktion erfüllen kann,ist nicht mehr gegeben.Hinweis: Fehlerhafte Spezifikationen sind Quellen für Ausfälle.1.42 (Abweichung, fault)Nicht normaler Zustand (Bedingung), welcher Ursache für ein Fehlverhalteneines Elementes (1.32) oder Fahrzeugsystems (1.69) sein kann.Hinweis 1: Permanente, intermittierende oder transiente Abweichungen (1.134)(insbesondere „Soft-Errors“) werden betrachtet.Hinweis 2: Eine intermittierende Abweichung tritt zeitweise immer wieder(sporadisch) auf. Diese Abweichungen können auftreten, wenn technischeKomponenten (1.15) das Ende ihrer Lebensdauer erreicht haben (Spezifikation)oder auch durch Störungen (prellen) an einem Schalter entstehen. Einige systematische Abweichungen (1.131) (zum Beispiel zeitliche Grenzlagen) könnenzu intermittierenden Abweichungen führen.5
61 EinleitungBei der Übersetzung wurden Annahmen getroffen, die hier erläutert werden.„Fault“, „failure“ und „error“ werden oft wie folgt übersetzt:Fault: Abweichung, Anomalie, Mangel, Defekt, Nicht-KonformitätError: Irrtum, Störung oder FehlerFailure: Versagen oder Ausfall.Die Zusammenhänge dieser drei Begriffe und auch deren Modell der Fehlerpropagation wird im Kapitel 4.4.2 beschrieben.
Funktionale Sicherheit im Automobil ISO 26262 , Systemengineering auf . Funktionale Sicherheit im Automobil ISO 26262, Systemengineering auf Basis . Nach der Vorgängerveranstaltung der safe-tronic im Jahre 1999, die
