TESTING NEXT GENERATION
Execute test logic in any target system and come to the same results
NEW OTX Runtime API
The second generation of the OTX Runtime API is a programming interface for the simple execution of OTX procedures in own applications. The API is available in the three technologies C ++, DotNet and Java and can therefore be used within most of the existing technologies under Windows or Linux. It has extensive options for seamless integration into existing systems and infrastructures.
The OTX Runtime API runs in many thousands of productive environments of automotive manufacturers in development, production, service and within the vehicle under Windows, Linux and in embedded systems. The areas of application of the OTX Runtime API range from ECU setup, flashing and coding, vehicle status documentation and test bench control to subjective assessment in production. Potential areas of application in future areas are, for example, service-oriented diagnosis (SOVD) or scenario-based testing in the field of autonomous driving.
Structure and Interfaces
In order to run OTX, the API of the OTX Runtime must be integrated into an application. OTX projects (PTX files) can be loaded via the API, the data structure can be browsed and procedures can be started. The OTX Runtime API is available in the three technologies C ++, DotNet and Java and therefore it can be used in practically any existing technology. When starting a procedure, a runtime context is created. The runtime context is the core of the runtime environment where the execution of OTX procedures takes place. The OTX Runtime and all layers below are written in native C ++. It is high-performance and saves resources and can be used on desktop, web or embedded.
Exchangeability at all Levels
The OTX Runtime also works on the available standalone DiagManager for diagnostics communication. Its task is to translate all OTX commands relevant for diagnostics to the commands of a specific diagnostics runtime system. It can work as a server so that parallel diagnostics from discretionary processes or applications are possible. The server serialize the commands of the clients and passes them on to the CommandProcessor. The CommandProcessor optimizes and priorities the diagnostics commands. For example, the CommandProcessor administers the open diagnostics channels. The CommandProcessor is exchangeable. This allows users to implement their own, specific administration of the communication channels or diagnostics services. The CommandProcessor sends its commands to the DiagRuntimeSystem. The actual translation from OTX to the specific methods of a diagnostics runtime system, for instance according to ISO 22900-3 (MVCI), takes Place in the DiagRuntimeSystem. This step is entirely exchangeable as well. Here users can independently connect to their own, proprietary diagnostics runtime systems.
The functionality to bind OTX to external systems (e. g. GUI, test bench, measurement data acquisition) is not located within the OTX runtime but in an external library, the so-called custom implementation. Interfaces that users can implement themselves are provided for this purpose in the OTX Runtime API. EMOTIVE supplies standard implementations for these interfaces. It is therefore possible to seamlessly integrate and execute OTX in any target system. The same OTX sequence can be executed in a web application With an HTML Screen connection or in a vehicle infotainment system.
Technical Data
Contact us for more information!