Service Oriented Vehicle Diagnostic Serviceorientierte Fahrzeugdiagnose für IT-Zentren auf Rädern

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Continental Automotive GmbH

Continental Automotive Technologies GmbH

Fahrzeuge gleichen heute fahrenden Rechenzentren, Software wird auch hier immer wichtiger. Wie können Fehler in diesen komplexen Systemen erkannt und schnell behoben werden?

Waren Fahrzeuge in den 1980er Jahren noch recht gut in mechanische bzw. elektromechanische Komponenten zerlegbar (Vergaser, Kupplungsseil, mechanisch gesteuerte Einspritzung, Saugmotor), so sind heutige Fahrzeuggenerationen für einen zuverlässigen Betrieb auf eine komplexe Selbstdiagnose angewiesn und ohne den Anschluss eines Diagnose Testers an die OBD-Buchse kann oftmals der Grund für eine Warnlampe im Kombiinstrument nicht gefunden werden. Wie haben sich Fahrzeuge in den letzten Jahren verändert! Assistenten allenthalben. Mehr und mehr Steuergeräte ersetzen Bowdenzüge durch ihr elektronisches Pendant, ermöglichen bald (teil-) autonome Fahrzeugfunktionen. Die Rechenleistung der Steuergeräte steigt, im selben Maß die Komplexität der Softwarefunktionen, sowie der Variantenvielfalt der Fahrzeugkonfigurationen.

Neue Services entstehen: das Smartphone als Türöffner, das permanent vernetzte Fahrzeug, welches sich Software Updates einspielt, Flottenmanagement, Big-Data-Analyse und vieles mehr.

Das wirft zahlreiche Fragen auf:

• Kann die klassische Fahrzeug-Diagnose hier Schritt halten?

• Sind Diagnosen noch eindeutig und erfüllen diese das Ziel einer eindeutigen und einmaligen Fehlerkorrektur?

• Was, wenn ein Dienst temporär ausfällt, da die Internet-Verbindung abbricht?

• Ist das Telematik-Steuergerät abgestürzt?

• Ist das Funknetz überlastet?

• Sind die Server des Service-Anbieters nicht verfügbar?

• Ist die Spannung der Fahrzeugbatterie unter einen Schwellwert gefallen?

• Führt dieser Code zur eigentlichen Fehlerursache?

Fahrzeugdiagnose ist heute standardisiert. Vor zwanzig Jahren wäre hier oder da noch eine Analyse des Blinkcode notwendig gewesen, um den wenigen verbauten Steuergeräten Informationen über deren Zustand zu entlocken.

Heutige Fahrzeugdiagnose im Normen-Umfeld

Mit dem „Unified-Diagnostic-Services“ (UDS) Standard, der ISO 14229, gibt es seit Februar 2020 die dritte Auflage eines einheitlichen Diagnose-Standards. Die dort spezifizierten Dienste helfen, ein Steuergerät mit einem Tester zu steuern, zu kalibrieren, auszulesen, die Firmware zu aktualisieren. Heutige Steuergeräte nutzen das CAN- oder Ethernet-Netzwerk des Fahrzeugs, um in der Werkstatt mit einem an der OBD-Buchse angeschlossenen Fahrzeugtester zu kommunizieren. Die Kommunikation im Transport-Layer folgt im Falle von CAN der zweiten Auflage der ISO 15786-2:2016, welche u.a. CAN-FD unterstützt, sowie im Falle von Ethernet den Vorgaben der zweiten Auflage der ISO 13400-2:2019.

Fahrzeugtester in den Werkstätten haben große Datenbanken gespeichert, welche die übermittelten Datenpakete aus dem Fahrzeug für die Mitarbeiter der Werkstätten auf den Bildschirmen der Tabletts darstellen. Ein heute übliches Format zur Übersetzung der Fahrzeugdatenrohwerten in menschenlesbare Formate ist in der ISO 22901-1:2008 (2017) als „Open-Diagnostic-Data-Exchange“-Format (ODX) bekannt. Die Hersteller der Werkstatttester beziehen diese Steuergerätebeschreibungsdateien von den Fahrzeugherstellern, diese wiederum von den Komponentenherstellern. Eine lange Kette und eine Vielzahl von Beteiligten, um eine Diagnose eines Steuergeräts im Fahrzeug zu machen. Mit der Variantenvielfalt der Fahrzeugausstattungen, der Verwendung von Baukastensystemen, der Auslagerung von (Komfort-) Funktionen in „Apps“ kommt es dazu, dass die Komplexität zunimmt und mehr und mehr Varianten in die Beschreibungsdateien mit ausgenommen werden müssen.

