Funktionale Sicherheit für Elektrofahrzeuge
Ic Sharp Arrow Downward

Wie schützt mich FuSi vor dem GAU* und dem DAU**?
Wir führen Sie ans Thema heran und begleiten durch den Normen-Dschungel.

Relevanz für Entwickler

Entwicklung heisst Verantwortung

Wenn etwas schief geht und es zu (Personen-) Schäden kommt, müssen Sie als Projektleiter oder Geschäftsinhaber bei Haftungsfragen die Verantwortung für die entwickelten und verkauften Produkte übernehmen. Die Funktionale Sicherheit hilft Ihnen, diese zu tragen.

Wer sagt, dass ich haftbar bin?

Schon vor Jahrzehnten hat jedes Land Produkthaftgesetze erlassen. Mit der EU wurde die ”Richtlinie 85/374/EWG des Rates vom 25. Juli 1985 zur Angleichung der Rechts- und Verwaltungsvorschriften der Mitgliedstaaten über die Haftung für fehlerhafte Produkte” geschaffen, welche folgendes vorsieht:

Relevanz der FuSi

«(…) Der Schutz des Verbrauchers erfordert es, daß alle am Produktionsprozeß Beteiligten haften, wenn das Endprodukt oder der von ihnen gelieferte Bestandteil oder Grundstoff fehlerhaft war. Aus demselben Grunde hat die Person, die Produkte in die Gemeinschaft einführt, sowie jede Person zu haften, die sich als Hersteller ausgibt, indem sie ihren Namen, ihr Warenzeichen oder ein anderes Erkennungszeichen anbringt, oder die ein Produkt liefert, dessen Hersteller nicht festgestellt werden kann. (…)

Damit der Verbraucher (…) geschützt wird, ist zur Bestimmung der Fehlerhaftigkeit eines Produkts nicht auf dessen mangelnde Gebrauchsfähigkeit, sondern auf einen Mangel an Sicherheit abzustellen, (…). Bei der Beurteilung dieser Sicherheit wird von jedem mißbräuchlichen Gebrauch des Produkts abgesehen, (…).

(…) daß es dem Hersteller möglich sein muß, sich von der Haftung zu befreien, wenn er den Beweis für ihn entlastende Umstände erbringt. (…)

Der Schutz des Verbrauchers erfordert die Wiedergutmachung von Schäden, die durch Tod und Körperverletzungen verursacht wurden, sowie die Wiedergutmachung von Sachschäden. (…).»

Selbstverständlich verfügt auch die Schweiz über entsprechende Gesetze. Diese sind bekannt als «Bundesgesetz über die Produktesicherheit (PrSG) – Art. 930.11» und «Bundesgesetz über die Produktehaftpflicht (PrHG) – Art. 221.112.944» und weisen sehr ähnliche Inhalte auf, wie die der EU.

Rechtsprechungen erklären uns Gesetze

Die Gesetzestexte sind komplex verfasst und im Detail nicht immer einfach zu verstehen. Sieht man Rechtsprechungen (Gesetzte angewendet auf Einzelfälle) an, wird das Bild klarer. Die letzten Jahrzehnte haben gezeigt, dass der Hersteller garantiert für folgende Fehlertypen haftet:

  • Entwicklungsfehler (Anforderung, Systemdesign, Spezifikation)
  • Konstruktionsfehler
  • Fabrikationsfehler
  • Instruktionsfehler
  • Verletzung der Produktbeobachtungspflicht

Die Aufgaben der funktionalen Sicherheit

Menschen machen Fehler bei der Entwicklung, Produktion und – nicht zu vernachlässigen – bei der Bedienung. Selbst wenn in ferner Zukunft automatisierte Systeme von Anfang bis Ende von Maschinen entwickelt, produziert und gar bedient werden, bleibt der Verschleiss an Komponenten. Darunter fallen nicht nur mechanische, sondern auch elektrische Komponenten. Der menschgemachte Fehler, oder der Verschleiss rufen einen Fehler in der Maschine hervor, welcher eine Gefahr darstellen kann. Die Aufgabe der Funktionale Sicherheit ist es, Menschen und Umwelt vor Gefahren durch Fehler von (automatisierten) Systemen zu schützen. Zudem hilft sie im Falle eines rechtlichen Konflikts, die Haftung zu klären.

