Adaptive Platform von AUTOSAR

Dieser Artikel besteht aus zwei Teilen: Im ersten Teil geht es um die AUTOSAR Classic Platform für tief eingebettete Steuergeräte auf Basis von Microcontrollern.

Motivation

Die Digitalisierung von Fahrzeugen geht über tief eingebettete Geräte hinaus und hat zu weiterem Wachstum geführt, das durch neue spezielle Hardware ermöglicht wurde. Die Entwicklung des autonomen Fahrens wird dazu führen, dass in der Zukunft zusätzliche übergeordnete Funktionen in Fahrzeuge integriert werden.

Die Classic Platform eignet sich für die Programmiersprache C und kleine, tief eingebettete Geräte. Die Adaptive Platform zielt auf die nächsthöhere Abstraktionsschicht ab. Diese umfasst eine leistungsfähigere Hardware. Beide sind für komplexere Anwendungsfälle erforderlich. Deshalb nutzt die Adaptive Platform die Programmiersprache C++ ab Version C++11 und C++14. Bei der Ziel-Hardware handelt es sich um leistungsfähige Einplatinencomputer mit POSIX PSE51-konformem Betriebssystem mit Mehrkernprozessoren und eventuell auch High Performance Computing (HPC).

Der Standard

Die Adaptive Platform steht zwischen den Welten der tief eingebetteten Steuergeräte (bleiben bei Classic) und der Welt der Infotainment-Geräte (die entweder so bleiben oder noch mehr mit dem mobilen Markt verschmelzen). Etwas weichere Echtzeit-Anforderungen müssen erfüllt werden, wobei Verzögerungen im Millisekunden-Bereich vertretbar sind. Wenn die verwendete Software (Mehrkernprozessoren, HPC-Hardware) leistungsfähiger ist, ermöglicht dies die Umsetzung anspruchsvollerer Features.

Ein weiterer Unterschied zwischen den Plattformen Classic und Adaptive liegt in der geplanten Dynamik. Mit der Classic Platform muss die Variabilität meist in Compile-Zeit bearbeitet werden, also während der Entwicklung eines Steuergeräts. Mit der Adaptive Platform wird die Entwicklung von Diensten in Laufzeit ermöglicht. Die tatsächlich erlaubte Flexibilität (es dürfen nur vorkonfigurierte Dienst-Instanzen entwickelt werden, oder alles darf entwickelt werden) kann für jede SWC festgelegt werden.

Von der Architektur her ist das grundsätzliche Muster der Adaptive Platform ähnlich wie das der Classic Platform: Die Schichtenarchitektur ist standardisiert und weitgehende Hardware-übergreifende Programmierschnittstellen und Anwendungsdienste werden bereitgestellt. Hier sehen Sie eine grafische Übersicht. Die neu definierte Schnittstelle „AUTOSAR Runtime for Adaptive Applications“ (ARA) ist der geistige Nachfolger der von der Classic Platform bekannten RTE und enthält viele Bibliotheken und Dienste. Eine sogenannte adaptive Anwendung beruht ausschließlich auf diesen Funktionen und ist voll portabel. Für anspruchsvolle Anwendungsfälle kann man auch nicht-portable Abhängigkeiten (z. B. auf spezieller Hardware) nutzen, wobei dann allerdings die Portabilität zwischen den kompatiblen Steuergeräten reduziert wird.

Architektur der AUTOSAR Adaptive Platform. Auf Grundlage von Abbildung 3-1 aus Explanation of Adaptive Platform Design, S. 13.

Die Adaptive Platform – Grundlage

Die Grundlage bilden 11 Funktionscluster, die man grob in drei Kategorien unterteilen kann: Grundlegende Funktionalitäten, Kommunikation sowie Sicherheit.

Grundlegende Funktionalitäten

Execution Management (ara::exec) beschäftigt sich mit dem Zustand der Anwendungen und des Steuergeräts insgesamt. Nach Anschalten und Booten des Kernels startet das Execution Management die Systeminitialisierung und kontrolliert das Hochfahren und Beenden aller anderen Softwarekomponenten der Anwendung. Dies lässt sich durch Manifeste detailliert konfigurieren, was aktive Anwendungssets ermöglicht, welche an den Maschinenstatus angepasst sind. Zur Vereinfachung können verwandte Anwendungen in Funktionsgruppen mit gemeinsamen Ausführungseigenschaften zusammengefasst werden.

