☎ (0 71 21) 8 20 17 40 STARTSEITE
   FUSI-BLOG   
   TIPPS UND TRICKS ZU   
   SYSTEM UND METHODEN   
FUSI-BLOG


FUNKTIONALE SICHERHEIT - AB WANN IM PROJEKT ?

von Timo Lang vom 12.08.2022
Ein neues interessantes Entwicklungsprojekt wird an Land gezogen, der Projektplan wird erstellt, die Lastenheftanforderungen an die jeweiligen Abteilungen delegiert. Das Gerüst mit seine Kernelementen wird zuerst in Angriff genommen, danach das subjektiv naheliegendste. Ist die Funktionale Sicherheit nicht Hauptaufgabe des Produktes, sondern eine von vielen Anforderungen, wissen manche Entwickler nicht sofort etwas damit anzufangen und schieben diese Punkte vor sich her. Vielleicht fragt sich sogar der eine oder andere, wann diese „sonderbaren“ Anforderungen bearbeitet werden und um was genau es dabei eigentlich geht, fallen doch Fremdwörter wie Sicherheitsintegrität, ASIL, FIT-Rate, fault tolerant time interval oder ähnliches mehr.

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.


SAFETY CASE

von André Fuchs vom 25.03.2022
ISO 26262‑2:2018 Kapitel 6.4.8 fordert die Erstellung des Safety Case. Da schon allein der Begriff für viel Verwirrung sorgen kann, sei hier ein Abriss zu seinem Inhalt und Nutzen gegeben.

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).


DEKOMPOSITION - FÜR ODER GEGEN BEETHOVEN ?

von Franz Montowski vom 15.12.2021
Es ist ein komischer Begriff und tatsächlich nahe am gebräuchlichen Wort „Komposition“ dran. Setzte Beethoven Noten zusammen zu einer Komposition, so nimmt die Dekomposition gemäß ISO 26262‑9:2018, Kapitel 5 Sicherheitsanforderungen auseinander, um sie „häppchenweise“ auf verschiedene Komponenten oder (Sub)-Systeme zu verteilen. Die Idee dabei ist, dass eine Sicherheitsfunktion mit hohem Sicherheitsintegritätslevel womöglich genauso gut von mehreren Sicherheitsfunktionen geringerer Sicherheitsintegrität gemeinsam übernommen werden könnte. Aber wie genau und mit welchen Randbedingungen ?

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.


TAILERING - WER SCHNEIDERT WAS UND WARUM ?

