UDS Allgemeine Fahrzeugdiagnose

Defi­niert ist UDS (Unified Diagno­stic Services) in den Nor­men ISO 14229 (ent­hält den bus­sys­te­mu­n­ab­hän­gi­ge Teil) und in ISO 15765-3 (beschreibt die CAN-spe­zi­fi­sche Imple­men­tie­rung). Im Gegen­satz zu OBD schreibt die UDS-Norm für die all­ge­mei­ne Fahr­zeug­dia­gno­se kei­ne CAN-Iden­ti­fier und kei­ne CAN-Bau­dra­ten vor. Hier ist also jeder Fahr­zeugher­stel­ler in der Lage frei zu ent­schei­den. Der Stan­dard defi­niert aller­dings, wie die SIDs und PIDs (hei­ßen bei UDS Sub-Level-Para­me­ter) bezeich­net wer­den. Im Unter­schied zu OBD ist der Inhalt der Bot­schaf­ten bei UDS prak­tisch nicht defi­niert. Das heißt, hier kann jeder Fahr­zeugher­stel­ler fest­le­gen, wie er Mess­da­ten defi­niert, unter wel­chen Para­me­tern er sie über­trägt, wie er sie kodiert etc.

Der Bot­schafts­auf­bau der UDS-Dia­gno­se­diens­te ent­spricht dem Auf­bau von OBD: Das ers­te Byte ist die SID. Dann folgt eine Detail­lie­rung des Diens­tes über den so genann­ten Sub-Level-Iden­ti­fier (ent­spricht im Wesent­li­chen dem PID bei OBD).

Bei UDS gibt es die Mög­lich­keit auf posi­ti­ve Ant­wort­bot­schaf­ten zu ver­zich­ten. Dazu muss der Dia­gno­se­tes­ter in der Anfra­ge das obers­te Bit des Sub-Level-Iden­ti­fiers auf 1 set­zen. Nega­ti­ve Ant­wor­ten dage­gen müs­sen immer gesen­det wer­den. Die­ser Ver­zicht auf posi­ti­ve Ant­wort­bot­schaf­ten ist sinn­voll, um die Bus­last bei­spiels­wei­se beim Flas­hen zu redu­zie­ren.

Es gibt in UDS eine große Anzahl von Dia­gno­se­diens­ten. Die fol­gen­den bei­den Tabel­len zei­gen hier einen Aus­zug davon. In den Tabel­len sind zum Ver­gleich auch die jewei­li­gen Diens­te für den Vor­gän­ger von UDS, KWP 2000 dar­ge­stellt.

Aus­zug der Dia­gno­se­diens­te von UDS und KWP 2000

In der ers­ten Spal­te fin­den Sie die soge­nann­te Funk­ti­ons­grup­pe. Sie fasst die Dia­gno­se­diens­te nach funk­tio­na­len Gesichts­punk­ten zusam­men. In der zwei­ten Spal­te steht die SID für UDS und KWP 2000. In vie­len Fäl­len sind die UDS-Dia­gno­se­diens­te und die KWP 2000-Dia­gno­se­diens­te zumin­dest bei den SIDs iden­tisch. In eini­gen Fäl­len gibt es aber auch Unter­schie­de. Dann sehen Sie in der nächs­ten Spal­te „Default-Ses­sion“ eine Anga­be, ob der Dienst in der Default-Dia­gno­se­sit­zung zur Ver­fü­gung steht oder nicht. Sie erin­nern sich, die Default-Ses­sion ist der Stan­dard-Zustand im Sicher­heits­kon­zept der Fahr­zeug­dia­gno­se, sie­he Abschnitt vorn. Dann ist die Bezeich­nung der Diens­te auf­ge­führt. Auch hier hat sich zwi­schen KWP 2000 und UDS eini­ges ver­än­dert und ganz am Ende noch eine Spal­te, die die Dia­gno­se­diens­te etwas näher beschreibt.

