In the context of the newly established ASAM ideation process, RA Consulting GmbH submitted idea for an ODX run-time format in 2017 as a proposal for a new . The data driven diagnosis in a run-time system according to ASAM standard-3 D is defined in the ODX MCD as the most important, but not the only target. Rather, many other aspects are taken into consideration in the structure of ODX containers (PDX stands for packaged ODX format) (single-source principle for the definition process of diagnostic data). For example, the work-shared development of diagnostic functionality (e.g. through heredity and linking), the documentation of diagnostic architectures, the exchangeability of the containers with suppliers, and the tracking of changes through administrative meta data. The implementation of this type of runtime system for the field of standard is achieved with the so-called MDC 3D server. "D" stands for diagnosis. For that reason, the name D-server is used frequently, alternatively: ODX kernel. This is defined in the diagnostics standard 22900 where it runs under the name "MCVCI server". ISO
The lack of optimization of ODX containers or PDX containers for diagnostic run-time systems makes direct access to the information of an ODX container by an server very inefficient and lowers performance. This is primarily because: MVCI
- the dimensions of the ODX container increase continuously due to greater requirements posed on diagnosis, and the processing of large files sometimes exceeds the RAM capacity of conventional computers.
- the nodes of an ODX container are semantically interlinked (e.g. via ODX links). The exchange format XML, on the other hand, is based on a purely hierarchical structure. This “discrepancy” must be resolved every time the container is loaded, which is both processor and memory intensive. This is not feasible with larger ODX containers.
- from the aspect of the run-time system, an ODX container has a high level of “noise”. That is information that is not required for carrying out a diagnosis and which relates to other aspects of the diagnosis development, such as change management, administrative data, and technical descriptions, such as the occupancy of electric plugs.
The transfer and processing of large ODX files is even more critical in the field of embedded and telematic applications than in conventional applications. There, computer performance, memory capacity and transfer bandwidth to the tester are available only in a very limited scope. Almost every diagnostic run-time implementation thus uses its own proprietary format for a more efficient data-driven diagnosis. A preprocessor transforms a given ODX container into a data format that is optimized, but not standardized for the run-time system.
For the of an ODX run-time format, an adapted, partial optimization must be undertaken for the two rival design objectives of completeness and task orientation: Normally, an ODX container fully describes and documents the diagnosis functionality of a logical unit. Logical units are, for example, control units, control unit families, vehicles or entire vehicle platforms with differing control unit variants. In practice, however, the diagnosis is usually task-oriented. A tester then requires for the run-time only the parts of a complete description that are necessary for a specific task. For example, an specification sequence, which reads out precisely one measured value from precisely one control unit with precisely one log through exactly one diagnostic service. A reduction of the diagnosis data to a previously known partial quantity would decisively reduce the size of the description OTX
(all vehicle variants)
|> 500||> 1000 MB|
(all ECU variants)
|50 - 150||50 - 200 MB|
(one variant of an ECU)
|8 - 30||2 - 15 MB|
(PDX, one per built-in ECU variant
|~ 70||~120 MB|
| ||0,5 - 5 MB|
Table 2: Number of files and file sizes for various ODX formats
This limitation is possible with the RDV, as the VIN and ascertainable CAN node list (device list) can serve as the basis for the limitation during a remote download of a test task to a specific vehicle. use-case
The objectives in standardizing a diagnostic run-time format can be summarized as follows:
- transport of the hierarchical textual exchange format into a binary file format ideally tailored to network structures (graphs)
- identification and elimination of the aspects which are not important for a runtime system, such as administrative data or special data groups (SDGs)
- resolution of modular and work-sharing aspects which do not contribute to the run-time view, for example, inheritance
- creation of a starting point for the further reduction with regard to task-oriented diagnosis
In the coming months, and if there is sufficient interest, proposals for further, identified telematic components are to be prepared by other ASAM members.
- MCD-3D server embedded
- MCD-3MC server embedded
- OTX Open function controller
- OTA API
- OTX extensions for simulations standards and Interfaces
In developing this telematic reference architecture, we hope to achieve the following objectives in the development process: ADAS
- The draft of a standard-based test system in order to reduce the high cost of test methods up to the point of licensing, or for repeated inspections in the operation of highly automated vehicles
- On the basis of new standards like OTX (Open test sequence exchange format) and domain-specific extensions (OTX extensions) drafts are to be prepared for the automation of repeated test sequences, thus making them easy to understand and efficient over the entire life cycle.
- Existing standardizing potential, for instance, with OpenDRIVE or OpenSCENARIO could be used here. The interoperability with other existing standards, or standards of ASAM, ISO or SAE that have been identified for development should be guaranteed.
- By means of drafting domain-specific extensions of the test standard OTX, the interoperability of vehicle maneuvers for test procedures in simulation systems should be facilitated.
4 Economic benefits and a view into the future
The economic significance of automotive engineering is of huge importance to the German automotive industry. The provisions of the current research programs reflect the necessity of speeding up standardization. ASAM has seen this need and has developed an accelerated and simplified procedure for innovative standardization initiatives, in particular for the fields of “telematics and ideation”. The aim should be to publish important new standards within 12 months.