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

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

(12 Bewertungen)

In die­sem Teil unse­res Semi­nars über Dia­gno­se­sys­te­me im Auto­mo­bil wer­den wir uns mit Anwen­dun­gen für das Mes­sen, das Kali­brie­ren und die Dia­gno­se beschäf­ti­gen. Im Blick auf das ISO/OSI Schich­ten­mo­dell bewe­gen wir uns ober­halb des eigent­li­chen Modells auf der Ebe­ne der Anwen­dun­gen.

Open System Interconnection (OSI) Schichtenmodell (ISO 1978)Open Sys­tem Inter­connec­tion (OSI) Schich­ten­mo­dell (ISO 1978)

Eine wich­ti­ge Rol­le spielt auf die­sem Gebiet die ASAM e.V. (Asso­cia­tion for Stan­dar­di­za­tion of Auto­ma­tion and Mea­su­ring Sys­tems). Gegrün­det wur­de sie 1991 als eine Ini­tia­ti­ve von Fahr­zeugher­stel­lern in Ver­bin­dung mit deren wich­tigs­ten Zulie­fe­rern. Mitt­ler­wei­le hat ASAM über 120 Mit­glieds­un­ter­neh­men, dar­un­ter alle wich­ti­gen Fahr­zeugher­stel­ler, ihre Zulie­fe­rer und eine gan­ze Rei­he von Tool­her­stel­lern. Ziel der Ver­ei­ni­gung ist es, Stan­dards für das Mes­sen und Kali­brie­ren, das heißt für die Appli­ka­tion und Dia­gno­se zu schaf­fen.

Der Bereich der ASAM Stan­dards lässt sich grob in zwei The­men­grup­pen unter­glie­dern:

Der ers­te Bereich ist ASAM AE – AE steht für Auto­mo­ti­ve Elec­tro­nics. Hier geht es um den Teil der Appli­ka­ti­ons- und Dia­gno­se­werk­zeu­ge, die das eigent­li­che Inter­fa­ce zum Fahr­zeug dar­stel­len. Also im Wesent­li­chen die Buspro­to­kol­le und die dar­über lie­gen­den Schich­ten, mit denen appli­ziert und kom­mu­ni­ziert wird. Die dazu ein­ge­setz­ten Werk­zeu­ge – die Haupt­grup­pe die­ser Stan­dards – lau­fen unter dem Namen MCD (Mea­su­re­ment Cali­bra­tion and Dia­gno­sis).

Im fol­gen­den Teil des Semi­nars wer­den wir näher ins­be­son­de­re auf die die Dia­gno­se betref­fen­den Tei­le von ASAM AE ein­ge­hen.

Der zwei­te große Bereich umfasst ASAM CAT – CAT steht für Com­pu­ter Aided Tes­ting. Dabei geht es um die Steue­rung und Auto­ma­ti­sie­rung von Prüf­stän­den. Die­ser Teil ist hier von unter­ge­ord­ne­ter Bedeu­tung.

Überblick ASAM AE MCD D (MVCI)

Die Grun­di­dee lässt sich am bes­ten beschrei­ben, wenn man sich auf dem fol­gen­den Bild die Struk­tur eines typi­schen ASAM Appli­ka­ti­ons- und Dia­gno­se­sys­tems anschaut:

Überblick MVCI-Server (ASAM AE MCD D)Über­blick MVCI-Ser­ver (ASAM AE MCD D)

Ganz oben sind die Test- und Dia­gno­se­an­wen­dun­gen zu sehen, ganz unten die Steu­er­ge­rä­te im Fahr­zeug, ver­bun­den über ein Bus­sys­tem. Das Appli­ka­ti­ons­sys­tem selbst ist über eine Hard­wa­re, das so genann­te Vehic­le Com­mu­ni­ca­tion Inter­fa­ce, kurz VCI an das Bus­sys­tem und damit an das Fahr­zeug ange­kop­pelt. Die Schnitt­stel­le zu die­sem Busin­ter­fa­ce ist in der Ebe­ne MCD 1 defi­niert. Als Pro­gram­mier­schnitt­stel­le für das Busin­ter­fa­ces gibt es unter ande­rem die D-PDU API (API = App­li­ca­tion Pro­gram­ming Inter­fa­ce), wel­che in der ISO 22900-2 stan­dar­di­siert ist.