Fan­gen wir oben an mit der Funk­ti­ons­grup­pe „Dia­gno­stics and Com­mu­ni­ca­tion Mana­ge­ment“. Also der Funk­ti­ons­grup­pe, die die Dia­gno­se­sit­zun­gen steu­ert und die Kom­mu­ni­ka­tion wäh­rend der Dia­gno­se­sit­zung beein­flusst. Es beginnt mit dem Dia­gno­se­dienst Dia­gno­stic-Ses­sion-Con­trol. Er hat den Iden­ti­fier 0x10 und ist natür­lich in der Default-Ses­sion bereits ver­füg­bar. Nur mit die­sem Dienst gelangt man von der Default-Ses­sion in irgend­ei­ne ande­re Dia­gno­se­sit­zung, bezie­hungs­wei­se am Ende einer spe­zi­el­len Dia­gno­se­sit­zung auch wie­der zurück in die Default-Ses­sion. Sie sehen bei KWP 2000 waren dies noch zwei ver­schie­de­ne Diens­te. Bei UDS wur­de das zu einem Dienst zusam­men­ge­fasst und über die Sub-Level-ID wird gesteu­ert, ob die Dia­gno­se­sit­zung gest­ar­tet oder gestoppt wer­den soll.

Dann gibt es den Dienst Tes­ter­Pre­sent. Er dient wäh­rend einer Non-Default-Ses­sion dazu, die Ses­sion auf­recht zu erhal­ten. Wei­ter­hin Secu­ri­ty-Access, den wir im Zusam­men­hang mit den Dia­gno­se­sit­zun­gen bereits ken­nen­ge­lernt haben. Es fol­gen der Dienst ECU-Reset, um Steu­er­ge­rä­te zurück­zu­set­zen und einen Dienst Com­mu­ni­ca­tion-Con­trol, um die Kom­mu­ni­ka­tion zu steu­ern. Dies ist typi­scher­wei­se der Fall, um wäh­rend einer Dia­gno­se­sit­zung die Kom­mu­ni­ka­tion ein­zu­schrän­ken, wie zum Bei­spiel bei der Flash-Pro­gram­mie­rung. Dort benö­tigt man mög­lichst viel Bus­band­brei­te. Das erreicht man am ein­fachs­ten, wenn man den ande­ren Steu­er­ge­rä­ten die Kom­mu­ni­ka­tion über die­sen Dienst ver­bie­tet.

Dann gibt es den Dienst Con­trolDT­C­Set­ting, wel­cher das Spei­chern der Feh­ler­ko­des steu­ert. Hier kann bei­spiels­wei­se inner­halb der Werk­statt bei Repa­ra­tu­r­ar­bei­ten die Feh­ler­spei­che­rung abge­schal­tet wer­den. Die zwei­te Funk­ti­ons­grup­pe Data-Trans­mis­sion wird im Wesent­li­chen benö­tigt, um Mess­da­ten zu lesen oder zu schrei­ben. Dort unter­schei­det man wir im Wesent­li­chen Diens­te, die mit einem Para­me­ter-Iden­ti­fier arbei­ten oder Diens­te, die direkt den Spei­cher adres­sie­ren. Das sind Read­Da­ta­By­I­den­ti­fier bzw. Wri­te­Da­ta­By­I­den­ti­fier und Read­Me­mo­ry­By­Adress bzw. Wri­te­Me­mo­ry­By­Adress. Über dem vom Fahr­zeugher­stel­ler vor­de­fi­nier­ten Iden­ti­fier kann dann ent­schie­den wer­den, wel­che Daten gele­sen oder geschrie­ben wer­den. Über den direk­ten Spei­cher­zu­griff kann man prak­tisch alles ändern, vor­aus­ge­setzt, man kennt die rich­ti­ge Spei­cher­adres­se für die aktu­el­le Soft­wa­re­va­ri­an­te.

Dann haben wir eine Grup­pe von Diens­ten, die in der UDS-Norm als Sto­red-Data-Trans­mis­sion Funk­ti­ons­grup­pe bezeich­net wird. Eigent­lich han­delt es sich um Dia­gno­se­diens­te für den Zugriff auf den Feh­ler­spei­cher. Das ent­spricht im Wesent­li­chen dem, was OBD zur Ver­fü­gung stellt. Es gibt hier haupt­säch­lich zwei Diens­te: ReadDTD­In­for­ma­tion und Clear­Dia­gno­sti­c­In­for­ma­tion. Mit ReadDTD­In­for­ma­tion kann man die Feh­ler­ko­des und Free­ze-Fra­me Daten aus­le­sen und mit Clear­Dia­gno­sti­c­In­for­ma­tion kann man den Feh­ler­spei­cher löschen. KWP 2000 hat­te hier viel mehr Diens­te. Die­se sind bei UDS nicht ver­schwun­den, son­dern ledig­lich in einem Dienst zusam­men­ge­fasst. Wobei die Unter­schei­dung über den Sub-Level-Para­me­ter erfolgt.

