Diagnose in Adaptive AUTOSAR
Für einen Diagnosetester ändert sich auf den ersten Blick mit Adaptive AUTOSAR nicht viel. Eine D-PDU API wird ein zusätzliches Protokollmodul für Diagnostics over IP (DoIP) besitzen, um mit einer Adaptive AUTOSAR kommunizieren zu können. Weiterhin wird auch noch die UDS- und ISO-Spezifikation um einige neue Fähigkeiten erweitert. Ende 2019 wird die Standardisierung in der ISO abgeschlossen sein. Da bei der Standardisierung Wert auf Evolution und weitgehende Kompatibilität gelegt wurde, gibt es keine tiefgreifenden Änderungen, die hier ein neues Systemdesign in der Diagnose erfordern würden. Es ist zu erwarten, dass diese Änderungen im Laufe des Jahres 2020 in die bereits existierenden off-the-shelf-Tools für Diagnose einfließen werden.
Softwarecluster
Zunächst wird das jeweilige zu diagnostizierende Fahrzeug bei DoiP anhand der Vehicle-Identifikationsnummer (VIN) ausgewählt und dann die Kommunikation mit den einzelnen Steuergeräten über deren Diagnose-Adressen aufgebaut. Eine Herausforderung dabei ist, dass ein adaptives Steuergerät mehrere Diagnose-Adressen gleichzeitig besitzen kann, jeweils eine Diagnose-Adresse pro Softwarecluster (SWC) mit den zugehörigen DiagnosticManager. Ein adaptives Steuergerät besitzt typischerweise dann 5 bis 10 Softwarecluster und damit gleich viele Diagnose-Adressen.
In dem Beispiel in Bild 1 sind zwei (Diagnose-)Anwendungen bei ECAS gegeben. Die Erste fürs Absenken eines Fahrzeuges, um den Einstieg von Fahrgästen zu erleichtern (sog. Kneeling) und die Zweite eine Tiltfunktion zur Überschlagsverhinderung eines Busses. Diese beiden Applikationen müssen nicht gleichzeitig im Software Cluster „ECAS“ aktiv sein. Sie können nach Bedarf dynamisch zur Betriebszeit gestartet und beendet werden.
Applikationen können auch je nach Fahrzeugvariante ganz ein- oder ausgeschaltet sein. Als Beispiel ist im Beispiel ein „Lane Change Assistent“ als kostenpflichtiges Ausstattungsmerkmal dauerhaft deaktiviert oder wird erst im Laufe des Fahrzeuglebens zusätzlich aktiviert. Dies hat zur Folge, dass die Applikationen mit Diagnosefunktionen nicht mehr gleichzeitig vorhanden oder gar dauerhaft im Fahrzeug deaktiviert sind. Ein Tester muss daher mithilfe der VIN die entsprechenden Fahrzeugdaten kennen und verwalten können. Er kann dabei nicht mehr davon ausgehen, dass alle DTC-Informationen der Diagnostic -Manager eines Steuergeräts aktuell oder vorhanden sind.
Für die beiden Softwarecluster, die jeweils ihre eigene Diagnose-Adresse haben, sind entsprechend auch zwei ODX-Datentöpfe notwendig. Im Prinzip ist ein Steuergerät mit Classic AUTOSAR ein Analogon für einen Softwarecluster in Adaptive AUTOSAR. Die Verteilung der Diagnose-Anfragen auf die jeweiligen DiagnosticManager eines Softwareclusters wird durch die AUTOSAR-Umgebung automatisch sicher – gestellt. Insgesamt entsprechen diese Änderungen jedoch mehr einer Evolu tion als einer Revolution.
Interessanter wird es, wenn man die neuen Möglichkeiten eines OnBoard-Diagnosetesters in Verbindung mit einer erweiterten Diagnosefunktionalität im Fahrzeug betrachtet (Bild 2).
OnBoard-Diagnosetester
Heute ist in Classic AUTOSAR eine elektrische Komponentendiagnose üblich. Dabei wird die angeschlossene Hardware zyklisch auf Fehler überprüft und gefundene Fehler im Diagnostics-Management gespeichert. Die bei der Erstellung der Auswirkungsanalyse, also der Failure Mode and Effects Analysis (FMEA), von Fehler einer Komponente festgelegte Fehlerreaktion wird durch das Fehler-Event ausgelöst.
Beispielsweise bei einem „Stuck at High“-Fehler das Öffnen eines Low-Side-Treibers, um einen dauerhaft fehlerhaft bestromten Aktor auf einen zweiten unabhängigen Weg abschalten zu können. Damit ist zunächst das elektrische Problem auf der Komponentenebene abschließend behandelt, mit der Konsequenz, dass eine Schaltfunktion und damit mindestens ein Aktor ausfällt.
Der Ausfall eines Aktors hat natürlich Auswirkungen auf das System, in dem er eingebunden ist. Damit diese Auswirkungen korrekt berücksichtigt werden, gibt es in AUTOSAR das Konzept von Events, mit denen andere Applikationen über aufgetretene Änderungen informiert werden können. Der Ausfall dieser Schaltfunktion hat beispielsweise zur Folge, dass die Funktion „Liftachse senken“ eines Nutzfahrzeugs auf der Systemebene nicht mehr zur Verfügung steht. Auf dieser Ebene erhält die betroffene Funktion dann ebenfalls einen entsprechenden Fehlercode. Die Auswirkungen auf das System, am Beispiel ECAS, wird in der System-FMEA betrachtet und weitere Folgeaktionen per Event ausgelöst, was im ECAS-Beispiel das Sperren der Funktion „Funktionsliftachse heben“ zur Folge hat, um hier eine Reduzierung der zulässigen Zuladung durch das technisch noch mögliche Anheben der Liftachse zu vermeiden.
Der Ausfall der Systemfunktion „Liftachse“ wirkt sich unterschiedlich aufs Fahrzeug aus. Wenn die aktuelle Liftachse abgesenkt bleibt, beeinträchtigt das nur die Systemeigenschaften und führt zu einer schlechteren Lenkbarkeit, einem erhöhtem Kraftstoffverbrauch und Verschleiß der Reifen.
Im Falle des Ausfalls einer gehobenen Liftachse, ist die noch zur Verfügung stehende Nutzlast reduziert, was erhebliche Auswirkungen auf die Verfügbarkeit des Fahrzeugs und evtl. die Notwendigkeit eines OnRoad-Services des Fahrzeugs zur Ladungsreduzierung bedeutet.
Ein OnBoard-Diagnosetester sammelt hier die eintreffenden Fehlerereignisse über DoIP, trifft daraufhin Entscheidungen, wie weiter mit der Situation zu verfahren ist und steht natürlich bei Onoder Off-Road-Services für weitere Analysen zur Verfügung. Der OnBoard- Tester kann hierbei nicht nur auf originäre UDS-Diagnose-Informationen zugreifen, sondern für tiefere Analysen auch selbst als Adaptive-AUTOSAR-Applikation über die ARA::COM-Schnittstelle aktiv auf weiteren Schnittstellen von anderen Applikation zugreifen.
Die zu analysierenden Datenmengen und gegenseitige Abhängigkeiten der Steuergeräte mit ihren Applikationen in der Steuergeräte-Entwicklung steigen und machen damit die Diagnose-Entwicklung komplexer. Die klassische Trennung zwischen Steuergeräte- und (Aftersales)-Diagnose-Entwicklung in der Zukunft muss daher aufgehoben werden, um hier noch effektivere und effizientere Entwicklungen zu ermöglichen.
Diagnose-Tools Mit den Anforderungen an ein Fahrzeug, inklusive der vorgesehenen Variabilität, startet der E/E-Entwicklungsprozess (Bild 3). Stand der Technik ist hier ein Import der Spezifikationsdaten eines Anforderungs-Managementsystems in einem Fahrzeugdateneditor. In diesem Fahrzeugdateneditor wird die Architektur der Steuergeräte weiter spezifiziert und die Kommunikationsanforderungen (klassisch: eine „CAN-Matrix“) definiert. Moderne Tools ermöglichen hier sowohl die AUTOSAR-Daten (DEXT) wie auch die Diagnosedaten (ODX) gemeinsam und gleichzeitig zu spezifizieren und diese in einer gemeinsamen Datenbank zu verwalten.
Es existiert eine weitgehende Überschneidung des Inhalts dieser beiden Datenformate, zum Beispiel beim DTC und DID. Beide Formate enthalten jedoch alle notwendigen Informationen für die Steuergeräte-Entwicklung. Bei DTCs fehlen in ODX ungefähr 40 Attribute, die zur Beschreibung einen DTC im Steuergerät, wie zum Beispiel die Priorität des Fehlers und die zu verwendende Debouncing-Strategy.
Damit ein Entwickler effektiv und effizient arbeiten kann, wenn er einen DTC hinzufügt oder ändert, ist es nahezu unerlässlich, dass er hierfür nur an einer Stelle die Definitionen erzeugen und verwalten muss. Besitzt ein Tool erstmal alle notwendigen Informationen, können hieraus DEXT- und ODX-Daten generiert werden und bei späteren Änderungen werde diese auch wieder reimportiert und in das jeweils andere Format zurück exportiert. Damit ist eine Kohärenz der ODX und DEXT-Daten sichergestellt, sodass ein Funktionsentwickler für seine tägliche Arbeit nur ein Tool benötigt. Die Änderungen spiegeln sich auf Knopfdruck in beiden Welten wider.
Dieser Prozess ermöglicht die Erzeugung aller notwendigen Datenformate für die Entwicklung und den Aftersales. Zusätzlich können automatisch Test sequenzen zur Verifizierung des tatsächlichen Diagnoseverhaltens der Steuergeräte generiert werden.
Dies bringt in Verbindung mit den verschiedenen Diagnose-Layern Component, System- und Vehicle eines Adap tive AUTOSAR-Steuergeräts wirkungsvolle Diagnosemöglichkeiten direkt ins Fahrzeug. Dadurch wird ein möglichst störungsfreier Betrieb und eine hohe Zuverlässigkeit gewährleistet. Bei auftretenden Fehlern ist eine der Fahrzeugvariante angepasste, zeitnahe Diagnose gegeben. Dank einer intelligenten Problembehandlung können komplexe Funktionen wie ADAS trotz der Störung eines Teilsystems ihren bestmöglichen Funktionsumfang beibehalten.
Fazit
Die Diagnose behält sich die Voraussetzung, sich stetig steigenden Anforderungen komplexer autonomer Systeme der Zukunft anzupassen. Mit der Verfügbarkeit von High-Performance-Computern im Fahrzeug, die auch ausreichende Ressourcen für Diagnosetester besitzen, werden diese Tester ins Fahrzeug integriert. Die Diagnose wird dadurch umfangreicher und mobiler.
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Service-orientierte Architekturen
Grundsätzlich soll mit Service-orientierten Architekturen (SOA) die Strukturierung und Nutzung verteilter Funktionalitäten im Fahrzeug ermöglicht und erleichtert werden. Statt der bisherigen statischen Bindung von Funktionen in einer Applikation (Apps) werden in Zukunft viele Funktionen der Apps erst beim Start miteinander verknüpft. Diese Service-orientierten Architekturen sind in der IT-Welt nichts Neues, aber wie funktionieren sie in Embedded-Systemen im Fahrzeug?
Find Service
Nach dem Einschalten des Fahrzeugs fahren die angeschlossenen Steuergeräte hoch und die dabei startenden Applikationen bieten ihre Services den Clients zur Nutzung an. Diese Services besitzen eine Versionsnummer, um hier die Kompatibilität zwischen verschieden Version sicherzustellen. Mit „Find Service“ können auch die Clients gezielt nach einem Service suchen, wenn der aktuelle Zustand nicht bekannt ist. Dadurch können sich die Kommunikationspartner zur Laufzeit in einem Netzwerk finden, ohne dass hier eine statische Konfiguration vorhanden sein muss. Weitere Applikationen, die neue Services anbieten oder Vorhandene benutzen, können auch nach der Produktion des Fahrzeugs einfach ergänzt werden. Letztlich erreicht man in Fahrzeugen ähnliche Möglichkeiten, wie sie Apps schon heute z. B. bei Smartphones bieten. Die Services selbst können auf drei Arten benutzt werden:
– „Fire und Forget“ – hier sendet der Client Daten an den Server und wartet nicht auf das Ergebnis. Das kann zum Beispiel eine neue Stellgröße für einen Temperaturregler sein.
– „Request und Response“ – hier sendet der Client Daten an den Server und erhält dann das Ergebnis als Antwort zurück. Ein Beispiel wäre das schrittweise Inkrementieren eines Stellwerts und das Zurücksenden des sich dadurch ergebenden
neuen Stellwertes.
– „Event“ – hier sendet der Server selbständig Informationen an einen Client, der sich zuvor registriert hat. Ein Beispiel wäre das zyklische Senden des aktuellen Messwertes der Temperatur an eine Anzeige. Beendet sich ein Server, auch während des laufenden Betriebs, so teilt er dieses den Clients durch das Senden eines Broadcast „Stop Offer Service“ mit. Die Clients können daraufhin ihrerseits entsprechend reagieren.
Fazit
Die Ziele der Service-orientierten Software-Architekturen entsprechen denen in der IT: So soll damit die langfristige Senkung von Kosten in der Entwicklung von Fahrzeugapplikationen erreicht werden. Die höhere Flexibilität dieser Fahrzeugapplikation ermöglicht die Wiederverwendung bestehender Services in verschiedenen Steuergeräten und unterschiedlichen Fahrzeugen. Dies ist notwendig, um die komplexere Software, welche für Autonomes Fahren entwickelt wird, in die Fahrzeuge integrieren und später warten zu können. www.kpit.com
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
FuSi für Künstliche Intelligenz
Um immer komplexere Automated Driving (AD)-Aufgaben zu erfassen, muss die Anwendung durch eine zunehmende Vielfalt von Sensoren in Anzahl und Typ eine komplexere und genauere Darstellung der Verkehrssituation erstellen (siehe Bild 1). In der Folge wird das AD-System immer komplexer und unterliegt daher zunehmend verschiedenen Fehlerarten. Ein unerkannter Fehler in einer der Komponenten dieses AD-Systems kann schwerwiegende Folgen haben. Ziel eines sicheren Systems ist es, sicherzustellen, dass Fehler erkannt werden und dass das System genügend Sicherheitsmechanismen implementiert, um das gesamte System in einen sicheren Zustand zu versetzen. Dennoch zwingt die Komplexität der AD-Komponenten die Anwendungen dazu, die Algorithmen von modellbasierten Techniken auf die der Künstlichen Intelligenz (KI) wie Machine Learning (ML) oder Deep Learning (DL) umzustellen. Solche Verfahren werden zwar immer besser, tendieren aber zur Instabilität, deren Ursprung nur schwer nach zuvollziehen ist.
Vertrauen in die Daten
Die grundlegende Aufgabe einer ADAnwendung besteht darin, die Daten der Sensoren zu erfassen, die Verkehrssituation auszuwerten, eine sichere Trajektorie zu berechnen und diese zur Ausführung an die Aktoren zu senden. Durch Fehler und Toleranzen der Sensoren leidet das System unter einer gewissen Un sicherheit und beeinflusst damit das Vertrauen, das man in die Detektionen setzen kann. Das Vertrauen kann durch den Einsatz von Sensorfusionstechniken im räumlichen Bereich und Zielverfolgungsmethoden im zeitlichen Bereich erhöht werden. Der Kalman-Filter wird häufig für diesen Zweck verwendet, insbesondere bei Radar.
Die Berücksichtigung des Vertrauens niveaus der Detektionen im Entscheidungsprozess ist bei AD-Anwendungen von entscheidender Bedeutung. Das Vertrauen muss sich durch die Verarbeitungskette ausbreiten. Softwarekomponenten, die auf KI basieren, können Teil der Verarbeitungskette sein und sollten daher nicht anders behandelt werden. Wenn man das Konzept auf das Gesamtsystem, vom Sensor bis zum Stellglied, überträgt, wird es möglich, das Gesamtsystem und die Sicherheit der beabsichtigten Funktion (SOTIF) zu bewerten.
NN-Komponenten einfach halten
Eine Möglichkeit, Fehlprognosen aus einem Neuronalen Netz (NN) erkennen zu können, besteht darin, die Komplexität so gering wie möglich zu halten, es mit Merkmalen (z. B. Geschwindigkeit und Lage von Objekten) zu versorgen und die Plausibilität der Ein- und Ausgänge zu überprüfen.
Um die NNs jedoch einfach und klein zu halten, muss eine Sammlung von NNs implementiert werden, die jeweils einer bestimmten Aufgabe zugeordnet sind. Dieser Ansatz unterliegt Abweichungen, wenn die Vorverarbeitungsschritte in Bezug auf die Entwicklungsreife nicht stabil genug sind. Es hat auch den Nachteil, dass kaskadierende NNs eine zunehmende Ungenauigkeit verursachen und sich somit auf das SOTIF auswirken können. Die Verwendung eines End-to-End-Ansatzes kann dieses Problem beheben. Deep Convolutional NNs wie das VGG16 haben eine hervorragende Leistung bei der Objekterkennung gezeigt. Aufgrund seiner Komplexität ist es aber auch wesentlich schwieriger, die Ursache von Fehleinschätzungen zu verstehen und damit Sicherheitsmechanismen zu entwickeln, um sie zu verhindern.
Die Situation wird noch komplizierter, wenn die Anwendung Objekte verfolgen muss. Bewegte Objekte wie z. B. Fußgänger oder Fahrzeuge müssen sehr präzise lokalisiert werden, um eine sichere Trajektorie zu berechnen. Damit ein NN auch eine präzise Lokalisierung der erfassten Objekte ermöglicht, wurden Netzwerkdesigns wie das U-Net [2] entwickelt. Das U-Net fügt ein weiteres Level in der Komplexität des NN hinzu. Es macht die Aufgabe, Fehlprognosen zu erkennen, noch komplizierter. Andererseits, wenn die Information über die Position der Objekte verfügbar ist, kann die zeitliche Verfolgung nicht nur mithilfe der Art des Objekts wie beim VGG16, sondern auch mit der Position dieser Objekte erfolgen.
Eine Möglichkeit, die Größe eines NNs auf der Grundlage von Rohbildern zu reduzieren, besteht darin, eine Sammlung von spezialisierten NNs zu verwenden, die der Erkennung sehr spezifischer Objekte, wie z. B. Verkehrszeichen, dienen (siehe Bild 1). Mit einfachen NNs erleichtert es die Gestaltung funktionaler Sicherheitsmechanismen zur Fehlererkennung. Da sie kleiner sind und sehr spezifischen Aufgaben gewidmet sind, sind diese NN in der Regel einfacher zu trainieren.
Erstellung eines ausfallsicheren Systems
Neben der Implementierung von Sicherheitsmechanismen ist es auch möglich, redundante KI-Komponenten einzusetzen. Diese Technik ist ähnlich wie jede Hardware- oder Software-Redundanz. Die Idee ist, mehrere Implementierungen zu verwenden, die auf den gleichen Anforderungen basieren, von verschiedenen Teams implementiert und auf verschiedenen Datensätzen trainiert werden, um systematische Fehler zu vermeiden. Die Ergebnisse der verschiedenen Versionen von NNs werden zusammen mit dem Vertrauen auf ihre Vorhersagen an ein Abstimmungssystem gesendet (siehe Bild 1). Dieses System kann dann die tatsächliche Leistung des NN-Sets ermitteln.
Fazit
Autonomes Fahren wird immer komplexer, je höher der Grad der Autonomie ist. Die Anzahl und Vielfalt der Sensoren nimmt zu und die AD-Anwendung erfordert immer ausgefeiltere Algorithmen zur Erfassung der Verkehrssituation und der Umgebung des Fahrzeugs.
Die KI ist an einer wachsenden Anzahl von Verarbeitungsstufen beteiligt, von der Wahrnehmung über die Situa tionsanalyse bis hin zur Trajektorienplanung. Trotz der Schwierigkeit, ihre interne Verarbeitung zu verstehen, kann die KI-Komponente in Bezug auf Funktionale Sicherheit und SOTIF wie jede andere Hard- und Softwarekomponente behandelt werden. Um die KI-Komponenten herum können funktionale Sicherheitsmechanismen aufgebaut werden. Sie können die Konsistenz der Vorhersagen sowohl im räumlichen als auch im zeit lichen Bereich überprüfen. Die zeitliche Domäne muss mit Vorsicht behandelt werden, wenn es darum geht, zeitliche Beschränkungen in den Sicherheitsanforderungen festzulegen.
Auf der anderen Seite bietet die Norm ISO 26262 Werkzeuge zur Zuordnung von Fehlerwahrscheinlichkeiten und zur Analyse des Gesamtsystems mit KI. Sicherheitsmechanismen können für das Gesamtsystem einschließlich der KIKomponenten konzipiert werden. Die Normen Für Funktionale Sicherheit und SOTIF sind eine große Hilfe bei der Weiterentwicklung der gesamten Softwarearchitektur, sodass alle Sicherheitsanforderungen erfüllt und die Sicherheitsziele erreicht werden können. » www.kpit.com
Quellenverzeichnis
[1] Very Deep Large Convolutional Networks for Large-Scale Image Recognition, K. Simonyan und A Zisserman, 10–04–2015, Veröffentlicht ICLR 2015,
[2] Convolutional Networks for Biomedical Image Segmentation, O. Ronneberger, P. Fischer und T. Brox, 18–05–2015
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Vernetzte Fahrzeuge und Connected Diagnostics
Die Komplexität moderner Fahrzeug architekturen hat zuletzt durch die Einführung von Gateway-Steuergeräten und DoIP noch einmal deutlich zugenommen. Parallel dazu haben sich die Prüfgeräte weiter entwickelt, um die steigenden Anforderungen von Fahrzeug und Anwender zu erfüllen. Ein Grundprinzip bei der Diagnose blieb bis dato aber unverändert: Sie erfolgt über eine Punkt-zu-Punkt-Verbindung zwischen Diagnosegerät und dem Fahrzeug. Zwar kommen dabei mittlerweile Technologien wie DoIP (Diagnostics over Internet Protocol) und WiFi zum Einsatz. Allerdings kann diese Kommunikation trotzdem nur sporadisch aufgebaut werden und nur dann, wenn das Fahrzeug schon besondere Aufmerksamkeit erfordert und daher beispielsweise in der Werkstatt steht. Die Vernetzung der Fahrzeuge bietet hier in Form von Connected Diagnostics ganz neuen Möglichkeiten für Werkstätten, Mobilitätsdienstleister und Flottenbetreiber.
Diagnose neu denken
Ein dauerhaft verbundenes Fahrzeug ermöglicht viele neue Anwendungen, die das Potenzial haben, Kosten zu senken und das Kundenerlebnis zu verbessern. Zu den möglichen Anwendungen gehören:
- Over-the-Air-Updates: Die Übermittlung von Software-Updates über eine drahtlose Kommunikationsverbindung hat die Automobilindustrie zum Teil bereits implementiert. Die Bedeutung dieser Anwendung wird noch weiter zunehmen.
- Überwachung des Fahrzeugzustands: Ein wichtiger Anwendungsfall ist die Überwachung und Bekanntmachung des Fahrzeugzustands. Auf diese Weise kann eine Organisation die gesammelten Informationen proaktiv einsetzen, um die Fahrtüchtigkeit eines Fahrzeugs ggf. in Interaktion mit dem Kunden und externen Dienstleistern zu gewährleisten. Zusätzlich lassen sich die gesammelten Daten als Grundlage für eine vorausschauende Instandhaltung nutzen.
- Wiederherstellung des Fahrzeugzustands: Wird ein Fahrzeug fahruntüchtig, kann das Fahrzeug in einigen Fällen über Diagnosebefehle in einen Zustand zurückversetzt werden, in dem es wieder sicher fahrbar ist. Damit können Pannendienst- und Kundensupportteams den Kunden bei der Aufrechterhaltung der Mobilität unterstützen.
Sicherheit und Datenschutz
In jeder vernetzten Umgebung sollte das Thema Sicherheit an erster Stelle stehen und das Konzept „Secure by Design“ strengstens eingehalten und befolgt werden. Konzepte wie Fahrzeugzu-Infrastruktur-Kommunikation-VPN, Fahrzeugschlüssel-/Zertifikatautorisierung und permanent sichere Kommunikation sind nur einige der Maßnahmen, die eingesetzt werden können, um Angriffsvektoren (während der externen Kommunikation) zu minimieren.
Auch der Datenschutz ist bei der Entwicklung vernetzter Diagnosesysteme (Connected Diagnostics Systems, CDS) konsequent zu beachten. Grundsätzlich müssen alle übermittelten fahrzeugbezogenen Daten auf eine sichere und kontrollierte Weise behandelt werden. Die Zustimmung des Kunden ist darüber hinaus ein zentraler Faktor. Unternehmen sollten daher Änderungen an ihren Geschäftsbedingungen vornehmen, um sicherzustellen, dass eine rechtskonforme Zustimmung vorliegt und die Dienste entsprechend geschützt sind.
Design to Scale
Die an die Datenerfassungskomponenten eines vernetzten Diagnosesystems gestellten Anforderungen werden mit der Zeit zunehmen bzw. sich verändern. So wird sich die Zahl der vernetzten Fahrzeuge und der Kommunikations ereignisse erhöhen. Gleichzeitig kann die Qualität und Verfügbarkeit der Datenübermittlung (wegen der Verfügbarkeit der Fahrzeugkommunikation, Zeitzonen, usw.) nicht jederzeit vorhergesagt oder garantiert werden.
Die Nutzung von „Design to Scale“-Prinzipien ist hier der Schlüssel zum Erfolg. Das Architekturdiagramm (Bild oben) zeigt eine beispielhafte Lösung.
Es gibt bei diesem Konzept mehrere zusammenwirkende Teile, die zum einen die Bereitstellungs-Gemeinkosten niedrig halten und zum anderen gleichzeitig für größtmögliche Skalierbarkeit und den reibungslosen Umgang mit Bedarfsschwankungen sorgen.
- Der Kommunikationsmanager (A) ist ein skalierbarer Dienst, der exklusiv mit dem Fahrzeug interagiert, und nur für eine minimale Verarbeitung der Nachrichten und die Übergabe an die Warteschlange verantwortlich ist.
- In der Verarbeitungswarteschlange (B) werden die Nachrichten nach der Annahme abgelegt. Dabei wird die Warteschlangentiefe überwacht und die ‚Worker‘ für die Datenverarbeitung bedarfsgerecht skaliert (Serverless Computing).
- ‚Worker‘ übernehmen die Nachrichtenverarbeitung (C) und erweitern die Daten geschäftsspezifisch. Bei einer erfolgreichen Verarbeitung werden die Fertigstellung der Working-Signale und die Quittierung an das Fahrzeug gesendet. Fehlermeldungen können Out-of-Band verwaltet und verarbeitet werden.
Moderne Skalierungstechniken unterstützen diese Architektur und die resultierende Lösung ist dadurch sowohl einfach als auch hochgradig skalierbar.
Neue Geschäftsmodelle
Bei der Einführung dieser Systeme müssen die Kosten (Fahrzeugplattformänderung, Infrastruktur, Systemänderung, Support, usw.) mit dem Nutzen für den Endkunden abgewogen werden. Eine vernetzte Diagnoselösung eröffnet aber eine breite Palette an Möglichkeiten und bietet geschäftliche Vorteile, durch die sich die erforderliche Investition für eine solche Lösung schnell bezahlt macht.
- Vorausschauende Wartung: Auf Basis von Vorort-Fahrzeugdaten und -zuständen ist es möglich, potenzielle Ausfälle zu erkennen, bevor sie auftreten. So lässt sich gemeinsam mit dem Kunden dafür sorgen, dass es nicht zu einem ungeplanten Fahrzeugstillstand kommt. Außerdem ist es im Rahmen von planmäßigen Werkstattbesuchen denkbar, Wartungsarbeiten vorzuschlagen, um erwartete Ausfälle zu vermeiden.
- Wiederherstellung des Fahrzeugzustands: Bei einer Fahrzeugpanne kann vorübergehend ein fahrbereiter Zustand wiederhergestellt werden. Dadurch lassen sich Ausfallzeiten reduzieren und der Kunde bleibt weiter mobil.
- Erhöhte Markentreue: Intelligente Services und die Erhöhung der Fahrzeugverfügbarkeit wirkt sich positiv auf Nutzererfahrung aus. Sie tragen zum Markenwert bei und stärken die Kundentreue.
- Verbesserte Händlererfahrung: Auch das Händlernetz profitiert von vernetzten Diagnosesystemen. Werkstatttechniker können den Fahrzeugzustand ermitteln und Erstdiagnosen durchführen und ggf. Ersatzteile bestellen, bevor das Auto in die Werkstatt kommt. Serviceberater können ein genaues Bild des Zustands vermitteln und Servicearbeiten proaktiv empfehlen, um den Kunden vor Fahrzeugausfälle zu bewahren.
- Lebensdaueranalysen: Derzeit erhalten Zulieferer und OEMs meist nur dann Informationen über eine verbaute Komponente, wenn sie ausfällt – und selbst dann nicht in allen Fällen. Der Kontext zu diesem Ausfall fehlt dabei in der Regel oder beschränkt sich auf einen Diagnose-Fehlercode (DTC). Vernetzte Diagnosesysteme versetzen diese Unternehmen in die Lage, die Leistung von Komponenten zu bewerten und zu verbessern. Zudem könnten sie diese Daten auch in Kombination mit maschinellem Lernen nutzen, um zukünftige Störungen präziser vorherzusagen.
- Aftermarket: Einige Länder verlangen, dass Ferndiagnosemöglichkeiten dem Aftermarket verfügbar gemacht werden. Eine vernetzte Diagnoselösung in Kombination mit einer Extended Vehicle Platform (ISO 20077/8/80) bietet einen Weg, um sowohl diese gesetzlichen Anforderungen zu erfüllen und gleichzeitig ein sicheres, kontrolliertes System zu realisieren.
Eine vernetzte Diagnoselösung hat das Potenzial auch die Anwendungsfälle abzudecken, die heute eine nachgeordnete Rolle oder, wie Pay-per-Use oder Ferninspektion, noch weitgehend Zukunftsmusik sind aber schnell an Bedeutung gewinnen können. Unternehmen, die rechtzeitig eine vernetzte Diagnoselösung einführen, können auf diese und ähnliche Anforderungen reagieren und neue Geschäftsmodelle entwickeln. » www.kpit.com
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Architekturkonzepte für autonome Fahranwendungen
In den vergangenen Jahren hat die Automobilindustrie die Funktionsmerkmale, die auf eine Unterstützung des Fahrers in schwierigen Verkehrssituationen abzielen, ganz erheblich verbessert. Diese im Allgemeinen unter dem Begriff Fahrerassistenzsystem (ADAS, Advanced Driver Assistance System) zusammengefassten Funktionen reichen vom Einparken über Spurhalteassistenten (LKA, Lane Keeping Assistance) bis hin zu komplexeren Funktionen wie adaptivem Tempomat (ACC, Advanced Cruise Control). Solche Funktionen erfordern eine begrenzte Anzahl an Sensoren. Die in Bild 1 gezeigte Architektur stellt eine mögliche Konstruktion zur Implementierung von Funktionen wie Spurhalteassistent und adaptivem Tempomat dar.
Unter der Voraussetzung, dass Spurhalteassistent und Tempomat entsprechend den Richtlinien von ISO 26262 realisiert wurden, kann eine solche Architektur das Egofahrzeug in einem sicheren Zustand halten. Die Erwartungen an Autonomes Fahren (AD) sind jedoch weitaus höher und erweitern den Komplexitätsgrad des Systems ganz erheblich.
Die Komplexitätsexplosion
Um zunehmend komplexe autonome Fahrfunktionen wahrzunehmen, muss die Anwendung eine aufwendigere und präzisere Darstellung der Verkehrssituation durch Einbeziehung einer immer größeren Zahl von Sensoren wie Radargeräten, Kameras, GPS-Ortung und hochauflösenden Karten ermöglichen. Eine Architektur wie die in Bild 1 gezeigte hat grundsätzlich mehrere gravierende Nachteile.
Erstens bietet diese Architektur nur geringe Konfigurationsmöglichkeiten. Zweitens erfordert sie auch den Austausch einer Datenmenge zwischen Komponenten, die mit steigender Anzahl von Sensoren immer größer wird. Damit wächst die Kommunikationsbandbreite, wodurch sich die Skalierbarkeit der Lösung verringern kann. Mit zunehmender Komplexität müssen mehr Funktionen zu den Entscheidungs- und Planungsebenen hinzugefügt werden. In der Folge sinkt die Modularität. Es sei auch darauf hingewiesen, dass diese Aspekte gegen die Empfehlungen der ISO 26262 sprechen.
Eine besser geeignete Architektur ist in Bild 2 zu sehen. Diese Architektur ermöglicht auch die Implementierung des oben erwähnten Spurhalteassistenten und Tempomats, dargestellt in den dunkelblauen Kästen. Auch die Integration neuer autonomer Fahrfunktion kann skalierbarer und reibungsloser erfolgen. Funktionen wie Spurwechselassistent (LCA) oder Notfall-Fahrmanöver (MRM) können ohne Beeinflussung des LKA/ ACC-Moduls hinzugefügt werden.
Zu beachten ist auch, dass diese Architektur vom Standpunkt der Funktionssicherheit aus eine kohärente Partitionierung der unterschiedlichen Module erlaubt, sodass eine hohe Kohärenz erreicht wird und die Schnittstellen zwischen Komponenten gleichzeitig möglichst schmal bleiben.
Sicheres Überholen auf der Autobahn
Der Anwendungsfall des Überholens eines vorausfahrenden Fahrzeugs auf einer dreispurigen Autobahn ist eine der gängigsten Situationen (siehe Bild 3). Für die autonome Fahranwendung besteht das Manöver darin, vom LKA/ACCModus auf den Spurwechselassistenten (LCA) umzuschalten. Aus Gründen der Funktionssicherheit wird die Notfall-Fahrmanöverkomponente ebenfalls aktiviert. Diese sorgt dafür, dass in allen Situationen einschließlich aller Fehlersituationen, die jederzeit auftreten können, ein sicherer Zustand aufrechterhalten werden kann. Hier ist darauf hinzuweisen, dass die autonome Fahranwendung bei einer solchen Aufgabe nur Fahrfertigkeiten ausübt.
Umgang mit Autobahnausfahrten
Bei einem höheren Grad an Autonomie muss die Anwendung komplexere Situationen meistern wie etwa das Anfahren einer Autobahnausfahrt, wie in Bild 4 dargestellt. Das rote Egofahrzeug nähert sich der zu benutzenden Ausfahrt. Nun liegt die Gefahr bei einem abstrakteren Begriff: einem gefährlichen Fahrstil. Dies kommt in einem höheren Abstraktionsgrad zum Ausdruck und kann nicht mit Gefahren aufgrund der Verkehrssituation vermischt werden. Zum Umgang mit dieser Situation muss die autonome Fahranwendung über Situationsanalysefähigkeiten verfügen.
Genauer gesagt verfügt die in Bild 2 gezeigte Architektur über keinerlei Mechanismen, mit denen sich die Frage klären lässt, ob ein Überholen des vorausfahrenden Fahrzeugs bzw. der vorausfahrenden Fahrzeuge auf sichere Weise möglich ist. Eine solche Architektur ist in Bild 5 dargestellt.
Die blau dargestellte Architektur aus Bild 2 ist dabei um das notwendige Modul zur Berechnung der Bahnen auf der Ausfahrtspur ergänzt. Bild 5 zeigt darüber hinaus eine zusätzliche gelbe Ebene. Als Eingangsdaten nutzt diese Ebene Informationen wie die vom GPS ermittelte Position und hochauflösende (HD)-Karten der Fahrzeugumgebung.
Das einem solchen Ansatz zugrunde liegende Konzept lässt sich mit Begriffen wie sichere Zustände und sicheres Segment umschreiben. Ein sicheres Segment besteht aus einer kontinuierlichen Abfolge sicherer Zustände zwischen wesentlichen Aktionspunkten wie Autobahnausfahrten. In diesen Segmenten können alle Fahrentscheidungen der unteren Ebene überlassen werden, auf der die autonome Fahranwendung ihre Fahrfertigkeiten nutzt. Andererseits sind in der Nähe der wesentlichen Punkte einige der fahrfertigkeitsbezogenen Aktionen durch Situationsanalysefähigkeiten zu entschärfen.
Vollautonomes Fahren
Das im vorhergehenden Abschnitt beschriebene Konzept lässt sich noch erweitern. Das eigentlich Ziel des Fahrers und der Insassen des Fahrzeugs besteht darin, von Punkt A zu Punkt B zu gelangen. Der Weg, dem das Fahrzeug folgt, ist eine Ansammlung von Segmenten, die an einigen speziellen Punkten durch Richtungswechsel getrennt sind. Diese Art von Fahrt hat auch einige zeitliche Beschränkungen, selbst wenn es keine sehr dringlichen sind (Beispiel: Ein Fahrer, der sich um 14 Uhr auf eine einstündige Fahrt begibt, möchte vor Anbruch der Dunkelheit am Zielort ankommen). Die Auswahl eines sicheren Wegs muss in Abhängigkeit davon erfolgen. Bei falscher Auswahl kann es zu gefährlichen Situationen kommen.
Es scheint daher die richtige Erweiterung des im vorhergehenden Abschnitts dargelegten Konzepts zu sein, eine sichere Fahrt als eine Ansammlung sichererer Segmente zu betrachten. Am wichtigsten ist eine stabile Definition von sicherer Fahrt. In vielen Fällen entwickelt sich die Verkehrssituation im Verlauf der Fahrt beispielsweise durch Unfälle oder Staus auf eine nicht vorhergesehene Weise. Es ist darauf hinzuweisen, dass die Handhabung des Begriffs einer sicheren Fahrt wiederum auf einer anderen konzeptionellen Ebene erfolgt, aber auch von der Art der behandelten Gefahren abhängt.
Da scheint es nur nahezuliegen, eine weitere Steuerungsebene zur im vorherigen Abschnitt beschriebenen Architektur hinzuzufügen. Ziel dieser Ebene ist die Umsetzung der Planungsfähigkeiten der autonomen Fahranwendung und somit die Umwandlung der geplanten Fahrt in eine Abfolge sicherer Segmente und zweitens bei Bedarf die dynamische Erstellung eines Satzes alternativer Fahrrouten und der zugehörigen Segmente.
Fazit
Mit einfachen ADAS-Funktionen wie Spurhalteassistent und adaptiver Tempomat kann die zugrunde liegende Architektur in einem sehr einfachen, flachen Layout verbleiben. Für die Behandlung komplexerer Situationen wie Autobahnausfahrten müssen die Architekturkonzepte erweitert werden.
Für die allerhöchste Ebene des autonomen Fahrens muss die autonome Fahranwendung in der Lage sein, eine sichere Fahrt auszuwählen, die sich aus einer dynamisch berechneten Ansammlung sicherer Segmente zusammensetzt. Mit einem hierarchischen Ansatz kann sich das Fahrzeug ohne Eingriffe des Fahrers auf eine sichere Reise begeben, und genau dies ist Level 5 des autonomen Fahrens.
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Modell- und netzwerkbasierte Diagnose Vorgestellt wird
Architekturen, virtuelle ECUs usw. an, so
steigt die Komplexität der Diagnostik oder der Diagnose
von Fehlern und der Lokalisierung ihrer Grundursache exponentiell
an. Die Auswirkungen dieser Komplexität sind deutlich
zu erkennen bei denjenigen, die diese Fahrzeugtechnologien
verwalten und aktualisieren müssen (wie End-of-Line-
Fertigung oder OEM-Kundendienstanbieter). Dies konzentriert
sich insbesondere im Kundendienstbereich an der
Schnittstelle zum Kunden. Die Kundenerfahrung ist ein kritischer
Parameter für den Aufbau und Erhalt von Markentreue,
daher ist es wichtig, jegliche Ausfallzeiten von Fahrzeugen
auf ein Minimum zu beschränken.
Diese Komplexität steht im direkten Widerspruch zu den
wachsenden Anforderungen der Kunden und dem Wunsch
nach einer Reduzierung der Fahrzeugausfallzeiten. Früher
verfügte ein Kfz-Mechaniker über die Kenntnisse, die eine effektive
Reparatur des Fahrzeugs gestatteten. In komplexen
Umgebungen sind die Möglichkeiten dieser Fachkräfte trotz
ihres umfangreichen Know-Hows jedoch begrenzt. Letztendlich
beeinträchtigt dies die effektive Diagnose und somit die
Reparatur des Fahrzeugs.
Ein weiterer unbefriedigender Punkt bei modernen Fahrzeugen
ist der immer häufiger vorkommende Austausch nicht
fehlerhafter Teile. Dies wird üblicherweise als „No Fault
Found“ oder „No Trouble Found“ bezeichnet. Dies geschieht
dann, wenn ein Mechaniker ein Teil ersetzt, das eigentlich
nicht die Grundursache für das vom Kunden beanstandete
Problem war. Im Allgemeinen ist es in diesem Fall erforderlich,
dass der Kunde zum Händler zurückkehrt, was mit hoher
Wahrscheinlichkeit mit Unannehmlichkeiten verbunden ist,
die vermeidbar gewesen wären. Wenn es für das Fahrzeug
eine Herstellergarantie gibt, entstehen dem OEM unmittelbare
Kosten.
Die Problempunkte sind offensichtlich – hohe Garantiekosten,
geringe Kundenzufriedenheit usw., und dies alles
letztlich verursacht durch Fehldiagnosen. Solche Probleme
lassen sich nur entschärfen oder lösen, wenn effektive Diagnosen
durchgeführt werden. Zunehmende Komplexität erfordert
erweiterte Kenntnisse, Fähigkeiten und Erfahrungen
– und all dies verursacht (direkte oder indirekte) Kosten. Ein
Ansatz besteht darin, die Abhängigkeit von den Entscheidungen
eines Kfz-Mechanikers zu reduzieren und das Konzept
der geführten Diagnose einzuführen.
Sieht man sich moderne technische Konzepte wie merkmalbasierte Architekturen, virtuelle ECUs usw. an, so steigt die Komplexität der Diagnostik oder der Diagnose von Fehlern und der Lokalisierung ihrer Grundursache exponentiell an. Die Auswirkungen dieser Komplexität sind deutlich zu erkennen bei denjenigen, die diese Fahrzeugtechnologien verwalten und aktualisieren müssen (wie End-of-Line- Fertigung oder OEM-Kundendienstanbieter). Dies konzentriert sich insbesondere im Kundendienstbereich an der Schnittstelle zum Kunden. Die Kundenerfahrung ist ein kritischer Parameter für den Aufbau und Erhalt von Markentreue, daher ist es wichtig, jegliche Ausfallzeiten von Fahrzeugen auf ein Minimum zu beschränken.
Diese Komplexität steht im direkten Widerspruch zu den wachsenden Anforderungen der Kunden und dem Wunsch nach einer Reduzierung der Fahrzeugausfallzeiten. Früher verfügte ein Kfz-Mechaniker über die Kenntnisse, die eine effektive Reparatur des Fahrzeugs gestatteten. In komplexen Umgebungen sind die Möglichkeiten dieser Fachkräfte trotz ihres umfangreichen Know-Hows jedoch begrenzt. Letztendlich beeinträchtigt dies die effektive Diagnose und somit die Reparatur des Fahrzeugs.
Ein weiterer unbefriedigender Punkt bei modernen Fahrzeugen ist der immer häufiger vorkommende Austausch nicht fehlerhafter Teile. Dies wird üblicherweise als "No Fault Found" oder "No Trouble Found" bezeichnet. Dies geschieht dann, wenn ein Mechaniker ein Teil ersetzt, das eigentlich nicht die Grundursache für das vom Kunden beanstandete Problem war. Im Allgemeinen ist es in diesem Fall erforderlich, dass der Kunde zum Händler zurückkehrt, was mit hoher Wahrscheinlichkeit mit Unannehmlichkeiten verbunden ist, die vermeidbar gewesen wären. Wenn es für das Fahrzeug eine Herstellergarantie gibt, entstehen dem OEM unmittelbare Kosten.
Die Problempunkte sind offensichtlich – hohe Garantiekosten, geringe Kundenzufriedenheit usw., und dies alles letztlich verursacht durch Fehldiagnosen. Solche Probleme lassen sich nur entschärfen oder lösen, wenn effektive Diagnosen durchgeführt werden. Zunehmende Komplexität erfordert erweiterte Kenntnisse, Fähigkeiten und Erfahrungen – und all dies verursacht (direkte oder indirekte) Kosten. Ein Ansatz besteht darin, die Abhängigkeit von den Entscheidungen eines Kfz-Mechanikers zu reduzieren und das Konzept der geführten Diagnose einzuführen.
Geführte Diagnose
Geführte Diagnose nennt man gewöhnlich den Prozess der Diagnose einer Fehlergrundursache an einem Fahrzeug. Man beginnt mit einem Fehlerfall (zum Beispiel bestimmten Symptomen oder anderen Hinweisen). Der Mechaniker wird dann durch mehrere Tests geführt, die schließlich eine Schlussfolgerung zulassen, welche Komponenten ursächlich betroffen sind. Geführte Diagnosen haben sich über die Jahre weiterentwickelt. Es gibt verschiedene Methoden und Verfahrensweisen, die eine geführte Diagnose ausmachen:
– Prüfschritt-Diagnose – Die einfachste Form einer geführten Diagnose lässt sich als Ablauf einfacher Verfahrensschritte darstellen, der bei Befolgung (wahrscheinlich) zu einer korrekten Diagnose mechanischer Fehler führen wird.
– DTC-basierte Diagnose – Wenn ein elektrisches System beteiligt ist, ermöglicht die DTC-basierte Diagnose-Tests auf Basis der vorhandenen DTCs durchzuführen. Dabei kann es sich um einen langen, aufwendigen Prozess handeln, der u. a. von der Genauigkeit der Informationen zu den DTCs abhängt.
– Modellbasierte Diagnose – Zur Darstellung der technischen Systeme wird ein mathematisches Modell herangezogen.
– Netzwerkbasierte, geführte Diagnose – Dieses Konzept beruht auf der Idee, dass Modelle zur Darstellung eines digitalen Zwillings des Fahrzeugs gebaut werden und Informationen aus dem realen Fahrzeug auf das Modell übertragen werden können, was ein weit präziseres Bild ermöglicht, sodass die Diagnoseschritte mit diesen Informationen dynamischer und mit ständigen Anpassungen durchgeführt werden können.
Netzwerkbasierte Diagnose?
Der wesentliche Vorteil erweiterter Techniken wie der modell- und netzwerkbasierten Diagnostik liegt im Übergang von statischer zu dynamischer Diagnose. Eine statische Diagnose stützt sich auf eine große Menge vorbestimmter Daten und kann nur so genau sein, wie die Informationen, auf denen sie basiert. Dies ist vollkommen zweckmäßig, wenn der Fehler bekannt ist oder verstanden wird, setzt aber voraus, dass bestimmte Bedingungen erfüllt sind.
Die dynamische Diagnose verwendet hingegen ein Modell, das kontinuierlich angepasst wird. Die dem Modell zugeführten Fakten werden ständig aktualisiert, wenn neue Informationen hinzukommen oder bestimmte Bedingungen erfüllt sind oder ausgeschlossen werden.
Validierung und kontinuierliche Verbesserung
Das Hauptunterscheidungsmerkmal eines solchen Systems besteht in seiner Fähigkeit, fahrzeugtechnische Daten wirksam zu nutzen und sich mit der Zeit zu verbessern. Dies gilt insbesondere für dynamische, datengetriebene Diagnosesysteme. Genauso wichtig ist es jedoch, der Qualität der Daten im Modell vertrauen zu können. Ferner hat ein dynamisches System einen immanenten Vorteil. Die Leistungsfähigkeit der K-Grip Reasoning Engine ermöglicht die Entwicklung intelligenter Algorithmen, die einfache Lücken feststellen können, die ansonsten übersehen und möglicherweise nie entdeckt worden wären. Zum Beispiel:
– Überflüssige Teile – Ein Teil ist im Modell vorhanden, weist aber keine Verbindung auf. Dies bedeutet, dass sämtliche Störungsszenarien (zum Beispiel Symptome in Bezug auf die Komponente oder DTCs), die ansonsten mit einer Grundursache enden würden, nicht diagnostiziert werden. Dies hat "No Fault Found"-Ergebnisse zur Folge, die sich wiederum auf die Kundenzufriedenheit auswirken.
– Unvollständige Störungen – Eine oder mehrere Störungsszenarien (zum Beispiel spezifische Symptome) sind nicht vollständig. Dies wird im Allgemeinen als ein Pfad durch das Modell beschrieben, der nicht zu einer Grundursache führt.
Datenerfassung und -speicherung
Für einen OEM werden täglich tausende Fahrzeuge diagnostiziert.
Die Erfassung dieser Daten ist erforderich, um sowohl aktuelle Modellverknüpfungen zu validieren, als auch von neuen und unzusammenhängenden Verknüpfungen zu erfahren. Ein typischer (vereinfachter) Datenerfassungsprozess ist in Bild 1 zu sehen. Lokale Clients erfassen Daten und speichern Diagnosesitzungen. Diese werden dann asynchron einem Remote-Speichersystem zugeführt, das die Daten erfasst und verwaltet. Die Sitzungsverfolgungs-Engine kann optimiert werden, um Online/Offline-Szenarien zu verarbeiten und mehrere lokale Clients transparent nachzuverfolgen.
Das Volumen der gesammelten Daten ist signifikant. Bild 2 zeigt das Datenvolumen, das für alle Diagnosesitzungen eines typischen mittelgroßen OEM gesammelt würde.
Bei solchen Datenmengen ist es wichtig, dass das Format leicht zu interpretieren und gut zu verschlüsseln ist. Dies ermöglicht den Offline-Prozessoren, den Datenraum zu durchforsten und Fakten zu extrahieren, die dann für weitergehende Analysen genutzt werden können.
Die "Lernschleife"
Das Konzept der Lernschleife wird durch eine große Menge von Daten ermöglicht, die das System zusammenträgt. Nimmt man zum Beispiel ein Szenario, in dem plötzlich eine steigende Anzahl von Komponenten ersetzt wird, ohne dass dabei eine Störung gefunden wird. Mit den im System vorhandenen Daten ist es möglich, nicht erwartete Fehlergruppen ausfindig zu machen – und die Systemtechniker frühzeitig auf Probleme hinzuweisen. Dadurch kann die Ursache identifiziert und das Modell aktualisiert werden, um eine alternative Prüfung bereitzustellen, die den Mechaniker anweist, die "tatsächliche" ursächliche Komponente zu kontrollieren und die No-Fault-Found-Situation zu bereinigen.
Netzwerkbasierte Diagnose K-GRIP
KGRIP ist die netzwerkbasierte Diagnoselösung von KPIT. Ihre von Grund auf skalierbare Architektur macht KGRIP in Kombination mit einer hochmodernen Regel-Engine zur idealen Lösung. Unter anderem sind dabei folgende Fragen zu stellen:
– Lässt sich eine Diagnose für jede Komponente im System durchführen?
– Sind jeder Grundursache Symptome zugewiesen, d. h., lässt sich das Problem beschreiben, das sich für jede Komponente stellt?
– Gibt es irgendwelche Komponenten ohne Grundursache?
Die K-GRIP-Lösung stellt Tools bereit, die den Aufwand für die Validierung dieser Fragen deutlich verringern. Die Lösung umfasst Werkzeuge und Berichte, die es einem Mechaniker ermöglichen, das Modell zu untersuchen und Fehler jeglicher Art sowie die entsprechenden Fehlerbehebungen schnell zu identifizieren. W (oe)
»»www.kpit.com
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Adaptive AUTOSAR – Eine neue Art des Arbeitens
Die Softwareplattformen, die heute in der Automobilindustrie vorwiegend genutzt werden, bauen auf Firmware auf. Die Firmware ist ein binär laufender Build für Bare-Metal in einem bestimmten Mikrocontroller. Es wird ein Anforderungskatalog erstellt und als Firmware-Implementierung oder -Konfiguration realisiert. Sie wird bei der Produktion, einer regelmäßigen Wartung in einer Werkstatt oder im ungünstigsten Fall bei einem Rückruf aufgrund von enthaltenen Fehlern heruntergeladen. Das ursprüngliche Ziel besteht jedoch darin, dass der Hersteller nach dem Download niemals einen Software-Update während der Lebensdauer des Fahrzeugs vornehmen muss.
Diese Vorgabe passt nicht sehr gut zu Software. Nicht weil die Automobilindustrie schlechte Softwareingenieure hätte. Aber die Funktionen und Aufgaben, die elektronische Steuergeräte heute übernehmen müssen, sind so komplex, dass sich kontinuierliche Funktionsupdates sowie auch Softwarefehler nicht vermeiden lassen. Je komplexer ein Projekt ist, desto stärker steigt die Zahl der Fehler pro Codezeile an [Code2], d. h. die Anzahl der Fehler ist nicht nur eine lineare Funktion der Codezeilen. Es können natürlich größere Investitionen in Überprüfung und Validierung vorgenommen werden, aber dem Funktionswachstum wird oft Vorrang vor der Modul- und Integrationserprobung gegeben. Zusätzlich verlangt eine typische Überprüfung das gleiche Expertenniveau wie bei der Implementierung. Der Systemtest ist teuer und schwierig zu koordinieren. Außerdem sind die Anforderungen nicht in allen Fällen von Beginn an klar, was die Validierung des Systems erschwert.
Die neue Generation der Fahrzeugeigentümer erwartet neueste und moderne Merkmale im Auto. Die meisten dieser Funktionen stehen in Verbindung mit der Software. Smartphones sind heute weit effizienter in der Anpassung an die Benutzeranforderungen. Sie sind permanent mit dem Internet verbunden und lösen viele Aufgaben, die als normaler Bestandteil der heutigen Lebensweise betrachtet werden.
Bei Infotainment- und Telematikprojekten wurden schon früh komplexe Funktionsimplementierung und ein agiler Arbeitsprozess eingeführt. Üblicherweise handelt es sich dabei um aktualisierbare Systeme mit einem Dateisysteme unterstützenden komplexen Betriebssystem wie Linux. Leider stellen diese Projekte in vielen Fällen eine Integration zahlreicher Module dar, wodurch eine Softwareplattformintegration entsteht, die sich nur wenig oder garnicht zur Wiederverwendung eignet. Jede Generation eines Projekts ist im Grunde ein Neubeginn. Darüber hinaus sind Linux-basierte Plattformen nicht sehr gut darin, Sicherheits- und anspruchsvolle Echtzeitanforderungen zu erfüllen.
Adaptive AUTOSAR
Vor diesem Hintergrund ist Adaptive AUTOSAR ein neuer Standard, der die oben erwähnten Probleme löst und eine teilweise service-orientierte Architektur (SOA) schafft.
Classic AUTOSAR ist eine eigenständige Firmware-Plattform, während Adaptive AUTOSAR nicht versucht, in diesem Sinne vollständig zu sein, um eine komplette SOA zu bilden. Eine SOA ist eine Softwareplattform, bei der Dienstleistungen im Mittelpunkt stehen. Eine Dienstleistung wird von einem Dienstleister erbracht und von einem Dienstleistungsnutzer in Anspruch genommen. Die Verbindung zwischen einem Dienstleister und einem Dienstleistungsnutzer wird von einem Service-Broker dynamisch zur Laufzeit hergestellt. Der Dienstleistungsnutzer muss nicht unbedingt wissen, wo sich der Dienstleister befindet. Daher ist die Softwareplattform dynamisch und kann teilweise ohne Auswirkungen auf das System aktualisiert werden.
Wie oben erwähnt, beansprucht Adaptive AUTOSAR nicht, eine komplette SOA zu schaffen. Das Betriebssystem ist nur verknüpft und nicht spezifiziert [AUTOSAR OS]. Hier verbindet sich eine Adaptive AUTOSAR-Anwendung mit einem Betriebssystem, das die API-Untergruppe PSE51 des POSIX-Standards bereitstellt [POSIX]. Dies bedeutet nicht, dass das Betriebssystem nur PSE51 sein kann, sondern dass die Adaptive AUTOSAR-Anwendung nur diese API verwenden kann. Das Betriebssystem kann immer noch ein vollständiges PSE54-System sein (z. B. das PSE54-basierte Linux).
Dieses Konzept hat den Vorteil, dass alle POSIX-konformen Anwendungen und Bibliotheken modelliert werden können.
Zudem können sie auf einer beliebigen AUTOSAR-Softwareplattform wiederverwendet und eingesetzt werden. In anderen Worten, AUTOSAR versucht nicht, POSIX neu zu definieren. Nur zur Klärung sei daran erinnert, dass POSIX eine Standardschnittstelle für eine Programmieroberfläche ist. Es ist weder eine implementierte Anwendung noch ein Betriebssystem (Bild 1).
Es gibt eine Nachfrage nach alter zuverlässiger Software, die schon lange angeboten wird, da befürchtet wird, dass eine neue Software immer Fehler enthält. Warum nicht also einfach den alten Code verwenden und einige kleinere Erweiterungen vornehmen? Die heute in der Software verlangten Funktionen entwickeln sich sehr stark weiter. Es ist sehr schwer, eine gute Architektur zu schaffen, die es ermöglicht, alle Arten von künftigen Merkmalen hinzuzufügen, die nicht von Anfang an bekannt sind. Ein Refactoring der Software ist von Zeit zu Zeit erforderlich, um die Software effizient pflegen und überprüfen zu können. In vielen Fällen wird so in Bezug auf das klassische AUTOSAR argumentiert. Der Vorzug von Adaptive AUTOSAR liegt darin, dass POSIX-konforme Software wiederverwendet werden kann, nach der Philosophie „Einmal schreiben, überall anpassen“. Es besteht kein Zwang, etwas umzuschreiben und können von bestehender offener Software profitieren, oder ein Software-Unternehmen kann Anwendungen für unterschiedliche Kunden wiederverwenden.
Die Entscheidung für eine service-orientierte Architektur (unter Verwendung von Adaptive AUTOSAR) beseitigt nicht alle Hindernisse auf dem Weg. Der Umstieg von einem firmwarebasierten Ansatz (d. h. Classic AUTOSAR) auf SOA bedeutet, dass man vor neuen Herausforderungen steht, die bisher nicht bekannt waren oder in erster Linie manuell gelöst wurden. Einige davon werden hier behandelt.
Eine aktualisierbare SOA impliziert, dass sich der Arbeitsprozess der Projekte verändern muss. Das klassische Wasserfallmodell, bei dem ein Lieferant eine Anforderungsliste erhält und diese umsetzt und testet, funktioniert dann nicht mehr wirklich. Stattdessen ist eine agile Arbeitsweise auf der Grundlage eines Continuous Integration (CI)-Konzepts erforderlich (Bild 2), nämlich eine CI, die kontinuierlich neue Software überprüft und freigibt. Zusätzlich verbinden sich der OEM und Lieferanten mit der CI, und die Lieferanten haben eine eigene CI für ihre Anwendungen oder Softwareplattformen. Um einem solchen CI-Ökosystem gerecht zu werden, müssen die CIs von OEM und Lieferanten automatisch interagieren. CIs, die automatisch Versionen für die CI anderer Unternehmen (OEMs) erstellen, sind für IT- und Rechtsabteilungen eine schwer zu knackende Nuss. Man muss die Eigentumsstruktur verstehen und wissen, wie sich solche Interaktionen sicher durchführen lassen.
Wiederverwendbarkeit
Ein weiteres wichtiges Thema ist es, eine Softwareplattform für verschiedene Projekte wiederverwendbar zu machen, ohne jedes Mal von Null zu beginnen. Hier erweist sich der Adaptive AUTOSAR-Standard als sehr hilfreich. Einerseits gibt es genau umrissene AUTOSAR-Basisdienste wie Diagnostic Manager für spezifische im Fahrzeug erforderliche Funktionen und andererseits eine klare Methodik und ein Austauschformat zur Verwendung durch OEMs und Lieferanten im Arbeitsprozess. Die Existenz eines solchen Standards ermöglicht die Entwicklung und Wiederverwendung von Anwendungen für unterschiedliche Projekte und Kunden.
Der Vorteil eines Firmware-Konzepts besteht darin, dass Updates einmalige Vorgänge sind. Bei einem aktualisierbaren System werden hingegen räumlich und zeitlich unterschiedliche Teil-Updates vorgenommen. Das Basis-Image wird implementiert, und verschiedene Organisationen (und Unternehmen) führen zu unterschiedlichen Zeiten Updates am System durch. Dies stellt hohe Anforderungen an die Bereitstellung von Offline-Tools. Das Update muss vor der Implementierung auf Kompatibilität überprüft werden. Das Update ist so zu verifizieren, dass es zu keinerlei Ausfällen im Fahrzeug führen wird. Auch müssen Updates orchestriert werden, wenn z. B. zwei elektronische Steuereinheiten aktualisiert werden müssen und eine ausfällt, muss die Software in beiden ECUs auf die Vorgängerversion zurückgesetzt werden.
Service-orientierte Architektur
Der POSIX-Standard definiert verschiedene Merkmale, wobei die Feature-Ebene von den PES51-54-Profilen gesteuert wird. In jedem Profil sind die meisten Merkmale optional [POSIX]. Im klassischen AUTOSAR ist der Funktionsinhalt klar umrissen und wird meist von den Skalierbarkeitsklassen gesteuert. Zwei verschiedene POSIX-Betriebssysteme können sich in ihrem Funktionsinhalt sehr stark unterscheiden. Es ist wichtig, die benötigten Merkmale eines POSIX-Betriebssystems in einer frühen Projektphase festzulegen und zusätzlich sicherzustellen, dass das gewählte POSIX-Betriebssystem mit weiteren Merkmalen erweiterbar ist, wenn das Projektwachstum dies erfordert.
SOA wird oft mit dynamischem Verhalten in Verbindung gebracht. Aber um die Software der nächsten Generation in Fahrzeugen steuern und verwalten zu können, muss der Arbeitsprozess stringent und automatisiert sein. Außerdem muss die Software im Fahrzeug gesteuert werden, um Verifizierung und Sicherheit zu erreichen. Lieferanten und OEMs für Fahrzeuge werden enger zusammenarbeiten und dabei automatisierte kontinuierliche Integrationssysteme nutzen. Die statische Prüfung ist durch eine dynamische Prüfung im Fahrzeug zu erweitern (z. B. durch Hinzufügen von Metadaten). Unterschiedliche Lieferanten im Ökosystem der Softwareplattform müssen effizient zusammenarbeiten. Dazu ist ein vertragsbasiertes Entwicklungskonzept vonnöten.
Dies sind einige Themen, die beim Umgang mit dem neuen SOA-Modell zu beachten sind. Eine auf Adaptive AUTOSAR basierende SOA ersetzt die klassische AUTOSAR-Plattform nicht 1:1. Es sollte hier nur gezeigt werden, dass es sowohl im technischen Bereich als auch hinsichtlich der Arbeitsprozesse neue Herausforderungen zu bestehen gibt. Der Vorteil des Konzepts von Adaptive AUTOSAR ist die Angleichung an einen bestehenden Standard wie POSIX. Daher ist es möglich, Software und Erfahrungen aus verschiedenen Projekten (auch aus anderen Bereichen als der Automobiltechnik) wiederzuverwenden.
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Eingebettete Fahrzeugdiagnose
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)
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
KPIT gibt die neuesten Upgrades seiner Produktfamilie für die Fahrzeugdiagnose bekannt
Das Release 2017-R2 der Produktfamilie Diagnostic & Connectivity Platform (KDCP) enthält zahlreiche neue Funktionen und Verbesserungen mit folgenden Highlights:
- Der leistungsfähige Diagnose-Stack von KPIT enthält einen ISO MVCI Server, eine D-PDU API und einen OTX-Interpreter. Er unterstützt jetzt Diagnostics over IP, welches die mit UDS eingeführten Diagnosedienste über Ethernet verwendet. Dadurch stehen im Vergleich zu CAN beträchtlich höhere Datenraten zur Verfügung, was eine erhebliche Zeitersparnis bei komplexen Diagnoseaufgaben und Flash-Anwendungen ermöglicht.
- Das in der D-PDU API integrierte Simulations-Modul, welches das Testen von Diagnosedaten auch ohne Steuergerät und VCI ermöglicht, wurde erneuert. Die neue JavaScript-basierte Dynamic ECU Simulation kann jetzt mehrere Steuergeräte enthalten und unterstützt neben dynamischen Änderungen von Werten auch das Setzen von Steuergeräte-Status, z.B. den Wechsel von Sessions.
- Das neue Diagnostic Example erleichtert den Einstieg und verkürzt die Einarbeitung in die gesamte Produktfamilie. Dazu wurden die mitgelieferten ODX 2.2 Beispieldaten erweitert, in Form einer Steuergeräte-Spezifikation vollständig dokumentiert und mit einer passenden Simulation komplettiert. Weiterhin wurden zahlreiche OTX-Abläufe inklusive Benutzeroberflächen als Beispiele hinzugefügt.
- Im OTX Authoring, der Entwicklungsumgebung für komplexe Diagnoseabläufe, grafische Benutzeroberflächen und Geführte Fehlersuche, wurde die Startseite komplett überarbeitet. Dies ermöglicht jetzt u.a. den direkten Zugriff auf die bereits erwähnten Beispiele.
- Ein neues Mitglied der Produktfamilie ist das Diagnostic Tester Framework. Es ermöglicht die generische Erstellung von Diagnosetester-Applikationen für die Produktion oder den Kundenservice auf Basis anwenderspezifischer OTX-Abläufe und Benutzeroberflächen. Für den komfortablen Zugriff auf Fehlerspeicher, Messwerte oder spezielle Funktionen (z.B. die Steuergeräte-Programmierung) stehen jeweils spezifische Ansichten zur Verfügung.
Bitte beachten:
Anwendern mit einem Wartungs- und Servicepaket wird das Upgrade auf Release 2017-R2
kostenfrei zur Verfügung gestellt.
Mehr Informationen über die Diagnostic and Connectivity Platform von KPIT finden Sie unter www.kpit.com/diagnostics
Als Experte für Fahrzeugdiagnose und Telematik ist die KPIT Technologies GmbH seit knapp 20 Jahren ein kompetenter Entwicklungspartner für Fahrzeughersteller und deren Zulieferer. Dabei setzt KPIT auf die aktuellsten internationalen Automotive-Standards und ist aktives Mitglied in Standardisierungsgremien der ASAM. Deren Produktfamilie Diagnostic and Connectivity Platform deckt nahezu alle möglichen Anwendungsfälle der Off-Board-Diagnose in Entwicklung, Produktion und Service ab. Neben den auf unseren Produkten basierenden Systemlösungen bietet KPIT Consulting, Engineering-Dienstleistungen und Trainings an. Weltweit arbeiten aktuell etwa 200 Mitarbeiter an verschiedenen Standorten im Geschäftsbereich Diagnose, dessen Hauptsitz in München ist.
Über KPIT
Das globale Unternehmen KPIT ist auf Technologielösungen in den Bereichen der Automobil- und Transportindustrie, Industrielle Fertigung und Energie- und Versorgungswirtschaft spezialisiert. Mit einem Umsatz von über 490 Millionen USD, wurde die KPIT von führenden Analysten und Beratungsunternehmen als einer der am schnellsten wachsenden Unternehmen anerkannt. Gemeinsam mit seinen Kunden und Partnern entwickelt das Unternehmen Technologien, die zu einer sauberen, grüneren und intelligenteren Welt, sowie mehr Nachhaltigkeit und Effizient beitragen.
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
