Gesetzliche On-Board-Diagnose und ODX

Transcription

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 1988. 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 22901-2) 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 ODXStandards (ISO 22901-2) 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ätesoftwareValidierung) 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.
Vector Informatik GmbH > Ingersheimer Str. 24 > 70499 Stuttgart > Tel. 0711-80670-0 > Fax 0711-80670-111 > www.vector.com
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 14230 K-Line
• ISO 9141-2 CARB
• ISO 15765 CAN
• SAE J1850 PWM und VPWM
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 AbgasGrenzwerte, die von den Fahrzeugen eingehalten werden müssen. Die ISODokumente 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.
Allgemeine Informationen
Begriffe, Definitionen, Abkürzungen
Diagnosestecker
Externes Testgerät
Diagnosedienste (Modes)
Fehlercodes
Data Link Security
ISO-Dokument
ISO 15031-1
ISO 15031-2
ISO 15031-3
ISO 15031-4
ISO 15031-5
ISO 15031-6
ISO 15031-7
SAE-Dokument
Keine Entsprechung
SAE J1930
SAE J1962
SAE J1978
SAE J1979
SAE J2012
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 15031-5. 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 15031-5 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 15031-5 entsprechen.
Dasselbe gilt auch für die Fehlercodes (DTCs) aus dem Dokument ISO 15031-6, das
sowohl deren Aufbau als auch die konkreten DTCs definiert. Alle Fehlercodes wer-
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 OBDStandards (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 27145 aber die Diagnose über IP (Ethernet
oder sogar drahtlos) vor.
Heute sind für die On-Board-Diagnose bei Nutzfahrzeugen die beiden Optionen ISO
15765-4 und J1939-73 verbreitet. Beides sind CAN-basierte Protokolle. Mit der Einführung der GTR5 wird die CAN-basierte Diagnose gemäß ISO 27145 über
ISO15765 und J1939-73 möglich sein oder aber die TCP/IP basierte Variante gemäß
ISO 27145 über ISO 13400.
ISO 27145 definiert die „Vehicle On-Board-Diagnostic“ (VOBD) bestehend aus dem
„VOBD System“ (fahrzeugseitige Implementierung), dem Datenzugriff und den OBDDaten. Die fahrzeugseitige Implementierung kann in einem Steuergerät oder über
mehrere Steuergeräte verteilt erfolgen.
ISO 27145 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
Allgemeine Information und Definition der Use Cases
Definition der Diagnosedaten
Definition der Diagnosedienste
Kommunikation zwischen Fahrzeug und externem
Testgerät
Dokument
ISO 27145-1
ISO 27145-2
ISO 27145-3
ISO 27145-4
Tests bzgl. der Einhaltung der Norm
Externes Testgerät
ISO 27145-5
ISO 27145-6
Tabelle 2: Dokumente des Standards ISO 27145.
WWH-OBD nutzt im Gegensatz zu OBD-II keine speziell für die On-Board-Diagnose
definierten Services, sondern bedient sich der in ISO 14229 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 15031 Mode 04)
• Service 0x19 „ReadDTCInformation“ zum Auslesen des Fehlerspeichers und
der Umgebungsdaten (Snapshot-Record und Extended-Data-Record). (Vgl.
ISO 15031 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 27145-2. Dieses Dokument schlägt die Brücke zwischen WWHOBD 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 SingleSource-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 XMLStruktur der Diagnosedaten definiert. XML-Instanzen können mit
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 UMLModell 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 2.2.0 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 22901-1 verabschiedet. Die erste Version des
Standards wurde 2004 vom ASAM als ODX 2.0.0 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.
Abbildung 2: Aufbau des ODX-Modelles
Die ODX-Version 2.0.1 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 22901-2: OBD-II in ODX
Ziele
Ziel der Standardisierung von OBD-II in ODX (ISO 22901-2) 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
Die Einhaltung des Standards sowohl bei der Erstellung der ODX-Daten als auch bei
der Implementierung des Scan-Tools ermöglicht die Austauschbarkeit. ISO 22901-2
stellt also quasi den Vertrag zwischen der Scan-Tool-Implementierung und den
OBD-ODX-Daten dar. Der Teilstandard 22901-2 bezieht sich auf ODX 2.2.0. 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 22901-2 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 FUNCTIONALGROUP mit dem SHORT-NAME „FG_OBD_II“ zusammengefasst. Da die OBDSpezifikation 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 ODXPROTOCOL-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 MVCISystem 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äß 22901-2 in
ODX. CPS=COMPARAM-SPEC; ES=ECU-SHARED-DATA; PR=PROTOCOL;
FG=FUNCTIONAL-GROUP; LL=LOGICAL-LINK.
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 LONGNAMEs 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 ODXStandard 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 ImportMechanismus 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 ECUSHARED-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 01-04 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-DATALayer.
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 ServiceDefinitionen 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
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 22901-2 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 XMLOverhead für die n-fache Definition von DIAG-SERVICEs, REQUESTs, RESPONSEs 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äteAntworten auf konkrete PID-Anfragen unterschiedlich decodiert werden müssen. Zur
Beschreibung dieses Merkmals des Modes 0x01 können die in ODX 2.1.0 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
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 22901-2) verwendet konsequent die durch die
ODX-Spezifikation (ISO 22901-1) 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äß 22901-2 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 22901-2 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.
Die Verwendung der OBD-II Daten in ISO 27145 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 27145 übernommen werden. Änderungen betreffen im Wesentlichen die ECU-SHARED-DATA mit den Service-Definitionen, denn die OBD-II Modes müssen durch die entsprechenden UDSServices 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 COMPARAMSPEC für DoIP ersetzt werden. Da ISO 22901-2 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 27145
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 USMarkt 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 27145 bzw. ISO 15031 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.
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]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
Title 13, California Code Regulations, Section 1968.2, Malfunction and
Diagnostic System Requirements for 2004 and Subsequent Model-Year
Passenger Cars, Light-Duty Trucks, and Medium-Duty Vehicles and Engines
(OBD II)
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
ISO 15031: Road vehicles - Communication between vehicle and external test
equipment for emissions-related diagnostics
Global Technical Regulation No. 5: Technical Requirements for On-BoardDiagnostic Systems (OBD) for Road Vehicles
ISO 27145-1: Road vehicles - Implementation of WWH-OBD communication
requirements
ISO 13400: Road vehicles - Diagnostic communication over Internet Protocol
(DoIP)
ISO 22901-1: Road vehicles - Open diagnostic data exchange (ODX)— Part 1:
Data model specification
ISO 22901-2: Road vehicles - Open diagnostic data exchange (ODX) — Part 2:
Emissions-related diagnostic data
Automatic Validation of Diagnostic Services by use of a Diagnostic Integration
and Validation Assistant, ATZ elektronik 6/2008

Gesetzliche On-Board-Diagnose und ODX

Transcription

Similar documents

Anforderungsschablonen – Der Bauplan Ihrer

Seminarausarbeitung Die Halflife-Engine

Quo Vadis SAE J1939

UMTS

Der Einsteiger

Diagnose über CAN

ISO 15765/4 - DUETTO

Heavy-Duty- Diesel Diagnose