Einleitung Transport Diagnoseprotokolle

From emotive
Jump to navigation Jump to search

Im fol­gen­den Kapi­tel gehen wir auf Trans­port- und Dia­gno­se­pro­to­kol­le ein. Nach einer kur­z­en Ein­lei­tung betrach­ten wir zunächst das Trans­port­pro­to­koll, wie es für CAN im Ein­satz ist und bespre­chen anschlie­ßend die Unter­schie­de, die sich bei der Wei­ter­ent­wick­lung für Flex­Ray erge­ben haben. Danach gehen wir auf die drei heu­te wich­tigs­ten Dia­gno­se­pro­to­kol­le ein:

Der fol­gen­de Abschnitt ist geglie­dert in:

Ein­lei­tung

Wir bewe­gen uns also im Bereich der Off-Board-Kom­mu­ni­ka­tion, das heißt der Kom­mu­ni­ka­tion zwi­schen den Gerä­ten im Fahr­zeug und den exter­nen Werk­statt- und Dia­gno­se­tes­tern.


Protocolls-On-Off-Board.png
Ver­ein­fach­te Dar­stel­lung der Kom­mu­ni­ka­tion im Fahr­zeug


Im ISO/OSI Schich­ten­mo­dell sind das die Ebe­ne 4, der Trans­port-Layer und die Ebe­ne 7, der App­li­ca­tion-Layer. Auf letz­te­rer sind die Dia­gno­se­pro­to­kol­le ange­sie­delt.


Protocolls-ISO-OSI-Model.png
Open Sys­tem Inter­connec­tion (OSI) Schich­ten­mo­dell nach ISO 1978


Off-Board-Kom­mu­ni­ka­tion

Im Gegen­satz zur On-Board-Kom­mu­ni­ka­tion bei CAN oder Flex­Ray, bei der jedes Steu­er­ge­rät sei­ne Infor­ma­tio­nen an alle sen­det, haben wir bei der Dia­gno­se­kom­mu­ni­ka­tion ein kla­res Rol­len­mo­dell: Der Dia­gno­se­tes­ter beginnt immer die Kom­mu­ni­ka­tion. Er sen­det eine Anfra­ge, wie bei­spiels­wei­se: „Gibt es abgas­re­le­van­te Feh­ler im Sys­tem?“ oder „Wie ist die Öltem­pe­ra­tur?“. Er sen­det auch Befeh­le wie zum Bei­spiel: „Schal­te den Motor­lüf­ter ein!“. Die­se Anfra­ge, der so genann­te Dia­gno­se-Request, geht an ein oder meh­re­re Steu­er­ge­rä­te. Die­se Ant­wor­ten mit den ent­spre­chen­den Dia­gno­se-Respon­ses. Es gibt also eine ein­deu­ti­ge Rol­len­ver­tei­lung: Der Tes­ter fragt, die Steu­er­ge­rä­te ant­wor­ten. Man nennt die­ses Kom­mu­ni­ka­ti­ons­prin­zip das so genann­te Request/Respon­se-Ver­fah­ren, sie­he Abbil­dung.


Protocolls-Off-Board-Communication.png
Off-Board-Kom­mu­ni­ka­tion – Request/Respon­se-Ver­fah­ren


Zu Beginn der Kom­mu­ni­ka­tion weiß der Dia­gno­se­tes­ter nicht unbe­dingt, wel­che Steu­er­ge­rä­te im Fahr­zeug ver­baut sind. Das heißt, er kennt nicht immer das genaue Fahr­zeug­mo­dell und vor allem nicht die Kom­bi­na­tion der ver­bau­ten Zusatzaus­stat­tun­gen. Auf der einen Sei­te muss es also mög­lich sein, dass der Dia­gno­se­tes­ter mit allen Steu­er­ge­rä­ten in irgend­ei­ner Form kom­mu­ni­ziert. Auf der ande­ren Sei­te kann natür­lich auch jeder, nicht nur die auto­ri­sier­te Werk­statt, einen Dia­gno­se­tes­ter am Fahr­zeug anschlie­ßen. Es muss also sicher­ge­stellt wer­den, dass der Dia­gno­se­tes­ter nicht alle Din­ge aus­le­sen und vor allem nicht alle Din­ge ver­än­dern oder mani­pu­lie­ren kann.

