(openPR) Von Christoph Rätz und Dr. Klaus Beiter, Vector Informatik GmbH, Stuttgart
Das Diagnoseaustauschformat ODX wurde erfolgreich in mehreren Pilotprojekten eingesetzt. Erstmals kam es auch in einem herstellerübergreifenden Fahrzeugprojekt produktiv zum Einsatz. Die Erfahrungen sind viel versprechend. Wie die Praxis zeigt, lässt der Standard ausreichend Spielraum für individuelle Ausprägungen, stellt aber aufgrund seiner Komplexität erhebliche Anforderungen an die eingesetzten Werkzeuge.
Die Entwicklung von Testsystemen zur Diagnose von Steuergeräten erfordert genaues Wissen über Protokoll, Auf bau, Format und Inhalt der Diagnosebotschaften. In der Vergangenheit haben die OEM proprietäre Lösungen entwickelt: Geringfügige Unterschiede in den Anforderungen führten zu spezifischen Diagnose- Testsystemen mit eigenen Datenformaten. Die Diagnosetests konnten nur mit den eigens dafür entwickelten Testern durchgeführt werden. Häufig wird nicht einmal innerhalb eines Unternehmens ein einheitliches Beschreibungsformat verwendet. Mit der Einführung von ODX ändert sich das.
ODX – Standardformat für den Diagnosedatenaustausch
Die ODX-Arbeitsgruppe im ASAM (Association for Standardisation of Automation and Measuring Systems) hat im Jahr 2002 begonnen, einen Standard für die Beschreibung von Diagnosedaten zu formulieren, um einen einfachen Austausch von Diagnosedaten auch über Werkzeuggrenzen hinweg zu ermöglichen. Die erste Version des Diagnose-Standards ODX (Open Diagnostic Data Exchange) wurde im Jahr 2004 veröffentlicht und seither kontinuierlich weiterentwickelt. In erster Linie dient das Datenaustauschformat ODX der Parametrierung von Testsystemen. ODXDaten enthalten alle Informationen, die für die Diagnose von Steuergeräten und Fahrzeugen benötigt werden. Dies ermöglicht die Erstellung von datengetriebenen Diagnoseapplikationen, da sämtliche Informationen über das zu diagnostizierende Steuergerät in Form von ODX-Daten bereitgestellt werden.
ODX besteht im aktuellen Release 2.1 aus sieben Teilmodellen. Sie beschreiben Services (ausführbare Dienste), Jobs (Sequenzen von Services), Kommunikationsparameter, Fahrzeugtopologien, Funktionssichten, Flashdaten und Steuergerätekonfigurationen. Die Teilmodelle lassen sich so kombinieren, dass die in der Praxis auftretenden Anwendungsfälle der Diagnose realisierbar sind.
Ein weiterer ASAM/ISO-Standard (MCD-3D) definiert die Programmierschnittstelle eines Diagnose-Ablaufsystems. Die Datenversorgung der Softwarebibliotheken, die diesen Standard implementieren, basiert auf ODX.
Erfahrungen aus Projekten
Der ODX-Standard stellt einen Baukasten für die Diagnosebeschreibung zur Verfügung. Er unterstützt viele Anwendungsfälle, bietet verschiedene Methoden der Redundanzvermeidung und erlaubt den Anwendern, ihre spezifischen Anforderungen in der Beschreibung der Daten zu berücksichtigen.
Ein zukunftsweisendes Gemeinschaftsprojekt und gleichzeitig Testfall für das Diagnose-Austauschformat war die gemeinsame Entwicklung der neuen Transporter-Generation Sprinter und Crafter der Daimler- Chrysler AG und der Volkswagen AG. Die beiden OEM haben im weltweit ersten herstellerübergreifenden Projekt Diagnosedaten auf Basis des ASAM-Standards ODX ausgetauscht und eingesetzt. Dabei erstellte DaimlerChrysler für die Steuergeräte des Fahrzeugs Diagnosebedatungen auf Basis eines Diagnose-Templates.
VW hat den gesamten Datenbestand übernommen und parametriert damit seine Testsysteme, insbesondere im Kundendienst. Folglich stehen in den Werkstätten optimal abgestimmte Diagnosewerkzeuge zur Verfügung. Die erfolgreiche Realisierung des herstellerübergreifenden Datenaustauschs unterstreicht die Praxistauglichkeit des Standards.
Die Erfahrungen aus weiteren Projekten, in denen Hersteller und Zulieferer Daten austauschen, zeigen, dass die unterschiedlichen Beschreibungsphilosophien zusätzliche Abstimmungen und Richtlinien erfordern. Das spontane Aufsetzen auf der ODX-Spezifikation wird den individuellen Anforderungen der OEM in den meisten Fällen nicht gerecht. Jeder OEM hat seine eigene Diagnosephilosophie, nutzt unterschiedliche Diagnosemöglichkeiten oder bevorzugt bestimmte Beschreibungsweisen. Der ODX-Standard lässt hier weitreichende Freiheiten. Spezifische Ausprägungen müssen deshalb in zusätzlichen Autorenrichtlinien geregelt werden. Die Einhaltung der Bedatungsrichtlinien wird teilweise durch maßgeschneiderte Checker- Werkzeuge sichergestellt. Eine Konsequenz dieser Entwicklung sind OEM-spezifische ODX-Dialekte, die alle konform zur ODX-Spezifikation sind.
Ein Beispiel: Die Beschreibung eines Diagnoseservices und die Interpretation der transportierten Daten im Tester kann in ODX unterschiedlich abgelegt werden. Dennoch führen die alternativen Strukturen zu äquivalentem Verhalten im Laufzeitsystem. Das Erstellen von ODX-Daten ist aufgrund der Komplexität bisher nur einem überschaubaren Kreis von Experten vorbehalten. Immerhin umfasst die aktuelle Spezifikation fast 400 Seiten. Die Anwender möchten sich aber auf ihre eigentliche Aufgabe, nämlich die Entwicklung von Diagnoseanwendungen, konzentrieren und sich nicht mit der Spezifikation und dem Datenformat und seinen Dialekten auseinandersetzen. Mit entsprechender Tool-Unterstützung ist dies möglich. Im Idealfall wird der Anwender nur mit einer diagnosegetriebenen Sicht auf die Daten konfrontiert. Ähnlich wie beim Umgang mit Anwendersoftware aus dem Office-Bereich, ist ein spezielles Know-how über das zugrunde liegende Datenformat dann nicht erforderlich. So ist es auch ohne Expertenwissen möglich, standardkonforme ODX-Diagnosedaten zu erstellen und weiter zu verarbeiten.
Effiziente Unterstützung des Diagnose-Entwicklungsprozesses
Im herstellerübergreifenden Projekt von DaimlerChrysler und VW kam CANdelaStudio von Vector Informatik für die Erstellung der ODX-Daten zum Einsatz. Die CANdela Werkzeugkette unterstützt nicht nur die Datenerstellung, sondern deckt den gesamten Diagnose-Entwicklungsprozess von der Spezifikation über Codegenerierung und Softwarevalidierung bis hin zum Steuergerätetest ab. Im Mittelpunkt steht das Autorenwerkzeug CANdelaStudio, das den Datenimport und -export von und nach ODX unterstützt. CANdelaStudio entkoppelt unterschiedlichste Datenformate und eignet sich deshalb auch für die Migration von Bestandsdaten in das ODX-Format.
Jede Diagnosebeschreibung basiert auf einem Diagnose-Template. Abhängig vom Kontext ist damit sichergestellt, dass nur zulässige und sinnvolle Daten eingegeben werden können. Diagnose-Templates sind herstellerspezifisch und erlauben eine automatische Anpassung des Tools hinsichtlich der OEM-spezifischen Anforderungen. Dieser Ansatz gewährleistet, dass die von CANdelaStudio erzeugten ODX-Daten der herstellerspezifischen Interpretation eines bestimmten Diagnoseprotokolls entsprechen.
Fazit
An ODX führt kein Weg vorbei. Der Markt fordert ein standardisiertes Austauschformat für Diagnosedaten. Es hat sich allerdings gezeigt, dass die Ausprägung unterschiedlicher herstellerspezifischer Dialekte sowie die Verfügbarkeit unterschiedlicher ODX-Versionen den einheitlichen Datenaustausch erschweren.
Vector Informatik ist sich dieser Problematik bewusst und entwickelt Werkzeuge, die eine anwendergerechte Unterstützung von ODX bieten. Wie die Erfahrungen aus diversen Projekten zeigen, setzt die weitere Verbreitung des Standards die Verfügbarkeit leistungsfähiger Werkzeuge voraus.
ODX entwickelt sich weiter. Das ODX-Standardisierungsgremium hat bisher im Jahresrhythmus Erweiterungen vorgestellt und wird auch in Zukunft die Erfahrungen aus der Praxis aufgreifen. Für 2007 ist geplant, ODX auch als ISO-Standard freizugeben.
Vector arbeitet im ASAM-Gremium und innerhalb der ISO aktiv an der Entwicklung der Spezifikation mit. Nicht zuletzt deshalb kann Vector Informatik gut abgestimmte Tools rund um ODX anbieten. Das in Kundenprojekten gesammelte Know-how f ließt kontinuierlich in die Weiterentwicklung der Produkte ein und garantiert anwendergerechte Lösungen für die Steuergeräte-Entwicklung.
Quelle: OEM & Lieferant Jahrbuch 2007
