General.Introduction

Overview

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:

Requirement	Name	Description	Priority
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.

Legal authorities

• 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.