| von Dipl.-Ing. Helmut Frank

29661.jpg

Vector Informatik

Die On-Board-Diagnose (OBD) im Fahrzeug ist eine kontinuierliche Selbstüberwachung des Systems. Dabei zeigen Kontrollleuchten unmittelbar die Ergebnisse dieser Selbstüberwachung an. Diese Ergebnisse werden zudem gespeichert und zu diskreten Zeitpunkten, beispielsweise während einer Wartung oder im Rahmen einer Reparatur, mit einem externen Testgerät ausgelesen.

Nachdem einige Automobilhersteller bereits in den 1980er Jahren damit begonnen hatten, solche Konzepte proprietär in Ihren Fahrzeugen zu implementieren, damals noch fast ausschließlich in den elektronischen Motormanagementsystemen, hat zuerst die Umweltschutzbehörde CARB im US-Bundesstaat Kalifornien Zulassungsvoraussetzungen für neue Fahrzeugtypen formuliert, die neben der Einhaltung bestimmter Emissionsgrenzwerte auch einen definierten Umfang an Selbstüberwachungsfunktionen der abgasrelevanten Systeme eines Fahrzeuges vorsahen.

Auf der ursprünglichen OBD-Version aus 1988 aufbauend wurden in den folgenden Jahren in den übrigen US-Bundesstaaten, aber auch in Europa und Japan, gesetzliche OBD-Umfänge definiert. Diese regional gültigen OBD-Versionen bauen zwar alle auf derselben Basis auf und sind teilweise sogar inhaltlich identisch, entstanden aber parallel zur herstellerspezifischen Diagnose und verwenden dazu gänzlich verschiedene Methoden, Services und Parameter.

Weltweite Harmonisierung der Fahrzeugdiagnose

Bei der OEM-spezifischen Diagnose ist in den letzten Jahrzehnten eine fortschreitende Standardisierung bezüglich Transport- und Diagnoseprotokoll zu beobachten. Mittlerweile haben sich auch eine einheitliche Diagnoseschnittstelle zu externen Testgeräten (die 16-polige OBD-Steckdose) und der CAN-Bus als Übertragungsmedium weitgehend durchgesetzt.

Diese Konvergenz hin zu UDSonCAN (Unified Diagnostic Services on CAN) legt es nahe, nun die Diagnoseprotokolle der gesetzlich geforderten und der herstellerspezifischen Diagnoseinhalte zusammen zu führen, was die World Wide Harmonized On-Board-Diagnostics (WWH-OBD) leisten soll. Die Standardisierung findet auf Betreiben der Vereinten Nationen in Form einer Global Technical Regulation (GTR) statt und wird unter anderem in der ISO-Norm 27145 spezifiziert.

Die neue Spezifikation sieht aber auch neue und erweiterte Funktionen vor. So erfolgt eine Einteilung der Fehlercodes nach Schweregrad eines Ausfalls in sogenannte Severity-Klassen A, B1, B2 und C – je nachdem, wie gravierend ihre Auswirkung auf die Abgasqualität ist. Auch wechseln die Fehler der zweithöchsten Klasse B1 in die höchste Klasse A, falls sie nicht in einem definierten und vom System überwachten Zeitrahmen, beispielsweise 200 Betriebsstunden, behoben wurden. Damit abgasrelevante Fehlfunktionen und auch deren Einfluss auf das Abgas für den Fahrer aber auch für Behörden oder Prüforganisationen unmittelbar erkennbar ist, wird die Kontrollleuchte „Malfunction Indicator Lamp (MIL)“ von den Fehlern der verschiedenen Severity-Klassen in unterschiedlicher Weise angesteuert.

Um auch künftige Anforderungen zu berücksichtigen und dem technischen Fortschritt in der Fahrzeugvernetzung gerecht zu werden, wird neben CAN auch das Internet-Protokoll (IP) als Transportmedium bei der Normung berücksichtigt. Somit wird also künftig auch UDSonIP zur Implementierung der WWH-OBD zulässig sein.

In einigen führenden Industrienationen wird die Implementierung der WWH-OBD bereits kurzfristig als Zulassungsvoraussetzung für neu entwickelte Typen schwerer Nutzfahrzeuge gefordert. Ab Anfang 2014 müssen beispielsweise in der EU alle neu zugelassenen schweren Nutzfahrzeuge die Euro-VI-Standards einhalten und damit über WWH-OBD diagnosefähig sein. Neu entwickelte Fahrzeugtypen müssen die Standards bereits zum 01.01.2013 erfüllen.

Die Ausbreitung des Gültigkeitsbereiches der WWH-OBD auf Pkw, Transporter, selbstfahrende Arbeitsmaschinen etc. ist beabsichtigt. Ebenfalls diskutiert wird die Aufhebung der Beschränkung auf abgasrelevante Systeme. Beispielsweise könnten sicherheitsrelevante Systeme wie Bremse, Lenkung, Rückhaltesysteme und Licht ebenfalls damit überwacht und im Rahmen von periodischen Prüfungen examiniert werden.

Intelligente WWH-OBD-fähige Werkzeuge

