Hallo Herr Schacht

Das mit dem 0 und dem 1 lasse ich nicht gellten. Es kommt halt darauf an ob an der Richtigen Stelle eine Null oder Eins steht und ob zum richtigen Zeitpunkt aus einer aus der 0 die Eins wird (oder umgekehrt).
Ich selbst habe einen SW Lastiges Studium hinter mir und auch in der Entwicklung gearbeitet. Später habe ich im Mechanischen Bereich FMEA Kennen und schätzen lernen dürfen. Die Systematik begeistert mich und ich bin sicher das es mit den richtigen Kriterien und Beurteilungen auch in der SW anwendbar und hilfreich ist.

Sehr geehrter Herr Müller,
wie Sie dem Artikel entnehmen können, stehe ich sehr kritisch zur Software FMEA.
Der Begriff wird häufig verwendet, wenn man Funktionen eines Systems analysiert, welche in Software implementiert werden.
Die FMEA beginnt hier meisst mit der Frage, was passiert wenn die betrachtete Funktion nicht das tut wofür Sie gedacht ist. Oder was passiert, wenn die Funktionalität zwar gegebebn ist, aber das zeitliche Verhalten nicht stimmt. Ich würde in dem Fall aber eher von einer System FMEA reden und nicht einer SW FMEA.

Aus meiner Sicht macht es keinen Sinn, wenn man eine Software als Betrachtungsgegenstand hernimmt und dann folgende Frage stellt: Was passiert wenn ein Fehler in Code Zeile xy enthalten ist.
Viele Grüße
Martin HEininger

ich bin durch ein Webinar Vectors auf Ihren Blog gestoßen. Ich selbst betreue aus Sicht der Funktionalen Sicherheit im Bereich Automotive die Entwicklung eines Tools, welches mittels einer Meta-Sprache Generics bzw. Templates für C realisiert. Damit ist es vergleichbar mit einem Compiler. In der ISO26262:2011 und dem Entwurf der ISO26262:2018 wird das Assessment des Entwicklungsprozesses des Tools als Qualifizierungsmaßnahme genannt, wie in Ihrem Blog beschrieben. Sie schreiben zudem, dass die Toolhersteller diesen Entwicklungsprozess oft selbst zertifizieren lassen. Welche Art von Entwicklungsprozess bzw. Zertifikat meinen Sie, bspw. eine Entwicklung nach ASPICE Capability Level 2? Falls ja, dann ist nach meinem Verständnis das Erreichen von Sicherheitszielen damit nicht sichergestellt.

besser kann man es nicht beschreiben und man sieht schon in den Antworten, dass das Verständnis oftmals nicht detailliert genug ist in der Automotive-Branche. Ich gebe Dir zu 100% recht und man kann es nicht nachdrücklich genug sagen: Fault Injection Tests sind ein oder der wesentliche Bestandteil der Nachweisführung und sind und müssen als ein Teile der Requirements basierten Tests verstanden werden. Wir sehen bei der Implementierung wie auch bei Anfragen unserer Kunden nach Testsystemen, dass sich dieses Verständnis noch nicht komplett durchgesetzte hat. Hier auch nochmals Dank an Herrn Schacht, der es aus einer automotiven Sicht herrlich beschreibt und auf den Punkt bringt: Requirements basierte Tests werden als ganz konkrete Testfälle mit wohl überlegten Anforderungen wahrgenommen, Fault Injection Tests als „darf halt nix böses passieren“. Aber genau dies ist doch das Wichtigerer und der Zweck der sicherheitskritischen Architektur? Eben nicht nur der Funktion zu folgen, sondern mit ausreichender Sicherheit Fehler zu identifizieren und dann richtig zu reagieren. Top Beitrag !!

Mit freundlichen Grüßen

Frank Heidemann / SET GmbH