Grund­la­gen Dia­gno­se­pro­to­kol­le

From emotive
Jump to navigation Jump to search

Im Fol­gen­den wol­len wir die drei Dia­gno­se­pro­to­kol­le OBD, UDS und das älte­re KWP 2000 betrach­ten. Doch zunächst wich­tigs­ten Prin­zi­pi­en der Dia­gno­se­pro­to­kol­le.

Der Abschnitt unter­glie­dert sich wie folgt:

All­ge­mei­nes

Die Grund­prin­zi­pi­en sind bei allen drei Pro­to­kol­len iden­tisch, auch wenn sie sich in eini­gen Details von­ein­an­der unter­schei­den.


Protocolls-DP-RequestResponse.png
Dia­gno­se­kom­mu­ni­ka­tion nach dem Request/Respon­se-Ver­fah­ren


Bei allen wird das Request/Respon­se-Kom­mu­ni­ka­ti­ons­prin­zip ein­ge­setzt: Der Dia­gno­se­tes­ter sen­det eine Anfra­ge, den Request, an ein oder meh­re­re Steu­er­ge­rä­te und erhält vom Steu­er­ge­rät eine posi­ti­ve oder nega­ti­ve Ant­wort, die Respon­se. Inner­halb der Request-Bot­schaft dient das ers­te Byte, der so genann­te Ser­vice-Iden­ti­fier, der Unter­schei­dung der ein­zel­nen Dia­gno­se­diens­te bzw. der Auf­ga­ben, die zu erle­di­gen sind. Die rest­li­chen Bytes ent­hal­ten Para­me­ter und Daten.


Protocolls-DP-Service.png
Auf­bau der Dia­gno­se­ser­vices


Um die Para­me­ter von­ein­an­der zu unter­schei­den, hat man wei­te­re Kenn­zif­fern ein­ge­führt. Bei OBD und KWP 2000 hei­ßen sie Para­me­ter-Iden­ti­fier (PID) und bei UDS Level-Iden­ti­fier (LEV). Das Steu­er­ge­rät ant­wor­tet auf eine Dia­gno­se­an­fra­ge ent­we­der mit einer posi­ti­ven oder mit einer nega­ti­ven Respon­se. Die posi­ti­ve Respon­se ent­hält im ers­ten Byte wie­der­um die SID. Hier ist jedoch grund­sätz­lich das Bit 6 gesetzt. Mathe­ma­tisch ent­spricht das einer Addi­tion von 0x40 zur SID. In den rest­li­chen Daten­by­tes der Bot­schaft wer­den die PID und die Ant­wort­da­ten zurück­ge­schickt. Im Feh­ler­fall sen­det das Steu­er­ge­rät die so genann­te nega­ti­ve Respon­se zurück. Das ers­te Byte ist dann immer 0x7F. Das zwei­te Byte ent­hält eine Kopie der SID und das letz­te Byte den so genann­ten Respon­se-Code. Die­ser beschreibt die Feh­ler­ur­sa­che.


Protocolls-DP-SIDs.png
Genorm­te Berei­che für Ser­vice IDs


Die drei Dia­gno­se­pro­to­kol­le unter­schei­den sich in den ein­zel­nen Dia­gno­se­diens­ten und deren Para­me­tern. Erfreu­li­cher­wei­se hat man bei OBD und UDS dar­auf geach­tet, dass die SID-Berei­che ein­deu­tig gewählt wer­den. Für OBD ist der SID-Bereich zwi­schen 0x00 und 0x0F reser­viert, die ent­spre­chen­den posi­ti­ven Respon­se-Bot­schaf­ten haben dann einen Wert, der um 0x40 grö­ßer ist, also zwi­schen 0x40 und 0x4F liegt. Die­se Ser­vice-IDs sind in der OBD-Norm in ISO 15031-5 und für UDS in der ISO 14229 defi­niert. Bei UDS ist der Bereich 0x10 bis 0x3E und für buss­pe­zi­fi­sche Auf­ga­ben der Bereich 0x83 bis 0x87 reser­viert. KWP 2000 ver­wen­det den glei­chen SID-Bereich, wes­we­gen sich UDS und KWP 2000 im sel­ben Fahr­zeug­netz lei­der nicht unter­schei­den las­sen. Schließ­lich gibt es noch zwei wei­te­re SID-Berei­che: 0xA0 bis 0xB9 und 0xBA bis 0xBE, die für die Fahr­zeug- und Steu­er­ge­räte­her­stel­ler spe­zi­fi­schen Dia­gno­se­diens­te reser­viert sind.


Protocolls-DP-ErrorCodes.png
Typi­sche Error Respon­se-Codes


