Freedom from Interference

Die Safety-Architektur bildet die Grundlage für die Koexistenz von Funktionen mit unterschiedlichen ASIL-Klassifikationen

Es ist Stand der Technik, mehrere sicherheitsrelevante Funktionen mit verschiedenen ASILs oder QM-Klassifikation auf einer gemeinsamen Hardware koexistieren zu lassen. Eine geeignete Software-Architektur ist für entsprechende Softwareprojekte nach ISO 26262 unverzichtbar. Diese Safety-Architektur zeigt die unabhängigen Software-Elemente und deren Schnittstellen. Die Einhaltung dieser Safety-Architektur ist die Grundlage für Rückwirkungsfreiheit (Freedom from Interference).

Einhaltung der geplanten Schnittstellen ermöglicht Freedom from Interference

Die Architekturprüfung der Axivion Suite stellt die konsequente Verwendung der definierten Schnittstellen und der gewählten Kommunikationsmechanismen sicher. Abweichungen von der Architektur werden im Quelltext sofort aufgezeigt. Dies umfasst unter anderem nicht spezifizierte Funktionsaufrufe, Überschreiben von Daten, oder ganz allgemein die Bezugnahme auf nicht als Schnittstelle definierte Deklarationen.

Im Bild ist eine Safety-Architektur mit zwei ASIL Partitionen und einer QM Partition gezeigt. Innerhalb der Partitionen ist eine detailliertere Architektur angedeutet, welche aber im Rahmen der Analyse auf Freedom from Interference nicht relevant ist. Hier geht es um die Schnittstellen zwischen den Partitionen unterschiedlicher Kritikalität. Diese Schnittstellen können in vielfältiger Weise modelliert werden. Die Ausführung von Code niedriger Kritikalität im Kontext einer Partition mit höherer Kritikalität stellt aber vermutlich einen Verstoß gegen den Safety Case dar. Im Bild sind derartige gegen die Safety-Architektur verstoßenden Beziehungen eingezeichnet und mit einem Hinweis-Schild versehen.
Solche Verstöße sind ohne eine Prüfung auf Einhaltung der Safety Architektur erst spät im Prozess mit Hardware und konfigurierter MPU/MMU zu erkennen. Mit der Architekturanalyse werden diese Verstöße unmittelbar als Architekturverstöße aufgefunden. Im Gegensatz zum dynamischen Testen mit Hardware lässt sich diese Prüfung auch direkt in die CI/DevOps Pipeline integrieren.

Im Bild ist eine Safety-Architektur mit zwei ASIL Partitionen und einer QM Partition gezeigt

Vereinfachte Integration eines Safety-Systems

Werden die Software-Elemente ergänzend mit der statischen semantischen Analyse auf Compliance mit einer geeigneten Codierrichtlinie (z.B. AUTOSAR C++ 14, MISRA, …) geprüft, so können auch Programmierfehler, die zu undefiniertem Verhalten führen, weitgehend ausgeschlossen werden. Diese Kombination liefert somit ein starkes Argument für Freedom from Interference in Mixed-ASIL-Systemen.

Diese Prüfungen können bereits früh im Entwicklungsprozess, während der Codierung, eingesetzt werden. In einem partitionierten System mit Speicherschutz sind somit deutlich weniger Probleme in den späten Integrationsphasen (z.B. MMU/MPU-Exceptions) zu erwarten.

Ich möchte mehr zu Freedom from Interference erfahren: