OTX test logic can be programmed in the graphical designer with a basic understanding of programming. The test logic is presented in a way that even a manager can understand.

With the OTL code editor, you can edit OTX just like in a regular code editor (e.g., DotNet or Java), with auto-completion and syntax highlighting. The programmed OTX is continuously synchronized with the graphical designer.

The Solution Explorer is the central entry point for editing OTX documents. It lists all projects, their contents, and dependencies. It provides an overview of the files on the file system and allows you to edit the project structure. All settings can be configured and PTX files can be exported via the Solution Explorer.

Design-time validation continuously checks all user input in the background and clearly displays errors (warnings and notes) in the error list. You can navigate directly to the error from the error list. Complete validation can selectively validate individual projects, documents, and procedures.

Using the Export Manager, standardized and target-system-independent PTX files as well as target-system-dependent PPX files can be created. You can specify whether the files should be executable and whether all dependencies should be included. The files can also be signed or encrypted.

The OTF has integrated, full-featured version control for SVN and GIT. Files can be updated and checked in. Changes are displayed in the Solution Explorer and can be diffed at the XML level.

The object search can be used to find text within OTX documents. It is possible to restrict the search to the current project, package, document, or procedure, as well as to OTX objects. Regular expressions are supported, and found text can be replaced.

The test logic programmed in OTX should be validated against the expected behavior. This is the task of the test project. Unit tests or integration tests can be written in OTX within the test project and parameterized using various test cases. The integrated Test Explorer executes the test cases and generates a test log.

The Info window provides useful, detailed information for each selected element. This includes a description of the function (semantics), the specification, the location of the element, and its relationship to other elements.

The debugger allows you to execute OTX procedures step by step. All common debugging features are supported, such as breakpoints, procedure stepping, changing the values of declarations in the breakpoint (watches), and returning.

The Runtime Explorer provides a graphical overview of the state of the OTX runtime environment. Time-based diagrams display useful information such as battery and ignition status, the number of open communication channels, the number of diagnostic services sent, and memory usage.

To analyze runtime behavior, the variable trace outputs all changes to OTX declarations, such as variables or procedure parameters. The communication trace logs diagnostic communication.

The OTX Profiler enables convenient analysis of the runtime behavior of an OTX procedure. For this purpose, the profiler files generated by the OTX runtime are processed. These contain information about the runtime, processor load, and memory usage of each executed OTX activity.

A diagnostic runtime system (MVCI server) standardized according to ISO 22900-3 is used for diagnostic communication. MVCI servers from five different manufacturers are currently supported. Additional MVCI server integrations can be added by the user or by EMOTIVE.

The diagnostic communication of a standardized MVCI server can be simulated at the D-PDU API level. This enables development without connected hardware. CAN and DoIP as well as functional addressing are supported. The ignition status and battery voltage can be simulated. The simulation is contained in an editable ASCII file and can be generated from a DiagLogging file. DiagRA-S simulation files can be processed. The OTX PduSimulation extension can be used to modify the simulation for individual test cases.

The ODX database view displays, among other things, all communication channels present in the loaded ODX database, their variants, the available diagnostic services, and their parameters in a high-performance and clear tree structure. Diagnostic services or other elements can be dragged directly into the process and parameterized.

The new SOVD standard according to ISO 17878 describes a REST API for service-oriented diagnostic communication. For this standard, OTX has been enhanced with a new extension that is fully supported. A loaded offline capability description is displayed in a performant and clear manner. The user receives design-time support, and the checker checks the input for correctness in a SOVD-specific manner.

SOVD communication can be simulated using the built-in SOVD servers. The simulation is available in a simple, self-explanatory JSON file and can be edited by the user. This allows the development of OTX procedures even without connected hardware.

The Declarations window lists all declarations valid in the current scope, such as global and local variables and constants, procedure parameters, and context variables, for editing. The declarations can be dragged and dropped directly into the designer.

The overview window displays a reduced graphical view of the current OTX procedure so that you can get an overview.

The Properties window lists all properties of the selected element for editing.

The graphical project overview displays the entire project folder (solution) in a mind map so that all project references and relationships between the documents can be recognized.

OTX mapping allows external functions or applications, such as a GUI screen or a DLL method, to be bound to OTX. OTX mapping thus binds the target-system-neutral OTX to a target-system-specific, user-programmable implementation.

The references used in OTX for ODX diagnostic data are also checked for correctness for different ECU variants. Potential errors are thus detected at design time.

The currently selected OTX element is displayed in the XML window as XML code, just as it is saved in the OTX file.

The language can be switched between German and English. Other languages can be implemented upon request.