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

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-