Application Story
Better Together - How OTX Connects Standards
emotive - Better Together - How OTX Connects Standards
Summary
OTX is a domain-specific programming language (DSL) for the process-safe description of exchangeable 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. Thanks to its Standard-compliant expandability to include any number of functions, OTX is able to connect different, previously separate standards from a wide range of varying areas. This article shows the potential of OTX in connecting various ASAM standards, e.g. ASAM XIL, ASAM ODS and the ASAM OpenX standards for testing in the field of autonomous driving.
1. Introduction
We are experiencing a radical change today - nothing is as constant as change. The increasingly demanding customer requirements and the increasing global competition are leading to growing complexity and thus to permanent pressure on all operational procedures and processes. Therefore, mastering complexity is one of the key challenges of today. In the long term, this is not a task for one person. It affects everyone. When it comes to collaboration between many people, standardization is unavoidable. To be successful in the long term, standardized processes are needed. This results in greater efficiency, reduced costs and improved product quality, which ultimately increases competitiveness and market opportunities.
To achieve this goal, the OTX Standard has been established in vehicle Diagnostics at automobile manufacturers in recent years. The practical introduction has shown that OTX is primarily a process and integration issue. OTX enables consistently standardized processes from Specification to execution of test logic on any target system.
2. What is OTX?
OTX according to ISO 13209 stands for "Open Test sequence eXchange" and is a domain-specific programming language (DSL) for the process-safe description of exchangeable and executable test logic. Test sequences can be created graphically or using a code editor and at the same time described in such detail that the same test logic can be executed barrier-free in any different target environment. The Standard has the necessary maturity and is comprehensive enough to replace existing solutions in development, production and the workshop. The possible uses of OTX range from the description of simple functional tests in development to commissioning processes in production to completely generic tester applications with guided troubleshooting in customer service. OTX is open, stable, platform and technology neutral. It is continuously further developed under the roof of ASAM. In summary, it can be said that OTX can ensure that the same unchanged test logic can be executed in any target system at any time and always produces the same results.
OTX is Turing-complete. This means it can calculate any computable function. It consists of a stand-alone executable core, see Figure 1. The Data Model of the programming language and all extension points are defined within the core. Each OTX extension extends the core with new domain-specific functions. First for the area of vehicle Diagnostics, then for communication with external systems and for many other functions that are required for a complete programming language.
3. OTX Extensibility
OTX can be extended with new OTX extensions in accordance with the Standard. Eleven extension points are defined in the core Data Model for this purpose. These extension points can extend OTX with any new language elements. This ranges from new activities, data types and declarations to new types of procedures or structural elements. This means that OTX can bring together different, previously separate standards under one roof like hardly any other Standard. For example, to use the ASAM SOVD Standard within OTX, one can simply standardize a new OTX extension for ASAM SOVD. A current, practical example of this is the new planned Standard ASAM TestSpecification.
4. OTX and ASAM TestSpecification
The ASAM TestSpecification project aims to develop a Standard for the general Specification of interchangeable tests. Focus is placed on the interaction of various ASAM standards such as ASAM XIL, ASAM ODS or the ASAM OpenX standards for testing in the field of autonomous driving. To connect these standards, OTX was evaluated and selected as the basic Standard. For ASAM TestSpecification, OTX is being expanded to include new extensions for test description and access to ASAM XIL. Likewise, this could be done for ASAM OpenSCENARIO as well.
5. Benchmarking OTX
When considering the significant effort required to develop a new programming language, one might reasonably ask: Why do we need a new language? Aren't there already enough existing solutions? We have explored these questions and aim to derive the answer by comparing OTX and C++ in terms of performance, memory usage, integrability, and process acceptance. To give a clear answer upfront: yes, we do need this new programming language! Instead of C++, one could fundamentally choose another language like .NET C# or Python. However, the results would be comparable. We are using C++ because we expect the best results in terms of performance and memory usage for deployment in embedded systems. For the examination of OTX, the EMOTIVE OTX runtime is used.
5.1 Process Acceptance
OTX was developed as an XML format for cross-domain integration into existing processes. OTX supports the entire development process of diagnostic test logic, starting from the Specification level by component managers without programming knowledge, to execution on various target systems. The Specification is created in OTX and transported with the test logic as a single source. Afterward, an OTX programmer implements the test logic graphically or in the OTL code editor, without altering the Specification. At this stage, the test logic should be secured through unit and integration tests using the OTX UnitTest extension, as shown in Figure 4. The next step is to adapt the platform-independent test logic to a specific target environment and distribute it, for example, through OTX mapping. The final step is execution on any target system. Results can be logged and returned, and runtime behavior can be analyzed directly on the target system through OTX profiling.
From a user’s perspective, OTX integrates very well into the existing processes of an automotive manufacturer. This is also fundamentally possible with C++; all necessary tools are available, but the required interfaces would need to be defined and implemented. This is precisely what OTX already provides as an ISO Standard. Therefore, I would rate the process acceptance of C++ as satisfactory.
5.2 Integrability
In this context, integrability refers to the ability to integrate into various technical systems without side effects and with minimal effort. The EMOTIVE OTX Runtime was specifically designed for this purpose. The OTX Runtime itself is written in native C++ and is available for Windows and various Linux distributions in both 32- and 64-bit versions. It offers APIs for C++, .NET, and Java, facilitating integration into existing applications. The execution of OTX test logic can occur either within the application’s process or encapsulated in a separate process. For communication with external systems, the OTX Runtime provides various interfaces, known as CustomImplementations, through which any function within a proprietary test system can be called directly from OTX, such as turning the ignition on or off. This makes the OTX Runtime highly integrable.
While the same is technically possible with C++, the effort required is disproportionately higher compared to OTX. Therefore, I would rate the integrability, like the process acceptance, as satisfactory.
5.3 Performance and Memory Usage
To make valid statements about performance and memory usage, a typical OTX application was implemented natively in C++ directly on an MVCI server and once in OTX. The chosen typical application was the generic reading of vehicle identification (FAP = Vehicle Analysis Protocol). Two functionally identical routines were programmed, one in OTX and one in C++.
The process parses ODX data through Database access to an MVCI server and reads information from the ECU using several diagnostic services. The data retrieval occurs over a fixed number of services simultaneously for five ECUs in parallel, and the collected information is then structured and written into a file. Communication is established via CAN and a simulated D-PDU API. It should be noted that the objective here is to perform a quick performance comparison, not to fully determine a vehicle analysis protocol.
For Measurement purposes, the process is executed multiple times. The execution duration, average CPU load during execution, and average memory usage during execution are measured. Figure 2 compares the Measurement results for native C++ and OTX. Lower values indicate better performance.
The measurements show that native C++ achieves better results in all evaluated metrics. This aligns with the expected performance for C++. There is virtually no room for further optimization; in other words, C++ serves as the performance benchmark. Although the OTX Runtime itself is written in C++, it incurs some overhead to ensure process acceptance and integrability. In terms of execution duration, the OTX Runtime is 20% slower; CPU load with OTX is about 30%, and memory usage with OTX is about 50 MB higher. In my view, the CPU load and memory usage values are within an acceptable range, making execution duration the primary relevant metric for performance assessment. Thus, one could say that the EMOTIVE OTX Runtime is approximately 20% slower than native C++. I believe this is a very good result for OTX. Therefore, I would rate the performance of C++ as excellent and the performance of OTX as very good.
5.4 Comparison
As expected, C++ excels in performance. The OTX Runtime, however, shines in process acceptance and integrability across various target systems, while still being performant enough to support all vehicle Diagnostics use cases, including those for embedded systems (see Figure 3).
6. OTX Tool Support
Standards also offer numerous advantages to tool manufacturers, as they provide tool support required to tap the full potential of standards. For tool manufacturers, standards make market access easier and increase customer satisfaction. Tools based on standards are easier to scale to new customers. Existing resources can be invested in increasing product quality instead of supporting proprietary interfaces. This leads to greater innovation and investment security.
In recent years, a broad tool landscape has been established for the OTX Standard. Through practical use by vehicle manufacturers, the tools have been tested and show to have the necessary maturity. Figure 4 shows an example development environment for creating, editing, testing and executing OTX procedures, like a Visual Studio for OTX.
Conclusion
With consistent standards compliance from creation to execution, OTX is more capable than almost any other Standard in the automotive environment of exchanging quality-assured test knowledge across process and tool boundaries and executing it under a wide range of environmental conditions. The harmonizing and integrative effect makes OTX a platform for connecting different, previously separate standards, even outside of vehicle Diagnostics. OTX is used as the basic technology in the upcoming Standard ASAM TestSpecification. OTX is powerful enough to Map all use cases in the area of vehicle Diagnostics, even in embedded systems.
BACK TO OVERVIEW
Follow us on