Dar­über liegt ein Lauf­zeit­sys­tem, das die Appli­ka­tion und Dia­gno­se von der dar­un­ter lie­gen­den Hard­wa­re unab­hän­gig machen soll. Die­ses Lauf­zei­tin­ter­fa­ce ist in der ISO 22900 stan­dar­di­siert und wird als MVCI Run­ti­me Sys­tem bezeich­net. Ande­re Bezeich­nun­gen hier­für sind MVCI-Ser­ver, ASAM 3D-Ser­ver oder ein­fach nur D-Ser­ver.

Die für die Dia­gno­se rele­van­ten fahr­zeug- und steu­er­ge­rä­te­s­pe­zi­fi­schen Daten sind nicht Bestand­teil des Lauf­zeit­sys­tems, son­dern sind in einer Daten­bank aus­ge­la­gert. Das Daten­for­mat die­ser Daten­bank wird auf der Ebe­ne MCD 2 beschrie­ben. Es ist in der ISO 22901-1 stan­dar­di­siert und bes­ser bekannt unter sei­ner Abkür­zung: ODX (Open Dia­gno­stics data eXchan­ge).

Dar­über liegt die ASAM Schicht MCD 3. Dies ist das Pro­gram­mier­in­ter­fa­ce, über das das Lauf­zeit­sys­tem pro­gram­miert wird. Die­se Schicht wird im All­ge­mei­nen als D-Ser­ver API bezeich­net.

Sehen wir uns nun an, wie eine typi­sche Appli­ka­ti­ons- oder Dia­gno­se­an­wen­dung in die­sem MCD-Sys­tem ablau­fen könn­te. Es beginnt mit der Fra­ge­stel­lung, die auf der Ebe­ne der Anwen­dung gestellt wird, zum Bei­spiel: „Wie groß ist die aktu­el­le Motor­dreh­zahl?“. Dazu ruft die Test- und Dia­gno­se­an­wen­dung über die D-Ser­ver API auf Ebe­ne MCD 3 eine Funk­tion auf, mit der die­se Anfra­ge an das Test­sys­tem gestellt wird. Das Test­sys­tem weiß nun, dass es dazu eine Bus­bot­schaft an das Steu­er­ge­rät im Fahr­zeug sen­den muss. Es weiß aber noch nicht wel­che. Des­we­gen wird in der Dia­gno­se­da­ten­bank nach­ge­schaut, wie die Bus­bot­schaft kurz PDU (Pro­to­col Data Unit) zum Aus­le­sen der Dreh­zahl lau­tet. Die­se Bus­bot­schaft ist in der Daten­bank beschrie­ben und wird an das Lauf­zeit­sys­tem zurück­ge­ge­ben. Das Lauf­zeit­sys­tem wie­der­um gibt sie über die MCD 1 Schnitt­stel­le (D-PDU API) an das Busin­ter­fa­ce wei­ter. Vom Busin­ter­fa­ce wird die Bot­schaft dann über das Bus­sys­tem als Dia­gno­se-Request an das Steu­er­ge­rät gesen­det. Für den Appli­ka­ti­ons­be­reich wäre es ent­spre­chend der Appli­ka­ti­ons-Request. Das Steu­er­ge­rät ant­wor­tet mit einer ent­spre­chen­den Respon­se, die wie­der­um vom Fahr­zeu­gin­ter­fa­ce ent­ge­gen­ge­nom­men und über die MCD 1 Schicht ent­packt und als Ant­wort­bot­schaft auf­be­rei­tet wird. Typi­scher­wei­se wird die Dreh­zahl als steu­er­ge­rä­te­s­pe­zi­fi­scher Hexa­de­zi­mal­wert zurück­ge­lie­fert. Der Anwen­der möch­te aber die Dreh­zahl in Umdre­hung pro Minu­te sehen. Es muss also eine Umrech­nung statt­fin­den. Wie die­se Umrech­nung geschieht, wie die steu­er­ge­rä­te­s­pe­zi­fi­schen Hexa­de­zi­mal­wer­te in den phy­si­ka­li­schen Dreh­zahl­wert umzu­rech­nen sind, steht wie­der­um in der Daten­bank. Daher wird die emp­fan­ge­ne Ant­wort­bot­schaft über die Daten­bank umge­setzt und in eine rea­le phy­si­ka­li­sche Dreh­zahl umge­rech­net und schließ­lich über die MCD 3 Schicht an die Test- und Dia­gno­se­an­wen­dung nach oben gesen­det.

