• Übersicht
  • Standardisierung
  • Einbindung in bestehende Standards
  • Einbindung externer Systeme
  • OTX vs. Java
  • Standardisierte Sprache zur prozesssicheren Beschreibung ausführbarer Prüflogik

    Was ist OTX?

    In der Vergangenheit wurden Testabläufe oft prosaisch beschrieben oder als Flow-Chart Diagramme in „Visio“ gezeichnet. Diese Spezifikation wurde dann für verschiedene Zielsysteme meist immer wieder neu „von Hand“ programmiert. Es ist leicht nachzuvollziehen, dass dies weder effizient noch prozesssicher ist. In der Automobilindustrie wurde daher der neue OTX Standard - Open Test sequence eXchange) - entwickelt. OTX ist ein in der ISO 13209 standardisiertes Plattform und Tester unabhängiges Beschreibungsformat für ausführbare Prüfsequenzen. Die XML basierte Testablaufsprache ist in der Lage, Prüfwissen über Abteilungs-, Tool- und Prozessgrenzen hinweg auszutauschen. Das in den Abläufen gespeicherte Know-how geht nicht verloren, sondern kann selbst nach vielen Jahren wiederverwendet werden. OTX ist eine ausführbare Spezifikation mit prüfbarer Qualität. Es ist plattformunabhängig und harmonisierend und integrierend, da es verschiedene Standards verbinden kann.

    DiagDataBrowsingPlus Extension

    Erweitert die DiagDataBrowsing-Extension um den lesenden Zugriff auf deutlich mehr Informationen innerhalb einer ODX-Datenbank.
    DiagDataBrowsing Extension

    Die DiagDataBrowsing-Bibliothek baut auf der DiagCom-Bibliothek auf und liefert zur Laufzeit Informationen über die Diagnosedaten.
    Flash Extension

    Flash erweitert die DiagCom-Bibliothek um Aktivitäten für den Zugriff auf die Flash-Daten eines ODX Containers. Es können Flashsequenzen erzeugt und somit Steuergeräte neu programmiert werden.
    ComInterface Extension

    Für das Handling eines Vehicle Communication Interface (VCI) zur Laufzeit insbesondere für DoIP.
    BusMonitoring Extension

    Ermöglicht das asynchrone Sammeln und Analysieren von Bus-Daten mit Hilfe eines MVCI-Servers.
    DiagConfiguration Extension

    Auswahl und Änderung von ODX-Projekten zur Laufzeit.
    DiagCom Extension

    Die DiagCom-Bibliothek erlaubt den Zugriff auf ein standardisiertes Diagnoselaufzeitsystem nach ISO 22900 (MVCI-Server) für die Off-Board Diagnose-Kommunikation mit dem Fahrzeug.
    EcuConfiguration Extension

    Zugriff auf den ECU-CONFIG Container von ODX zur Varianten-Kodierung.
    OTX Core

    Der stand-alone lauffähige Core enthält alle Aktivitäten für die allgemeine Prüflogik, wie beispielsweise Prozeduraufrufe, Zuweisungen, Verzweigungen, Schleifen, Aktivitäten für die parallele Ausführung und Fehlerbehandlung. Jede Extension erweitert den Core um neue, spezifische Funktionen.
    HMI Extension

    Die HMI Bibliothek enthält Aktivitäten für die Interaktion mit dem Anwender über eine grafische Benutzerschnittstelle (GUI). Das OTF ist dabei in der Lage, sich an bestehende Windows-Forms oder WPF-Anwendungen zu binden. Die in den Anwendungen gefundenen Steuerelemente werden dabei über das so genannte Screen-Mapping an OTX-Variablen eines Ablaufs gemappt.
    Quantities Extension

    Die Quantities-Bibliothek erweitert den Core um Aktivitäten zum Rechnen mit physikalischen Einheiten.
    EventHandling Extension

    Die EventHandling-Bibliothek bietet Aktivitäten für das Arbeiten mit Ereignissen, z. B. Mausklick des Benutzers, Änderung einer Variablen oder Ablauf eines Timers.
    EventPlus Extension

    Erweitert die EventHandling-Extension um sogenanntes Deep-Change-Monitoring der komplexen Datentypen List, Map und ByteField.
    Measure Extension

    Mit der Measure-Bibliothek stellt OTX Aktivitäten für grundlegende Mess- und Steueraufgaben bereit.
    i18n Extension

    Zur sprachlichen Anpassung des Ablaufsystems enthält die I18n-Bibliothek Aktivitäten für den Zugriff auf eine mehrsprachige Textbaustein-Bibliothek.
    ExternalServiceProvider Extension

    Ermöglicht es, innerhalb von OTX auf beliebige externe Systeme (z.B. WebService, DLL, Assembly) zuzugreifen.
    Assertion Extension

    Erweitert OTX um eine neue ASSERT Aktivität. Darauf aufbauend können mit OTX Unit-Tests zur Sicherstellung einer korrekten Implementierung ohne Veränderung der Prüflogik entwickelt werden.
    StateVariable Extension

    Transportiert Status-Informationen aus einem OTX-Ablauf in die Umgebung. Status-Variablen sind das Gegenteil von Context-Variablen.
    DataType Extension

    Erweitert OTX um Datentypen für Strukturen (Structure) und Aufzählungen (Enumeration).
    Job Extension

    Die Job-Bibliothek erweitert die DiagCom um den Zugriff auf die Job-API eines MVCI-Servers.
    Math Extension

    Die Math-Bibliothek enthält eine Sammlung mathematischer Funktionen, die nicht durch den OTX Core abgedeckt werden, z. B. Power, Log, Ln, Sin, Cos, Tan.
    FlashPlus Extension

    Erweitert die Flash-Extension um das so genannte Late-Binding von Flash-Dateien.
    DiagComPlus Extension

    Erweitert die DiagCom-Extensions bzgl. funktionaler Adressierung und Kommunikationskanal-Handling.
    StateMachine Extension

    Erweitert OTX um einen neuen Prozedurtyp für Ereignis getriebene Status-Maschinen als Alternative zu den sequentiellen Sequenzen.
    DateTime Extension

    DateTime stellt Elemente für die Arbeit mit Datum und Uhrzeit zur Verfügung.
    StringUtil Extension

    Die StringUtil-Bibliothek enthält Aktivitäten für das Arbeiten mit Strings.
    ZipHandling Extension

    Erweitert OTX um den Lese- und Schreibzugriff auf ZIP-Archive.
    ResultHandling Extension

    Zum Ermitteln, Prüfen und Speichern der Ergebnisse von Prüfroutinen.
    Util Extension

    Enthält Komfortfunktionen, die im Core nicht enthalten sind, z.B. ListSort oder StringFormat.
    BlackBox Extension

    Der BlackBox Datentype ist ein Container-Datentyp. Er dient dem Transport von externen Werten, deren Aufbau in OTX unbekannt ist.
    SQL Extension

    Lese und Schreibzugriff auf eine SQL-Datenbank.
    File Extension

    Erweitert OTX um einen allgemeinen Lese- und Schreibzugriff auf beliebige Dateien.
    XML Extension

    Erweitert OTX um den Lese- und Schreibzugriff auf XML-Dateien.
    CommonDialogs Extension

    Stellt allgemeine Dialoge (z.B. FileOpenDialog) zur Verfügung.
    Logging Extension

    Über die Logging-Bibliothek können Nachrichten in eine Log-Datei geschrieben werden.
    Persistence Extension

    Zum einfachen persistenten Speichern und Abrufen von Laufzeitdaten in einem nicht flüchtigen Speicher.

    Ein Prüfablauf besteht aus einer oder mehreren Aktivitäten. Alle Aktivitäten sind in OTX Bibliotheken so genannte OTX-Extensions thematisch gruppiert. Die OTX-Basisbibliothek (Core) enthält alle Aktivitäten für die allgemeine Prüflogik, wie beispielsweise Prozedur-Aufrufe, Zuweisungen, Verzweigungen, Schleifen, Aktivitäten für parallele Ausführung und Fehlerbehandlung. Alle Extensions erweitern den auch stand-alone lauffähigen Core um spezifische Funktionen, siehe Bild oben (Dunkelgrau = ISO 13209-3, Hellgrau = ISO 13209-4)

    Standardisierung zur Beherrschung der wachsenden Komplexität

    Wir leben in einer vernetzten Welt. Die flächendeckende Verfügbarkeit sicherer, breitbandiger und systemübergreifender Kommunikation, die immer anspruchsvollere Kundenanforderungen sowie der stetig steigende globale Wettbewerb führen zu einem permanenten Druck auf alle betrieblichen Abläufe und Prozesse. Die dadurch zunehmende Komplexität stellt Unternehmen vor die Herausforderung, ihre operativen Abläufe kontinuierlich zu hinterfragen und zu verbessern. Am Grad der "entspannten" Beherrschung der Komplexität wird die Qualität der betrieblichen Prozesse sichtbar.

    Hierbei spielen Standards eine zentrale Rolle. Standards schaffen weltweit einheitliche Grundlagen für den Austausch von Komponenten. Sie basieren auf beweisbaren naturwissenschaftlichen Argumenten und verfolgen gesamtwirtschaftliche Zwecke. Der Nutzen für alle steht über dem Vorteil einzelner Personen oder Institutionen. Grundsätzlich ist ein Standard eine Empfehlung und der Einsatz ist freiwillig. Wegen der großen Bedeutung für das Zusammenspiel von technischen und wirtschaftlichen Lösungen ist jedoch eine möglichst breite Akzeptanz und Anwendung von Standards notwendig und sinnvoll.

    Aufgrund seiner integrativen und harmonisierenden Wirkung kommt dem Standard OTX eine besondere Bedeutung zu, denn OTX ist wie kaum ein anderer Standard in der Lage, verschiedene bisher getrennt Standards zusammenzuführen.

    Einbindung in bestehende Standards

    OTX integriert sich nahtlos in bestehende Standards wie ISO 22900 (Diagnoselaufzeitsystem MVCI) und ISO 22901 (ODX) und dient als Bindeglied zu Standards und Anwendungen in anderen Bereichen, z.B. ASAM GDI, ASAM XIL oder ASAM MCD3-MC. Das Ziel von OTX ist der prozesssichere Austausch, die Archivierung und Ausführung von Prüfwissen. Mit der Unterstützung durch geeignete graphische Softwarewerkzeuge wird dadurch der Diagnoseentwicklungsprozess einfacher und produktiver.

    Vorteile

    1. Einfache Meta-Sprache zur kompletten Beschreibung ausführbarer Prüflogik
    2. Ausführbare Spezifikation mit prüfbarer Qualität
    3. Maschinen und Menschen lesbare Ablage des Prüfwissens
    4. Unabhängig (Technologie, Dienstleister, Toolhersteller), offen und stabil
    5. Wirkt harmonisierend und integrierend, da es einfach verschiedene Standards verbinden kann
    6. Plattformunabhängig durch strikte Trennung zwischen Prüflogik und Laufzeitimplementierung
    7. Aktive Weiterentwicklung und breite Toolunterstützung

    Anbindung externer Systeme (OTX-Mapping)

    Für die universelle und plattformübergreifende Anbindung beliebiger externer System wurde gemeinsam mit der Porsche AG das so genannte OTX-Mapping entwickelt. Unabhängig von der eigentlichen Prüflogik, können über eine Mapping-Schicht Benutzeroberflächen, Umgebungsdaten, Status-Informationen oder beliebige Gerätetreiber eingebunden werden. Durch den Austausch einer einzigen XML-Datei kann dieselbe OTX Sequenz auf Prüfstand A von Hersteller 1 oder auf Prüfstand B von Hersteller 2 ausgeführt werden. Über den OTX-Mapping Editor können die Verbindungen graphischen erstellt und bearbeitet werden.

    OTX vs. Java

    Wenn man OTX als Domänen spezifische Meta-Sprache vorstellt, kommt schnell das Argument: Wozu benötigt man eine neue Programmiersprache? Gibt es nicht schon genug davon? Warum verwendet man nicht Java? Ist Java nicht ausgereifter und hat eine bessere Tool-Unterstützung?

    Die Argumente sind zwar nachvollziehbar, jedoch sind Java und OTX nicht vergleichbar. Das Datenmodel von Java ist erheblich komplexer als das von OTX. OTX lebt von der Reduktion auf das, was für das Testen im Umfeld der Automobilindustrie wirklich benötigt wird. OTX enthält umfangreiches anwendungsbezogenes Expertenwissen für die Beschreibung von Prüfabläufen. Würde man versuchen, Java in Richtung OTX zu verändern hätte man nur einen zweiten OTX Standard geschaffen und keinen Gewinn.

    Für Java benötigt man einen Softwareentwickler mit Spezialkenntnissen, für OTX einen Ingenieur (Techniker mit Programmierkenntnissen). Mit Java kann man einen OTX-Editor programmieren, mit OTX beschreibt man Prüfabläufe.

    Für die Ausführung wird aus OTX Java (oder anderer) Code generiert, übersetzt und ausgeführt.