Ein wei­te­res Pro­blem für die Kom­mu­ni­ka­tion ent­steht dadurch, dass die Bot­schaf­ten, die aus­ge­tauscht wer­den, unter Umstän­den sehr viel län­ger sind, als eine ein­zel­ne Bus-Bot­schaft. Wenn man bei­spiels­wei­se die Fahr­ge­stell­num­mer abfra­gen will, hat man 17 Zei­chen zu über­tra­gen. CAN kann aber in einer ein­zel­nen Bot­schaft maxi­mal 8 Nutz­da­ten­by­tes über­tra­gen. Man braucht also meh­re­re CAN-Bot­schaf­ten, um die­se Abfra­ge zu rea­li­sie­ren. Ein Extrem­fall stellt das Flas­hen der Steu­er­ge­rä­te­soft­wa­re dar. Dort hat man häu­fig meh­re­re hun­dert Kilo­by­te bis viel­leicht sogar eini­ge Mega­by­te zu über­tra­gen.

Pro­to­koll­sta­pel (Pro­to­col Stack)

Durch das ISO/OSI-Schich­ten­mo­dell wird die Auf­ga­ben­ver­tei­lung bei der Kom­mu­ni­ka­tion zwi­schen Tes­ter und Steu­er­ge­rät fest­ge­legt, sie­he Abbil­dung. Das Dia­gno­se­pro­to­koll beschreibt den App­li­ca­tion-Layer, also die Ebe­ne, mit der die Dia­gno­se­an­wen­dung arbei­tet. Die­ser App­li­ca­tion-Layer stellt nun ein­zel­ne Diens­te dar, zum Bei­spiel den Dienst: „Feh­ler­spei­cher lesen“. Wenn die Dia­gno­se­bot­schaft nicht in eine ein­zel­ne Bus-Bot­schaft hin­ein­passt, zer­legt das Trans­port­pro­to­koll die ent­spre­chen­de Dia­gno­se­bot­schaft dann auf der Sen­der­sei­te in meh­re­re Bus-Bot­schaf­ten. Das Bus­sys­tem selbst, der Data-Link-Layer und der Phy­si­cal-Layer ver­sen­den die­se Bot­schaft.


Protocolls-Protocoll-Stack.png
Pro­to­koll­sta­pel (Pro­to­col Stack)


Auf der Sei­te des Steu­er­ge­rä­tes wird die Bot­schaft emp­fan­gen. Auf der Ebe­ne des Trans­port­pro­to­kolls im Steu­er­ge­rät wer­den die ein­zel­nen Bus-Bot­schaf­ten wie­der zur ursprüng­li­chen Dia­gno­se­bot­schaft zusam­men­ge­setzt und über den App­li­ca­tion-Layer als Ser­vice an die Anwen­dungs­soft­wa­re auf dem Steu­er­ge­rät über­ge­ben. Das Steu­er­ge­rät sei­ner­seits stellt dann die Ant­wort zusam­men und über­gibt sie einem Dienst, der die­se Ant­wort ver­sen­det. Die­se wird wie­der in der Trans­por­tebe­ne seg­men­tiert, über das Bus­sys­tem über­tra­gen, auf der Sei­te des Tes­ters wie­der in umge­kehr­ter Rei­hen­fol­ge zusam­men­ge­setzt und ganz oben an die Dia­gno­se­an­wen­dung über­ge­ben.

Stan­dar­di­sie­rung

Wenn wir Dia­gno­sethe­men bespre­chen, haben wir es meist mit ISO-Stan­dards und ASAM-Spe­zi­fi­ka­tio­nen zu tun. In den ent­spre­chen­den Nor­men von ISO und ASAM, die Trans­port- und Dia­gno­se­pro­to­kol­le betref­fen, haben Steu­er­ge­rä­te auf der einen und Tes­ter auf der ande­ren Sei­te spe­zi­el­le Bezeich­nun­gen. Bei ASAM heißt der Dia­gno­se­tes­ter „Mas­ter“, weil er durch sei­ne Request-Anfra­gen die Kom­mu­ni­ka­tion aus­löst, wäh­rend die Steu­er­ge­rä­te als „Sla­ve­s“ bezeich­net wer­den, weil sie mit den Respon­ses nur auf sol­che Anfra­gen ant­wor­ten. ISO dage­gen sieht das gan­ze eher aus Sicht der Infor­ma­tik. Hier wird das Steu­er­ge­rät, das auf eine Anfra­ge war­tet, als einen „Ser­ver“ bezeich­net und der Tes­ter, der eine sol­che Anfra­ge stellt, als „Cli­ent“.

