Fahrzeugdiagnose – zum gewollten Muss (Teil 1) - Softing ...

12lAUTOMOTIVE 5-6.2011l ENGINEERING TOOLSDIAGNOSE – VON DER ENTWICKLUNGBIS ZUM SERVICEFahrzeugdiagnose –vom lästigen Übelzum gewollten Muss (Teil 1)Die Fahrzeugdiagnose befindet sich bereits seit einigen Jahren in einemrapiden Umbruch. Die Anzahl der Steuergeräte im Fahrzeug steigt nacheiner kurzen Phase der Konsolidierung wieder stetig an und bewegt sichnun mit großen Schritten auf 100 ECUs im Fahrzeug zu. Parallel dazusteigt auch die Komplexität sowohl der Funktionen in einer ECU als auchdie des Fahrzeugnetzwerks selbst erheblich. Die Diagnose stellt damiteine eigene Klasse von Anforderungen an das Gesamtfahrzeug dar, dieparallel zu den eigentlichen Funktionen implementiert werden muss.In Mittelklassefahrzeugen findet man heute bereitsvier Bussysteme, in der Oberklasse kommen nochmal zwei bis drei weitere hinzu, die alle untereinandervernetzt werden müssen. Für die Diagnose ergebensich daraus mehrere Konsequenzen: Eine reineBeschränkung der Diagnose auf die vom Gesetzgeber vorgeschriebenenUmfänge bezüglich der Einhaltung vonAbgasstandards genügt seit Langem nicht mehr. EineReparatur von Fahrzeugen ist in einer Werkstatt heuteohne Diagnose nicht mehr möglich. Gleiches gilt für dieFahrzeugproduktion. Und um die Komplexität beherrschenzu können, muss die Diagnose sehr früh im Entwicklungsprozessintegriert und als begleitender Prozess durch diegesamte Entwicklung mitgezogen werden – beim Fahrzeughersteller,aber auch unter Einbeziehung der beteiligtenSteuergerätelieferanten.Damit das Zusammenspiel aller Beteiligten funktioniert,sind Standards unabdingbar. Sie stellen das Ineinandergreifenvon Daten und Tools an den Schnittstellen vonSteuergeräteentwicklung, Prüffeld, Produktion und derServiceorganisation sicher und ermöglichen dadurch dieKonzentration auf die eigentliche Aufgabe. Im Folgendenwerden die zugrundeliegenden Standards und die Absicherungder Diagnose im Entwicklungsprozess ausführlichbeleuchtet.Entlang der Wertschöpfungskette des Fahrzeugs spielt dieDiagnose heute in allen Bereichen von der Entwicklungüber die Produktion bis in den Service eine Rolle. Entscheidenddabei ist, dass die Mechanismen der Diagnose– die Kommunikation eines Testgeräts außerhalb des Fahrzeugsmit einem Steuergerät – heute für eine ganze Reihevon zusätzlichen Aufgaben verwendet werden (Bild 1).EntwicklungsbereichIn der Steuergeräteentwicklung wird die Diagnose für dienachfolgenden Bereiche zur Verfügung gestellt. Die Basisist die Diagnosekommunikation, bei neuen Steuergerätenin der Regel auf Basis des Standards UDS. Die klassischeDiagnose als Funktion im Steuergerät dient der Erkennungvon unerwartetem Verhalten innerhalb des Steuergerätsund in seiner Umgebung, einer Bewertung und dem Eintragendieser Auffälligkeiten im Fehlerspeicher. Von dortkönnen die Einträge dann durch ein externes Testsystemausgelesen und weiterverarbeitet werden. Neben denklassischen Fehlerspeicherfunktionen – dazu gehörenebenso die Ermittlung von Randbedingungen für den Feh-

AUTOMOTIVE 5-6.2011l13lereintrag („Umgebungsbedingungen“) und das Löschendes Fehlerspeichers – kommt dieselbe Basisfunktionalitätheute auch für verwandte Anwendungsfälle zum Einsatz.Beispiele sind:■ Flash-Programmierung: Austausch von Code oderDaten im Steuergerät.■ Varianten-Codierung: Anpassung des Verhaltens einesSteuergeräts entsprechend gesetzlicher Vorschriften(z. B. Tagfahrlicht in Skandinavien) oder der kommerziellenRandbedingungen („SW als Produkt“).■ Routinen starten: Funktionen des Steuergerätes werdenvon außen angestoßen und laufen dann selbstständigab, beispielsweise ein Selbsttest.■ Messen: Auslesen der durch das Steuergerät mithilfevon Sensoren ermittelten Größen.Die Diagnosekommunikation wird also immer dann eingesetzt,wenn ein präziser Daten- und Freigabeprozess nötigist (Flash-Programmierung, Varianten-Codierung) oder sieeinen einfachen und preisgünstigen Zugang zur BlackboxSteuergerät erlaubt.Im Entwicklungsbereich kommt die Diagnose in zahlreichenAnwendungen zum Einsatz, sei es bei der Kommunikationsentwicklung,der Entwicklung von Steuergerätefunktionen,der Entwicklung von Flash- und Variantencodierfunktionen,im HiL, in Systemprüfplätzen oder bei derSteuergeräteintegration. Anschließend wird auch im Fahrzeugtestvielfältig darauf zurückgegriffen.ProduktionGerade der einfache Zugang zum Steuergerät ermöglichtin der Produktion eine Vielzahl von Anwendungen, diesonst nur mit komplexen Lösungen kostenintensiv zu realisierenwären. Die heutigen mechatronischen Systemekönnen ohne Zugang zur Elektronik kaum einer Prüfungunterzogen werden, sollten andererseits aber so früh wiemöglich getestet werden. Auch die Variantencodierungdes Fahrzeugs, die Schlüsselprogrammierung und die Initialisierungder Wegfahrsperre werden hier durchgeführt.Schließlich erfolgt im „End-of-line“-Test eine finale Kontrolleder Fahrzeugfunktionen und das Löschen des Fehlerspeichers.Eine besondere Herausforderung stellt in der Produktiondie Unterscheidung der „echten“ Fehler von den „systematischen“Fehlern dar. Letztere ergeben sich aus der Tatsache,dass die Steuergeräte zahlreiche Fehlereinträgeführen, die sich aus der zum Verbauzeitpunkt fehlendenSystemumgebung ergeben. Beispielsweise werden Fehlereingetragen, wenn auf dem CAN-Bus ein Signal nichtverfügbar ist, das von einem noch nicht verbauten Steuergerätgesendet werden sollte. Der Eintrag ist selbstverständlichrichtig, er verweist aber eben nicht auf ein fehlerhaftes(Teil-)System.ServiceDie Ursprünge der Diagnose finden sich im Service, genauerin der nüchternen Erkenntnis, dass ein Fahrzeug auf derelektronischen Basis von aktuell 30 bis 80 Steuergeräten,bei der eine Vielzahl der Fahrzeugfunktionen in Softwarerealisiert sind, in einer Werkstatt nicht mehr repariert wer-

