Über System- und Protokollgrenzen hinweg einheitlich Testen

Um der technischen Komplexität Herr zu werden, etabliert die Automobilindustrie derzeit die Autosar-Adaptive-Architektur als Ergänzung zum schon etliche Jahre bestehenden Autosar Classic. Dabei verschmilzt die klassische Automobilelektronik immer mehr mit der aktuellen Informationstechnik, was sich zunächst nicht sonderlich spektakulär anhören mag. Hier prallen zwei Welten aufeinander, die auf teilweise diametral entgegengesetzten Modellentwürfen basieren. Schon die Bestrebungen, solche komplexen gemischten Systeme umfassend zu testen und dabei alle Aspekte zu berücksichtigen, erfordern von den Ingenieuren gleichsam einen technischen Spagat.

Bei Autosar Classic ist die gesamte Kommunikation statisch vordefiniert. Der Hersteller erzeugt ein exakt zur Fahrzeughardware passendes Softwareimage mit fester Kommunikationsmatrix, das über die gesamte Laufzeit

Bild 1: Moderne E/E-Architekturen in Fahrzeugen erfordern stetige Update-Fähigkeit und Anbindung an Backend-Infrastrukturen – vergleichbar zu Smartphones. Vector Infomatik

erhalten bleibt. Allenfalls sind dafür gelegentliche Updates in der Werkstatt vorgesehen. Auf der physikalischen Ebene dienen Bussysteme, wie CAN, LIN oder FlexRay, zum Informationsaustausch und der Fokus liegt auf maximaler Echtzeitfähigkeit. Ein typisches Szenario ist zum Beispiel folgendermaßen organisiert: An den vier Rädern eines Fahrzeugs befindet sich jeweils ein Drehgeber zum Erfassen der Rotationsgeschwindigkeit. Die Leitungen vom Steuergerät zu den Sensoren sind über CAN sinngemäß „fest verdrahtet“ und deren Position ist allen Kommunikationsteilnehmern genau bekannt. Außerdem aktualisiert das System die Geschwindigkeitssignale innerhalb exakt definierter Zeitintervalle. Fällt etwa ein Drehgeber aus, führt das zu einer kritischen Fehlermeldung innerhalb des Kommunikationssystems.

SOA für innovative Fahrzeugfunktionen

Autosar Adaptive unterscheidet sich grundlegend davon. Die Architektur bildet das Fundament für künftige Fahrzeuggenerationen, bei denen sich die Autos immer mehr zu fahrenden Softwareplattformen wandeln. Vergleichbar mit einem Smartphone ist die Fahrzeugfunktionalität nicht mehr statisch, sondern lässt sich jederzeit durch Apps ergänzen (Bild 1). Das System lädt automatisch Updates herunter und Nutzer können jederzeit zusätzliche Fahrzeugfunktionen hinzukaufen oder freischalten. Ein wesentliches Merkmal von Autosar Adaptive ist die Serviceorientierung (SOA – Service-Oriented Architecture). SOA-Systeme sind gekennzeichnet durch eine beliebige veränderbare Anzahl von verteilten Dienstanbietern, den Providern sowie den Consumern, die die Dienste nutzen. Da sich mit dem Begriff „Dienst“ nahezu jede Funktionalität verknüpfen lässt, reicht das Dienstespektrum vom einfachen Blinker, der ein Lichtsignal liefert, über Kamerasysteme, die im Fahrzeug Videodaten zur Verfügung stellen, bis hin zu umfassenden externen Server-Diensten im Backend. Als physikalisches Übertragungsmedium dient bei Autosar Adaptive vornehmlich Ethernet. Softwareseitig basieren SOA-Entwicklungen auf objektorientierten Programmiermethoden, statt der klassischen C-Programmierung bei Autosar-Classic-Steuergeräten.

