FUNCTION DICTIONARY

The idea of ​​function-based diagnosis is to abstract the diagnosis. Away from the diagnostic services of individual control units, ie the communications protocol-oriented view of functions, to the user's perspective.

The most important features are summarized below:

• Function-oriented diagnosis: Abstract view on the diagnosis

• Not the controller, but the function is considered

• At a function can be involved in several SG

• Example of the exterior lighting:

  • Function: Lamp test (all lights on and off)
  • BCM front (ECU)
  • BCM rear (ECU)
  • Instrument system (controller, switch)

• User sees only the function; Do not know what SG is sent to which service to turn on and off

• Functions are organized in FUNCTION NODES and FUNCTION-NODE-GROUPS with any tree depth

• About references to executable services (Executable), the connections to the individual SG produced

• But: The FUNCTION DICTIONARY can map any Workflow!

In the function-oriented diagnosis, the user should no longer with the various diagnostic services such as the lamp test must address. He knows only the "lamp test". About the ODX-parameterization in the FUNCTION DICTIONARY know the diagnostic run-time system, which services must be called.

Within the function-oriented diagnostic functions in so-called function nodes and be combined in groups of functional nodes. These do have references to the individual control units and the necessary diagnostic services on there. In a way, multiple-ECU-Jobs are on one side and the function-based diagnosis on the other hand, related, for in both cases one can perform diagnostic tasks across multiple control units. The FUNCTION DICTIONARY allowed, however, a well-defined and formalized description of such services and is in contrast to Java code reliably. However, no processes are ready to buy it. The later is for the format described for test sequences OTX (Open Test sequence eXchange).

Function-oriented diagnosis FUNCTION DICTIONARY