Automotive Safety und Security mit Linux und Open-Source-Software beherrschen

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Die geltenden Sicherheitsanforderungen für die Automobilindustrie schließen den Einsatz von Open-Source-Software aus – oder nicht? Tatsächlich können gutes OSS-Management, eine SEooC-Strategie und bewährte Linux-Pakete helfen, Automotive-Anwendungen schnell, sicher und vor allem günstig zu entwickeln.

Die Softwarekomplexität für Sicherheitsanwendungen in der Automobilindustrie nimmt weiter zu. Die Anforderungen an solche Automobilfunktionen wie Bordnetzmanagement, ADAS-Verbesserungen und autonomes Fahren (SAE-Level 4 und 5 für autonomes Fahren) haben zu branchenweiten Innovationen geführt. Dazu gehören der verstärkte Einsatz von Ethernet, die Ablösung mechanischer Systeme durch Digitaleinrichtungen und komplexe Entscheidungen, die nicht mehr vom Fahrer, sondern von der Software getroffen werden. Gleichzeitig hat der Technologietrend, Systemfunktionen in weniger, aber leistungsstärkeren Mikroprozessoren zu konsolidieren, zu einer erhöhten Abhängigkeit von 64-Bit-Multicore-Prozessoren (mit mehreren CPU-Kernen auf einem Chip) geführt, die mehr Rechenleistung und reduzierte Materialkosten für das Fahrzeug bieten.

Die zusätzliche Komplexität führt zu immer höher entwickelten Softwarearchitekturen, einschließlich von WLAN- und Mobilfunk-Konnektivitätsprotokollen zur Gewährleistung von Fahrfunktionen und Sicherheit. Die Interaktion von Automobilen mit der Außenwelt stellt eine Herausforderung im Hinblick auf die physische Sicherheit und Netzwerksicherheit dar. Sie stützen sich auf eine komplexe Software, die aufgrund der ständigen Änderung der Cyberbedrohungen für Fahrzeuge ständig weiterentwickelt werden muss. Daher ist es entscheidend, dass die Fahrzeugsoftware kontinuierlich über Over-the-Air-Updates (OTA) aktualisiert wird.

Bildergalerie

Automobilhersteller haben die Bewältigung dieser Probleme schrittweise in Angriff genommen, was schwierig und kostspielig sein kann, sowie im Falle des Scheiterns ein größeres Risiko für ihre Kunden und den Ruf dieser Unternehmen darstellt. Deshalb entschlossen sich die Fahrzeughersteller dazu, als Grundlage Open Source Software (OSS) zusammen mit Sicherheitsfunktionen einzusetzen, die beispielsweise von SELinux und OpenSSL bereitgestellt werden.

Einführung von ISO 26262 und Safety Elements out of Context

SEooC (Safety Element out of Context) ist eines der Konzepte, die in der internationalen Norm ISO 26262 zur Regelung der funktionalen Sicherheit bei der Produktinnovation in der Automobilindustrie formalisiert wurden. Dieses Konzept bietet eine gemeinsame Sprache zur Diskussion der Standardkomponenten und Kriterien, wenn man über ihren Einsatz in einem Steuergerät (ECU) zu entscheiden hat. Ein SEooC kann entweder eine Hardwarekomponente (ein Mikrocontroller oder LiDAR-Sensor) oder eine Softwarekomponente (ein Betriebssystem oder ein Datenbankmanager) sein. Für das SEooC bestehen erst dann Sicherheitsanforderungen, wenn es mit anderen Komponenten in einen Zusammenhang gebracht wird.

Betrachten wir einmal einen Mikroprozessor für die Automobilindustrie, wie den Fahrzeug-Netzwerkprozessor NXP S32G3 (siehe Bild auf der nächsten Seite). Dieser Prozessor verfügt über zahlreiche Funktionen, die sowohl die Netzwerkkonnektivität (CAN, LIN, Ethernet usw.), einschließlich der funktionalen Sicherheit, als auch die Datensicherheit unterstützen. Gleichzeitig ist der Prozessor auch für den Einsatz in einer Vielzahl von Fahrzeuganwendungen vorgesehen, die jeweils eigene Sicherheitsanforderungen (hinsichtlich der Sicherheitsfunktionen sowie des ASIL-Levels dieser Sicherheitsfunktionen) stellen.

