Servicexpert - Gesellschaft für Service-Informationssysteme mbH

OTX

Austausch von Inbetriebnahme- und Testabläufen zwischen Zulieferer und OEM

Hamburg, 19.09. 2013

Der Bedarf zum Austausch von „Ablaufinformationen“ im weitesten Sinne ergibt sich für Fahrzeughersteller in der Automobil- und Nutzfahrzeugindustrie bei der Integration von Komponenten verschiedener Zulieferer. Je komplexer die zugelieferte Komponente ist, vom einzelnen Steuergerät über Motor, Getriebe bis hin zum vollständigen Chassis, desto größer wird der Bedarf. Der Hersteller erwartet diese Informationen als Teil der Komponentendokumentation. Aber auch der Zulieferer wünscht sich, dass Kunden diese Ablaufinformationen befolgen, um Support- und Gewährleistungsanfragen zu minimieren.

Wenn wir im Folgenden von „Testabläufen“ sprechen, meinen wir jede Art von mehrschrittigen Operationen, die von einem menschlichen Benutzer, einem Computer, einem Diagnosegerät oder einem Prüfstand einzeln oder in Kombination durchgeführt werden müssen, um am Fahrzeug bzw. an der gelieferten Komponente ein gewünschtes Ergebnis zu erzielen, beispielsweise für die Inbetriebnahme, das Flashen und Programmieren, das Anlernen und Kalibrieren, das Prüfen bei Lieferannahme, Verbau und am Bandende, das Testen auf die korrekte Funktionsweise und das Finden von Fehlern im Problemfalle (Diagnose, geführte Fehlersuche).

Die Dokumentation und der Austausch von Ablaufinformationen erfolgt heute typischerweise in frei formulierten und formatierten Dokumenten sowie mit graphischen Ablaufdarstellungen (Programmablaufplänen) in einem geeigneten Graphikformat. Will der Komponentenintegrator diese Abläufe auch nur teilweise automatisieren, so muss er die gelieferten Informationen in die Sprache des verwendeten Automatisierungswerkzeugs (z.B. Bandendetester, Werkstattdiagnosetester) ab- und umschreiben. Dies birgt große Fehlerrisiken bei zudem unklaren Verantwortlichkeiten.

Der neue Standard ISO 13209 „OTX — Open Test sequence eXchange“ kann Abhilfe schaffen. OTX ist ein XML-basiertes Austauschformat für Testabläufe im weitesten Sinne, das zudem operationalisierbar ist. Mit diesem Format können Abläufe spezifiziert, graphisch beschrieben, dokumentiert, ausgetauscht und ausgeführt werden. Als Spezifikationssprache erlaubt OTX das graphische Erstellen von Programmablaufplänen inklusive frei formulierter Beschreibungstexte für die einzelnen Schritte. Als Programmiersprache erlaubt OTX die Ausdetaillierung dieser Spezifikation durch konkrete, ausführbare Einzelaktionen, die sich wahlweise an einen Benutzer, an eine Fahrzeugkommunikationsschnittstelle oder an andere aufrufbare Komponenten eines Testsystems richten.

OTX kann auch ohne ODX erfolgreich genutzt werden

Der Standard ISO 22901 „ODX — Open Diagnostic data eXchange“ beschreibt die Diagnosekommunikationsschnittstelle von Steuergeräten in einem ebenfalls XML-basierten, operationalisierbaren Austauschformat: Wird eine ODX-Beschreibung in einen sogenannten D-Server (Diagnoselaufzeitsystem) geladen, kann eine Test-Applikation Aufrufe an Diagnosedienste eines Steuergeräts in verallgemeinerter Form senden, die von dem D-Server auf Basis der ODX-Daten in spezifische Kommunikationstelegramme an das Steuergerät umgewandelt werden. ODX ist ein hochkomplexes Format, das wegen seiner Vorteile bereits bei vielen Fahrzeugherstellern und Zulieferern eingesetzt wird, aber wegen des damit verbundenen Erstellungs-, Pflege- und Testaufwands bei weitem noch nicht bei Allen.

