Diagnoselayer und Diagnosedienste

From emotive
Jump to navigation Jump to search

DIAG-LAYER-CON­TAI­NER

Wir wol­len nun die Con­tai­ne­r­ele­men­te der ODX-Struk­tur beschrei­ben und begin­nen mit dem wich­tigs­ten Con­tai­ne­r­ele­ment, dem DIAG-LAYER-CON­TAI­NER. Er ist Bestand­teil jeder ODX-Beda­tung und ent­hält sämt­li­che Dia­gno­se­diens­te und Dia­gno­seab­läu­fe eines Steu­er­ge­rä­tes inklu­siv der dazu­ge­hö­ri­gen Daten. Der DIAG-LAYER-CON­TAI­NER selbst ist unter­teilt in hier­ar­chi­sche Schich­ten, die soge­nann­ten DIAG-LAYER, deren Zusam­men­hang wir uns auf der fol­gen­den Abbil­dung ver­an­schau­li­chen wol­len.


ODX-DIAG-LAYER-CONTAINER-Inheritance.png
DIAG-LAYER-CON­TAI­NER – Ver­er­bung


Ganz oben haben wir den soge­nann­ten PRO­TO­COL-LAYER. Der PRO­TO­COL-LAYER beschreibt das gene­ri­sche Dia­gno­se­pro­to­koll, das ver­wen­det wer­den soll. Zum Bei­spiel UDS oder KWP 2000. Dann haben wir den BASE-VARI­ANT Dia­gno­se-Layer. Der BASE-VARI­ANT Dia­gno­se-Layer beschreibt eine bestimm­te Gerä­te-Fami­lie, zum Bei­spiel ein Tür­steu­er­ge­rät, von dem es typi­scher­wei­se meh­re­re Vari­an­ten gibt, zum Bei­spiel ein Tür­steu­er­ge­rät für die Front­tü­ren, ein ande­res Tür­steu­er­ge­rät für die Heck­tü­ren. Die­se Vari­an­ten wer­den in der soge­nann­ten ECU-VARI­ANT Dia­gno­se-Schicht beschrie­ben. Häu­fig ist es dabei sinn­voll, bestimm­te Dia­gno­se­diens­te zu grup­pie­ren. Zum Bei­spiel in Diens­te, die die Flash-Pro­gram­mie­rung betref­fen, in Diens­te, die bestimm­te Werk­statt­tes­tab­läu­fe beschrei­ben etc. Das leis­tet der soge­nann­te FUNC­TIO­NAL-GROUP-LAYER. Und schlus­send­lich Funk­tio­nen und Daten, die über­ge­ord­net und in meh­re­ren Pro­jek­ten ver­wen­det wer­den kön­nen, fasst man in der Regel im ECU-SHA­RED-DATA-LAYER zusam­men. Die­ser ECU-SHA­RED-DATA Con­tai­ner stellt eine Art Biblio­thek dar. Zu den Kern­kon­zep­ten von ODX gehört es, Daten nur ein­ma­lig defi­nie­ren zu müs­sen und dann inner­halb des­sel­ben Pro­jekts oder in ande­ren Pro­jek­ten ein­fach wie­der­zu­ver­wen­den. Dadurch wird die Daten­men­ge ins­ge­samt redu­ziert und die Daten­si­cher­heit ver­grö­ßert, da immer nur Ände­run­gen gegen­über einem Refe­renz­da­ten­satz beschrie­ben wer­den müs­sen. Die ECU-SHA­RED-DATA Biblio­thek ist dabei eine ers­te Mög­lich­keit, sol­che Daten wie­der­zu­ver­wen­den. Im Bereich ECU-SHA­RED-DATA defi­nier­te Daten, kön­nen von ande­ren Schich­ten impor­tiert und somit ver­wen­det wer­den. Das Impor­tie­ren erfolgt durch ein Refe­ren­zie­ren, das heißt, inner­halb des PRO­TO­COL-LAYERS kann zum Bei­spiel ein Ele­ment aus der Biblio­thek ECU-SHA­RED-DATA ver­wen­det wer­den, indem im PRO­TO­COL-LAYER auf die­ses Ele­ment ver­wie­sen wird.