Schnittstelle des Betriebssystems(n/a) bestimmt die Funktionalitäten, die von der Adaptive Platform selbst nicht effizient umgesetzt werden können, jedoch vom Host-Betriebssystem. Diese Funktionalitäten sind (a) PSE51-Compliance, (b) grundlegendes Ressourcenmanagement für Speicher und CPU sowie (c) Unterstützung der zeitgesteuerten Ausführung. Dieses Funktionscluster ermöglicht außerdem, dass das Betriebssystem die Kontrolle an das Execution Management übergibt, sobald das Host-System initialisiert wurde.

Logging und Tracing(ara::log) stellt APIs für Adaptive Anwendungen und den Rest der Plattform zur Verfügung, um Ereignisse zu protokollieren. Es unterstützt Schweregrade (Debugging, Information, Warnung und Fehler) sowie das Konzept von Kontext und Logger-Informationen, anhand derer Nachrichten gruppiert und gefiltert werden können.

Persistenz(ara::per) hält permanente Speicherung für (read-only) Konfigurationsdaten, Lesen und Schreiben von anwendungsspezifischen Datenformaten bereit. Was die Features angeht, so unterstützt sie die Fehlererkennung und -korrektur. Es werden sowohl dateibasierte als auch Schlüssel-Werte-APIs angeboten.

Zeitsynchronisation (ara::tsync) ermöglicht es Anwendungen, eine gemeinsame Zeitbasis einzustellen und abzurufen. Dieses Funktionscluster stellt keine eigene Zeitbasis zur Verfügung, sondern erlaubt Nutzern, entweder als Zeitgeber (Master) oder als Requester (Slave) zu agieren. Unterschiedliche Zeitbasen (lokal, global, synchronisiert) erlauben es den Clients, entweder die eigene Zeitbasis aufrecht zu erhalten, oder sich innerhalb bzw. unter verschiedenen Steuergeräten synchronisieren zu lassen.

Kommunikation

Kommunikationsmanagement (ara::com) bietet die Grundlage für eine dienstbasierte Kommunikation zwischen Anwendungen und mit Plattformdiensten. Es definiert Schnittstellen zwischen Diensten, also flexible Kopplungsmechanismen für die Definition der zur Verfügung gestellten und der notwendigen Schnittstellen. Bei diesen Schnittstellen kann es sich um Methoden (etwa Remote Procedure Calls), um Felder (lesbares und schreibbares Shared Memory) oder um Ereignisse (schreibgeschützte Benachrichtigungen) handeln. Der Port ermöglicht die Gruppierung mehrerer Schnittstellen. Das Kommunikationsmanagement abstrahiert ausgehend vom zugrundeliegenden Protokoll oder Bus (z. B. vSOMEIP oder CAN).

RESTful Communication (ara::rest) bietet ein orthogonales Kommunikationsparadigma, das weniger verbindungs- oder serviceorientiert ist, sondern vielmehr von webbasierten, zustandslosen APIs inspiriert ist. Dieses Funktionscluster bietet die Grundbausteine für die Schaffung von Adaptive Anwendungen, die einen REST-konformen Dienst (Server-Seite) anbieten oder mit einem anderen Dienst interagieren (Client-Seite).

Sicherheit

Identitäts- und Zugriffsmanagement(ara::iam) bietet dem Berechtigungsmanagement ähnliche Mechanismen, mit denen man den Zugriff von Adaptive Anwendungen auf die Adaptive Platform Foundation und Services erlauben oder verwehren kann.

Kryptographie(ara::iam) bietet eine standardisierte Schnittstelle für den Zugriff auf Umsetzungen verschiedener kryptographischer Algorithmen. Diese enthalten eine zufällige Zahlengenerierung, Hashing-Algorithmen und verschiedene symmetrische und asymmetrische Chiffren.

Platform Health Management (ara::phm) erlaubt die Überwachung von Adaptive und Plattform-Anwendungen durch die Nutzung der APIs des Execution Management. Im Falle einer Störung können spezifische Handlungen konfiguriert werden. Mögliche Handlungen sind der Neustart der Anwendungen oder eine Zustandsänderung innerhalb einer Anwendung, Funktionsgruppe oder eines Steuergeräts.