Mit dieser Architektur sind dynamische und flexibel erweiterbare Infrastrukturen abbildbar, deren Geltungsbereiche weit über die Fahrzeuggrenzen hinausreichen. Der Schwerpunkt bei Autosar Adaptive liegt somit auf einem Datenaustausch mit wechselnden Teilnehmern beziehungsweise Kommunikationsendpunkten sowohl innerhalb als auch außerhalb des Fahrzeugs. Für die externe Kommunikation mit Echtzeitanforderungen ist das künftige 5G-Netz prädestiniert. Um einen entfernten Dienst zu finden, bedient sich der Consumer gegebenenfalls noch eines Brokers, dessen Funktionsweise vergleichbar ist mit der von Domain-Name-Servern (DNS) zur Namensauflösung bei Internetzugriffen. Ebenso wie IP-Adressen können sich auch Server ändern, auf denen bestimmte Dienste laufen. Bei Nichtverfügbarkeit eines Servers muss das System in der Lage sein, einen alternativen Dienst zu finden. Innerhalb des Fahrzeugs kommt als Protokoll SOME/IP (Scalable Service-Oriented Middleware over IP) zum Einsatz. Statt eines zentralen Brokers gibt es hier einen speziellen Service-Discovery-Mechanismus, bei dem die Provider zyklisch mit „Hier bin ich!“-Broadcast-Botschaften auf ihre Existenz und Verfügbarkeit aufmerksam machen.

Einheitliches Testverfahren für fahrende Software-Plattformen gesucht

Diese dynamischen und fehlertoleranten Mechanismen sind nicht nur für das autonome Fahren eine unabdingbare Voraussetzung. Auch bei der Elektromobilität ist eine tiefgreifende Vernetzung mit dem Backend notwendig; nur so ist das gesamte Rationalisierungspotenzial der Technologie auszuschöpfen. Das Finden freier Ladesäulen und das Aushandeln von Ladetarifen gehört dabei eher zu den einfacheren Übungen. Die echten Herausforderungen hingegen liegen bei der Kommunikation mit dem intelligenten Stromnetz (Smart Grid), das die Verantwortung für eine optimale Verteilung der Ressourcen trägt und in der Lage ist, auf die natürlichen Schwankungen der regenerativen Energieerzeugung zu reagieren. Die künftige Elektromobilität ist in der Lage, bei Energieknappheit Ladeleistungen zu drosseln oder Ladevorgänge temporär auch vollständig zu unterbrechen und automatisch wieder zu starten. Dieses intelligente Laden (Smart Charging) erfordert erwartungsgemäß regen Datenaustausch mit Servern im Internet.

Am anschaulichsten verdeutlicht immer noch das autonome Fahren die Komplexität der künftigen Fahrzeuggenerationen (Bild 2): Steuergeräte fordern Daten von zahlreichen (Stereo-)Kameras, Radarsensoren und Laserscannern an, sie müssen Objekte in Videobildern identifizieren, fortlaufend hochauflösende Karten zum aktuellen Standort aus dem Internet nachladen, gleichzeitig mit anderen Verkehrsteilnehmern oder Objekten kommunizieren (Car2X), die Informationen aus den verschiedenen Quellen im Fusionssteuergerät schließlich zusammenführen, auswerten und blitzschnell die korrekte Entscheidung für das Navigieren fällen. In die Prozessabläufe sind viele Teilnehmer, viele Sensoren und viele Dienste-Server involviert. Die große Aufgabe besteht darin, diese Applikationen in den Griff zu bekommen. Das Testen verschiebt sich dadurch immer mehr in Richtung applikationszentrierter Tests.

Lösungsansatz: Kommunikationsobjekte

Der Anspruch an die Testgüte im Automobilbereich ist traditionell sehr hoch, es handelt sich immerhin um Maschinen mit Leistungen von rund 100 PS/74 kW oder mehr, die es sicher zu beherrschen gilt; autonomes Fahren

Bild 2: Automotive Anwendungen: aktuelle Trends und Anforderungen. Vector Informatik

macht die Sache nicht einfacher. Für Automobilhersteller und Zulieferer stellt sich somit die elementare Frage, wie sich Autosar-Classic- und Autosar-Adaptive-Anwendungen in Zukunft möglichst rationell und einheitlich testen lassen, idealerweise mit ein und demselben Tool. Solch eine Lösung muss flexibel und für künftige Protokollerweiterungen offen sein.