Refe­ren­zen und Ver­er­bung

Für die­se Refe­ren­zen kennt ODX zwei ver­schie­de­ne Mög­lich­kei­ten, die wir nach­fol­gend betrach­ten wol­len.

Zum einen ist der Ver­weis über die ID mög­lich. Sie haben vor­her gese­hen, jedes ODX-Ele­ment kann eine ID bekom­men. Ein Ver­weis erfolgt, indem man in einem Ele­ment über einen ODX-LINK (ID-REF) auf die ID des ande­ren Ele­men­tes ver­weist. Die zwei­te Mög­lich­keit besteht darin, über den SHORT-NAME auf ein ande­res Objekt zu ver­wei­sen. Das ist die soge­nann­te SHORT-NAME-REF (SN-REF).

Beim Impor­tie­ren von Daten aus der ECU-SHA­RED DATA Biblio­thek kön­nen die impor­tier­ten Daten nicht ver­än­dert wer­den. Dies macht für häu­fig ver­wen­de­te Biblio­the­ken, sie sich kaum ändern, Sinn. Eine leis­tungs­fä­hi­ge­re Mög­lich­keit, Daten wie­der­zu­ver­wen­den, ist jedoch das Ver­er­ben.

Das Ver­er­ben ist ein Grund­kon­zept der Infor­ma­tik. Beim Ver­er­ben defi­niert man auf einer höhe­ren der so genann­ten Parent-Schicht, im Bei­spiel hier Pro­to­col-Layer, Diens­te und Daten in gene­ri­scher Form. Die dar­un­ter lie­gen­den Schich­ten, zum Bei­spiel der BASE-VARI­ANT Layer, erben die­se Diens­te. Das heißt, sie kön­nen alle Diens­te, die auf der höhe­ren Schicht defi­niert wur­den, eben­falls ver­wen­den. Dies bezeich­net man als Erben. Die dar­un­ter lie­gen­den Schich­ten kön­nen die­se Diens­te aber auch modi­fi­zie­ren. Bei­spiels­wei­se kön­nen bei ein­zel­nen Diens­ten ande­re Imple­men­tie­run­gen, ande­re Para­me­ter etc. nötig sein. Dies bezeich­net man als Über­schrei­ben. Wei­ter­hin kann auch die Ver­wen­dung ein­zel­ner Diens­te oder Daten aus­ge­schlos­sen wer­den. Dies bezeich­net man als Enter­ben.

Prak­tisch erfolgt das Ver­er­ben durch Refe­ren­zen. Die zu erben­de Schicht refe­ren­ziert auf die Schicht, von der sie erben will. Im Unter­schied zum Import, wo auf ein ein­zel­nes Daten­ele­ment ver­wie­sen wird, wird beim Erben auf eine gan­ze höher gele­ge­ne Schicht ver­wie­sen. Das Über­schrei­ben eines Ele­men­tes ist geschieht, in der man in der Schicht, die über­schrei­ben möch­te, ein glei­ches Ele­ment mit dem glei­chen SHORT-NAME defi­niert.

Die Sicht­bar­keit der Ele­men­te hängt davon ab, wel­che Ver­wei­se gewählt wer­den, ob mit ODX-LINK oder mit SHORT-NAME refe­ren­ziert wird. Das Enter­ben, das heißt, das Unsicht­bar-Machen geerb­ter Ele­men­te, erfolgt mit einem spe­zi­el­len Attri­but, dem NOT-INHE­RI­TED-SHORT-NAME-REF Attri­but.

Das Ver­er­ben und Enter­ben ist sehr leis­tungs­fä­hig, was die Wie­der­ver­wen­dung der Daten angeht. Es ist aller­dings auch feh­ler­träch­tig, weil nicht immer ein­deu­tig klar ist, wel­che Ele­men­te auf wel­cher Ebe­ne defi­niert wer­den.