Die Error-Respon­se-Codes kenn­zeich­nen einen Feh­ler. Sie sind in der Tabel­le für alle drei Nor­men auf­ge­führt und weit­ge­hend ein­heit­lich, sie­he oben. So bedeu­tet 0x10 einen Gene­ral-Reject, d. h. einen all­ge­mei­nen, nicht wei­ter spe­zi­fi­zier­ten Feh­ler. Die Respon­se-Codes 0x11 und 0x12 zei­gen an, dass ein bestimm­ter Dienst oder eine bestimm­te Unter­funk­tion durch das Steu­er­ge­rät nicht unter­stützt wer­den. 0x13 bedeu­tet, dass das Bot­schafts­for­mat nicht kor­rekt ist und 0x31 bedeu­tet, dass zwar der Dia­gno­se­dienst prin­zi­pi­ell unter­stützt wird, aber bei irgend­ei­nem Para­me­ter der Wer­te­be­reich über­schrit­ten wur­de. Des Wei­te­ren gibt es eini­ge Dia­gno­se­diens­te, die zur Aus­füh­rung län­ge­re Zeit benö­ti­gen. Dort kann das Steu­er­ge­rät über die Respon­se-Codes 0x21 (Busy-Repeat) und 0x78 (Respon­se-Pen­ding) dem Tes­ter mit­tei­len, dass es noch etwas Zeit zur Lie­fe­rung der Ant­wort­bot­schaft benö­tigt. Im Fall von 0x21 muss der Tes­ter die Anfra­ge wie­der­ho­len. Im Fall von 0x78 muss der Dia­gno­se­tes­ter war­ten, bis das Steu­er­ge­rät die eigent­li­che Ant­wort sen­det.

Adres­sie­rungs­ar­ten

Eine wei­te­re Gemein­sam­keit der drei Dia­gno­se­pro­to­kol­le ist die Adres­sie­rung von Dia­gno­se­tes­tern und Steu­er­ge­rä­ten. Im ein­fachs­ten Fall wird die so genann­te phy­si­ka­li­sche Adres­sie­rung ein­ge­setzt. Dabei haben der Dia­gno­se­tes­ter und das ein­zel­ne Steu­er­ge­rät ein ein­deu­ti­ges Paar von Adres­sen. Im Fall von CAN wer­den die Adres­sen über CAN-IDs abge­bil­det: Mit einer CAN-ID sen­det der Tes­ter sei­ne Bot­schaf­ten (Requests) an das ent­spre­chen­de Steu­er­ge­rät, mit einer ande­ren schickt das Steu­er­ge­rät sei­ne Ant­wort (Respon­se) zurück an den Dia­gno­se­tes­ter.

Die so genann­te funk­tio­na­le Adres­sie­rung hat man für die Fäl­le ein­ge­setzt, in denen der Dia­gno­se­tes­ter nicht genau weiß, wel­che und wie vie­le Steu­er­ge­rä­te im Fahr­zeug ver­baut sind. Sie gilt nur vom Tes­ter zu den Steu­er­ge­rä­ten. In der umge­kehr­ten Rich­tung – von den Steu­er­ge­rä­ten zum Tes­ter – wird immer die phy­si­ka­li­sche Adres­sie­rung ver­wen­det. Bei die­ser Adres­sie­rung gibt es eine Adres­se für eine gan­ze Grup­pe von Steu­er­ge­rä­ten und des­halb muss der Dia­gno­se­tes­ter damit rech­nen, dass auf eine ein­zel­ne Request-Anfra­ge meh­re­re Steu­er­ge­rä­te mit einer Respon­se-Bot­schaft ant­wor­ten. In der Regel haben Steu­er­ge­rä­te daher zwei Adres­sen. Eine phy­si­ka­li­sche und optio­nal eine funk­tio­na­le Adres­se.


Protocolls-DP-Adressing.png
Adres­sie­rungs­ar­ten – funk­tio­na­le & phy­si­ka­li­sche Adres­sie­rung


