Einfuehrung OTX

OTX (Open Test sequence eXchan­ge) ist eine Domä­nen spe­zi­fi­sche Spra­che auf hoher Abstrak­ti­ons­ebe­ne mit dem Ziel der gra­phi­schen Beschrei­bung von Prüf­se­quen­zen für die Off-Board-Dia­gno­se. Das XML basier­te Platt­form und Tes­ter unab­hän­gi­ge Aus­tausch­for­mat ist in der ISO 13209 beschrie­ben und besteht aus 3 Tei­len, sie­he Tabel­le. Teil 1 gibt einen all­ge­mei­nen Über­blick über die ver­schie­de­nen Tei­le des Stan­dards und zeigt Anwen­dungs­fäl­le auf. Der Teil 2 spe­zi­fi­ziert das so genann­te Core-Daten­mo­dell. Er beschreibt die Basis-Struk­tur die jedem OTX-Ele­ment zugrun­de liegt. Er defi­niert die Ablauf­lo­gik für Prüf­se­quen­zen und ent­hält ähn­lich einer pro­ze­du­ra­len Pro­gram­mier­spra­che alle dafür nöti­gen Kon­troll­struk­tu­ren, Dekla­ra­tio­nen, Feh­ler­be­hand­lungs- und Erwei­te­rungs­me­cha­nis­men.

ISO 13209 Open Test sequence eXchan­ge For­mat
Stan­dard	Beschrei­bung
ISO 13209 - 1	All­ge­mei­ner Über­blick und Anwen­dungs­bei­spie­le
ISO 13209 - 2	Core Daten­mo­dell
ISO 13209 - 3	Erwei­te­rungs­bi­blio­the­ken (Diag­Com, HMI etc.)

In Teil 3 sind dann die stan­dar­di­sier­ten Erwei­te­rungs­bi­blio­the­ken für die unter­schied­li­chen Auf­ga­ben in der Fahr­zeug­dia­gno­se beschrie­ben. Sie ver­wen­den den nor­ma­len Erwei­te­rungs­me­cha­nis­mus des Core-Daten­mo­dells. Erst im Teil 3 des Stan­dards kommt die Fahr­zeug­dia­gno­se zum tra­gen. Das Core-Daten­mo­dell selbst ist davon unab­hän­gig und kann bei­spiels­wei­se auch in der Tes­t­au­to­ma­ti­sie­rung oder der HIL-Simu­la­tion ver­wen­det wer­den.

OTX folgt dem Prin­zip der impe­ra­ti­ven, struk­tu­rier­ten Pro­gram­mie­rung. "Impe­ra­tiv" bedeu­tet im Wesent­li­chen, dass die Spra­che modu­lar auf­ge­baut ist. Die Modu­le sol­len dabei nach fol­gen­den zwei Grund­sät­zen unab­hän­gig von­ein­an­der ent­wi­ckel- und test­bar sein:

• Modul A soll­te so wenig Wis­sen über Modul B wie mög­lich besit­zen
• Modul A ist ver­än­der- oder reim­ple­men­tier­bar, ohne Modul B zu ver­än­dern

Gemäß den Prin­zi­pi­en der struk­tu­rier­ten Pro­gram­mie­rung sind in OTX kei­ne expli­zi­ten Sprün­ge (goto) son­dern nur kon­trol­lier­te, impli­zi­te Sprün­ge (return, con­ti­nue, break, throw etc.) erlaubt.

Da der typi­sche Autor von Dia­gno­se-Test­se­quen­zen zwar ein Fach­mann für Dia­gno­se­pro­zes­se jedoch kein Soft­wa­re­ent­wick­ler ist, wur­de OTX im Gegen­satz zu ande­ren Pro­gram­mier­spra­chen, in denen Pro­gramm-Code meist in Text-Edi­to­ren geschrie­ben wird, spe­zi­fi­sche für die Ver­wen­dung inner­halb gra­fi­scher Auto­ren­sys­te­me ent­wi­ckelt. Dabei stand die ein­fa­che und pro­zess­si­che­re Erzeu­gung feh­ler­frei­er und aus­tausch­ba­rer Test­se­quen­zen im Vor­der­grund. Es fin­den sich daher in OTX Struk­tu­ren, wie bei­spiels­wei­se das Spe­ci­fi­ca­tion/Rea­li­sa­tion Kon­zept, wel­che in ande­ren Pro­gram­mier­spra­chen nicht vor­kom­men.

