METHOD FOR DIAGNOSING A VEHICLE ELECTRICAL SYSTEM OF A VEHICLE

Abstract

A method for diagnosing a vehicle electrical system of a vehicle including a plurality of intercommunicating arithmetic logic units. A diagnostic application is executed on one arithmetic logic unit of the plurality of arithmetic logic units. The diagnostic application receives a diagnostic inquiry from an external diagnostic unit. The diagnostic inquiry is analyzed by the diagnostic application. Based on the content of the diagnostic inquiry, the diagnostic application sends data to at least one arithmetic logic unit and/or sends a diagnostic response to the external diagnostic unit.

Claims

1. A method for diagnosing a vehicle electrical system of a vehicle including a plurality of intercommunicating arithmetic logic units, the method comprising the following steps: executing a diagnostic application on one arithmetic logic unit of the plurality of arithmetic logic units; receiving, by the diagnostic application, a diagnostic inquiry from an external diagnostic unit; analyzing, by the diagnostic application, the diagnostic inquiry; and based on a content of the diagnostic inquiry: (i) sending data by the diagnostic application to at least one of the arithmetic logic units, and/or (ii) sending a diagnostic response to the external diagnostic unit.

2. The method as recited in claim 1, wherein the analysis of the diagnostic inquiry includes determining at least one arithmetic logic unit, of the plurality of arithmetic logic units, that is addressed in the diagnostic inquiry, and wherein communication with the at least one addressed arithmetic logic unit is carried out from the diagnostic application.

3. The method as recited in claim 1, wherein, when the diagnostic inquiry includes a service message that addresses at least one arithmetic logic unit, of the plurality of arithmetic logic units, from which diagnostic data are to be read out and/or to which diagnostic data are to be delivered, the diagnostic application relays the service message or the diagnostic data to the at least one addressed arithmetic logic unit and/or sends diagnostic data concerning the at least one addressed arithmetic logic unit to the external diagnostic unit as a part of the diagnostic response.

4. The method as recited in claim 3, wherein the diagnostic application receives the diagnostic data from the at least one addressed arithmetic logic unit and sends the diagnostic data to the external diagnostic unit as a part of the diagnostic response.

5. The method as recited in claim 3, wherein the diagnostic application analyzes data and/or signals exchanged between the plurality of arithmetic logic units and generates expanded diagnostic information based on the data and/or signals exchanges, and wherein the diagnostic data are determined based on the expanded diagnostic information and are sent to the external diagnostic unit as a part of the diagnostic response.

6. The method as recited in claim 5, wherein, independently of a timing of a diagnostic inquiry, the diagnostic application analyzes the data and/or signals exchanged between the plurality of arithmetic logic units and generates the expanded diagnostic information based on the data and/or signals exchanged.

7. The method as recited in claim 1, wherein, when the diagnostic inquiry includes a control message that addresses at least one arithmetic logic unit, of the plurality of arithmetic logic units, that is to be put into a predetermined state, the diagnostic application relays the control message to the at least one addressed arithmetic logic unit and/or puts the at least one addressed arithmetic logic unit into the predetermined state.

8. The method as recited in claim 1, wherein, when the diagnostic inquiry includes a programming message that addresses precisely one arithmetic logic unit, of the plurality of arithmetic logic units, to which program data are to be written and/or from which program data are to be read, the diagnostic application: (i) relays, to the addressed arithmetic logic unit, the programming message or program data to be written, and/or (ii) receives program data from the addressed arithmetic logic unit, and sends the program data to the external diagnostic unit as a part of the diagnostic response.

9. The method as recited in claim 8, wherein the arithmetic logic unit that is addressed is determined based on system information, and wherein the system information is in particular initially and/or repeatedly stored in the diagnostic application.

10. The method as recited in claim 9, wherein the system information is determined or generated dynamically by reading out the plurality of arithmetic logic units.

11. The method as recited in claim 1, wherein the diagnostic inquiry is received by the diagnostic application by way of a first protocol, and data are sent to the at least one arithmetic logic unit by way of a second protocol that is different from the first protocol.

12. The method as recited in claim 1, wherein the plurality of arithmetic logic units are selected from: main vehicle computers, vehicle controllers, actuators, and sensors.

13. An arithmetic logic unit configured to diagnose a vehicle electrical system of a vehicle including a plurality of intercommunicating arithmetic logic units, the plurality of intercommunicating arithmetic logic units including the arithmetic logic unit, the arithmetic unit configured to: execute a diagnostic application on the arithmetic logic unit; receive, by the diagnostic application, a diagnostic inquiry from an external diagnostic unit; analyze, by the diagnostic application, the diagnostic inquiry; and based on a content of the diagnostic inquiry: (i) send data by the diagnostic application to at least one arithmetic logic unit, and/or (ii) send a diagnostic response to the external diagnostic unit.

14. A vehicle electrical system of a vehicle, comprising: a plurality of intercommunicating arithmetic logic units, of which one arithmetic logic unit is configured to diagnose the vehicle electrical system, the one arithmetic unit configured to: execute a diagnostic application on the one arithmetic logic unit; receive, by the diagnostic application, a diagnostic inquiry from an external diagnostic unit; analyze, by the diagnostic application, the diagnostic inquiry; and based on a content of the diagnostic inquiry: (i) send data by the diagnostic application to at least one arithmetic logic unit, and/or (ii) send a diagnostic response to the external diagnostic unit.

15. A non-transitory machine-readable storage medium on which is stored a computer program for diagnosing a vehicle electrical system of a vehicle including a plurality of intercommunicating arithmetic logic units, the computer program, when executed by an arithmetic logic unit of the arithmetic logic units, causing the arithmetic logic unit to perform the following steps: executing a diagnostic application on the arithmetic logic unit; receiving, by the diagnostic application, a diagnostic inquiry from an external diagnostic unit; analyzing, by the diagnostic application, the diagnostic inquiry; and based on a content of the diagnostic inquiry: (i) sending data by the diagnostic application to at least one of the arithmetic logic units, and/or (ii) sending a diagnostic response to the external diagnostic unit.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0029] FIG. 1 schematically shows a vehicle electrical system according to an example embodiment of the present invention in a preferred configuration in a vehicle.

[0030] FIGS. 2 to 5 schematically show a sequence of a method according to the present invention in a preferred specific embodiment.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

[0031] FIG. 1 schematically shows a vehicle electrical system 101 according to the present invention in a preferred configuration in a vehicle 100, in which diagnostics proposed in the context of the present invention can be carried out. By way of example, the vehicle electrical system 101 comprises a main vehicle computer 110, two vehicle controllers 120, and a plurality of actuators and sensors 130 (here, no distinction is to be drawn between actuators and sensors).

[0032] In this connection, these are arithmetic logic units that intercommunicate, for example by way of one or more communications media 112. Said media need not necessarily be the same for all the links between arithmetic logic units; it is possible for there to be a difference depending on the type of arithmetic logic unit or of arithmetic logic units to be linked. For instance, simpler sensors are coupled merely via LIN, for example, while more complex controllers are coupled via CAN or Ethernet, for example.

[0033] By way of example, a diagnostic application 114 (also referred to as system diagnostic software) is executed on the arithmetic logic unit 110 formed as the main vehicle computer. Furthermore, a diagnostic unit 150 (also referred to as a diagnostic tester or a tester) that is external, i.e., does not belong to the vehicle electrical system or vehicle, is shown next to the vehicle 100. Said diagnostic unit is connected to the vehicle electrical system 101, in particular the main vehicle computer 110, via a suitable communications link. By way of example, a so-called “OBD interface” can be used for this purpose. In this case, the diagnostic unit 150 communicates only with the diagnostic application 114 on the main vehicle computer, not with the other arithmetic logic units.

[0034] FIG. 2 now shows an overview of the sequence of a method according to the present invention in a preferred specific embodiment, i.e., the sequence of diagnostics in the vehicle electrical system, as shown for example in FIG. 1, or in particular of the individual arithmetic logic units therein.