Obwohl die Selbstdarstellung etwas Anderes nahelegt, ist OTX weder eine Erweiterung von ODX noch setzt es die Verwendung von ODX voraus. OTX wurde zwar unter anderem deshalb entwickelt, um Java als Sprache für komplexe Abläufe in ODX abzulösen, damit die Automobilindustrie von „außenliegenden“ Änderungszyklen wie bei Java unabhängig wird. Die Beschreibung der Diagnosekommunikation mit der Standardbibliothek von OTX setzt ebenfalls auf ODX auf.

Davon abgesehen können alle Ausdrucksmittel von OTX auch dort Erfolg bringend eingesetzt werden, wo kein ODX vorhanden ist.

OTX ist ein Multitalent: Spezifizieren und Programmieren in einem Format

Für die Spezifikation eines Ablaufs mit einem Programmablaufplan kann jeder OTX-Editor verwendet werden, da die Erstellung von OTX-Abläufen in graphischem Format vorgenommen wird. OTX bietet alle Aktionselemente einer normalen Programmiersprache (u.a. Prozeduraufrufe, Verzweigungen und Schleifen).

Wichtig für den Austausch ist jedoch, dass zunächst nur sprachlich beschrieben wird, was an der jeweiligen Stelle passieren soll. Erst im nächsten Schritt werden die Aktionselemente ausdetailliert, indem konkrete Berechnungen, Bedingungen und Aufrufe an Standardbibliotheken hinterlegt werden. Diese Standardbibliotheken bieten unter anderem Mittel zur Fahrzeugkommunikation per ODX, zur Benutzerinteraktion, zum Einbinden von externen Messgeräten, zum Umgang mit Mehrsprachigkeit („Internationalisierung“) oder schlicht zur Verwendung von physikalischen Messwerten mit Maßeinheiten. Außerdem wurde in OTX darauf geachtet, dass für den Umgang mit Ausstattungs- und Umgebungsvarianten adäquate und leicht erweiterbare Ausdrucksmittel verfügbar sind.

OTX-Einführung muss auf seine Verwendung abgestimmt sein

Bei OTX handelt es sich also um eine domänenspezifische Programmiersprache mit umfassendem Sprachumfang. Das Besondere daran ist die graphische Erfassbarkeit. Wichtig für die schrittweise Ausdetaillierung von Abläufen ist die Möglichkeit, einen Ablauf in jedem Detaillierungs- und Vollständigkeitsgrad ausführen zu lassen. Die meisten Editoren bieten für Aktionen, die nur einen beschreibenden Text enthalten, an dieser Stelle genau die Anzeige dieses Textes. Ebenfalls wichtig für den Austausch zwischen verschiedenen Beteiligten ist, dass ein Ablauf in jeder Stufe seiner Entstehung zwischen verschiedenen Editoren ausgetauscht werden kann. Das Abschreiben und Umwandeln von einer graphischen Spezifikation in eine codierte Implementation entfällt.

Diese Vielseitigkeit lässt sich nur mit entsprechend leistungsfähigen Editoren ausnutzen. Namhafte Hersteller von Diagnosesystemen buhlen zurzeit um die Gunst der Kunden, die Fähigkeiten und funktionalen Schwerpunkte der einzelnen Tools sind jedoch noch unterschiedlich ausgeprägt. Die Wahl des richtigen Werkzeugs hängt daher in hohem Maße von dem Verwendungsszenario ab, das für OTX geplant ist.

ServiceXpert, ein Unternehmen der ESG-Gruppe, beschäftigt heute über 85 Mitarbeiter an den Standorten Hamburg und München. ServiceXpert ist ein europaweit operierendes System- und Softwarehaus mit einem fokussierten Leistungsportfolio für das Lifecycle-Management von EE-Informationen für führende Nutzfahrzeughersteller und deren Zulieferindustrie.

Copyright ServiceXpert Gesellschaft für Service-Informationssysteme mbH 2016. All rights reserved.