Wieso macht nicht jeder FuSi?

Alle Firmen, die sich «Safety First» auf die Fahne schreiben, müssten alle Produkte im Rahmen der Funktionalen Sicherheit entwickeln. Folgende Hindernisse und Fehler führen dazu, dass diese Firmen sich nicht an ihr eigenes Credo halten.

Aus der Sicht der Entwicklung

Folgende Herausforderungen ergeben sich im Rahmen einer Produktentwicklung. Dem Nachweis eines Sicherheitslevels sind sie nicht dienlich.

Fehlerhafte Spezifikationen

Die Ingenieurswelt ist Spezifikations- und Anforderungsbezogen. Anhand technischer Anforderungen werden Produkte und Dienstleistungen entwickelt, die die Aufgabe haben, die vorgesehene Funktion zu erfüllen. Davon sind alle Funktionen oder Mechanismen ausgeschlossen, die nicht explizit erwähnt werden.

Entwicklungen sind iterative Prozesse

Bei Produktentwicklungen durchläuft man oft mehrere Iterationen, bei denen Komponenten evaluiert und getauscht werden. Werden sicherheitskritische Komponenten geändert, müssen diese in den FuSi–Prozess eingearbeitet werden.

Sicherheit kostet Zeit und Geld

Eine Funktion, die nicht nur die technische Anforderung erfüllt, sondern auch Sicherheitsaspekte miteinbezieht, resultiert in einer Haupt-Funktion, die Nebenfunktionen hat, womit sich die Komplexität erhöht. So wird ein Produkt mehr Zeit in der Entwicklungsphase beanspruchen und damit insgesamt teurer.

Entwicklungen sind kreative Prozesse

Bei Entwicklungen kann man selten komplett auf 08/15-Komponenten zurückgreifen und sucht daher kreative Lösungen. In der Funktionalen Sicherheit müssen diese genaustens analysiert werden, was sich auf die Zeit und Kosten niederschlägt.

Aus Sicht der Disziplin „Funktionale Sicherheit“

Folgende Themen bilden sich aus der Natur der Funktionalen Sicherheit und deren Vorschriften:

FuSi ist kein Feature

Funktionale Sicherheit ist spitzfindig. Konkret heisst das, dass oft nicht das gesamte Produkt einen Sicherheitslevel erfüllt, sondern nur eine Teilfunktion eines Subsystems (z.B. ein Abschaltpfad).

FuSi ist Bestandteil der Entwicklung

Ein Produkt mit einem Sicherheitslevel fordert die gesamte Entwicklung des Produkts und dessen Dokumentation.

Ein bestehendes Produkt kann nicht auf einen Sicherheitslevel upgegradet werden

Wurde ein Produkt entwickelt, können im Nachhinein nicht andere Komponenten in der Erwartung verbaut werden, dass die Sicherheitslevel erreicht werden.

FuSi ist Bestandteil der Geschäftsprozesse

Darüber hinaus haben nicht nur die Entwickler, sondern auch die Produktion und das Management Aufgaben und Verantwortlichkeiten.

So haben wir das schon immer gemacht!

Um bei den Entwicklungsressourcen zu sparen, kürzt man bei Funktionen, die keine Anforderung an das Sicherheitslevel haben, ab (Vorsicht vor Spezifikationsfehlern!). Dann gibt es nur noch Fehler aus Anforderungen, oder Fehler aus dem Handgelenk des Ingenieurs, welche eventuell durch Gegenmassnahmen abgedeckt werden.

Entwicklungsprozess der Funktionalen Sicherheit
Functional Safety Layer Protection

Entwicklungsprozess der Funktionalen Sicherheit

Das führt zu einer Schwarz-Weiss-Sicht von Problemen. Diese Probleme oder Fehler fallen dann entweder in den Bereich «prozessualer Alarm» oder «Not-Abschaltung».

Verfügbarkeit vs. Sicherheit

