Short description:

ODX Editor for abstracting ECU parameters and visualizing existing ODX-data compliant with ASAM MCD-2D V2.0.1.

ODX Editor
The ODX Editor is an extension software to the MDT - Modular Diagnostic Tool, the innovative diagnostic software. It is used to abstract the ECU parameters. If an ODX file is already available to an ECU from the producer or from the designing process, this file can be examined with the ODX Editor. It corresponds to the ASAM MCD-2D V2.0 standard, so to say it is a standardised XML format to describe ECUs.

Available and new ODX files are edited via a GUI. In addition, the ODX Editor simplifies writing texts and sees about observing the rules to create valid files.

The ODX Editor was especially developed to be able to create ODX-data for a diagnostic application. The parameters of an ECU are simply transferred to a database. The access to a parameter including the necessary protocol specifications can be entered beside the communication parameters like the CAN bus with baud rate and ECU-ID. Supporting the user, the functionallity can be checked directly by executing a service and showing the return value at connected ECU. Variations can also be completed in the database in case of a firmware change.

Protocol definitions have to be made for an ECU, including variable types and CAN bus properties like baud rate, basic ID, filling bytes etc. Furthermore global valued services and belonging requests and responses can be defined. This data can be accessed later or be defined in the base variant, too. The structure of the base variant is similar. The global definitions from the protocols are handed down to the base variant, but can also be overwritten, if required.

Editing is done in the following way: The context menu is opened and properties are selected with the right mouse button. Entries can be copied or deleted in addition. Alternatively a double click onto the entry is enough to edit. Properties like Short Name or Long Name can be selected freely corresponding to the ASAM definition. The internal and external data type (casting) as well as the size (1, 8 or 16 Bit) are defined. In addition some bits could be masked out via a bit mask. A text table can be defined. A text is attributed to certain values, there. Another possibility is the type MATHEMATICAL FORMULAR. A translation of the ECU parameters is enabled directly here.

Defining services, both request and response must already be defined. So it is recommended to define those first. The parameter type CODED-CONST indicates that those definitions are not changeable later (from the authoring system). The ServiceID, the starting address and the length must be indicated for an ECU with KWP2000 support. Name and value must be indicated for every parameter. In a similar way the belonging response is defined. The value of the parameter is given back to a byte position besides the firm ServiceID. The data type (DOP) is a text table, so a string is given back to the application.

Request and response are referred in the service. It can be about more responses and even no responses, if the message is laid cyclic onto the bus by the ECU. Specific communication parameters of the “parents”, in DIAG SERVICES or COMPARAM defined values, can be overwritten here.A test of such a service is advised after defining. This functionality can be accessed via the menu bar. If parameters are adjustable, those can be selected. After that the service is transmitted to the ECU via the data collection layer and the result is displayed. That guarantees an unobstructed integration of the service in the authoring tool after a successful definition. An integrated help function is available as reference.