Autosar-konforme Fahrzeugdiagnose über DoIP. (Bild: Vector Informatik GmbH)
DoIP ist vielseitig einsetzbar: Elektronisch gesteuerte Systeme moderner Fahrzeuge sind hochgradig miteinander vernetzt und führen eine Vielzahl komplexer Funktionen aus. Das Kommunikationsprotokoll DoIP (Diagnostics over Internet Protocol), welches von Autosar unterstützt wird, ermöglicht eine flexible und leistungsfähige Diagnose der Systeme über Ethernet, WLAN und Mobilfunk: Sowohl Offboard in der Werkstatt als auch Onboard und per Remote-Zugriff während der Fahrt. Dasselbe gilt für das Flashen von Steuergeräten in der Fertigung, der Werkstatt oder Over-the-Air. Damit das funktioniert, müssen die Kommunikationspfade zwischen dem Diagnosetester und dem jeweiligen Diagnoseobjekt (DUT) des Fahrzeugnetzwerks genau festlegt werden. Um die optimalen Pfade im komplexen Netzwerk einer modernen Fahrzeug-Elektrik/Elektronik (E/E) zu finden, ist der Einsatz geeigneter Werkzeuge unumgänglich.
Autosar-konforme Fahrzeugdiagnose über DoIP. Vector Informatik GmbH
Die Herausforderungen der Architektur moderner Fahrzeug-E/E sind enorm: Fortschrittliche Systeme zur Fahrerassistenz, Infotainment oder auch die Anbindung des Fahrzeugs an externe Netzwerke übertragen zum Teil viele Daten. Die sicherheitsrelevanten Systeme autonomer Fahrzeuge müssen redundant ausgelegt werden. Gleichzeitig erfolgt die Elektrifizierung des Antriebsstrangs und der meisten Nebenaggregate. All das hat erhebliche Auswirkungen auf die Architektur und die Diagnose der Fahrzeug-E/E.
Was sind typische Merkmale der E/E-Architektur neuer Baureihen? An ein zentrales Gateway mit integriertem Ethernet-Switch sind über Automotive-Ethernet die Domain-Controller der einzelnen E/E-Segmente angeschlossen – zum Beispiel für den Antriebsstrang, die Karosserie, das Fahrwerk, die Sicherheitssysteme oder für das Infotainment. An diesen hängen die domänenspezifischen Steuergeräte, Aktuatoren und Sensoren. Sie sind über Bustechnologien wie CAN, CAN FD, Flexray, LIN oder weitere Ethernet-Cluster miteinander verbunden. Das zentrale Gateway dient zusätzlich zur Kommunikation des Fahrzeugs mit dem Internet und mit OEM-spezifischen Diensten im Backend (Bild 1).
Fahrzeugdiagnose via DoIP-Standard
Bild 1: E/E-Architektur neuer Baureihen (schematisch). Vector Informatik GmbH
Der DoIP-Standard (ISO 13400) bietet Optionen, die für eine effiziente Diagnose und Programmierung moderner Fahrzeugelektronik essenziell sind. Außer der Datenübertragung hält DoIP Features zum Suchen und Erkennen von Fahrzeugen, zum Aufbauen und Prüfen von Verbindungen, zum Flashen von Steuergeräten, für das Fehlermanagement sowie Firewall-Funktionalitäten bereit. DoIP bettet Transportschicht-unabhängige Diagnosebotschaften, wie sie mit dem UDS-Protokoll (ISO 14229) beschrieben werden können, in das TCP/IP-Protokoll ein. Auf der anderen Seite ist die Konfiguration der Kommunikation via DoIP sehr aufwendig: Denn es sind viele Elemente wie Sockets, Socket-Verbindungen oder PDUs zu erstellen, miteinander zu verknüpfen und zu bedaten.
Viele Wege führen zum Ziel
Bild 2: Möglichkeiten des Verbindens externer Tester mit einem Device-under-Test (DUT) über ein zentrales Gateway. Vector Informatik GmbH
Im Beispiel von Bild 1 ist ein externer Diagnosetester über DoIP an das zentrale Gateway angeschlossen. Während der Fahrt überwachen interne Tester im Fahrzeug die Systeme. In beiden Fällen müssen die DUTs mit den jeweiligen Testern verbunden werden. Aufgrund unterschiedlicher Optionen, welche die Diagnosestandards DoIP und UDS bieten, der Topologie des physikalischen Netzwerks und dessen Unterteilung in logische Subnetze in Form von Ethernet-VLANs können sich vielerlei alternative Pfade ergeben. Über alle lassen sich die Verbindungen zwischen Testern und DUTs realisieren. Bei DoIP haben Tester immer die Rolle des Clients inne. Das Gateway im Beispiel spielt deshalb die Rolle des Servers. Der Tester muss sich gegenüber dem Gateway authentifizieren. Beim Anschluss eines externen DoIP-Testers über ein Ethernet-Gateway lassen sich verschiedene Fälle unterscheiden (Bild 2):
- DoIP-Verbindung zum Gateway mit Diagnose-Routing über UDS zu DUTs in anderen Subnetzen (im Bild links): Das Gateway extrahiert die UDS-Botschaft und leitet sie an den Adressaten in einem anderen Bussystem, zum Beispiel CAN, weiter.
- DoIP-Verbindung zum Gateway mit Diagnose-Routing über UDS in ein anderes logisches Subnetz (VLAN) desselben Ethernet-Clusters (Bildmitte): DUT und externer Tester sind hier im selben Ethernet-Cluster. Es besteht allerdings kein VLAN-Kanal, der die beiden Teilnehmer logisch miteinander verbindet. Das Gateway extrahiert die UDS-Botschaft und leitet sie in das entsprechende VLAN des Ethernet-Clusters weiter.
- DoIP-Verbindung zum Switch des Gateways, welches die Kommunikation direkt zum DUT über Ethernet weiterleitet (im Bild rechts): Das Gateway wechselt nach erfolgreicher Authentifizierung des DoIP-Testers die Switchkonfiguration, sodass Tester und DUT direkt miteinander kommunizieren können. Dies wird entweder durch ein VLAN-Retagging oder die Einbeziehung des externen Testers in das VLAN bewerkstelligt. In diesem Fall nimmt das DUT die Rolle des DoIP-Servers ein.
Eckdaten
Mit adäquaten E/E-Entwicklungsumgebungen lässt sich Diagnosekommunikation über CAN und Automotive-Ethernet mithilfe der Protokolle UDS und DoIP inklusive des Routings durch Diagnose-Gateways einfach und schnell modellieren. Im ersten Schritt werden dabei alle externen Offboard- und internen Onboard-Tester festgelegt sowie die DUTs (Devices under Test), also die zu diagnostizierenden Komponenten, bestimmt. Jedes DUT wird dann den relevanten internen und externen Testern zugewiesen. Auf Basis der getroffenen Zuordnungen ermittelt das Entwicklungswerkzeug dann die möglichen Kommunikationspfade zwischen Testern und DUTs. Alternative Pfade werden dem Anwender zur Auswahl zur Verfügung gestellt. Im letzten Schritt synthetisiert das Werkzeug alle zusätzlichen Artefakte, die für eine Autosar-konforme Diagnosekommunikation erforderlich sind. Der Aufwand für das Konfigurieren der Kommunikationsinfrastruktur für DoIP-basierte Diagnosen lässt sich so deutlich verringern.
Aufgrund unterschiedlicher Vor- und Nachteile finden all diese Szenarien Anwendungen in der Praxis. Im ersten Fall ist die Kommunikation zwischen Tester und DUT vollständig entkoppelt. Dieses Szenario stellt die einzige Möglichkeit dar, um ein Nicht-Ethernet-DUT mithilfe eines DoIP-Testers zu diagnostizieren. Im zweiten Fall wird die Kommunikation zwischen Tester und DUT ebenfalls durch das Gateway entkoppelt. In beiden Fällen erfordert die Entkopplung zusätzliche Routings, welche das Gateway belasten. Das zweite Szenario kommt dennoch beim Reprogrammieren von Steuergeräten zum Einsatz, wo das gesamte Datenvolumen aus Gründen der Sicherheit explizit über das Gateway geroutet wird. Der dritte Fall erlaubt den direkten Zugriff des Testers auf die Komponenten des Ethernet-Clusters. Der Ethernet-Switch, der in das Gateway integriert ist, führt in diesem Fall die Routings effizient und performant aus. Deshalb bietet dieses Szenario vor allem für die Übertragung großer Datenmengen Vorteile. Weil die Kommunikation hier nicht entkoppelt ist, lassen sich in diesem Fall unberechtigte Zugriffe von außen allerdings prinzipiell nicht ausschließen. Außer der obligatorischen Authentifizierung durch das Gateway sind deshalb zusätzliche Schutzmaßnahmen erforderlich.
DoIP-Fahrzeugdiagnose konsistent beschreiben
Für eine konsistente Modellierung, Bewertung und Optimierung komplexer E/E-Architekturen kommen Software-Umgebungen wie PREEvision von Vector zum Einsatz. Innerhalb dieser Umgebung lassen sich eine Vielzahl von Aufgabenstellungen auf der Basis eines gemeinsamen Modells konsistent bearbeiten: Angefangen bei der Anforderungsanalyse über die Architektur der logischen, funktionalen und Software-Ebene, dem Entwurf von Netzwerk-Topologien, Stromlaufplänen und Leitungssätzen bis hin zum geometrischen Layout von E/E-Systemen. Darüber hinaus stellt PREEvision Werkzeuge und Funktionen zur Verfügung, welche dem detaillierten Modellieren der Kommunikation innerhalb des Fahrzeugnetzwerks dienen. Paralleles, kollaboratives Arbeiten vieler Teams auf einem gemeinsamen Modell ist ebenfalls möglich. Leistungsfähige Import- und Exportschnittstellen für Autosar und andere relevante Austauschformate erlauben die einfache Integration der Entwicklungsumgebung in vorhandene Werkzeugketten.
Bild 3: Workflow zum Beschreiben der Fahrzeugdiagnose mit PREEvision. Vector Informatik GmbH
Zum Beschreiben der Fahrzeugdiagnose bietet PREEvision einen Workflow an (Bild 3). Im ersten Schritt werden darin die Netzwerktopologie der Fahrzeug-E/E und die Komponenten definiert. Die Offboard-Tester, die nicht Bestandteil des Fahrzeug-Netzwerks sind, werden im Modell als externe Komponenten berücksichtigt. Im zweiten Schritt werden die internen Tester und DUTs markiert, um sie anschließend miteinander zu verknüpfen. Ein Tester kann beliebig viele DUTs überwachen. Ebenso lässt sich ein DUT von mehreren Testern ansprechen, wie zum Beispiel von einem externen und einem internen Tester. Im dritten Schritt sucht PREEvision die Pfade im Netzwerk, über die Tester und DUTs miteinander kommunizieren können. Falls es nur eine Kommunikationsmöglichkeit gibt, legt PREEvision die entsprechenden Pfadinformationen automatisch an. Falls unterschiedliche Pfade identifiziert werden, kann der Benutzer einen der Pfade auswählen.
Die Tester-DUT-Zuordnungen werden im PREEvision-Modell abgelegt. Als Soll-Zustand der Diagnosekommunikation unterstützen sie den Anwender sowohl bei der Spezifikation der Fahrzeugdiagnose als auch bei der Prüfung des fertiggestellten Modells der Diagnosekommunikation. Im letzten Schritt des Workflows wird die zur Diagnose benötigte Kommunikationsinfrastruktur vollständig synthetisiert. Danach liegen alle Pfade und Routings fest, über die Tester und DUTs miteinander kommunizieren können. Je nach Verbindungsszenario und Übertragungsmedium werden dabei unterschiedliche Autosar-Artefakte der Kommunikationsinfrastruktur erzeugt, zum Beispiel PDUs, DoIP-Connections, Sockets und Socket-Verbindungen, CAN-Frames oder Segmentation-PDUs. Diagnoseinhalte werden dabei nicht erstellt.
Schneller zur passenden Kommunikations-Infrastruktur
Bild 4: Diagnosekommunikations-Explorer mit Netzwerkdiagramm in PREEvision. Vector Informatik GmbH
Zur Unterstützung des Workflows stellt PREEvision einen Diagnosekommunikations-Explorer zur Verfügung (Bild 4). Das Explorer-Fenster enthält im linken Teil Kategorien, die entlang der jeweiligen Schritte gegliedert sind. Die rechte Seite beinhaltet eine oder mehrere tabellarische Sichten auf die konkreten Daten. Der Diagnosekommunikations-Explorer geht von einer vorhandenen Netzwerk-Topologie aus und setzt bei der Festlegung von Testern und DUTs an. Anschließend wird der Benutzer anhand der einzelnen Kategorien durch den Workflow geführt. Tabellarische Editoren helfen dabei, den Zustand des Modells nach jedem Schritt zu prüfen und die Modellierung weiterzuführen. Elemente, die im Explorer ausgewählt sind, werden zusätzlich dazu in einem Diagramm hervorgehoben, welches die Netzwerktopologie repräsentiert.
Damit stellt PREEvision die Pfade und Routings in der E/E-Architektur, die zur Diagnose verwendet werden, leicht verständlich für den Anwender grafisch dar. Für Zuordnungen, die sich einfach per Drag-and-Drop durchführen lassen, wählt ein sogenannter Artefakt-Picker die relevanten Elemente aus und stellt sie zur Verfügung. Für komplexe Syntheseaufgaben finden sich im oberen Bereich des Explorers auswahlsensitive Buttons, die neben den üblichen Buttons von Standard-Funktionen wie zum Beispiel Sortierung und Filterung angeordnet sind. Die wesentlichen Artefakte, welche bei der Synthese der Kommunikationsinfrastruktur erzeugt werden, zeigt der Explorer ebenfalls an. Diese ermöglichen ein effizientes Navigieren und Bearbeiten der relevanten Kommunikationsartefakte und sorgen bei Änderungen und Anpassungen für konsistente Modellstrukturen. Dazu dienen Tabellen, die dem letzten Workflow-Schritt zugeordnet sind.
Dr. Daniel Gebauer
(av)
