Einfuehrung ODX

Nach­dem wir in den letz­ten Kapi­teln gese­hen haben, wie die Onboard-Kom­mu­ni­ka­tion und die Appli­ka­ti­ons­da­ten mit stan­dar­di­sier­ten Daten­for­ma­ten beschrie­ben wer­den kön­nen, wen­den wir uns in die­sem Kapi­tel den Dia­gno­se­da­ten zu, für die das Daten­for­mat ODX (Open Dia­gno­stic Data eXchan­ge, ISO 22901) spe­zi­fi­ziert wur­de.

MVCI-Ser­ver (ASAM 3D-Ser­ver, ODX-Ker­nel)

Dia­gno­se­pro­zess­ket­te – Aktu­el­ler Zustand

Die Welt der Dia­gno­se ist dadurch gekenn­zeich­net, dass es sehr vie­le betei­lig­te Stel­len gibt. Es fängt an in der Ent­wick­lung des Fahr­zeugher­stel­lers, der das Fahr­zeug ent­wirft und sei­ne ein­zel­nen Kom­po­nen­ten defi­niert. Die Ent­wick­lung der Kom­po­nen­ten erfolgt typi­scher­wei­se bei Sys­tem­lie­fe­ran­ten, die in meh­re­ren Mus­ter­run­den zusam­men mit dem Fahr­zeugher­stel­ler die Elek­tro­nik­sys­te­me ent­wi­ckeln. Am Ende der Ent­wick­lungs­pha­se steht die Über­lei­tung in die Pro­duk­tion. Inner­halb der Pro­duk­tion müs­sen die ein­zel­nen Elek­tro­nik­kom­po­nen­ten, die in das Fahr­zeug ein­ge­baut wer­den natür­lich auch getes­tet wer­den. Des­we­gen wird die Dia­gno­se hier inner­halb der Pro­duk­tion eben­falls bereits ein­ge­setzt um das Fahr­zeug wäh­rend der Fer­ti­gung zu prü­fen. Die eigent­li­che Ent­wick­lung der Dia­gno­se erfolgt typi­scher­wei­se nicht in der Pro­duk­tion selbst, son­dern mit Hil­fe von Dia­gno­se­sys­tem­lie­fe­ran­ten, die ent­spre­chen­de Prüfab­läu­fe defi­nie­ren bzw. nach den Vor­ga­ben des Her­stel­lers umset­zen. Letzt­end­lich muss noch die Werk­statt­ket­te des Fahr­zeugher­stel­lers in die Lage ver­setzt wer­den, die Fahr­zeu­ge zu war­ten und Feh­ler fest­zu­stel­len. Des­halb muss für den Ser­vice eben­falls ein Dia­gno­se­kon­zept aus­ge­ar­bei­tet wer­den. Alle Stel­len in die­ser Pro­zess­ket­te arbei­ten typi­scher­wei­se mit unter­schied­li­chen Werk­zeu­gen, unter­schied­li­chen Tools und – jeden­falls in der Ver­gan­gen­heit – auch mit unter­schied­li­chen Daten­for­ma­ten sowie unter­schied­li­chen Dia­gno­se­test­sys­te­men. Als Fol­ge der vie­len betei­lig­ten Stel­len und der hete­ro­ge­nen Werk­zeu­ge und Daten­for­ma­te, erge­ben sich natür­lich erheb­li­che Pro­ble­me bei der Daten­wei­ter­ga­be, bei der Kon­sis­tenz der Daten und ins­be­son­de­re ein erheb­li­cher Arbeits­auf­wand.

Die heu­ti­ge Dia­gno­se­pro­zess­ket­te ist gekenn­zeich­net durch einen hete­ro­ge­nen Aus­tausch von dia­gno­se­re­le­van­ten Infor­ma­tio­nen

Dia­gno­se­pro­zess­ket­te – Ziel

Die Grun­di­dee von ASAM besteht nun darin, mit Hil­fe eines gemein­sa­men Daten­for­mats die Daten­be­reit­stel­lung und die Daten­wei­ter­ver­ar­bei­tung zu ver­ein­fa­chen und zu ver­ein­heit­li­chen.