Schau­en wir uns nun zum The­ma Ver­er­ben und zum The­ma Sicht­bar­keit beim Ver­er­ben ver­schie­de­ne Bei­spie­le an. Ein ers­tes Bei­spiel, in dem es drei ver­schie­de­ne Schich­ten gibt, A, B und C. A ist die hier­ar­chisch höchs­te, C die hier­ar­chisch nied­rigs­te Schicht. Inner­halb der höchs­ten Stu­fe A wer­den 2 Objek­te defi­niert, Objekt O1 und Objekt O2, wobei das Objekt O1 über eine Short-Name-Refe­rence auf das Objekt O2 refe­ren­ziert. O1 sei zum Bei­spiel ein Dia­gno­se­dienst, O2 sei ein bestimm­ter Para­me­ter die­ses Dia­gno­se­diens­tes. Die Schicht B erbt nun von die­ser Schicht A, das heißt die Objek­te O1 und theo­re­tisch auch O2 sind in der Schicht B gen­au­so ver­füg­bar. Da die Schicht B aller­dings den Para­me­ter O2 umde­fi­nie­ren möch­te, defi­niert sie einen eige­nen, von O2 abge­lei­te­ten Para­me­ter O2`. Das Objekt O1 in der Schicht B ist von der Schicht A geerbt und wird dort nicht ver­än­dert. Durch die Short-Name-Refe­rence refe­ren­ziert nun das Objekt O1 in der Schicht B, nicht O2, das es ja gar nicht geerbt hat, weil es ja über­schrie­ben wur­de, son­dern refe­ren­ziert das Objekt O2`. Das glei­che sehen wir noch­mals auf der Schicht C. Die Schicht C erbt von der Schicht B. Die­se wie­der­um von der Schicht A, das heißt das Objekt O1 ist auch in der Schicht C ver­wend­bar. Das Objekt O2` wür­de die Schicht C theo­re­tisch von der Schicht B erben (nicht O2), möch­te das aber eben­falls als O2`` selbst defi­nie­ren. Die SHORT-NAME-REF von Objekt O1 zeigt nun in der Schicht C auf das Objekt O2``. Das heißt die SHORT-NAME-REF bleibt inner­halb der­sel­ben Schicht. Wenn dort ein Ele­ment über­schrie­ben wird, zeigt die SHORT-NAME-REF auf das über­schrie­be­ne Ele­ment in der­sel­ben Schicht.


ODX-Inheritance-SN-REF.png
Refe­ren­zen und Ver­er­bung – SHORT-NAME-REF (SN-REF)


Schau­en wir uns nun die­sel­be Struk­tur mit den drei hier­ar­chi­schen Ebe­nen A, B und C und den bei­den Ele­men­ten O1 und O2 inner­halb einer Schicht an, wenn statt des Ver­wei­ses über den SHORT-NAME ein Ver­weis über die ID, ein soge­nann­ter ODX-Link, ver­wen­det wird. In der Ebe­ne A lie­gen wie­der­um die Objek­te O1 und O2, wobei jetzt O1 auf O2 über einen ODX-Link ver­weist. In der Schicht B wie­der­um wird das Objekt O1 unver­än­dert geerbt, wäh­rend das Objekt O2 durch ein Objekt O2` über­schrie­ben wird. Nun ver­weist das Objekt O1 in der Schicht B auf das Objekt O2, aber nicht in der Schicht B, son­dern in Schicht A, auf das­sel­be O2, auf das das O1 in A auch ver­wie­sen hat. Grund: O2 und O2` haben unter­schied­li­che IDs. In Schicht C sieht es gen­au­so aus: O1, das ja letzt­lich von A geerbt wur­de, ver­weist in C immer noch auf die ID von O2 in A. Die über­schrie­be­nen Objek­te O2` und O2`` in den Ebe­nen B und C sind zwar defi­niert, aber das O1-Objekt ver­wen­det sie nicht, son­dern ver­wen­det immer noch das O2 aus A.


