
Facilitating OEM diagnostic data development | VisualODX
ODX 2.2 is a diagnostic standard proposed by ASAM (Association for Standards in Automation and Measurement Systems) and also listed as ISO 22901, which is an open diagnostic data format based on XML language and has been widely used in the international area. At present, ODX diagnostic standard has been used by major OEMs, but in the ODX data development stage, ODX diagnostic database editing, creation is still a huge workload, and we launched the ODX diagnostic design tool- VisualODX can solve this problem for OEMs.
Since the release of VisualODX, we already received many request from OEMs about ODX how to deal with Session and Security issues, here is a brief introduction for you.
According to the ODX protocol, the description of the Session and Security submodules is divided into two parts:
•Describes the State Transitions Resulting that may result from executing a diagnostic object (DIAG-COMM);
•Describes the preconditions (Precondition) for the execution of a diagnostic object (DIAG-COMM).
To describe these two sub-modules with ODX, all states and state transitions supported by the ECU are first defined in the STATE-CHART module of the Diagnostics Container Layer in terms of session type and security level. The States are used to describe the preconditions for the execution of the diagnostic objects, and the State Transitions describe the possible results of the execution of the diagnostic objects.
(Figure 1 Security Level States)
(Figure 2 Session Type States)
(Figure 3 State Transitions for Security Level)
(Figure 4 State Transitions for Session Types)
After defining the State Chart, the diagnostic object can be associated with the Precondition for execution and the State Transitions Resulting that may result from the execution of the diagnostic object. Figure 5 Example of a Diagnostic Object for Service 22, with the preconditions that support the execution of this service - Session Type and Security Level.
(Figure 5 Example of Precondition association)
Figure 6 provides an example of the correlation of the status jump results generated with the 11 service as the object of the performed diagnostics, also including session type and security level. (The 11 service is ECUReset.)
(Figure 6 Example of State Transitions Association)
Adding preconditions and state transitions to diagnostic objects can be a complex and tedious task, but with the use of semi-customizable software, VisualODX, the engineer's workload can be greatly reduced.
We will define the session types and security levels in the ODX template and the Excel diagnostic questionnaire template based on the requirements specification. Users will only need to fill in the supported security levels and session types for the services in the Excel to automatically associate them with the services when converting the ODX data.
(Figure 7 Session types and security levels defined in the template)
(Figure 8 Fill in the Excel for the service with its supported security level and session type)
After completing the ECU Diagnostic Questionnaire, import the Excel into VisualODX, and the ODX data can be automatically generated.
The semi-customizable software VisualODX helps users to edit the created ODX databases in addition to creating ODX databases. It is a powerful ODX editor that creates, views, and edits ODX diagnostic data according to ODX standards and supports consistency checking of the data.
VisualODX creates StateChart templates in ODX templates ahead of time that can be associated with execution preconditions (Precondition) and State Transitions Resulting.
(Figure 9 Example of editing StateChart at the diagnostic session level)
(Figure 10 Adding Precondition to Services)