[0035] First, the functioning of the diagnostic application will be described. When the diagnostic application communicates with the diagnostic unit or the arithmetic logic units or controllers of the vehicle electrical system, the standard “Unified Diagnostic Services” (UDS) as defined in the ISO 14229-1:2020 standard is used as the diagnostic protocol, for example. The diagnostic application can, however, also use alternative protocols for communicating with the arithmetic logic units. In that case, the diagnostic application translates the messages from the tester into the other protocol or vice versa.

[0036] The “Universal Measurement and Calibration Protocol” (XCP) as defined in the ASAM MCD-1 standard, which is generally frequently used in controller development, is taken into consideration as a protocol variant, for example as an alternative standard, for example for reprogramming. A proprietary protocol defined and deployed accordingly can also be used as another protocol variant. In that case, the protocol would not need to be disclosed (it is used only for the communication between the diagnostic application and the arithmetic logic units in the vehicle electrical system, not for the communication between the diagnostic application and the tester), as a result of which the arithmetic logic units or controllers would be more securely protected by standard tools against attacks.

[0037] During the diagnostics, the tester is then first connected to the vehicle electrical system such that communication with the diagnostic application is possible. The tester then sends a diagnostic inquiry (request) 200 to the diagnostic application, which receives it. This diagnostic inquiry 200 can comprise various kinds of messages, specifically, for example, a service message 210, a control message 220, or a programming message 230. These messages from the tester can then, for example, be relayed to one or more arithmetic logic units in the vehicle electrical system.

[0038] For this kind of relaying, different variants can be used. One variant is message-based; in this case, the diagnostic application always first receives the entire message before relaying it to an arithmetic logic unit. Another variant is frame-based; in this case, a message is transmitted in segmented form, as is the case, for example, in DoCAN (“Diagnostic communication over Controller Area Network”), as per the ISO 15765-2:2016-04 standard. The message can also be relayed frame by frame after each received frame.

[0039] Next, the superordinate sequence of the diagnostics, as shown in FIG. 2 and already briefly explained, will be discussed in more detail. At the start of the program sequence in the diagnostic application, system information 211, 221, 231 is used in a step 250, in particular depending on the various types of messages.

[0040] These messages can include data from all the arithmetic logic units that make diagnostic information (e.g., DTC, DID) available (as sources). In the process, a controller, actuator, sensor, or the diagnostic application itself (and the arithmetic logic unit on which it is executed) can be taken into consideration as an arithmetic logic unit or source.

[0041] The system information can be generated by different variants. One option is static generation. In this case, the system information is stored in the diagnostic application statically and is updated in the event of a change to the software in a controller.

[0042] Another option is generation by learning. In this case, the diagnostic application learns the system information by reading out the arithmetic logic units or sources of the vehicle electrical system, e.g., in the event of a software update in the vehicle electrical system. This has the advantage whereby the diagnostic application need not necessarily be updated after a change to the software of a controller.

[0043] In the next steps 212, 222, 232, in which the messages 210, 220 and 230 are processed, use is made of the system information. If the diagnostic application receives a message containing the diagnostic inquiry 200 from the tester, said inquiry is first characterized in step 202, for example on the basis of Service Identification (SID), and delivered to a step 212, 222, or 232 depending on the type.

[0044] In the process, and as mentioned, the messages are split into the following types. A service message 210 is a message in which diagnostic information (or diagnostic data) are read from or delivered to the vehicle electrical system or arithmetic logic units (hereinafter also referred to simply as the “system”). In UDS, these are, for example, “ReadDataByldentifier,” “InputOutputControlByIdentifier,” or “ReadDTCInformation.”

[0045] A control message 220 is a message in which the system or a particular arithmetic logic unit is to be put into a particular state. In UDS, these are, for example, “SessionControl,” “Authentication,” or “ControlDTCSetting.” Different services can thus be activated in an arithmetic logic unit, for example. A programming message 230 is a message used directly for writing or reading the controller software (program data). In UDS, these are, for example, “RequestDownload,” “TransferData,” or “RequestTransferExit.” However, these can also include special routines, for example for erasing or reviewing a memory area.

[0046] According to the type of message, a step or action is then carried out in which a response is obtained where applicable (for example if the message is relayed to an arithmetic logic unit, which then returns a response) and is then sent back to the tester in or as a part of a diagnostic response 240. This completes a run-through of this path. The arrival of a new message starts it again from the beginning.