von Franz Montowski vom 07.06.2021
Konformität mit der ISO 26262:2018 wird dadurch erreicht, dass sämtliche zutreffende Anforderungen erfüllt und dies geeignet bestätigt wird. Ausnahmen sind nur möglich durch nachvollziehbare und überprüfte Begründung, warum eine Nichtkonformität akzeptabel sei oder bei Anwendung von „Tailoring“ von Sicherheitsaktivitäten, was beispielsweise eine reguläre Anforderung ausklammert oder als unzutreffend beschreibt (ISO 26262:2018, jeder Normteil Absatz 4.2). Aber was genau darf denn jetzt in welchem Umfang zu welchem Zweck geschneidert werden ?

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:

  • entsprechend im Safety Plan definiert ist und
  • ausreichend glaubhaft begründet werden kann, dass trotz Abweichung funktionale Sicherheit erreicht wird

    Legitime Gründe für Anpassungen von Sicherheitsaktivitäten sieht selbige Normstelle im Kontext von:

  • Einflussanalyse bei Verwendung von Komponenten aus verwandter Vorgängeranwendung,
  • Proven in use Arguments,
  • Hardwareevaluation,
  • Softwarequalification,
  • Confidence in the use of Softwaretools,
  • Safety Elements out of Context (SEooC),
  • Bei Trucks and Busses für Kombinationen von Komponenten aus dem Safety- und non-Safety-Bereich.

    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.


  • NORMSTRUKTUR ISO 26262:2018

    von Timo Lang vom 04.03.2021
    Die Funktionale Sicherheit (FS) gemäß ISO 26262:2018 für seriengefertigte Radfahrzeuge (inkl. LKW, Busse und Motorräder) ist ein Gebilde, das in zwölf Normteilen beschrieben wird. Um hier den Überblick zu behalten, ist die Norm nach inhaltlichen Schwerpunkten gegliedert:

    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.


    OVERALL SAFETY MANAGEMENT

    von Franz Montowski vom 29.01.2021
    Overall Safety Management ? Ist das was für die Textilindustrie ? Vielleicht auch. Overall meint im Kontext der ISO 26262:2018 allerdings weniger den Jumpsuit oder den Malerkittel, sondern das Allumfassende, Grundlegende. Insbesondere wenn die Funktionale Sicherheit nach ISO 26262:2018 für eine Firma neu ist, kommen viele Fragen auf. Was genau ist diese funktionale Sicherheit ? Was müssen wir dafür alles tun ? Das, was die Norm als Overall Safety Management bezeichnet, beinhaltet die Implementierung der firmenspezifisch relevanten Grundsätze und Prozesse zur Erreichung funktionaler Sicherheit, die Einführung von Kompetenzmanagement und Qualitätsmanagement sowie die damit einhergehende Institutionalisierung einer so genannten Sicherheitskultur (ISO 26262‑2:2018 Abs. 5.1).

    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.

    → Zum IBH FUSI-PORTAL ...


    DAS IBH FUSI-PORTAL

    von Bernd Hölle vom 23.10.2020
    Was verlangt die ISO 26262 von mir ? Welche Prozesse zur Umsetzung der Funktionalen Sicherheit benötige ich ? Welche Arbeitsergebnisse (Work products) sind gefordert ? Wie soll ich dokumentieren ? Jeder der erstmalig mit einem Funktionale Sicherheit Projekt startet, stellt sich diese Fragen. Die IBH hat ein digitales FUSI-PORTAL entwickelt, das Einsteigern einen Rahmen bieten soll.



    → Zum IBH FUSI-PORTAL ...


    FUNKTIONALE SICHERHEIT ALS PHASENMODELL - TEIL 3 VON 3

    von Franz Montowski vom 02.10.2020
    Die IBH betrachtet für die Produktentwicklung unter dem Aspekt der funktionalen Sicherheit drei Phasen. Phase 3 beinhaltet die Planung der Produktion, des Betriebs, des Services und der Außerbetriebnahme eines Items mit Anforderungen an die funktionale Sicherheit. Der betrachtete Zeitraum liegt folglich nach Phase 2, sollte aber schon während dieser geplant werden, um unnötigen Zeitverzug zu vermeiden (z.B. müssen Fertigungsmaschinen schon während der Entwicklung bestellt werden).

    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.


    FUNKTIONALE SICHERHEIT ALS PHASENMODELL - TEIL 2 VON 3

    von Franz Montowski vom 28.08.2020
    Wir von der Ingenieurbüro Bernd Hölle GmbH (IBH) betrachten für die Produktentwicklung unter dem Aspekt der funktionalen Sicherheit drei Phasen. Phase 2 beinhaltet dabei nach unserer Definition die eigentliche Produktentwicklung auf den Ebenen System, Hardware und Software. Die entsprechenden Normteile sind die Bücher 4, 5 und 6 der ISO 26262 enthalten. Ergänzend ist auch Buch 8 von Relevanz, falls bereits existente Hardware- oder Softwarekomponenten zum Einsatz kommen sollen. Dort wird beschrieben, wie vorhandene Sicherheitsnachweise entsprechend überprüft und ergänzt werden müssen, um die funktionale Sicherheit auch bei neuerlicher Anwendung mit eventuell völlig neuem Zweck oder auch nur leicht veränderten Einsatzbedingungen dennoch sicherzustellen.

    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.


    FUNKTIONALE SICHERHEIT ALS PHASENMODELL - TEIL 1 VON 3

    von Franz Montowski vom 14.08.2020
    Phase 1 beinhaltet das Overall Safety Management und die Konzeptphase. Insbesondere für Neulinge im Bereich der funktionalen Sicherheit ist hierauf besonderes Augenmerk zu richten. Bezogen auf die ISO 26262 befasst sich Phase 1 insbesondere mit den Büchern 2, 3 und 8 der ISO 26262. Ziel des Overall Safety Managements in Normteil 2 ist das mental vorhandene, im Managementsystem der funktionalen Sicherheit dokumentierte und in der Umsetzung von Projekten überprüfbare Bewusstsein für die Angelegenheiten der Funktionalen Sicherheit. Das heißt, dass ähnlich dem allseits bekannten Qualitätsmanagementsystem gemäß ISO 9001 oder IATF 16949 ein Managementsystem der funktionalen Sicherheit existieren muss. Dazu gehören firmenspezifische Prozessbeschreibungen, wie die funktionale Sicherheit in den firmentypischen Entwicklungsschritten sichergestellt werden soll. Genauso aber auch grundlegendere Angelegenheiten wie ein Kompetenzmanagement (kein Koch am Stromkasten), Qualitätsmanagement (Qualitätsüberwachung ist Grundvoraussetzung für Produktsicherheit) und der Umgang mit dokumentierter Information, allgemein und bezüglich funktionaler Sicherheit (wie schreibe ich es am besten auf, damit niemand mich versteht oder meine Notizen jemals findet ?).

    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.


    FUNKTIONALE SICHERHEIT - IST DAS NEUERDINGS MODERN ?

    von Franz Montowski vom 07.08.2020
    Je neuer die Autos sind, umso mehr elektrische und elektronische Systeme enthalten sie. Neben der Selbstverständlichkeit von elektrisch verstellbaren Außenspiegeln, elektrischen Fensterhebern und Sitzeinstellungen gibt es weitere Komfortfunktionen wie automatisch abblendende Spiegel, Klimaautomatik, LED-Scheinwerfer mit Abblendautomatik, Regensensor für automatische Scheibenwischer und noch vieles mehr. Versteckter sind da die Assistenzprogramme wie ABS, ESP, Bremsregelassistent, elektronisch gesteuerte Lenkunterstützung und manches mehr. Natürlich gibt es dann auch noch Assistenten für teilautomatisiertes Fahren wie Abstands-, Spurhalte- und Geschwindigkeitsregelautomatik, die auch elektronische Systeme sind.

    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.


    DIA - EIN ALTERTÜMLICHES BILDMEDIUM ?

    von Timo Lang vom 23.07.2020
    Urlaubsfotos den Nachbarn auf Leinwand zeigen, oder was war das noch mit diesem DIA ? In der ISO 26262:2018 steht DIA als Abkürzung für Development Interface Agreement und beschreibt nichts anderes als der deutschsprachige Begriff Entwicklungsschnittstellenvereinbarung, der schon lange vor Aufkommen der funktionalen Sicherheit im Automobil branchenübergreifend Verwendung fand. Und was versteckt sich inhaltlich hinter dieser länglichen Floskel ?

    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).


    FUNCTIONAL SAFETY AUDIT VERSUS FUNCTIONAL SAFETY ASSESSMENT

    von Franz Montowski vom 17.07.2020
    Die ISO 26262-2:2018 6.4.9 beschreibt Confirmation Measures und fordert diese als Maßnahmen zur Bestätigung des Systems der Funktionalen Sicherheit. Nach Absatz 6.4.9.1 beinhalten die Confirmation Measures das Confirmation Review, das Functional Safety Audit und das Functional Safety Assessment. Was ist ein Functional Safety Audit und was ein Functional Safety Assessment ?

    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.


    IHR PARTNER FÜR FUNKTIONALE SICHERHEIT


    INGENIEURBÜRO BERND HÖLLE GMBH

    Technologiepark Tübingen-Reutlingen
    Gerhard-Kindler-Straße 3
    72770 Reutlingen

    ☎ (0 71 21) 8 20 17 40
    ✉ info@myibh.de
    🌍 myibh.de