Das Prin­zip soll an einem Bei­spiel mit einem Dia­gno­se­tes­ter und zwei Steu­er­ge­rä­ten ver­deut­licht wer­den, sie­he Bild oben. Die ange­ge­be­nen CAN-IDs stam­men aus der OBD-Norm. Dort sind die­se vom Gesetz­ge­ber vor­ge­ge­ben. Wäh­rend bei der all­ge­mei­nen Fahr­zeug­dia­gno­se (UDS) die CAN-IDs her­stel­ler­spe­zi­fisch gewählt wer­den dür­fen. Der Dia­gno­se­tes­ter stellt eine Anfra­ge und weil er nicht genau weiß, wel­che Steu­er­ge­rä­te im Fahr­zeug ver­baut sind, ver­wen­det er die funk­tio­na­le Adres­sie­rung. Bei OBD ist die funk­tio­na­le Adres­se für abgas­re­le­van­te Steu­er­ge­rä­te – für einen 11 Bit CAN-Iden­ti­fier – auf 0x7DF fest­ge­legt. Wir neh­men nun an, dass auf die­se Adres­se zwei Steu­er­ge­rä­te ant­wor­ten: ECU 1 und ECU2. Die Steu­er­ge­rä­te ant­wor­ten jeweils mit einer ein­deu­ti­gen phy­si­ka­li­schen CAN-ID. Die OBD-Norm legt fest, dass für die Ant­wort des Steu­er­ge­rä­tes 1 die Adres­se 0x7E8 und für das Steu­er­ge­rät 2 die Adres­se 0x7E9 ver­wen­det wer­den müs­sen. Danach möch­te der Dia­gno­se­tes­ter gezielt eine Anfra­ge an das Steu­er­ge­rät 2 rich­ten. Damit das Steu­er­ge­rät 1 oder ande­re Steu­er­ge­rä­te nicht ant­wor­ten, ver­wen­det er die ein­deu­ti­ge phy­si­ka­li­sche Adres­se des Steu­er­ge­rä­tes 2 – in der OBD-Norm mit 0x7E1 fest­ge­legt – und bekommt so nur von die­sem eine Ant­wort – näm­lich mit der phy­si­ka­li­schen Adres­se 0x7E9, der­sel­ben, mit der es auch auf die funk­tio­nal adres­sier­te Anfra­ge geant­wor­tet hat.

Da OBD ver­sucht, weit­ge­hend bus­sys­te­mu­n­ab­hän­gig zu sein, wer­den die funk­tio­na­len und phy­si­ka­li­schen Adres­sen nicht in der OBD-Norm, son­dern in der ISO 15765-4 (Dia­gno­se über CAN) beschrie­ben. Die Adres­sen unter­schei­den sich, je nach­dem ob 11 Bit oder 29 Bit CAN-Iden­ti­fier ein­ge­setzt wer­den, sie­he Tabel­le.


Protocolls-DP-OBD-Adresses.png
Für OBD-rele­van­te Gerä­te sind die Adres­sen in ISO 15765-4 fest vor­ge­ge­ben


Die Gerä­te­adres­sen wer­den bei KWP 2000 (K-Line) und bei Flex­Ray in den ers­ten Bytes der Nutz­da­ten­bot­schaft über­tra­gen. Bei CAN gibt es zusätz­lich zur nor­ma­len noch die erwei­ter­te Adres­sie­rung. Hier wird das ers­te Daten­by­te der Bot­schaft mit zur Adres­sie­rung ver­wen­det. Das heißt, der Nutz­da­ten­teil wird noch mal etwas redu­ziert. Aus die­sem Grund ver­sucht man, die erwei­ter­te Adres­sie­rung zu ver­mei­den.

Wei­ter­hin sind noch die Timeouts (Zeit­be­din­gun­gen) von Bedeu­tung. Bei CAN müs­sen die Steu­er­ge­rä­te typi­scher­wei­se inner­halb von 50 Mil­li­se­kun­den ant­wor­ten. Das ist vor allem bei der funk­tio­na­len Adres­sie­rung zu beach­ten. Da der Dia­gno­se­tes­ter nicht weiß, wie vie­le Steu­er­ge­rä­te auf sei­ne Anfra­ge ant­wor­ten, muss er grund­sätz­lich bis zum Timeout, also 50 Mil­li­se­kun­den abwar­ten, bevor er die nächs­te Dia­gno­se­an­fra­ge stel­len kann. Dies könn­te bei­spiels­wei­se bei 50 im Fahr­zeug ver­bau­ten Steu­er­ge­rä­ten eini­ge Sekun­den dau­ern. Bei der phy­si­ka­li­schen Adres­sie­rung dage­gen kann er, sobald er eine Ant­wort­bot­schaft erhal­ten hat, sofort die nächs­te Dia­gno­se­an­fra­ge ver­sen­den.

Sicher­heits­kon­zept – Dia­gno­se­sit­zun­gen

Bei OBD gibt es kein Sicher­heits­kon­zept. Das ist inso­weit unkri­tisch, als die OBD-Dia­gno­se­diens­te Daten aus dem Steu­er­ge­rät nur aus­le­sen kön­nen. Der ein­zi­ge Dia­gno­se­dienst, der hier den Steu­er­ge­rätein­halt ver­än­dert, ist der Dienst, der den Feh­ler­spei­cher löscht.