14lAUTOMOTIVE 5-6.2011l ENGINEERING TOOLSBild 1: Diagnoseanwendungsfälle im Lebenszyklus.den kann. Dem Fachmann in der Werkstatt muss für denFall, dass der Kunde unerwartete Symptome meldet, derpassende „Schraubenschlüssel“ zur Hand gegeben werden.Das entsprechende Werkzeug ist der Service-Tester.Es verbindet die gemeldeten Symptome mit Fehlereinträgenin den Steuergeräten und Messwerten, die parallelermittelt werden können. Expertensysteme kombiniert mitder Erfahrung des Fachmanns in der Werkstatt führen dannin aller Regel zu einer Reparaturempfehlung.Zusätzlich ist es in der Regel möglich, Steuergeräte mitneuen Software-Ständen zu programmieren.In allen genannten Anwendungsfällen kommen heuteODX-Daten zum Einsatz. Außer in Testsystemen werdendiese auch für die Parametrierung von Steuergeräten undfür die automatische Erzeugung von Testprozeduren verwendet.Es liegt auf der Hand, dass die Qualität der ODX-Daten – alleine, aber auch in Verbindung mit dem Steuergerät– für die Gesamtqualität eine entscheidende Einflussgrößedarstellt. Neben der Durchführung von intensivenReviews wird dies durch eine aufwendige Datenverifikationerreicht. Die Datenverifikation ist ein wichtigerAnwendungsfall eines modernen Entwicklungstesters.Darüber hinaus kommt dieser im ganzen Entwicklungsprozesszum Einsatz: als Testumgebung für die wichtigenSteuergerätefunktionen Diagnosekommunikation, Diagnosefunktion,Flash-Programmierung und Variantencodierung.Auch als preiswerter „Debugger“ wird der Entwicklungstesterimmer wieder eingesetzt. In späteren Phasenspielt er eine große Rolle bei der Fahrzeugüberprüfung inder Versuchswerkstatt und teilweise sogar im Fahrversuchbeim Test einzelner Fahrzeugfunktionen und in der Fehleranalyse,speziell bei Problemen in der Kommunikation. Undauch bei der Prüfvorbereitung spielt der Entwicklungstesterals Inbetriebnahmewerkzeug eine große Rolle. DieKombination aus ODX-Daten und Steuergerät in Verbindungmit dem D-Server stellt für den Testingenieur imWesentlichen eine Blackbox dar, die für ihn nur schwer inBetrieb zu nehmen ist. Mit dem Entwicklungstester kannhier sehr einfach die Kommunikation in Betrieb genommenwerden und das korrekte Verhalten des Testablaufs simuliertwerden.OBDDie On-board-Diagnose stellt einen besonderenBereich der Diagnose dar, da sie vomGesetzgeber vorgeschrieben ist. Er verlangtvon den Fahrzeugherstellern – ursprünglichnur von den Pkw-Herstellern, inzwischen aberauch von Lkw-Herstellern –, dass alle abgasrelevantenSysteme kontinuierlich einemSelbsttest unterzogen werden. Im Falle einerAuffälligkeit muss dies dem Fahrer durch eineWarnleuchte unverzüglich mitgeteilt werden,damit er das Problem beheben lassen kann.Für den Fall Kalifornien ist dieses „kann“ insoferneine Verniedlichung, da der Fahrer empfindlicheStrafen zahlen muss, wenn er dasAbgassystem nicht reparieren lässt. DieserSelbsttest wird durch die Forderung unterstützt,dass jederzeit mit einem einfachen Diagnosetester,dem sogenannten Scantool, die Erkenntnisseder On-board-Diagnose ausgelesen werden können.Sowohl eine funktionierende On-board-Diagnose als aucheine funktionierende Kommunikation mit den Scantoolsstellen für die Hersteller eine Marktzugangsvoraussetzungdar. Entsprechend genau müssen die Tests dieser Funktionalitätensein. Diese sind mit der Fahrzeugzulassung auchnicht beendet, da eine Häufung von Meldungen bei bereitsverkauften Fahrzeugen schnell auch zu Fahrzeugrückrufenführen kann.© automotiveAnforderungen an DiagnosesystemeWenn man sich moderne Testsysteme im Automotive-Umfeld anschaut, erkennt man generelle Blöcke, dieimmer wiederkehren. Zunächst ist entscheidend, dassman in den meisten Fällen ein Erstellsystem und eine Laufzeitumgebungvorfindet. Das Erstellsystem dient der Konfigurationdes Laufzeitsystems, in ihm konfiguriert der TestingenieurTestabläufe und die Visualisierung für die spätereVerwendung. In vielen Fällen wird auch die Dokumentationdes Tests bereits hier definiert. Das Erstellsystemarbeitet oft in einem Administratormodus. In der Laufzeitumgebungsind die Eingriffsmöglichkeiten des Testers häufigstark eingeschränkt. Der Tester hat nur noch denAnwendungsmodus im Zugriff. Das Ziel ist, dass er sich nurnoch auf die Testumgebung konzentriert und das Tool mitwenigen Handgriffen funktioniert.Die Testsysteme haben für die Konfiguration und TestdurchführungEingangsdaten, die Konfigurationen und Randbedingungenparametrieren. Standardisierte Eingangsgrößensind die heute geforderten ODX-Daten und zunehmendauch OTX-Daten (Bild 2). Daneben kommen häufig proprietäreDaten zum Einsatz, zum Beispiel Logistikinformationenwie Freigabestände und Verbaulisten. Diese Größen sindstark prozessabhängig, teilweise auch infrastrukturabhängigund können schlecht standardisiert werden.Daneben werden auch entsprechende Ausgangsdatenerzeugt. Diese können ebenfalls standardisiert oder proprietärsein. In der Diagnose gibt es heute, anders als in derMesstechnik, (noch) kein standardisiertes Ausgabeformat.Ein typisches Ausgabeformat ist die Testdokumentation, in

