Gesetzliche On-Board-Diagnose und ODX

Transkript

1 Gesetzliche On-Board-Diagnose und ODX Klaus Beiter, Christoph Rätz, Oliver Garnatz Abstract Legislated On-Board-Diagnostics is based on the requirement to monitor emission related systems during the complete life cycle of a vehicle. There have been many standardization activities since the CARB released OBD-I in The latest standard under creation is WWH-OBD. This paper gives an overview of the available OBD standards with their inter-relationships and their connection to other important diagnostic standards. ODX (Open Diagnostic Data Exchange) is a well accepted and widely used standard for the description of ECU and vehicle diagnostics. One part of the ODX standard (ISO ) is dedicated to the description of OBD data. This article will briefly introduce ODX and present the underlying design principles of the OBD ODX description. Differing requirements of the data description, based on different use cases (parameterization of diagnostic testers, diagnostic software generation, diagnostic software validation) will be analyzed and discussed. WWH-OBD has now been implemented in its first vehicle platforms. Questions arising from the WWH-OBD introduction, together with implementation approaches, will complete the article. Kurzfassung Die gesetzliche On-Board-Diagnose basiert auf der Anforderung, Abgasvorschriften nicht nur zum Zeitpunkt der Zulassung, sondern über den gesamten Lebenszyklus eines Fahrzeugs hinweg zu überwachen. Seit Verabschiedung der OBD-I Norm im Jahr 1988 durch die CARB gab es weltweit mehrere Standardisierungsaktivitäten, die in dem gerade entstehenden WWH-OBD Standard münden. Der Beitrag gibt einen Überblick über die vorhandenen OBD-Standards und ihre Beziehungen zueinander und zu anderen Diagnosestandards. ODX (Open Diagnostic Data Exchange) ist ein heute weit verbreiteter Standard zur Beschreibung der Steuergeräte- bzw. Fahrzeugdiagnose. Ein Teil des ODX- Standards (ISO ) ist der Beschreibung von OBD-Daten gewidmet. Der Beitrag wird eine kurze Übersicht über ODX geben und die zugrunde liegenden Designprinzipien der OBD ODX-Beschreibung vorstellen. Die unterschiedlichen Anforderungen an die Datenbeschreibung in Abhängigkeit von der geplanten Verwendung (Testerparametrierung, Steuergerätesoftware-Generierung, Steuergerätesoftware- Validierung) der Daten sollen anhand des OBD-Anwendungsfalls aufgezeigt und diskutiert werden. WWH-OBD wird in ersten Fahrzeugprojekten umgesetzt. Die hierbei auftretenden Fragestellungen und Lösungsansätze runden den Beitrag ab.

2 1. Gesetzliche On-Board-Diagnose 1.1 OBD-I Ausgangspunkt für die Entwicklung der OBD war die Forderung der CARB (Californian Air Resources Board), dass alle ab 1988 zugelassenen Fahrzeuge über eine selbständige Überwachung der abgasrelevanten Systeme verfügen sollten. Dies erfordert das Detektieren der Verschlechterung des Abgasverhaltens mit einer entsprechenden Meldung an den Fahrer. OBD-I fasst erstmals die in diesem Zusammenhang erforderlichen Anforderungen an die On-Board-Diagnose zusammen. OBD-I ist relativ einfach aufgebaut und beschränkt sich auf die Überwachung der Lambdasonde, der Abgasrückführung, Kraftstoffzufuhr und die Motorsteuerung. Fehler konnten als Blinkcodes am Kombiinstrument abgelesen werden. Der Fahrzeugzugang wurde im Rahmen von OBD-I nicht standardisiert, so dass hersteller- und baureihen-spezifische Lösungen entstanden. 1.2 OBD-II 1994 macht die CARB die OBD-II Norm zur Vorschrift für Fahrzeuge, die ab 1996 in Kalifornien zugelassen werden sollen. Für diese Fahrzeuge fordert die Norm, die Ausstattung mit einem OBD-System, welches die abgasrelevanten Komponenten ständig überwacht und dass Fehler, die zu erhöhten Schadstoffemissionen führen, in einem vorgegebenen Format abgespeichert werden müssen. Schwere Fehler müssen dem Fahrer mittels der MIL (Malfunction Indicator Lamp) angezeigt werden. Ebenso sind Regeln definiert, die das Ausschalten der MIL und das Löschen der Fehlerspeichereinträge beschreiben, wenn der Fehler während eines definierten Zeitraumes nicht mehr auftritt. Mit dem sogenannten Scan-Tool kann der Zustand des Fahrzeuges bzgl. seines Emissionsverhaltens ausgelesen werden, um z. B. die benötigten Informationen zur Fehlerbehebung zu ermitteln. Dies sind Steuergerätewerte (PIDs), die Fehlercodes (DTCs) und die sogenannten Umgebungsdaten zum Zeitpunkt des Fehlerauftretens (Freeze-Frames). Eine wichtige Frage beim Auslesen des Fehlerspeichers betrifft die Testabdeckung. OBD-II definiert in diesem Zusammenhang den Begriff der Readiness. Sie drückt aus, ob ein bestimmter Fehler auftreten konnte, d.h. ob die Situation (bzw. der Test), die den Fehler erkennt, seit dem letzten Löschen des Fehlerspeichers schon durchlaufen wurde. Die Readiness kann vom Scantool als Bitmaske ausgelesen werden und falls erforderlich können fehlende Tests mit dem Scantool gestartet werden. OBD-II definiert in jeweils eigenständigen Dokumenten den OBD-Stecker (SAE J1962), das OBD-Scan-Tool (SAE J1978), die Diagnosedienste (SAE J1979), die Fehlercodes (SAE J2012) und die Data Link Security (SAE J2186). Folgende Bussysteme sind für die OBD-Kommunikation möglich: ISO K-Line ISO CARB ISO CAN SAE J1850 PWM und VPWM