Die von ASAM vor­ge­schla­ge­ne Lösung die­ser Pro­ble­ma­tik ent­hält zwei Tei­le. Man wird sicher nicht in der Lage sein, die Anzahl der betei­lig­ten Stel­len zu redu­zie­ren. Ganz im Gegen­teil, durch zuneh­men­de Koope­ra­tion ver­schie­de­ner Her­stel­ler wird die Anzahl der Betei­lig­ten sicher noch wei­ter anstei­gen. Aber man kann zumin­dest für ein gemein­sa­mes Daten­for­mat und damit für eine rela­tiv ein­fa­che Wei­ter­ga­be der Daten von einer Stel­le zur ande­ren sor­gen. Das ist die Grun­di­dee von ODX, des „Open Dia­gno­stic Data Exchan­ge“ Daten­for­mats: Eine stan­dar­di­sier­te Daten­bank für Dia­gno­se­da­ten, die in einer gemein­sa­men Quel­le liegt und auf die alle betei­lig­ten Stel­len Zugriff haben.

ODX – Aus­tausch von stan­dar­di­sier­ten Dia­gno­se­da­ten über alle Pha­sen des Fahr­zeug­le­bens­zy­klus – Grund­prin­zip: Single Sour­ce

Der zwei­te Teil der von ASAM vor­ge­schla­ge­nen Lösung kon­zen­triert sich auf den Dia­gno­se­tes­ter. Wäh­rend frü­her Dia­gno­se­tes­ter typi­scher­wei­se pro­prie­tä­re Sys­te­me waren, schlägt ASAM vor, einen uni­ver­sel­len Dia­gno­se­tes­ter mit einem stan­dar­di­sier­ten Lauf­zeit­sys­tem zu benut­zen, der nicht von jedem Fahr­zeugher­stel­ler neu pro­gram­miert wer­den muss. Er ver­fügt über ein stan­dar­di­sier­tes Inter­fa­ce auf wel­ches das Fahr­zeug­dia­gno­se-Bus­sys­tem zugrei­fen kann und er wird über die ODX Daten­bank kon­fi­gu­riert. Die Idee ist, den Dia­gno­se­tes­ter nicht mehr fahr­zeu­g­ab­hän­gig zu pro­gram­mie­ren, son­dern einen gene­ri­schen Dia­gno­se­tes­ter über den fahr­zeugs­pe­zi­fi­schen ODX Daten­satz ein­fach zu para­me­trie­ren.

Dia­gno­se­lauf­zeit­sys­tem MVCI nach ISO 22900 (ASAM AE MCD 3D)

ODX – Was ist das?

Das Daten­for­mat ODX ent­stand als ASAM Spe­zi­fi­ka­tion unter der Rubrik MCD 2D und ist mitt­ler­wei­le als ISO 22901-1 stan­dar­di­siert. Als Aus­tausch­for­mat für alle dia­gno­se­re­le­van­ten Daten müs­sen meh­re­re Berei­che abge­deckt wer­den:

• Pro­to­koll­s­pe­zi­fi­ka­tion für die Kom­mu­ni­ka­tion zwi­schen Tes­ter & Steu­er­ge­rät
• Kom­mu­ni­ka­ti­ons­pa­ra­me­ter für ISO/OSI-Schich­ten und Steu­er­ge­rä­te­soft­wa­re
• Steu­er­ge­rä­te-Pro­gram­mier­da­ten (Flash)
• Beschrei­bung der Fahr­zeug­schnitt­stel­le (Steck­ver­bin­der und Pin-Bele­gung)
• Steu­er­ge­rä­te-Kon­fi­gu­ra­tion (Vari­an­ten­ko­die­rung)
• Erlaubt Über­gang von der Diens­te-zen­trier­ten zur Funk­ti­ons-zen­trier­ten Dia­gno­se­ent­wick­lung

Es geht also um das Dia­gno­se­pro­to­koll (UDS, KWP 2000, OBD) in der jeweils her­stel­ler­spe­zi­fi­schen Ausprä­gung, um die Kom­mu­ni­ka­ti­ons­pa­ra­me­ter des betei­lig­ten Bus­sys­tems (Trans­port und Data­link-Ebe­nen), die Fahr­zeug­schnitt­stel­le, Steck­ver­bin­dun­gen, Pin-Bele­gun­gen, Pro­gram­mier­da­ten­sät­ze für die Werk­statt, Vari­an­ten­ko­die­rung etc. Außer­dem soll ein Über­gang von einer Diens­te ori­en­tier­ten Dia­gno­se – d.h. eine mehr an den Kom­mu­ni­ka­ti­ons­bot­schaf­ten ori­en­tier­te Dia­gno­se – zu einer funk­ti­ons­ori­en­tier­ten Dia­gno­se mög­lich wer­den. Da es aus Sicht der Werk­statt völ­lig uner­heb­lich ist, mit wel­chen Bot­schaf­ten eine bestimm­te Auf­ga­be erfüllt wird. Eine Werk­stat­t­or­ga­ni­sa­tion hat bestimm­te Auf­ga­ben zu lösen und dafür ver­sucht man die­se Dia­gno­se zukünf­tig funk­ti­ons- statt Diens­te zen­triert zu ent­wer­fen.

