Freedom from Interference in Embedded Software

Situation

Ein führender Automobilzulieferer für elektronische Lenkradschlösser stand vor der Aufgabe die Software eines bestehenden Systems an eine neue Modelreihe des Automobilbauers anzupassen. Die Software-Anpassung sollte konform zur Safety-Norm ISO 26262 realisiert werden. Ein neues Hardware-Design war nicht vorgesehen. Das bestehende System verfügte über einen 16-bit Mikrocontroller ohne hardwarebasierten Speicherschutz.
Auf dem Mikrocontroller sollten Teile der Software nach ASIL-A bzw. ASIL-B(D) realisiert werden, andere Teile der Software stammten von Drittanbietern oder sollten nach QM-Anforderungen entwickelt werden. Das Projektteam sollte nun sicherstellen, dass eine Beeinflussung der sicherheitsrelevanten Anteile der Software durch die QM-Software nicht zu einer Gefährdung der Sicherheitsziele führte. Die Hardware sollte dabei unverändert bleiben.

 

Dauer des Projektes

3 Jahre

Haben Sie Fragen?

Wollen Sie sich zu unserem Themen-Portfolio beraten lassen?

Contact card open Contact card close

Lösung

Um dieses Ziel zu erreichen, analysierte der Safety Experte von Method Park zusammen mit dem Software-Architekten des Kunden die Software, um mögliche Beeinflussungen zu identifizieren und geeignete Gegenmaßnahmen zur Vermeidung bzw. zur Erkennung einer Beeinflussung zu definieren. Der Safety Exptere begleitete die anschließende Umsetzung der Maßnahmen.
Gemeinsam führten der Safety Experte von Method Park und der Software-Architekt eine Critical Path Analysis (CPA) durch. Ausgehend vom Hardware-Software-Interface (HSI) identifizierten sie die sicherheitskritischen Teile der Software. Zu den Teilen der Software, die aus funktionaler Sicht sicherheitskritisch waren, kamen noch Anteile hinzu, die einen fehlerfreien Betrieb der Hardware absichern. Dabei handelte es sich um die Diagnose von Aktoren und Sensoren und die Fehlerdiagnose für den Programm- und Arbeitsspeicher (ROM/RAM) sowie Rechenwerk (ALU) und Taktgeber etc.
Im nächsten Schritt teilte der Safety Experte von Method Park zusammen mit dem Software-Architekten des Kunden die Software abhängig von der ASIL-Einstufungen in getrennte Partitionen auf. Innerhalb einer Partition wurde die Software immer nach der gleichen ASIL-Einstufung entwickelt. Software-Komponenten mit unterschiedlich eingestuften Anteilen wurden aufgesplittet. Die Anzahl der Partitionen wurde auf zwei reduziert, um den Aufwand bei der Analyse und den Maßnahmen zu reduzieren. Die Software-Komponenten innerhalb einer Partition wurden dabei immer unter Berücksichtigung der höchsten ASIL-Einstufung entwickelt.
Nach der Partitionierung analysierte der Safety Experte von Method Park die Software-Architektur systematisch im Hinblick auf eine mögliche Beeinflussung zwischen den Partitionen. Für die Analyse verwendete er eine SW-FMEA. Dabei betrachtete er vor allem die Fehler, die sich über gemeinsam genutzte Ressourcen und Schnittstellen (Arbeitsspeicher, Rechenzeit, HSI, Software-Schnittstellen) ausbreiten und so in den ASIL-Anteilen der Software unbeabsichtigt zu einem kritischen Verhalten führen können-
Es gibt eine Reihe von Maßnahmen, die eine solche, gegenseitige Beeinflussung erkennen oder verhindern. In diesem Projekt war das Erkennen einer möglichen Beeinflussung und das Vermeiden einer Verletzung des Sicherheitszieles der einzig mögliche Ansatz, da ein hardwarebasierter Speicherschutz nicht zur Verfügung stand. Der Einsatz einer hardwarebasierten Partitionierung des Arbeitsspeichers war keine Option, da der Mikrocontroller über keine Memory Protection Unit (MPU) verfügte. Nach der Ausführung von QM-Anteilen der Software musste daher davon ausgegangen werden, dass mögliche Fehler unbeabsichtigt den sicherheitskritischen Inhalt im Speicher verändern.
Diese Ausgangssituation erhöhte den Aufwand, der in der Software betrieben werden musste, deutlich, machte es jedoch nicht unmöglich das Verhalten der Software abzusichern. Es sei angemerkt, dass der Einsatz einer MPU auch nicht jede gegenseitige Beeinflussung verhindert; es werden damit lediglich die Ressourcen Arbeitsspeicher und HSI abgedeckt.
Für jede identifizierte, potenzielle Beeinflussung definierte der Safety Experte von Method Park gemeinsam mit dem Software-Architekten und dem Safety Manager des Projektes geeignete Gegenmaßnahmen. Die definierten Maßnahmen wurden als sicherheitsrelevante Anforderungen an die Software-Architektur bzw. die Software-Komponenten im Projekt aufgenommen.
Der Safety Experte von Method Park unterstützte den Kunden zusätzlich während des gesamten Projektverlaufs bei der Umsetzung der definierten Anforderungen. Dies erwies sich als sinnvoll, da nicht alle ursprünglich definierten Maßnahmen wie geplant realisierbar waren und späte Änderungen der Systemanforderungen zusätzlich die Ausgangssituation veränderten.

Bestimmen sicherheitskritischer Software-Komponenten

Definition von Partitionen

Analyse einer potenziellen Beeinflussung

Definition von Maßnahmen zur Vermeidung

Verifikation der Maßnahmen

 

 

Ergebnis

Von der Wirksamkeit der Maßnahmen waren am Ende der Safety Manager des Kunden und eine unabhängige Stelle (TÜV) überzeugt, so dass die Software erfolgreich ausgeliefert werden konnte.

 

Keine Gefährdung der Sicherheitsziele durch QM-Software

Angepasste Software erfüllt ISO 26262