RTI Real-Time Innovations

Für Unternehmen im AUTOSAR-Umfeld (AUTomotive Open System ARchitecture), der weltweiten Entwicklungspartnerschaft von Fahrzeugherstellern, Zulieferern, Dienstleistern und Unternehmen aus der Automobilelektronik-, Halbleiter- und Softwareindustrie, sind zwei verschiedene Plattformen entstanden: AUTOSAR Classic und AUTOSAR Adaptive sowie der Foundation-Standard, der die Interoperabilität zwischen den AUTOSAR-Plattformen ermöglicht. Die Beteiligung des Software-Framework-Anbieters RTI an AUTOSAR Adaptive geht mittlerweile weit über die Veröffentlichung von Standards hinaus und umfasst sowohl die Zusammenarbeit mit führenden AUTOSAR Software-Anbietern als auch die interne Entwicklung einer voll funktionsfähigen Implementierung des Funktionsclusters für das Kommunikationsmanagement, genannt ara::com.

Die Spezifikation, Verwaltung und Weiterentwicklung der DDS-Netzwerkanbindung (Data Distribution Service) ermöglicht es, dass AUTOSAR Adaptive-Anwendungen mit bestehenden und zukünftigen DDS-Systemen zusammenzuarbeiten können.

Über die DDS-Netzwerkanbindung

Innerhalb der AUTOSAR Adaptive-Plattform bietet das Funktionscluster für das Kommunikationsmanagement eine serviceorientierte Kommunikationsmodellierung und Infrastruktur. APIs auf Applikationsebene sind protokollunabhängig und basieren daher auf einer Middleware, die zwischen den APIs und den tatsächlich zugrundeliegenden Kommunikationstechnologien vermittelt. (Abb. 1) Solche Mappings werden im AUTOSAR-Sprachgebrauch als Netzwerkanbindungen bezeichnet und nur drei von ihnen sind standardisiert:

• DDS
• SOME/IP
• Signalbasierte Kommunikation

Das Entwerfen und die Implementierung von Komponenten zur Netzwerkanbindung für AUTOSAR ist aufgrund diverser Design-Aspekte der AUTOSAR Adaptive Plattform generell eine komplexe Aufgabe:

1. Es gibt keine standardisierte API-Schicht zwischen anwendungsbezogenen APIs und Komponenten zur Netzwerkanbindung, sodass bei der Implementierung spezieller Netzwerkanbindungen jede Integration etwas anders angegangen werden muss.
2. AUTOSAR verfügt über ein eigenes Typsystem, das orthogonale UML- und C++ - Programmiersprachen wiedergibt. Diese müssen von den Netzwerkanbindungen mit dem Typsystem und den Funktionen jeder zugrundeliegenden Kommunikationstechnologie, z. B. DDS-eigenen erweiterbaren Typen, abgeglichen werden.
3. AUTOSAR schreibt auch sehr spezifische Protokolle für den Objektlebenszyklus und die Speicherverwaltung vor, die wiederum mit den zugrunde liegenden Frameworks in der gekapselten Netzwerkanbindung abgeglichen werden müssen.

DDS und das AUTOSAR-Typsystem

Auch wenn die AUTOSAR-Typen relativ weit verbreitet sind und naturgemäß auf DDS-XTypes (Booleans, Numerics, Strings, Strukturen, Arrays, Sequenzen usw.) abgebildet werden, erfordert die eigentliche Integration die Zusammenführung der plattformspezifischen Module (PSM) für beide Typsysteme in den Programmiersprachen C und C++.

Im Folgenden geht es um die einzige von AUTOSAR unterstützte Sprachanbindung C++ (bis hin zu C++14), sowie die C-Sprache PSM von DDS (letztere aus Gründen, die noch deutlich werden). Ein einfaches Beispiel zeigt, wie ein simpler Point3D-Typ nach der Übersetzung von DDS-IDL oder DDS-XML nach C aussehen könnte:

struct Point3D {

     float x;

    float y;

    float z;

};

Und dann nach der Übersetzung von AUTOSARs ARXML nach C++:

struct Point3D {

    float x;

    float y;

    float z;

};

Fällt das Ergebnis also identisch aus? Dann wäre die Typkompatibilität von AUTOSAR/DDS bereits eine klare Sache. Entwickelt man jedoch den Typenkatalog noch etwas weiter und gruppiert 3D Points zu Point-Clouds, die der Einfachheit halber als reine Arrays mit fester Länge angeordnet sind, würde das gemäß DDS C PSM so aussehen:

typedef Point3D PointCloud[1024];

Der gleiche Typ (ein Point Array mit 1024 Elementen) würde in AUTOSAR Adaptive allerdings wie folgt erstellt werden:

typedef ara::core::Array<Point3D, 1024> PointCloud;