Das Ziel ist sicher­lich, ODX in Ver­bin­dung mit dem gene­ri­schen Lauf­zeit­sys­tem ein­zu­set­zen, aber in der Ein­füh­rungs­pha­se wird man ODX sicher zunächst als rei­nes Daten­for­mat für den Daten­aus­tausch zwi­schen den Betei­lig­ten ver­wen­den.

Anwen­dungs­bei­spie­le

Im Ide­al­fall wird ODX in allen Pro­jekt­pha­sen und bei allen Betei­lig­ten ein­ge­setzt. Beim OEM, bei sei­nen Zulie­fe­rern, in der Pro­duk­tion und in der Werk­statt.

ODX ist aber auch dann ein­setz­bar, wenn die Dia­gno­se­pro­zess­ket­te noch nicht durch­gän­gig auf ASAM Stan­dards basiert, son­dern wenn ODX nur als Aus­tausch­for­mat z. B. inner­halb der Ent­wick­lung ein­ge­setzt wird.

Eben­so ist ODX für die Ver­tei­lung der Dia­gno­se­da­ten vom Her­stel­ler zu sei­nem Händ­ler­netz geeig­net.

Vor­tei­le und Nut­zen

Den Vor­teil und Nut­zen beim Ein­satz von ODX haben alle betei­lig­ten Stel­len. Das fängt an beim OEM, des­sen Auf­wand sich deut­lich redu­ziert, wenn er nur eine ein­zi­ge Daten­quel­le mit einem ein­heit­li­chen Daten­for­mat zu pfle­gen hat, wenn in die­ser Daten­bank gleich­zei­tig auch die Ver­wal­tung ver­schie­de­ner Fahr­zeug- und Gerä­te­va­ri­an­ten erfol­gen kön­nen und er die Daten nicht bei der Wei­ter­ga­be an die ver­schie­de­nen Betei­lig­ten jedes Mal neu erstel­len und veri­fi­zie­ren muss.

Des Wei­te­ren ver­ein­facht sich die Spe­zi­fi­ka­tion für die Zulie­fe­rer und die Doku­men­ta­tion der Dia­gno­se, denn ODX ist in der Lage bei­des zu leis­ten. Es kann als Spe­zi­fi­ka­tion für den Zulie­fe­rer die­nen, gen­au­so wie als Doku­men­ta­tion für die zuge­lie­fer­te Kom­po­nen­te, soweit es die Dia­gno­se angeht.

Beim Zulie­fe­rer kann ODX für die Gene­rie­rung des Dia­gno­se­pro­to­koll­sta­pels ein­ge­setzt wer­den. Das heißt, statt die Dia­gno­se­soft­wa­re nach den ODX Vor­ga­ben zu pro­gram­mie­ren kann man mit ent­spre­chen­den Werk­zeu­gen aus den ODX-Daten­sät­zen die not­wen­di­ge Soft­wa­re für den Dia­gno­se­pro­to­koll­sta­pel auto­ma­tisch erzeu­gen.

Gleich­zei­tig kön­nen auf Basis von ODX auch die Soft­wa­re-Test­sys­te­me, mit denen der Pro­to­koll­sta­pel im rea­len Steu­er­ge­rät zu tes­ten ist, auto­ma­tisch kon­fi­gu­riert wer­den. Dadurch wer­den Soft­wa­re­tests zuver­läs­si­ger, da man über auto­ma­ti­sier­te Tools direkt gegen die ODX-Spe­zi­fi­ka­tion tes­ten kann.

In der Pro­duk­tion ver­ein­facht sich die Ent­wick­lung der Pro­duk­ti­ons­tes­ter, wenn sie auf die ODX-Daten­sät­ze zugrei­fen kön­nen. Es ist sicher­ge­stellt, dass die­sel­ben veri­fi­zier­ten Daten­sät­ze wie in der Ent­wick­lung ver­wen­det wer­den. Damit redu­zie­ren sich die Anzahl der Feh­ler und der Gesamt­auf­wand.