Eine erfolgversprechende Antwort ist in diesem Zusammenhang die Verwendung universeller Kommunikationsobjekte, die von einer zusätzlichen Abstraktionsebene zur Verfügung gestellt wird. Sie entkoppelt den eigentlichen Dienst von der Übertragungsschicht und erlaubt ein einheitliches Testen gegen die Kommunikationsobjekte, kurz COs genannt (Communication Objects). Da die Abstraktion auf relativ hoher Ebene, nahe an der Applikationsschicht erfolgt, müssen die Details der Datenübertragung dort nicht mehr bekannt sein. Bei jedem CO handelt es sich lediglich um „ein Stück Kommunikation“, dem der Tester einfach einen Wert zuweist, statt zum Beispiel eine CAN-Botschaft zu senden. Die Zugriffs- und Testfunktionen sind stets gleich bei allen COs, egal ob nur der Blinker adressiert wird oder es sich um eine Anfrage an einen Server im Backend zur Routenplanung handelt. Testingenieure können sich so auf den Kern ihrer Arbeit konzentrieren und sind von der Notwendigkeit entbunden, sich mit den unzähligen Details von CAN, FlexRay, Automotive Ethernet oder den Eigenheiten serviceorientierter Internetprotokolle zu beschäftigen. Das Testen von verteilten Applikationen führt auf diese Weise signifikant schneller zum Ziel und ist insbesondere auch nicht auf das Fahrzeug begrenzt.

Komplexität verbirgt sich im Binding

Natürlich lässt sich die Komplexität nicht einfach wegzaubern, deshalb benötigt das Konzept noch zusätzlich sogenannte Bindings. Das jeweilige Binding beschreibt die konkrete Zuordnung eines COs zu einem Bussystem, beispielsweise Automotive Ethernet oder einem Protokoll. Unter anderem sind hier die Endpunkte der Kommunikation, also Provider und Consumer, definiert. Ebenso sind im Binding IP-Adressen, Ports, Nachrichten-IDs, Datenbereiche und zahlreiche weitere Informationen hinterlegt. Sowohl binäre Schaltbefehle lassen sich über ein Binding abbilden als auch der Transfer umfangreicher Datenmengen. Letztere sind in der Regel über dynamische Datenstrukturen organisiert.

Radarsensoren beispielsweise senden keine Digitalaufnahme mit zuvor bekannter Auflösung beziehungsweise Anzahl von Pixeln, sondern eine variable Punktwolke mit Entfernungen, Relativgeschwindigkeiten und Wahrscheinlichkeiten. Ähnliches gilt, wenn das Fahrzeug die Beschreibung einer Kreuzung bei der Car2x-Kommunikation anfordert oder für Kartendienste zum Navigieren. Die hochauflösenden zentimetergenauen Kartendaten sind in einem komplexen Format verpackt.

Weil das Definieren der Bindings mitunter sehr anspruchsvoll sein kann, übernehmen diese Aufgabe vorzugsweise die jeweiligen Spezialisten für CAN, FlexRay, SOME/IP und so weiter. Testingenieure hingegen müssen sich nicht mehr damit auseinandersetzen. Vielfach sind in bereits vorhandenen Autosar Classic Descriptions, Autosar Adaptive Descriptions oder allgemein Kommunikationsmatrizen alle notwendigen Informationen enthalten. In solchen Situationen ist die automatische Konfiguration der korrespondierenden Bindings nur eine Frage des passenden Importfilters. Importierte Daten lassen sich selbstverständlich über einen Editor manuell nachbearbeiten.

Abstraktes Binding für virtuelle Prototypen

Als interessante Binding-Option für COs verdient zudem das „abstrakte Binding“ eine entsprechende Erwähnung. Im Entwicklungsprozess ist die Funktionalität eines Dienstes vielleicht bereits hinreichend klar beschrieben, und es existieren erste Implementierungen im Prototypenstadium, beispielsweise auf einer virtuellen Linux-Maschine. Selbst wenn die Details der Kommunikation noch nicht festgeschrieben sind und kein Übertragungsmedium bestimmt ist, lassen sich solche virtuellen Prototypen schon über abstraktes Binding in Tests integrieren. Beim applikationszentrierten Testen ist es unerheblich, ob zum Beispiel eine Bildinformation über Ethernet Frames in das Steuergerät hineinkommt, ob die Anwendung auf reeller Steuergerätehardware läuft oder in einer virtuellen Maschine. Vielmehr liegt der Fokus auf dem Verifizieren des Algorithmus, der etwa andere Fahrzeuge identifizieren soll. So lassen sich Applikationen über das virtuelle Bedaten sehr frühzeitig testen.

