top of page

OTX Scripting Support

  • Writer: Jörg Supke
    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:


  1. Lua

    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.

  2. Python

    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.


Figure 1: OTX Mapping
Figure 1: OTX Mapping

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:


  1. Computationally intensive algorithms, for example:

    • Cryptography

    • Signal processing

    • Statistical analysis

    • Safety-critical calculations

  2. Use of existing libraries - Especially Python provides a large ecosystem of libraries for:

    • Data analysis

    • Visualization

    • Mathematical computations

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

bottom of page