3 1.2 EOBD Die EOBD-Norm ist das europäische Pendant zu OBD-II. Die Norm wird erstmals für PKW mit Ottomotor ab Modelljahr 2001 vorgeschrieben. Die Anwendung der Regelung wurde später auf PKWs mit Dieselmotoren ab Modelljahr 2004 ausgeweitet. Die EOBD-Norm bezieht sich - wie auch die amerikanische OBD-II-Norm - auf mehrere ISO-Dokumente, in denen die Anforderungen an die technische Umsetzung festgeschrieben sind. Darüber hinaus definiert EOBD wie auch OBD-II die Abgas- Grenzwerte, die von den Fahrzeugen eingehalten werden müssen. Die ISO- Dokumente sind in Tabelle 1 mit den jeweils entsprechenden Dokumenten der SAE aufgelistet. Da ISO und SAE auf dem Gebiet der On-Board-Diagnose zusammenarbeiten, sind die Dokumente inhaltlich weitestgehend identisch. ISO-Dokument SAE-Dokument Allgemeine Informationen ISO Keine Entsprechung Begriffe, Definitionen, Abkürzungen ISO SAE J1930 Diagnosestecker ISO SAE J1962 Externes Testgerät ISO SAE J1978 Diagnosedienste (Modes) ISO SAE J1979 Fehlercodes ISO SAE J2012 Data Link Security ISO SAE J2186 Tabelle 1: OBD-Dokumente der ISO mit den jeweiligen Entsprechungen der SAE. Das zentrale Dokument ist die Beschreibung der OBD-Modes in ISO Das Dokument definiert die Services, die ein Scan-Tool ausführen kann und die von OBD-relevanten Steuergeräten zu unterstützen sind. Vorgesehen sind 10 Modes (Diagnosedienste). Neben dem Zugriff auf den Fehlerspeicher (Mode 02, 03, 04, 07, 0A) sind das Auslesen von Steuergerätewerten (Mode 01, 09) das Auslesen der Testergebnisse der ständigen Überwachungsfunktionen (Mode 05 oder Mode 06) und Stellgliedtests (Mode 08) vorgesehen. Ein typischer OBD-Test-Ablauf kann folgendermaßen aussehen: Mit Mode 09 werden Fahrzeugidentifikationsdaten ausgelesen Danach kann mit Mode 01 der Zustand der MIL, die Anzahl abgelegter Fehler und der Readiness-Code abgefragt werden. Mit dem Mode 03 und 07 können dann die als aktiv bzw. vorläufig eingestuften Fehler ausgelesen werden. Zusatzinformationen (Freeze Frames) für die Fehlerbehebung können mit Mode 02 ausgelesen werden. Falls zur Fehlerbehebung OBD-Routinen ausgeführt werden müssen, können diese durch das Testgerät mittels Mode 08 gestartet werden. Nach der Fehlerbehebung kann der Fehlerspeicher mit Mode 04 gelöscht werden. Die Subfunktionen zu den Modes 01, 02, 05, 06, 08 sind im Anhang des Dokumentes ISO in Ihrer Struktur definiert. Nicht jedes Steuergerät muss alle hier aufgeführten PIDs, TIDs, MIDs unterstützen. Wenn das Steuergerät die Subfunktionen unterstützt, müssen sie aber den Definitionen in ISO entsprechen. Dasselbe gilt auch für die Fehlercodes (DTCs) aus dem Dokument ISO , das sowohl deren Aufbau als auch die konkreten DTCs definiert. Alle Fehlercodes wer-

