AUTOMOTIVE 5-6.2011l13lereintrag („Umgebungsbedingungen“) und das Löschendes Fehlerspeichers – kommt dieselbe Basisfunktionalitätheute auch für verwandte Anwendungsfälle <strong>zum</strong> 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 <strong>zum</strong> 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 <strong>zum</strong> 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 <strong>zum</strong> 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(<strong>Teil</strong>-)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 <strong>zum</strong> 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 Entwicklungsprozess<strong>zum</strong> 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 <strong>zum</strong> Einsatz, <strong>zum</strong> 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