• Twitter
  • LinkedIn
  • Xing
+49 7353 981781
Heicon Ulm
  • HOME
  • UNTERNEHMEN
  • PRODUKTE
  • HEICON BLOG
  • Deutsch
    • Deutsch
    • English
  • Menü Menü
Du bist hier: Startseite1 / FuSi_Automotive2 / ISO 26262: Rückwirkungsfreiheit – Was ist das?

ISO 26262: Rückwirkungsfreiheit – Was ist das?

FuSi_Automotive

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:

ISO26262 Rückwirkungsfreiheit

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

23. Juni 2017/4 Kommentare/von HEICON Global Engineering GmbH
Schlagworte: Freedom of Interference, Funktionale Sicherheit, ISO26262, ISO26262 Verification, ISO26262 Verifikation, Rückwirkungsfreiheit
Eintrag teilen
  • Teilen auf Facebook
  • Teilen auf Twitter
  • Teilen auf WhatsApp
  • Teilen auf LinkedIn
https://heicon-ulm.de/wp-content/uploads/2020/03/DI1A6086_klein_Automotive-1.jpg 533 684 HEICON Global Engineering GmbH https://heicon-ulm.de/wp-content/uploads/2020/07/heicon-logo-5.png HEICON Global Engineering GmbH2017-06-23 19:08:102021-06-06 21:42:53ISO 26262: Rückwirkungsfreiheit – Was ist das?
Das könnte Dich auch interessieren
ISO26262ISO 26262 ASIL Dekomposition – Chancen und Risiken!
Funktionale SicherheitQualitätssicherung in FuSi-Projekten – Was ist anders?
Funktionale SicherheitWichtigkeit der Toolqualifikation in der FuSi (Teil 1)!
ISO26262ISO 21448 – SOTIF! Wo ist der Mehrwert?
Funktionale SicherheitFunktionale Sicherheit und Pragmatismus geht das?
Funktionale SicherheitCompiler für sicherheitsrelevante Software – Was ist zu tun?
4 Kommentare
  1. Hans Leo Ross sagte:
    24. Juni 2017 um 23:03

    Die Schreibweise B(D) deutet auf eine Dekomposition hin. Das sollte Rueckwirkungsfreiheit nicht hinreichend sein.

    Antworten
    • MartinHeininger sagte:
      28. Juni 2017 um 10:40

      Hallo Herr Ross, Sie haben völlig recht. Mir geht es in dem Blog aber „nur“ um den Aspekt Rückwirkungsfreiheit. Vielleicht wäre es besser wenn ich den Dekompositionsaspekt ganz weggelassen hätte.

      Antworten
  2. D. Hönig sagte:
    10. März 2022 um 17:53

    Danke für die bündige Erklärung. Allerdings machen die zahlreichen Komma und Rechtschreibfehler den Artikel schwer leserlich und senken seine äusserliche Qualität deutlich.

    Antworten

Trackbacks & Pingbacks

  1. Rückwirkungsfreiheit – Die gelebte Praxis! | HEICON sagt:
    7. Juli 2017 um 10:29 Uhr

    […] letzten Blogbeitrag (Juni 2017) habe ich das Prinzip der Rückwirkungsfreiheit erklärt. Das verwendete Beispiel bezog sich dabei […]

    Antworten

Hinterlasse einen Kommentar

An der Diskussion beteiligen?
Hinterlasse uns deinen Kommentar!

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Kategorien

  • A_Requirement Engineering
  • B_Validation und Verifikation
  • C_Konfig-/ Änderungsmanagement
  • D_Security
  • FuSi_Allgemein
  • FuSi_Automotive
  • FuSi_Bahn
  • FuSi_Industrie
  • FuSi_Landwirtschaft
  • FuSi_Luftfahrt

Kontakt

HEICON Global Engineering GmbH
Dipl. Ing. (FH) Martin Heininger
Kreuzweg 22
88477 Schwendi

Tel.: +49 7353 – 98 17 81
Mobil: +49 176 – 24 73 99 60

Email: info[at]heicon-ulm.de

IMPRESSUM  |  DATENSCHUTZ

Strukturelle Source Code Überdeckung auf dem Target!Funktionale SicherheitFunktionale SicherheitRückwirkungsfreiheit – Die gelebte Praxis!
Nach oben scrollen