Im fol­gen­den Schau­bild sieht man ver­schie­de­ne ISO-Stan­dards auf­ge­führt, die auf den ers­ten Blick etwas ver­wir­ren kön­nen:


Protocolls-Standards.png
Über­blick der Stan­dards – His­to­ri­sche Ent­wick­lung in Euro­pa


His­to­risch gese­hen gibt es die all­ge­mei­ne Fahr­zeug­dia­gno­se schon sehr lan­ge. Zunächst hat sie jeder Her­stel­ler, zumin­dest in der Appli­ka­ti­ons­schicht, pro­prie­tär gehand­habt. Auf der Ebe­ne der Dia­gno­se­schnitt­stel­le hat man sich mit ISO 9141, der K-Line Schnitt­stel­le, bezie­hungs­wei­se SAE J1850 rela­tiv früh fest­ge­legt. Die Unter­schie­de auf der Appli­ka­ti­ons­ebe­ne haben dazu geführt, dass die Steu­er­ge­rä­te- und Dia­gno­se­tes­ter­her­stel­ler viel par­al­le­len Ent­wick­lungs­auf­wand für ver­schie­de­ne Fahr­zeugher­stel­ler hat­ten. Um dies zu redu­zie­ren, führ­te man das in der ISO 14230 spe­zi­fi­zier­te KWP 2000 ein. Die­se Norm ver­such­te, die Dia­gno­se­diens­te, die bei allen Her­stel­lern im Ein­satz waren, mehr oder weni­ger zu stan­dar­di­sie­ren.

Wäh­rend der Ein­füh­rung von KWP 2000 war die K-Line noch das domi­nie­ren­de Bus­sys­tem auf dem Markt. Als dann jedoch auch für die Dia­gno­se CAN ein­ge­führt wur­de, hat man die Appli­ka­ti­ons­schicht von KWP 2000 zunächst ein­mal auf CAN über­tra­gen. Die Ände­run­gen waren rela­tiv gering. Spe­zi­fi­ziert wur­de das mit dem Nor­m­ent­wurf ISO/DIS 15765-3, der aber nie­mals den Ent­wurfs­sta­tus ver­ließ und zu einer vol­len ISO Norm wur­de. Grund: Wäh­rend des Ent­wick­lungs­pro­zes­ses die­ses Stan­dards hat man das KWP 2000 Pro­to­koll aus ver­schie­de­nen Grün­den ver­wor­fen und auf das so genann­te Uni­fied-Dia­gno­stic-Sys­tems Pro­to­koll (UDS) gesetzt. UDS unter­schei­det sich zwar nicht in den Grund­prin­zi­pi­en, aber in vie­len Details von KWP 2000. Das in der ISO 14229 stan­dar­di­sier­te UDS ist etwas kla­rer und sau­be­rer als KWP 2000. Zudem ist es grund­sätz­lich unab­hän­gig vom dar­un­ter lie­gen­den Bus­sys­tem, wird aber heu­te prak­tisch nur für CAN umge­setzt. Die­se Umset­zung erfolgt durch die ISO 15765 (ohne DIS!). Teil 3 beschreibt die Anpas­sung an CAN und Teil 2 das ent­spre­chen­de Trans­port­pro­to­koll.

Par­al­lel zu der all­ge­mei­nen Fahr­zeug­dia­gno­se war der Gesetz­ge­ber aktiv. Mit der OBD hat zunächst der ame­ri­ka­ni­sche Gesetz­ge­ber Anfor­de­run­gen an das Abgas­ver­hal­ten eines Fahr­zeu­ges und an deren Feh­ler­über­wa­chung gestellt. Die Euro­pä­er haben das dann mehr oder weni­ger unver­än­dert über­nom­men. Dafür waren ein ent­spre­chen­des Dia­gno­se­pro­to­koll und eine Dia­gno­se­schnitt­stel­le not­wen­dig. Die­se wur­den in Euro­pa in der ISO 15031 spe­zi­fi­ziert. Die­se Norm hat eine gan­ze Rei­he von ver­schie­de­nen Tei­len. Im drit­ten Teil ist bei­spiels­wei­se die Dia­gno­se­steck­do­se (OBD-Dose) und im Teil 5 die Appli­ka­ti­ons­schicht mit den Dia­gno­se­diens­ten spe­zi­fi­ziert. Ver­wend­bar ist OBD mit allen übli­chen Bus­sys­te­men, also mit K-Line, SAE J1850 und CAN.