4 den als 2-Byte-Werte übertragen und als fünfstellige alphanumerische Werte am Tester angezeigt. In dem fünfstelligen Fehlercode ist folgende Information codiert: 1. Stelle: Gibt an, welchem Bereich der DTC zugeordnet ist: Powertrain (P), Fahrwerk (C), Karosserie (B) oder Bussystem (U) 2. Stelle: Gibt an, wer den DTC festgelegt hat: ISO-15031/SAE 2012, oder der Fahrzeughersteller. 3. Stelle: Gibt für die durch die ISO/SAE definierten Codes an, welchem Subsystem der DTC zugeordnet ist: Einspritzsystem (1,2), Zündung (3), Abgasrückführung (4), Geschwindigkeits- und Leerlaufregelung (5), Steuergeräteinterne Fehler (6), Getriebe (7,8). Die 4. und 5. Stelle werden zur weiteren Klassifizierung der Fehler verwendet. 1.3 WWH-OBD Im Rahmen der Vereinten Nationen wird gegenwärtig an einem Standard zur weltweiten Vereinheitlichung der Diagnose zur Überwachung des Emissionsausstoßes gearbeitet. Die Anforderungen sind in der Global Technical Regulation 5 (GTR 5) zusammengefasst. Die Norm ist zunächst auf den Nutzfahrzeug-Bereich beschränkt, soll aber später auf andere Fahrzeugbereiche ausgedehnt werden. Diese sogenannte World-Wide-Harmonized On-Board-Diagnostics (WWH-OBD) soll mittel- und langfristig die regionalen Standards ersetzen und ablösen. Zunächst werden die Anforderungen an die Abgaskontrolle und die Diagnosekommunikation festgelegt. Die Festlegung der Grenz-/Schwellenwerte obliegt vorerst noch den regionalen Behörden. Später sollen auch diese Grenzwerte harmonisiert werden. Die Ausarbeitung der technischen Rahmenbedingungen des Standards erfolgt im Rahmen der ISO (TC22 SC3) in dem Standard ISO 27145, der die bestehenden regionalen OBD- Standards (z.b. ISO 15031) ablösen soll. Um einen möglichst reibungslosen Übergang zu ermöglichen, wird als Kommunikationsbasis zunächst die Diagnose über CAN vorgesehen. Langfristig sieht ISO aber die Diagnose über IP (Ethernet oder sogar drahtlos) vor. Heute sind für die On-Board-Diagnose bei Nutzfahrzeugen die beiden Optionen ISO und J verbreitet. Beides sind CAN-basierte Protokolle. Mit der Einführung der GTR5 wird die CAN-basierte Diagnose gemäß ISO über ISO15765 und J möglich sein oder aber die TCP/IP basierte Variante gemäß ISO über ISO ISO definiert die Vehicle On-Board-Diagnostic (VOBD) bestehend aus dem VOBD System (fahrzeugseitige Implementierung), dem Datenzugriff und den OBD- Daten. Die fahrzeugseitige Implementierung kann in einem Steuergerät oder über mehrere Steuergeräte verteilt erfolgen. ISO besteht aus sechs Teilen, die in der folgenden Tabelle 1 im Überblick dargestellt sind. Die Dokumente haben momentan den Status eines Draft International Standard (DIS). Beschreibung / Inhalt Dokument Allgemeine Information und Definition der Use Cases ISO Definition der Diagnosedaten ISO Definition der Diagnosedienste ISO Kommunikation zwischen Fahrzeug und externem ISO Testgerät

