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.
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.
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 Porsche AG. 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.