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 3

Zielführende Middleware

Die Ziele lassen sich in zwei Hauptziele unterteilen: Zunächst eine flexible Konfiguration der Steuergeräte im Fahrzeug (Bild 5), die eine modulare Bereitstellung der Anwendung ohne Neuprogrammierung des gesamten Steuergeräts ermöglicht. Weiterhin übernimmt die selbe Ansteuerung mit dem hohen Integrationsgrad, ein breites Spektrum von Fahrzeuganwendungen, vom Infotainment bis hin zur Lenksteuerung oder Bremse.

Jobangebote+ passend zum Thema

Ingenieur/Elektroingenieur/Elektrotechniker als Field Application Engineer

GEYER Electronic GmbH, Planegg

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Die vorherige, nämlich dynamische Konfiguration, ist mit obigen Gründen eine große Herausforderung für die Sicherheit dar. Letztere impliziert ein hohes Maß an Anwendungen gemischter Kritikalität, deren Rückwirkungsgrad zu bewältigen ist.

AUTOSAR zählt also grundsätzlich drei Arten von Komponenten oder Software-Dienstprogrammen:

Anwendungen, die völlig unabhängig und portierbar sein sollen,
die Service-Plattform-Komponenten, welche automobilspezifische Funktionen wie Diagnose oder Netzwerkmanagement implementieren und nur über adaptive Plattformen hinweg portabel sind
Funktions-Cluster, also plattformabhängige Komponenten, spezifisch zu einem bestimmten adaptiven ECU und seiner Konfiguration.

Im Gegensatz zum klassischen AUTOSAR, das viele Schnittstellen als c-Funktionen zusammen mit ihrer internen Struktur festsetzt, legt adaptives AUTOSAR den Fokus auf die Spezifikation der Schnittstellen (Bild 6) zwischen diesen drei Komponententypen. Zusätzlich werden einige Randbedingungen für das Design der plattformabhängigen Komponenten festgelegt. Die interne Struktur zur Implementierung bleibt dem Anwender überlassen: am Fundament einer service-orientierten Architektur werden technologie- und produktabhängige Module festgelegt.

Die Standard-Middleware im adaptiven AUTOSAR heißt ARA. (AUTOSAR Runtime for Adaptive Applications - beschrieben in der Spezifikation AUTOSAR_EXP_ARAComAPI) Sie soll die API definieren, mit der jeder Dienst oder jede Anwendung, Softwarekomponenten auf einem adaptiven Steuergerät völlig transparent anspricht - ohne Kentniss der Implementierungssprache dieser Komponente, der unterliegenden Hardware oder des spezifischen Kommunikationsprotokolls. Diese Gesamheit definiert das sogenannte "verbindliche Protokoll" (binding protocol). Die akutelle adaptive AUTOSAR-Version unterstützt C++11 (language binding) als Sprachbindung und Ethernet als Netzwerkbindung (network binding).

Die Bindung der Einzelkomponenten in diesem Rahmen erfolgt folgendermaßen: jede kann im Wesentlichen entweder als Kunde (client) oder als Anbieter (server) betrachtet werden. Außerdem ist eine Datenbank notwendig, die Dienste registriert und als Broker fungiert - eingehende Serviceanfragen entgegennimmt, Anfragen nach der entsprechenden Übereinstimmung stellt und schließlich die Anfragen abfertigt. Bei AUTOSAR spielt diese Brokerrolle der Funktionscluster "Communication Management". Er stellt die Mechanismen zur Bereitstellung oder Anspruchnahme von Diensten transparent bereit. Darüber hinaus haben auch die Applikationsbeschreibung und die Konfigurationsdatei eine entscheidende Rolle in Bezug auf die Systemsicherheit.

Die Manifestdatei wird zur Softwarebeschreibungsdatei der adaptiven Plattform: alle kritischen Konfigurationen und die Abonnement-Rechte der Komponenten, die spezifischen Kommunikationsprotokolle (Ethernet, CAN, usw.), der Zugriff auf Hardware-Ressourcen und die notwendigen Sicherheitskonfigurationen, sind dort hinterlegt.