5 Tests bzgl. der Einhaltung der Norm ISO Externes Testgerät ISO Tabelle 2: Dokumente des Standards ISO WWH-OBD nutzt im Gegensatz zu OBD-II keine speziell für die On-Board-Diagnose definierten Services, sondern bedient sich der in ISO festgelegten Unified Diagnostic Services (UDS), die mittlerweile bei vielen Fahrzeugherstellern auch für die Hersteller-spezifische Diagnose verwendet werden. Die für die WWH-OBDkonforme Diagnose geforderten UDS-Services sind: Service 0x14 ClearDiagnosticInformation zum Löschen des Fehlerspeichers. (Vgl. ISO Mode 04) Service 0x19 ReadDTCInformation zum Auslesen des Fehlerspeichers und der Umgebungsdaten (Snapshot-Record und Extended-Data-Record). (Vgl. ISO Mode 03, 07, 02). Service 0x22 ReadDataByIdentifier zum Auslesen der Steuergerätedaten und Testergebnisse (Vgl. ISO15031 Mode 01, 06 und 09) Service 0x31 RoutineControl zum Ausführen von Routinen (Vgl. Mode 08). Die Bereiche der zu unterstützenden Subfunktionen ergeben sich aus den Datendefinitionen aus ISO Dieses Dokument schlägt die Brücke zwischen WWH- OBD einerseits und OBD-II/EOBD andererseits, denn es verweist für die Definition der Steuergerätedaten und DTCs auf die entsprechenden SAE Dokumente SAE J1979-DA und SAE J2012-DA. 2 ODX 2.1 Grundlagen ODX wurde im Rahmen einer ASAM/ISO Arbeitsgruppe seit 2003 standardisiert. Die Notwendigkeit für die ODX-Entwicklung ergab sich aus der mangelnden Akzeptanz der damals bestehenden Standards zur Beschreibung von Diagnosedaten. Der Austausch von Diagnosedaten über Prozessgrenzen hinweg war deshalb teilweise mit erheblichem Aufwand verbunden. Ein wichtiges Ziel der ODX-Standardisierung ist die Unterstützung des Single- Source-Prinzips. Abbildung 1 veranschaulicht zwei Aspekte: Einerseits sollen die Daten in unterschiedlichen verarbeitenden Werkzeugen eingesetzt werden können, andererseits werden die Daten ohne Anpassung auch in unterschiedlichen Unternehmensbereichen weiterverarbeitet. Bei der Entwicklung von ODX wurden zahlreiche Anwendungsfälle aus den unterschiedlichen Unternehmensbereichen berücksichtigt, so dass ODX-basierte Prozesse nach dem Single-Source-Prinzip ermöglicht werden. Der Standard besteht aus folgenden Komponenten: Kernstück des Standards ist ein UML-Modell, das die Datenstruktur definiert. Abgeleitet aus dem UML-Modell ist das XML-Schema, welches die XML- Struktur der Diagnosedaten definiert. XML-Instanzen können mit

6 Abbildung 1: Das Single-Source-Prinzip: Oben Identische Daten in unterschiedlichen verarbeitenden Werkzeugen. Unten: Identische Daten in verschiedenen Unternehmensbereichen. entsprechenden Werkzeugen automatisch gegen die Schema-Definition validiert werden. Die semantische Bedeutung der Datenstrukturen ist in einer textuellen Beschreibung festgelegt, die unter anderem die Parametrierung der ODXbasierten Testsysteme festlegt. Da sich nicht alle erforderlichen semantischen Einschränkungen im UML- Modell bzw. im XML-Schema abbilden lassen, werden zusätzliche semantische Einschränkungen in den sogenannten Checker-Regeln definiert. Standardkonforme ODX-Daten müssen sowohl valide im Sinne des XML-Schemas, als auch konform zu den Checker-Regeln sein. Letzteres wird in der Praxis durch den Einsatz von ODX-Checkern erreicht. Der Fokus der Standardisierungsaktivitäten lag auf der Parametrierung der Diagnosetester. Das Datenmodell in der Version ist aus sieben Teilmodellen aufgebaut, die sich an dieser Ausrichtung orientieren (Abbildung 2). Die unteren drei Teilmodelle bilden mit der Definition der Diagnosedienste, den Kommunikationsparametern und der Beschreibung der Fahrzeugzugänge das Herzstück des Standards. Sie bilden gleichzeitig den minimalen Umfang, der für die Kommunikation eines Testgerätes mit einem oder mehreren Steuergeräten inklusive der Dateninterpretation erforderlich ist. Die oberen vier Teilmodelle sind der Beschreibung der Flash-Daten, den Steuergerätekonfigurationsdaten, der funktionsorientierten Diagnose und den sogenannten Multiple ECU Jobs vorbehalten. Ihre Verbreitung und Bedeutung ist niedriger im Vergleich zu den erst genannten Teilmodellen. ODX wurde 2008 als ISO-Standard verabschiedet. Die erste Version des Standards wurde 2004 vom ASAM als ODX herausgegeben. Zwischen dieser und der ISO-Ausgabe lagen zwei weitere Releases, in die Korrekturen und auch die Erfahrungen aus Projekten in Form von Verbesserungsvorschlägen und Erweiterungen eingeflossen sind.

