|
|
|
|
 |
|
Wann sollte die FuSi spätestens angegangen werden? Die ISO 26262‑2:2018 definiert den (Sicherheits-) Lebenszyklus als Gesamtheit der Phasen von Konzept bis zur Außerbetriebnahme (=Entsorgung) des Produktes (= Item, (Sub-) System, Komponente). In der Folge ist die Funktionale Sicherheit auch von Beginn an zu berücksichtigen. Ist eine Hardwarearchitektur erst einmal definiert, eine Baseline gezogen und gibt es womöglich eine partiell ausgelagerte Entwicklung (distributed development), wird jede spätere Änderung formal kompliziert (Change Request mit entsprechendem Folgeprozess) und praktisch daher auch oft teuer. Selbst nicht-physische Entwicklungen wie Software können bei Nachtragsänderungen sehr viel Geld kosten (Verzögerung, andere erforderliche Hardware). Dringende Empfehlung ist daher, schon für die Projektplanung die FuSi zu berücksichtigen und sie zeitlich, personell und finanziell zu berücksichtigen. Liegt die Kompetenz innerhalb der Firma (noch) nicht vor, können entsprechende externe Fachleute zu Rate gezogen werden. |
 |
|
Der Safety Case ist weder ein Koffer noch ein Fall, wobei der Koffer noch am naheliegendsten ist. Der Safety Case soll „das Argument“ liefern, warum die funktionale Sicherheit erreicht ist. Tatsächlich handelt es sich nach Idee der ISO 26262 um eine in Analogie zum Safety Plan geführte Argumentation(skette), warum der Autor/ die Entwicklungsabteilung glaubt, dass die funktionale Sicherheit erreicht sei. Demnach ist der Sicherheitsnachweis, wie der Safety Case in deutschsprachiger Literatur teilweise genannt wird, idealerweise eine sinnvoll und verständlich gestaltete Zusammenfassung sämtlicher Work Produkts, die der Safety Plan aufführt, ergänzt um Verweise auf deren ungekürzte Dokumentation, mit dem Ziel, dem Assessor nahezubringen, warum die funktionale Sicherheit durch das jeweilige Work Product begünstigt bzw. in Summe der Work Products für das Item erreicht wird. Der Safety Case ist folglich kein dokumentierter Informationszuwachs, sondern eine zusammenfassende Handreichung für den Assessor. Auch ermöglicht er durch seine Erstellung dem Autor selbst eine Überprüfung der Vollständigkeit und Konsistenz des Sicherheitskonzeptes, seiner Umsetzung und der Nachweisführung (Verifications und Confirmation Measures). |
 |
