Der hier vorgestellte Embedded-Diagnostic-Ansatz basiert auf den in den ISO-Standards spezifizierten Infrastrukturkomponenten (z. B. ODX, OTX) und ebnet damit den Weg für eine datengetriebene Architektur. Die im Fahrzeug verbauten Diagnose-Infrastrukturkomponenten ermöglichen eine nahtlose Kommunikation mit dem ECU-Netzwerk und arbeiten in ähnlicher Weise wie das Service-Tool. So wird die Ausführung aller diagnostischen Anwendungsfälle aus entfernten Standorten ermöglicht.
Je moderner die Fahrzeuge werden, desto mehr sind sie auf die eingebettete Elektronik und Software angewiesen.
Da diese immer umfangreicher und komplexer werden, wächst auch die Fahrzeugkomplexität. Die heutigen Servicetechniker in den Autohäusern, die Zugang zu herkömmlichen Servicetester haben, sind durch die Tatsache eingeschränkt, dass sie sich beim Fahrzeug befinden müssen, um die Ursache des Problems diagnostizieren und beheben zu können. Dies erhöht die Servicezeiten, die Reparaturkosten und senkt wiederum die Kundenzufriedenheit.
Dieser Artikel stellt einen fortschrittlichen Ansatz zur Fahrzeugdiagnose vor und unterstreicht die Notwendigkeit, Servicetechniker mit Diagnosewerkzeugen der nächsten Generation auszustatten, um für die kommenden Kommunikationsanforderungen zwischen Mensch und Maschine gewappnet zu sein.
Die Fähigkeit zur Fahrzeugdiagnose ist ein überaus wichtiger Aspekt der Fahrzeugarchitektur. Die gebräuchlichste Methode in der Automobilindustrie ist der Zugriff auf die Gesamtheit der Diagnosedaten (DTC, Messwerte etc.) über den OBD-II-Port des Fahrzeugs. Es gibt auf dem Markt verfügbare Tools (von OEMs oder unabhängigen Aftermarket- Anbietern) welchen den Servicetechnikern helfen, den Status der verschiedenen Fahrzeugsubsysteme abzurufen, die erkannten Probleme zu beheben und Reparaturverfahren nach Vorgaben anzuwenden. Der auf dem Service Tool basierende Ansatz kann das Problem jedoch nur beheben, wenn der Techniker beim Fahrzeug anwesend ist.
Heute gibt es bereits zahlreiche Lösungen auf dem Markt, die von sich behaupten, eine kompetente Ferndiagnose mit OBD-II-Dongles vorzunehmen.
Tatsache ist jedoch, dass diese Lösungen nur die für die Emissionsnormen relevanten Diagnoseinformationen auslesen können und somit den Mehrwert für den Servicetechniker auf Abgaswerte begrenzt bleibt.
Ökosystemvisualisierung
Die gesamte in Bild 1 gezeigte Lösung besteht aus den folgenden fünf Hauptkomponenten: Telematics Control Unit (TCU), Diagnoselaufzeitsystem, OTXSequenzen, ODX-Daten und dem Diagnoseserver zur Unterstützung von Diagnosefunktionen.
Die TCU stellt die Umgebung und die notwendigen Ressourcen für die Ausführung des Diagnosesystems zur Verfügung, um verschiedene Anwendungsfälle wie Read Data Identifier (DID), Vehicle Scanning, Umprogrammierung etc. zu realisieren. Normalerweise arbeitet TCU mit LINUX als Betriebssystem mit unterschiedlichen Größen von RAM/Flash-Speicher und CPU-Leistung.
Das Diagnose Runtime stellt Infrastrukturkomponenten für die Diagnosekommunikation über Netzwerk (CAN, Ethernet etc.) zur Verfügung. Die Infrastrukturkomponenten umfassen Diagnostic APIs, OTX Runtime, D-Server- APIs) auf dem Remote-Server zu installieren.
Das Konzept einer solchen Architektur ist in Bild 3 dargestellt. Die Auswahl der Architektur gewährleistet eine Trade-Off-Analyse hinsichtlich der Geschäftsanforderungen, z. B. Unterstützung für den Online-/Offline-Modus, erforderliche Anwendungsfälle (Full-Service- Funktionalitäten vs. nur Umprogrammierung) etc.
Diagnoseverfahren
- OTX ist eine domänengesteuerte grafische Programmiersprache, die es erlaubt, automatisierte Diagnoseverfahren in grafischer Weise zu erstellen. OTX-Prozeduren werden im Standard-XML-Format angegeben.
- ODX ist ein XML-basierter Standard zur OEM-unabhängigen Definition von ECU-Diagnosedaten. Es enthält alle notwendigen Daten für die Diagnosekommunikation wie z. B. Kommunikationsparameter, ECU-Varianten-Beziehung, Diagnose- Services, Maßeinheiten, Genauigkeit, Datentypen etc. Die Komplexität und Größe der ODX-Daten hängt von den ECU-Varianten und der Anzahl der von den ECUs unterstützten Diagnoseservices ab.
Herausforderungen
Der in diesem Artikel angesprochene Ansatz ermöglicht die Diagnosefähigkeiten der nächsten Generation, aber er bringt auch einige Herausforderungen bzgl. einer tragfähigen Lösung mit sich.
Zu diesen Herausforderungen zählen beispielsweise:
Management des Fahrzeugzustands
- So muss der On-Board-Diagnose- Laufzeit-Stack sicherstellen, dass er den Netzwerkverkehr nicht überlastet oder die Fahrzeugfunktionen im Fehlerfall nicht beeinträchtigt.
- Sicherheit - Die Diagnoseinhalte, die an Bord und an/von TCU-Daten verfügbar sind, müssen hochgradig gesichert sein, um sie vor unbefugtem Zugriff zu schützen.
- Software-Aktualisierungen - Die Verfügbarkeit der erforderlichen Infrastruktur zur Unterstützung von drahtlosen (Over-the-Air)-Updates für den Fall, dass Softwarekomponenten innerhalb der TCU ausfallen.
- Mobilfunkbandbreite - Sicherstellung einer optimalen Nutzung der Mobilfunkbandbreite für die Datenübertragung zwischen Diagnoseserver und TCU
- Begrenzte Hardware-Ressourcen innerhalb der TCU - Software, die innerhalb der TCU läuft, muss hocheffizient sein, um innerhalb der begrenzten Ressourcenverfügbarkeit zuverlässig zu arbeiten.
Fazit
Die in diesem Artikel erwähnten Softwarekomponenten sind bereits vorhanden und werden bei verschiedenen Anwendungsfällen in den Bereichen Engineering, Fertigung und After-Sales-Service eingesetzt. Darüber hinaus sind immer mehr OEMs dabei, TCUs als Kernkomponenten ihrer Fahrzeugarchitekturen einzuführen. Schnell wechselnde Technologietrends, sich entwickelnde Kundenerwartungen und ein hart umkämpfter Markt werden OEMs und TCU-Zulieferer weiter dazu bewegen, den hier vorgestellten Ansatz für den Aufbau von Diagnosesystemen der Zukunft aufzugreifen. Bei KPIT wurde ein solcher Trend bereits bei technologisch fortgeschrittenen Kunden beobachtet. Die Diagnose- und Connectivity- Plattform (K-DCP) von KPIT ist schon in Produktion (in Embedded-Umgebung) und bedient Anwendungsfälle wie Over-the-Air-ECU-Flashing und Ferndiagnose.
Die eingebettete Fahrzeugdiagnose hat das Potenzial, den Nutzen entlang der gesamten automobilen Wertschöpfungskette zu steigern. Am Ende der Kette können die OEMs durch Kosteneinsparungen im Zusammenhang mit Fahrzeugrückrufen und der Reduzierung von Garantieansprüchen, die von No- Trouble-Found (NTF) gestützt werden, enorm profitieren, und das alles durch eine erweiterte und geführte Diagnose.
Die Service-Händler wiederum ziehen Nutzen aus einer Verbesserung der Fix- First-Visit-Kennzahlen, der Reduzierung von Servicezeit und -kosten durch Ferndiagnose, der Erzielung einer höheren Techniker-Effizienz und -Produktivität und nicht zuletzt aus dem höherem Komfort für den Kunden (Fahrzeughalter).
Dies alles auf Grundlage der neu gewonnenen Fähigkeiten der Service-Händler im Bereich der vorbeugenden/vorausschauenden Wartung.
Da sich eine Win-Win-Situation für alle Beteiligte ergibt, ist davon auszugehen, dass sich der Bereich der Embedded Diagnostics weiterentwickeln, wachsen und immer mehr Anhänger finden wird. W (oe)
»»www.kpit.com
Je moderner die Fahrzeuge werden, desto mehr sind sie auf die eingebettete Elektronik und Software angewiesen.
Da diese immer umfangreicher und komplexer werden, wächst auch die Fahrzeugkomplexität. Die heutigen Servicetechniker in den Autohäusern, die Zugang zu herkömmlichen Servicetester haben, sind durch die Tatsache eingeschränkt, dass sie sich beim Fahrzeug befinden müssen, um die Ursache des Problems diagnostizieren und beheben zu können. Dies erhöht die Servicezeiten, die Reparaturkosten und senkt wiederum die Kundenzufriedenheit.
Dieser Artikel stellt einen fortschrittlichen Ansatz zur Fahrzeugdiagnose vor und unterstreicht die Notwendigkeit, Servicetechniker mit Diagnosewerkzeugen der nächsten Generation auszustatten, um für die kommenden Kommunikationsanforderungen zwischen Mensch und Maschine gewappnet zu sein.
Die Fähigkeit zur Fahrzeugdiagnose ist ein überaus wichtiger Aspekt der Fahrzeugarchitektur. Die gebräuchlichste Methode in der Automobilindustrie ist der Zugriff auf die Gesamtheit der Diagnosedaten (DTC, Messwerte etc.) über den OBD-II-Port des Fahrzeugs. Es gibt auf dem Markt verfügbare Tools (von OEMs oder unabhängigen Aftermarket- Anbietern) welchen den Servicetechnikern helfen, den Status der verschiedenen Fahrzeugsubsysteme abzurufen, die erkannten Probleme zu beheben und Reparaturverfahren nach Vorgaben anzuwenden. Der auf dem Service Tool basierende Ansatz kann das Problem jedoch nur beheben, wenn der Techniker beim Fahrzeug anwesend ist.
Heute gibt es bereits zahlreiche Lösungen auf dem Markt, die von sich behaupten, eine kompetente Ferndiagnose mit OBD-II-Dongles vorzunehmen.
Tatsache ist jedoch, dass diese Lösungen nur die für die Emissionsnormen relevanten Diagnoseinformationen auslesen können und somit den Mehrwert für den Servicetechniker auf Abgaswerte begrenzt bleibt.
Ökosystemvisualisierung
Die gesamte in Bild 1 gezeigte Lösung besteht aus den folgenden fünf Hauptkomponenten: Telematics Control Unit (TCU), Diagnoselaufzeitsystem, OTXSequenzen, ODX-Daten und dem Diagnoseserver zur Unterstützung von Diagnosefunktionen.
Die TCU stellt die Umgebung und die notwendigen Ressourcen für die Ausführung des Diagnosesystems zur Verfügung, um verschiedene Anwendungsfälle wie Read Data Identifier (DID), Vehicle Scanning, Umprogrammierung etc. zu realisieren. Normalerweise arbeitet TCU mit LINUX als Betriebssystem mit unterschiedlichen Größen von RAM/Flash-Speicher und CPU-Leistung.
Das Diagnose Runtime stellt Infrastrukturkomponenten für die Diagnosekommunikation über Netzwerk (CAN, Ethernet etc.) zur Verfügung. Die Infrastrukturkomponenten umfassen Diagnostic APIs, OTX Runtime, D-Server- APIs) auf dem Remote-Server zu installieren.
Das Konzept einer solchen Architektur ist in Bild 3 dargestellt. Die Auswahl der Architektur gewährleistet eine Trade-Off-Analyse hinsichtlich der Geschäftsanforderungen, z. B. Unterstützung für den Online-/Offline-Modus, erforderliche Anwendungsfälle (Full-Service- Funktionalitäten vs. nur Umprogrammierung) etc.
Diagnoseverfahren
- OTX ist eine domänengesteuerte grafische Programmiersprache, die es erlaubt, automatisierte Diagnoseverfahren in grafischer Weise zu erstellen. OTX-Prozeduren werden im Standard-XML-Format angegeben.
- ODX ist ein XML-basierter Standard zur OEM-unabhängigen Definition von ECU-Diagnosedaten. Es enthält alle notwendigen Daten für die Diagnosekommunikation wie z. B. Kommunikationsparameter, ECU-Varianten-Beziehung, Diagnose- Services, Maßeinheiten, Genauigkeit, Datentypen etc. Die Komplexität und Größe der ODX-Daten hängt von den ECU-Varianten und der Anzahl der von den ECUs unterstützten Diagnoseservices ab.
Herausforderungen
Der in diesem Artikel angesprochene Ansatz ermöglicht die Diagnosefähigkeiten der nächsten Generation, aber er bringt auch einige Herausforderungen bzgl. einer tragfähigen Lösung mit sich.
Zu diesen Herausforderungen zählen beispielsweise:
Management des Fahrzeugzustands
- So muss der On-Board-Diagnose- Laufzeit-Stack sicherstellen, dass er den Netzwerkverkehr nicht überlastet oder die Fahrzeugfunktionen im Fehlerfall nicht beeinträchtigt.
- Sicherheit - Die Diagnoseinhalte, die an Bord und an/von TCU-Daten verfügbar sind, müssen hochgradig gesichert sein, um sie vor unbefugtem Zugriff zu schützen.
- Software-Aktualisierungen - Die Verfügbarkeit der erforderlichen Infrastruktur zur Unterstützung von drahtlosen (Over-the-Air)-Updates für den Fall, dass Softwarekomponenten innerhalb der TCU ausfallen.
- Mobilfunkbandbreite - Sicherstellung einer optimalen Nutzung der Mobilfunkbandbreite für die Datenübertragung zwischen Diagnoseserver und TCU
- Begrenzte Hardware-Ressourcen innerhalb der TCU - Software, die innerhalb der TCU läuft, muss hocheffizient sein, um innerhalb der begrenzten Ressourcenverfügbarkeit zuverlässig zu arbeiten.
Fazit
Die in diesem Artikel erwähnten Softwarekomponenten sind bereits vorhanden und werden bei verschiedenen Anwendungsfällen in den Bereichen Engineering, Fertigung und After-Sales-Service eingesetzt. Darüber hinaus sind immer mehr OEMs dabei, TCUs als Kernkomponenten ihrer Fahrzeugarchitekturen einzuführen. Schnell wechselnde Technologietrends, sich entwickelnde Kundenerwartungen und ein hart umkämpfter Markt werden OEMs und TCU-Zulieferer weiter dazu bewegen, den hier vorgestellten Ansatz für den Aufbau von Diagnosesystemen der Zukunft aufzugreifen. Bei KPIT wurde ein solcher Trend bereits bei technologisch fortgeschrittenen Kunden beobachtet. Die Diagnose- und Connectivity- Plattform (K-DCP) von KPIT ist schon in Produktion (in Embedded-Umgebung) und bedient Anwendungsfälle wie Over-the-Air-ECU-Flashing und Ferndiagnose.
Die eingebettete Fahrzeugdiagnose hat das Potenzial, den Nutzen entlang der gesamten automobilen Wertschöpfungskette zu steigern. Am Ende der Kette können die OEMs durch Kosteneinsparungen im Zusammenhang mit Fahrzeugrückrufen und der Reduzierung von Garantieansprüchen, die von No- Trouble-Found (NTF) gestützt werden, enorm profitieren, und das alles durch eine erweiterte und geführte Diagnose.
Die Service-Händler wiederum ziehen Nutzen aus einer Verbesserung der Fix- First-Visit-Kennzahlen, der Reduzierung von Servicezeit und -kosten durch Ferndiagnose, der Erzielung einer höheren Techniker-Effizienz und -Produktivität und nicht zuletzt aus dem höherem Komfort für den Kunden (Fahrzeughalter).
Dies alles auf Grundlage der neu gewonnenen Fähigkeiten der Service-Händler im Bereich der vorbeugenden/vorausschauenden Wartung.
Da sich eine Win-Win-Situation für alle Beteiligte ergibt, ist davon auszugehen, dass sich der Bereich der Embedded Diagnostics weiterentwickeln, wachsen und immer mehr Anhänger finden wird. W (oe)
»»www.kpit.com
