Startseite > Messen + Testen > Testsysteme > Adaptive AUTOSAR im Fokus der Sicherheit

Systemdesign / Safety&Security

Adaptive AUTOSAR im Fokus der Sicherheit

15. April 2019, 16:00 Uhr | M.Sc. Bogdan Gradinaru, Safety Expert CROWN Gabelstapler

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 5

Verifikationspunkte II

Einen guten Überblick über die meisten Softwareanforderungen aus ISO26262 Teil 6 auf AUTOSAR-Entwicklungen, gibt die klassische AUTOSAR_EXP_FunctionalSafetyMeasures Spezifikation Tabelle 12.

Sie definiert das Schichten-Architekturmodell, das den Grundstein für viele allgemeine Software-Sicherheitsanforderungen legt: etwa die Verwendung etablierter Designprinzipien oder ein modulares Design mit definierten Schnittstellen zwischen den Komponenten. Darüber hinaus ist der vollständige AUTOSAR-Spezifikationssatz für geeignete Abstraktion strukturiert. Die allgemeinen Systemanforderungen werden durch detaillierte Spezifikationen der Implementierungssoftware unterstützt: damit verfügt er über eine "integrierte Rückverfolgbarkeit".

Die Software-Spezifikationen beschreiben die Abhängigkeiten und Interaktionen der Module, mit den, über Sequenzdiagramme und funktionales Verhalten definierten APIs und Konfigurationsspezifikationen. Darüber hinaus gibt es eine ausführliche AUTOSAR-Metamodell-Beschreibung. Sie unterstützt grundlegende Sicherheitsanforderungen, wie eindeutige Notationen und grafische Darstellungen, zur Beschreibung der Softwarearchitektur.

Die Sicherheits-Spezifikation des adaptiven AUTOSAR fußen auf dieser Basis. Zur Diskussion der fünf Sicherheitsaspekte wird also die Manifestdatei die Meta-Modellbeschreibung sein. "Platform Health Manager" wird viele Fehlererkennungs- und Handhabungsmechanismen übernehmen und darüber hinaus Unterstützung für die Überwachung des Laufzeitsystems und den Lastausgleich bieten.

Das Strukturmodell der Spezifikationen bleibt unverändert, mit RS als Systemanforderungen und SWS als Softwarespezifikationen. Die Beschreibung des Funktionsverhaltens, der APIs und Konfigurationen, wird sich leicht ändern. Das funktionale Verhalten wird weniger detailliert: beschrieben werden nur noch die beteiligten Softwareeinheiten, der allgemeinen Ausführungsablauf und eventuell einige Designbeschränkungen. Die API muss die spezifischen C++-Datentypen und -Klassen sowie die Standardfehlertypen und Fehlerbehandlungsmechanismen beschreiben. Im Falle von adaptiven Diensten, geben die Softwarespezifikationen auch die Serviceschnittstellen an. Die müssen in ihren Manifestdateien konfiguriert werden. AUTOSAR_EXP_SafetyOverview gibt einen Überblick über die Maßnahmen im adaptiven Bereich zu geben.

Auch die Grenzen von AUTOSAR als Spezifikationsstelle für Softwarearchitekturen sollten verstanden sein. Diese erläutert das Kapitel "Bekannte Einschränkungen" (known limitations) im AUTOSAR_EXP_SafetyOverview. Da Sicherheit völlig vom Anwendungskontext abhängt, kann es auch mit adaptive AUTOSAR kein vollständiges Sicherheitskonzept geben. Vielmehr sind die notwendigen Integritätsmechanismen für das höchste Kritikalitätsniveau, ASIL D zu bewältigen. Das besprechen die Kapitel 4, 5 und 6 in dem erwähnten Dokument. Damit können Sicherheitsobjektive für gebrauchsfertige Softwaregruppen formuliert werden.

Es existieren noch viele Herausforderungen und offene Punkte fernab obiger Diskussion. Beispielsweise Themen, die mit Fehlertoleranzmechanismen oder der Aufrechterhaltung wesentlicher Fahrzeugfunktion im Fehlerfall, zusammenhängen. Weiterhin Mechanismen, die sich mit der Fehlerisolierung, der zunehmenden Komplexität und dem Grad der Kritikalität gemischter Software sowie einem Konzept für abhängige Fehler befassen.

Sobald die Industrie mehr Erfahrung und Reife mit hochautonomen Fahrsystemen gesammelt hat, sind diese Themen anzugehen. Dafür sollten auch Entwicklungs- und Validierungstechniken aus anderen Branchen, die echtzeitkritische Systeme betrachten, berücksichtigt werden. (ct)