Welche Funktionen des Prozessors verwendet und wie diese für eine bestimmte Funktion eingesetzt werden müssen, wird erst klar, wenn der OEM oder Tier-1-Lieferant entschieden hat, welche Funktionen der Prozessor unterstützen soll. Um die ordnungsgemäße Verwendung in einem sicherheitskritischen Gerät zu bestimmen, ist es notwendig, die Komponente in den jeweiligen Kontext zu setzen.

In einigen Fällen überprüft der Hersteller so viele Funktionen einer Komponente, wie im sicherheitskritischen Kontext als angemessen anzusehen sind. Der Hersteller muss auch eine zusätzliche Dokumentation (ein Sicherheitshandbuch) mit Beschreibungen zur Verfügung stellen, wie die Komponente installiert und verwendet werden muss, um die Sicherheitsaussagen des Herstellers zu untermauern, einschließlich von Chipfunktionen (wie beispielsweise Hardware-Debug-Unterstützung), die nicht im Sicherheitskontext verwendet werden dürfen.

Für handelsübliche Komponenten (wie beispielsweise Mikroprozessoren oder Echtzeit-Betriebssysteme) führt der Hersteller die zuvor erwähnte Analyse, Dokumentation usw. durch und lässt anschließend sein gesamtes Produkt, die zugehörige Dokumentation und seinen Entwicklungsprozess von einem Dritten – zum Beispiel vom TÜV SÜD – überprüfen. Von diesem erhält er eine Bescheinigung, die bestätigt, dass die Komponente für den Einsatz in einem Sicherheitssystem unter allen im Sicherheitshandbuch der Komponente dokumentierten Einschränkungen geeignet ist. Anschließend gilt die Komponente als „zertifiziert“, obwohl ein solches Zertifizierungskonzept für Komponenten in keinem Sicherheitsstandard definiert wird.

Ist es gut, Open Source Software als SEooC zu verwalten?

Das in der ISO 26262 definierte SEooC-Konzept bietet zwar einen Rahmen, der bei der Integration einer externen Komponente in ein Steuergerät zu berücksichtigen ist – kann aber für sich betrachtet nicht den Einsatz von OSS in sicherheitskritischen Systemen rechtfertigen. In der ISO 26262–10:9.1 ist dies recht deutlich festgelegt: „Ein SEooC wird auf der Grundlage von Annahmen in Übereinstimmung mit der Normenreihe ISO 26262 entwickelt. Es ist für die Verwendung in mehreren verschiedenen Elementen vorgesehen, wenn die Gültigkeit seiner Annahmen bei der Integration des SEooC nachgewiesen werden kann.“

Eine Open Source Software wird nicht „... in Übereinstimmung mit der Normenreihe ISO 26262 entwickelt“. Die Entwicklungsstandards für Linux und andere gängige Open-Source-Projekte, wie OpenSSL und Python, sind qualitativ hochwertig und robust (z. B. Standards für allgemeine handelsübliche Software im Vergleich zu Software für ein Sicherheitssystem). Somit darf eine OSS-Komponente im Sinne der strengen Definition für diesen Begriff nicht als SEooC betrachtet werden.

Dennoch ist es wichtig, bei Überlegungen zu einer Open Source Software in einer Fahrzeugsicherheitsanwendung in diesen Begriffen zu denken. Fragen Sie sich also selbst: Welche Annahmen müssen bei der Integration der OSS-Komponente validiert werden? Für eine hochwertige Open-Source-Komponente, die in einem Sicherheitskontext eingesetzt werden soll, haben wir umfangreiche Kenntnisse und Dokumentationen, die mögliche Annahmen hierfür beschreiben. So würde zum Beispiel angenommen, dass jede dokumentierte API einer OSS-Komponente bei jedem gültigen Aufruf wie in der Dokumentation beschrieben funktioniert. Dasselbe würde für Funktionen gelten, die nicht vollständig durch API-Aufrufe gesteuert werden, wie RTLinux, aber zur sicheren Umsetzung aller zeitabhängigen Anforderungen mit Linux erforderlich sind.