Adaptive Platform-Dienste

Ab Release R18-03 gibt es vier spezielle Adaptive Platform-Dienste:

Diagnose(ara::diag) bietet Dienste gemäß Unified Diagnostic Services (UDS, ISO 14229) und Diagnostics over IP (DoIP, ISO 13400). Dies beinhaltet die Begriffe Diagnoseereignisse, einschließlich Fehler, Warnungen und Störungen sowie Diagnosekommunikation, bei der es um die Übertragung der erwähnten Ereignisse von der Quelle in eine langfristige Speicherung geht.

Signal-to-Services Mapping(ara::s2s) bietet eine Kompatibilitätsschicht zur Classic Platform und übersetzt Signale aus Classic in Dienste der Adaptive Platform. Damit wird die Interoperabilität zwischen Softwarekomponenten der Classic Platform und der Adaptive Platform erreicht.

Netzwerkmanagement (ara::nm) regelt das Zustandsmanagement aller verbundenen BUS und hält gegebenenfalls auch den BUS offen, wenn er für zeitkritische Kommunikation benötigt wird.

Zustandsmanagement (ara::sm) ist für die Bestimmung des aktuellen Zustands des Steuergeräts zuständig. Für mehr Granularität können sogenannte Funktionsgruppen getrennte Zustandsübergänge für Gruppen aus Funktionsclustern bzw. Adaptive Anwendungen zulassen. Wenn eine Zustandsänderung angefordert wird, löst dies über das Execution Management die notwendigen Änderungen aus.

Update- und Konfigurationsmanagement (ara::ucm) bietet eine Möglichkeit, neue Softwarekomponenten bzw. Upgrades vorhandener Softwarekomponenten im Steuergerät zu installieren. Sowohl Over-the-Air (OTA) also auch Workshop-basierte (mit diagnostischen Geräten) Use Cases werden unterstützt.

Demonstrator

Mit der Adaptive Platform hat sich AUTOSAR von der reinen Erstellung von Spezifikation weiterentwickelt. Zusätzlich zur bisherigen Arbeitsweise, bei der ein Korpus von Spezifikationsdokumenten veröffentlicht und gepflegt wird, hat die Entwicklungspartnerschaft sich nun entschieden, die Veröffentlichung von Spezifikationen mit einem Demonstrator zu begleiten, der aufzeigt, wie ein grundlegender Softwarestack auf der Adaptive Platform in der Praxis aussehen könnte. Allerdings ist der Adaptive Platform Demonstrator (APD) nicht für den Einsatz in der Produktion zugelassen. Die Spezifikationsdokumente sind zwar öffentlich, doch die Codebasis ist nur für registrierte AUTOSAR-Partner zugänglich, und zwar entweder über statische Releases (R17-03, R17-10, R18-03) oder über die neueste Entwicklungsversion.

Implementierungen

Genau wie bei der Classic Platform ist für die Verwendung von AUTOSAR in der Produktion ein Softwarestack notwendig. Die folgende Tabelle führt die Hersteller auf, die Adaptive Platform Softwarestacks anbieten oder dies angekündigt haben: 

Roadmap

Derzeit bereitet AUTOSAR Release R18-10 vor, das Ende Oktober 2018 veröffentlicht werden soll. Zu diesem Datum erfolgt auch der Übergang des Arbeitsmodus wie unten erklärt. Die Standardentwicklung schaltet dann von der gegenwärtigen Entwicklungsphase auf eine stabilere Phase um. Ab dann werden die Release-Zyklen der Classic Platform (CP) und der Adaptive Platform (AP) synchronisiert. Das wird die Einführung neuer Features, die beide Plattformen gleichzeitig betreffen, vereinfachen.

Release-Plan für Adaptive Platform Der Reifegrad wird bis zu R18-10 ansteigen und dann stabil bleiben, während weitere Features veröffentlicht werden. R18-10 soll mit der Classic Platform Release 4.4.0 synchronisiert werden. Aus  Adaptive Platform Release Overview, S. 4.

Mehr zu dem Thema

AUTOSAR