7 Abbildung 2: Aufbau des ODX-Modelles Die ODX-Version wurde 2005 herausgegeben und ist heute die am weitesten verbreitete, die auch von den verfügbaren Softwarewerkzeugen am besten unterstützt ist. Um der zunehmenden Bedeutung der On-Board-Diagnose gerecht zu werden, wurde im Rahmen der ISO-Aktivitäten die ODX-Spezifikation um einen zweiten Teil ergänzt, der Richtlinien für die Erstellung der OBD-relevanten Diagnoseinhalte festlegt. Der Standard hat die Abstimmung zum Draft International Standard (DIS) bereits bestanden. Das Release als ISO-Standard steht noch aus. 2.2 ISO : OBD-II in ODX Ziele Ziel der Standardisierung von OBD-II in ODX (ISO ) ist es, die für die Entwicklung eines generischen MVCI-basierten Scan-Tools benötigten Festlegungen zu treffen. Dies sind insbesondere: Festlegung der Layer-Hierarchie (DIAG-LAYER) Definition der benötigten Kommunikationsparameter (COMPARAM-SPEC) Definition der VEHICLE-INFO-SPEC Definition der Service-Struktur (DIAG-SERVICEs) Festlegung ausgezeichneter SHORT-NAMEs und LONG-NAMEs Definition von SEMANTIC-Werten für Services und die zugehörigen Daten (DIAG-SERVICEs und TABLEs) Definition der ODX IDs Exemplarische Festlegung der PIDs und DTCs

8 Die Einhaltung des Standards sowohl bei der Erstellung der ODX-Daten als auch bei der Implementierung des Scan-Tools ermöglicht die Austauschbarkeit. ISO stellt also quasi den Vertrag zwischen der Scan-Tool-Implementierung und den OBD-ODX-Daten dar. Der Teilstandard bezieht sich auf ODX Er besteht aus einem Text-Dokument mit ODX-Beispielen, stellt aber keine vollständige OBD-Beschreibung in ODX dar. Aus dem Standard können Checker-Regeln abgeleitet werden, diese sind aber nicht im Standard definiert. ISO ist somit bzgl. Umfang und Inhalt mit den ODX-Autorenrichtlinien vergleichbar, die sich bei vielen Firmen etabliert haben Struktur des Modells Die OBD-Kommunikation basiert auf der funktionalen Adressierung. Alle abgasrelevanten Steuergeräte werden deshalb im ODX-Modell in einer FUNCTIONAL- GROUP mit dem SHORT-NAME FG_OBD_II zusammengefasst. Da die OBD- Spezifikation nicht nur die Kommunikation über CAN, sondern auch über K-Line, und SAE J-1850 vorsieht, gibt es für jeden der genannten Physical-Layer einen ODX- PROTOCOL-Layer, der die entsprechenden Kommunikationsparameter referenziert, die auch jeweils in einer Datei zusammengefasst sind. Zwischen PROTOCOL und COMPARAM-SPEC besteht hier einen 1:1-Beziehung. Die FUNCTIONAL-GROUP FG_OBD_II erbt von allen Protokollen. Der Start der Kommunikation zwischen Tester und Steuergerät erfolgt am MVCI- System durch das Öffnen eines LOGICAL-LINK. Der LOGICAL-LINK ist in der VEHICLE-INFO-SPEC VI_OBD_II definiert und enthält als wesentlichen Bestand- Abbildung 3: Schematische Darstellung der OBD-Modellierung gemäß in ODX. CPS=COMPARAM-SPEC; ES=ECU-SHARED-DATA; PR=PROTOCOL; FG=FUNCTIONAL-GROUP; LL=LOGICAL-LINK.

