ODX-based diagnostic test development (2): ODX database analysis

The previous article in the series "Diagnostic Test Development Based on ODX (1): ODX Database Analysis" briefly introduced the ODX file type and the hierarchical structure of each file. In this issue, we will introduce in detail how to parse the ODX database.
Before launching the main text, let me first explain the purpose of parsing the ODX database introduced in this article. For projects involving diagnostic function tests (such as DTC, etc.), the implementation process is roughly two steps: first, complete the development of a general diagnostic function test script through CANoe-CAPL; when implementing tests on specific ECUs, complete the parameter configuration of the above general script based on the diagnostic data table of the ECU, which can be manually configured (lower efficiency) or automatically configured by parsing the diagnostic data table. In previous projects, the diagnostic data table has both Excel and ODX formats. For this reason, Beihui has developed a diagnostic data table parsing module (supporting Excel and ODX formats) to realize automatic configuration of test script parameters, thereby improving efficiency.

01ODX Implementation MethodODX
is described using the Unified Modeling Language UML class diagram, 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 do we map UML to XML? The ISO22901-1 specification makes the following provisions:

Regulation

Map UML classes to XML elements; If the attribute of the class in UML has an "attr" tag, map the attribute to the attribute of the XML element; If the attribute of the class in UML does not have an "attr" tag, map it to the child element of the XML element. If the UML attribute has a "content" tag, map it to the content of the XML element; If class B is associated with class A through Aggregation and composition, class B is mapped to the child element of the XML class A element; If class B is associated with class A through association, it is usually implemented in XML as a reference, such as "snref", "snpathref" or "odxlink"; The inheritance relationship in the UML class diagram is implemented in XML as; Note: Aggregation, composition and association are the relationships between UML class diagrams, which will not be introduced in detail here.

Figures 1 and 2 are examples of converting UML into XML based on the above rules.

Figure 1

Figure 2

02ODX inheritance - value inheritance
Value inheritance is a core concept in ODX. The concept of object-oriented inheritance has the following advantages when used to diagnose data models:

Multiple ECU variants reuse diagnostic data;

In the case where an ECU is used in multiple projects, common data can be extracted and only different data is retained in the ECU variants, thus reducing data redundancy;

Provides data security and integration.

In the previous issue, we briefly introduced ODX inheritance. In order to avoid data duplication and redundancy, ODX divides the diagnostic layer into five levels. As shown in Figure 3, Protocol is general, ECU Variant is specific, and ECU Shared Data is like a library that can provide data and services for other layers.

As shown in Figure 3
, the inheritance relationship in ODX is implemented in XML. If some of the inherited data is not applicable, the inapplicable data can be removed. As can be seen from the example in Figure 4, the ECU does not support level 3 and level 4 unlocking levels.

Figure 4

03 Introduction to ODX parsing ideas
When we get an ODX or PDX (PDX is a package of a series of ODX files), how do we carry out the parsing work?

First find the Base Variant file of the ECU.

Look for inheritance relationships in the Base Variant.

Find the corresponding ECU variant, i.e. ECU Variant, in the Base Variant file.

Find the corresponding diagnostic services and data in the ECU Variant file.

Figure 5

04ODX parsing practice
According to the ODX parsing ideas in Chapter 3, the parsing results are shown in Figures 6, 7 and 8. Among them, ECU Shared Data, as a library, provides general diagnostic services, as shown in Figure 6; and ECU variant BCM 88890251 A not only inherits the general diagnostic services of Base Variant, but also adds multiple DIDs, RIDs, and IO Controls, and removes 19 15, 27 05 and 27 06, which are not applicable. Figure 8 shows the various data types contained in ODX, which will not be introduced in detail here.

Figure 6

Figure 7

Figure 8

05 Summary
Compared with the inconvenience of exchanging diagnostic data in the traditional Excel format, ODX unifies the format of diagnostic files. When exchanging data between R&D, testing, production and after-sales departments, there is no need for format conversion. Therefore, many OEMs have begun to use ODX.