|
Die Dekomposition setzt voraus, dass die aufgeteilte Sicherheitsfunktion von mehreren ausreichend unabhängigen Teilfunktionen ausgeführt wird. Darf beispielsweise die Abstandsautomatik mit ASIL C nur für Geschwindigkeiten kleiner gleich 120 km/h verwendet werden, weil sie darüber zu ungenau wird, so ist die entsprechende Absicherung dieser Anforderung darauf angewiesen, dass die Geschwindigkeit und die Aktivierung der Abstandsautomatik beide mit ASL C abgesichert sind. Könnte es nicht aber auch ausreichen, die Geschwindigkeit mit ASIL kleiner C zu detektieren und auszuwerten, wenn gleichzeitig und unabhängig eine Funktion die Abstandregelung nur aktiviert, wenn die Geschwindigkeit im erlaubten Bereich liegt ? In diesem Beispiel wird behauptet, dass die Anforderung auf einen ASIL B und einen ASIL A aufgeteilt wird. Durch ihre Herkunft von ursprünglich ASIL C muss der Ursprung entsprechend dokumentiert werden. Die ISO 26262:2018 verwendet hierfür die Nomenklatur des Ursprungs-ASILs in Klammern hinter dem dekomponierten ASIL. Folglich ist die Geschwindigkeit jetzt mit einem ASIL B(C) behaftet und die Freigabe der Abstandsautomatik mit ASIL A(C). Durch die unterschiedlichen Aufwände der Realisierungen, die mit zunehmendem ASIL in der Regel steigen, kann es manchmal lohnend sein, zu dekomponieren. Anders herum ist es manchmal so, dass bereits mehrere Sensoren und/oder Aktoren vorhanden, die gemeinsam eine „höhere Aufgabe“ übernehmen könnten. Sind sie voneinander ausreichend unabhängig und somit gegen abhängige Fehler ausreichend abgesichert, so bedarf es für die fiktive Beispielfunktion keiner neuen Komponente höhere Sicherheitsintegrität. Gerade im Kontext Platzbedarf sowie Material- und Entwicklungskosten ist dieser Ansatz oft attraktiv. Zur Rechtfertigung des Ansatzes ist eine Analyse abhängiger Fehler erforderlich. Ebenso sind die Anforderungen an die Hardwaremetriken (siehe Buch 5 Kapitel 8 und 9) zu beachten, da diese gemäß ISO 26262‑9:2018 für die Gesamtfunktion gleichbleiben müssen. Aufgrund dieser Tatsache ist die Dekomposition nicht immer leicht umsetzbar. |
|
|
|
Buch 2 Absatz 6.4.5 befasst sich mit diesem Thema. Hier heißt es, dass für eine bestimmte Produktentwicklung von den „allgemeinen“ Anforderungen der ISO 26262:2018 abgewichen werden darf, wenn die Abweichung: Legitime Gründe für Anpassungen von Sicherheitsaktivitäten sieht selbige Normstelle im Kontext von: Einfach gehalten geht es um das, wonach es klingt. Ein normativ beschriebener Prozess wie die Verwendung eines gesamten, unveränderten Items für einen neuen Kontext (z. B. Einsatz unter neuen Umwelteinflüssen) muss bezüglich der neuen Einsatzbedingungen und deren Einfluss auf die funktionale Sicherheit hin untersucht werden. Nach Absatz 6.4.3.3 müssen relevante Safety Activities erneut durchlaufen werden. Ist in einem plakativen Beispiel das Item für Einsatz in chemisch aggressiven Flüssigkeiten bei Temperaturen von -20 °C bis +80 °C konstruiert und wird künftig nur noch Spritzwasser von der Straße ausgesetzt, so kann man argumentieren, dass die veränderten Temperaturbedingungen nicht erneut betrachtet werden müssen, obwohl die Norm das verlangen würde. Ähnliche Beispiele lassen sich gelegentlich für die weiteren aufgeführten Anwendungsfelder des Tailorings finden. |
|
|
|
Normteil 1 ist ein Nachschlagewerk, das sich lediglich mit Definitionen von Begrifflichkeiten in der Norm befasst. Insbesondere, wenn Normpassagen nicht ausreichend eindeutig erscheinen, kann ein Blick hierher hilfreich sein. Normteil 2 sollte als Grundvoraussetzung verstanden werden, ohne deren Umsetzung innerhalb der Firma keine automotive Anwendungen entwickelt werden können, wenn das Produkt der ISO 26262 genügen soll. Normteil 3 beschreibt den Beginn eines FS relevanten Projektes. Hier wird beschrieben, wie das Entwicklungsprojekt zu definieren und abzugrenzen ist. Auch die Definition potentieller Gefahren, deren Risikoanalyse mit Quantifizierung, resultierende Sicherheitsziele und das darauf basierende funktionale Sicherheitskonzept werden hier erläutert und bilden die projektspezifische Grundlage für alle weiteren Schritte. Wird in Normteil 4 das System auf einer mäßig detaillierten Ebene betrachtet, so gehen die Bücher 5 und 6 der Norm bezüglich HW und SW sehr tief ins Detail und erfordern auch die Definition der Schnittstellen zwischen Hardware und Software, um das jeweilige Gewerk normkonform im System zusammenfügen zu können. Teil 7 der Norm befasst sich mit dem Leben nach der Entwicklung. Fertigungsrelevante Aspekte der funktionalen Sicherheit (wie wird sie bei der Produktion nicht gefährdet? Auf was muss besonders geachtet werden?) und entsprechend für den Fahrzeugnutzer oder Servicetechniker wichtige Information wird abverlangt. Buch 8 der Norm beschreibt sogenannte Hilfsprozesse. Hier wird beschrieben, was bei Nennung in der Norm nicht erklärt und als selbstverständlich vorausgesetzt wird. Wie definiert die ISO 26262 eine Verifizierung oder welche Anforderungen werden hier an Change Management, dokumentierte Information oder die Verwendung von Softwaretools zur Entwicklungsunterstützung gestellt? Antworten findet man hier zahlreich. Ähnlich verhält es sich mit Normteil 9 und den Sicherheitsanalysen. Auch hier wird allgemeines spezifiziert und uneindeutiges oft klar. Normteil 10 kann wie Teil 1 als klärende Handreichung verstanden werden, dessen Lektüre grundsätzlich zu empfehlen ist. Für erfahrene Anwender dienen sie allerdings meist eher als eine Art Nachschlagewerk, wenn man sich an bestimmten Punkten entweder vergewissern möchte, oder Argumentationshilfe sucht. Die Normteile 11 und 12 sind seit 2018 neu und sollen für mehr Klarheit sorgen. So können sich beispielsweise Chiphersteller für automotive Anwendungen in Buch 11 der Norm Handreichungen holen, um den Chip für die favorisierte Endanwendung im Fahrzeug angemessen auszulegen. Teil 12 adaptiert die übrige Norm punktuell für Motorräder, um sie für die teilweise anderen Anwendungsbedingungen angemessener zu gestalten. Seither hat sie auch für Motorräder Gültigkeit. |
|
|
|
Da Firmen, die für die Automobilindustrie tätig sind in der Regel bereits ein etabliertes Qualitätsmanagementsystem gemäß ISO 9001 oder IATF 16949 haben, ist sowohl diese Anforderung als auch das Kompetenzmanagement meist keine Neuerung. Dadurch werden bereits allgemeine Qualitätsgrundsätze eingefordert und beispielsweise durch den Einsatz fachlich kompetenten Personals in allen relevanten Bereichen befolgt. Die wesentliche Ergänzung heißt demnach, dass weitere spezifisch für die funktionale Sicherheit erforderliche Grundsätze zu definieren und auszurollen sind. Gibt es in den Entwicklungsgrundsätzen von Hard- und Software relevante Anforderungen zur Berücksichtigung funktionaler Sicherheit ? Das könnte beispielsweise Hardware-seitig abhängig von der Sicherheitsanforderung die Bauteilauswahl betreffen (FIT-Rate, Automotive-Qualifizierung) oder die Architektur (Signalredundanzen). Bezüglich des Prozesses heißt das andererseits, werden ausreichend umfängliche und tiefgehende Entwicklungsprüfungen durchgeführt ? Haben diese neben Qualitätsstandards auch die funktionale Sicherheit im Blick ? Letztlich ist die Sicherheitskultur das Ergebnis aller Bemühungen des Overall Safety Managements: das mental vorhandene, im Funktionale Sicherheit Managementsystem dokumentierte und in der Umsetzung von Projekten überprüfbare Bewusstsein für die Angelegenheiten der Funktionalen Sicherheit. Ein Beispiel für ein Funktionale Sicherheit Managementsystem ist das FuSi-Portal der Ingenieurbüro Bernd Hölle GmbH. Es gibt einen Überblick über die Phasen des Sicherheitslebenszyklus und deren Inhalte, Anleitungen zur Umsetzung normativer Anforderungen, bietet Dokumentationsvorlagen für die meisten Work Products und Erklärungen für alle 102 verschiedenen Work Products der ISO 26262018. |
 |
 |