9 teil im Fall von OBD einen Verweis auf die FUNCTIONAL-GROUP FG_OBD_II und auf einen der oben definierten PROTOCOL Layer. Insgesamt sind also für die vier Physical-Layer vier LOGICAL-LINKS erforderlich. Ihre SHORT-NAMEs und LONG- NAMEs sind im Standard festgelegt. Auf Basis dieser Festlegung kann das Testsystem die Kommunikation auf dem gewünschten Physical-Layer starten. Redundanzvermeidung Die OBD-II-Modes werden in ODX als DIAG-SERVICEs beschrieben. Der ODX- Standard sieht unterschiedliche Mechanismen zur Vermeidung von Redundanzen in den Daten vor: Die sogenannte Value-Inheritance ist an die Vererbung in der Objektorientierung angelehnt. DIAG-SERVICEs (aber auch andere Elemente) können in höheren Schichten definiert werden und sind bei Erstellung einer Vererbungsbeziehung auf diese Schicht auch in den sogenannten erbenden Schichten sichtbar (d.h. ausführbar). Im Gegensatz zur Value-Inheritance, die eine generelle Übernahme der Elemente aus der erbenden Schicht zur Folge hat, steht mit dem Import- Mechanismus ein weiteres Mittel bereit, mit dem selektiv einzelne Elemente aus einer bestehenden Datenbeschreibung ausgewählt werden können. Im Fall von OBD werden die Konzepte eingesetzt, um die wiederholte identische Definition der Modes (Dienste) in den vier PROTOCOL-Layern zu vermeiden. Hierzu wird die Definition der DIAG-SERVICEs in ECU-SHARED-DATA Layer ausgelagert, von denen die vier PROTOCOL-Layer erben. Die geerbten Dienste aus den ECU- SHARED-DATA sind somit nach Öffnen des entsprechenden LOGICAL-LINKs für jeden der vier PROTOCOL-Layer sichtbar d.h. ausführbar. Da Mode 05 für OBD auf CAN nicht vorgesehen ist, ist eine zusätzliche Aufteilung der Modes und 06-0A einerseits und Mode 05 andererseits in jeweils eine ECU-SHARED-DATA erforderlich. Der PROTOCOL-Layer für OBD on CAN erbt direkt von dem erstgenannten, die übrigen PROTOCOL-Layer erben von dem letztgenannten ECU-SHARED-DATA- Layer. Abbildung 3 zeigt schematisch den Aufbau des ODX-Modells mit den Zuordnungen zu den ODX-Kategorien und den Beziehungen der wichtigsten Elemente untereinander. Die linke Hälfte der Abbildung führt die Modellierung für den Fall der Diagnose auf CAN im Detail aus, die rechte Seite deutet die Modellierung für die drei anderen Physical-Layer schematisch an. Die Modellierung hat zur Folge, dass die Service- Definitionen komplett in den ECU-SHARED-DATAs erfolgt. Die PROTOCOL- und FUNCTIONAL-GROUP-Dateien hingegen enthalten im Wesentlichen die Verweise auf die entsprechenden Kommunikationsparameter und die Informationen über die vererbenden Layer nicht aber Diagnoseinhalte. Die Unterstützung für DoIP könnte in dem Modell durch Hinzufügen des entsprechenden Tripels aus COMPARAM-SEPC, PROTOCOL und LOGICAL-LINK integriert werden. Diagnosedienste Für die Beschreibung der DIAG-SERVICEs (Modes) kommen in ODX zwei prinzipiell unterschiedliche Varianten in Frage: a) Erstellung eines DIAG-SERVICEs für jede gültige Kombination aus SID (Mode) und Subfunction. b) Einmalige generische Beschreibung des DIAG-SERVICEs mit einer TABLE, welche die Definition der spezifischen Daten für die Subfunctions enthält. Abbildung 4 zeigt die beiden Möglichkeiten schematisch anhand des UDS-Services 0x22 für die zwei Identifier 0x0001 und 0x002. Die Varianten unterscheiden sich

10 Abbildung 4: Alternativen zur Beschreibung von DIAG-SERVICEs in ODX. Links: Möglichkeit a) ohne Verwendung des Elementes TABLE. Rechts: Variante b) unter Verwendung des Elementes TABLE. zwar in der ODX-Datei deutlich, aus Sicht der Applikation müssen sie zu identischem Verhalten führen. In kommt für alle Services die Alternative b) zum Einsatz, denn sie hat folgende Vorteile: Die Service-Beschreibung kann vollständig von der Beschreibung der transportierten Daten getrennt werden. Wenn mehrere Services auf den gleichen Daten operieren, so können Erweiterungen (bspw. des DTC-Umfanges oder des PID-Umfanges) an zentraler Stelle gepflegt werden. Die Beschreibung nach Alternative b) ist deutlich kompakter, da der XML- Overhead für die n-fache Definition von DIAG-SERVICEs, REQUESTs, RES- PONSEs etc. entfällt. Mit zunehmender Anzahl von Subfunctions wird der Effekt größer. Vor dem Hintergrund der hohen Anzahl an PIDs, MIDs und TIDs im OBD-II Standard resultiert die Modellierung der Modes gemäß Variante b) in Dateigrößen, die etwa halb so groß sind verglichen mit der Modellierung nach Variante a) Eine Besonderheit in der Definition des OBD-Modes 0x01 ist die strukturelle Abhängigkeit einiger PIDs von der Unterstützung der PIDs 0x13 bzw. 0x1D. Ein Beispiel hierfür sind die PIDs 0x14-0x24. Die Unterscheidung trägt unterschiedlichen Powertrain-Layouts (Zuordnung der Sauerstoffsensoren zu den Bänken) Rechnung. Für den OBD-Test bedeutet das, dass nach dem Ausführen des Modes 0x01 mit dem PID 0x00 je nach erhaltener Steuergeräteantwort die weiteren Steuergeräte- Antworten auf konkrete PID-Anfragen unterschiedlich decodiert werden müssen. Zur Beschreibung dieses Merkmals des Modes 0x01 können die in ODX eingeführten SUB-COMPONENTs verwendet werden. SUB-COMPONENTs sind neben den Steuergeräte-Varianten (ECU-VARIANTs) ein zusätzlicher Mechanismus, um eine Varianz der Steuergeräte-Beschreibung innerhalb eines ODX-Layers auszudrücken. Für die SUB-COMPONENTs gibt es ebenfalls einen Identifikationsmechanismus, der

