Die Ausgangssituation
Ein führender Automobilzulieferer für elektronische Lenkradschlösser stand vor der Aufgabe, die Software eines bestehenden Systems für eine neue Modellreihe des Automobilherstellers anzupassen. Die Softwareanpassung sollte gemäß der Sicherheitsnorm ISO 26262 für funktionale Sicherheit erfolgen. Ein neues Hardwaredesign 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 stammten von Drittanbietern oder sollten nach entsprechenden QM-Anforderungen entwickelt werden. Um die Sicherheitsziele nicht zu gefährden, musste das Projektteam sicherstellen, dass die QM-Software keine sicherheitsrelevanten Softwarekomponenten beeinträchtigt. Die Hardware sollte dabei unverändert bleiben.
Projektdauer
Drei Jahre
Unser Ansatz
Um dieses Ziel zu erreichen, analysierte der Sicherheitsexperte von UL Solutions Software Intensive Systems (SIS) die Software zusammen mit dem Softwarearchitekten des Kunden, um mögliche Rückwirkungen zu erkennen und geeignete Maßnahmen zur Erkennung bzw. Vermeidung zu definieren. Der Sicherheitsexperte begleitete auch die Umsetzung dieser Maßnahmen.
Gemeinsam führten der SIS-Sicherheitsexperte und der Softwarearchitekt eine Analyse des kritischen Pfades (CPA) durch. Ausgehend von der Hardware-Software-Schnittstelle (HSI) identifizierten sie die sicherheitskritischen Teile der Software. Dazu gehörten neben den aus funktionaler Sicht systemkritischen Softwarekomponenten weitere, die den fehlerfreien Betrieb der Hardware sicherstellen, wie etwa die Diagnose von Aktoren und Sensoren sowie die Fehlersuche im Programm- und Arbeitsspeicher (ROM/RAM), in der arithmetisch-logischen Einheit (ALU) und dem Taktgeber etc.
Im nächsten Schritt teilten der SIS-Sicherheitsexperte und der Softwarearchitekt des Kunden die Software entsprechend der jeweiligen ASIL-Klassifikation in getrennte Partitionen auf. Die Software wurde innerhalb einer Partition immer nach der gleichen ASIL-Klassifikation entwickelt. Softwarekomponenten mit unterschiedlichen Klassifikationen wurden fragmentiert. Die Anzahl der Partitionen wurde auf zwei reduziert, um den Aufwand für Analyse und Maßnahmen zu verringern. Die Softwarekomponenten innerhalb einer Partition wurden immer gemäß der höchsten ASIL-Klassifikation entwickelt.
Nach der Partitionierung analysierte der SIS-Sicherheitsexperte die Softwarearchitektur mithilfe einer Fehlermöglichkeits- und Einflussanalyse (FMEA) systematisch auf mögliche Rückwirkungen zwischen den Partitionen. Er betrachtete insbesondere Fehler, die gemeinsam genutzte Ressourcen und Schnittstellen (RAM, Rechenzeit, HSI, Softwareschnittstellen) betreffen und damit unbeabsichtigt zu kritischem Verhalten in den ASIL-Softwarekomponenten führen können.
Es gibt verschiedene Maßnahmen, mit denen eine gegenseitige Rückwirkung festgestellt bzw. verhindert werden kann. Da kein hardwarebasierter Speicherschutz verfügbar war, gab es in diesem Projekt nur eine Möglichkeit: potenzielle Rückwirkungen zu erkennen und zu verhindern, dass diese die Sicherheitsziele gefährden. Eine hardwarebasierte Partitionierung des Arbeitsspeichers kam nicht in Frage, da der Mikrocontroller über keine Speicherschutzeinheit (MPU) verfügte. Nach der Implementierung der QM-Komponenten der Software musste daher davon ausgegangen werden, dass mögliche Fehler zu unbeabsichtigten Veränderungen sicherheitskritischer Inhalte im Speicher führen könnten.
Diese Ausgangssituation erhöhte zwar den Aufwand für die Software erheblich, ermöglichte aber gleichzeitig die Absicherung des Softwareverhaltens. Wir weisen darauf hin, dass auch der Einsatz einer MPU gegenseitige Rückwirkungen nicht verhindert; es werden damit lediglich die Ressourcen RAM und HSI abgedeckt.
Zusammen mit dem Softwarearchitekten und dem für das Projekt verantwortlichen Sicherheitsmanager definierte der SIS-Sicherheitsexperte für jede identifizierte potenzielle Rückwirkung geeignete Gegenmaßnahmen. Die definierten Maßnahmen wurden als sicherheitsrelevante Anforderungen an die Softwarearchitektur bzw. die Softwarekomponenten im Projekt aufgenommen.
Zusätzlich unterstützte der SIS-Sicherheitsexperte den Kunden während des gesamten Projektverlaufs bei der Umsetzung der definierten Anforderungen. Diese Vorgehensweise erwies sich als sinnvoll, da nicht alle ursprünglich definierten Maßnahmen wie geplant umgesetzt werden konnten, und sich durch nachträgliche Änderungen der Systemanforderungen die Ausgangssituation veränderte.
Zu den Highlights unseres Ansatzes gehören:
- Bestimmung sicherheitskritischer Softwarekomponenten
- Definition von Partitionen
- Analyse potenzieller Rückwirkungen
- Definition von Präventionsmaßnahmen
- Verifizierung der Maßnahmen
Vorteile
Sowohl der Sicherheitsmanager des Kunden, als auch eine unabhängige Stelle waren von der Wirksamkeit der Maßnahmen überzeugt – die Software konnte erfolgreich ausgeliefert werden.
Zu den wichtigsten Vorteilen für den Kunden gehören:
- Keine Gefährdung der Sicherheitsziele durch QM-Software
- Angepasste Software erfüllt ISO 26262
Mehr zu dem Thema
Kontaktieren Sie unser Team
Vielen Dank für Ihr Interesse an unseren Produkten und Dienstleistungen. Wir würden gerne ein paar Informationen sammeln, damit wir Sie mit der richtigen Person in Kontakt bringen können.