ENGINEERING TOOLSl AUTOMOTIVE 5-6.2011l15der erfolgreiche und fehlgeschlagene Testfälle aufgezeichnetsind. Diese können entweder durch Spezialisten analysiertoder später für Regressionstests wieder ins Systemzurückgespielt werden. Auch Fehlerstatistiken werden vielfachmit den Testergebnissen erzeugt.Anforderungen an EntwicklungstesterSpeziell an Entwicklungstester, die ja im gesamten Prozesszum Einsatz kommen, müssen noch eine Reihe zusätzlicheAnforderungen gestellt werden. Dies liegt in erster Linie anden Einsatzfällen, aber auch an den zugrundeliegenden Verarbeitungsschichten.Insbesondere werden ODX-Datendurch einen sogenannten D-Server verarbeitet. Dieser stelltdie Daten aufbereitet zur Verfügung. Es ist aber für das Testsystemkaum möglich festzustellen, welchem Zweck dieDaten dienen. D. h., Diagnosedienste für die Kommunikationskontrolleunterscheidensich in der Praxis an der Schnittstellemeist nicht von Diagnosedienstenzum Messen oder zumParametrieren eines Steuergerätes.Der Diagnosetester mussden Anwender aber durchanwendungsspezifische Darstellungenunterstützen, die entsprechendkonfiguriert werdenmüssen. Erst dadurch wird dieDarstellung mit den passendenDiagnosediensten verbunden.Die Arbeit am Fehlerspeicherstellt vielleicht die wichtigsteDiagnosefunktion dar. Er mussgelesen, aber auch gelöschtwerden, um den korrektenWiedereintrag eines Fehlers prüfenzu können. Je nach Anwenderinteressieren die Fehler desganzen Fahrzeugs oder einesSteuergerätes, nur die Liste derFehler oder die Fehler mit denabgespeicherten Umgebungsbedingungenund den Statusinformationen.Gerade die Statusinformationensind für eine tiefergehende Analyse von Bedeutung,da sie den Fehler näherbeschreiben. Man erfährt beispielsweise,ob ein Fehler dauerhafteingetragen wurde odernur temporär, ob er sporadischauftritt oder dauerhaft. Eine weiterewichtige Information ist dasReadiness-Flag. Es gibt an, obdie zur Erkennung des Fehlersim Steuergerät implementierteRoutine bereits vollständigdurchlaufen wurde. Für eineganze Reihe von Fehlern müssendazu Vorbedingungen eingehaltenwerden, wie „Motortemperatur muss Mindestwerterreicht haben“, „vorgegebene Drehzahl muss Wert überschrittenhaben“, usw. Die Anforderungen an die Visualisierungder Flash-Programmierung sind gänzlich andererNatur. Diese beschränkt sich im Wesentlichen auf die Auswahlder Programmierdaten (z. B. Programmcode, Kennfelder,…)einen Start-Button und möglichst eine Fortschrittsanzeige,da bei Datengrößen von mehreren MByte durchausnennenswerte Programmierzeiten entstehen. Dieeigentliche Herausforderung steckt bei der Flash-Programmierungim Ablauf. Hier wird zunächst eine Authentifizierungdurchgeführt, in die Programmiersession geschaltet,die restlichen Busteilnehmer aufgefordert, im Folgendenkeine Busfehler einzutragen und anschließend die Buskommunikationzwischen den Steuergeräten beendet, um ausreichendBandbreite zur Verfügung zu haben. Danachwww.elektrobit.com

16lAUTOMOTIVE 5-6.2011l ENGINEERING TOOLSBild 2: Generelle Anforderungen an Testsysteme.© automotivebeginnt die möglichst performante Übertragung der Daten.Am Ende werden Checksummen überprüft, das programmierteSteuergerät reinitialisiert und die Buskommunikationwieder freigeschaltet. Abschließend sind manchmalnoch Systemanpassungen durchzuführen.Beim Messen muss hauptsächlich unterschieden werdenzwischen graphischer Darstellung der einzelnen Messwerteund textueller Darstellung. Bei der graphischen Darstellungsind die Grenzen im Wesentlichen durch die Bedienbarkeitgesetzt, von der Art der Darstellung (Zeigerinstrument,Balkendiagramm, x-t-Darstellung, …) über die verwendetenFarben bis zum Darstellungsbereich (Wertebereich,Gültigkeitsbereich mit Farbumschlag, …) ist hier fastalles möglich. Daneben müssen häufig Messwertblöckedargestellt werden. Diese werden auf einmal vom Steuergerätausgelesen, um bei zusammenhängenden Größenkeine Latenzen durch die Busübertragung in die Messungeinfließen zu lassen.Bei der Ausführung von Steuergeräteroutinen ist wiederumein sehr breites Anwendungsspektrum abzudecken. Daseine Ende wird durch Steuergeräteroutinen gebildet, beidenen das Feedback allein von Aktuatoren gegeben wird.Beispiele sind der Zeigertest am Kombiinstrument oderVentile am ABS-Steuergerät, die öffnen und schließen. Fürdiese Art von Routinen muss der Tester eigentlich nur einenStart-Button anbieten sowie vielleicht ein Beschreibungsfeldfür den Test. Das entgegengesetzte Ende stellenSelbsttests dar, die als Ergebnis eine Ergebnisliste über denBus zurückliefern. Hier muss der Tester die relevanten Teileder Steuergeräteantwort auf dem Bildschirm darstellen.Ähnlich funktioniert auch die wichtige Darstellung der Fahrzeug-oder Steuergeräteidentifikation, die in der Regel auseiner Liste von Informationen wie der VIN (VehicleInformation),HW-Stand, SW-Stand, usw. gebildet wird.Der Einsatzfall Datenverifikation erfordert einen erheblichweiteren Darstellungsraum. Der Zugriff sowohl auf dieParametrierung von Diagnosediensten als auch auf dieErgebnisse muss so vollständig sein, dass alle Methodiken,die in automatischen Tests angewendet werden, mitdem Entwicklungstester auch manuell überprüft werdenkönnen. Im Entwicklungstester müssen auch Werte einstellbarsein, die eigentlich nicht erlaubt sind,um das korrekte Verhalten an den Grenzen verifizierenzu können. Bei der Überprüfung istbesonders wichtig, dass nicht nur die Werteanalysiert werden können, sondern auch dieStrukturierung der Ergebnisse. Diese ist für denZugriff durch eine Testautomatisierung eineFehlerquelle, die nicht unterschätzt werdendarf. Es sind übrigens nicht alle Tests automatisierbar,da zwar die Plausibilität automatischgeprüft werden kann, nicht aber die richtigeUmsetzung von hexadezimalen (Bus-)Daten insymbolische Daten. Dies ist eine Aufgabe fürSpezialisten, die massiven Einfluss auf dieGesamtqualität des Systems hat.VariantencodierungMit Hilfe der Variantencdierung werden Funktionenim Steuergerät ein- und ausgeschaltet. Dies haterhebliche Kostenvorteile, da nicht für jede Variante derSteuergerätecode einzeln frei getestet werden muss. DieFunktion Variantencodierung muss dafür umso genauergetestet werden. Dies ist mit hohem Aufwand verbunden,da die einzelnen Codierbits nicht unabhängig sind. Dies giltinnerhalb eines Steuergeräts, umso mehr aber auch für dasGesamtfahrzeug. Offensichtlich wird dies an der Kombinationvon Motor und Getriebe. Die Motorleistung wird heutein der Regel für einen Motor codiert, muss aber mitbestimmten Getrieben kombiniert werden, da das eineGetriebe für ein Drehmoment nicht spezifiziert ist, anderseitsbei hohen Leistungen häufig nur noch ein Automatikgetriebeangeboten wird. Der Diagnosetester muss für dieFunktionsprüfung die Kombination verschiedener Codierungenmöglichst einfach erlauben. Gleichzeitig sollte auchhier das Setzen fehlerhafter Kodierkombinationen möglichsein, um das Fehlerverhalten überprüfen zu können.RestbussimulationEigentlich kein Thema der Diagnose ist die Restbussimulation.Dennoch hat sie einen großen Einfluss, da in vielenFällen – insbesondere, wenn nur ein einzelnes Steuergerätoder ein Teilnetzwerk in Betrieb genommen werden sollen– die Diagnose nicht funktioniert. Oftmals ist die Diagnosein einem Steuergerät nicht aktiv, solange bestimmte Signalenicht auf dem Bus übertragen werden. Ein typischesBeispiel ist die Zündungserkennung, die von einem Steuergerätdurchgeführt wird und dann als Signal allen anderenECUs auf dem CAN-Bus zur Verfügung gestellt wird.Gleiches gilt für Signale, die für eine plausible Diagnosenötig sind (z. B. einem Geschwindigkeitssignal). In jedemFall muss der Entwicklungstester diese Signale simulierenkönnen, indem er einzelne CAN-Nachrichten auf den Buszyklisch sendet. Sinnvollerweise sollten die einzelnen Signaleauch änderbar sein, da sich beispielsweise das Diagnoseverhaltenvon niedrigen zu hohen Fahrzeuggeschwindigkeitenändern kann.Auch die Anforderung Analysefähigkeit erzeugt Anforderungenan den Entwicklungstester. Zum einen dient er derDatenvisualisierung. Er muss also die Daten geeignet auf-