11 an den Variantenidentifikationsmechanismus angelehnt ist. Eine Applikation kann somit die zur Identifikation von SUB-COMPONENTS erforderlichen Services mit den geforderten Kriterien (Parameterwerte) auslesen. Je nach Antwort können dann die im Folgenden ausführbaren Services/Daten durch die Applikation entsprechend gefiltert werden. 3 Erfahrungen und Konsequenzen Die OBD ODX-Beschreibung (ISO ) verwendet konsequent die durch die ODX-Spezifikation (ISO ) verfügbaren Mechanismen zur Redundanzvermeidung und zum modularen Aufbau der Daten. Hierdurch wird ein hoher Grad an Änderungsfreundlichkeit erreicht. Die im Rahmen des Standards vorgegebenen Regeln sind auf die optimale Parametrierung eines Diagnose-Testers oder Scan-Tools zugeschnitten. Neben der Testerparametrierung sind aber auch die Code-Generierung der Diagnosesteuergerätesoftware und deren Validierung weitere wichtige Verwendungsszenarien, deren Unterstützung im Folgenden betrachtet wird. Die Anforderungen an die Datenqualität sind für die Code-Generieung und die Software-Validierung höher als für die Testerparametrierung, da die Daten in beiden Fällen Spezifikationsqualität aufweisen müssen. Die Datenqualität ist entscheidend für den Abdeckungsgrad der automatisch erzeugten Software und die Aussagekraft der Tests im Rahmen der automatisierten Validierung. Vor diesem Hintergrund können ODX-Daten die gemäß für die generische Testerparametrierung erstellt wurden, aus den folgenden Gründen nur eingeschränkt zur Code-Generierung oder Softwarevalidierung herangezogen werden: Die generische Testerbedatung eines Scantools muss alle in ISO15031 vordefinierten Datendefinitionen (PID, MID, TID, DTC) komplett enthalten, weil das Scantool mit allen erlaubten Datenkonstellationen sinnvoll umgehen muss. Die Steuergerätespezifikation hingegen darf nur die von dem spezifizierten Steuergerät tatsächlich unterstützten Daten beschreiben. ISO beschreibt die OBD-Daten in einer FUNCTIONAL-GROUP. Ein einzelnes Steuergerät wird in ODX durch ein BASE-VARIANT beschrieben. Eine BASE-VARIANT für eine OBD-Bedatung muss folglich von der FUNCTIONAL-GROUP erben. Die vom Steuergerät nicht unterstützten Services und Daten müssten deaktiviert werden. Die Verwendung dynamischer TABLEs in den Steuergeräteantworten ist aus Sicht der Testerparametrierung ideal, für die Steuergerätespezifikation aber nicht ausreichend, weil nicht ausgedrückt werden kann, dass in den Steuergeräteantworten nur die im Request angefragten Daten übertragen werden dürfen. ODX sieht hierfür zwar einen Mechanismus vor (MATCHING-REQUEST), er kann aber in der konkreten Situation nicht verwendet werden, da bis zu 6 PIDs in einer Antwort übertragen werden können. Die Modellierung des Powertrain-Layouts mit SUB-COMPONENTs - wie oben beschrieben - wird der Testerparametrierung gerecht, weil zur Laufzeit entschieden werden kann, welche Teile des Modells gültig sind. Die Information, für welche SUB-COMPONENT Code erzeugt werden soll, also welches Powertrain-Layout vorliegt, muss entweder dem Code-Generator außerhalb von ODX mitgeteilt werden, oder die ODX-Daten müssen entsprechend aufbereitet werden.

