Rückwirkungsfreiheit: Es gibt 4 wesentliche Maßnahmen in der Entwicklung sicherheits relevanter Systeme.

• Design von Systemen von denen keine Gefahr ausgeht
• Maßnahmen zur Minimierung von zufälligen Hardwarefehlern
• Maßnahmen zur Minimierung von systematischen Hardware und Softwarefehlern
• Organisatorische Maßnahmen (Management der Funktionalen Sicherheit)

Insbesondere beim Design von Systemen von denen keine Gefahr ausgeht, kommt immer wieder das Prinzip der Rückwirkungsfreiheit (=Freedom of Interference) zur Anwendung. Was ist das? Wie wird es in der Praxis angewendet? Der nachfolgende Blogbeitrag liefert Antworten auf diese Fragen.

Was bedeutet das Prinzip der Rückwirkungsfreiheit?

Folgende Darstellung illustriert das Prinzip:

Rückwirkungsfreiheit

Mit der Rückwirkungsfreiheit wird nachgewiesen, dass ein (Teil-)System mit niedrigem ASIL Level (in der Darstellung ASIL A) in keiner Form auf ein System mit höherem ASIL (in der Darstellung ASIL C) einwirken kann. Damit wird verhindert das ein System bei dem eine höhere Fehlerrate (=ASIL A) erlaubt ist auf ein System wirkt bei dem eine niedrigere Fehlerrate (ASIL C) gefordert wird.

Das Design in der linken Darstellung zeigt auf, dass es keinerlei Möglichkeit gibt, wie das ASIL A System das ASIL C System beeinflussen könnte. Das bedeutet, dass das ASIL C System bezogen auf das ASIL A System rückwirkungsfrei ist.

Im Systemdesign in der rechten Darstellung ergibt sich ein Daten-/Kontrollfluss von dem ASIL A auf das ASIL C System. Damit ist das ASIL C System erstmal nicht rückwirkungsfrei. Das ASIL C System kann von dem ASIL A System beeinflusst werden. In diesem Fall müssen weitere Design Maßnahmen ergriffen werden um eine Rückwirkungsfreiheit trotzdem zu erreichen. Z.B. könnte das ASIL C System die Daten die vom ASIL A System als Eingang anliegen zunächst auf Korrektheit plausibilisieren. Unter Berücksichtigung dieser Maßnahme, wäre die Rückwirkungsfreiheit der ASIL C Komponente ggf. auch erreicht.

Was sagt die ISO 26262 dazu?

In beiden Darstellungen entstand das Systemdesign durch die ASIL Dekomposition einer ASIL D Komponente. Daher rührt das D in der Klammer.
Die ISO26262 macht zu diesem Thema „nur“ die Aussage, dass eine ausreichende Unabhängigkeit erreicht werden muss. Wie sich das nun in der gelebten Projekt-Praxis auswirkt lesen Sie im nächsten Blog.

Ihre individuellen Fragen zur praktischen Umsetzung der ISO 26262 beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).