ENGINEERING TOOLSl AUTOMOTIVE 5-6.2011l17bereiten und Messwerte auf passenden Instrumenten darstellen,den Fehlerspeicher auflisten und die Daten zurFlashprogrammierung so präsentieren, dass sie fehlerfreiins Steuergerät programmiert werden können. Zum anderendient er aber der Inbetriebnahme und soll zu diesemZweck einen möglichst genauen Zugriff auf die ODX-Informationenund eventuell auftretende Kommunikationsfehlerermöglichen. Falls in der Kommunikation selbst Problemeauftreten, muss aber auch der Busverkehr so dargestelltwerden, dass das jeweilige Problem effizient auffindbar unddokumentierbar ist.Für die Prüfung der OBD-Funktion müssen die OBD-Modes,es handelt sich dabei um spezielle Diagnosedienste, in derjeweils adäquaten Form präsentiert werden. Grob gegliedertdienen sie zum Lesen der Messwerte, zur Fehlerspeicherbearbeitungund zur Auswertung von Testergebnissen.Die Adressierung erfolgt dabeiimmer auf die Funktion „OBD“, eskönnen also mehrere Steuergerätebetroffen sein. Das VCI muss dazudie funktionale Adressierung beherrschen,das Diagnosesystem mitmehreren Antworten von verschiedenenSteuergeräten umgehen können.Welche Teilfunktionen bei deneinzelnen Modes unterstützt werden,wird bitcodiert von den Steuergerätenans Testsystem gemeldet.Hier ist es besonders wichtig, dassder Tester erlaubt, Anfragen an dieSteuergeräte zu stellen, die erst einmalfalsch erscheinen, da die Scantoolsdie Spezifikation teilweiseunterschiedlich interpretieren.Im zweiten Teil dieses Beitrags werden die verschiedenenProtokolle und Programmierschnittstellen aufgezeigt.Schließlich wird am Beispiel des DTS-Monaco von SoftingAutomotive ein Entwicklungstester vorgestellt, der D-PDUAPI, ODX, MCD-3D und OTX beherrscht.Markus Steffelbauer leitet das Produktmanagementund verantwortet Entwicklung undMarketing der Hardware- und Softwareproduktebei der Softing Automotive ElectronicsGmbH. Daneben vertritt Steffelbauer seit vielenJahren Softing in verschiedenen Standardisierungsgremien,seit 2008 als Vertreter imASAM TSC (Technical Steering Committee).Softing Automotive Electronics GmbH@ www.softing.comWelche wichtigenStandards muss manbeachten?Heute in der Diagnose verwendeteStandards können grundsätzlich indrei Kategorien eingeteilt werden:Protokolle, Datenbeschreibungenund Programmierschnittstellen. Dieälteste Kategorie stellt sicher die derProtokolle dar. Eingeführt ursprünglichum die Forderung des Gesetzgebersnach einer Überwachungsmöglichkeitdes Abgasverhaltens zugenügen, erfüllen diese Protokolleheute zahllose weitere Aufgaben.Die Vielzahl der herstellerspezifischenProtokolle wurde heute durchstandardisierte Protokolle abgelöst,allerdings sollte die Bedeutung derAltprotokolle für Servicetester nichtunterschätzt werden, schließlich sinddie Fahrzeuge noch viele Jahre aufder Straße aufzufinden.

ENGINEERING TOOLSl AUTOMOTIVE 7-8.2011l39DIAGNOSE – VON DER ENTWICKLUNG BIS ZUM SERVICEFahrzeugdiagnose –vom lästigen Übel zum gewollten Muss(Teil 2)Die Fahrzeugdiagnose befindet sich bereits seit einigen Jahren in einemrapiden Umbruch. Die Diagnose stellt eine eigene Klasse von Anforderungenan das Gesamtfahrzeug dar, die parallel zu den eigentlichen Funktionenimplementiert werden muss. Im zweiten Teil dieses Beitrags werden dieverschiedenen Protokolle und Programmierschnittstellen aufgezeigt. Schließlichwird am Beispiel des DTS-Monaco von Softing Automotive ein Entwick -lungstester vorgestellt, der D-PDU API, ODX, MCD-3D und OTX beherrscht.Kommunikationsprotokoll UDSDie heute gängigsten Protokolle sind in Europa ISO 14765(KWP2000 auf CAN) und das darauf aufbauende ISO 14229(UDS – Unified Diagnostic Services). Sie teilen sich eingemeinsames Transportprotokoll und beschreiben imWesentlichen auch die gleichen Klassen an Diagnosediens -ten (DiagnosticServices). Allerdings wurden für UDS, demNamen entsprechend, die Dienste für unterschiedlicheAnwendungsfälle und entsprechend der bei den verschiedenenHerstellern verwendeten Altprotokolle so verallgemeinert,dass eine Migration relativ einfach möglich ist. ImWesentlichen werden folgende Dienstklassen beschrieben:■ Datenlesen■ Flashprogrammierung■ Fehlerspeicher■ Steuergeräteroutinen■ IO Control■ KontrollfunktionenUm darüber hinaus in nicht wettbewerbsrelevanten BereichenEinsparungen zu ermöglichen, ist schon vor einigenJahren im Rahmen des ASAM e.V. eine Art Diagnose -betriebssystem von OEMs und Toolherstellern gemeinsamentwickelt worden. Es handelt sich dabei um ein daten -getriebenes System, die Daten beschreiben die Fähigkeitendes Systems im Zusammenspiel mit dem jeweiligen Steuergerätoder Fahrzeug. Die Notwendigkeit eines solchen Vorgehensist einfach zu verstehen, wenn man sich vergegenwärtigt,dass ein Türsteuergerät gänzlich andere Funktionalitätenund Größen implementiert als etwa ein Motorsteuergerät.Innerhalb des ASAM e.V. wurde eine Programmierschnittstelle(ASAM MCD-3D) zum symbolischen Zugriff auf Steuergeräte-und Fahrzeuginformation und die Datenbeschreibung(ASAM MCD-2D ODX – Open Diagnostic data eXchange)als Austauschformat zwischen den Beteiligten im Diagnoseprozessdefiniert. Beide wurden auch als ISO-Standardsübernommen. Innerhalb der ISO wurden noch zwei