Wir haben hier also vor allem drei ver­schie­de­ne Ebe­nen oder Auf­ga­ben­be­rei­che, die ASAM abzu­de­cken ver­sucht. Der ers­te ist das Busin­ter­fa­ce zum Bus­sys­tem inner­halb des Fahr­zeugs. Das ist die Schicht MCD 1. Die Idee dahin­ter ist, über stan­dar­di­sier­te Schnitt­stel­len ver­schie­de­ne Busin­ter­fa­ces unter­schied­li­cher Her­stel­lers ein­set­zen und/oder aus­tau­schen zu kön­nen.

Die zwei­te Ebe­ne betrifft die Daten. Die Daten­bank einer Fahr­zeug­bau­rei­he setzt sich aus den ein­zel­nen Daten­sät­zen der ver­schie­de­nen Steu­er­ge­rä­te zusam­men. Die­se wer­den meist von ver­schie­de­nen Zulie­fe­rern bereit­ge­stellt und sol­len über den gesam­ten Lebens­zy­klus eines Fahr­zeugs kon­sis­tent und wie­der­ver­wend­bar bereit­ste­hen. Im wei­te­ren Teil des Semi­nars wird detail­liert auf den hier ver­wen­de­ten Stan­dard ODX ein­ge­gan­gen. Für den Bereich MC, also Appli­ka­tion heißt das Daten­for­mat ASAP 2.

Die drit­te Ebe­ne ist das Lauf­zeit­sys­tem. Das Lauf­zeit­sys­tem kap­selt alle für das Ver­sen­den, Emp­fan­gen und Umrech­nen nöti­gen Algo­rith­men. Die zuge­hö­ri­ge API gibt der Dia­gno­se- oder Appli­ka­ti­ons­an­wen­dung Mög­lich­kei­ten zum Zugriff auf die Daten­bank und die Lauf­zeit­funk­tio­nen.

Wir wer­den in den fol­gen­den Abschnit­ten genau­er auf die ein­zel­nen Ebe­nen MCD 1 bis MCD 3 ein­ge­hen.

Timeline

Wie wir vor­her gese­hen haben exis­tiert die ASAM-Ini­tia­ti­ve seit Anfang der 90er Jah­re. Es gibt also eine ent­spre­chend lan­ge His­to­rie und eine gan­ze Rei­he von Ver­sio­nen der ein­zel­nen Pro­to­kol­le­be­nen, die mehr oder weni­ger par­al­lel und seri­ell ent­stan­den sind.

ASAM TimelineASAM Time­li­ne

Begin­nen wir mit dem Appli­ka­ti­ons­pro­to­koll CCP (CAN Cali­bra­tion Pro­to­col), ent­stan­den Anfang der 90er Jah­re, als CAN zum ers­ten Mal für die Appli­ka­tion ein­ge­setzt wur­de. Dies ist mitt­ler­wei­le bei Ver­sion 2.2. Der desi­gnier­te Nach­fol­ger des CAN Cali­bra­tion Pro­to­cols XCP (Exten­ded Cali­bra­tion Pro­to­col), liegt heu­te in der Ver­sion 1.1 vor. Die Schnitt­stel­le zum Bus­sys­tem ist nicht ganz so alt: Die D-PDU API ist in der zwei­ten Hälf­te die­ses Jahr­zehnts ent­stan­den.

Für die On-Board-Kom­mu­ni­ka­tion hat man bei ASAM eben­falls eine Spe­zi­fi­ka­ti­ons­schie­ne auf­ge­macht. Unter dem Stich­wort FIBEX ver­sucht man dort die Bus­bot­schaf­ten, die Signa­le und die Topo­lo­gie des On-Board-Netz­wer­kes im Fahr­zeug zu beschrei­ben. ASAP2 (A2L) gibt es mitt­ler­wei­le in der Ver­sion 1.6. Die Daten­sät­ze für die Dia­gno­se sind etwas jün­ger. Mit ODX liegt hier mitt­ler­wei­le ein ISO Stan­dard. In der Pro­gram­miere­be­ne zur Test- oder Appli­ka­ti­ons­an­wen­dung wur­de im Bereich MC bereits rela­tiv früh stan­dar­di­siert. Für die Dia­gno­se (MCD 3D) erst in die­sem Jahr­zehnt.

Siehe auch

  • Erstellt
    12. Januar 2011
  • Version
    8
  • Geändert
    06. April 2011
  • Zugriffe
    62008