Eine der größten Herausforderungen für die Automobilindustrie ist heute der Übergang von hardwarebasierten zu softwaredefinierten Fahrzeugen. Da Software immer mehr in den Mittelpunkt der Entwicklung in der Automobilindustrie rückt, entwickeln sich OEMs und Zulieferer allmählich zu Softwareunternehmen. Das Auto entwickelt sich von einem reinen Transportmittel zu einem Mobilitätscomputer, also einem Computer auf vier Rädern.
Unterschiede und Synergien zwischen funktionaler Sicherheit, SOTIF und Cybersecurity
Die rasche Entwicklung intelligenter, vernetzter Fahrzeuge hat zu einem stetigen Aufkommen neuer Technologien geführt, wie z. B. Software-Updates aus der Ferne über Over-the-Air-Technologie (OTA) oder die Integration mit persönlichen digitalen Geräten. Der breite Einsatz dieser neuen Technologien in intelligenten, vernetzten Fahrzeugen stellt zusätzliche Anforderungen an die Angriffssicherheit (oder Cybersicherheit, engl. Cybersecurity) des gesamten Fahrzeugs. Der Stand der Technik in diesem Bereich ist in der Industrienorm ISO 21434 „Road vehicles - Cybersecurity engineering“ dokumentiert.
Gegenwärtig wenden die meisten OEM und Zulieferer technische Verfahren an, um die Sicherheit (im Sinne von Safety) der elektrischen/elektronischen Systeme (E/E) in ihren Fahrzeugen zu gewährleisten. Dies bedeutet, dass sie die in den internationalen Normen ISO 26262 und ISO 21448 beschriebenen Entwicklungsprozesse für die funktionale Sicherheit (oder Funktionssicherheit bzw. Funktionsausfallsicherheit, engl. Functional Safety) und die Sollfunktionssicherheit (engl. Safety of the Intended Functionality, SOTIF) berücksichtigen.
Für Praktiker:innen ist es entscheidend, die Beziehung zwischen den aktuellen Standards funktionaler Sicherheit, SOTIF und Cybersicherheit zu verstehen und zu wissen, wie die Koordination zwischen den verschiedenen Lebenszyklen, die diese vorschlagen, erreicht werden kann. Wie können wir zum Beispiel funktionale Sicherheit, Sollfunktionssicherheit, Cybersicherheit und letztendlich Softwarequalität in einem modellbasierten Entwicklungsprozess erreichen, insbesondere wenn wir Werkzeugketten basierend auf Simulink oder TargetLink verwenden? Auf diese Fragen werden in den folgenden Abschnitten eingehen.
Zunächst wollen wir uns die grundlegenden Sicherheitsstandards für den Automobilsektor vor Augen führen. Das deutsche Wort Sicherheit umfasst dabei 2 Aspekte:
- Sicherheit im Sinne von Safety. Dieser Bereich umfasst die Sollfunktionssicherheit und die funktionale Sicherheit (Funktionsausfallsicherheit).
- Sicherheit im Sinne von Security. In diesen Bereich fällt die Cybersicherheit (Angriffssicherheit).
Die beiden Bereiche werden durch insgesamt drei grundlegende Standards abgedeckt:
- Die ISO 26262:2018 „Road vehicles – Functional safety“ befasst sich mit möglichen Gefährdungen durch Fehlfunktionen sicherheitsrelevanter E/E-Systeme im Fahrzeug. Sie definiert einen automobilspezifischen risikobasierten Ansatz, der Risiken durch die Verwendung von Automotive Safety Integrity Levels (ASILs) ermittelt und darstellt. [ISO 26262, ISO DTS 5083]
- ISO 21448:2022 „Road vehicles – Safety of the intended functionality“ befasst sich mit unangemessenen Risiken aufgrund von Gefährdungen, die sich aus Unzulänglichkeiten der Sollfunktion , indem sie einen allgemeinen Argumentationsrahmen und Leitlinien für Maßnahmen zur Gewährleistung der SOTIF bereitstellt. Die Idee ist, die negativen Auswirkungen bekannter potenziell gefährlicher Szenarien zu reduzieren und die Anzahl unbekannter gefährlicher Szenarien zu minimieren. [ISO 21448, ISO DTS 5083]
- ISO/SAE 21434:2021 „Road vehicles – Cybersecurity engineering“ konzentriert sich auf Risiken, die durch unbefugte Handlungen, einschließlich mutwilliger Angriffe, entstehen. Dies macht den Einsatz zusätzlicher Ingenieurstätigkeiten und technischer Mechanismen erforderlich, die sich jedoch auch auf die anderen Aspekte der Sicherheit auswirken können. Diese Norm beschreibt die Cybersicherheitsaktivitäten mit besonderem Schwerpunkt auf dem Risikomanagement. [ISO/SAE 21434, ISO DTS 5083]
Ganzheitliche Sicherheit
Um die Herausforderungen im Zusammenhang mit softwaredefinierten Fahrzeugen erfolgreich zu meistern, reicht es nicht aus, die oben genannten Bereiche - funktionale Sicherheit, SOTIF und Cybersicherheit - isoliert zu betrachten. Vielmehr muss ein umfassender Sicherheitsansatz verfolgt werden. Ganzheitliche Sicherheit kann definiert werden als die Fähigkeit eines Systems, einen Dienst oder eine Funktion unter Berücksichtigung von Safety und Security zu erbringen (Abb. 1). Leider gibt es noch keinen ganzheitlichen Sicherheitsstandard für die Automobilindustrie[1].
Safety vs. Security
Wie hängen nun Safety und Cybersecurity zusammen? Zwei Zitate aus der Literatur veranschaulichen die gegenseitige Abhängigkeit:
Safety und Security werden traditionell als unterschiedliche Disziplinen betrachtet, die von unterschiedlichen Fachleuten bearbeitet werden. Ein genauerer Blick auf ihre Besonderheiten und Gemeinsamkeiten führt jedoch zu dem Schluss, dass sie tatsächlich voneinander abhängig sind. Insbesondere setzt Safety Security voraus. [Ser19].
Es hat sich auch folgendes gezeigt: Es gibt keine Safety ohne Security. Und weiterhin: Wir können Security als ein Schutzschild betrachten, der die Safety gewährleistet. [Rya18]
Die Beziehung zwischen Safety und Security wird - aus einer anderen Perspektive - auch in Abbildung 2 dargestellt. Wie in Abbildung 2 dargestellt, konzentriert sich (Cyber-)Security" auf den Schutz des betreffenden Systems vor externen Bedrohungen. "Safety" hingegen konzentriert sich auf den Schutz vor Gefährdungen, die vom System selbst ausgehen. Diese Gefährdungen können dabei durch die Sofffunktionalität oder durch Fehlfunktionen des Systems verursacht werden.
In der Ära der hardwarebasierten Fahrzeuge wurde der Cybersicherheit weniger Aufmerksamkeit geschenkt. Mit der raschen Entwicklung softwaredefinierter Fahrzeuge werden jedoch auch Fragen der Cybersicherheit immer wichtiger, so dass sowohl die Safety als auch die Cyberecurity systematischer und koordinierter berücksichtigt werden müssen.
Safety und Cybersecurity Co-Engineering
Lassen Sie uns nun einen genaueren Blick darauf werfen, wie ein automotives E/E-System, das sowohl strenge Safety- als auch Cybersecurityanforderungen erfüllen muss, entwickelt werden kann. Dazu werden wir zunächst die vorgeschlagenen Lebenszyklen für funktionale Sicherheit nach ISO 26262 und für Cybersicherheit nach ISO/SAE 21434 betrachten, um ihre Gemeinsamkeiten und Unterschiede besser zu verstehen. Anschließend wird eine mögliche Integration dieser Lebenszyklen diskutiert.
Die Norm für funktionale Sicherheit ISO 26262 umfasst den Lebenszyklus auf System- und Softwareebene, wie in Abbildung 3 dargestellt (der Hardware-Entwicklungszyklus wird der Kürze halber hier nicht betrachtet). Die Aktivitäten werden mit Hilfe des V-Modells visualisiert. Die Aktivitäten auf Systemebene sind oberhalb der gestrichelten Linie dargestellt, die Aktivitäten auf Softwareebene darunter.
Die linke Seite des V umfasst die Spezifikations-, Design- und Implementierungsaktivitäten für das System und die Software.
Auf Systemebene beginnen die Praktiker mit der Gefahren- und Riskoanalyse (GuR, G&R; engl. Hazard Analysis and Risk Assessment, HARA), um potenzielle Gefahren und damit verbundene Risiken aus der Perspektive der funktionalen Sicherheit zu identifizieren und zu bewerten. Anschließend wird das ASIL-Level bestimmt und entsprechende Sicherheitsziele festgelegt, die als übergeordnete Sicherheitsanforderungen dienen.
Die Sicherheitsziele werden dann in einem zweistufigen Verfahren zunächst in eine Reihe von funktionalen Sicherheitsanforderungen und anschließend in technische Sicherheitsanforderungen heruntergebrochen. Die Ergebnisse werden im funktionalen bzw. technischen Sicherheitskonzept dokumentiert.
Nach der Erstellung des technischen Sicherheitskonzepts wird der Lebenszyklus auf der Softwareebene fortgesetzt. Hier werden die Softwaresicherheitsanforderungen. Anschließend werden die Softwarearchitektur und die einzelnen Softwareeinheiten entworfen und dann implementiert.
Anschließend gehen wir zur rechten Seite des Vs über, die die notwendigen Integrations-, Verifikations- und Validierungsaktivitäten (V&V) umfasst.
Die Grundidee besteht darin, die Software und das System schrittweise zu integrieren und jeden Schritt auf der linken Seite des Vs durch eine entsprechende V&V-Aktivität abzusichern.
Nach Abschluss der Entwicklung setzt sich der Lebenszyklus mit Produktion und Einsatz fort.
Die internationale Norm ISO/SAE 21434 führt einen Cyber-Sicherheitslebenszyklus (CySec) ein, der in Abbildung 4 dargestellt ist. Dieser Lebenszyklus weist einige konzeptionelle Ähnlichkeiten mit dem zuvor diskutierten Lebenszyklus der funktionalen Sicherheit auf.
Auf der linken Seite des V führt eine erste Bedrohungs- und Risikoanalyse (TARA) zu übergeordneten Cybersicherheitszielen, die zu einem Cybersicherheitskonzept auf Systemebene verfeinert werden. Dieses Konzept bildet die Grundlage für die Designs auf den darunter liegenden Ebenen der Komponenten und Unterkomponenten.
Bitte beachten Sie, dass die Verfeinerungsschritte hier im Vergleich zum Lebenszyklus der funktionalen Sicherheit eher allgemeiner Natur sind. Die genauen Schritte können aufgrund unterschiedlicher Unternehmensstrukturen oder Systemeigenschaften variieren.
Die rechte Seite des Vs umfasst die üblichen Integrations-, Verifikations- und Validierungsaktivitäten. Auf eine erfolgreiche Validierung der Cybersicherheit folgen die Produktions- und Einsatzaktivitäten.
Der Cybersicherheitslebenszyklus ist eher iterativ. Wie im linken oberen Teil von Abbildung 4 dargestellt, werden die oben genannten Aktivitäten der Konzeption, Produktentwicklung, Produktion und des Einsatzes in Zyklen durchgeführt. Die Wartung der Software durch OTA-Updates wird zu einem integralen Bestandteil des Lebenszyklus. Einer der Gründe dafür ist die Gewährleistung der erforderlichen Cybersicherheit während des gesamten Produktlebenszyklus.
Bisher gibt es zwei verschiedene Lebenszyklen, einen für die funktionale Sicherheit und einen für die Cybersicherheit. Die beiden Normen selbst weisen nur auf die Notwendigkeit hin, Safety- und Cybersicherheitsaktivitäten zu koordinieren, und geben nur einige allgemeine Hinweise, wie dies zu erreichen ist.
ISO 26262 fordert die Einrichtung und Aufrechterhaltung effektiver Kommunikationskanäle zwischen funktionaler Sicherheit, Cybersicherheit und anderen verwandten Bereichen. ISO 21434 fordert, dass Organisationen diejenigen Themenfelder identifizieren sollten, die sich auf die Cybersicherheit beziehen oder mit ihr interagieren. Die Norm fordert auch die Einrichtung und Aufrechterhaltung von Kommunikationskanälen zwischen diesen Bereichen, um festzulegen, wie Cybersicherheit synergetisch in die aktuellen Prozesse eingebettet werden kann.
In beiden Standards fehlen jedoch detaillierte Beschreibungen von Prozessen, Methoden und Werkzeugen für das Co-Engineering von Safety und Security.
Daher bleibt der praktische Abgleich zwischen beiden Lebenszyklen ein aktueller Forschungs- und Diskussionsgegenstand.
Einen Beitrag hierzu hat das Forschungsprojekt „EmbeddedSafeSec“ [2], dessen Ziel die Entwicklung eines Prozessmodells und einer integrierten Methodik zur Gewährleistung von Safety und Security bei der Entwicklung kritischer eingebetteter Systeme war, geleistet [EmbeddedSafeSec].
Um den Abgleich zu erreichen, wurden die Lebenszyklen von Safety und Cybersecurity so in zusammenhängende Aktivitäten gegliedert, dass sie zumindest teilweise zu Aktivitätenpaaren zusammengefasst und im Rahmen eines Co-Engineering-Prozesses gemeinsam bearbeitet werden können (Abb. 5).
Abbildung 6 veranschaulicht diese recht komplexe Zuordnung von Aktivitäten der funktionalen Sicherheit und der Cybersicherheit für die Softwareentwicklung, und Abbildung 7 zoomt weiter auf die Aktivität der 'Verifikation der Softwareunits'.
Der obere Teil von Abbildung 7 zeigt die verschiedenen Abschnitter der ISO 26262 und der ISO/SAE 21434, die auf ein Aktivitätspaar für die Verifikation der Software-Units abgebildet werden können. Im unteren Teil sind die Input- und Output-Arbeitsprodukte sowie die Ziele dieses Aktivitätspaares aufgeführt.
Anwendungsbeispiel: Überprüfung von Modellierungs- und Kodierrichtlinien
In der Automobilindustrie werden bei der Anwendungssoftwareentwicklung häufig Methoden der modellbasierten Entwicklung (MBE; engl. Model-Based Design, MBD) eingesetzt. Zur Unterstützung dieser Methoden werden Modellierungswerkzeuge wie Simulink und TargetLink eingesetzt.
Im Rahmen eines MBE-Ansatzes könnte das Design der Softwareunits durch ausführbare Implementierungsmodelle in TargetLink beschrieben und die anschließende Implementierung in C-Code durch Code-Generierung automatisiert werden.
Sowohl ISO 26262 als auch ISO/SAE 21434 verlangen die Anwendung von Modellierungs- und Kodierungsrichtlinien, um mögliche negative Auswirkungen bestimmter Eigenschaften der Modellierungs- bzw. Implementierungssprachen auf die funktionale Sicherheit bzw. die Cybersicherheit zu vermeiden. Für die Sprache C können solche Richtlinien auf den MISRA C oder CERT C Guidelines basieren.
Durch die Verwendung von MBE kann ein wesentlicher Teil dieser Richtlinien bereits auf der Ebene des Implementierungsmodells, d.h. durch die Anwendung entsprechender Richtlinienprüfungen auf Modellebene, überprüft und sichergestellt werden.
Bei einem Co-Engineering-Ansatz für Sicherheit und Cybersicherheit würden die Unternehmen bei der Unitverifikation einen gemeinsamen Satz von Modellierungsrichtlinien anwenden, um sowohl die funktionale Sicherheit als auch die Cybersicherheit zu berücksichtigen.
Ein solcher Leitfaden könnte z.B. Prüfungen zur Sicherstellung konsistenter Eingaben (Datentyp und Skalierung) und konsistenter Datenbereiche für arithmetische Operationen enthalten (Abb. 8).
Bei der Verwendung von TargetLink mit Integer-Arithmetik müssen beispielsweise der Datentyp der Ausgänge und die Skalierung der Zwischenvariablen ausreichend sein, um einen Überlauf zu vermeiden. Dies wird durch die Implementierung des Datentyps mit ausreichender Bitlänge für die Ausgabe und die Speicherung von Zwischenergebnissen zur Vermeidung von Sättigungsgrenzen in der Integer-Arithmetik über die Option Integer-Overflow erreicht.
Ein Richtliniensatz für das Safety & Cybersecurity Co-Engineering würde auch eine Modellierungsrichtlinienprüfung enthalten, um unbeabsichtigte direkte Vergleiche von Gleitkommadatentypen auf exakte Gleichheit zu erkennen (Abb. 9). Eine solche Prüfung würde z. B. das Beispiel im unteren linken Teil von Abbildung 9 flaggen, so dass es durch die verbesserte Modellierung im unteren rechten Teil der Abbildung ersetzt werden kann.
Um die Effizienz des Softwareentwicklungsprozesses zu gewährleisten, sollte die Überprüfung von Modellierungs- und Codierungsrichtlinien so weit wie möglich automatisiert werden. Ingenieure können durch Richtlinienüberprüfungswerkzeuge wie MXAM wirksam unterstützt werden, um die Einhaltung von Modellierungsrichtlinien zu gewährleisten und damit Safety und Cybersecurity zu unterstützen. Beispielsweise werden die in der ISO 26262 oder ISO/SAE 21434 erwähnten Richtlinien nun vollständig durch die Richtlinienbibliothek von MXAM abgedeckt. Darüber hinaus wurden Richtlinien zur funktionalen Sicherheit und Best Practices führender Industrieunternehmen in MXAM integriert, um Ingenieure bei der automatischen Überprüfung und Korrektur ihrer Modelle zu unterstützen. MXAM kann auch Berichte für bestimmte vordefinierte Richtliniensätze erstellen und Richtlinienverletzungen automatisch korrigieren. Abbildung 10 zeigt den Prozess der automatischen Modellanalyse und -korrektur in MXAM.
Fazit
Funktionale Sicherheit, SOTIF und Cybersicherheit sind eng miteinander verflochten. Es gibt insbesondere keine Safety ohne Cybersecurity. Die traditionelle Trennung zwischen den Sicherheitsaspekten (einschließlich funktionaler Sicherheit und SOTIF) muss durch einen ganzheitlichen Sicherheitsansatz ersetzt werden, der ein Co-Engineering von Safety und Security beinhaltet. Ein solcher Co-Engineering-Ansatz erfordert eine umfassende Zusammenarbeit während des gesamten Lebenszyklus und eine systematische Vorgehensweise. Eine leistungsfähige Werkzeugunterstützung kann dabei helfen, Synergien zu erzielen.
-------------------------------
[1] Die im Entstehen begriffene technische Spezifikation ISO TS 5083:2024 „Road vehicles - Safety for automated driving systems - Design, verification and validation“ (Straßenfahrzeuge - Sicherheit für automatisierte Fahrsysteme - Entwurf, Verifikation und Validierung) verfolgt einen ganzheitlicheren Sicherheitsansatz [ISO DTS 5083]. Aufgrund ihres engeren Fokus auf automatisierte Fahrsysteme ist dieses Dokument jedoch keine Basisnorm wie die oben genannten.
[2] Das Projekt EmbeddedSafeSec (01.03.2021 - 31.12.2022) wurde im Rahmen des Programms zur Förderung von Forschung, Innovation und Technologie (ProFIT) der Investitionsbank Berlin (IBB) und durch den Europäischen Fonds für regionale Entwicklung (EFRE) gefördert.
Quellen
- [ISO 26262] ISO 26262 ‘Road vehicles – Functional safety’. International standard, 2nd edition, ISO 2018
- [ISO/SAE 21434] ISO/SAE 21434 ‘Road vehicles – Cybersecurity engineering’. International standard, ISO/SAE 2021
- [ISO 21448] ISO 21448 ‘Road vehicles – Safety of the intended functionality’. International standard, ISO 2022
- [ISO DTS 5083] ISO DTS 5083 ‘Road vehicles – Safety for automated driving systems – Design, verification and validation’. Technical Specification (Draft), ISO 2024
- [Ser19] Serpanos: There Is No Safety Without Security and Dependability. IEEE Computer 52(6), June 2019, pp. 78 – 81
- [Rya18] A. Ryan: There is no safety without security. 2018 www.tessentembeddedanalytics.com/no-safety-without-security/
- [EmbeddedSafeSec] EmbeddedSafeSec Research Project. 2021-2022 https://embeddedsafesec.zesys.de/en/