40lAUTOMOTIVE 7-8.2011l ENGINEERING TOOLSweitere Standards ergänzt: D-PDU API als Low-level-Programmierschnittstellezum einfachen Austausch von Diagnoseinterfacesund OTX (Open Test sequence eXchangeformat). Letzteres ermöglicht den Austausch von Diagnoseabläufen,z.B. zwischen Entwicklung und Produktion.SOFTING UND KVASERSofting Automotive Electronics und Kvaser vertiefen ihre Partnerschaft.Die Partnerschaft erweitert die bereits bestehendetechnische Partnerschaft von Softing Automotive Electronicsund Kvaser AB. Durch die Ergänzung mit Kvaser-CAN-Interfaceskann das bisherige Interface-Portfolio von Softing weiter abgerundetwerden. Softing tritt somit als Vertriebspartner von Kvaser-Hardwaream Markt auf und unterstützt die Hardware inihren Anwendungen. Geplant ist auch ein neues Paket imBereich der Diagnoselösung. Dieses soll mit DTS-Monaco (Softwarefür Steuergeräte-Kommunikation, -Diagnose und OnboardAnalyse) und dem Leaf Light HS von Kvaser kombiniert werden.Peter Biermann, Geschäftsführer der Softing Automotive ElectronicsGmbH: „Mit dem Leaf Light Interface von Kvaser können wirdem Kunden eine preisgünstige Diagnose-Lösung anbieten, dienoch dazu einfach zu bedienen ist und die Kundenanforderungenan Performance und Handhabbarkeit erfüllt."D-PDU API – die Integrationsschichtfür VCIsDer Standard beschreibt eine Programmierschnittstelle aufhexadezimaler Ebene. Das Transportprotokoll wird dabeivollständig transparent behandelt, d. h., für die darüberliegendeAnwendung spielt es keine Rolle, welches Protokollim D-PDU API bearbeitet wird. Der Schnittstelle werden dieDaten in Form eines Bytestreams zusammen mit den Adressierungsinformationenübergeben und das Protokoll parametriert(z. B. Timings). Die Ausführung entsprechend deseingestellten Protokolls erfolgt dann automatisch. Steuergeräteantwortenwerden der Anwendung anschließendebenfalls als Bytestream mit den Adressinformationen derantwortenden Steuergeräte zurückgespiegelt. WeitergehendeFähigkeiten der Interfaces, wie Ein- und Ausgänge,die angesprochen werden können, können über D-PDU APIebenfalls bedient werden. Insgesamt wird die Beschreibungder Fähigkeiten der Interfaces, die je nach Produkt abweichen,in einer XML-Datei abgelegt. Dadurch ist ein Wechseldes Interfaces sehr einfach möglich, es kann beispielsweiseein Testprogramm in der Entwicklung mit einem USB-Interfacevom Hersteller A betrieben werden und später im Prüfstandmit einem WLAN-Interface vom Hersteller B. In derPraxis werden – allerdings geringe – Anpassungen nötigsein.ODX – das Austauschformatfür DiagnosedatenDer Standard beschreibt die Dateninhalte der Diagnose-Kommunikation für die im Fahrzeug verbauten Steuergeräteals XML-Datei. Er stellt damit in einer Quelle sowohl dieDokumentation als auch die Testsystemparametrierung zurVerfügung. Die Daten können somit von der Spezifikationsphasebis zur Nutzung in Produktion und Service gleichermaßenverwendet werden. Über die Datei kann eine Umsetzungvon hexadezimalen in symbolische Werte erfolgen,d. h., für ein „Motorsteuergerät“ existiert die Beschreibungeines Diagnosedienstes „DrehzahlLesen“. Die entsprechendenHex-Werte zum Senden über D-PDU API könnenaus der ODX-Datei ermittelt werden. Aus der Antwort kannder hexadezimale Wert ermittelt werden, der in„1900 U/min“ umgerechnet wird. Neben diesen Kommunikationsinformationenwerden in ODX auch die Protokoll-Parametrierung, Verbaulisten eines Fahrzeugs in verallgemeinerterForm, Flashprogrammierdaten und Daten für dieVariantencodierung beschrieben. Hauptziele der Standardisierungwar die Schaffung eines Standards, dermaschinenlesbar und langzeitstabil ist (Verwendungvon XML) und den Entwicklungsprozess unterstütztund (möglichst) redundanzfrei ist (Vererbungskonzept).Das Vererbungskonzept beruht auf der Idee, dass fürein bestimmtes Steuergerät eine Vielzahl von Informationenbeschrieben werden kann, die über dengesamten Lebenszyklus konstant bleibt. DieseInformation wird in der sogenannten BaseVariantbeschrieben. Die einzelnen Varianten eines Steuergerätes,beschrieben z. B. über den Identifikationsstringoder einen Softwarestand, unterscheiden sichnur geringfügig. Der Hauptteil der Informationenkann also für eine Variante aus der Basisvariantegeerbt werden, in der ECUvariant muss dann nurnoch das Delta beschrieben werden. Dieses kanndazugefügt werden oder überflüssige Informationkann ausgeblendet werden. Darüber hinaus könnenInformationen, die in der Steuergeräte varianteanders beschrieben sind als für die BaseVariant, wiein einer objektorientierten Programmierspracheüberschrieben werden. Zusätzlich zu diesen beidenEbenen BaseVariant und ECUvariant existieren nochzwei weitere Ebenen: Die Protokollebene beschreibt diedurch das Diagnoseprotokoll vorgegebenen Dienste undParametrierungen und dient damit als „Blaupause“ für diedavon abgeleiteten Steuergeräte. Die Ebene Functional-Group schließlich ermöglicht die Beschreibung der funktionalenAdressierung, bei der mehrere Steuergeräte einer logischenGruppierung über eine gemeinsame Adresse angesprochenwerden können. Das bekannteste Beispiel ist dieOBD-Funktionalität, bei der alle abgasrelevanten Steuergerätezusammengefasst werden und gemeinsam angefragtwerden. Beim OEM werden in einer ODX-Datenbank in derRegel die Daten für eine Baureihe zusammengefasst. DieGesamtdatenmenge kann dabei relativ groß werden, weildie Datenbank folgende Informationen enthält:■ die im Fahrzeug verwendeten Protokolle,■ die Information über die mit funktionaler Adressierungzugreifbaren Steuergeräte,■ die Gesamtheit der Fahrzeug verbaubaren Steuergeräte,also sowohl optional erhältliche Steuergeräte (Getriebe-