OTX selbst beschreibt nur die Schnitt­stel­len der ein­zel­nen Ele­men­te! Die detail­lier­te Beschrei­bung des Lauf­zeit­ver­hal­tens der Ele­men­te ist kein Bestand­teil von OTX! Es ist die Auf­ga­be eines OTX kom­pa­ti­blen Ablauf­sy­tems (OTX-Run­ti­me) die anwen­dungs­spe­zi­fi­sche Imple­men­tie­rung vor­zu­neh­men. Bei­spiels­wei­se wäre die detail­lier­te Defi­ni­tion der Men­sch-Maschi­ne-Schnitt­stel­le (HMI) durch OTX nicht prak­ti­ka­bel, da sich die Anfor­de­run­gen an eine Ein- und Aus­ga­be zwi­schen den unter­schied­li­chen Testum­ge­bun­gen stark unter­schei­den kön­nen (Moni­tor, Punkt-Matrix-Dis­play, LED).

Integration in bestehende Standards

Im nach­fol­gen­den Bild ist die Bezie­hung von OTX zu den beste­hen­den Stan­dards ISO 22900 (MVCI) und ISO 22901 (ODX) dar­ge­stellt. Die bedeu­tet jedoch nicht, dass OTX nur inner­halb die­ser Umge­bung ver­wen­det wer­den kann. OTX wur­de expli­zit für die Ver­wen­dung in belie­bi­gen Umge­bun­gen ent­wi­ckelt. Es zeigt jedoch, dass der ini­tia­le Ein­satz­be­reich von OTX die Off-Board Fahr­zeug­dia­gno­se ist, um die dort vor­han­de­ne Lücke für die pro­zess­si­che­re Beschrei­bung von Prüf­se­quen­zen zu schlie­ßen.

Ein­bin­dung von OTX in beste­hen­de Stan­dards

Vor­tei­le

• Wie­der­ver­wend­bar­keit (Single-Sour­ce)

• Erhö­hung der Sicher­heit, durch weni­ger Pro­zess­schrit­te

• Ein­fa­che und schnel­le Veri­fi­zier­bar­keit

• Ver­bes­se­rung der Wart­bar­keit

• Lang­zeit­ver­füg­bar­keit von Test­se­quen­zen und Dia­gno­se­wis­sen

• XML For­mat: Maschi­nen- und Men­schen­les­bar­keit

• Erhö­hung der Doku­men­ta­ti­ons­qua­li­tät

• Her­stel­le­ru­n­ab­hän­gig­keit

• Auto­ma­ti­sier­te Tools zur Kon­fi­gu­ra­tion, Doku­men­ten­er­stel­lung, Kode-Erzeu­gung etc.

• Gene­ri­sche Erstel­lung von Dia­gno­se­appli­ka­tio­nen

Anwendungsgebiete

Nach­fol­gend wer­den die wesent­lichs­ten Anwen­dungs­ge­bie­te zusam­men­ge­fasst in 5 Grup­pen auf­ge­lis­tet:

 1. Doku­men­ta­tion und Spe­zi­fi­ka­tion

• Erstel­lung von Test­se­quen­zen auf hoher Abstrak­ti­ons­ebe­ne

Ein Sys­te­m­ex­per­te beschreibt mit OTX die grund­le­gen­den Abläu­fe ohne dabei die genau­en Details der Imple­men­tie­rung ken­nen zu müs­sen (Spe­zi­fi­ka­tion). Ein Dia­gno­se-Exper­te ver­fei­nert die Abläu­fe indem er schritt­wei­se die Test­schrit­te imple­men­tiert (Rea­li­sie­rung).

• Erstel­lung von aus­führ­ba­ren Test­se­quen­zen

Ein Fahr­zeu­g­in­ge­nieur erstellt gra­phisch aus­führ­ba­re Test­se­quen­zen ohne kon­ven­tio­nel­le Pro­gram­mie­rung. Er ver­fügt über spe­zi­fi­sches Fahr­zeug­sys­tem-Wis­sen jedoch nicht über Pro­gram­mier­kennt­nis­se.

• Aktua­li­sie­rung und Anpas­sung von Test­se­quen­zen

Ein Prü­f­in­ge­nieur ist in der Lage vor­han­den Test­se­quen­zen auf­grund geän­der­ter Anfor­de­run­gen zu ändern ohne dabei über Pro­gram­mier­kennt­nis­se zu ver­fü­gen.

 2. Aus­tausch und Wie­der­ver­wen­dung

