Was ist OTX?

Jörg Supke
24. Okt.
6 Min. Lesezeit

Aktualisiert: 29. Okt.

OTX ist eine domänenspezifische Programmiersprache (DSL) zur prozesssicheren Beschreibung austauschbarer und ausführbarer Prüflogik in der Automobilindustrie. Der Standard hat sich als plattformunabhängige Grundlage für die Beschreibung von Diagnose- und Testabläufen etabliert und wird branchenweit eingesetzt. Der Beitrag gibt einen Überblick über den OTX-Standard, erläutert Anwendungsbereiche und Zielgruppen, zeigt die Vorteile und typischen Einsatzszenarien auf, die OTX zu einem zentralen Baustein moderner Fahrzeugdiagnose machen.

Einleitung

In einer zunehmend digitalisierten Fahrzeugwelt werden die Anforderungen an Diagnoseprozesse immer komplexer. Genau hier kommt OTX ins Spiel – ein leistungsstarker ISO-Standard, der entwickelt wurde, um komplexe Abläufe in der Fahrzeugdiagnose strukturiert, wiederverwendbar und zielsystemunabhängig zu beschreiben.

OTX ist mehr als nur ein XML-Format für Ablaufbeschreibungen. Es ist ein zukunftssicheres Werkzeug, das es Entwicklern, Diagnosesystemen und OEMs ermöglicht, Diagnoselogik transparent zu modellieren, plattformunabhängig auszutauschen und zuverlässig auszuführen – und das über den gesamten Fahrzeuglebenszyklus hinweg.

Ob man als Entwickler Diagnoseabläufe erstellt, als OEM einheitliche Standards implementiert oder als Tool-Hersteller innovative Lösungen baut: Mit OTX gestaltet man die Mobilität von morgen mit – klar strukturiert, prozesssicher und effizient.

Was ist OTX?

OTX nach ISO 13209 steht für „Open Test sequence eXchange“ und ist eine domänenspezifische Sprache (DSL) zur prozesssicheren Beschreibung austauschbarer und ausführbarer Prüflogik, siehe Abbildung 1. Diagnoseabläufe können graphisch erstellt und gleichzeitig so detailliert beschrieben werden, dass dieselbe Prüflogik barrierefrei in beliebigen unterschiedlichen Zielumgebungen ausgeführt werden kann. Der Standard hat die nötige Reife und ist umfangreich genug, um bestehende Lösungen in Entwicklung, Produktion und Werkstatt zu ersetzen.

Die Einsatzmöglichkeiten von OTX reichen von der Beschreibung einfacher Funktionstests in der Entwicklung über Inbetriebnahme-Abläufe in der Produktion bis hin zu vollständig generischen Tester-Anwendungen mit geführter Fehlersuche im Kundendienst, siehe Abbildung 2. OTX ist offen, stabil, plattform- und technologieneutral und nicht zuletzt gibt es eine aktive Weiterentwicklung beim ASAM. Zusammenfassend kann man sagen, dass OTX sicherstellen kann, dass dieselbe unveränderte Prüflogik zu jeder Zeit in beliebigen Zielsystemen ausführbar ist und immer zu denselben Ergebnissen kommt.

Abbildung 2: Softwaretechnischer Aufbau einer Diagnoseanwendung mit OTX

OTX besteht aus einem stand-alone ausführbaren Kern, dem OTX-Core, siehe Abbildung 3. Innerhalb des Kerns (Core) werden das Datenmodell der Programmiersprache sowie alle Erweiterungspunkte definiert. Jede OTX-Extension erweitert den Kern um neue domänenspezifische Funktionen. Zuerst für den Bereich Fahrzeugdiagnose, weiterhin für die Kommunikation mit externen Systemen und für viele andere Funktionen, die für eine vollständige Programmiersprache erforderlich sind.

OTX kann außerdem standardkonform um neue so genannte OTX-Extensions erweitert werden. Potenzielle neue Extensions sind beispielsweise ASAM Test Specification, JSON oder die neue SOVD-Extension zur Service-orientierten Fahrzeugdiagnose. Die neue Range-Extension ermöglicht es, OTX-Deklarationen Gültigkeitsbereiche zuzuordnen und die ASAM XIL-Extension erweitert OTX für den Zugriff auf den Prüfstand.

