Autor: Firma KPIT Technologies

Modell- und netzwerkbasierte Diagnose Vorgestellt wird

Modell- und netzwerkbasierte Diagnose Vorgestellt wird

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.

Über die KPIT Technologies GmbH

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

Firmenkontakt und Herausgeber der Meldung:

KPIT Technologies GmbH
Adams-Lehman-Str. 109
80797 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com

Ansprechpartner:
Stefanie Köhler
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Für die oben stehende Pressemitteilung ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.
Adaptive AUTOSAR – Eine neue Art des Arbeitens

Adaptive AUTOSAR – Eine neue Art des Arbeitens

Im vorliegenden Beitrag werden einige Themen vorgestellt, die beim Umgang mit der neuen serviceorientierten Architektur (SOA) zu beachten sind. Eine auf Adaptive AUTOSAR basierende SOA ersetzt die klassische AUTOSAR-Plattform nicht 1:1. Es soll hier lediglich gezeigt werden, dass sowohl im technischen Bereich als auch hinsichtlich der Arbeitsprozesse neue Herausforderungen entstehen.

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.

 

 

Firmenkontakt und Herausgeber der Meldung:

KPIT Technologies GmbH
Adams-Lehman-Str. 109
80797 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com

Ansprechpartner:
Stefanie Köhler
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Für die oben stehende Pressemitteilung ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.
Eingebettete Fahrzeugdiagnose

Eingebettete Fahrzeugdiagnose

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

 

Firmenkontakt und Herausgeber der Meldung:

KPIT Technologies GmbH
Adams-Lehman-Str. 109
80797 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com

Ansprechpartner:
Stefanie Köhler
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Für die oben stehende Pressemitteilung ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.
KPIT gibt die neuesten Upgrades seiner Produktfamilie für die Fahrzeugdiagnose bekannt

KPIT gibt die neuesten Upgrades seiner Produktfamilie für die Fahrzeugdiagnose bekannt

Die KPIT Technologies GmbH (europäische Tochtergesellschaft der KPIT Technologies Ltd), ein auf IT-Beratung und Produkt-Engineering spezialisiertes Technologieunternehmen gibt die neuesten Upgardes seiner Produktfamilie für die Fahrzeugdiagnose bekannt. Das Diagnostic & Connectivity-Portfolio von KPIT unterstützt Fahrzeug- und Gerätehersteller, Serviceanbieter und Techniker bei der Remoteüberwachung ihrer Geräte & Maschinen, Entwicklung von Prozessen und bei der Durchführung von Diagnoseabläufen. Die Diagnostic und Connectivity Plattform, die eine Reihe von Tools und Anwendungen umfasst, ermöglicht eine schnelle und genaue Fehlersuche und Fehlerdiagnose was erhebliche Auswirkungen auf die Reduzierung von Ausfallzeiten und Verbesserung der vorausschauenden Wartung und Rentabilität hat.

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

Über die KPIT Technologies GmbH

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.

Firmenkontakt und Herausgeber der Meldung:

KPIT Technologies GmbH
Adams-Lehman-Str. 109
80797 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com

Ansprechpartner:
Stefanie Köhler
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Für die oben stehende Pressemitteilung ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.