Hier wurden also ähnliche, aber nicht identische Typen erstellt. Tatsächlich erhält ara::core::Array<> einige Semantiken der einfachen Array-Typen mit fester Länge (z. B. den indizierten Zugriff), fügt aber auch STL-ähnliche Semantiken wie begin() und end() Methoden hinzu und konvertiert nicht vorbehaltlos in einen Point3D Pointer. Diese Diskrepanz vergrößert sich bei anderen Typen, wie z. B. Strings und Vektoren, noch mehr.

In ara::com von RTI enthalten Implementierungstypen für strukturierte, benutzerdefinierte Typen über die AUTOSAR-Modellierung keine Wertefelder, sondern funktional kompatible Wrapper, die auf einen intern verwalteten „Backend-Speicher“ verweisen. Ein solcher Backend-Speicher könnte auf dem PSM der Adaptive Plattform (numerische C++-Standardtypen und ara::core-Containertypen) oder auf den automatisch generierten PSM-Typen von DDS aus DDS-IDL oder DDS-XML basieren.

Dieser Ansatz vereinfacht nicht nur die Integration mit Kommunikationsframeworks verschiedenster Art, sondern hält auch weitere Möglichkeiten für eine effiziente Speicherverwaltung und die Reduzierung und Eliminierung von Sample-Kopien beim Austausch von Daten offen.

Strategien für die Speicherverwaltung

Mit der beschriebenen Flexibilität der Datentyp-Struktur ergeben sich zwei Speicherverwaltungs-Strategien für Data Samples, die sich gegenseitig nicht ausschließen:

• Instanzen des Implementierungstyps können direkt von der Anwendung gestapelt oder dem Heap zugewiesen werden. Dies veranlasst die interne Typ-Implementierung, die In-Memory-PSM-Typen von AUTOSAR zu verwenden. Bei der Übergabe an das zugrundeliegende Framework müssen diese Datentypen entsprechend dem gewünschten Zieldatenformat konvertiert und/oder serialisiert werden, z. B. autogenerierte DDS-Typen aus DDS-IDL oder DDS-XML.
• Bei der Suche nach Zero-Copy-Datentransfers können Applikationen auch die Standardmethode Allocate() nutzen, die von Events und Field Notifiers bereitgestellt wird. In diesem Fall fragt die Netzwerkanbindung das zugrundeliegende Framework ein intern zugewiesenes Datenmuster „auszuleihen“. Es wird „zurückgegeben“, wenn es von der Applikation ausgefüllt und zurückgesendet wurde.

Letztere Strategie stellt einen extrem leistungsfähigen Mechanismus dar, der größenunabhängige und zeitlich konstante Datentransfers in verschiedenen Szenarien ermöglicht:

• Shared Memory-Transporte
• Speicherzugeordnete Netzwerkschnittstellen
• Prozessinterne Kommunikation

Compliance erreichen

Neben der performanten Zuordnung von Typsystemen und APIs bringt der Produktfokus von AUTOSAR eine weitere Herausforderung mit sich, nämlich die Einhaltung der funktionalen Sicherheit.

Die Bewertung einer DDS-Implementierung als „Sicherheitselement außerhalb des Kontextes“ (Safety Element out of Context, SEooC) in einem beliebigen ISO-26262 ASIL-Level stellt eine eigene Herausforderung dar, die RTI mit dem Connext Drive Produkt bereits adressiert. Angesichts der Vorgehensweise und des finanziellen Aufwands bei den Bewertungen der funktionalen Sicherheit kann es aus strategischer Sicht notwendig sein, die Funktionalität gegen die Größe der Codebasis und des Footprints einzutauschen.

Solche Einschränkungen fließen in RTIs ara::com-Designentscheidungen und in zukünftige AUTOSAR-Standards ein:

• C ist die einzige DDS-Sprache, die PSM bei der Implementierung von DDS-Netzwerkanbindungen erlaubt. Das ermöglicht eine einfache Anpassung für DDS-Implementierungen verschiedener Varianten (kleiner Footprint, mit Berücksichtigung von Safety-Aspekten).
• Die Unterstützung des Multi-Bindings ist erforderlich, da mehr als eine DDS-Netzwerkanbindung zur Verfügung stehen muss, um die erwähnte Vielfalt an DDS-Implementierungen zu unterstützen.
• Ein schlankerer Ansatz für die Service-Erkennung und die Anbindungsfunktionen in der Spezifikation der AUTOSAR Adaptive DDS-Netzwerkanbindung besteht darin, allgemeine DDS-Funktionen wie Topics und Instanzen zu nutzen, die in den meisten DDS-Middleware-Implementierungen leichter zu finden sind.

Autoren:

Emilio Guijarro, Automotive Applications Engineer bei Real-Time Innovations (RTI),

Peter Schmuckermaier, Senior Account Manager bei Real-Time Innovations (RTI)