Dann hat­ten wir bei OBD bereits Diens­te, die bestimm­te Test­funk­tio­nen, zum Bei­spiel den Tan­kent­lüf­tungs­test akti­vie­ren kön­nen. Das haben wir eben­falls in erwei­ter­ter Form bei UDS. Dies ist die Funk­ti­ons­grup­pe Input-Out­put-Con­trol. In eine ganz ähn­li­che Rich­tung gehen auch die Dia­gno­se­diens­te der Funk­ti­ons­grup­pe Remo­te-Acti­va­tion-Of-Rou­ti­ne. Mit dem Dienst Rou­ti­ne­Con­trol kann man im Prin­zip eine belie­bi­ge, von der Steu­er­ge­rä­te­ent­wick­lung im Steu­er­ge­rät vor­pro­gram­mier­te Funk­tion, von außen akti­vie­ren. Das kann ein Tes­ta­blauf, eine Rou­ti­ne zur Flas­h­pro­gram­mie­rung oder etwas ande­res sein. Zuletzt fin­den wir noch die Funk­ti­ons­grup­pe Upload-Dow­n­load. Hier sind Diens­te zusam­men­ge­fasst, mit denen man den Steu­er­ge­rä­te­spei­cher in großen Blö­cken lesen oder schrei­ben kann. Sie wer­den meist für das Aus­le­sen von Betrieb­spa­ra­me­tern oder zur Flash-Pro­gram­mie­rung ver­wen­det. Die vor­ge­stell­te Lis­te der Dia­gno­se­diens­te ist kei­nes­wegs voll­stän­dig. Wir haben eine Rei­he von sel­ten genutz­ten exo­ti­schen Funk­tio­nen weg­ge­las­sen, wol­len aber auf eini­ge Spe­zia­li­tä­ten doch noch etwas genau­er ein­ge­hen.

Spezialitäten von UDS

Dies betrifft zum einen die Kom­mu­ni­ka­ti­ons­pa­ra­me­ter. CAN arbei­tet typi­scher­wei­se mit einer fes­ten Bitra­te. Beim Umschal­ten auf eine ande­re Dia­gno­se­sit­zung ist es aber durch­aus mög­lich, die Para­me­ter des Bus­sys­tems oder des Trans­port­pro­to­kolls umzu­stel­len. Die Mög­lich­keit zur Umstel­lung der Bitra­te stammt noch aus Zei­ten der K-Line. Bei CAN wer­den im Wesent­li­chen nur die Para­me­ter des Trans­port­pro­to­kolls, also die Time-Outs zwi­schen Request und Respon­se oder zwi­schen Con­se­cu­ti­ve-Fra­mes umge­stellt. Das macht man haupt­säch­lich bei der Flash-Pro­gram­mie­rung, um die Band­brei­te des Bus­sys­tems, die für die Pro­gram­mier­da­ten nutz­bar ist, zu ver­grö­ßern. Außer­dem sperrt man hier meist die Kom­mu­ni­ka­tion der ande­ren Steu­er­ge­rä­te und schal­tet die Feh­ler­spei­che­rung aus.

Zu den zusätz­li­chen spe­zi­el­len Mög­lich­kei­ten von UDS gehört die Daten­auf­zeich­nung, wie man sie bei Prüf­stän­den oder bei der Fah­rer­pro­bung benö­tigt: Nor­ma­ler­wei­se wer­den Mess­wer­te aus dem Steu­er­ge­rät durch Pol­ling abge­fragt. Das heißt, der Dia­gno­se­tes­ter sen­det eine Request-Anfra­ge an das Steu­er­ge­rät und das Steu­er­ge­rät ant­wor­tet mit genau einer Ant­wort­bot­schaft. Für peri­odisch auf­tre­ten­de Mess­wer­te müss­te der Tes­ter also peri­odisch Requests sen­den. Zur Redu­zie­rung der Bus­last und der Ver­ein­fa­chung der Kom­mu­ni­ka­tion ist es jedoch bei UDS mög­lich, über den Dia­gno­se­dienst Read­Da­ta­By­Pe­ri­odi­cI­den­ti­fier mit nur einen Request peri­odisch Respon­ses zu emp­fan­gen. Die Respon­ses ent­hal­ten dann ent­spre­chend des Iden­ti­fiers die jewei­li­gen Mess­wer­te. Been­det wird die­ser Dienst, sobald der Tes­ter einen wei­te­ren Request sen­det.