Per Fingerdruck wird ein Wert aus dem Fahrzeugsteuergerät ausgelesen, eine Aktion ausgeführt oder auch mal ein Stellgliedtest stimuliert, was aber, wenn das Steuergerät nicht ein einziges Steuergerät ist, sondern eine große schwarze Box, die mehrere Funktionen in eben einer dieser Box vereint? Was, wenn der Test über eine Remote-Verbindung ausgeführt werden soll?

Diese großen schwarzen Boxen sind High Performance Computer (HPCs). Die Elektronik besteht aus Hochleistungsrechnern, KI-Unit, einigen Gigabyte an RAM und ROM, mehreren Schnittstellen, wie AE, Bluetooth, CAN, Wifi, fast, wie in einem Computer! Im Innern werkelt eine erste Software-Schicht, die als Hypervisor die Hardware von den Gast-Systemen trennt. Zu den heutigen Vertretern von Gast-Systemen zählen echtzeitbasierte Systeme, wie AUTOSAR classic, aber auch Vertreter, wie Linux oder QNX. Mittels UDS-Diagnose können die üblichen Echtzeitbetriebssysteme diagnostiziert werden. Schwieriger wird es da schon, wenn es sich beim Gast-System um eines handelt, welche komplexe, parallel ablaufende Prozesse zulässt, welches z.B. Sensor-Daten in einer KI-Maschine durch neuronale Netze jagt, um Entscheidungen zu treffen oder permanent mit der Außenwelt in Verbindung steht, das Fahrzeug quasi zum Teil in die Cloud auslagert. Hier kommt die klassische Fahrzeugdiagnose an ihre Grenzen.

Die im UDS-Standard beschriebenen Dienste eignen sich jedoch hervorragend, wenn es darum geht, die Peripherie des HPC zu analysieren: Spannungsversorgung, angeschlossene Sensoren, klassische, in Blöcken aufgebaute Speicherbausteine, CAN oder AE Transceiver.

Wie kann die Arbeit des Hypervisors überwacht werden und ist der Hypervisor ein Steuergerät mit Fehlerspeicher, aktualisierbarer Firmware? Einen kompletten HPC mit der aktuellen Diagnose testen wird nicht möglich sein, ein dunkler Fleck bleibt.

Das Thema Software-Update ist wichtig, um die Zuverlässigkeit und Sicherheit des Gesamtsystems zu gewährleisten. Die klassische Diagnose ist in der dritten Auflage des UDS-Standards um Dienste erweitert worden, welche den Zugriff auf sensible Daten durch aktuelle Methoden der Authentifizierung schützten, aber beim Transfer von Daten weiterhin in Start- und Endadressen denkt. Es gibt, wohl wahr, einen Dienst, der sich um den „File-Transfer“, den Transfer einzelner Dateien, kümmert. Dateien, ganze Partitionen mit einigen Gigabytes, Gast-Systeme als Ganzes austauschen? Hier sind heutige Methoden mit ihrem Latein am Ende.

In welchem Format werden die unzähligen Varianten der Steuergeräte bzw. Fahrzeugfunktionen abgebildet? Ein Fahrzeug, welches in einem zentralen Steuergerät mit Müdigkeitsassistent ausgestattet ist, hat mehr bzw. andere Fehlercodes hinterlegt als das Fahrzeug ohne diese Funktion. Wäre es nicht gut, das Fahrzeug könnte service-orientiert agieren und dynamisch statt vorbestimmt, zur Compile-Zeit festgelegt, die Prozesse monitoren und Fehler berichten?

Es gilt, die Herausforderungen anzugehen!

„Service Oriented Vehicle Diagnostic“ (SOVD)

Bei HPCs versuchen sich OEM und TIER-1 derzeit in proprietären Lösungsansätzen, um die Systeme, welche im Feld sind auf Stand zu halten und dem Kunden die bestmögliche Wartung in der Werkstatt zu bieten:

Im November 2018 waren Markus Zoll und Simon Stimmler als letzte Redner auf dem 9. Vector Congress der Firma Vector Informatik in Stuttgart auf der Agenda gelistet: „Des isch wie immer, grad no so die Kurve kriegt für die Diagnose“, so Simon Stimmler zu Beginn seines Vortrags zum Thema „Die Fahrzeugarchitektur der Zukunft und ihr Einfluss auf Diagnoseprozesse und -tools“ – die Herren haben nicht nur die Kurve bekommen, sie haben mich und viele andere im Saal mit ihrem ersten Entwurf einer möglichen Service-Orientierten-Diagnose angefixt. Ein spannendes Video mit einem Appell am Ende, an einer neuen Fahrzeugdiagnose zu arbeiten und zu standardisieren, gar die Fahrzeugdiagnose zu revolutionieren. Nicht, indem neue Protokolle entworfen werden, sondern durch die Nutzung von IT-Protokollen, die auf der Höhe der Zeit sind, die schnelle Software-Updates ermöglichen unter Beachtung der Kompatibilitäten der Hardware- und Softwarestände im Fahrzeug, im Backend; die eine Service-Orientierte Kommunikation erlauben und die Fahrzeugdiagnose via Onboard-App auch in das Fahrzeug selbst bringt. „Wir haben größtes Interesse hier in der [Diagnose-]Community zusammenzuarbeiten und die Dinge in den Standard rein zu bringen“ endet Simon Stimmler seinen Vortrag – treffender hätte dies im November 2018 nicht formuliert werden können.