Der Bereich After-Sales pro­fi­tiert eben­falls von ODX. Der Auf­wand bei der Erstel­lung und Wei­ter­ga­be der Dia­gno­se­da­ten an das Werk­statt­netz wird deut­lich gerin­ger, da bereits veri­fi­zier­te Daten­sät­ze vor­lie­gen.

Da das Daten­for­mat stan­dar­di­siert ist, wird der Fahr­zeugher­stel­ler vom Tes­ter-Her­stel­ler mehr oder weni­ger unab­hän­gig. Gleich­zei­tig kön­nen stan­dar­di­sier­te Daten­sät­ze sehr viel leich­ter als Dia­gno­se­tes­ter­pro­gram­me wei­ter­ge­ge­ben wer­den. Davon pro­fi­tie­ren auch die Werk­stät­ten. So ist es in Zukunft vor­stell­bar, dass die Werk­statt nicht mehr im Abon­ne­ment Soft­wa­reu­p­da­tes für ihren Werk­statt­tes­ter kau­fen muss, son­dern sich je nach Bedarf die ent­spre­chen­den Daten­sät­ze für Fahr­zeu­ge, die aktu­ell zu repa­rie­ren sind, über das Inter­net her­un­ter­lädt.

Durch die Ein­füh­rung des stan­dar­di­sier­ten Daten­for­mats sind die Dia­gno­se­da­ten gleich­zei­tig in einem frei zugäng­li­chen For­mat doku­men­tiert. Damit las­sen sich her­stel­le­ru­n­ab­hän­gi­ge Abgas­test­sys­te­me für TÜV oder DEKRA sowie für freie Werk­stät­ten sehr viel leich­ter ent­wi­ckeln als mit den heu­ti­gen, oft noch pro­prie­tä­ren Daten­for­ma­ten.

Nach­fol­gend wer­den alle Vor­tei­le noch­mals auf­ge­lis­tet:

• Zulie­fe­rer
  • Auto­ma­ti­sche Kon­fi­gu­ra­tion der Steu­er­ge­rä­te­dia­gno­se­da­ten und des Kom­mu­ni­ka­ti­ons­pro­to­kolls
  • Auto­ma­ti­sche Erzeu­gung der Doku­men­ta­tion (Steu­er­ge­rä­te­dia­gno­se-daten = Doku­men­ta­tion)
  • Auto­ma­ti­sche Kon­fi­gu­ra­tion des Ent­wick­lungs­tes­ters zur Über­prü­fung der imple­men­tier­ten Dia­gno­se­diens­te
  • Maschi­nen­les­ba­res For­mat (XML) für den Import in die eige­ne Dia­gno­se­da­ten­bank
  • Kode-Gene­rie­rung zur Kon­fi­gu­ra­tion des Dia­gno­se Ker­nels

• Fahr­zeugher­stel­ler – Ent­wick­lung
  • Auf­wands­re­duk­tion bei der Dia­gno­se­da­ten­er­stel­lung
  • Single-Sour­ce Prin­zip: Alle Ent­wick­lungs­tes­ter unter­stüt­zen das­sel­be For­mat.
  • Nur ein For­mat für den Im- und Export mit der zen­tra­len Dia­gno­se­da­ten­bank

• Fahr­zeugher­stel­ler – Pro­duk­tion
  • Auf­wands­re­duk­tion bei der Dia­gno­se­da­ten­ve­ri­fi­ka­tion – Daten müs­sen nur ein­mal veri­fi­ziert wer­den
  • Wie­der­ver­wen­dung von veri­fi­zier­ten Dia­gno­se­da­ten
  • Weni­ger Feh­ler wegen gerin­ge­rer Anzahl von Pro­zess­schrit­ten
  • End-Of-Line Tes­ter ver­wen­den die­sel­ben Dia­gno­se­da­ten und den­sel­ben Dia­gno­se­tes­ter wie in der Ent­wick­lung

• Fahr­zeugher­stel­ler – After Sales
  • Ein­fa­che­re Wie­der­ver­wend­bar­keit von veri­fi­zier­ten Dia­gno­se­da­ten
  • Gerin­ge­rer Auf­wand bei der Ver­tei­lung der Dia­gno­se­da­ten
  • „Abru­fen“ von Dia­gno­se­da­ten via Intra­net/Inter­net vs. „Bereit­stel­len“ von Soft­wa­reu­p­da­tes auf CD-Rom
  • Ein For­mat für die ver­schie­de­nen Dia­gno­se­sys­te­me

