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 2

Abstraktionsebenen und Sicherheitsmodell

Die neue Architektur betrachtet im Wesentlichen drei Entitäten: adaptive Anwendungen, Plattformdienste und Foundation Cluster. Die adaptiven Anwendungen sind als vollständig portierbare und wiederverwendbare Software konzipiert und können auch außerhalb des Automotive-Segements als Bibliothek bereitgestellt werden.

Bild 4: Monitoring der Plattformsicherheit
Bild 4: Monitoring der Plattformsicherheit
© Autosar - AUTOSAR_EXP_PlatformDesign

Die Plattformdienste und "Foundation Cluster" sind Software-Cluster, die automobiltypische Dienstleistungen wie Diagnose, Update, Kommunikation, Plattformzustand und Ausführungsmanagement oder Zeitsynchronisation handeln (Bild 4). Sie sind grundsätzlich als Software-Werkzeuge konzipiert, die von den adaptiven Steuergeräten bereitgestellt werden, im Gegensatz zum klassischen AUTOSAR mit vollständig definierten Schnittstellen.

Das primäre Ziel von Adaptive AUTOSAR war die Spezifizierung der Schnittstelle bzw. der Middleware, zwischen den adaptiven Anwendungen und den übrigen Plattformdiensten. Darüber werden die wesentlichen Fahrzeugdienste bereitgestellt. Das Dokument AUTOSAR_EXP_PlatformDesign gewährt einen weiterführenden Einblick in die technischen Aspekte der adaptiven Plattform.

Die nächste AUTOSAR-Generation addressiert also eine hochdynamische, anpassungsfähige Ausführungsumgebung: zur Laufzeit wird Software aktualisiert und die Konfigurations- und Kommunikationswege verändert. In unterschiedlichen Programmiersprachen formulierte und kompilierte Anwendungen müssen die notwendige Infrastruktur zur Interaktion vorfinden.
 
Die Systemsicherheit betrachtet sämtliche Konstruktionen, die zu flexibel, zu dynamisch oder zu dezentral sind, zurückhaltend. Teil 6 der ISO26262 (Sicherheit in der Produktentwicklung auf Softwareebene) betont bis in den letzten Winkel eine geringe Komplexität, den Einsatz von defensiven Implementierungstechniken, Kontrolle des Datenflusses sowie strenge Überprüfung von Konfigurations- und Kalibrierdaten. Darüber hinaus verbietet die IEC61508 in ihrem zweiten Teil (Softwareanforderungen), Tabelle A.2 (Softwaredesign und -entwicklung: Softwarearchitekturdesign), grundsätzlich die dynamische Rekonfiguration vor Ort. Sie könnte die Systemfreiheit erhöhen und unvorhersehbares Verhalten bewirken.

Damit ist die Frage gestellt, wie all diese Funktionen mit den bestehenden AUTOSAR-Sicherheitsmaßnahmen und der hochmodernen Sicherheitsentwicklung zurechtkommen: diesen Determinismus stringent durchsetzen, eine strenge Kontrolle und Überwachung der Ressourcen und des Kontrollflusses ermöglichen, eine feste Konfiguration zur Laufzeit mit einer begrenzten Teilmenge der Programmiersprachen gewähren und unsichere Funktionen blockieren.

Es ist klar, dass die Bibliotheksprogrammierung, die intensive Nutzung der dynamischen Speicherzuweisung, die hohe Hardwareparallelität und die Rekonfiguration der Strategien zur Ablaufplanung in der Laufzeit, neue de-facto-Entwicklungsmethoden für adaptives AUTOSAR werden.

Es wird nicht einfach sein, dies mit MISRA-Richtlinien, de-facto-Codierrichtlinien in der Automobilindustrie, dem Verbot der Verwendung von dynamischem Speicher oder mit vielen bestehenden, in das Betriebssystem eingebetteten Sicherheitsmaßnahmen zu vereinbaren. Beispielsweise einem stringenten Interrupt- und Ressourcenmanagement oder einer statischen OS-Konfiguration. Adaptives AUTOSAR fordert nicht wie das klassische AUTOSAR ein bestimmtes Betriebssystem, sondern nur POSIX-Konformität.

Die Grundlage dieses neuen Sicherheitsmodells für für lose gekoppelte, serviceorientierte Architekturen wird untersucht. Dazu müssen die oben genannten Hauptziele von Adaptive AUTOSAR in Korrelation mit den technischen Mechanismen erneut erklärt werden.


  1. Adaptive AUTOSAR im Fokus der Sicherheit
  2. Gründe für den neuen Standard
  3. Abstraktionsebenen und Sicherheitsmodell
  4. Zielführende Middleware
  5. Verifikationspunkte I
  6. Verifikationspunkte II

Lesen Sie mehr zum Thema


Das könnte Sie auch interessieren

Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu AUTOSAR

Weitere Artikel zu Motion Control