|
|
|
Die Produktion muss die funktionale Sicherheit gewährleisten. Folglich müssen Aspekte, die hier potentiell abträglich wirken, ausgeschlossen werden können. Das heißt beispielsweise, dass der Produktionslenkungsplan zu ergänzen ist und möglicherweise auch weitere Maschinenfunktionen für die Fertigung erforderlich sein können. Im Betriebsfall sollte der Produktanwender wissen, dass er mit seinem Fahrzeug in die Werkstatt muss, wenn das ABS nicht mehr funktioniert. Wie erfährt er das ? Entsprechende Hinweise im Handbuch des Fahrzeugs (Zeichenerklärung) sowie Wartungsintervallvorgaben können hier eine Maßnahme sein. Damit der Servicetechniker weiß, wie er ohne Erzeugung von Anwendergefahren agieren kann, muss auch für ihn eine entsprechende Dokumentation erstellt werden. Selbst für Rettungskräfte muss der Entwickler mitdenken. Woher weiß denn die Feuerwehr, wo sie ein Auto aufschneiden darf, ohne dass ein Seitenairbag aufgeht ? Oder kann dieser Fall schon vorab technisch umgangen werden ? Meist gibt es hierzu allgemeine Leitlinien für Rettungskräfte, an deren Einhaltung sich der Entwickler (freiwillig) orientiert. Eine Belegdokumentation ist dennoch erforderlich. Auch hier gilt die Beziehung zwischen Dokumentation und Haftung: wer schreibt, der bleibt. Der Fertiger eines Produktes soll belegen, dass er in der Lage ist, den Ansprüchen der funktionalen Sicherheit gerecht zu werden. Hierzu fordert die Norm den Production Process Capability Report als Nachweis. Dieser ist auch bei Inhouse-Fertigung zu erstellen und ist nicht nur eine Dokumentationsanforderung für Auftragsfertiger. Zur Entdeckung bislang unbekannter Fehler ist eine Feldüberwachung sinnvoll (und auch normativ gefordert), die entweder in Echtzeit oder durch Auslesen des Fehlerspeichers in einer Autowerkstatt eine Fehlererkennung ermöglicht. So ist der Hersteller in der Lage, das Produkt über einen änderungsprozess bezüglich funktionaler Sicherheit (und auch anderweitig) zu verbessern. Phase 3 beschreibt folglich insbesondere den Bereich des Produktlebenszyklus, der vom Kunden oder Endanwender begleitet wird. Trotz seiner inhaltlichen Kürze ist Normteil 7 daher die entsprechende Aufmerksamkeit zu widmen. |
|
|
|
Systemseitig geht es um die Festschreibung einer Architektur, um Entwicklungsaufgaben, auch innerhalb derselben Firma, besser delegieren zu können und eine Möglichkeit zu schaffen, die funktionalen Aufgaben des Systems zur Erreichung der funktionalen Sicherheit (so auch die technischen Sicherheitsanforderungen, die sich aus den funktionalen Sicherheitsanforderungen ableiten) entsprechend zuzuweisen. Auch die Integration diverser Komponenten in das System und die Prüfung der korrekten Interaktion sämtlicher Subsysteme/ Bausteine ist gemäß Normteil 4 zu planen. Hardware und Software bedingen sich gegenseitig, werden aber meist von verschiedenen Menschen oder gar Abteilungen entwickelt. Entsprechend wichtig ist die gute Abstimmung zwischen diesen Disziplinen. Hierzu verlangen die Normteile 4, 5 und 6 daher unter anderem die Definition der Hardware-Software-Schnittstelle. Wird die Entwicklung in verschiedenen Firmen durchgeführt, ist zusätzlich ein Development Interface Agreement DIA (ISO 26262-8, Kapitel 5) gefordert. Des Weiteren ist die Architektur der Hardware und Software so zu entwickeln, dass neben dem Primärziel (beispielsweise Lenkerleichterung) auch die bestmögliche Verhinderung von Sicherheitszielverletzungen (Lenkung darf nicht blockieren) erreicht wird. Die beste Software nützt hier nichts bei unangemessener Hardware. Andersherum kann sicherlich eine clevere Hardwarearchitektur manchen Softwarefehler egalisieren, sicherlich aber auch nicht jeden. Hardwareseitig führt man daher Analysen zur Ausfallwahrscheinlichkeit und Fehlerabhängigkeiten durch, um sowohl die Risiken zufälliger Hardwarefehler zu minimieren als auch systematische Fehler zu entdecken. Softwareseitig wird auf systematische und abhängige Fehler hin untersucht, da zufällige Fehler hier quasi nicht existent sind. Ist die Phase 2 abgeschlossen, sollte Phase 3 bereits in vollem Gange sein. Diese beiden Phasen behandeln zeitlich aufeinanderfolgende Abschnitte des Sicherheitslebenszyklus, sind allerdings zwingend zeitlich parallel zu planen. |
|
|
|
Ist eine Firma nicht in der Lage, alle Disziplinen eigenständig abzudecken (z.B. Kompetenz oder Kapazität nicht vorhanden, Eigenfertigung zu teuer), ist Normteil 8 der ISO 26262 gefragt. Hier wird beispielsweise der Umgang mit verteilter Entwicklung bzw. ausgelagerter Fertigung im Kontext funktionaler Sicherheit behandelt. Sollte dann womöglich noch jemand einen Verbesserungsvorschlag machen, ist dieser (bei aller Freude über die Idee) zwingend über den definierten Change Management Prozess einzubauen. ISO 26262‑8 Kapitel 8 stellt hierzu Anforderungen auf, die neben der Aufrechterhaltung funktionaler Sicherheit auch die Frage nach dem Mehraufwand berücksichtigt. Abgesehen von diesen „äußerlichkeiten“ gehört nach IBH-Definition auch die Konzeptphase aus Normteil 3 in die Phase 1 der funktionalen Sicherheit. Was ist eigentlich mein Entwicklungsgegenstand ? Gehört zum Lenkungssteuergerät das Gehäuse mit Schirmung dazu, oder muss der Verbauort hierfür bürgen? Soll die Traktionsbatterie sich selber überwachen oder geht es im Batteriemanagementsystem nur um die Leistungsoptimierung ? Sieht die Anforderung auf den ersten Blick eindeutig aus, lohnt sich der Zweite Blick dennoch (fast) immer. Auf Basis der Systembeschreibung (Item Definition) ist eine Gefährdungsanalyse (Hazard Analysis and Risk Assessment HARA) gefragt. Kann das Airbag-Steuergerät im Fehlerfall den Fahrer während der Fahrt gefährlich beeinflussen ? Ja. Geht vom Bremsregelassistent eine Gefahr für den Fahrer im Stillstand aus ? Vermutlich nicht oder kaum. Aus einer ausreichend detaillierten Situationsanalyse und quantifizierten Bewertung entdeckter Gefahrenpotenziale ergeben sich dann Sicherheitsziele. Diese wiederum sollen durch die Definition von funktionalen Sicherheitsanforderungen (ohne technisches Detailwissen) abgedeckt werden. Für die Durchführung der HARA und die Erstellung des funktionalen Sicherheitskonzeptes kann es sinnvoll sein, eine unbeteiligte Stelle zu Rate zu ziehen, selbst wenn die Kompetenz bei den Entwicklern vorhanden ist. Dadurch wird die Objektivität bei der Gefährdungseinschätzung gewährleistet. Ist die Phase 1 abgeschlossen, kann die eigentliche Entwicklung beginnen. |
|
|
|
Wenn man nach der obigen Aufzählung in den Geltungsbereich (Kapitel 1 jedes Normteils) der „ISO 26262:2018 Road vehicles – Functional safety“ schaut, dann stellt man fest, dass funktionale Sicherheit tatsächlich gerade hoch modern ist und es wohl künftig immer mehr wird. Da heißt es, die Norm sei anzuwenden auf sicherheitsbezogene Systeme, die elektrische und/ oder elektronische Systeme enthalten und in serienproduzierten Straßenfahrzeugen installiert sind. Was heißt jetzt aber sicherheitsbezogen ? Teil 1 der Normserie beinhaltet die Begriffserläuterungen und sagt, ein Element oder eine Funktion ist sicherheitsbezogen, wenn es/ sie potentiell zur Verletzung oder Erreichung eines Sicherheitsziels beitragen kann (ISO 26262‑1:2018, Absätze 3.144 und 3.145). Angewendet auf die Eingangsbeispiele stellt sich also jeweils die Frage, ob die Funktionen potentiell sicherheitsgefährdend oder -fördernd sein können. Als kurze Vertiefung sei darauf hingewiesen, dass sich trotz Sicherheitsrelevanz ein Sicherheitsintegritätslevel von ASIL QM in der HARA herauskristallisieren kann, was in der Entwicklung außer ISO 9001- bzw. IATF 16949-Konformität keine weiteren Anforderungen bedeutet. Um welche Sicherheitsrisiken geht es dabei ? Scharfe Kanten und elektrischen Schlag ? Hierzu sagt der Norm-Scope, dass mögliche Gefährdungen betrachtet werden sollen, die durch Fehlfunktionen des sicherheitsbezogenen Elements verursacht werden. Gefährdungen wie elektrischer Schlag, Feuer, Rauch, Hitze, Strahlung, Gifte, Entflammbarkeit, Reaktivität, Korrosion, Energiefreisetzung oder ähnliche werden ausdrücklich nicht betrachtet, wenn sie nicht direkt durch eine Fehlfunktionalität des sicherheitsbezogenen Elements verursacht sind. Ein Beispiel aus der Praxis ist hier, dass elektrischer Schlag durch eine Traktionsbatterie grundsätzlich nicht zu betrachten ist. Bleiben die Leistungsanschlüsse allerdings in der demontierten Batterie schaltbar, so könnte eine Fehlfunktion zu einem elektrischen Schlag führen und muss berücksichtigt werden. Fast am interessantesten ist hier noch der Hinweis am Ende des Norm-Scopes, dass die Nominalfunktion von elektrischen/ elektronischen Systemen (E/E) ausdrücklich nicht betrachtet wird. Funktioniert der Airbag wie definiert, sind aus dieser beabsichtigten Funktion heraus resultierende Gefährdungen (Verbrennungen, Prellungen, etc.) folglich nicht Teil der funktionalen Sicherheit. |
|
|
|
Nach ISO 26262‑1:2018 3.32 (Normteil der Begriffserklärungen) ist das DIA eine Vereinbarung zwischen Kunde und Zulieferer, in der die Verantwortlichkeiten für auszuführende Tätigkeiten, auszutauschende Dokumente sowie zu prüfende Nachweise definiert werden. Die Norm weist auch darauf hin, dass das DIA die Entwicklungsphase betrifft, das Supply Agreement wiederum die Produktionsphase. Entwickelt beispielsweise ein Batteriehersteller eine Traktionsbatterie und lässt das Batteriemanagementsystem (BMS) fremdentwickeln, so fordert die ISO 26262‑2:2018 in Abs. 6.4.6.4 und die ISO 26262‑8:2018 in Abs. 5.4), dass die Hersteller von Batteriesystem und BMS genau klären, wo die Komponenten abgegrenzt sind, wie die Schnittstellen aussehen und wer für welche Entwicklungsaufgaben zuständig ist. Außerdem wichtig ist die Definition der auszutauschenden Dokumente. Der BMS-Entwickler benötigt die systemseitige Definition der Hardware-Software-Schnittstelle und sonstiger Systemübergänge und Interkationen. Anders herum möchte der BMS Hersteller womöglich nicht unnötig viel Spezialwissen über seine Software preisgeben und liefert daher (vertraglich vereinbart) nur den zwingend erforderlichen Teil der Information mit dem BMS an den Batteriehersteller aus. Oftmals ist eine uneingeschränkte Einsichtnahme des Herstellers des übergeordneten Systems bei seinem Zulieferer zur überprüfung der Produktqualität und Detailabstimmung gewünscht bis erforderlich. Deshalb ist für jeden Informationsaustausch sinnvoll, auch die Austauschart festzulegen (u.a. vollständige übergabe, beschränkte übergabe und nur begleitete Einsichtnahme vor Ort beim Zulieferer.) Um die Zeitschiene des Gesamtprojektes sicherzustellen, sind auch für die Zulieferkomponenten entsprechende Zeitlimits zu definieren. Muss der Systemhersteller das System zum Datum X an seinen Kunden ausliefern, sollten die zugelieferten Komponenten entsprechend früher definiert, entwickelt, abgestimmt, integriert und angemessen getestet worden sein. Die nachfolgende Tabelle soll eine Idee geben, welche Aspekte in einem DIA abgestimmt werden sollten. Projektspezifisch sind beliebige Ergänzungen möglich. Projektmeilensteine sollten mindestens im Projektplan mit realen Kalenderdaten versehen sein, sodass man beispielsweise im DIA auf die dortige Zeitschiene referenzieren kann. Eingangs wurde noch das Supply Agreement erwähnt. Es dient der vertraglichen Vereinbarung von Fertigungseckdaten wie Stückzahlen, Zielterminen, anzuwendenden Qualitätsstandards und, hier natürlich im Fokus, der Sicherstellung der funktionalen Sicherheit in der Fertigung. Es sollte also definiert werden, welche Maßnahmen in der Fertigung bezüglich Funktionale Sicherheit zu ergreifen sind, um diese im Produktbetrieb zu gewährleisten (u.a. Handling-Anweisungen, Anschluss- und Testprozeduren). |
|
|
|
In der ISO 26262 ist zu Audit und Assessment sinngemäß folgendes angegeben: Das Functional Safety Audit beurteilt die implementierten Prozesse zur Erreichung der funktionalen Sicherheit. Das Funktional Safety Assessment beurteilt die erreichte funktionale Sicherheit des Items bzw. den Beitrag zur Funktionalen Sicherheit durch die betrachteten Systemkomponente(n). Bei einem Functional Safety Audit geht es also darum, die firmenseitig dokumentierten FS Prozesse und ihre projektspezifische Umsetzung auf Normkonformität und spezifische Tauglichkeit zu prüfen. Letzteres wird durch den Safety Plan unterstützt, der die Planung der jeweils projektspezifischen Anwendung der Prozesse wiedergibt. Eine Richtlinie für inhaltliche Schwerpunkte des Audits ist in ISO 26262‑2:2018 6.4.11 gegeben. Hierzu gehören: • Beurteilung der implementierten Prozesse gegen ihre normativen Anforderungen, • Beurteilung der Safety Plan Outputs gegen firmenspezifische Regeln und Prozesse • Beurteilung eventueller Argumentationen, warum die Prozesse den normativ angestrebten Zielen genügen, • Beurteilung der Verfügbarkeit vom Safety Plan geforderter Work Products, • Beurteilung, ob die genannten Work Products den normativen Anforderungen entsprechen und • Empfehlungen, wie etwaige Nichteinhaltungen von Anforderungen behoben werden können. Das Functional Safety Assessment ist gemäß Norm kein synonym gebrauchtes Wort zum Functional Safety Audit, sondern betrachtet neben dem Auditergebnis auch die Umsetzung der funktionalen Sicherheit am Produkt selbst. Dabei wird nicht bewertet, wie die funktionale Sicherheit erreicht wurde, sondern ob. Dazu sind inhaltliche Handreichungen gegeben in ISO 26262‑2:2018 Kapitel 6.4.12 sowie in Anhang C.12 und Anhang D. Das Functional Safety Assessment soll anhand des Safety Plans die Erreichung der funktionalen Sicherheit des betrachteten Items untersuchen und dazu sämtliche Work Products des Safety Plans berücksichtigen. Hierfür ist es hilfreich, wenn ordnungsgemäß und detailliert erstellte Berichte von Verifizierungen und Confirmation Measures vorliegen. Da letztere bereits in angemessener Unabhängigkeit erstellt werden müssen (wie übrigens auch Audit und Assessment selbst), ist es ausreichend, sich bei der Beurteilung im Assessment auf den nur durch Stichproben geprüften Bericht zu stützen. Auch der Audit Bericht ist solch ein Confirmation Measure Report. Der Safety Case ist dem Assessor ebenfalls eine große Hilfe, da er zusammenfassend die Erreichung der funktionalen Sicherheit aus Perspektive des jeweiligen Work Product Autors argumentiert. Inhalte des Functional Safety Assessments sind u.a.: • Bewertung der Normkonformität der dokumentierten Work Products, • Bewertung des jeweiligen Work Product Beitrags zur Erreichung der funktionalen Sicherheit, • Bewertung der Normkonformität implementierter Prozesse (insbesondere den Auditbericht), • Bewertung implementierter Sicherheitsmechanismen, • Beurteilung von Argumentationen, warum die Work Products den normativen Zielen genügen und • Empfehlung, ob das Item als funktional sicher betrachtet werden kann. |
|
|
 |