• Tool­her­stel­ler
  • Gerin­ge­rer Auf­wand bei der Erstel­lung von Dia­gno­se­appli­ka­tio­nen durch die Ver­wen­dung eines gene­ri­schen daten­ge­trie­be­nen Ansat­zes
  • Focus: Dia­gno­se-Kil­ler-Appli­ka­tio­nen vs. Bits & Bytes
  • Ein­fa­che­re Wie­der­ver­wend­bar­keit von veri­fi­zier­ten Dia­gno­se­da­ten

• Werk­statt
  • Wie­der­ver­wen­dung von veri­fi­zier­ten Dia­gno­se­da­ten
  • Tes­ter Kon­fi­gu­ra­tion durch Daten-Dow­n­load vs. Soft­wa­re Modi­fi­ka­tion
  • Dow­n­load nach Bedarf vs. Kauf eines Soft­wa­reu­p­da­tes

• Gesetz­ge­ber
  • Stan­dar­di­sier­tes For­mat für die Doku­men­ta­tion der rele­van­ten Dia­gno­se­da­ten (z.B. DTCs, PIDs, etc.)
  • Ermög­licht her­stel­le­ru­n­ab­hän­gi­ge Scan-Tools und Tools für Ser­vice und Instan­t­hal­tung
  • Erfüllt die For­de­rung frei­er Werk­stät­ten auf Zugang zu erwei­ter­ten Dia­gno­se­da­ten

Zusammenfassung Vorteile

• Wie­der­ver­wend­bar­keit (Single-Sour­ce)
• Erhö­hung der Sicher­heit, durch weni­ger Pro­zess­schrit­te
• Ein­fa­che und schnel­le Veri­fi­zier­bar­keit
• Ver­bes­se­rung der Wart­bar­keit
• XML For­mat: Maschi­nen- und Men­schen­les­bar­keit
• Her­stel­le­ru­n­ab­hän­gig­keit
• Auto­ma­ti­sier­te Tools zur Kon­fi­gu­ra­tion, Doku­men­ten­er­stel­lung, Kode-Erzeu­gung etc.
• Gene­ri­sche Erstel­lung von Dia­gno­se­appli­ka­tio­nen

Risi­ken der ODX / MVCI Ein­füh­rung

Bei allen Vor­tei­len von ODX darf natür­lich nicht über­se­hen wer­den, dass das Ein­füh­ren des ASAM basier­ten Kon­zepts auch eine Rei­he von Risi­ken birgt.

Zum einen haben die Her­stel­ler bereits heu­te Dia­gno­se­werk­zeu­ge, Dia­gno­se­tes­ter im Ein­satz und die Umstel­lung wird natür­lich bedeu­ten, dass man die alten Sys­te­me nicht weg­wer­fen kann, son­dern dass man sie wei­ter­pfle­gen muss. Das heißt zunächst ein­mal ent­steht durch ODX kei­ne Kos­te­n­er­spar­nis, son­dern zunächst ein­mal ent­steht ein Zusatz­auf­wand. Dann wird man die Umstel­lung natür­lich nicht schlag­ar­tig durch­füh­ren kön­nen, son­dern man wird sie schritt­wei­se durch­füh­ren müs­sen. Das bedeu­tet, zunächst wird man ODX als rei­nes Daten­aus­tausch­for­mat ein­füh­ren mit Import und Export zu den pro­prie­tä­ren Sys­te­men. Dann wird man Zug um Zug die gesam­te Dia­gno­se­da­ten­ba­sis auf ODX umstel­len und am Ende wird man erst die stan­dar­di­sier­ten Dia­gno­se­tes­ter ein­füh­ren. Zu den tech­ni­schen Risi­ken kom­men natür­lich auch noch wirt­schaft­li­che Risi­ken, denn es ist kei­nes­wegs klar, ob ein stan­dar­di­sier­tes Dia­gno­se­tes­ter-Kon­zept wirk­lich für die Her­stel­ler die heu­te von der Ent­wick­lung von Dia­gno­se­tes­tern und Dia­gno­se­werk­zeu­gen leben ein erfolg­rei­ches Geschäfts­mo­dell ist. Und wenn die Her­stel­ler das gan­ze wirt­schaft­lich nicht erfolg­reich umset­zen kön­nen, wird das Kon­zept ster­ben.

Siehe auch

Einführung in die Anwendungen für Diagnose (ASAM MCD)

Diagnoselaufzeitsystem MVCI nach ISO 22900 (ASAM AE MCD 3D)

OTX – Open Test sequence eXchange Datenformat