ENGINEERING TOOLSl AUTOMOTIVE 7-8.2011l41steuergerät für Automatikgetriebe) als auch alternativeSteuergeräte (Motorsteuergerät für 4- und 6 Zylinder Diesel-und Benzinmotor),■ die Varianten über die Produktionszeit des Fahrzeugs.Reale ODX-Datenbanken erreichen heute die 100-MByte-Grenze. Um den Datenaustausch zu vereinfachen, wurdezusätzlich zu ODX das PDX-Format standardisiert (packedODX). Dabei handelt es sich um eine indizierte ZIP-Datei.ASAM MCD-3D –das DiagnosebetriebssystemDer Standard beschreibt eine Programmierschnittstelle zumZugriff auf Steuergeräte mithilfe von ODX-Daten. Das entsprechendeLaufzeitsystem wird in der Regel D-Server oderMVCI-Server genannt. Es kann im Diagnoseprozess von derEntwicklung über die Produktion bis in den Ser vice in verschiedenstenAnwendungen zum Einsatz kommen undstellt somit eine konsistente Verwendung der ODX-Datensicher. Dies wird insbesondere dadurch möglich, dass zurVerwendung mit verschiedenen ProgrammiersprachenReferenzimplementierungen für COM/ DCOM, JAVA undC++ beschrieben und im Markt auch verfügbar sind.Der Zugriff erfolgt auf symbolischer Ebene, d. h., es wird einSteuergerät über seinen Namen „Motorsteuergerät“ ausgewähltund anschließend können für dieses SteuergerätDiagnosedienste ausgeführt werden. Ein Beispiel ist der vorherbeschriebene Dienst „DrehzahlLesen“, der von derODX-Ablaufmaschine im D-Server verarbeitet und über D-PDU API an das Steuergerät gesendet wird. Die Antwortwird ebenfalls über die ODX-Daten prozessiert und dasErgebnis an der API als „1900 U/min“ zur Verfügung gestellt.Um insbesondere in der Produktion die Performance zu verbessern,können im Prinzip beliebig viele solcher Anfragenparallel abgearbeitet werden. Die Grenze ergibt sich imWesentlichen aus der Buslast des (in der Regel) verwendetenCAN-Busses und der Fähigkeit des Gateway-Steuergerätes,die Anfragen auf die verschiedenen Busse hinter demGateway sinnvoll zu verteilen.Die ODX-Daten werden in realen D-Servern heute mithilfeeines Laufzeitformats verarbeitet. Dies hat zum einen Performance-Gründe– in einem Binärformat können die Datengepackt und für den Zugriff optimiert abgelegt werden – zumanderen Sicherheitsgründe. Gerade im Service liegen dieDaten im Prinzip ungeschützt auf den Service-Testern undkönnen von Interessierten verändert und entwendet werden.Binärdaten sind einfach zu verschlüsseln und gegenZugriff zu sichern, sodass hiermit ein deutlicher Sicherheitsgewinnzu verzeichnen ist.

42lAUTOMOTIVE 7-8.2011l ENGINEERING TOOLSOTX – das Austauschformatfür DiagnoseabläufeDer Standard beschreibt ein Austauschformat für Dia gnose-Testsequenzen. Auch hier waren – ähnlich wie bei ODX – dieMaschinenlesbarkeit und Langzeitverfügbarkeit die zentralenAnforderungen. Die Idee hinter dem Standard ist, eineMöglichkeit zu schaffen, bereits in der Spezifikationsphasegrundlegende Abläufe zwischen Testssystem und Steuergerätformal zu beschreiben. Im Prozess können dieseAbläufe weiterverwendet und spezialisiert werden, manmuss also nicht wieder bei Null anfangen und einen Grundablaufaus einer Papierspezifikation abschreiben. Durch dieMaschinenlesbarkeit wird darüber hinaus eine graphischeDarstellung der Abläufe z. B. als Flussdiagramme unterstützt,die den Ingenieuren in Entwicklung, Verifikation, Produktionund Service eine allgemeingültige Basis für ihreDiskussionen bietet. Der Standard OTX wird in mehrereBereiche unterteilt. Der Kern (Core) enthält eine Programmiersprachemit den typischen Elementen Variablen, Ausdrücken/Anweisungenund Operationen (Schleifen, Verzweigungen,Vergleiche,…). Er ist nicht diagnosebezogenund kann grundsätzlich für unterschiedliche Aufgaben angewendetwerden. Standardisierte Bibliotheken stehen fürspezielle Aufgaben zur Verfügung. Neben der Diagnosekommunikation(Anbindung an den D-Server) gehören dazuinsbesondere Stringoperationen, Größenhandling, Darstellungsfunktionen(HMI) und die Internationalisierung, um dieAusgaben von Abläufen für verschiedene Märkte in verschiedenenSprachen anbieten zu können. Die standardisiertenBibliotheken nutzen einen allgemeinen Erweiterungsmechanismus.Dieser kann auch für nicht-standardisierteErweiterungen verwendet werden, wodurch in denAblauf beliebige Testsysteme integrierbar sind. TypischeBeispiele sind HiL-System, Simulationen oder Messtechnik.OTX unterstützt den Entwick lungsprozess durch verschiedeneMechanismen. Zunächst ermöglicht es für frühe Prozessphaseneine reine Spezifikationssicht. Dabei wird dieIdee des Ablaufs beschrieben, ohne schon eine konkreteImplementierung des Ablaufs zu hinterlegen. Es kann somitbeispielsweise ohne echte ODX-Datei, in der dann reale Diagnosedienstebeschrieben sind, schon die Kommunikationmit einem Steuergerät skizziert werden. Dabei entstehtkeine ablauffähige OTX-Sequenz. Dies wird dann später inder Implementierung der Sequenz nachgeholt. Um auch dieVariantenvielfalt ähnlich wie in ODX zu unterstützen, ohneeine Sequenz jedes Mal vollständig neu freigeben zu müssen,wurden ebenfalls spezielle Mechanismen realisiert.Im Unterschied zu ODX existiert für OTX kein standardisiertesAPI für eine Ablaufmaschine. Als Austauschformat stehtes dem Toolhersteller frei, das Formatin einem Interpreter zu verarbeiten,es in ein Maschinenformatzu kompilieren oder es in bereitsexistierende Testsysteme zu importierenund dort weiter zu verarbeiten.Bild 3: DTS-Monaco von Softing ist ein Beispiel für einen Entwicklungstester. In Abhängigkeitvom verwendeten Interface können grundsätzlich beliebige Protokolle unterstütztwerden, solange ein Interface mit D-PDU API und entsprechende ODX-Daten existieren.Entwicklungstester – einBeispielDTS-Monaco ist ein Beispiel füreinen Entwicklungstester. Esbasiert auf den Standards D-PDUAPI, ODX, MCD-3D und OTX undbeherrscht damit die relevantenStandards (Bild 3). DTS-Monacobesteht aus einigen wenigenHauptkomponenten und kannanwendungsspezifisch erweitertwerden: Das Framework, die HMIcontrolsund die Run-times für die© automotive Standards OTX und ODX. ODX werdendurch den D-Server DTS-COSbearbeitet. Er stellt das standardisierte API entsprechendASAM MCD-3D zur Verfügung, bietet darüber hinaus abernoch einige Erweiterungen, die den Einsatz in Testautomatisierungenvereinfachen, und im Entwicklungstester überden Standard hinausgehende Funktionalitäten ermöglichen.Für OTX wurde ein Laufzeitinterpreter integriert.Das Framework stellt die Basisfunktionalitäten zur Verfügung,die für die Diagnose notwendig sind. Neben der Anbindungan die Laufzeitsysteme ist das vor allem die Werkzeugkonfiguration,die abgespeichert und wieder geladenwerden kann. Auch die Rollenverwaltung ist im Frameworkintegriert. Monaco unterstützt die Rollen „Adminstrator“und „Anwender“. Der Administrator kann Konfigurationenerstellen, abspeichern und sie dem Anwender zur Verfügungstellen. Dies betrifft sowohl Oberflächenkonfigurationen alsauch OTX-Abläufe. Diese können durch den Administratorim Tool erstellt und angepasst werden. Der Anwender kanndiese Vorkonfigurationen lediglich ins Tool laden und verwenden.Änderungen sind nur im geringen Umfang möglich.Dadurch ist sichergestellt, dass jeder Anwender nur dieFunktionen am Fahrzeug verwendet, für die er auch ausgebildetist. Innerhalb des Frameworks laufen als Komponentendie HMIcontrols. HMIcontrols übersetzen die Kommuni-

