OTX (Open Test sequence eXchan­ge) is a domain-specific language at a high level of abstraction with the aim of the graphic description of test sequences for the off-board diagnostics. The XML-based platform-independent exchange format and tester is described in ISO 13 209 and consists of 3 parts, see table. Part 1 provides a general overview of the different parts of the standard and shows use cases. The part 2 specifies the so-called core data model. It describes the basic structure of the OTX each element is based. It defines the process logic for test sequences and contains a procedural programming language similar to ensure all necessary control structures, declarations, error handling and extension mechanisms.

In Part 3, then the standard extension libraries for the different tasks are described in the vehicle diagnostics. Use the normal extension mechanism of the core data model. Only in Part 3 of the standards will take the vehicle for diagnosis. The core data model itself is independent and can for example be used in test automation or the HIL simulation.

OTX follows the principle of the imperative, structured programming. "Imperative" essentially means that the language is modular. The modules will be here the following two principles independently developed and testable:

• A module should have so little knowledge of module B as possible
• A module is changeable or reimplementierbar without changing module B

According to the principles of structured programming in OTX (return, continue, break, throw, etc.) explicit jumps (goto) but only controlled, implicit jumps allowed.

Since the typical author of diagnostic test sequences, although a specialist in diagnostic processes is not a software developer, however, was OTX in contrast to other programming languages, in which program code is usually written in text editors, specifically developed for use within graphical authoring tools. This simple and reliable production flawless and interchangeable test sequences was in the foreground. There are therefore found in OTX structures, such as the specification / realization concept, which do not occur in other programming languages.

OTX itself only describes the interfaces of the individual elements! The detailed description of the runtime behavior of the elements is not part of OTX! It is the duty of OTX compatible Ablaufsytems (OTX-Runtime) make the application-specific implementation. For example, would be the detailed definition of the human-machine interface (HMI) by OTX not practical because the requirements may differ greatly from an input and output between the different test environments (monitor, dot-matrix display, LED).

Integration into existing standards

The following picture of the relationship OTX to existing standards ISO 22900 (MVCI) and ISO 22 901 is shown (ODX). The does not mean that OTX can only be used within that environment. OTX was explicitly designed for use in any environment. However, it shows that the initial range from OTX the off-board vehicle diagnostics is to close the existing gap there for the reliable description of test sequences.

Integration of OTX in existing standards

Benefits

• Reusability (single source)

• Increase safety, by reducing process steps

• Simple and easy verifiability

• Improve the maintainability

• Long-term availability of test sequences and diagnostic knowledge

• XML format: machine and human readability

• Increase the quality of documentation

• Vendor independence

• Automated tools for configuration, document creation, code generation etc.

• Generic creating diagnostic applications

Applications

The following are the most important applications are listed together in 5 groups:

1. Documentation and specification

• Creation of test sequences on the high level of abstraction

  An expert system with OTX describes the basic processes without knowledge of the exact details of implementation need to (specification). A diagnostic expert refines the processes by gradually implementing the test steps (implementation).

• Creation of executable test sequences

  An automotive engineer created graphically executable test sequences without conventional programming. He has specific knowledge vehicle system does not have programming skills.

• Updating and adaptation of test sequences

  A test engineer is able to modify existing test sequences based on changed requirements without any programming knowledge.

2. Sharing and reuse

• Exchange of test sequences between development, production and service

  Between the different areas are verified test sequences exchanged and can be adapted to individual needs. It is available diagnostic knowledge reused and not wasted.

3. Extensibility

• Generation of new libraries

  The defined in OTX extension mechanism allows the format to adapt to virtually any environment. The author writes of no proprietary expansion for its application, but uses the standard extension mechanism. It can replace the produced libraries and other users of OTX. Existing systems can enhance OTX author easily to the new libraries will be without all authoring tools have to support these specific extensions.

4. Localization

• Presentation of internationalized text

  Texts that require translation, influence the processes and can not be communicated in a transparent way.

• Display of measured values ​​and local units

  OTX will ensure (through the diagnostic runtime system MVCI), units that are adapted to local conditions and displayed accordingly. Within the course of an author but is working with normalized values ​​and must therefore do not pay attention to local conversions.

• Comparison of values ​​and units

  In OTX, measured values ​​can be compared without regard to the specific local unit.

• Comparison of text strings

  In OTX, text strings are compared without regard to the particular translation.

5. Run-time execution

• Test sequences are executed by a compliant application OTX

  The OTX format is appropriate, directly and without intermediate steps to be executed. This may be an unencrypted OTX file or a precompiled binary and encrypted. Within the organization is probably the unencrypted OTX file and in the workshop, the encrypted binary file used.

In summary, one can say that will only be available with OTX (based on ODX) a complete, data-driven solution for the entire diagnostic process chain. With the support of appropriate software tools by graphical diagnostic development process is more reliable, easier and more productive.