Fehlerspeicher

From emotive
Jump to navigation Jump to search

Anwendungsbeispiel: Fehlerspeicher (DTC-DOP, ENV-DATA-DESC)

Als Anwen­dungs­bei­spie­le für kom­ple­xe Date­n­ob­jek­te wol­len wir das Aus­le­sen des Feh­ler­spei­chers betrach­ten. Das Aus­le­sen des Feh­ler­spei­chers ist immer zwei­stu­fig. Sie erin­nern sich: Der Inhalt des Feh­ler­spei­chers besteht aus der Anzahl der Feh­ler, aus einem Feh­ler­co­de für jeden ein­zel­nen Feh­ler (DTC = Dia­gno­stic-Trouble-Code) und einem Sta­tuts. Der Sta­tus bein­hal­tet, ob der Feh­ler aktiv ist, ob es sich um einen spo­ra­di­schen oder einen per­ma­nen­ten Feh­ler. Wei­ter­hin besteht der Feh­ler­spei­cher aus den Umge­bungs­da­ten, den soge­nann­ten Free­ze-Fra­meS. Dies sind Mess­wer­te, wie bei­spiels­wei­se die Motor­dreh­zahl zum Zeit­punkt als der Feh­ler auf­trat.

Um die­se Feh­ler­spei­che­r­ein­trä­ge zu beschrei­ben stellt ODX die DTC-DOPs und die Envi­ron­men­tal-Data-Des­crip­tion (ENV-DATA-DESC) bereit. In der Abbil­dung ist ein typi­scher Ablauf von Dia­gno­se­bot­schaf­ten abge­bil­det. Er beginnt mit dem Aus­le­sen des Feh­l­er­sta­tus. Wir setz­ten hier im Bei­spiel KWP 2000 als Pro­to­koll ein. Die ers­te Dia­gno­se­bot­schaft ist ReadDT­C­By­Sta­tus, beste­hend aus dem Request, hier in oran­ge dar­ge­stellt, mit der Ser­vice-ID 0x18 und den not­wen­di­gen Para­me­tern, wel­che den Inhalt des Feh­ler­spei­chers kenn­zeich­nen. Im Bei­spiel wird der gesam­te Feh­ler­spei­cher aus­ge­le­sen. Auf der rech­ten Sei­te wird in Gelb die Respon­se vom Steu­er­ge­rät dar­ge­stellt. Da wird als Echo die um 0x40 erhöh­te SID zurück­ge­lie­fert, also 0x58. Dann erscheint in der Respon­se die Anzahl der Feh­ler­spei­che­r­ein­trä­ge (hier 2) gefolgt von dem eigent­li­chen Feh­ler­ko­de und einem Sta­tus. Feh­ler­ko­de und Sta­tus wer­den danach so oft wie­der­holt, wie Feh­ler vor­han­den sind.

Mit der Read­Sta­tu­sOfDTC-Bot­schaft soll nun aus­ge­le­sen wer­den, wel­che Umge­bungs­da­ten zu einem bestimm­ten Feh­ler gespei­chert wer­den. Dazu sen­det der Dia­gno­se­tes­ter eine Anfra­ge (REQUEST) für jeden Feh­ler­co­de, der in der vori­gen Bot­schaft aus­ge­le­sen wur­de. Das Steu­er­ge­rät ant­wor­tet mit den jewei­li­gen zu die­sem Feh­ler gespei­cher­ten Umge­bungs­da­ten, also Motor­dreh­zahl, Kühl­was­ser­tem­pe­ra­tur etc.


ODX-DTC-DOP1.png
Daten­ele­men­te für den Feh­ler­spei­cher DTC-DOP, ENV-DATA-DESC


Wie wird nun der ers­te Teil der Dia­gno­se­bot­schaft in ODX defi­niert? Schau­en wir uns dazu die Struk­tur an, mit der ODX die Ant­wort­bot­schaft für den ers­ten Request (ers­te gelb mar­kier­te Bot­schaft Abbil­dung oben) defi­niert, sie­he Abbil­dung unten.


ODX-DTC-DOP2.png
Lesen des Feh­ler­spei­ch­er­sta­tus – Posi­ti­ve Respon­se von ReadDT­C­By­Sta­tus


Der ers­te Daten­wert in der Ant­wort­bot­schaft ist die SID für ReadDT­C­By­Sta­tus. Wir defi­nie­ren einen Para­me­ter vom Typ CODED-CONST. Der zwei­te Daten­wert ist die Anzahl der Feh­ler. Hier­für wird ein Para­me­ter vom Typ Value defi­niert. Es reicht ein SIM­PLE-DOP, da die Anzahl der Feh­ler immer genau ein Byte, hat also eine fes­te Län­ge hat. Anders sieht es dage­gen mit der Daten­struk­tur aus, die sich beste­hend aus DTC und Sta­tus des ent­spre­chen­den Feh­lers ergibt. Da die Anzahl der Feh­ler varia­bel ist, kann sich die­se Daten­struk­tur wie­der­ho­len. Sie hängt damit vom ers­ten Para­me­ter ab. Man wird die Lis­te der vor­han­de­nen Feh­ler mit ihrem zuge­hö­ri­gen Sta­tus daher als Struk­tur mit einer dyna­mi­schen Län­ge (DYNA­MIC-LENGTH-FIELD) defi­nie­ren. Inner­halb die­ser Struk­tur wird man wie­der auf eine Struk­tur ver­wei­sen, beste­hend aus dem eigent­li­chen Feh­ler­co­de mit 2 Bytes, der über einen DOP beschrie­ben wird und dem ent­spre­chen­den Sta­tus mit 1 Byte, der eben­falls über einen DOP beschrie­ben wird. Für den Feh­ler­co­de selbst wird man einen DTC-DOP beschrei­ben, der dem hexa­de­zi­ma­len Feh­ler­co­de eine Klar­text­be­schrei­bung zuord­net.

Für das ite­ra­ti­ve Lesen der ein­zel­nen Feh­ler­spei­che­r­ein­trä­ge im zwei­ten Schritt betrach­ten wir nun die Respon­se zu Read­Sta­tu­sOfDTC, wie sie in ODX beschrie­ben wird.


ODX-DTC-DOP3.png


Nach der SID wer­den wie­der­um der Feh­ler­co­de und der Sta­tus des Feh­lers zurück­ge­lie­fert. Das wird, wie im vori­gen Abschnitt beschrie­ben, durch eine Struk­tur dar­ge­stellt, die ihrer­seits wie­der auf eine DTC-DOP ver­weist. Die Umge­bungs­da­ten, die bei einem Feh­ler zurück­ge­mel­det wer­den, sind abhän­gig vom ent­spre­chen­den DTC. Sie wer­den in der Tabel­le Env-Data-Desc als eine Ansamm­lung von Struk­tu­ren abge­legt. Die­se Tabel­le wird durch den DTC zur Lauf­zeit indi­ziert.


Siehe auch

Autorenwerkzeuge

Grundstruktur

Gemeinsame Elemente

Diagnoselayer und Diagnosedienste

Diagnosesitzungen

Kommunikationsparameter

Fahrzeugzugang

Steuergeräteprogrammierung

Diagnoseabläufe mit mehreren Geräten

Variantenkodierung

Funktionsorientierten Diagnose