• DIAG-LAYER-CON­TAI­NER
  
  • References and Inheritance
  • Enter­ben
  • DIAG-COMM-primitives
  • DATA-OBJECT-PROPERTY (DOP)
  • Conversion methods (COMPU-METHOD)
  • Data types for DOPs (Diag-Coded-Types)
  • Date Element Complex (Complex DOP)
• Variantenidentifikation

DIAG-LAYER-CON­TAI­NER

We now want to describe the container elements of the ODX structure and begin the main container element, the DIAG-LAYER CONTAINER. He is part of each ODX-parameterization and includes all diagnostic services and diagnostic procedures of a control unit including the associated data. DIAG-LAYER CONTAINER itself is divided into hierarchical layers, called DIAG-LAYER, their context, we want to illustrate on the following figure.

DIAG-LAYER CONTAINER - Vererbung

At the top we have the so-LAYER PROTOCOL. The PROTOCOL LAYER describes the generic diagnostic protocol to be used. For example, UDS and KWP 2000th Then we have the BASE VARIANT diagnostic layer. The BASE VARIANT diagnostic layer describes a specific device family, such as a door control device, of which there are typically several variants, such as a door control device for the front door, another door control device for the rear doors. These variants are described in the so-called ECU-VARIANT diagnostic layer. Often it is useful to group some diagnostic tests. For example, in services linked to the Flash programming, services, certain workshop test procedures, etc. The description makes the so-called FUNCTIONAL-GROUP-LAYER. And finally, functions and data that can be sorted and used in several projects, we normally meet up in the ECU-SHARED-DATA LAYER. This ECU-SHARED-DATA container is a kind of library suitable to the core concepts of ODX is to define data just once and then having to just reusing the same project or other projects. Thereby reducing the overall amount of data and increased data security, because only changes from a reference data set must be described. The ECU-SHARED-DATA reuse this library is a first opportunity to provide such data. In the field of ECU-SHARED-DATA-defined data, other layers can be imported and thus used. Importing is done by a homing, that is, the possibility of PROTOCOL LAYERS such an item from the library ECU-SHARED-DATA be used by referring in-LAYER PROTOCOL to this item.

References and Inheritance

For these references ODX knows two different ways, which we shall consider the following.

First, the reference to the ID is possible. You have seen before, each element can get a ODX ID. A reference made by referring to an element of an ODX-LINK (ID-REF) to the ID of another element. The second option is to refer to the SHORT-NAME on another object. This is called SHORT-NAME-REF (SN-REF).

When you import data from the ECU SHARED DATA library, the imported data can not be changed. This makes for common libraries, change them is difficult, mind. A more powerful way to reuse data, but the inheritance.

Inheritance is a fundamental concept in computer science. When inheriting one defined on a higher of the so-called parent-layer, in the example here-Layer Protocol, services and data in generic form. The underlying layers, for example, inherit the BASE VARIANT layer, these services. That is, they can use all the services that were defined on the higher layer as well. This is called Inherit. The underlying layers of these services, but also modify. For example, of certain services provided in other implementations, other conditions etc. are needed. This is called Override. Furthermore, the use of individual services or data are excluded. This is called Enter­ben.

Virtually the inheritance is through references. The reference to inheriting layer on the layer will inherit from them. In contrast to the import, which refers to a single data element, referenced the heir to a whole higher ground layer. The overwriting of an element is done, in which one in the layer, the override would like to define an identical item with the same SHORT-NAME.

The visibility of the elements depends on which links are selected, whether referenced with ODX-LINK or SHORT-NAME. The disinherited, that is, the invisible-making elements are inherited, with a special attribute, the NOT INHERITED-SHORT-NAME-REF attribute.

Inheriting and disinherit is very powerful in terms of reuse of data. However, it is also prone to error, because not always entirely clear which elements can be defined at what level.

