OTX Scripting Support
- Jörg Supke

- 3 days ago
- 3 min read

Offloading computationally intensive tasks efficiently – In many projects in vehicle diagnostics and test automation, OTX has established itself as a powerful description language. OTX is deliberately designed as a domain-specific language (DSL) for test and diagnostic workflows in the automotive industry. The language is Turing-complete, meaning that, in principle, any kind of logic can be formulated in OTX. In practice, however, it becomes evident that not every task should actually be implemented in OTX. Especially for computationally intensive algorithms or functions that lie outside the core diagnostic processes, using a specialized scripting language is often significantly more efficient without compromising process reliability. Therefore, the OTX toolchain has been extended with scripting support.
Inhalt
Why OTX Is Not Always the Best Choice
OTX was primarily designed to:
describe diagnostic and test workflows
orchestrate vehicle communication
model test procedures in a structured and traceable way
For these tasks, OTX is highly suitable. However, the situation is different for tasks such as:
complex mathematical calculations
data analysis or signal processing
specialized algorithms
use of existing libraries
Such functions can often be implemented much more compactly and with better performance in traditional scripting languages.
Extension of the OTX Toolchain
To close this gap, the EMOTIVE OTX toolchain has been extended. OTX sequences can now invoke external scripts in Lua and Python:
When compactness and performance are critical, especially when using OTX in embedded systems, Lua is the best choice. Since the OTX runtime already uses Lua, no additional system requirements are necessary.
Due to its large ecosystem of libraries, complex calculations can be implemented efficiently in Python.
This allows specialized functions to be easily used from within an OTX sequence. The principle is intentionally kept simple:
The OTX sequence calls a defined script function
Parameters are passed
The script performs the computation
Results are returned to OTX
This keeps orchestration entirely within OTX, while specialized logic is implemented in a suitable language.
Neutral Integration via OTX Mapping
The connection between OTX and the script is established via OTX mapping. The function to be invoked, the parameters, and the return values are bound to OTX signatures in a platform-independent manner.

The advantage of this approach:
Clear interface between OTX and the script
No dependency on a specific function
Reusable integration mechanisms
Scripts are distributed together with the PTX
Another important aspect is the distribution of the scripts. The script files are transported as self-contained within the PTX file. They can therefore be executed directly, and no separate installation is required. The user receives a fully executable PTX, including all required scripts.
Typical use cases
The integration of scripting languages into OTX enables a range of practical applications:
Computationally intensive algorithms, for example:
Cryptography
Signal processing
Statistical analysis
Safety-critical calculations
Use of existing libraries - Especially Python provides a large ecosystem of libraries for:
Data analysis
Visualization
Mathematical computations
Extension of OTX functionality - Tasks that cannot currently be directly represented in OTX can be easily offloaded.
Example
The example shows a Lua script for generating a list of random numbers, see function RandomList. This list is then sorted in the QuickSort function. The comment above the functions is used to map the Lua functions to the DeviceServiceSignature in OTX.
In the following OTX example, the two Lua functions are bound to two DeviceServiceSignatures and invoked via the OTX action ExecuteDeviceService.
Best of Both Worlds
With the new scripting support, the OTX toolchain combines the strengths of two worlds:
OTX for structured test and diagnostic workflows
Scripting languages for specialized or computationally intensive functions
The result is a more flexible and powerful test architecture without sacrificing the advantages of standardized OTX-based descriptions.