• Aus­tausch von Test­se­quen­zen zwi­schen Ent­wick­lung, Pro­duk­tion und Ser­vice

Zwi­schen den ver­schie­de­nen Berei­chen wer­den veri­fi­zier­te Test­se­quen­zen aus­ge­tauscht und kön­nen dort an die jewei­li­gen Bedürf­nis­se ange­passt wer­den. Dabei wird vor­han­de­nes Dia­gno­se­wis­sen wie­der­ver­wen­det und geht nicht ver­lo­ren.

 3. Erweiter­bar­keit

• Erzeu­gung von neu­en Biblio­the­ken

Der in OTX defi­nier­te Erwei­te­rungs­me­cha­nis­mus erlaubt es, das For­mat prak­tisch an belie­bi­ge Umge­bun­gen anzu­pas­sen. Der Autor schreibt dabei kei­ne pro­prie­tä­re Erwei­te­rung für sei­nen Anwen­dungs­fall, son­dern nutzt den stan­dar­di­sier­ten Erwei­te­rungs­me­cha­nis­mus. Er kann die so erzeug­te Biblio­thek mit ande­ren OTX Anwen­dern aus­tau­schen. Beste­hen­de OTX Auto­ren­sys­te­me kön­nen ohne großen Auf­wand um die neu­en Biblio­the­ken erwei­tern wer­den ohne dass alle Auto­ren­sys­te­me die­se spe­zi­fi­schen Erwei­te­run­gen unter­stüt­zen müs­sen.

 4. Loka­li­sie­rung

• Dar­stel­lung von inter­na­tio­na­li­sier­ten Tex­ten

Tex­te, die eine Über­set­zung benö­ti­gen, beein­flus­sen die Abläu­fe nicht und kön­nen in einem trans­pa­ren­ten Weg wei­ter­ge­ge­ben wer­den.

• Dar­stel­lung von Mess­wer­ten und loka­len Ein­hei­ten

OTX stellt sicher (über das Dia­gno­se­lauf­zeit­sys­tem MVCI), dass Ein­hei­ten an die loka­len Gege­ben­hei­ten ange­passt und ent­spre­chend dar­ge­stellt wer­den. Inner­halb des Ablaufs arbei­tet ein Autor jedoch mit nor­ma­li­sier­ten Wer­ten und muss somit nicht auf loka­le Umrech­nun­gen ach­ten.

• Ver­gleich von Wer­ten und Ein­hei­ten

In OTX kön­nen Mess­wer­te ver­gli­chen wer­den, ohne auf die lokal spe­zi­fi­sche Ein­heit zu ach­ten.

• Ver­gleich von Text­strings

In OTX kön­nen Text­strings ver­gli­chen wer­den, ohne auf die spe­zi­el­le Über­set­zung zu ach­ten.

 5. Aus­füh­rung zur Lauf­zeit

• Tes­tab­läu­fe wer­den durch eine OTX kom­pa­ti­ble Anwen­dung aus­ge­führt

Das OTX-For­mat ist geeig­net, direkt und ohne Zwi­schen­schrit­te aus­ge­führt zu wer­den. Dies kann eine unver­schlüs­sel­te OTX-Datei oder eine vor­kom­pi­lier­te und ver­schlüs­sel­te Binär­da­tei sein. Inner­halb der eige­nen Orga­ni­sa­tion kommt ver­mut­lich die unver­schlüs­sel­te OTX-Datei und in der Werk­statt die ver­schlüs­sel­te Binär­da­tei zum Ein­satz.

Zusam­men­fas­send kann man sagen, dass erst mit OTX (auf­bau­end auf ODX) eine voll­stän­di­ge, daten­ge­trie­be­ne Lösung für die gesam­te Dia­gno­se­pro­zess­ket­te vor­liegt. Mit der Unter­stüt­zung durch geeig­ne­te gra­phi­sche Soft­wa­re­werk­zeu­ge wird dadurch der Dia­gno­se­ent­wick­lungs­pro­zess pro­zess­si­che­rer, ein­fa­cher und pro­duk­ti­ver.

Siehe auch

Einführung in die Anwendungen für Diagnose (ASAM MCD)

ODX – Datenformat für Diagnosedaten nach ISO 22901

Diagnoselaufzeitsystem MVCI nach ISO 22900 (ASAM AE MCD 3D)

Weitere Ressourcen

OTX - Referenz