Deutsch (DE-CH-AT)English (United Kingdom)

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

(5 Bewertungen)

Wen­den wir uns jetzt dem eigent­li­chen Dia­gno­se­tes­ter zu. Die Grun­di­dee von ASAM war, stan­dar­di­sier­te Daten­for­ma­te und ein Lauf­zeit­sys­tem für die Imple­men­tie­rung eines Appli­ka­ti­ons- und Dia­gno­se­sys­tems zu ent­wer­fen. Die Imple­men­tie­rung eines sol­chen Lauf­zeit­sys­tems für den Bereich der Dia­gno­se stellt der soge­nann­te MCD 3D-Ser­ver dar. Das D steht für Dia­gno­se. Daher sagt man auch oft D-Ser­ver oder auch ODX-Ker­nel. Es ist stan­dar­di­siert in der ISO 22900 und läuft dort unter den Namen MVCI-Ser­ver, der auch hier ver­wen­det wird.

Standardisiertes Diagnoselaufzeitsystem nach ISO 22900Stan­dar­di­sier­tes Dia­gno­se­lauf­zeit­sys­tem nach ISO 22900

In der Abbil­dung sehen wir den Auf­bau eines sol­chen Lauf­zeit­sys­tems im Detail. Nach oben, zur eigent­li­chen Dia­gno­se­appli­ka­tion also der gra­phi­schen Ober­flä­che des Dia­gno­se­tes­ters, bie­tet das MVCI-Lauf­zeit­sys­tem eine stan­dar­di­sier­te Pro­gram­mier­schnitt­stel­le, eine API (App­li­ca­tion Pro­gram­ming Inter­fa­ce). Nach unten zum Fahr­zeug ver­wen­det die Lauf­zeit­um­ge­bung die D-PDU-API, um auf das Bus-Inter­fa­ce (VCI) zuzu­grei­fen. Die Kon­fi­gu­ra­tion des Lauf­zeit­sys­tems erfolgt über den ent­spre­chen­den ODX-Daten­satz.

Innerer Aufbau eines MVCI-Diagnosesystem nach ISO 22900Inne­rer Auf­bau eines MVCI-Dia­gno­se­sys­tem nach ISO 22900

Inner­halb des Lauf­zeit­sys­tems ist dafür der soge­nann­te Data-Pro­ces­sor zustän­dig, der auf den eigent­li­chen Daten­satz zugreift. Das heißt, der Pro­gram­mie­rer inter­a­giert nicht direkt mit den ODX-Daten, son­dern benutzt Funk­tio­nen, um auf den Daten­satz zugrei­fen zu kön­nen. Die Kom­mu­ni­ka­tion mit dem Bus-Inter­fa­ce wird durch den soge­nann­ten Com­mu­ni­ca­tion-Pro­ces­sor inner­halb des Lauf­zeit­sys­tems aus­ge­führt. Der Ablauf von Single-ECU-Jobs erfolgt im Job-Pro­ces­sor, wäh­rend Flash-Jobs durch den soge­nann­ten Flash-Data-Pro­ces­sor abge­wi­ckelt wer­den. Für alle die­se Ele­men­te gibt es in der Ser­ver-API ent­spre­chen­de Funk­ti­ons­grup­pen und ent­spre­chen­de Funk­ti­ons­auf­ru­fe.

Klas­sen­struk­tur

Betrach­ten wir nun die Klas­sen­struk­tur des MCD-Lauf­zeit­sys­tems soweit sie für die Pro­gram­mier-API, also den Anwen­der von Bedeu­tung ist. Sie sehen dabei eine Zwei­tei­lung. Auf der einen Sei­te gibt es Date­n­ob­jek­te, also Klas­sen, die ODX-Daten kap­seln. Auf der ande­ren Sei­te gibt es die Lauf­zeit­ob­jek­te, die im Wesent­li­chen die Metho­den und Akti­vi­tä­ten ent­hal­ten, um auf die­sen Daten bestimm­te Funk­tio­nen aus­zu­füh­ren. Zwi­schen den Date­n­ob­jek­ten und den Lauf­zeit­ob­jek­ten steht die Logi­cal-Link-Table, wel­che die Infor­ma­tion über die logi­schen Ver­bin­dun­gen des Dia­gno­se­tes­ters zu den ein­zel­nen Steu­er­ge­rä­ten ent­hält. Die Logi­cal-Links kön­nen auf drei ver­schie­de­ne Klas­sen­struk­tu­ren zugrei­fen. Für den Bereich der Appli­ka­tion gibt es die soge­nann­ten Col­lec­tor-Klas­sen, das sind Klas­sen, die Mess­da­ten und den Umgang mit den Mess­da­ten kap­seln. Für die Ver­stel­lung von Daten sind die Cha­rac­te­ri­stics vor­ge­se­hen, die ver­stell­ba­re Para­me­ter, Kenn­li­ni­en, Kenn­fel­der ent­hal­ten. Für die Dia­gno­se ist es die Klas­sen­struk­tur MCD Diag-Com-Pri­mi­ti­ves, die die Dia­gno­se­diens­te und Dia­gno­seab­läu­fe wie Single-ECU-Jobs, Mul­ti­ple-ECU-Jobs etc. kap­selt.