Anwendung von OTX im Prozess

Bei der praktischen Einführung von OTX hat sich gezeigt, dass der Standard vor allem ein Prozess- und Integrationsthema ist. OTX ermöglicht durchgängig standardisierte Prozesse von der Spezifikation bis zur Ausführung von Prüflogik auf beliebigen Zielsystemen, siehe Abbildung 4.

Der typische OTX-Prozess beginnt mit der Spezifikation der Prüflogik auf Ebene eines Diagnoseexperten. Ziel dabei ist es, für die Spezifikation kein anderes Format als OTX „single-source“ zu verwenden. Verantwortlich hierfür ist der Bauteile-Verantwortliche, der keine Programmierkenntnisse besitzen muss. Dies erreicht man, indem man eine durch geschickte Regeln, „auf die Kenntnisse eines Diagnoseexperten“ eingeschränkte Sicht auf OTX graphisch darstellt. Das Ergebnis ist ein OTX-Projekt, welches in einer standardisierten PTX-Datei, die signiert oder verschlüsselt sein kann, gespeichert wird.

Im zweiten Schritt wird die Spezifikation durch einen OTX-Programmierer implementiert. Dabei wird die Spezifikation selbst nicht verändert. So entsteht eine angereicherte PTX-Datei. Sie enthält neben der Spezifikation auch die komplette Prüflogik in einer beliebigen Projektstruktur.

Der OTX-Programmcode muss im dritten Schritt gegen das erwartete Verhalten abgesichert werden. Dies macht man über die UnitTest Extension von OTX.

Im vierten Schritt wird die Prüflogik für die Ausführung in verschiedenen Zielsystemen für Entwicklung oder Produktion konfiguriert. Dies wir auch als OTX-Mapping bezeichnet. Das OTX-Mapping ordnet eine Schnittstelle in OTX einer realen Implementierung beispielsweise einem HTML-Screen zu. Alle Mapping-Informationen für eine Zielumgebung werden innerhalb der OTX-Mapping Datei gespeichert.

Im letzten Schritt wird die Prüflogik auf dem Zielsystem ausgeführt. Durch die Verwendung einer anderen Mapping-Datei kann derselbe OTX-Ablauf auf beliebigen Zielsystemen unter Linux, Android oder in eingebetteten Systeme ausgeführt werden.

Einfache OTX-Beispiele

Der nachfolgende OTL-Code (OTX in ASCII-Notation) zeigt ein vereinfachtes Beispiel für das Auslesen und Darstellen der Teilenummer eines Steuergeräts. Zuerst werden lokale Variablen deklariert. Danach wird die Verbindung mit dem Steuergerät hergestellt. Der erzeugte Diagnosedienst wird über ExecuteDiagService an das Steuergerät versendet. Der Response-Parameter des versendeten Diagnosedienstes ist an die lokale String-Variable sparePartNo gebunden. Nach dem erfolgreichen Empfangen der Antwort vom Steuergerät enthält diese Variable den Wert der Teilenummer. Sie wird über einen einfachen Dialog auf dem Bildschirm ausgegeben. Der ganze Ablauf ist in eine Fehlerbehandlung (try-catch) eingebunden.

public procedure main()
{
   // Local variables
   String sparePartNo;
   DiagCom.ComChannel comC;
   DiagCom.DiagService diagS;
   Exception e;

   try
   {
      // Establish a connection to the ECU with
      // an implicit variant identification and selection.
      comC = DiagCom.GetComChannel("LL_MyEcu", true);

      // Creates a diagnostic service at the 
      // communication channel to read out the spare part number.
      diagS = DiagCom.CreateDiagServiceByName(comC, "ReadSPartNo");

      // Executes a diagnostic service to read out the
      // spare part number from the ECU and assign
      // the response parameter to a local variable.
      DiagCom.ExecuteDiagService(diagS,
         { PR_ReadSPartNo.PA_SPartNo = sparePartNo });

      // Display the spare part number in a dialog
      HMI.ConfirmDialog(sparePartNo);
   }
   catch (Exception e)
   {
      // Do something ...
   }
}

