What is OTX?
- Jörg Supke
- Oct 24
- 6 min read
Updated: Oct 29
OTX is a domain-specific programming language (DSL) for the reliable description of interchangeable and executable test logic in the automotive industry. The standard has established itself as a platform-independent foundation for describing diagnostic and test procedures and is used industry-wide. This article provides an overview of the OTX standard, explains application areas and target groups, and highlights the advantages and typical use cases that make OTX a central component of modern vehicle diagnostics.
Contents
Introduction
In an increasingly digitalized automotive world, the requirements for diagnostic processes are becoming increasingly complex. This is where OTX comes in – a powerful ISO standard developed to describe complex vehicle diagnostic processes in a structured, reusable, and target-system-independent manner.
OTX is more than just an XML format for process descriptions. It's a future-proof tool that enables developers, diagnostic systems, and OEMs to transparently model diagnostic logic, exchange it across platforms, and execute it reliably—across the entire vehicle lifecycle.
Whether you are a developer creating diagnostic processes, an OEM implementing uniform standards, or a tool manufacturer building innovative solutions: With OTX, you are helping to shape the mobility of tomorrow – clearly structured, process-reliable, and efficient.
What is OTX?
OTX according to ISO 13209 stands for "Open Test Sequence eXchange" and is a domain-specific language (DSL) for the process-safe description of interchangeable and executable test logic, see Figure 1. Diagnostic sequences can be created graphically and simultaneously described in such detail that the same test logic can be executed barrier-free in any number of different target environments. The standard has the necessary maturity and is comprehensive enough to replace existing solutions in development, production, and the workshop.
OTX's possible applications range from describing simple functional tests in development and commissioning processes in production to fully generic tester applications with guided troubleshooting in customer service, see Figure 2. OTX is open, stable, platform- and technology-neutral, and, last but not least, is actively developed further by ASAM. In summary, OTX can ensure that the same, unchanged test logic can be executed at any time on any target system and always produces the same results.
OTX consists of a stand-alone executable core, the OTX core (see Figure 3 ). The core defines the programming language's data model and all extension points. Each OTX extension extends the core with new domain-specific functions. Initially, these are for vehicle diagnostics, then for communication with external systems and many other functions required for a complete programming language.
OTX can also be extended with new, standards-compliant OTX extensions. Potential new extensions include the ASAM Test Specification , JSON, and the new SOVD extension for service-oriented vehicle diagnostics. The new Range extension enables OTX declarations to be assigned to validity ranges, and the ASAM XIL extension extends OTX for access to the test bench.
Application of OTX in the process
The practical implementation of OTX has shown that the standard is primarily a process and integration issue. OTX enables consistently standardized processes from specification to the execution of test logic on any target system, see Figure 4 .
The typical OTX process begins with the specification of the test logic at the diagnostics expert level. The goal is to use only a single-source OTX format for the specification. This is the responsibility of the component owner, who does not require any programming knowledge. This is achieved by graphically representing a view of OTX that is limited to the knowledge of a diagnostics expert using clever rules. The result is an OTX project, which is saved in a standardized PTX file, which can be signed or encrypted.
In the second step , the specification is implemented by an OTX programmer. The specification itself remains unchanged. This creates an enriched PTX file. It contains not only the specification but also the complete test logic in any project structure.
In the third step, the OTX program code must be validated against the expected behavior. This is done using the OTX UnitTest extension.
In the fourth step, the test logic is configured for execution in various target systems for development or production. This is also known as OTX mapping. OTX mapping maps an interface in OTX to a real implementation, for example, an HTML screen. All mapping information for a target environment is stored within the OTX mapping file.
In the final step, the test logic is executed on the target system. By using a different mapping file, the same OTX flow can be executed on any target system running Linux, Android, or embedded systems.
Simple OTX examples
The following OTL code (OTX in ASCII notation) shows a simplified example for reading and displaying the part number of an ECU. First, local variables are declared. Then, the connection to the ECU is established. The generated diagnostic service is sent to the ECU via ExecuteDiagService . The response parameter of the sent diagnostic service is bound to the local string variable sparePartNo . After successfully receiving the response from the ECU, this variable contains the value of the part number. It is displayed on the screen via a simple dialog. The entire process is integrated into error handling ( try-catch ).
public procedure main()
{
// Local variables
String sparePartNo;
DiagCom.ComChannel comC;
DiagCom.DiagService diagS;
Exception e;
try
{
// Establish a connection to the ECU with
// an implicit variant identification and selection.
comC = DiagCom.GetComChannel("LL_MyEcu", true);
// Creates a diagnostic service at the
// communication channel to read out the spare part number.
diagS = DiagCom.CreateDiagServiceByName(comC, "ReadSPartNo");
// Executes a diagnostic service to read out the
// spare part number from the ECU and assign
// the response parameter to a local variable.
DiagCom.ExecuteDiagService(diagS,
{ PR_ReadSPartNo.PA_SPartNo = sparePartNo });
// Display the spare part number in a dialog
HMI.ConfirmDialog(sparePartNo);
}
catch (Exception e)
{
// Do something ...
}
}The following OTL code (OTX in ASCII notation) shows a simplified example of reading a vehicle's errors via SOVD. All detected errors of the first-level components are identified and returned as a list.
// Returns all faults found
public procedure GetFaults(out List<SOVD.FaultDescriptor> faultLst)
{
// Local variables
List<SOVD.EntityDescriptor> servers;
SOVD.EntityDescriptor server;
Map<String, SOVD.EntityDescriptor> components;
SOVD.EntityDescriptor component;
Map<String, SOVD.FaultDescriptor> faults;
SOVD.FaultDescriptor fault;
// Gets the discovered SOVD servers
servers = SOVD.GetDiscoveredSovdServer();
// Browse through all discovered servers
foreach(server in servers)
{
// Gets all components of a certain server
components = SOVD.GetComponentDescriptors(server);
// Browse through all components
foreach(component in components)
{
// Gets all faults of a certain component
faults = SOVD.GetFaultsAsDescriptors(component);
// Browse through all faults
foreach(fault in faults)
{
// Add the faults to the list which will be returned
ListAppendItems(faultLst, { fault });
}
}
}
}Advantages of OTX
standardization
OTX is an international standard defined in ISO 13209. Manufacturers, suppliers, and tool providers can work transparently and interoperably.
Visual modeling of processes
Diagnostic processes are modeled graphically as flowcharts. Complex processes are easy to understand, maintain, and document.
Reusability and modularity
Procedures and subprocedures can be reused and combined, reducing development effort and sources of error.
Testability and debugging
OTX sequences can be executed step by step. Diagnostic tools offer breakpoints, variable monitoring, and logging.
Integration into diagnostic tools
OTX is embedded in many OEM-related tools. It can be seamlessly integrated into workshop, production, and development systems.
Flexibility in protocols and communication interfaces
OTX can be used with various backend technologies: UDS, DoIP, SOVD, etc. The diagnostic logic remains the same, only the technical implementation changes.
Traceability and documentation
OTX sequences are readable by both humans and machines. OTX sequences can contain not only the logic but also the logic specification—ideal for audits, quality assurance, and series releases.
Interface between development, production and after-sales
OTX enables a consistent diagnostic status throughout the entire vehicle life cycle.
Who needs OTX?
OTX is primarily a process issue. OTX's strengths lie in the exchange of testing knowledge in complex environments across process boundaries. In this context, OTX is unique in its ability to ensure that the same test logic can be executed at any time in any target system and produces the same results. However, when it comes to individual test benches, there are many alternatives, such as Python. However, when you have the complexity of an automobile manufacturer, in my opinion, there's no way around OTX.
Conclusion
OTX is a domain-specific programming language (DSL) for the process-safe description of interchangeable and executable test logic within the automotive industry. OTX has established itself as a platform-independent description of diagnostic test logic in the automotive industry.