Now let's look on inheritance and visibility on the inheritance of several examples. A first example in which there are three layers, A, B and C. A is the highest hierarchy, C is the lowest hierarchical layer. Within the highest level A 2 objects are defined, object O1 and O2 object, the object referenced by a short O1-name-reference to the object O2. O1 is such a diagnostic service, O2 is a certain parameter of this diagnostic service. The layer B now inherits from that layer A, which means the objects O1 and O2 are also theoretically in the layer B as available. Since the layer B, however, would redefine the parameters of O2, it defines its own parameters derived from O2 O2 `. The object O1 in layer B is inherited from the layer A and is not changed there. By Short-Name-Reference referenced, the object O1 in the layer B, not O2, which has inherited it not so, because it was so overwritten, but the object referenced O2 `. We see the same again on the layer C. Layer C inherits from B. This layer in turn on the layer A, which is the object O1 is used in the C layer. The object would inherit the O2 `C theoretical layer of the layer B (not O2) would like, but which also defined as `` self-O2. The SHORT-NAME-REF object O1 shows in the C layer to the object O2 ``. That is the SHORT-NAME-REF remains within the same layer. If there is an element to override the SHORT-NAME-REF shows the overwritten element in the same layer.

References and Inheritance - SHORT-NAME-REF (SN-REF)

Let us now turn to the same structure with the three hierarchical levels A, B and C, and the two elements of O1 and O2 during a shift if, instead of referring to the SHORT-NAME, a reference to the ID, called a ODX-Link, used is. A turn in the plane are the objects O1 and O2, where O1 to O2 now refers to an ODX-link. In layer B, in turn, the object O1 is inherited unchanged, while the object is overwritten by an object O2 O2 `. Now the object O1 refers to the layer B on the object O2, but not in layer B, but in layer A, on the same O2, to which reference has the O1 in A also. Reason: O2 and O2 'have different IDs. In layer C, it looks the same: O1, which was indeed ultimately inherited from A as in C still on the ID of O2 in A. The overwritten objects O2 and O2 ``` in the planes B and C are indeed defined but the object O1 does not use it but still using the O2 from A.

References and Inheritance - OTX-LINK or ID-REF

We recommend that when you refer in principle to use SHORT NAMES, SHORT NAMES as reference the object in the same layer and all changes are therefore transferred automatically. ODX the link you should use only if you consciously refer to a unique object in another layer like!

Enter­ben

Let's look at a third example of the disinherited. Again, 3 levels. The planes A, B and C. A is again the highest hierarchical level. Where an object is defined O3. The level B inherits from the level A, the object O3 in the plane B also visible and usable. Level B defines itself, two other objects O1 and O2. The level C, in turn, inherits from B. This means that the objects O1 and O2 would be visible there. However, O2 is overridden with C in O2 `. The object O3 is replaced on the C-NOT INHERITED attribute. It is thus at the level of C neither visible nor usable.

References and Inheritance - disinherit

DIAG-COMM-primitives

DIAG-COMM-PRIMITIVE describe the diagnostic services within the DIAGNOSTIC-layer. There are the ODX DIAG-SERVICE-description element that contains three elements. A REQUEST, one or more positive response messages (POS RESPONSE) and one or more negative response messages (NEG-RESPONSE). These elements refer to parameters in turn. The parameters can in turn called DATA-OBJECT-PROPERTIES (DOP), the conversion methods are included and these can continue to refer to the corresponding physical unit, called UNITS.

Processes that require the execution of several consecutive diagnostic services, particularly in relation to response data of a service, can be as macros, as so-called SINGLE-ECU-JOBS define ODX. SINGLE-ECU-JOBS are Java programs, which means the data element in the ODX-structure refers to a Java program. must be defined in the ODX data structure, which is calling Java program for this process, enter the parameters, which parameters go out and the return values ​​are supplied in case of error (INPUT PARAMS, OUTPUT PARAMS and NEG OUTPUT PARAMS). The detailed description of the parameters themselves are back on DATA-OBJECT-PROPERTIES with the appropriate units (UNITS).

Diagnostic Communication Primitives (DIAG-COMMS)

ODX distinguishes different types of parameters, see table. We have among others the coded constants (CODED-CONST). These are, for example, SIDs, so fixed hexadecimal numbers. Furthermore, there are parameters that represent a physical value, PHYS-CONST.

The actual numerical values ​​(VALUE) always point to the corresponding DATA-OBJECT-PROPERTY, see below, and then we still have complex parameter structures that are described in tables. The tables consist of a key with which the table is indexed and the actual data structure. These include the appropriate table entries.

Parameter types for DIAG-SERVICES