12 Die Verwendung der OBD-II Daten in ISO impliziert auch die Übernahme einiger OBD-II-Konzepte wie etwa die Ermittlung der verfügbaren/unterstützten PIDs durch Anfrage der Supported PIDs 0x00, 0x20 etc., deren Steuergeräteantwort die unterstützten PIDs in dem entsprechenden PID-Bereich (0x01-0x1F, 0x21-0x3F, etc.) enthält. Die grundlegenden Design-Entscheidungen der OBD-ODX-Modellierung können auch für die Modellierung des WWH-OBD-Standards ISO übernommen werden. Änderungen betreffen im Wesentlichen die ECU-SHARED-DATA mit den Service-Definitionen, denn die OBD-II Modes müssen durch die entsprechenden UDS- Services ersetzt werden. Die für OBD-II zulässigen K-Line-Protokollle und SAE J1850 entfallen. An deren Stelle tritt die Diagnose über IP. Die rechte Seite der Abbildung 3 müsste also durch PROTOCOL, LOGICAL-LINK und COMPARAM- SPEC für DoIP ersetzt werden. Da ISO die Definition der Daten aus SAE J1979 und SAE J2012 in ECU-SHARED-DATA-Layern definiert, könnten diese weitestgehend übernommen werden, allerdings müssen einzelne Datenbeschreibungen der jeweils aktuellen Version der SAE J2012-DA und SAE J1979-DA angepasst werden. Die Einführung von WWH-OBD für den Nutzfahrzeugbereich ist für Fahrzeuge ab Modelljahr 2013 gefordert. Deshalb beschäftigen sich die Entwicklungsabteilungen der Fahrzeughersteller seit geraumer Zeit mit diesem Thema, das sie vor neue Herausforderungen stellt. Es ist davon auszugehen, dass WWH-OBD nach ISO in der Praxis zunächst auf die CAN-Kommunikation beschränkt bleiben wird. So kann zunächst die WWH-OBD-Diagnose eingeführt werden, in einem späteren Schritt kann dann ggf. auch der neue Physical-Layer unterstützt werden. Risiken bei der Einführung neuer Standards und Technologien lassen sich durch die isolierte Betrachtungsweise besser einschätzen und minimieren. Abhängig von den potentiellen Absatzmärkten ist eine nicht zu unterschätzende Vielfältigkeit an unterschiedlichen Fehlerspeicherimplementierungen notwendig, die je nach regionalen Anforderungen zum Einsatz kommen müssen. So wird auf dem US- Markt die Diagnose über J1939 bzw. OBD-II noch einige Zeit gesetzt sein. Für Fahrzeuge die auch auf dem europäischen Markt verkauft werden sollen, muss ebenfalls der Zugang und die Diagnose gemäß ISO bzw. ISO vorgesehen werden. Neben diesen Varianten ist die Enhanced-Diagnose für die Serviceorganisation eine weitere Ausprägung. Es wird also nicht selten vorkommen, dass man alle vier Implementierungen auf einem Steuergerät vorfindet. Hier stellt sich auch die Frage, wie die Fehlercodes der Herstellerdiagnose in die standardisierten Codes abgebildet werden. In ODX sind die unterschiedlichen Ausprägungen durch entsprechende DTC-DOPs beschreibbar, die je nach Diagnoseprotokoll für die Kommunikation herangezogen werden können. Die Umsetzung von OBD-II und WWH-OBD zeigt, wie verschiedene Standards kombiniert werden können. Die Integration dieser Technologien hat gerade erst begonnen. Die Zukunft wird zeigen, wie sich die Themen WWH-OBD, OBD über ODX und DoIP weiter entwickeln werden.

13 Abkürzungen ASAM CAN CARB DA DoIP DTC EOBD GTR IP ISO KWP MIL MVCI OBD ODX SAE TCP UDS VOBD WWH-OBD Association for Standardisation of Automation and Measuring Systems Controller Area Network Californian Air Resources Board Digital Annex Diagnostics over IP Diagnostic Trouble Code European On-Board-Diagnosis Global Technical Regulation Internet Protocol International Organization for Standardization Key Word Protocol Malfunction Indication Lamp Modular Vehicle Communication Interface On-Board-Diagnosis Open Diagnostic Data Exchange Society of Automotive Engineers Transmission Control Protocol Unified Diagnostic Services Vehicle On-Board-Diagnosis World-Wide-Harmonized OBD Literatur [1] Title 13, California Code Regulations, Section , Malfunction and Diagnostic System Requirements for 2004 and Subsequent Model-Year Passenger Cars, Light-Duty Trucks, and Medium-Duty Vehicles and Engines (OBD II) [2] Richtlinie 98/69/EG des Europäischen Parlamentes und des Rates vom 13. Oktober 1998 über Maßnahmen gegen die Verunreinigung der Luft durch Emissionen von Kraftfahrzeugen und zu Änderung der Richtlinie 70/220/EWG des Rates [3] ISO 15031: Road vehicles - Communication between vehicle and external test equipment for emissions-related diagnostics [4] Global Technical Regulation No. 5: Technical Requirements for On-Board- Diagnostic Systems (OBD) for Road Vehicles [5] ISO : Road vehicles - Implementation of WWH-OBD communication requirements [6] ISO 13400: Road vehicles - Diagnostic communication over Internet Protocol (DoIP) [7] ISO : Road vehicles - Open diagnostic data exchange (ODX) Part 1: Data model specification [8] ISO : Road vehicles - Open diagnostic data exchange (ODX) Part 2: Emissions-related diagnostic data [9] Automatic Validation of Diagnostic Services by use of a Diagnostic Integration and Validation Assistant, ATZ elektronik 6/2008