Anders ausgedrückt: stört der Fehler den Prozess, oder nicht? Bei Funktionen, die keine Anforderung an den Sicherheitslevel haben, ist das auch nicht falsch. Ein guter Ingenieur fragt sich während der Entwicklung, ob der Zustand der Maschine gefährlich für Personen ist. Die meisten dieser Sicherheitsüberlegungen sind Bauchgefühl oder Erfahrung eines Ingenieurs und kommen nicht aus einer Hazard und Risk Analyse (H&R). Weiter schwingen dabei auch immer Gedanken an die Verfügbarkeit mit. Der Ingenieur will nicht wegen jedem noch so kleinen Problem einen Stillstand forcieren müssen. So wägt jeder Ingenieur «Sicherheitsrelevant» anders ab.

Von ISO 26262 bis IEC 62061

Die Funktionale Sicherheit hat ihren Ursprung in der Maschinenindustrie. Diese hat mit der IEC/EN 61508 ein allgemeines Regelwerk geschaffen. Daraus wurden branchenspezifische Standards abgeleitet (homologisiert). Um die branchenspezifischen Standards zu verstehen, sind Kenntnisse über die ISO 12100 und EN 61508 von grossem Vorteil.

Sprechen Sie FuSi?

Die Welt der FuSi ist ausschliesslich von Standards durchwachsen, die ein eigenes Vokabular mit sich bringen. Wie in jeder Ingenieursdisziplin, kommt man ohne den Jargon schwer voran. Die allgemeine EN 61508 hat 29 Seiten Begriffsdefinitionen und die branchenspezifische ISO 26262 verfügt über 32 Seiten Vokabular und Abkürzungen.

Alle machen mit!

Die FuSi erwartet nicht nur Extra-Leistungen aus der Entwicklungsabteilung, sondern auch von anderen Abteilungen. Das Management muss die unterstützenden Geschäftsprozesse auch auf die FuSi ausrichten und an Top-Level Reviews dabei sein und mitentscheiden. Falls das Gerät oder Fahrzeug in-house produziert wird, müssen auch die Produktionsprozesse dafür ausgelegt werden.

Kalkulierter Tod

Unabhängig von der Branche, wird in der Funktionalen Sicherheit mit Eintreffens-Wahrscheinlichkeit und Gefährdung gerechnet. Aus denen beiden Zahlen wird darauf das Risiko berechnet, dem man die Personen aussetzt. Dabei wird auch ausgerechnet, wie wahrscheinlich Tote beim Betrieb der Maschine sind.

Betrieb und Wartung

Die FuSi definiert nicht nur die Entwicklung und Produktion, sondern legt auch Gewicht auf den korrekten Betrieb und dieWartung. Deshalb ist nicht nur die Entwicklungsdokumentation, sondern auch die Kundendokumentation wichtiger Bestandteil einer FuSi-Entwicklung.

Rückruf, aber nicht am Telefon

Grosse Fahrzeughersteller haben sich schon verkalkuliert, oder nicht ausreichend getestet (Stichwörter MTBF, MTTF). Sie mussten Rückrufe starten, weil beispielsweise die Möglichkeit bestand, dass sich das Lenkradschloss während der Fahrt aktiviert.

Tschüss Not-Aus

In der Fahrzeugbranche beinhaltet der Schritt vom Prototypen zum Serienfahrzeug eine Entwicklung im Rahmen der FuSi, denn nur damit können Sie die Sicherheit des Fahrzeuges beweisen und bei den Zulassungsstellen eine Fahrzeugzulassung ohne eingebauten Not-Aus erhalten.

Komponenten auswählen ≠ integrieren

In einigen Fällen definiert die FuSi, auf welche Art man in der Entwicklung vorzugehen hat. In der ISO 26262 wird beispielsweise das V-Modell vorgegeben. Anhand des Modells hat die Entwicklung von Design-Ebene bis zur Integration auf der HW-Ebene zu erfolgen. Es reicht also nicht nur, die richtigen Komponenten zu verbauen., Sie müssen auch gemäss FuSi integriert werden.

Spannende Ansicht

Nicht zur funktionalen Sicherheit gehören unter anderem die elektrische Sicherheit und der Brandschutz. Allerdings entscheidet sich beispielsweise anhand der Batteriespannung und deren Gefährdungspotential, welche elektrischen Sicherheitsmassnahmen getroffen werden müssen.

