• Overview
  • Standardization
  • Integration into existing standards
  • External systems
  • OTX vs. Java
  • Standardized language for process-reliable description of executable test logic

    What is OTX?

    In the past, test procedures were often prosaically described or drawn as flow chart diagrams in "Visio". This specification was programmed again and again for various target systems "by hand". It is easy to see that this is neither efficient nor process-safe. The new OTX standard - Open Test Sequence Exchange - has therefore been developed in the automotive industry. OTX is an ISO 13209 standardized platform and tester independent description format for executable test sequences. The XML-based test description language is able to exchange test knowledge across departmental, tool and process boundaries. The know-how stored in the sequences is not lost and can be reused even after many years. OTX is an executable specification with verifiable quality. It is platform independent. It can connect different standards, therefore it has a harmonizing and integrating nature.

    DiagDataBrowsingPlus Extension

    Extends the DiagDataBrowsing extension to read static information stored in an ODX database.
    DiagDataBrowsing Extension

    The DiagDataBrowsing extension is based on the DiagCom extension and provides information about the diagnostic data at runtime.
    Flash Extension

    Flash extends the DiagCom extension with activities for accessing the Flash data of an ODX container. Flash sequences can be generated and thus ECUs can be reprogrammed.
    ComInterface Extension

    Enables the handling of vehicle communication interfaces at runtime for DoIP.
    BusMonitoring Extension

    Is introduced to enable asynchronous collection of communication data at runtime and analysis of monitored frames closely related to an MVCI based system.
    DiagConfiguration Extension

    Enables the selecting and changing of the ODX project at runtime.
    DiagCom Extension

    The DiagCom library allows access to a standardized diagnostic runtime system according to ISO 22900 (MVCI server) for off-board diagnostic communication with the vehicle.
    EcuConfiguration Extension

    Enables a simple way to completely configure an ECU based on the ECU-CONFIG container in ODX.
    OTX Core

    The stand-alone executable Core contains all the general test logic activities, such as procedure calls, assignments, branches, loops, parallel execution activities, and error handling. Each extension extends the core with new, specific functions.
    HMI Extension

    The HMI extension contains activities for interacting with the user via a graphical user interface (GUI). The OTF is able to bind to existing Windows Forms or WPF applications. The controls found in the applications are mapped to OTX variables of a process via the so-called screen mapping.
    Quantities Extension

    The Quantities extension extends the core with activities for computing with physical units.
    EventHandling Extension

    The EventHandling extension provides activities for working with events, such as: mouse click of the user, change a variable or expiration of a timer.
    EventPlus Extension

    Extends the Event extension to support deep change monitoring of complex types such as List, Map or ByteField.
    Measure Extension

    With the Measure extension, OTX provides activities for basic measurement and control tasks.
    i18n Extension

    To locate the tester, the I18n extension contains activities for accessing a multilingual text block library.
    ExternalServiceProvider Extension

    Provides actions, terms, events and data types for accessing arbitrary external services, e.g. web service, data base or library.
    Assertion Extension

    Provides a new Assert action which can be used to ensure the correct implementation of OTX test sequences without influence to the test logic.
    StateVariable Extension

    Provides a mechanism to transport status information from inside an OTX sequence to the environment.
    DataType Extension

    Supports the often required data types Enumeration and Structure.
    Job Extension

    The job extension expands the DiagCom extension for an access to the Job API of an MVCI server.
    Math Extension

    The Math extension contains a collection of mathematical functions not covered by the OTX Core, such as: B. Power, Log, Ln, Sin, Cos, Tan.
    FlashPlus Extension

    Extends the Flash extension to enable late-binding of flash files.
    DiagComPlus Extension

    Extents the DiagCom extension related to functional addressing and com channel handling.
    StateMachine Extension

    Extents OTX to support state machine workflows as an alternative to sequences.
    DateTime Extension

    DateTime provides elements for working with date and time.
    StringUtil Extension

    The StringUtil extension contains activities for working with strings.
    ZipHandling Extension

    Provides actions and terms to compress or decompress ZIP containers.
    ResultHandling Extension

    Provides functionality which allows capturing, evaluating and persistently writing results of test sequences in a structured way.
    Util Extension

    Includes advanced convenience functionality which are not covered by the OTX Core, e.g. StringFormat or ListSort.
    BlackBox Extension

    The BlackBox data type is a container data type to transport values of user-specific data types which are unknown in OTX.
    SQL Extension

    Provides actions and terms for a read and write access to a SQL data base.
    File Extension

    Allows general read and write access to files.
    XML Extension

    Provides functionality to read, interpret, create and manipulate XML documents from the file system or any other source.
    CommonDialogs Extension

    Provides the support for dialogs that have common use cases in OTX but were not included in the original specification (e.g. FileOpenDialog).
    Logging Extension

    Messages can be written to a log file via the logging extension.
    Persistence Extension

    Used to store runtime information stored in non-volatile storage which can be retrieved in a different process from the one that created it.

    A test sequence consists of one or more activities. All activities are thematically grouped in OTX libraries called OTX Extensions. The OTX base library (Core) contains all the activities for the general logic, such as procedure calls, assignments, branches, loops, parallel execution activities and error handling. All extensions expand the stand-alone run-able core by specific functions, see picture above (dark gray = ISO 13209-3, light gray = ISO 13209-4)

    Standardization to master the growing complexity

    We live in a connected world. The comprehensive availability of secure, broadband and cross-system communication, the ever more demanding customer requirements as well as the constantly increasing global competition results in a permanent pressure on all operational work flows and processes. The increasing complexity provides companies with the challenge of continually questioning and improving their operational processes. The degree of "relaxed" mastery of complexity makes the quality of operational processes visible.

    For this background standards play a central role. Standards establish uniform principles for a worldwide exchange of components. They are based on provable scientific arguments and pursue macroeconomic purposes. The benefit for all is beyond the benefit of individuals or institutions. Basically, a standard is a recommendation and the use is voluntary. Because of the great importance for the interaction of technical and economic solutions, however, the widest possible acceptance and usage of standards is necessary and useful.

    Due to its integrative and harmonizing effect, the OTX standard is of particular importance, since OTX is able to bring together different currently separate standards like almost no other standard.

    Integration into existing standards

    OTX seamlessly integrates with existing standards such as ISO 22900 (Diagnostic Runtime System MVCI) and ISO 22901 (ODX) and serves as a link to standards and applications in other areas, e. g. ASAM GDI, ASAM XIL or ASAM MCD3-MC. The target of OTX is the process-reliable exchange, archiving and execution of test knowledge. With the support of suitable graphical software tools, this makes the diagnostic development process easier and more productive.


    1. Simple meta-language for a complete description of executable test logic
    2. Executable specification with testable quality
    3. Machines and human readable storage of test knowledge
    4. Independent (technology, service providers, tool manufacturers), open and stable
    5. Acts harmonizing and integrating as it can easily combine different standards
    6. Platform-independent through strict separation between test logic and runtime implementation
    7. Active development and broad tool support

    Access to external systems (OTX Mapping)

    For the universal and cross-platform access to any external system, the so-called OTX Mapping was developed together with a vehicle manufacture. Independent of the actual test logic, user interfaces, environment data, status information or any device driver can be integrated via a mapping layer. By exchanging a single XML file, the same OTX sequence can be run on test bench A from manufacturer 1 or test bench B from manufacturer 2. The mapping can be created and edited graphically via the OTX Mapping Editor.

    OTX vs. Java

    If OTX was introduced as a domain-specific meta-language, the argument quickly comes: Why do you need a new programming language? Are there not enough of it? Why we do not use Java? Is not Java more mature and has better tool support?

    The arguments are understandable, but Java and OTX are not comparable. The data model of Java is much more complex than that of OTX. OTX thrives on the reduction to what is really needed for testing in the automotive industry. OTX contains extensive application-specific expert knowledge for the description of test sequences. If you tried to change Java in the direction of OTX you would only have created a second OTX standard and you will have no benefit.

    For Java you need a software developer with special knowledge, for OTX an engineer or technician with programming skills. With Java you can program an OTX editor, with OTX you describe test sequences.

    For the execution of OTX, Java (or other) code is generated, translated and executed.