Eine wei­te­re spe­zi­el­le Mög­lich­keit in UDS ist der Dia­gno­se­dienst Respon­seO­nE­vent­S­er­vice. Hier sen­det das Steu­er­ge­rät von sich aus, abhän­gig von bestimm­ten inter­nen Ereig­nis­sen, ein oder meh­re­re Ant­wor­ten an den Tes­ter. Typi­sche Ereig­nis­se, die eine der­ar­ti­ge Bot­schaft aus­lö­sen kön­nen sind Zeit­ge­ber­in­ter­rupts, Feh­ler­spei­che­r­ein­trä­ge oder das Über- oder Unter­schrei­ten bestimm­ter Schwell­wer­te.

Zusam­men­fas­send kann man sagen, dass UDS ein rela­tiv kom­ple­xer Stan­dard ist, dass es eine Rei­he optio­na­ler oder red­un­dan­ter Funk­tio­nen gibt und dass man daher in der Pra­xis sel­ten eine 100 pro­zen­ti­ge UDS Imple­men­tie­rung fin­den wird. Jeder Her­stel­ler wird sich typi­scher­wei­se für eine bestimm­te Teil­men­ge ent­schei­den. Dazu kommt, dass die Norm zwar sehr vie­le Diens­te stan­dar­di­siert, dass aber die Inhal­te der Diens­te, wie bei­spiels­wei­se Feh­ler­ko­des, PIDs, Mess­da­ten, Wer­te­be­rei­che etc., in der Regel her­stel­ler­spe­zi­fisch sind.

Beispiel: Flashprogrammierung I

Als prak­ti­sches Bei­spiel für die UDS-Dia­gno­se­diens­te wol­len wir den typi­schen Ablauf einer Flash-Pro­gram­mie­rung betrach­ten, sie­he Abbil­dung. Der Dia­gno­se­tes­ter sen­det als ers­tes eine Read­Da­ta­By­I­den­ti­fier. Mit die­ser Anfra­ge liest er die Hard­wa­re­ken­nung und die Soft­wa­re­ken­nung des Steu­er­ge­rä­tes aus, um zu erfah­ren wel­ches Gerät er genau vor sich hat. Dann schal­tet der Dia­gno­se­tes­ter das Steu­er­ge­rät in eine spe­zi­el­le Dia­gno­se­sit­zung. Noch nicht die eigent­li­che Dia­gno­se­sit­zung für das Pro­gram­mie­ren, son­dern eine Sit­zung, in der eine Rei­he von erwei­ter­ten Diens­ten zur Ver­fü­gung ste­hen. Dies erfolgt mit dem Dia­gno­se­dienst Dia­gno­stic­Ses­sion­Con­trol. In die­ser erwei­ter­ten Dia­gno­se­sit­zung fragt der Dia­gno­se­tes­ter das Steu­er­ge­rät ab, ob die Vor­be­din­gun­gen für die Flas­h­pro­gram­mie­rung erfüllt sind. Dazu gehört typi­scher­wei­se, dass die Pro­gram­mie­rung nur bei ste­hen­dem Fahr­zeug vor­ge­nom­men wer­den kann, dass der Motor aus sein muss usw.

Prin­zi­pi­el­ler Ablauf einer Flas­h­pro­gram­mie­rung

Dann wird der Dia­gno­se­tes­ter nor­ma­ler­wei­se mit dem Ser­vice Com­mu­ni­ca­tion­Con­trol die Feh­ler­spei­che­rung und die Bus­kom­mu­ni­ka­tion in ande­ren Steu­er­ge­rä­ten abschal­ten. Damit hat die erwei­ter­te Dia­gno­se­sit­zung ihren Zweck erfüllt. Nun schal­tet der Dia­gno­se­tes­ter über den Dia­gno­se­dienst Dia­gno­stic­Ses­sion­Con­trol in die Pro­gram­mier­sit­zung um. Spä­tes­tens jetzt ist auch ein Secu­ri­tyAc­cess not­wen­dig. Danach sen­det der Dia­gno­se­tes­ter in der Regel den so genann­ten Fin­ger­print an das Steu­er­ge­rät. Dies ist eine Infor­ma­tion, die im Steu­er­ge­rä­te­spei­cher per­ma­nent abge­legt wird, um die­sen Pro­gram­mier­vor­gang zu kenn­zeich­nen. Dabei wird typi­scher­wei­se eine Werk­statt­ken­nung in den Spei­cher des Steu­er­ge­rä­tes geschrie­ben, damit hin­ter­her nach­voll­zo­gen wer­den kann, wer das Steu­er­ge­rät umpro­gram­miert hat.