ENGINEERING TOOLSl AUTOMOTIVE 7-8.2011l43kationssicht, die durch den D-Server und dieOTX run time zur Verfügung gestellt werden,in die Anwendungssicht, die vom Nutzer fürseine spezielle Aufgabe erwartet wird. Dieskann eine Fehlerspeicherliste oder ein Messinstrument sein. Jedes HMIcontrol bringtfür den Administrator seinen eigenen Konfigurationsdialogmit. Neben Einstellungsmöglichkeiten,die allen HMIcontrols gemeinsamsind, können dort auch spezifischeEinstellungen vorgenommen werden. BeimFehlerspeicher wäre dies zum Beispiel, obStatusinformationen angezeigt werden sollenoder nicht, und beim Mess instrument,ob es als Zeigerinstrument dargestellt wirdoder als Balkendiagramm.Die Implementierung als Komponentenermöglicht es auf einfache Weise zusätzlicheAnwendungsfälle mit einem Kunden zudiskutieren, zu implementieren und nachträglichoder in einem spezifischen Setup zuinstallieren. Der Vorteil ist, dass diese Komponentevöllig unabhängig getestet werdenkann und die Systemintegrität in keinerWeise beeinflusst. Besonders wichtig werdendiese Erweite rungskomponentenimmer dann, wenn eine Anbindung an Logistiksysteme gefordert ist. Diese ist natürlichkundenspezifisch, kann also nicht ohne weiteresin ein Produkt implementiert werden,soll aber auch nicht für jeden Anwendersichtbar sein und muss deshalb unabhängiginstalliert werden.DatenversorgungDie Basis für DTS-Monaco sind ODX- undOTX-Laufzeitumgebungen. Die wichtigstenDaten im System sind also OTX- und ODX-Daten. Der Zugriff auf die ODX-Daten erfolgt– unabhängig ob von den HMIcontrols oderaus OTX heraus – über Namen („Drehzahl-Lesen“). Diese ODX-Namen müssen mitden Konfigurationen und den OTX Abläufenzusammen verwaltet werden. Dies erfolgtüber Projekte.Die OTX-Daten werden direkt im XML-Formatverarbeitet. Dies erleichtert das Handling,weil hier entweder Daten aus einer Spezifikationsphaseübernommen und angepasstwerden oder direkt für die Anwendungsfälledes Entwick lungstesters erstelltwerden. Datenkonvertierungen wären hiernur sperrig in der Bedienung. Für ODX-Daten gilt dies so nicht. Diese werden ineinem kleinen Bereich der Anwendungsfälleerstellt, in der Vielzahl der Anwendungsfällestehen sie allerdings schon unter Versionsverwaltungund sollen nur unter strengreglementierten Vorgaben verändert werden.Hier ist ein Schutz der Daten also angebracht.In DTS-Monaco erfolgt eine Konvertierungin ein Binärformat, das sowohl verschlüsseltals auch passwortgeschützt ist.Es lässt sich also auch mit einem Datenbankeditornicht öffnen, solange man dasPasswort nicht kennt. Das Datenformatunterstützt verschiedene Verwaltungsprozesse:Es ist sowohl möglich die Daten ineiner ODX-Datenbank in einer Dateizusammenzufassen – typischerweise dieDaten einer Baureihe –, als auch jedes Steuergerätmit seinen Varianten in einer eigeneDatei abzuspeichern. Beide Vorgehensweisenhaben Vor- und Nachteile.Neben diesen Daten können in einem Projektnoch weitere Datentypen verwaltetwerden, z. B. Simulationsdateien, die CAN-Matrix oder Filterdateien.Anwendungsfälle mit HMIcontrolsEines der zentralen HMIcontrols ist das DiagnosticServicesControl. Es deckt einen großenTeil der Anwendungsfälle Datenverifikationund Analyse ab. Dies erfolgt über eindreigeteiltes Fenster: Im ersten Teil kannman die Diagnosedienste der Datenbank ineiner Baumdarstellung „browsen“, sortiertnach Steuergeräten und nach Funktionsklassen.Der selektierte Diagnosedienstkann im zweiten Teil parametriert werden.Dies kann symbolisch erfolgen, indem derRequest Parameter „Variable“ auf „Drehzahl“gestellt wird, oder, indem direkt imBytestream die Hexwerte geändert werden.Auf diese Art und Weise können zu Testzweckenauch „not OK“-Werte eingestelltwerden, die symbolisch nicht erreichbarsind. Im dritten Teil werden die Ergebnissedargestellt, wobei konfigurierbar ist, oblediglich die Ergebnisse dargestellt werdenoder auch die Struktur der Ergebnisse mitdargestellt wird. Für einen Schnellzugriffkönnen zusätzlich Buttons konfiguriert werden,mit denen ohne lange Suche im Browserauf Diagnosedienste zugegriffen werdenkann.Zur Darstellung von Messgrößen stehenzwei unterschiedliche Methoden zur Verfügung:Messwertblöcke können textuell ineiner Liste dargestellt werden, was einensehr kompakten Überblick über die Größenermöglicht. Die Wiederholrate ist einstellbar,ein Zugriff nur auf manuelle Anforderung istauch möglich, um die Buslast gering zu halten.Daneben können Instrumente konfiguriertwerden, die Vielfalt dieser Darstellungsmöglichkeitenist erheblich. Übrigens

