1. Introduction

Before delving into the main content, let’s first clarify the purpose of parsing the ODX database. For diagnostic functionality-related testing projects (such as DTC testing), the implementation generally involves two steps: first, using CANoe-CAPL to develop a generic diagnostic functionality test script; and second, when testing a specific ECU, configure the parameters of the generic script based on the ECU's diagnostic data sheet. This configuration can be done manually (which is inefficient) or automatically by parsing the diagnostic data sheet. In past projects, diagnostic data sheets were available in both Excel and ODX formats. To address this, Polelink developed a diagnostic data sheet parsing module (supporting both Excel and ODX formats), which enables the automatic configuration of test script parameters, thus improving efficiency.

2. ODX Implementation Method

ODX uses Unified Modeling Language (UML) class diagrams for description, and ODX data is stored in XML file format. We know that classes contain attributes and methods and have features such as encapsulation, inheritance, and polymorphism. So, how is UML mapped to XML? The ISO 22901-1 specification provides the following guidelines:

- Map UML classes to XML elements.

- If an attribute in a UML class has an "attr" marker, map the attribute to an XML element’s attribute. If the attribute does not have an "attr" marker, map it as a child element of the XML element. If the UML attribute has a "content" marker, map it to the content of the XML element.

- If class B is related to class A through aggregation or composition, class B is mapped as a child element of class A in the XML structure.

- If class B is associated with class A, it is typically represented as a reference in XML, such as `<snref>`, `<snpathref>`, or `<odxlink>`.

- Inheritance in UML class diagrams is represented as `<PARENT-REF>` in XML.

Note: Aggregation, composition, and association are relationships between UML class diagrams, which will not be elaborated on here.

Figures 1 and 2 below illustrate examples of converting UML to XML based on the rules mentioned above.

Figure 1

Figure 2

3. ODX Inheritance – Value Inheritance

Value inheritance is a core concept in ODX, where the concept of object-oriented inheritance is applied to the diagnostic data model, offering the following benefits:

1. Reuse of diagnostic data across multiple ECU variants.

2. For ECUs used in multiple projects, common data can be extracted, with only the differences retained in the ECU variants, reducing data redundancy.

3. Provides data security and integrability.

In the previous article, we briefly introduced ODX inheritance. To avoid data redundancy, ODX divides diagnostic layers into five levels, as shown in Figure 3. Among these levels, the protocol layer is general, while the ECU Variant layer is specific. The ECU Shared Data layer functions as a library, providing data and services for other layers.

Figure 3

As mentioned earlier, inheritance in ODX is implemented using `<PARENT-REF>` in XML. If part of the inherited data is not applicable, it can be excluded using `<NOT-INHERITED-DIAG-COMM>`. For example, in Figure 4, this ECU does not support level 3 and level 4 unlock levels.

Figure 4

4. Overview of the ODX Parsing Process

When you receive an ODX or PDX file (PDX is a package of several ODX files), how do you start the parsing process?

1. First, locate the Base Variant file of the ECU.

2. Find the inheritance relationship in the Base Variant.

3. Search for the corresponding ECU variant, i.e., ECU Variant, in the Base Variant file.

4. Look for the corresponding diagnostic services and data in the ECU Variant file.

Figure 5

5. ODX Parsing Practice

Based on the ODX parsing process outlined in section 3, the parsing results are shown in Figures 6, 7, and 8. The ECU Shared Data serves as a library and provides common diagnostic services, as shown in Figure 6. In addition to inheriting the common diagnostic services of the Base Variant, the ECU variant BCM 88890251 A adds several DIDs, RIDs, and IO Controls while removing incompatible services such as 19 15, 27 05, and 27 06. Figure 8 shows various data types contained in ODX, which will not be elaborated on here.

Figure 6

Figure 7

Figure 8

6. Conclusion

Compared to the traditional Excel format for diagnostic data exchange, ODX unifies the format of diagnostic files, making it unnecessary to convert formats when sharing data across R&D, testing, production, and after-sales departments. As a result, many OEMs have started using ODX. Currently, Polelink has developed an automated diagnostic testing solution based on ODX. If you’re interested, feel free to join us for discussions.