OTX – ISO 13209

OTX (Open Test Sequence eXchange) was introduced with ISO 13209. This standard defines a programming language that is used specifically to describe diagnostic procedures in the automotive industry.

Some of the use cases are:

• Test and calibration procedures in production,
• Description of a flashing process for a control unit,
• Standardization of access to control units from different manufacturers,
• Replacement for Java jobs introduced in ISO 22900-3.

One of the main goals in introducing OTX was to ensure a high degree of interchangeability of test sequences between automotive manufacturers and ECU manufacturers. The syntax and grammar of the language therefore had to be defined in a technology-neutral manner. XML (Extensible Markup Language) was therefore chosen as the output format for OTX test sequences. An OEM can use an OTX runtime environment that is compatible with its existing software solution to execute OTX test sequences (e.g., a Java-based OTX interpreter with an MVCI kernel implemented in Java, or a C++ OTX code generator with a C++ MVCI kernel). If an HMI (Human-Machine Interface) element is required in a test sequence, it can be specified at an abstract level in XML and implemented by the runtime environment using the technology appropriate for the target system (e.g., HTML or a Windows dialog).

Another feature of the OTX standard is its process-oriented approach. OTX is intended for use in all phases of a process: from specification and documentation through implementation to execution. This ensures compliance with the single-source principle.

The OTX standard was designed for users with little or no programming knowledge. For this reason, the language is strongly typed and defines a set of checker rules that flag many programming errors as early as the design phase. Test sequences can be represented graphically. In addition, many OTX editors offer the option of graphical, modular programming based on a building-block approach. Direct memory accesses, the conversion of object types, and other potentially dangerous operations—which are possible in hardware-oriented programming languages such as C—are prohibited in OTX. Runtime errors are signaled by throwing exceptions. Consequently, the stability of the diagnostic system during execution depends on the quality of the OTX runtime environment used, rather than on the OTX test sequences themselves.

Despite the limitations mentioned above, OTX is a functionally complete, imperative, procedural, and modular programming language that includes all typical language elements such as branches, loops, threads (lanes), and events. In addition, it offers the ability to extract reusable code into separate libraries (OTX packages).

The OTX language elements are divided into groups:

• OTX-Core (basic language elements such as assignment, conditional execution, loops, etc.) and
• Extension (e.g., DiagCom extension for connecting to the MVCI kernel or a similar diagnostic layer).

OTX extensions relevant to diagnosis:

• DiagCom
• DiagComPlus
• Flash, FlashPlus
• DiagDataBrowsing
• DiagDataBrowsingPlus
• EcuConfiguration
• DiagConfiguration
• ComInterface
• BusMonitoring

General OTX Extensions:

• HMI
• Internalization
• ExtrenalServiceProvider
• Quantities
• Event
• EventPlus
• Measure
• Math
• String
• Time
• CommonDialogs
• Persistence
• Logging
• File
• XML
• SQL
• ZIP
• ResultHandling
• StateMachine
• Util
• BlackBox
• Assertion
• DataType

The OTX extension concept allows for the expansion of the language’s scope. The ASAM OTX working group is constantly working on new OTX extensions that are relevant not only to the automotive sector.