Bevor der Flas­h­spei­cher neu pro­gram­miert wer­den kann, muss er gelöscht wer­den. Das wird durch den Auf­ruf einer Rou­ti­ne im Steu­er­ge­rä­te­spei­cher über den Dia­gno­se­dienst Rou­ti­ne­Con­trol erle­digt. Danach wird über den Dienst Request­Dow­n­load der eigent­li­che Pro­gram­mier­vor­gang ein­ge­lei­tet. Über die­sen Dienst wird dem Steu­er­ge­rät auch mit­ge­teilt, in wel­chen Speicher­be­reich die Daten gela­den wer­den und wie vie­le Daten zu erwar­ten sind. Jetzt beginnt der eigent­li­che Dow­n­load der Daten in einer Schlei­fe mit dem Dienst Trans­fer­Da­ta. Der Speicher­be­reich wird hier block­wei­se über­tra­gen. Zum Abschluss sagt der Dia­gno­se­tes­ter dem Steu­er­ge­rät über Trans­fer­E­xit dass nun alle Daten über­tra­gen wur­den. Nach einer Prü­fung der über­tra­ge­nen Daten im Steu­er­ge­rät fin­det nun der eigent­li­che Flas­h­vor­gang statt. Typi­scher­wei­se wird der Pro­gram­mier­vor­gang eini­ge Zeit dau­ern. In die­ser Zeit ist das Steu­er­ge­rät nicht in der Lage, Anfra­gen vom Tes­ter zu ver­ar­bei­ten. Daher wird Das Steu­er­ge­rät den Dienst Trans­fer­E­xit meist mit einer nega­ti­ven Ant­wort und dem Feh­ler­ko­de Respon­se­Pen­ding ant­wor­ten. Erst wenn der Pro­gram­mier­vor­gang abge­schlos­sen ist, sen­det das Steu­er­ge­rät die posi­ti­ve Bestä­ti­gung auf Trans­fer­E­xit.

Danach prüft der Dia­gno­se­tes­ter, ob die Pro­gram­mie­rung erfolg­reich war, indem er über Rou­ti­ne­Con­trol eine Rou­ti­ne im Steu­er­ge­rät akti­viert, die den Spei­cher über­prüft. Danach wer­den über einen wei­te­ren Auf­ruf von Rou­ti­ne­Con­trol ver­schie­de­ne n Abhän­gig­kei­ten der Flas­h­pro­gram­mie­rung über­prüft, bei­spiels­wei­se ob zur Soft­wa­re noch der ent­spre­chen­de Daten­satz pro­gram­miert wer­den muss. Ist der Pro­gram­mier­vor­gang des Steu­er­ge­räts voll­stän­dig abge­schlos­sen, wird das Steu­er­ge­rät nor­ma­ler­wei­se über ECU­Re­set zurück­ge­setzt. Das Steu­er­ge­rät wird neu gest­ar­tet und geht in den nor­ma­len Betrieb, also zurück in die Default-Dia­gno­se­sit­zung.

Um bei den ande­ren Steu­er­ge­rä­ten im Fahr­zeug eben­falls den Nor­mal­zu­stand wie­der­her­zu­stel­len, wird über Com­mu­ni­ca­tion­Con­trol auch die nor­ma­le Bus­kom­mu­ni­ka­tion wie­der auf­ge­nom­men und die Feh­ler­spei­che­rung in den ande­ren Steu­er­ge­rä­ten wird wie­der ein­ge­schal­tet. Damit ist der Pro­gram­mier­vor­gang abge­schlos­sen

Im fol­gen­den Abschnitt wol­len wir noch auf KWP 2000, den Vor­läu­fer von UDS ein­ge­hen.

Siehe auch

Diagnoseprotokolle

OBD on CAN

KWP 2000 on CAN