ODX-Inheritance-ODX-LINK.png
Refe­ren­zen und Ver­er­bung – OTX-LINK oder ID-REF



Wir emp­feh­len daher bei Ver­wei­sen, grund­sätz­lich SHORT-NAMES zu ver­wen­den, da SHORT-NAMES das Objekt in der­sel­ben Schicht refe­ren­zie­ren und Alle Ände­run­gen somit auto­ma­tisch über­nom­men wer­den. Den ODX-Link soll­ten Sie nur dann ver­wen­den, wenn Sie bewusst auf ein ein­deu­ti­ges Objekt in einer ande­ren Schicht ver­wei­sen möch­ten!

Enter­ben

Schau­en wir uns als drit­tes Bei­spiel das Enter­ben an. Auch hier wie­der 3 Ebe­nen. Die Ebe­nen A, B und C. A ist hier­ar­chisch wie­der die obers­te Ebe­ne. Dort ist ein Objekt O3 defi­niert. Die Ebe­ne B erbt von der Ebe­ne A, das Objekt O3 ist in der Ebe­ne B eben­falls sicht­bar und ver­wend­bar. Ebe­ne B defi­niert selbst noch zwei wei­te­re Objek­te O1 und O2. Die Ebe­ne C erbt ihrer­seits wie­der von B. Das heißt, die Objek­te O1 und O2 wären dort sicht­bar. O2 aller­dings wird in C mit O2` über­schrie­ben. Das Objekt O3 erhält auf C das NOT-INHE­RI­TED Attri­but. Es ist somit auf der Ebe­ne C weder sicht- noch ver­wend­bar.


ODX-Disinheritance.png
Refe­ren­zen und Ver­er­bung – Enter­ben


DIAG-COMM-PRI­MI­TI­VES

DIAG-COMM-PRI­MI­TI­VES beschrei­ben die Dia­gno­se­diens­te inner­halb des DIA­GNO­STIC-LAYERs. Dafür gibt es das ODX-Beschrei­bungs­ele­ment DIAG-SER­VICE, das drei Unte­r­ele­men­te ent­hält. Einen REQUEST, eine oder meh­re­re posi­ti­ve Ant­wort­bot­schaf­ten (POS-RESPON­SE) und eine oder meh­re­re nega­ti­ve Ant­wort­bot­schaf­ten (NEG-RESPON­SE). Die­se Ele­men­te ver­wei­sen ihrer­seits wie­der auf Para­me­ter. Die Para­me­ter kön­nen wie­der­um soge­nann­te DATA-OBJECT-PRO­PER­TIES (DOP), das sind Umrech­nungs­me­tho­den, ent­hal­ten und die­se wei­ter­hin kön­nen auf ent­spre­chen­de phy­si­ka­li­sche Ein­heit ver­wei­sen, so genann­te UNITS.

Abläu­fe, die die Aus­füh­rung meh­re­rer Dia­gno­se­diens­te hin­ter­ein­an­der, ins­be­son­de­re in Abhän­gig­keit von Ant­wort­da­ten eines Diens­tes erfor­dern, las­sen sich als Makros, als soge­nann­te SINGLE-ECU-JOBS in ODX defi­nie­ren. SINGLE-ECU-JOBS sind Java-Pro­gram­me, das heißt das Daten­ele­ment in der ODX-Struk­tur ver­weist auf ein Java-Pro­gramm. In der ODX-Daten­struk­tur muss defi­niert wer­den, wel­ches Java-Pro­gramm für die­sen Ablauf auf­zu­ru­fen ist, wel­che Para­me­ter hin­ein­ge­hen, wel­che Para­me­ter her­aus­ge­hen und wel­che Rück­ga­be­wer­te im Feh­ler­fall gelie­fert wer­den (INPUT-PARAMS, OUT­PUT-PARAMS und NEG-OUT­PUT-PARAMS). Die Detail­be­schrei­bung der Para­me­ter selbst erfolgt wie­der über DATA-OBJECT-PRO­PER­TIES mit den ent­spre­chen­den Ein­hei­ten (UNITS).


ODX-DIAG-COMMS.png
Dia­gno­stic Com­mu­ni­ca­tion Pri­mi­ti­ves (DIAG-COMMS)


ODX unter­schei­det ver­schie­de­ne Para­me­ter­ty­pen, sie­he Tabel­le. Wir haben hier unter ande­rem die kodier­ten Kon­stan­ten (CODED-CONST). Dies sind bei­spiels­wei­se SIDs, also fixe hexa­de­zi­ma­le Zah­len­wer­te. Wei­ter­hin gibt es Para­me­ter, die einen phy­si­ka­li­schen Wert dar­stel­len, die PHYS-CONST.

Die eigent­li­chen Zah­len­wer­te (VALUE) ver­wei­sen immer auf das ent­spre­chen­de DATA-OBJECT-PRO­PER­TY, sie­he unten und dann haben wir noch kom­ple­xe Para­me­ter­struk­tu­ren, die über Tabel­len beschrie­ben wer­den. Die Tabel­len beste­hen dabei aus einem Schlüs­sel, mit dem die Tabel­le indi­ziert wird und der eigent­li­chen Daten­struk­tur. Die­se ent­hält die ent­spre­chen­den Tabel­len­ein­trä­ge.


ODX-DIAG-SERVICE-Parameter.png
Para­me­ter-Typen für DIAG-SER­VICES


DATA-OBJECT-PRO­PER­TY (DOP)

DOPs ent­hal­ten alle not­wen­di­gen Anga­ben, um die von einem Dia­gno­se­dienst gelie­fer­ten oder mit einem Dia­gno­se­dienst zu sen­den­den Daten für den Men­schen inter­pre­tier­bar zu machen. Wir unter­schei­den zwei Arten von DOPs. Die ein­fa­chen SIM­PLE-DOPs, die einen ein­zel­nen Daten­wert beschrei­ben und die COM­PLEX-DOPs, die Struk­tu­ren von Daten­wer­ten defi­nie­ren. Ein DOP defi­niert im Wesent­li­chen die Umrech­nungs­me­tho­de zwi­schen dem kodier­ten Wert, wie er letzt­lich ans Steu­er­ge­rät über­tra­gen wird und der phy­si­ka­li­schen Grö­ße.


ODX-DOPS.png
DATA-OBJECT-PRO­PER­TY (DOP)


Fol­gen­de Daten wer­den im DOP gespei­chert:

  • COM­PU-METHOD
    • Umrech­nungs­me­tho­de zw. kodier­ten Wert und der phy­si­ka­li­schen Grö­ße

  • DIAG-CODED-TYPE
    • Daten­typ des kodier­ten Wer­tes eines Para­me­ters

  • PHY­SI­CAL-TYPE
    • Daten­typ des phy­si­ka­li­schen Wer­tes eines Para­me­ters

  • INTER­NAL-CON­STR
    • Gül­tig­keits­in­ter­val­le für den Para­me­ter im kodier­ten For­mat

  • UNIT-REF
    • Refe­renz zur phy­si­ka­li­schen Ein­heit des Para­me­ters

  • PHYS-CON­STR
    • Gül­tig­keits­in­ter­val­le für den phy­si­ka­li­schen Para­me­ter

Umrech­nungs­me­tho­den (COM­PU-METHOD)

ODX stellt eine Viel­zahl von Umrech­nungs­me­tho­den für Date­n­ob­jek­te bereit, sie­he Abbil­dung. Für Feh­ler zum Bei­spiel ver­wen­det man häu­fig die Text­ta­ble, mit der einem Feh­ler­co­de, der typi­scher­wei­se hexa­de­zi­mal kodiert ist, ein Klar­text zuge­ord­net wer­den kann. Vie­le Wer­te sind über­haupt nicht kodiert, das heißt, der phy­si­ka­li­sche und der kodier­te Wert sind iden­tisch. Hier setzt man die Umrech­nungs­me­tho­de Iden­ti­cal ein. Vie­le Sen­sor­wer­te ver­wen­den eine linea­re Zuord­nung mit Stei­gung und Off­set, die Linear Umrech­nungs­me­tho­de. Mit Sca­le-Linear gibt es auch eine stück­wei­se linea­re Umrech­nung, indem man eine Kenn­li­nie durch stück­wei­se linea­re Funk­tio­nen beschreibt. Nahe­zu belie­bi­ge Funk­tio­nen las­sen sich über den Quo­ti­en­ten zwei­er Poly­no­me mit der Rat-Func Umrech­nungs­me­tho­de abbil­den. Wenn das allei­ne nicht reicht, kann man sol­che Quo­ti­en­ten von ratio­na­len Funk­tio­nen auch stück­wei­se zusam­men­set­zen, sie­he Sca­le-Rat-Func. Dann haben wir die übli­chen Kenn­li­ni­en, die linear inter­pre­tiert wer­den: Tab-Interp und Umrech­nungs­me­tho­den, die so kom­plex sind, dass man sie in Pro­gram­me aus­la­gern muss. Dafür besteht die Mög­lich­keit des Compu­co­des, der auf ein exter­nes Java-Pro­gramm ver­weist, das die­se Umrech­nung dann durch­führt.


ODX-COMPU-METHOD.png
Umrech­nungs­me­tho­den (COM­PU-METHOD)


Daten­ty­pen für DOPs (Diag-Coded-Types)

Auch bei den Daten­ty­pen erweist sich ODX als recht fle­xi­bel. Für kodier­te Daten­ty­pen gibt es bei­spiels­wei­se den Stan­dard-Length-Type. Wenn der Wert eine fes­te Län­ge hat, dann defi­niert man in der DOP die Anzahl der Bits die not­wen­dig sind, um den Zah­len­wert dar­zu­stel­len. Für Daten, bei denen die Län­ge in einem bestimm­ten Bereich vari­iert, gibt es den Min-Max-Length-Type. Dort müs­sen in der ODX-Beschrei­bung die mini­ma­le, die maxi­ma­le Bit-Län­ge und eine Ende-Kenn­zeich­nung für den Daten­wert ange­ben wer­den. Das ist eine typi­sche Beschrei­bungs­form für Strings, die typi­scher­wei­se mit 0 als letz­tem Byte abge­schlos­sen wer­den. Bei man­chen Dia­gno­se­diens­ten ist die Län­ge der Daten Teil der Ant­wort­bot­schaft. Dafür eig­net sich der Lea­ding-Length-Info-Type. Und nicht zuletzt gibt es noch den Param-Length-Info-Type. Das ist ein Daten­typ für Daten, deren Län­ge durch einen ande­ren Daten­wert beschrie­ben wird. Das heißt, es gibt einen Daten­wert, der die Län­ge ent­hält und einen wei­te­ren Daten­wert, der dann die eigent­li­chen Wer­te bein­hal­tet. Das ist zum Bei­spiel bei der Abla­ge des Feh­ler­spei­chers üblich. Sie erin­nern sich an die Bot­schaft, mit der man die Anzahl der Feh­ler lesen konn­te. Die ist aus ODX-Sicht ein Para­me­ter, die Feh­ler­co­des sind dann der zuge­hö­ri­ge Daten­wert.


ODX-DIAG-CODED-TYPES.png
Daten­ty­pen für DOPs (DIAG-CODED-TYPES)


Kom­ple­xe Daten­ele­men­te (Com­plex-DOP)

Wo ein­fa­che Daten­ele­men­te nicht aus­rei­chen, las­sen sich Com­plex-DOPs ein­set­zen. COM­PLEX-DOPs sind aus ein­fa­chen Date­n­ob­jek­ten zusam­men­ge­setz­te Struk­tu­ren. Sie wer­den u. a. ver­wen­det, wenn die Art und Zusam­men­set­zung der Para­me­ter erst zur Lauf­zeit bestimmt wer­den kann. Ein typi­scher Anwen­dungs­fall ist die Beschrei­bung des Feh­ler­spei­chers. Er besteht aus Feh­ler­co­des und soge­nann­ten Free­ze-Fra­mes (Umge­bungs­da­ten des Feh­lers).

Mit den Mul­ti­ple­xer-Ele­men­ten MUX, stellt ODX eine Mög­lich­keit bereit, inner­halb der ODX-Daten eine Art Ver­zwei­gung zu imple­men­tie­ren. Das ist zum Bei­spiel sinn­voll, wenn man eine Mess­da­ten­an­fra­ge abge­schickt hat und die Bear­bei­tung der Ant­wort­bot­schaft abhän­gig von den PIDs, die in der Ant­wort ent­hal­ten sind, erfol­gen muss. Das kann über ein MUX-Ele­ment gelöst wer­den. Das MUX-Ele­ment selbst ver­zweigt dann auf ver­schie­de­ne ein­fa­che DOPs oder Struk­tu­ren. Struk­tu­ren ihrer­seits kön­nen ein­fach sein, sie kön­nen aber auch als Arrays mit einer fes­ten oder einer dyna­mi­schen Anzahl wie­der­holt wer­den.


ODX-COMPLEX-DOPS.png
COM­PLEX-DOPs sind aus ein­fa­chen Date­n­ob­jek­ten zusam­men­ge­setz­te Struk­tu­ren


Vari­an­te­ni­den­ti­fi­ka­tion

ODX kann ver­schie­de­ne Vari­an­ten eines Steu­er­ge­rä­tes hand­ha­ben. Auf­grund der­sel­ben phy­si­ka­li­schen Adres­se (PHY­SI­CAL-VEHIC­LE-LINK), kann zur Lauf­zeit immer nur eine Vari­an­te aktiv sein (BASE-VARI­ANT oder ECU-VARI­ANT). Bevor eine Vari­an­te selek­tiert wer­den kann, wird nor­ma­ler­wei­se über das Dia­gno­se­lauf­zeit­sys­tem die jewei­li­ge Basis-Vari­an­te aus­ge­wählt. Jedes Steu­er­ge­rät besitzt eine Iden­ti­fi­ka­tion, wel­ches das Steu­er­ge­rät und sei­ne jewei­li­ge Vari­an­te ein­deu­tig beschreibt. Das Lauf­zeit­sys­tem ver­sen­det nun ein oder meh­re­re Dia­gno­se­ser­vices (z.B.: Rea­dE­CUI­den­ti­fi­ca­tion) wel­che im ECU-VARI­ANT-PAT­TERN-Ele­ment der ECU-VARI­ANT defi­niert sind und ver­gleicht die Ant­wor­ten vom Steu­er­ge­rät mit den eben­falls dort kon­fi­gu­rier­ten Ant­wor­ten (MAT­CHING-PARA­ME­TERS). Stim­men dies über­ein, wur­de die Vari­an­te kor­rekt erkannt. Nor­ma­ler­wei­se schal­tet das Lauf­zeit­sys­tem nun direkt auf die­se Vari­an­te um, d. h. es ist nicht mehr die Basis-Vari­an­te son­dern die ECU-Vari­an­te aus­ge­wählt.


Siehe auch

Autorenwerkzeuge

Grundstruktur

Gemeinsame Elemente

Fehlerspeicher

Diagnosesitzungen

Kommunikationsparameter

Fahrzeugzugang

Steuergeräteprogrammierung

Diagnoseabläufe mit mehreren Geräten

Variantenkodierung

Funktionsorientierten Diagnose