- 1 Overview
- 2 Requirements on OTX
- 3 OTX benefit examples
- 3.1 ECU system suppliers
- 3.2 Vehicle manufacturer engineering departments
- 3.3 Vehicle manufacturer production departments
- 3.4 Vehicle manufacturer service departments and repair shops
- 3.5 Test equipment manufacturers
- 3.6 Authorized and independent repairers
- 3.7 Legal authorities
- 3.8 From the technical view
OTX (abbreviation for Open Test sequence eXchange, ISO 13209) is an international standard for the formal description of diagnostic and test sequences in the automotive industry. OTX is created to support in vehicle development, production and service. Moreover, it is also created to support in technical security controls (for instance, the general inspection in Germany). The goal of the standard is to alter existing proprietary solutions in these fields.
OTX is a Domain Specific Language (DSL) for automobile diagnostics. It determines a standardized, tester-independent, XML-based data exchange format for the formal description and documentation of executable test sequences. OTX supports the idea of the "Executable Specification". Through this, the test sequences can be described at a specification level and at the same time, OTX includes enough implementation details to execute these sequences. An additional special feature of OTX is the direct support for variant management that should simplify the adaptation of processes to e.g. different variations of a vehicle model considerably. The format takes a role in supporting the requirements of transferring test sequence logic between electronic system suppliers, automobile manufacturers and service dealerships/repair shops. Diagnostic test sequences are used in the process of diagnosing, testing, reprogramming, initializing all the automotive components or functions with diagnostic capabilities by off-board test device. Test sequences define the progression of interactions between the user (i.e. workshop or assembly line staff), the diagnostic application (the test device) and the vehicle communication interface as well as any calculations and decisions that have to be implemented. Test sequences supply a means to define interactive, guided diagnostics or similar test logic.
Nowadays, the automotive industry chiefly depends on paper documentation and/or proprietary authoring environments. During setting up engineering, assembly line or service diagnostic test applications, an author has to implement the required test sequences manually, supported by non-uniform test sequence documentation, most likely using different authoring applications and formats for each specific test application. This redundant effort can be reduced a lot if processes and tools support the OTX concept.
Through ISO 13209, there is an open and standardized format for the human- and machine-readable description of diagnostic test sequences. The format supports the demands of transferring diagnostic test sequence logic uniformly between electronic system suppliers, automobile manufacturers and service dealerships/repair shops. The OTX standard consists of three parts:
Part 1: General information and use cases
This part of ISO 13209-1:2011(E) supplies a general overview of the individual parts of the OTX standard. Besides, it documents use cases to be considered during the standardization. These use cases are adopted from real world scenarios as in the automotive industry. This document is also supposed to supply the rationale for proposing the OTX standard, to explain the considerations that went into the development of that standard and to give an overview of the structure of the concepts and documents related to the standard.
Part 2: Core data model specification and requirements
Part 2 of ISO 13209 serves as the requirements and technical specification for the basic of the OTX format, which is called the "OTX Core". The stand-alone executable Core defines the primary structure underlying every OTX document. This consists detailed data model definitions of all required control structures which describes test sequence logic, but also definitions of the outer, enveloping document structure in which test sequence logic is embedded. For the reason of extensibility, the Core also has well-defined extension points, which grant an independent definition of extra OTX features – without changing the core data model.
Part 3: Standard extensions and requirements
Part 3 of ISO 13209 supplies specifications for universal functionalities that may to different extents be used by every OTX-based environment. The core data model extensions defined in part three makes use of the extension mechanisms supplied by the OTX language to provide interface definitions for feature sets such as HMI (Human-Machine-Interface), internationalization or diagnostic vehicle communication.
OTX was created for the special demands of automobile diagnostics, but in principle, it can also be applied in other areas for any sequential logic description, even outside the automotive domain. For that reason, automotive-specific features are contained only in Part 3 of ISO 13209.
Requirements on OTX
As a guideline to define the OTX requirements, the following basic principles have been established:
- OTX requirements specify the conditions that the OTX data model and format shall satisfy,
- All stakeholders (System Suppliers, OEMs, Tool Suppliers), which offer diagnostic test procedures are expected to implement and follow the requirements of this standard,
- The content of OTX documents and the quality of the information is the responsibility of the originator.
The table below provides an overview of the main requirements on OTX:
|Core_R02||Machine readable format||The OTX format has to be machine-readable to allow a tool to open an existing document for editing, checking, displaying or executing.||SHALL|
|Core_R02||Platform independence||OTX shall not be dependent on any specific hardware or software platform. OTX shall not be bound to any particular hardware, operating system or application.||SHALL|
|Core_R03||Well-defined syntax and semantics||All OTX elements have to be defined clearly (syntax + semantics). For the syntax definition, XML Schema shall be used. For the behavioural/semantics specification, a prose description shall exist.||SHALL|
|Core_R04||Universal language||OTX shall have the ability to solve any computable problem. (Turing-Completeness)||SHALL|
|Core_R05||Minimal language||OTX should be defined with the minimal set of language elements necessary to reach Turing-Completeness.||SHOULD|
|Core_R06||Structured programming approach||OTX shall follow the structured programming approach. Only flow control statements branch, loop return, continue, break and throw may implicitly induce jumps. The behaviour of these jumps shall be well defined in the prose semantic documentation of each of these statements. An explicit GOTO statement which allows to jump anywhere in the procedure shall not be supported.||SHALL|
|Core_R07||Imperative structure||OTX shall only support program structures that can be translated by a compiler into imperative programming languages.||SHALL|
|Core_R08||Extensibility||OTX shall be extendable to integrate means to access new technology employed within the di-agnostic process. It shall be possible to integrate interfaces of various base technologies into OTX.||SHALL|
|Core_R09||Embed non-machine readable content||OTX shall provide means to express parts of a diagnostic application in a non-machine readable format. This non-machine readable content shall be clearly marked so that processes operating on OTX files can identify it.||SHALL|
|Core_R10||High level test procedure||It shall be possible to describe test procedures at a high level.||SHALL|
|Core_R11||Exchange high level test procedure||It shall be possible to exchange a high-level test plan using a plain text description.||SHALL|
|Core_R12||Exchange a fully functional test procedure||It shall be possible to mix high-level description and implementation details on the same procedure.||SHALL|
|Core_R13||Exchange an intermediate stage test procedure||It shall be possible to mix high-level description and implementation details on the same procedure.||SHALL|
|Core_R14||Floating comments||It shall be possible add floating comments to a test procedure that can refer to one or more statements its flow or its sub-flows at any block depth.||SHALL|
OTX benefit examples
ECU system suppliers
- Documentation can be generated from OTX/XML test sequence exchange format,
- Development testers can be automatically configured to verify ECU diagnostic behaviour,
- OTX/XML data format provides machine readable information to import into supplier test sequence database,
- Test sequences for test equipment specific application framework can be automatically generated.
Vehicle manufacturer engineering departments
- Reduction of test sequence authoring effort,
- Various development testers can be supported with "single source“ test sequences,
- One single file format for import and export to/from OTX database.
Vehicle manufacturer production departments
- Reduced effort for test sequence verification, because verification needs to be performed only once,
- Reuse of verified test sequences,
- Fewer errors because of fewer manual process steps,
- Manufacturing tester can use the same basic test sequences as engineering diagnostic tester.
Vehicle manufacturer service departments and repair shops
- More convenient reuse of verified test sequences,
- Less cost to distribute test sequences,
- "Pull“ (via Intranet/Internet) test sequences for example from a portal into a diagnostics application versus "Push“ (e.g. send CD ROMs),
- One single format for various diagnostic service systems.
Test equipment manufacturers
- Less effort needed to implement high quality scan tool software by using a standardized test sequence approach,
- Focus on "rich diagnostic application(s)“ versus bits & bytes,
- More convenient reuse of test sequences verified by vehicle manufacturers.
Authorized and independent repairers
- More convenient reuse of test sequences verified by vehicle manufacturers,
- Tester configuration by data download instead of software modification,
- Download on demand versus buying tester software update upfront.
- Standardized description format for enhanced test sequences documentation,
- Enables road-side scan tools and I&M (inspection and maintenance) tools to be vehicle manufacturer independent,
- Fulfils the requirement of making enhanced test sequences available to independent aftermarket.
From the technical view
- Core concepts for the variant & process management to reduce and manage the complexity
- Powerful variable binding mechanism,
- Its proven – all German and some other vehicle manufacturers has committed to this international standard,
- Tool chains from different suppliers are available and will be further developed.