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


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