Funktionale Sicherheit wird zunehmend zu einem bedeutenden Aspekt bei der Entwicklung von softwarebasierten Systemen in der Automobilindustrie, sowohl bei OEMs als auch bei Tier-1 und Tier-n Lieferanten. In diesem Beitrag wird die Lösung für ein allgemeines Problem beschrieben, wenn der Bedarf besteht, zwischen den Organisationen entlang der Lieferkette Sicherheitsinformationen auszutauschen.
Maßnahmen für funktionale Sicherheit betreffen den gesamten Lebenszyklus des zu entwickelnden Systems (bzw. der zu entwickelnden Komponente) und werden von allen Beteiligten entsprechend ihren jeweiligen Zuständigkeiten durchgeführt. Daher müssen die Arbeitsergebnisse dieser sicherheitsrelevanten Aktivitäten zwischen allen beteiligten Unternehmen ausgetauscht werden. Die Details wie Aufgaben, Zuständigkeiten und Ergebnisse müssen gemäß ISO-Norm 26262 in einem Development Interface Agreement (DIA) festgelegt werden. Die ISO-Norm 26262 schreibt jedoch nicht vor, auf welche Weise diese Informationen ausgetauscht werden sollen (bezüglich der Inhalte, Formate usw.). In der gängigen Praxis führt dies oftmals zu ineffizienten, auf manueller Dokumentationserstellung beruhenden Verfahren und innerhalb der Lieferkette zu duplizierten Informationen sowohl auf Integratoren- als auch Lieferantenseite. Ebenso kann es geschehen, dass wichtige Informationen fehlen, wenn bestimmte Tätigkeiten (wie die Bereitstellung oder Konfiguration von Sicherheitsmechanismen der Basissoftware) ausgeführt werden. Das Ergebnis sind Unstimmigkeiten, unzureichende Rückverfolgbarkeit und Probleme bei der Zusammenstellung der allgemeinen Sicherheitsnachweise.
Andererseits gewährleistet die Verwendung der AUTOSAR-Architektur in Kombination mit der AUTOSAR-Methode und Support- Tools bereits die Nutzung von Standardformaten für den Austausch von Entwicklungsinformationen für alle Unternehmen in der Lieferkette. Unter Verwendung dieser Formate können für die Implementierung von Softwaresystemen und ECUs relevante Informationen auf komfortable Weise ausgetauscht werden. Nachstehend wird aufgezeigt, wie mit den seit Version 4.2.1. im AUTOSAR-Standard enthaltenen Erweiterungen das Problem des Austausches von Informationen zur funktionalen Sicherheit auf elegante Weise gelöst werden kann. Als Beispiel dient die Methode, wie ein OEM die funktionale Sicherheit für eine Fahrzeugplattform unterstützt (Bild 1). Der Prozess könnte sich im Hinblick auf die Tätigkeiten und Arbeitsprodukte für die funktionale Sicherheit aus folgenden, allgemeinen Phasen zusammensetzen:
Entwurf und Definition durch den OEM
Der OEM erstellt die übergreifenden Konzepte für die Komponenten (Systeme) einer Plattform. Die Ausarbeitung des Konzepts für die funktionale Sicherheit beginnt in der Regel auf der/den Komponentenebene/n einer Fahrzeugplattform, beginnend mit der Definition der Sicherheitsziele sowie der Anforderungen für die verschiedenen Komponenten, Systeme und Subsysteme der Plattform.
Auf diese Weise werden die spezifischen Sicherheitsmechanismen auf Subsystem- oder Systemebene durch Tier-1 implementiert und validiert.
Dies kann als schrittweiser Prozess erfolgen.
Ein ähnliches Verfahren gilt für Unternehmen auf niedrigeren Ebenen der Lieferkette, die zur Arbeit von Tier-1 beitragen.
Die oben beschriebenen Probleme mit dem Transfer sicherheitsrelevanter Informationen treten hauptsächlich in zwei Phasen auf, in denen diese Informationen zwischen Unternehmen ausgetauscht werden (Bild 2):
Das Ziel der Sicherheitserweiterungen besteht darin, die AUTOSAR-XML-Darstellung (.arxml) als das Standardformat zu etablieren, in dem Sicherheitsinformationen präsentiert und ausgetauscht werden. In der aktuellen Version, die Teil von AUTOSAR 4.2.1 ist, wurde ein Ansatz verwendet, der das bestehende AUTOSAR-Metamodell nicht verändert. Der neue Standard definiert aber, wie die Informationen nur unter Einsatz bestehender, allgemeiner Konzepte des AUTOSARMetamodells durch Verwendung spezifischer, standardisierter Tags und Inhalte bereitgestellt werden. Die Idee besteht darin, dass zusätzlich zu den herkömmlichen AUTOSAR-Modellen, die zwischen Unternehmen innerhalb der Lieferkette ausgetauscht werden, Sicherheitserweiterungen bereitgestellt werden, die das Modell um neue Elemente erweitern und sich gleichzeitig auf bestehende Elemente beziehen. Die Sicherheitserweiterungen können daher als reine Ergänzungen genutzt werden, das bedeutet, sie wirken sich auf bestehende AUTOSAR-Modelle nicht aus.
Sicherheitsanforderungen und Sicherheitsmaßnahmen
Gemäß dem vorstehend genannten Entwicklungsprozess sind die Hauptkonzepte der Sicherheitserweiterungen die Sicherheitsanforderungen und Sicherheitsmaßnahmen, gemeinsam mit deren ASIL-Attributen (Bild 4).
Die Nutzung der AUTOSAR-Sicherheitserweiterungen in Kombination mit angemessener Tool-Unterstützung bietet diverse Vorzüge. Die Notwendigkeit, Informationen in beliebigen Formaten (in der Regel Word und Excel) auszutauschen, wird reduziert, ebenso wie die Notwendigkeit, diese Daten zu konvertieren, wenn sie unternehmensübergreifend transferiert werden. Folglich können die Arbeitsabläufe wesentlich effizienter organisiert werden als zum aktuellen Zeitpunkt. Neben den Vorteilen im Prozess wird auch die Qualität der Sicherheitsinformationen gesteigert, da ihre Rückverfolgbarkeit optimiert ist, beispielsweise für die Argumentation zur Erlangung von Sicherheitsnachweisen. Außerdem ermöglicht diese explizite Rückverfolgbarkeit innerhalb der Modelle die Durchführung von Konsistenzprüfungen.
www.kpit.com
Maßnahmen für funktionale Sicherheit betreffen den gesamten Lebenszyklus des zu entwickelnden Systems (bzw. der zu entwickelnden Komponente) und werden von allen Beteiligten entsprechend ihren jeweiligen Zuständigkeiten durchgeführt. Daher müssen die Arbeitsergebnisse dieser sicherheitsrelevanten Aktivitäten zwischen allen beteiligten Unternehmen ausgetauscht werden. Die Details wie Aufgaben, Zuständigkeiten und Ergebnisse müssen gemäß ISO-Norm 26262 in einem Development Interface Agreement (DIA) festgelegt werden. Die ISO-Norm 26262 schreibt jedoch nicht vor, auf welche Weise diese Informationen ausgetauscht werden sollen (bezüglich der Inhalte, Formate usw.). In der gängigen Praxis führt dies oftmals zu ineffizienten, auf manueller Dokumentationserstellung beruhenden Verfahren und innerhalb der Lieferkette zu duplizierten Informationen sowohl auf Integratoren- als auch Lieferantenseite. Ebenso kann es geschehen, dass wichtige Informationen fehlen, wenn bestimmte Tätigkeiten (wie die Bereitstellung oder Konfiguration von Sicherheitsmechanismen der Basissoftware) ausgeführt werden. Das Ergebnis sind Unstimmigkeiten, unzureichende Rückverfolgbarkeit und Probleme bei der Zusammenstellung der allgemeinen Sicherheitsnachweise.
Andererseits gewährleistet die Verwendung der AUTOSAR-Architektur in Kombination mit der AUTOSAR-Methode und Support- Tools bereits die Nutzung von Standardformaten für den Austausch von Entwicklungsinformationen für alle Unternehmen in der Lieferkette. Unter Verwendung dieser Formate können für die Implementierung von Softwaresystemen und ECUs relevante Informationen auf komfortable Weise ausgetauscht werden. Nachstehend wird aufgezeigt, wie mit den seit Version 4.2.1. im AUTOSAR-Standard enthaltenen Erweiterungen das Problem des Austausches von Informationen zur funktionalen Sicherheit auf elegante Weise gelöst werden kann. Als Beispiel dient die Methode, wie ein OEM die funktionale Sicherheit für eine Fahrzeugplattform unterstützt (Bild 1). Der Prozess könnte sich im Hinblick auf die Tätigkeiten und Arbeitsprodukte für die funktionale Sicherheit aus folgenden, allgemeinen Phasen zusammensetzen:
Entwurf und Definition durch den OEM
Der OEM erstellt die übergreifenden Konzepte für die Komponenten (Systeme) einer Plattform. Die Ausarbeitung des Konzepts für die funktionale Sicherheit beginnt in der Regel auf der/den Komponentenebene/n einer Fahrzeugplattform, beginnend mit der Definition der Sicherheitsziele sowie der Anforderungen für die verschiedenen Komponenten, Systeme und Subsysteme der Plattform.
- Transfer vom OEM an Tier-1
- Entwurf und Definition durch
- Neuentwurf und Neudefinition durch Tier-1
- Implementierung durch Tier-1
Auf diese Weise werden die spezifischen Sicherheitsmechanismen auf Subsystem- oder Systemebene durch Tier-1 implementiert und validiert.
- Transfer von Tier-1 zum OEM
- Integration und Validierung durch den OEM
Dies kann als schrittweiser Prozess erfolgen.
Ein ähnliches Verfahren gilt für Unternehmen auf niedrigeren Ebenen der Lieferkette, die zur Arbeit von Tier-1 beitragen.
Die oben beschriebenen Probleme mit dem Transfer sicherheitsrelevanter Informationen treten hauptsächlich in zwei Phasen auf, in denen diese Informationen zwischen Unternehmen ausgetauscht werden (Bild 2):
- Transfer vom OEM zu Tier-1: Die zu übertragenden Informationen beinhalten die relevanten Teile des Konzepts für funktionale Sicherheit, also die Sicherheitsziele und -anforderungen, Sicherheitsmaßnahmen für die Architektur sowie Informationen über die Zuordnung der Sicherheitsanforderungen zu bestimmten Architekturelementen.
- Transfer von Tier-1 zum OEM: Hier sind die Informationen über die implementierten Sicherheitsmechanismen und -maßnahmen sowie die Zuordnungen zwischen den Sicherheitsanforderungen und diesen Mechanismen von Bedeutung.
Das Ziel der Sicherheitserweiterungen besteht darin, die AUTOSAR-XML-Darstellung (.arxml) als das Standardformat zu etablieren, in dem Sicherheitsinformationen präsentiert und ausgetauscht werden. In der aktuellen Version, die Teil von AUTOSAR 4.2.1 ist, wurde ein Ansatz verwendet, der das bestehende AUTOSAR-Metamodell nicht verändert. Der neue Standard definiert aber, wie die Informationen nur unter Einsatz bestehender, allgemeiner Konzepte des AUTOSARMetamodells durch Verwendung spezifischer, standardisierter Tags und Inhalte bereitgestellt werden. Die Idee besteht darin, dass zusätzlich zu den herkömmlichen AUTOSAR-Modellen, die zwischen Unternehmen innerhalb der Lieferkette ausgetauscht werden, Sicherheitserweiterungen bereitgestellt werden, die das Modell um neue Elemente erweitern und sich gleichzeitig auf bestehende Elemente beziehen. Die Sicherheitserweiterungen können daher als reine Ergänzungen genutzt werden, das bedeutet, sie wirken sich auf bestehende AUTOSAR-Modelle nicht aus.
Sicherheitsanforderungen und Sicherheitsmaßnahmen
Gemäß dem vorstehend genannten Entwicklungsprozess sind die Hauptkonzepte der Sicherheitserweiterungen die Sicherheitsanforderungen und Sicherheitsmaßnahmen, gemeinsam mit deren ASIL-Attributen (Bild 4).
- Sicherheitsanforderungen: In AUTOSAR R4.2.1 können klar unterscheidbare Sicherheitsanforderungen im AUTOSAR- Metamodell definiert werden, sodass die Vorgaben gemäß ISO 26262 Teil 4 und 8 (Abschnitt 4) erfüllt werden. Sicherheitsanforderungen können Attribute und Relationen haben, die verwendet werden, um sie gemäß ISO 26262 zu spezifizieren, wie z. B. Dekomposition oder Verfeinerung. Mit AUTOSAR-Trace können außerdem die Rückverfolgbarkeit und die Allokation von Sicherheitsanforderungen und Sicherheitsmaßnahmen gemäß ISO 26262 Teil 4, 6 und 8 (Abschnitt 6) beschrieben werden.
- Sicherheitsmaßnahmen: Sicherheitsmaßnahmen setzen sich aus einer Beschreibung in Textform, einer eindeutigen ID und einer Typangabe zusammen, die definiert, ob es sich um einen Sicherheitsmechanismus (z. B. Teil der AUTOSAR-Implementierung) oder eine externe Maßnahme handelt (z. B. einen Review). Außerdem können ASIL-Attribute gemäß ISO 26262 festgelegt werden.
- ASIL-Attributwerte: In AUTOSAR R4.2.1 können jedem AUTOSAR-Element Sicherheits-Integritätslevels / ASIL zugewiesen werden, einschließlich Sicherheitsanforderungen und Sicherheitsmaßnahmen.
Die Nutzung der AUTOSAR-Sicherheitserweiterungen in Kombination mit angemessener Tool-Unterstützung bietet diverse Vorzüge. Die Notwendigkeit, Informationen in beliebigen Formaten (in der Regel Word und Excel) auszutauschen, wird reduziert, ebenso wie die Notwendigkeit, diese Daten zu konvertieren, wenn sie unternehmensübergreifend transferiert werden. Folglich können die Arbeitsabläufe wesentlich effizienter organisiert werden als zum aktuellen Zeitpunkt. Neben den Vorteilen im Prozess wird auch die Qualität der Sicherheitsinformationen gesteigert, da ihre Rückverfolgbarkeit optimiert ist, beispielsweise für die Argumentation zur Erlangung von Sicherheitsnachweisen. Außerdem ermöglicht diese explizite Rückverfolgbarkeit innerhalb der Modelle die Durchführung von Konsistenzprüfungen.
www.kpit.com