DATA-OBJECT-PROPERTY (DOP)

DOPs contain all the information needed to establish the diagnosis of a service provided or to make a diagnosis service data to be transmitted to humans interpret. We distinguish two types of DOPs. The simple SIMPLE DOPs, describing a single data value and the COMPLEX-DOPs, the structures of data values. A DOP essentially defines the conversion method between the encoded value as it is ultimately transmitted to the controller and the physical size.

DATA-OBJECT-PROPERTY (DOP)

The following data is stored in the DOP:

• COMPU-METHOD
  Conversion method between encoded value and the physical size

• DIAG-CODED-TYPE
  Data type of the encoded value of a parameter

• PHYSICAL-TYPE
  Data type of the physical value of a parameter

• INTERNAL-CONSTR
  Validity intervals for the parameters in the encoded format

• UNIT-REF
  Reference to the physical unit of the parameter

• PHYS-CONSTR
  Validity intervals for the physical parameters

Conversion methods (COMPU-METHOD)

ODX is a variety of conversion methods for data objects available, as illustrated. For error, for example, are often used the text table, with an error code that is typically encoded in hexadecimal format, a plain text can be assigned. Many values ​​are not encoded at all, that is, the physical and the coded value are identical. Here is given to the translation method Identical. Many sensor values ​​using a linear map with slope and offset, the linear conversion method. Scale-linear, there is also a piecewise linear conversion by describing a curve by piecewise linear functions. Almost any function can be the quotient of two polynomials with the Council Func-map conversion method. If that alone is not enough, you can put together such a quotient of rational functions, piecewise see scale-Rat-Func. Then we have the usual characteristics that are linear are interpreted: Tab-Interp and conversion methods that are so complex that they must outsource programs. But there is the possibility of Compucodes that points to an external Java program that performs this conversion then.

Conversion methods (COMPU-METHOD)

Data types for DOPs (Diag-Coded-Types)

Even with the data types, ODX proves to be quite flexible. For coded data types there are, for example, the standard-length Type. If the value has a fixed length, then one defined in the DOP, the number of bits needed to represent the value. For data in which the length varies in a given area, there is the Min-Max-Length-Type. There have in the ODX specification, the minimum and the maximum bit length and end-labeling specify the data value. This is a typical description form for strings that are typically completed with 0 as the last byte. Some diagnostic services, the length of the body of the response message. Suitable for the Leading-Length-Info-Type. And finally there is the Param-Length-Info-Type. This is a data type for data whose length is described by another data value. That is, there is a data value that contains the length and another data value, which then contains the actual values. That is, for example, when storing the error memory common. You remember the message with which one could read the number of errors. The view is from ODX-a parameter, the error codes are then the associated data value.

Data types for DOPs (DIAG-CODED-TYPES)

Date Element Complex (Complex DOP)

Where insufficient simple data elements may also be used DOPs Complex. COMPLEX-DOPs of simple data objects are composite structures. They cover such uses where the nature and composition of the parameters can be determined only at run time. A typical application is the description of the fault memory. It consists of error codes and so-called freeze-frames (environmental data of the error).

With the multiplexer MUX elements, is ODX provides a way to implement within the ODX data, a kind of branching. This is useful, for example, if one has sent a data request and upon processing the response message of the PIDs contained in the answer must be. This can be achieved via a MUX element. The MUX element itself then branches to different simple DOPs or structures. Structures themselves may be simple, but they can also be repeated as arrays with a fixed or a dynamic number.

COMPLEX-DOPs of simple data objects are composite structures

Variantenidentifikation

ODX can handle different variants of a control unit. Because the same physical address (PHYSICAL-VEHICLE-LINK), can at run time, only one version can be active (BASE VARIANT or VARIANT ECU). Before an option can be selected, usually on the Diagnoselaufzeitsystem the respective base variant selected. Each control unit has an identification which describes the control device and its respective variants clearly. The runtime system sends a now or more diagnostic services (eg ReadECUIdentification) which defines the ECU-VARIANT PATTERN element of the ECU-VARIANT, and compares the responses from the control unit with the similarly configured there responses (MATCHING PARAMETERS). If they match, the variant was detected correctly. Normally, the runtime system now switches directly to this variant is, that it is not the basic version but the ECU variant selected.