Im Frühjahr 2019 lud die ASAM e.V. ihre Mitglieder für den Juni 2019 nach Höhenkirchen bei München ein, um über eine neue Arbeitsgruppe zum Thema „Diagnose für HPCs“ zu beraten. Von Dr. Ansgar Schleicher, DSA, Aachen, wurde ein erster Projektentwurf eingereicht und vor Ort den interessierten ASAM Mitgliedern vorgestellt. In der ersten von vielen weiteren Sitzungen wurde klar, dass sich hier etwas neues anbahnt, ein neuer Standard, der aus Automobilen mit HPCs beherrschbare Rechenzentren auf vier Rädern machen soll und uns allen sichere und zuverlässige Fortbewegung ermöglichen wird. Die öffentlich zugänglichen Foliensätze auf der Seite der ASAM e.V. zeigen die Sichten verschiedener OEM und Zulieferer der Automobilindustrie und bieten einen Einstieg in das Thema.

Aktuelle Inhalte der Standardisierung

Inzwischen sind rund 25 Use-Cases beschrieben, die Protagonisten zwischen Funktionsentwickler, Steuergerätehersteller, Endmontage, Kunde, Werkstatt und Schrottplatz bekannt, sowie für die wichtigsten Use-Cases der erste Schwung an Anforderungen an die API beschrieben. Die Technologie-Arbeitsgruppen sind im Gange und prüfen die Realisierbarkeit der zuvor beschriebenen Anforderungen an die API. Derzeit ist der Fokus auf die Diagnostizierbarkeit der HPCs gesetzt, der noch viel spannendere Teil, die Anbindung der klassischen Fahrzeugdiagnose an die neuen IT-Protokolle steht noch aus.

Das Projekt läuft offiziell seit September 2019 und soll im Oktober 2021 ein erstes Release bekommen. Die Teilnehmer aus dem Kreis der OEM und Zulieferer sind sich einig, dass dieser Standard in einer engen Kooperation mit den AUTOSAR Arbeitsgruppen zu erfolgen hat und final in einem ISO Standard münden soll. Die ersten rund 100 Seiten Papier sind bereits mit Anforderungen an die API gefüllt, es werden sicher noch einige folgen, sobald Ergebnisse zur Machbarkeit aus den Technologie-Gruppen vorliegen.

Zusammenfassung und Ausblick

Wir konnten schon einige wichtige Use-Cases mit Anforderungen beschreiben. Das Thema Daten-Modell und -Beschreibung ist bereits auf dem Tisch, aber wie geht eine saubere Übersetzung einer ‚Stateless‘ Kommunikation zu einer ‚Statefull‘ Kommunikation ohne weiteres Vorwissen? Heutige Internet-Technologien sind ‚Stateless‘, während die Tester-Steuergeräte-Kommunikation heutiger Steuergeräte einen großen Wert auf ‚Statefull‘ Kommunikation legt. Die Themen rund um die im Bild mit Nr. 1 bezeichnete Schicht sind weitestgehend klar, der sogenannte „Classic Diagnostic Adapter“ (Nr. 2) wird das größte Brett, das es in der verbleibenden Zeit noch zu bohren gilt.Wie werden moderne Rechenzentren überwacht und Rechner im Büro, die Terminals im Supermarkt auf Stand gehalten, gewartet und bei Notwendigkeit defekte Hardware ausgetauscht? Wir möchten uns hier von existierenden Standards und IT-Protokollen inspirieren lassen.

Wer Mitglied beim ASAM e.V. ist, möge sich gerne zwecks Zusammenarbeit an diesem neuen Standard melden, erst jüngst stieß mit einem Vertreter von Firma Ford/GM ein neuer Teilnehmer in unseren Experten-Kreis

* * Alexander Brede ... ist Systemarchitekt und Entwickler bei der Business Unit CVS der Continental AG sowie Mitglied des Standardisierungsgremiums im ASAM e.V..

(ID:47101254)