[0047] If the diagnostic application receives an update to the internal data from the system, for example via normal communication, the updated data are delivered to the block 260. In this block, the expanded diagnostic information is then generated. This information can be queried when a message 210 arrives. This completes this path. The arrival of a new update starts it again from the beginning.

[0048] FIG. 3 illustrates the handling of a service message 210 in more detail. If the system information 211 and a service message 210 are applied to the inputs of step 212, the following activity is carried out. In step 300, on the basis of the identification of the service message, of a possible sub-function, and of one or more pieces of diagnostic information, it is determined which sources (arithmetic logic units) are making them available (the system information is used for this purpose). The result is then also the source type 302 and thus how the message has to be relayed to the controllers or arithmetic logic units.

[0049] The type of source can be a system source 310. Each controller and the diagnostic application are sources for the requested information. In step 312, the message is functionally relayed to all the controllers. In addition, the diagnostic application queries the information internally.

[0050] The type of source can be a multi-source 320 (a plurality of sources). A plurality of controllers (but not necessarily all the controllers) and/or the diagnostic application are sources for the requested information. In step 322, the message is physically relayed to any controller identified as a source (or addressed as such). In the process, before being relayed the message can be divided up according to the requested diagnostic information, such that each source can only request the information it has made available. If the diagnostic application is one of the sources, the diagnostic application queries the corresponding information internally.

[0051] The type of source can also be a single source 330. A controller or the diagnostic application is the source for the requested information. In step 332, either the message is physically relayed to the controller identified as the source or the diagnostic application queries the information internally.

[0052] In step 340, the responses of the sources are collected and merged into one response 342. This response is delivered to the superordinate sequence via the output and is thus in particular sent to the diagnostic unit as a part of the diagnostic response.

[0053] FIG. 4 illustrates the handling of a control message 220 in more detail. If the system information 211 and a control message 220 are applied to the inputs of step 222, the following activity is carried out. In step 400, on the (sole) basis of the identification of the control message, the relaying type 402 thereof is determined, i.e., whether it is relayed directly to all the controllers or there is a special handling.

[0054] In the event that no direct relaying is provided, there is a special handling or action 410 for the control message. These messages include “SecurityAccess,” “Authentication,” and “TesterPresent.” Optionally, the latter can also be relayed.

[0055] In the first two control messages, information for security mechanisms is transmitted, for example, and additional functions are made accessible on the basis thereof. These mechanisms can be implemented differently in each controller, so there cannot be any direct relaying here. In this case, the diagnostic application should know the mechanisms in each controller and communicate with the controllers accordingly. From the responses thereof, the diagnostic application then generates the final response to the external tester.

[0056] “TesterPresent” is, for example, a piece of information for the diagnostic application according to which it is to remain in a previously controlled state. Since each controller is also in this state, the controllers likewise have to be kept therein. This can be done by relaying the inquiry and also by periodically forwarding the message to the controllers discretely, independently of an inquiry from the tester.

[0057] If the special handling 410 is carried out, the response 430 is delivered to the superordinate sequence via the output.

[0058] In the case of a system source, in step 420 the message is functionally relayed to all the controllers. In step 425, the responses are collected and merged into the response 430. This response is delivered to the superordinate sequence via the output.

[0059] FIG. 5 illustrates the handling of a programming message 230 in more detail. If the system information 231 and a programming message 230 are applied to the inputs of step 232, the following activity is carried out. In step 500, the controller to which the message is relayed is determined on the basis of address information in said message.

[0060] In step 510, the message is physically relayed to the target controller. In step 520, the response is received and delivered to the superordinate sequence via the output.

[0061] Overall, diagnostics of a vehicle electrical system in a vehicle comprising a multiplicity of arithmetic logic units or controllers in which the tester communicates only with the diagnostic application are therefore made possible. The communication with the arithmetic logic units in the vehicle electrical system occurs via the diagnostic application and can therefore be carried out independently of the tester in terms of, for example, the communications protocol to be used or the selection of messages that are then actually relayed.