Obwohl wir eine OSS-Komponente nicht als SEooC betrachten dürfen, dient sie bei der Analyse zur Verwendung einer Open Source Software als Orientierung, da dieselben Überlegungen berücksichtigt werden müssen – welche OSS-Funktionen sind tatsächlich erforderlich, um die Sicherheitsanforderungen des Objekts zu erfüllen, welche ASIL-Level werden diesen Funktionen zugewiesen und wie verifizieren wir diese Funktionen im Kontext eines sicherheitskritischen Systems?

Management einer OSS im ISO 26262-Kontext

Es ist nützlich, einmal eine andere sicherheitsorientierte Branche – die Medizintechnik – dahingehend zu untersuchen, wie sie Open Source Software (und andere nicht zertifizierte Komponenten) in sicheren Geräten einsetzt. Die speziellen Sicherheitsanforderungen sind in der Automobil- und Medizintechnik vollkommen unterschiedlich. Doch beide Industriebereiche konzentrieren sich bewusst auf die Produktsicherheit, da für sie dieselben juristischen und moralischen Risiken sowie Rufgefährdungsrisiken zutreffen.

Für medizinische Software wurde das „SOUP“-Konzept (Software of Unknown Provenance) als Rahmenwerk für extern entwickelte Softwaremodule definiert. SOUP ist ein etabliertes Softwaremodul, das allgemein verfügbar ist, aber nicht speziell für medizintechnische Geräte entwickelt wurde (IEC 62304:3.29). Die Verwendung eines SOUP in einem medizinischen Gerät muss die folgenden Anforderungen erfüllen (beschrieben in mehreren Abschnitten der IEC 62304):

• Die Anforderungen (hinsichtlich Funktionalität und Leistung) an ein SOUP müssen spezifiziert werden;

• Ausfälle oder unerwartete Ergebnisse müssen berücksichtigt werden, um gefährliche Situationen zu verhindern;

• Bekannte Probleme des SOUP müssen bewertet werden, und jede Anomalie, die zu möglichen Gefahrensituationen führen kann, muss (hinsichtlich Risiko und Gefahr für die Patienten) auf ein akzeptables Maß reduziert werden; und

• Die Wartung und Pflege des SOUP (Upgrades usw.) muss berücksichtigt werden.

Alle mit der SOUP-Nutzung verbundenen Risiken müssen für die Dauer des gesamten Produktlebenszyklus berücksichtigt werden – Entwicklung, Verifizierung, Validierung und Wartung, einschließlich der Minderung von Risiken auf ein akzeptables Niveau. Viele Hersteller von Medizintechnik verwenden mittlerweile Linux- und andere OSS-Pakete, um sich die behördliche Zulassung durch Behörden wie die FDA (USA) und die National Medical Products Administration (NMPA) in China zu sichern.

Obwohl das SOUP-Konzept nicht auf den Automobilmarkt ausgerichtet ist, demonstriert es, wie ein OSS-Modul zum Erfolg einer sicherheitskritischen Automobilkomponente beitragen kann. Das Ziel besteht in der durchgängigen Einführung der Open Source Software für den gesamten Entwicklungslebenszyklus sowie in der Identifizierung und Minderung der bei Verwendung dieser Software eingeführten Risiken. Entscheidend ist es, zu demonstrieren, wie Gefahren auf das in ISO 26262 festgelegte Niveau für Einzelelemente gemindert werden. Dies lässt sich dadurch erreichen, dass Hardware- und Software-Designelemente zur Begrenzung der Wahrscheinlichkeit des Eintretens spezifischer identifizierter Gefahren berücksichtigt werden. Auf diese Weise wird der E-Wert (die Wahrscheinlichkeit einer Exposition) auf ein Niveau gesenkt, das zur Begrenzung des ASIL-Niveaus der untersetzten Sicherheitsforderung auf ein zufriedenstellendes Niveau gemäß ISO 26262-3:6.4.3 und Anhang B führt.

Weitere Designüberlegungen für die Fahrzeugsicherheit

Auch wenn die Einhaltung eines ISO 26262-konformen durchgängigen Entwicklungslebenszyklus bei der Erstellung sicherheitskritischer ECUs entscheidend ist, gibt es beim Einsatz von Open Source Software für funktionsreiche, sichere Geräte weitere Überlegungen, die Anpassungen hinsichtlich der Implementation in den Lebenszyklus nötig machen können:

• Zur Einhaltung der Sicherheit gemäß ISO 26262 muss der Entwickler Gefährdungen identifizieren, die dementsprechenden Sicherheitsanforderungen definieren und diese entsprechenden Teilsystemen zuordnen und zuweisen. Anschließend werden diese Teilsysteme (mit weiter untergliederten Teilanforderungen) sowohl für die Hardware als auch für die Software konzipiert und entwickelt.

• Die Untergliederung ist so detailliert wie möglich durchzuführen, einschließlich einer Analyse der Fähigkeiten der OSS zur Erfüllung dieser untergliederten Teilanforderungen sowie weiterer Gefährdungen, die sich aus ihrer Verwendung ergeben könnten. Auf diese Weise kann der Benutzer (bei Bedarf) Maßnahmen zur Risikominderung definieren, um die Wahrscheinlichkeit des Auftretens einer Gefahr zu begrenzen und den Schweregrad zu verringern, falls bzw. wenn diese Gefahr auftritt.

• Mehrere Sicherheitsanforderungen in einem System werden durch dieselben von der durch die Open Source Software bereitgestellten Fähigkeiten unterstützt.

• Der Einsatz einer modernen ALM-Lösung kann die Gesamtverfolgbarkeit dieser Anforderungen gewährleisten, insbesondere wenn im ersten Schritt oder während einer Iteration während der Entwicklung des Geräts neue Gefahren (und neue Sicherheitsanforderungen) identifiziert werden.

• Die Risikominderungen werden im Rahmen eines ISO 26262-konformen Entwicklungsprozesses verwaltet. Findet die Risikominderung getrennt von der Open Source Software statt, so ist sie Bestandteil der Software, die vom Geräteentwickler geschrieben wird. Sie muss daher auf dieselbe Weise entwickelt werden. Infolgedessen ist es erforderlich, sie in den ISO-26262- Entwicklungsprozess des Entwicklers zu implementieren.

• All dies muss hinsichtlich Dokumentation, Implementation, Validierung und Verifizierung demselben Standard gerecht werden, den der Geräteentwickler für den Rest seiner Implementierung verwendet.

• Im Hinblick auf neue OSS-Versionen müssen die Entwicklungsunternehmen regelmäßig die Problemlisten für die im Gerät eingesetzten OSS-Module überprüfen und bestimmen, ob neue Probleme zur Beeinträchtigung der Fahr- oder Datensicherheit beim Endgerät führen können und nicht vermieden werden können.

• Es ist entscheidend, dass die OSS-Community groß gefasst und engagiert ist, gut definierte Entwicklungsmethoden bietet, Probleme erkennt, verfolgt und behebt sowie bei Bedarf auftretende Fragen beantwortet. Projekte wie Linux, glibc und OpenSSL sind einige Beispiele für Communities, die Module für sichere Systeme unterstützen, da sie alle oben genannten Anforderungen erfüllen.

Bei den Überlegungen, ob eine Open-Source-Software in einem Gerät mit Sicherheitsanforderungen für die Automobilindustrie eingesetzt werden kann, ergeben sich Herausforderungen, da kein OSS-Paket nach den Standards entwickelt wurde, die gemäß ISO 26262 oder anderen Sicherheitsnormen erwartet werden. Obwohl es einen gewissen Aufwand erfordert, können diese Pakete auch in einem Sicherheitskontext zur Anwendung gelangen, ohne die Sicherheitsziele eines Geräts zu beeinträchtigen. Siemens Embedded verfügt über jahrzehntelange Erfahrungen, die OEMs oder Tier-1- bzw. Tier-2-Lieferanten für die Automobilindustrie bei der Meisterung dieser Anforderungen und bei der erfolgreichen Bereitstellung einer Open-Source-Software in ihren Geräten unterstützen können.

Multikernel-OS

Ein Automotive-Betriebssystem für neue Herausforderungen

Open Source und Automotive-Applikationen

So viel Open Source wird in der Automobilindustrie bereits genutzt

* Robert Bates ist Chief Safety Officer for Embedded Platform Systems bei Siemens Digital Industries Software.

(ID:48228480)