Die Richtigkeit und Vollständigkeit der OBD-Funktionalität ist den Zulassungsbehörden vom Fahrzeughersteller in geeigneter Form nachzuweisen. Dabei erfolgt die Überprüfung im Rahmen der Homologation und setzt geeignete Prüfmittel zur Verifizierung voraus.

Sowohl der Fahrzeughersteller als auch der Systemlieferant benötigt somit bereits im Vorfeld der Homologation, also schon während der Entwicklung beziehungsweise der Systemintegration, geeignete Diagnosewerkzeuge, um die OBD-Funktionen zu testen.

Die gute Nachricht dabei ist, dass die im Rahmen einer WWH-OBD zwischen Fahrzeug und externem Testgerät ausgetauschten Informationen weitgehend identisch mit denen bleiben, die bereits bei einer Diagnose nach OBD-II oder EOBD ausgetauscht werden. Hier sieht der neue Standard lediglich überschaubare Erweiterungen der Funktionalität vor. Ändern wird sich im Wesentlichen nur die Art und Weise, wie diese Inhalte transportiert werden.

Bild 1: Vorteil für den Anwender beim Diagnosezugriff: Intelligente Tools erkennen automatisch welcher Standard verwendet wird, stellen sich automatisch darauf ein und liefern das Ergebnis.

Bild 1: Vorteil für den Anwender beim Diagnosezugriff: Intelligente Tools erkennen automatisch welcher Standard verwendet wird, stellen sich automatisch darauf ein und liefern das Ergebnis.Vector Informatik

Die Grafik in Bild 1 verdeutlicht den Unterschied der OBD-Kommunikation nach bisherigem Standard und neuem WWH-OBD-Standard. Dargestellt ist jeweils das Auslesen aktuell vorliegender, aber noch nicht bestätigter Diagnostic Trouble Codes (DTC), also der „pending DTC“. Das Fahrzeug übermittelt in beiden Fällen denselben Fehler „Engine Oil Temperature Sensor High“, P0198, an das Scan-Tool. Im Falle der WWH-OBD lassen sich jedoch zusätzliche Informationen wie beispielsweise der Schweregrad des Fehlers auf das Abgasverhalten (Severity) sowie dessen vollständige Statusinformation übertragen und darstellen.

Umstieg auf WWH-OBD

Moderne leistungsfähige Diagnosewerkzeuge müssen die vollständige Unterstützung des neuen WWH-OBD-Standards bieten – und das sofort. Mit ihnen lassen sich auch die zügig näher rückenden Termine Anfang 2013 und Anfang 2014 gut meistern. Sie reihen sich nahtlos in vorhandene Werkzeugketten ein und machen Fahrzeugherstellern und Zulieferern den Umstieg auf WWH-OBD besonders einfach. Erfahrungsgemäß ist es dabei am effizientesten, auf praxisbewährte Lösungen zu setzen. Vector bietet dafür das einfach zu bedienende Diagnosetest-Tool Indigo, das schon jetzt den WWH-ODB-Standard unterstützt. Dies erleichtert den Umstieg auf WWH-OBD.

Betrachtet man die Byte-Inhalte der Requests und Responses, dann wird deutlich, dass deren Aufbau im Falle der WWH-OBD anders aussieht als bei der OBD-II: Zunächst fällt auf, dass die Länge der Fehlercodes in der WWH-OBD gemäß der Spezifikation drei Byte umfasst; bei OBD-II sind es zwei Byte. Allerdings erfolgt eine Weiterverwendung der ersten beiden Byte aus der SAE J2012 beziehungsweise ISO 15031-5.

  • Die ältere OBD-Version liest die DTCs getrennt nach ihrem Status in unterschiedlichen OBD-Modes aus:
  • Service $03 — Request Emission-Related Diagnostic Trouble Codes für confirmed DTC,
  • Service $07 — Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle für pending DTC und
  • Service $0A — Request Emission-Related Diagnostic Trouble Codes with Permanent Status für permanent DTC).

WWH-OBD verwendet hingegen den Protokollservice ReadDTCInformation [0x19] mit der Subfunktion reportNumberOfDTCByStatusMask [0x42] und ein Bitfeld in Byte 4 des Requests zum Einstellen des Status, den die zurück zu meldenden Fehlercodes haben sollen.

Ein intelligentes Testsystem, wie beispielsweise Indigo von Vector, ist in der Lage, den der Prüfung zugrunde zu legenden Standard selbsttätig zu erkennen, die für den jeweiligen OBD Standard relevante Funktionen zur Verfügung zu stellen und dabei aber die protokollspezifischen Unterschiede für den Anwender transparent zu machen. Dieser kann sich somit bei seiner Arbeit auf die Inhalte konzentrieren. Bei Bedarf kann er aber auch in die Tiefen des Protokolls absteigen und die Rohdaten analysieren. Dies ist beispielsweise bei der Ermittlung von Fehlerursachen nützlich, wenn das Steuergerät nicht die erwartete Antwort auf einen OBD-Request liefert.

Dipl.-Ing. Helmut Frank

ist als Business Development Manager bei Vector Informatik für die Produktlinie Diagnose zuständig.

(av)

Kostenlose Registrierung

Der Eintrag "freemium_overlay_form_all" existiert leider nicht.

*) Pflichtfeld

Sie sind bereits registriert?