Diagnostic procedures

Abstract

Diagnostic method for diagnosing functional units designed as control units, in particular of a motor vehicle, wherein a diagnostic device can be connected to a functional unit, wherein diagnostic-relevant requirements are assigned to the functional unit(s), wherein the requirements are generated from an information technology description of the control unit of the functional unit and are compared with external data.

Description

[0001] The invention relates to a diagnostic method, in particular for functional units of a motor vehicle.

[0002] Motor vehicles have a multitude of electronically controlled functional units, some of which also communicate with each other. Such functional units include, for example, control units, actuators, or sensors, etc. Various vehicle functions are controlled by these functional units. An external diagnostic control unit can be used to diagnose the functional units, to which the functional unit to be tested must be connected. The diagnostic control unit can be connected to a vehicle, with the respective functional units connected, for example, via a data bus.

[0003] Error codes can be read out as so-called event data stored in the functional unit. Measured values ​​for status detection stored in the functional unit can also be read out. Furthermore, control routines can be transmitted, which can be used to control the functional unit.

[0004] The requirements for the diagnostic procedure and the diagnostic control unit vary for each vehicle or each functional unit. This leads to additional effort in creating and performing the diagnosis.

[0005] It is the object of the present invention to create a diagnostic method which enables an adapted effort.

[0006] The problem is solved with the features of claim 1.

[0007] An embodiment of the invention relates to a diagnostic method for diagnosing functional units, in particular of a motor vehicle, wherein a diagnostic device can be connected to a functional unit, wherein diagnosis-relevant requirements are assigned to the functional unit(s), wherein the requirements are generated from an information technology description of the control unit and compared with external data.

[0008] It is advantageous if one requirement is that an event memory entry is made in the event of an error or failure of a functional unit.

[0009] Another useful requirement is that a functional unit supports installation-relevant identifications.

[0010] A further advantage has been shown to be that a functional unit can be controlled via commands, such as input / output commands.

[0011] It is also advantageous if a functional unit is an actuator, a sensor or a control unit.

[0012] The invention is explained in detail below using an exemplary embodiment with reference to the drawing. The drawing shows: Fig. 1 a schematic representation of a motor vehicle with a diagnostic control unit, Fig. 2 a block diagram, and Fig. 3 a block diagram.

[0013] The Fig. Figure 1 shows a representation of a motor vehicle 1 with various indicated functional units 2, 3 that are connected to a diagnostic control unit 5 via a data or signal connection. The control unit diagnosis performed by a diagnostic control unit 5 uses, among other things, the following functions: • Reading identifications, e.g. a part number or a software version • Reading out measured values, e.g. for status recording of a sensor or actuator as a functional unit • Reading event data, e.g. error codes to identify defective parts • Execution of routines or actuator controls, e.g. to control an actuator such as a stepper motor as a functional unit.

[0014] The functional contents are exchanged by means of diagnostic communication between the motor vehicle 1 and the diagnostic control unit 5.

[0015] Different requirements can be placed on the functional scope of the control unit diagnosis: • Error codes: A defective sensor or actuator as a functional unit requires at least one error code. • Measured values: A sensor or actuator as a functional unit requires at least one measured value to record its status. • Routines: An actuator requires at least one routine for control.

[0016] In Fig. Figure 2 illustrates a diagnostic analysis of a control unit as a complete system, including peripheral sensors / actuators and wiring harness. Blocks 10 at the edge depict the diagnostic activities based on actions related to the centrally displayed control unit 11. For example, an error log entry is made if the GPS system antenna is not installed or is defective (see block 12). The other blocks describe other actions for corresponding errors.

[0017] The diagnostic requests can be generated automatically if an IT description of the ECU topology is available. Accordingly, diagnostic requests for the ECU implementation can be generated automatically using the IT description of an ECU system.

[0018] These requirements may include, for example, the following: • Identifications, • Measured values, • Event codes, • Routines, • Actuator controls, • Configurations, • Wiring harness, and / or • Networking hierarchy.

[0019] To model an ECU system, sensors and / or actuators are assigned diagnostic elements such as measured values, control routines, event log entries, and / or identifications. Requirements are formulated for this purpose, such as: - in case of failure of a sensor / actuator, an event log entry must be stored, - Sensors / actuators connected to a communication bus must support installation-relevant identification, - Actuators must be able to be controlled via input / output control routines.

[0020] These requirements can be tracked and compared with external data. The hardware-oriented description of control units (ECUs) implicitly creates diagnostic requirements. These requirements, modeled by function managers, can then be specified in more detail in diagnostic data. For this purpose, the submodels of an ECU, sensor, or actuator contain pre-initialized diagnostic elements that can be further specified as needed. For diagnostics, a view of the hardware topology is advantageously used, from which conclusions can be drawn about the required diagnostic elements.

[0021] The Fig. 3 shows a modeling of the block diagram according to Fig.2. The modeling example shows the diagnostic master PCM 20 and the slaves TV 21 and DVD 22. The representation is shown in a network diagram. The diagnostic content created and further described during modeling can be saved in a file that can be further imported and / or edited.

Claims

[1] Diagnostic method for diagnosing functional units designed as control units, in particular of a motor vehicle, wherein a diagnostic device can be connected to a functional unit, wherein diagnosis-relevant requirements are assigned to the functional unit or units, wherein the requirements are generated from an information technology description of the control unit of the functional unit and are compared with external data. [2] Diagnostic method according to claim 1, characterized by that a requirement is that an event memory entry is made in the event of an error or failure of a functional unit. [3] Diagnostic method according to claim 1 or 2, characterized by that one requirement is that a functional unit supports identifications, especially those relevant to installation. [4] Diagnostic method according to claim 1 or 2, characterized bythat one requirement is that a functional unit can be controlled via commands, in particular input / output commands. [5] Diagnostic method according to one of the preceding claims, characterized by that a functional unit is an actuator, a sensor or a control unit.

Images