Stringente Dokumentation

Die aus der Funktionalen Sicherheit wichtigsten Entwicklungsschritte müssen dokumentiert werden und in einer definierten Form zu «work products» zusammengefasst werden. Diese ermöglichen den Kontrollorganen die Überprüfung der Entwicklungsarbeit.

Safety – Entwicklungsprozess

Bei der Entscheidung, ob man ein Produkt im Rahmen der Funktionalen Sicherheit entwickelt, sollte die Tool-Chain unbedingt beachtet werden. Diese hilft in allen Phasen der Entwicklung auf technischer Ebene und hat auf die FuSi-Dokumentation ausgerichtete Bausteine.

Die Entwicklung des Produkts in der Durot Tool-Chain beginnt mit der Analyse der Anforderungsspezifikationen (Requirements) und dem Modellieren des Produkts in SYSML / UML im SW-Tool «SOX». Das sind die Grundbausteine, worauf die Hazard & Risk Analyse (H&R) erstellt wird. Diese ist wiederum Grundlage für alle folgenden Schritte und das klassische Engineering.

Entwicklungsprozess der Funktionalen Sicherheit
Funktionale Sicherheit Im Entwicklungsprozess

Entwicklungsprozess der Funktionalen Sicherheit

Die Entwicklung des Produkts in der Durot Tool-Chain beginnt mit der Analyse der Anforderungsspezifikationen (Requirements) und dem Modellieren des Produkts in SYSML / UML im SW-Tool «SOX». Das sind die Grundbausteine, worauf die Hazard & Risk Analyse (H&R) erstellt wird. Diese ist wiederum Grundlage für alle folgenden Schritte und das klassische Engineering.

Functional Safety Tool Chain Beispiel
Functional Safety Tool Chain Beispiel

Functional Safety Tool Chain Beispiel

Für FuSi-Entwicklung ist im – wie klassischen Engineering und im Safety-Engineering – eine verlässliche Tool-Chain unabdingbar und leider auch kostenintensiv, da jedes Design-Level abgetestet werden muss. Dazu gehört auch ein Hardware-In-The-Loop – Test (HIL). Dieser Aufbau – in unserem Falle mit Vector – simuliert beispielsweise die spezifizierte HW-Umgebung einer VCU. Währen dieses HIL-Test werden alle möglichen Kombinationen von Fehlerzuständen oder Fehlmanipulationen abgetestet und die Reaktion der entwickelten VCU aufgezeichnet.

Für FuSi-Entwicklung ist im – wie klassischen Engineering und im Safety-Engineering – eine verlässliche Tool-Chain unabdingbar und leider auch kostenintensiv, da jedes Design-Level abgetestet werden muss. Dazu gehört auch ein Hardware-In-The-Loop – Test (HIL). Dieser Aufbau – in unserem Falle mit Vector – simuliert beispielsweise die spezifizierte HW-Umgebung einer VCU. Währen dieses HIL-Test werden alle möglichen Kombinationen von Fehlerzuständen oder Fehlmanipulationen abgetestet und die Reaktion der entwickelten VCU aufgezeichnet.

Restrisiko bleibt

Auch wenn man im Design, in der FuSi und beim Testen alles richtig gemacht hat, können Fehler auftreten die zum Tod einer Person führen. FuSi hilft Ihnen zu beweisen, dass Sie technisch und organisatorisch genug unternommen haben, um das zu vermeiden.

GAU, der
Wortart: Substantiv, maskulin
Bedeutung: Abkürzung für «Grösster Anzunehmender Unfall»,
bzw. schwerster Störungsfall, der in einem System auftreten kann
[und für den beim Bau der Anlage entsprechende Sicherheitsvorkehrungen zu treffen sind].

DAU, der
Wortart: Substantiv, maskulin
Bedeutung: Abkürzung für «Dümmster Anzunehmender User»,
bzw. schwerste Fehlbedienung, die der Anwender in einem System hervorrufen kann
[und für den beim Bau der Anlage entsprechende Sicherheitsvorkehrungen zu treffen sind].

Artikel teilen

Sicher, dass Sie sicher sind?