Obwohl Software heutzutage zu einem großen Teil nicht nach Normen und Standards für funktionale Sicherheit entwickelt wird, steigen die Erwartungen, dass die integrierten „Lines of Code“ – gerade auch im Umfeld des autonomen Fahrens – exponentiell zunehmen werden. Entsprechend wuchs das Interesse an der 2024 erschienenen Norm ISO 8926, die sich mit der Integration von PSAE (pre-existing software architecture element) in bestehende und neue Softwarearchitekturen im Umfeld der ISO 26262 beschäftigt. Die neue Norm bündelt Handlungsanweisungen und Anforderungen, um z. B. Legacy-Code oder von einer Open-Source-Community entwickelte Betriebssysteme oder Softwarebibliotheken in funktional sichere Produkte im Automotive-Umfeld integrieren zu können.

Bei der Entwicklung eines funktional sicheren Produktes geht es im Allgemeinen darum, das Risiko dieses Produktes für Leib und Leben zu ermitteln und Maßnahmen zu ergreifen, um das Risiko auf ein „gesellschaftlich akzeptables“ Maß zu reduzieren. Für die Softwareentwickler bedeutet das, dass sie z. B. den durch Automotive SPICE® vorgegebenen Entwicklungsprozess – ergänzt um Maßnahmen zur Reduzierung von Fehlern – zielgerichtet befolgen. Je nach Automotive Safety Integrity Level (ASIL) ist dies mit mehr oder weniger Aufwand verbunden. Der Prozess und die Maßnahmen tragen dazu bei, die Wahrscheinlichkeiten für das Auftreten systematischer Fehler zu reduzieren – immer bei Betrachtung der gesamten Software des Produkts.

Was ist jedoch zu beachten und welche Maßnahmen sind umzusetzen, wenn man nicht die komplette Software selbst entwickelt? Die ISO 26262 hat bereits das Konzept von SEooC (Safety Element out of Context) eingeführt, das allerdings nur die Komponenten betrifft, die nach demselben Standard entwickelt wurden. Bisher nur marginal gestreift wurde der Fall, entweder Legacy-Code des Unternehmens übernehmen oder Bibliotheken, Anwendungen oder ganze Betriebssysteme einsetzen zu wollen, die außerhalb des Projektteams oder gar des gesamten Unternehmens und nicht der ISO 26262 entsprechend entwickelt wurden. Für ebenjene Anwendungsfälle füllt die ISO 8926 einige Prozess-, Argumentations- und Maßnahmenlücken.

Welches Vorgehen beschreibt nun die ISO 8926?

Am Anfang steht die „Impact Analysis“ mit der Betrachtung, welche funktional sicheren Anforderungen und Funktionen aus dem Lastenheft auf das PSAE gemappt werden, mit welcher Qualität (Entwicklungsprozess) das PSAE entwickelt wird und welchen Umfang es besitzt. Je nach Prozess und Komplexität wird das PSAE anschließend einer der Klassen „Class I“, „Class II“ und „NR“ zugeordnet. „Class I“ beinhaltet relativ „einfache“ Software mit einem gut dokumentierten Prozess, wohingegen komplexe und ohne Prozess entwickelte Software der Klasse „NR“ – also „not recommended“ – angehört. Je nach Klassenzuordnung unterscheiden sich die im Rahmen des gesamten Entwicklungsprozesses zu treffenden Maßnahmen, um das dem PSAE inhärente Risiko zu senken. Dafür kommen sowohl Analysen und Plausibilisierungen als auch Absicherungen in Soft- oder Hardware (z. B. Watchdog, Memory Protection etc.) infrage. Diese Maßnahmen sind in die Gesamtentwicklung des Produkts aufzunehmen und zu planen.

Fazit

Schon vor der ISO 8926 war es möglich, nicht nach der Norm ISO 26262 entwickelte Software im Automotive-Umfeld zu verwenden. Jedoch war in jedem Einzelfall eine substantiierte Begründung vorzubringen, warum die Software frei von systematischen Fehlern ist und warum folglich das dem Gesamtsystem inhärente Risiko für Leib und Leben das akzeptable Maß nicht überschreitet. Die ISO 8926 liefert nun einen konstruktiven Ansatz für die Klasseneinteilung und damit für die Ermittlung des Risikos der einzusetzenden Software. Darüber hinaus gibt sie auch die Handlungsanweisungen zur Risikoreduzierung an die Hand. Wer sich daran hält, wird auch die Auditoren und Assessoren von der Funktionalen Sicherheit seines Produktes überzeugen können.