Der nachfolgende OTL-Code (OTX in ASCII-Notation) zeigt ein vereinfachtes Beispiel für das Auslesen der Fehler eines Fahrzeugs über SOVD. Es werden alle gefundenen Fehler der Komponenten der ersten Ebene ermittelt und als Liste zurückgegeben.

// Returns all faults found
public procedure GetFaults(out List<SOVD.FaultDescriptor> faultLst)
{
   // Local variables
   List<SOVD.EntityDescriptor> servers;
   SOVD.EntityDescriptor server;
   Map<String, SOVD.EntityDescriptor> components;
   SOVD.EntityDescriptor component;
   Map<String, SOVD.FaultDescriptor> faults;
   SOVD.FaultDescriptor fault;

   // Gets the discovered SOVD servers
   servers = SOVD.GetDiscoveredSovdServer();

   // Browse through all discovered servers
   foreach(server in servers)
   {
      // Gets all components of a certain server
      components = SOVD.GetComponentDescriptors(server);
      // Browse through all components
      foreach(component in components)
      {
         // Gets all faults of a certain component
         faults = SOVD.GetFaultsAsDescriptors(component);
         // Browse through all faults   
         foreach(fault in faults)
         {
            // Add the faults to the list which will be returned
            ListAppendItems(faultLst, { fault });
         }
      }
   }
}

Vorteile von OTX

Standardisierung
OTX ist ein internationaler, in der ISO 13209 genormter Standard. Hersteller, Zulieferer und Tool-Anbieter können transparent und interoperabel arbeiten.
Visuelle Modellierung von Abläufen
Diagnoseprozesse werden grafisch als Flussdiagramme modelliert. Komplexe Abläufe sind leicht verständlich, wartbar und dokumentiert.
Wiederverwendbarkeit und Modularität
Prozeduren und Unterprozeduren können wiederverwendet und kombiniert werden. Das reduziert Entwicklungsaufwand und Fehlerquellen.
Testbarkeit und Debugging
OTX-Sequenzen sind schrittweise ausführbar. Diagnosetools bieten Breakpoints, Variablenüberwachung und Logging.
Integration in Diagnosetools
OTX ist in vielen OEM-nahen Tools eingebettet. Es lässt sich nahtlos in Werkstatt-, Produktions- und Entwicklungssysteme einbinden.
Flexibilität bei Protokollen und Kommunikationsschnittstellen
OTX kann mit verschiedenen Backend-Technologien genutzt werden: UDS, DoIP, SOVD etc. Die Diagnose-Logik bleibt gleich, nur die technische Ausführung ändert sich.
Nachvollziehbarkeit und Dokumentation
OTX-Sequenzen sind sowohl für Menschen als auch Maschinen lesbar. OTX-Sequenzen können neben der Logik auch die Spezifikation der Logik enthalten – Ideal für Audits, Qualitätssicherung und Serienfreigaben.
Schnittstelle zwischen Entwicklung, Produktion und After-Sales
OTX ermöglicht einen konsistenten Diagnosestand über den gesamten Fahrzeug-Lebenszyklus.

Wer braucht OTX?

OTX ist in erster Linie ein Prozess-Thema. Die Stärken von OTX liegen im Austausch von Prüfwissen in komplexen Umgebungen über Prozessgrenzen hinweg. Dort ist OTX wie kaum ein anderer Standard in der Lage sicherzustellen, dass dieselbe Prüflogik zu jeder Zeit in beliebigen Zielsystemen ausführbar ist und zu denselben Ergebnissen kommt. Geht es jedoch um einzelne Prüfstände, dann gibt es viele Alternativen wie beispielsweise Python. Hat man jedoch die Komplexität eines Automobilherstellers, dann führt meines Erachtens kein Weg an OTX vorbei.

Fazit

OTX ist eine domänenspezifische Programmiersprache (DSL) zur prozesssicheren Beschreibung austauschbarer und ausführbarer Prüflogik innerhalb der Automobilindustrie. OTX hat sich als plattformunabhängige Beschreibung von Diagnoseprüflogik im Umfeld der Automobilindustrie etabliert.