Automotive Industry Insights

ODS and MDF

Description
ASAM MDF (Measurement Data Format) is a binary file format for storing recorded or calculated data for postmeasurement processing, off-line evaluation, or long-term storage. ASAM MDF is not only used for the storage of sensor, ECU, bus, or monitoring data, it is also used for the compact storage of large data amounts as external components managed by an ODS (Open Data Services) Mixed-Mode Server.

In addition to the classical bus data like Flexray, LIN, CAN, or Ethernet, new types of data are recorded in the ADAS/AD areas (ground truth data (e.g. GNSS), GigEVision, SerDes/GMSL, FPD Link, or MIPI. These new types of data should be managed and stored in a similar way to the classical bus data in future MDF versions.

Therefore, ASAM is currently planning to extend the ASAM MDF standard by an associated standard, “Image Radar Lidar Sensor Logging,” that describes how to store image streams that are created in ADAS/AD areas. The aim of this project is to clarify how raw sensor data and stream metadata can be handled in ASAM MDF 4.x and its associated standards.

Results in the testing study group might influence the work of that parallel working group or vice versa.

ASAM ODS (Open Data Services) focuses on the persistent storage and retrieval of testing data. The standard is primarily used to set up a test data management system on top of test systems that produce measured or calculated data from testing activities. Tool components of a complex testing system can store data or retrieve data as needed for proper operation of tests or for test data postprocessing and evaluation.

The standard provides the so-called base model. This base model is used to derive specific application models for different application areas. It provides a rough classification of the data in application models by adding semantics to them. This enables client tools from different vendors to correctly interpret the data. Application models can be defined that cover the data storage needs for a variety of application areas.

Test data saved in the ODS standard can be accessed through standard APIs. For that purpose ODS has released different APIs:

• RPC (90s)
• CORBA API (2003)
• Web-service-based HTTP API (2017)

Benefits of the Standard
The major strength of ODS as compared to non-standardized data storage solutions is that data access is independent of the IT architecture and that the data model of the database is highly adaptable yet still well defined for different application scenarios. Despite this flexibility, clients can query the data from the database and still correctly interpret the meaning of the data.

The ODS standard includes several associate standards, which, for instance, further specify the use of ODS in certain domains, for certain types of test data, or for certain technologies, such as:
Technical driven:

• Storage of ODS data in big-data environments
• Integration of MDF data for storage of measurement data in “mixed mode”
• Storage of bus data
• Storage of calibration data

Domain related:
• Geometry and NVH data
• Workflow specifications (including parallel execution, synchronization, etc.)
• Passive safety data (owned by ISO 22240)

Because the storage of MDF files is part of the ASAM ODS standard, the related activities of the MDF working group might have an impact on the further development of the ASAM ODS standard. Following the already-mentioned minor standard “Image Radar Lidar Sensor Logging,” the ODS 6.2.0 minor release will:

• be updated to include the therefore-defined streaming data
• be updated by an interface that allows the integration of user-specific (binary) file formats by different vendors; those could also include non-MDF ADAS test data

Similar to (physical) testing domains, plenty of artifacts are created in the ADAS/AD domains that either describe the execution of tests or test results or contain the recorded data during the tests. Therefore, it seems promising to develop a specific ADAS/AD domain model as an associate ASAM ODS standard. A high-level domain model containing the most important data objects and their constraints has already been identified by the study group (see e.g. chapter 5).