Deutsch (DE-CH-AT)English (United Kingdom)

OTX – Open Test sequence eXchange Datenformat

(10 Bewertungen)

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.

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.)
ISO 13209 Open Test sequence eXchan­ge For­mat

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.

Einbindung von OTX in bestehende StandardsEin­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.

  1. 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.

  1. 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.

  1. 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.

      1. 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

      Weitere Ressourcen

      • Erstellt
        12. Januar 2011
      • Version
        92
      • Geändert
        22. Juni 2011
      • Zugriffe
        69037