Neues Kommunikationskonzept in CANoe

Das beschriebene Konzept zum einheitlichen Testen von Autosar-Classic- und dienstorientierten Autosar-Adaptive-Anwendungen über universelle Kommunikationsobjekte ist mit dem Kommunikationsmodell des Test- und

Bild 3: Verschiedene Beschreibungsformarte können in das CANoe Kommunikationsmodell importiert werden. Änderungen im Modell (Ergänzungen, Fehlerkorrekturen) sind über einen eigenen Editor möglich. Vector Informatik

Simulationswerkzeugs CANoe verfügbar (Bild 3). Alle genannten Eigenschaften und Funktionen, vom Importieren der Datenbankbeschreibungen bis zum abstrakten Binding, sind enthalten – zusätzlich zum bisherigen Funktionsumfang. Befürchtungen dieser könnte eingeschränkt sein sind unbegründet, denn Classic- und Adaptive- Anwendungen werden viele Jahre lang parallel existieren. Vector hat die Oberfläche und grundsätzliche Bedienung von CANoe unverändert gelassen. Vielmehr haben Anwender die freie Wahl, nach welchem Modell sie arbeiten wollen. Der zentrale Einstiegspunkt in das neue Kommunikationskonzept verbirgt sich in der Registerkarte „Umgebung“ des Menübands und dem darunterliegenden Menübefehl „Kommunikationsaufbau“. Es wird in der Praxis vermutlich erst einmal nur bei neuen Projekten Anwendung finden. So erlaubt CANoe eine schrittweise Migration vom bisherigen Workflow hin zum Testen gegen universelle Kommunikationsobjekte, die in der Lage sind, alle aktuellen und künftigen Kommunikationsformen einheitlich abzubilden. Wahlweise lassen sich so mit demselben Werkzeug ab sofort Classic- und Adaptive-Anwendungen zeitsynchronisiert und gemeinsam testen. Ein Demo-Testprojekt ist in der Software enthalten.

Fazit und Ausblick

Das Testen der künftigen Automobilelektronik erfordert eine andere Herangehensweise als bisher. Zusätzlich zur klassischen signalbasierten Kommunikation hält die moderne Informationstechnik mit zahlreichen zusätzlichen Protokollen und Technologien Einzug ins Automobil. Damit rücken eine dienstorientierte Architektur und das applikationszentrierte Testen in den Fokus. Auch ein guter Testingenieur dürfte in Zukunft kaum noch in der Lage sein, als Spezialist für jedes der vielen Protokolle, Hardwareschichten und Dienste zu fungieren. Die Lösung bringt ein neues Kommunikationskonzept, das mit einer zusätzlichen Abstraktionsebene, mit Bindings und mit universellen Kommunikationsobjekten arbeitet. Mit diesen gestalten sich Testdefinitionen einheitlich für alle denkbaren Kommunikationsarten, auch solche die in Zukunft möglicherweise hinzukommen.

Die Technik im Automobilsektor verändert sich aktuell sehr dynamisch und welche Kommunikations- und Softwarestandards in wenigen Jahren zum Einsatz kommen, lässt sich schwer abschätzen. Sei es, dass sich die Technik in Richtung REST (Representational State Transfer) entwickelt oder sich ganz andere Systeme durchsetzen. Mit dem neuen CANoe Kommunikationskonzept ist Vector in der Lage auf Veränderungen zu reagieren. Zur Unterstützung einer neuen Technologie ist lediglich ein entsprechendes Binding zu implementieren, das dem Kundenkreis zeitnah in einem Service Pack zur Verfügung gestellt wird.

(wi)