44lAUTOMOTIVE 7-8.2011l ENGINEERING TOOLSkönnen solche Instrumente auch verwendet werden, umbeispielsweise über Drehknöpfe oder Schalter Werte imSteuergerät zu verändern. Eine Darstellung mehrer Messwerteüber der Zeit ist zusätzlich möglich.Für die Flash-Programmierung steht ein eigenes HMIcontrolzur Verfügung. Dieses deckt zwei Anwendungsfälle ab: eskann sowohl für die Entwicklung der Funktion Flash-Programmierungverwendet werden, als auch für die reine Ausführung,um Programmstände zu aktualisieren oder Datensätzeauszutauschen. Im ersten Fall ist es möglich, über einfünfschrittiges Vorgehen Initialisierung, Kompatibilitätsprüfung,Programmierablauf, Validierung und Abschluss Teilfunktioneneinzeln im Steuergerät in Betrieb zu nehmen.Dadurch werden die einzelnen Testläufe deutlich beschleunigt.Im zweiten Fall wird lediglich das zu programmierendeDatenpaket ausgewählt und anschließend das Steuergerätauf Knopfdruck programmiert. In beiden Fällen wird der Programmierfortschrittüber eine Fortschrittsanzeige dargestellt.Die Behandlung von Fehlerspeicher und Identifikation ist ineinem HMIcontrol „Quicktest“ zusammengefasst. DerSchnelltest wird vor allem in der Versuchswerkstatt häufigeingesetzt. Dazu werden die Steuergeräteidentifikationengelesen und anschließend von allen erkannten Steuergerätender Fehlerspeicher. Ob zusätzlich die Umgebungsbedingungenabgefragt werden, kann der Anwender selbst konfigurieren.Die Herausforderung besteht darin, dass in der Versuchswerkstatthäufig nicht freigegebene Softwareständein den Steuergeräten programmiert sind, sodass keine Varianteerkannt werden kann. Ebenso häufig sind die gültigenODX-Daten noch nicht verfügbar, auch in diesem Fall kannkeine Variante erkannt werden und die Diagnose muss überdie Basisvariante erfolgen. Um den häufigen AnwendungsfallSchnelltest möglichst performant ausführen zu können,werden möglichst alle Steuergeräte parallel angesprochen.Dies ermöglicht in der Praxis Performance-Gewinne um denFaktor 4. Allerdings können nicht alle Steuergeräte parallelangesprochen werden. Zunächst müssen die alternativenSteuergeräte erkannt werden, da beispielsweise nur entwederdas Steuergerät für den 4-Zylinder-Dieselmotor oderdas für den 6-Zylinder-Benziner vorhanden sein kann. Genausomuss aber beachtet werden, dass entsprechend der Bus-Architektur Steuergeräte hinter Gateways häufig erst nachdem Gateway selbst angesprochen werden können.Sequenziell anzusprechende Steuergeräte werden voneinem Spezialisten konfiguriert.Darüber hinaus sind noch zahlreiche weitere Ansichten aufDiagnoseinformationen verfügbar, die hier jedoch nicht erörtertwerden sollen.TestdokumentationEs stehen mit DTS-Monaco verschiedene Möglichkeiten zurVerfügung, um die durchgeführten Tests zu dokumentieren.Der symbolische Trace zeichnet alle Sende- und Empfangsinformationenauf, die zwischen Tester und Steuergerät(en)ausgetauscht werden. Dabei werden zum einen die über dieODX-Daten interpretierten Werte gespeichert, zum anderenaber auch die auf hexadezimalem Level gesendeten undempfangenen Daten. Dadurch ist eine vollständige Prüfungauch im Nachgang zu einem Test darstellbar. Gleichzeitigermöglicht es aber auch die Dokumentation des durchgeführtenTests. Die Ablage erfolgt als XML-Datei, sodass Konvertierungenin andere Formate oder Filterung auf die imjeweiligen Kundenprozess benötigte Darstellung unproblematischmachbar sind.Parallel dazu kann auf der Ebene Bus-Kommunikation einTrace mitgeschrieben werden. Dieser Trace, in den meistenFällen ein CAN-Trace, erlaubt auch Auffälligkeiten in der Protokollverarbeitungsicher zu erkennen und zu dokumentieren.ZusammenfassungStandards haben sich im Diagnoseumfeld nicht nur durchgesetzt,es finden sich mit steigender Verwendungstiefesogar weitergehende Bereiche, die standardisiert werden.Den Anfang haben Diagnoseprotokolle gemacht, bei denenbald kein Hersteller mehr für die Implementierung seinerSonderlösungen in der steigenden Anzahl von Steuergerätenbezahlen wollte. Datenformate und Programmierschnittstellenzur Integration von Diagnoselösungen inunterschiedlichste Testsysteme waren ein logischer nächsterSchritt. Unabhängig davon, dass Single-source grundsätzlichzum Kostensparen geeignet ist, gewinnt man durchden breiten Einsatz der entsprechenden Standards auch anQualität. Sobald nämlich die Diagnose leicht zu integrierenist, spricht nichts dagegen, deren durchaus mächtigenMethoden auch in vielen Bereichen einzusetzen und damitzu einer viel größeren Testbreite und -tiefe zu kommen.Die Qualität ist aber das zentrale Argument für die Kundenbindung.Wenn man sieht, wie nervös die Hersteller bei Rükkrufaktionenreagieren, sieht man, dass die Nachricht verstandenwurde. Wenn man sieht, wie penibel die KundenPannenstatistiken durcharbeiten und zu ihrer Kaufentscheidungheranziehen, weiß man warum. Wenn aber ein Fahrzeugtrotz aller Bemühungen im Vorfeld einen Defekt hat,dann muss der Kunde nach einem möglichst kurzen Aufenthaltwieder zufrieden aus der Werkstatt fahren. Diagnose istdazu der Schlüssel.Sehr offensichtlich wird die Ersparnis, wenn man kalkuliert,was spezielle Prüfmechanismen in Entwicklung und Produktionkosten würden. Natürlich kann man zu Prüfzweckenspezielle Sensorik und Aktuatoren aufbauen, um Testsdurchzuführen. Natürlich kann man zusätzliche Werkzeugefür diese Prüfungen bereithalten. Viel schneller und preiswerter– und in vielen Fällen ausreichend gut – geht es aberüber die eingebauten Mechanismen im Fahrzeug mit ohnehinvorhandenen Diagnosetestern. Deshalb wird es genauso gemacht. (oe)Markus Steffelbauer leitet das Produktmanagementund verantwortet Entwicklung undMarketing der Hardware- und Softwareproduktebei der Softing Automotive ElectronicsGmbH. Daneben vertritt Steffelbauer seit vielenJahren Softing in verschiedenen Standardisierungsgremien,seit 2008 als Vertreter imASAM TSC (Technical Steering Committee).Softing Automotive Electronics GmbH@ www.softing.com