Bei UDS und KWP 2000 dage­gen gibt es eine gan­ze Rei­he von Diens­ten, mit denen Steu­er­ge­rätein­hal­te mani­pu­liert wer­den könn­ten. Des­we­gen gibt es dort ein Sicher­heits­kon­zept, das den unbe­schränk­ten Zugriff auf das Steu­er­ge­rät ver­hin­dert.


Protocolls-DP-Sessions.png
Sicher­heits­kon­zept - Dia­gno­se­sit­zun­gen


Nor­ma­ler­wei­se befin­det sich ein Steu­er­ge­rät in der so genann­ten Default-Dia­gno­stic-Ses­sion, sie­he Abbil­dung. Hier ist nur ein klei­ner, unkri­ti­scher Teil der Dia­gno­se­diens­te ver­wend­bar, und nur ein klei­ner Teil der Mess­wer­te und Steu­er­ge­rä­te­da­ten kann gele­sen wer­den. Geschrie­ben wer­den kann eigent­lich gar nicht. Soll­te einer der Dia­gno­se­diens­te not­wen­dig wer­den, mit denen kri­ti­sche Mess­da­ten gele­sen oder gar geschrie­ben wer­den kön­nen, dann muss in eine spe­zi­el­le Dia­gno­stic-Ses­sion umge­schal­tet wer­den. Dafür gibt es bei UDS den Dia­gno­se­dienst Start­Dia­gno­stic­Ses­sion. Typi­scher­wei­se gibt es ver­schie­de­ne Dia­gno­se­sit­zun­gen mit unter­schied­li­chen Grup­pen von Dia­gno­se­diens­ten, wie bei­spiels­wei­se die Pro­gram­ming-Ses­sion (zur Flash-Pro­gram­mie­rung) und die Exten­ded-Dia­gno­stic-Ses­sion (inner­halb der Werk­statt für die Nach­jus­tie­rung ver­schie­de­ner Para­me­ter). Beim Umschal­ten von der Default-Ses­sion in eine spe­zi­el­le Ses­sion ist in der Regel eine bestimm­te Login-Pro­ze­dur not­wen­dig, so genann­ter Secu­ri­ty-Access, sie­he nächs­ter Abschnitt. Die Non-Default-Ses­sion bleibt nur dann erhal­ten, wenn der Dia­gno­se­tes­ter regel­mä­ßig Dia­gno­seauf­for­de­run­gen an das Steu­er­ge­rät sen­det. Ansons­ten star­tet, sobald die Non-Default-Ses­sion betre­ten wur­de ein Timer. Wenn die­ser ins Timeout geht, fällt das Steu­er­ge­rät auto­ma­tisch wie­der in die Default-Ses­sion mit dem ein­ge­schränk­ten Dia­gno­se­um­fang zurück.

Secu­ri­ty Access

Die Login-Pro­ze­dur, der so genann­te Secu­ri­ty-Access ver­wen­det ein Seed-and-Key Ver­fah­ren: Der Dia­gno­se­tes­ter for­dert den Secu­ri­ty-Access mit einer Request-Secu­ri­ty-Access-Bot­schaft an. Sie sehen in der fol­gen­den Abbil­dung sym­bo­lisch die SID und die not­wen­di­gen Para­me­ter.


Protocolls-DP-SeedAndKey.png
Secu­ri­ty Access – „Seed & Key“ Ver­fah­ren


Mit die­ser Anfra­ge for­dert der Dia­gno­se­tes­ter eine so genann­te Seed vom Steu­er­ge­rät an. Dies ist ein­fach eine im Steu­er­ge­rät gene­rier­te Zufalls­zahl. Sie dient dem Dia­gno­se­tes­ter als Ini­tia­li­sie­rungs­wert für einen gehei­men Algo­rith­mus, mit dem er den Key (Schlüs­sel) berech­net. Der Key wird dann an das Steu­er­ge­rät zurück­ge­schickt. Das Steu­er­ge­rät berech­net par­al­lel dazu mit dem­sel­ben Algo­rith­mus eben­falls den ent­spre­chen­den Key und ver­gleicht den vom Dia­gno­se­tes­ter Gelie­fer­ten mit dem selbst Berech­ne­ten. Stim­men bei­de Keys über­ein, erlaubt das Steu­er­ge­rät dem Dia­gno­se­tes­ter den Zugang zur gewünsch­ten Dia­gno­se-Ses­sion und ant­wor­tet mit einer posi­ti­ven Respon­se.


Siehe auch

OBD on CAN

UDS - Allgemeine Fahrzeugdiagnose

KWP 2000 on CAN