Grundstruktur eines MVCI-Diagnosesystem nach ISO 22900Grund­struk­tur eines MVCI-Dia­gno­se­sys­tem nach ISO 22900

Wir beschäf­ti­gen uns hier nicht mit dem Bereich Mes­sen und Kali­brie­ren (MC) son­dern aus­schließ­lich mit der Dia­gno­se (D). Obwohl ASAM mit MCD 3 eigent­lich den Anspruch erhebt sowohl die Dia­gno­se als auch den Bereich Mes­sen und Kali­brie­ren, also den Appli­ka­ti­ons­be­reich abzu­de­cken, gibt es hier his­to­risch begrün­det zwei ver­schie­de­ne Wel­ten. Bis­lang ist hier eine Har­mo­ni­sie­rung nicht gelun­gen.

Timeline ASAM AE MCDTime­li­ne ASAM AE MCD

Bei­spie­la­b­lauf im Job-Pro­ces­sor

Als ers­tes Bei­spiel, wie eine Dia­gno­se­an­wen­dung das Lauf­zeit­sys­tem ver­wen­det, soll hier der Auf­ruf eines MUL­TI­PLE-ECU-Jobs betrach­tet wer­den. Die Anwen­dung ver­wen­det bei­spiels­wei­se den Auf­ruf der Metho­de Exe­cu­te­Sync mit dem MUL­TI­PLE-ECU-Job als Argu­ment. Das Lauf­zeit­sys­tem wird, falls noch nicht gesche­hen, die Java-Vir­tual-Machi­ne ini­tia­li­sie­ren. Dann wird sie auf die Klas­sen­da­tei zugrei­fen, in der der eigent­li­che Job, der Pro­gramm­co­de die­ses Jobs gespei­chert ist. Die­ser Pro­gramm­co­de wird dann die ent­spre­chen­den Dia­gno­se­diens­te über das Lauf­zeit­sys­tem aus­füh­ren und so mit dem Steu­er­ge­rät kom­mu­ni­zie­ren. Das Lauf­zeit­sys­tem nimmt die ent­spre­chen­de Ant­wort vom Steu­er­ge­rät ent­ge­gen, ver­ar­bei­tet die­se und lie­fert das Ergeb­nis über ein MCDRe­sult-Objekt an die Anwen­dung zurück.

Beispielablauf im JOB-PROCESSORBei­spie­la­b­lauf im JOB-PRO­CES­SOR

Typi­scher Pro­gram­ma­b­lauf

Ein typi­scher Pro­gram­ma­b­lauf sieht wie folgt aus, sie­he Abbil­dung links: Zuer­st muss man das MCD-Sys­tem ini­tia­li­sie­ren. Dann lädt man ein bestimm­tes Pro­jekt. Damit wird der Daten­satz aus der ODX-Daten­bank gela­den. Danach wird ein Fahr­zeug aus­ge­wählt, also Typ, Modell­jahr und anschlie­ßend ein Logi­cal-Link geöff­net. Jetzt kön­nen die Dia­gno­se­diens­te erzeugt und aus­ge­führt wer­den. Die Ergeb­nis­se wer­den typi­scher­wei­se in einer Schlei­fe ver­ar­bei­tet und am Ende wird die gan­ze Objekt­struk­tur wie­der auf­ge­räumt. In der Abbil­dung rechts fin­den Sie den stark redu­zier­ten Pro­gramm­co­de für obi­ges Bei­spiel.

Schematischer ProgrammierablaufSche­ma­ti­scher Pro­gram­mier­ab­lauf

Ent­wick­lung von Dia­gno­se­an­wen­dun­gen

Die zuvor beschrie­be­nen Stan­dards für die Beschrei­bung der Dia­gno­se­da­ten und für ein Dia­gno­se­lauf­zeit­sys­tem sind sicher ein Weg in die rich­ti­ge Rich­tung und vor dem Hin­ter­grund der wach­sen­den Kom­ple­xi­tät in der Fahr­zeug­dia­gno­se nicht ersetz­bar. Dies ist jedoch nur eine Sei­te der Medail­le. Moder­ne Fahr­zeug­dia­gno­se setzt sich nicht allein aus ein­zel­nen Ser­vices zusam­men, son­dern vie­le tau­sen­de Abläu­fe, die mit dem MVCI-Ser­ver und ODX nicht abbild­bar sind.

OTX-Designer der Firma emotive GmbHOTX-Desi­gner der Fir­ma emo­ti­ve GmbH

Die­se Lücke schließt das in der ISO 13209 stan­dar­di­sier­te Aus­tausch­for­mat für Dia­gno­se­se­quen­zen OTX, auf wel­ches im nächs­ten Kapi­tel aus­führ­lich ein­ge­gan­gen wird.

Siehe auch

  • Erstellt
    12. Januar 2011
  • Version
    4
  • Geändert
    17. Februar 2011
  • Zugriffe
    49973