Vehicle control device

Abstract

The invention provides a vehicle control device. A vehicle ECU is a control device for a vehicle provided with a CPU and a CAN controller, the CPU transmitting an instruction to execute fault diagnosis to the CAN controller, the CAN controller having a diagnosis buffer and a sequencer, the diagnosis buffer storing data relating to a request for fault diagnosis to a diagnosis target and data relating to a response from the diagnosis target. The sequencer is configured to read data from the diagnostic buffer in response to reception of an execution instruction, transmit a request for fault diagnosis to the ECU to be diagnosed, receive a response transmitted from the ECU to be diagnosed, perform diagnosis on the basis of the response, and transmit a result of the diagnosis to the CPU.

Description

Technical Field

[0001] The present invention relates to a control device for a vehicle. Background Art

[0002] For example, Japanese Patent Application Laid-Open No. 2016-061293 describes a device including a processor that processes input information and generates a failure prediction report for one or more movable parts. Summary of the Invention

[0003] In the conventional devices described above, the CPU processes code stored in flash memory, etc., to issue diagnostic requests and set diagnostic responses for fault diagnosis. However, with the increasing demand for software processed by the CPU, the CPU's processing load and memory usage are increasing, and there is a desire to reduce the burden on the CPU associated with fault diagnosis.

[0004] One embodiment of the present invention is a control device for a vehicle having a CPU and a CAN controller, wherein the CPU sends an execution instruction for fault diagnosis to the CAN controller, the CAN controller has a storage unit and a sequencer, the storage unit stores data related to a request for fault diagnosis of a diagnosis object and data related to a response from the diagnosis object, the sequencer operates according to the execution instruction, and the sequencer is configured to read data from the storage unit in response to the receipt of the execution instruction, send a request for fault diagnosis to the diagnosis object, receive a response sent from the diagnosis object in response to the request for fault diagnosis, perform diagnosis based on the received response, and send the diagnosis result to the CPU.

[0005] In a vehicle control device according to one embodiment of the present invention, the CPU sends a fault diagnosis execution instruction to a CAN controller. Upon receipt of the execution instruction, the CAN controller performs a diagnosis and transmits the diagnosis results to the CPU. The CPU can obtain the diagnosis results simply by sending the fault diagnosis execution instruction without performing any diagnostic processing. This reduces the CPU's processing load and memory usage compared to a system where the CPU itself performs diagnostic processing, alleviating the burden on the CPU associated with fault diagnosis.

[0006] In one embodiment, a storage unit may store request-related data and response-related data as multiple data frames, and a sequencer may select whether to send a fault diagnosis request to the object to be diagnosed or to perform a diagnosis based on the response based on the data contained in the data frames read from the storage unit. In this case, the sequencer can automatically switch its operation by sequentially reading the data frames.

[0007] In one embodiment, the sequencer may transmit data indicating the end of reading to the CPU after reading all the data contained in the data frames from the storage unit. In this case, the CPU can recognize that a series of diagnostics contained in the data frames has ended.

[0008] According to the present invention, the burden on the CPU associated with fault diagnosis can be reduced compared to a case where the CPU itself performs diagnostic processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Features, advantages, and technical and industrial significance of exemplary embodiments of the present invention will be described below with reference to the accompanying drawings, in which like symbols represent like elements, and wherein:

[0010] Figure 1 is a block diagram showing an example of the configuration of a vehicle control device according to an embodiment;

[0011] Figure 2 is a graph representing an example of a data frame;

[0012] Figure 3 This is a sequence diagram showing an example of diagnostic processing of a vehicle control device. DETAILED DESCRIPTION

[0013] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings.

[0014] Figure 1 FIG. 1 is a block diagram showing an example of the structure of a vehicle control device according to an embodiment. Figure 1 As shown, the vehicle ECU (Electronic Control Unit) 1 (vehicle control device) of this embodiment is an electronic control unit (microcomputer) installed in a vehicle such as a sedan. The vehicle ECU 1 is connected to various ECUs such as the transmission, ABS, doors, and actuators via a CAN bus 2, providing integrated vehicle control. The CAN bus 2 is a CAN (Controller Area Network) communication network within the vehicle that conducts data communications according to a predefined CAN communication protocol.

[0015] The diagnosis target ECU 3 is an ECU among these various ECUs that is the target of the fault diagnosis of the vehicle ECU 1. The vehicle ECU 1 may diagnose one diagnosis target ECU 3 or may diagnose a plurality of diagnosis target ECUs 3 in sequence.

[0016] The vehicle ECU 1 includes a CPU 11 (Central Processing Unit), a flash memory 12 (ROM) (Read Only Memory), and a RAM (Random Access Memory). In the vehicle ECU 1, various functions are implemented by loading programs stored in the flash memory 12 into the RAM, and then executing the programs in the RAM by the CPU 11. The vehicle ECU 1 may also be composed of multiple electronic units.

[0017] The vehicle ECU 1 includes a CAN controller 13. The CAN controller 13 provides an interface between the vehicle ECU 1 and the CAN bus 2. Based on instructions from the CPU 11, the CAN controller 13 communicates data with other ECUs, such as the diagnostic target ECU 3, in accordance with the CAN communication protocol. The CAN controller 13 has functions such as data transmission and reception and error detection. The CAN controller 13 can include, for example, a CAN transceiver or a CAN interface chip. Furthermore, as long as the CPU 11 and the CAN controller 13 are within the same chip, the protocol is not specifically limited, and signals can be transmitted via an insert or bus.

[0018] The CAN controller 13 includes a sequencer 20 and a diagnostic buffer (storage unit) 26 .

[0019] The sequencer 20 is a programmable logic controller (PLC) that operates according to various instructions from the CPU 11. The sequencer 20 is suitable for tasks requiring real-time response. The sequencer 20 operates according to fault diagnosis execution instructions from the CPU 11. The functional structure of the sequencer 20 is described below.

[0020] The diagnostic buffer 26 is a storage area for storing data used in fault diagnosis. It includes a non-volatile storage area. The diagnostic buffer 26 stores data related to fault diagnosis requests to the diagnostic target ECU 3 and data related to responses from the diagnostic target ECU 3. This data can also be written from factory equipment, for example, during vehicle or vehicle ECU 1 manufacturing.

[0021] These data are used to automatically perform multiple fault diagnoses. For example, the diagnostic buffer 26 stores data related to a fault diagnosis request to the ECU 3 to be diagnosed and data related to a response from the ECU 3 to be diagnosed as multiple data frames.

[0022] Figure 2 is a diagram showing an example of a data frame. Figure 2 As shown, the diagnostic buffer 26 can store data related to the request for fault diagnosis of the diagnostic target ECU 3 and data related to the response from the diagnostic target ECU 3 as a plurality of data frames corresponding to N-1 fault diagnoses. One data frame is equivalent to Figure 2 The data related to the fault diagnosis request can be set as CAN message data containing an ID corresponding to the type of the ECU 3 being diagnosed and data for fault diagnosis. The data related to the response can be set as CAN message data containing an ID corresponding to the type of the ECU 3 being diagnosed and an expected value as the response. The expected value is the value of the response sent by the ECU 3 being diagnosed after receiving the data for fault diagnosis, if the ECU 3 being diagnosed is normal.

[0023] exist Figure 2 In the example, a data frame includes data specifying whether it is a fault diagnosis request or a response, data specifying whether it is a request command to the ECU 3 being diagnosed or an expected value to be expected in response, and a waiting time. N-1 sets of these data frames are pre-set and used for N-1 consecutive fault diagnoses. The last N-th data frame is set to "NULL" to indicate that the N-1 fault diagnoses have concluded.

[0024] As a functional structure, the sequencer 20 includes a timer 21 , a buffer reader 22 , a buffer decoder 23 , a diagnostic transmitter 24 , and a diagnostic receiver 25 .

[0025] The timer 21 measures time using a counter generated by a clock provided in the CAN controller 13. The timer 21 begins operating, for example, upon receiving an instruction to execute fault diagnosis from the CPU 11. The timer 21 operates in synchronization with the clock provided in the CAN controller 13 and controls, for example, the timing of data read by the buffer reader 22. The timer 21 accurately manages the timing of CAN communications and synchronizes the sending and receiving of data. This prevents a reduction in the accuracy of processing time for executing fault diagnosis requests, such as those performed by the CAN controller 13. For example, unlike the CPU 11, accuracy can be ensured at the μsec (microsecond) level.

[0026] The buffer reader 22 reads data from the diagnostic buffer 26. The buffer reader 22 reads data from the diagnostic buffer 26 when the counter of the timer 21 reaches a predetermined count value. The predetermined count value is, for example, a "wait time" Nc set in the diagnostic buffer 26. Nc is an integer representing the predetermined count value.

[0027] The buffer reader 22 reads, for example, Figure 2 Multiple data frames are obtained by reading once until N-1 times Figure 2 The buffer reader 22 obtains the NULL value for the Nth time. The diagnostic buffer 26 is, for example, a ring buffer, and the buffer reader 22 may return to the first time after reading for the Nth time.

[0028] The buffer decoder 23 interprets the contents of the diagnostic buffer 26 (one line of data) it has read as either a "command" or an "expected value of a response" for this processing. If the buffer decoder 23 has read a "command," it transmits data related to a request for fault diagnosis of the ECU 3 being diagnosed to the diagnostic transmitter 24. If the buffer decoder 23 has read an "expected value," it transmits data corresponding to the expected value to the diagnostic receiver 25.

[0029] The diagnostic transmitter 24 is a transmitter for transmitting message data between the CAN controller 13 and the CAN bus 2. The diagnostic transmitter 24 issues a fault diagnosis (Diagnosis) transmission command to the CAN bus 2. Upon receiving the "command" from the buffer decoder 23, the diagnostic transmitter 24 issues a transmission command conforming to the CAN communication protocol to the CAN bus 2, transmitting data related to the received fault diagnosis request for the target ECU 3 to the target ECU 3.

[0030] The diagnostic receiver 25 is a receiver for receiving message data between the CAN controller 13 and the CAN bus 2. The diagnostic receiver 25 receives a fault diagnosis (diagnosis) response command from the CAN bus 2, performs a diagnosis based on the response received from the ECU 3 being diagnosed, and transmits the diagnostic results to the CPU 11. When the buffer decoder 23 reads the "expected value," the diagnostic receiver 25 compares the response received from the ECU 3 being diagnosed with the received expected value to determine whether they match, and obtains the comparison result as a "diagnostic result (OK or NG)." If the received response does not match the expected value, the diagnostic receiver 25 obtains the ID of the ECU 3 being diagnosed as the subject of the diagnosis as "error information (inconsistent ID)." The diagnostic receiver 25 transmits the diagnostic results and error information to the CPU 11.

[0031] If the buffer reader 22 obtains a NULL value as a result of the Nth read, the diagnostic receiver 25 may also send a completion message to the CPU 11 indicating that a NULL value has been received. The completion message is data indicating the completion of reading the data frame. The completion message may be different information (e.g., a different ID) than the information sent to the CPU 11 during each read from the first to the N-1th read by the buffer reader 22. The information sent to the CPU 11 during each read from the first to the N-1th read may include the number of remaining processes until the Nth read. Alternatively, the information may be pre-set so that a predetermined ID is sent and the CPU 11 recognizes, for example, that "if this ID is sent, three processes remain."

[0032] Processing of vehicle ECU1

[0033] Next, refer to Figure 3 , an example of the processing of the vehicle ECU 1 is described. Figure 3 This is a sequence diagram showing an example of diagnostic processing of a vehicle control device. Figure 3 The processing shown is executed at a predetermined diagnostic timing during the operation of the vehicle ECU 1 , for example.

[0034] like Figure 3 As shown, in S11 , in the vehicle ECU 1 , the CPU 11 transmits an instruction to execute the fault diagnosis to the CAN controller 13 .

[0035] In S12, the sequencer 20 of the CAN controller 13 counts the waiting time using the timer 21. In S13, the sequencer 20 reads the diagnostic buffer using the buffer reader 22. In S14, the sequencer 20 reads the "command" using the buffer decoder 23 and transmits data related to the fault diagnosis request to the ECU 3 to be diagnosed via the diagnostic transmitter 24.

[0036] In S15 , the diagnosed ECU 3 transmits response data based on the received data regarding the request for fault diagnosis.

[0037] In S16, the sequencer 20 reads the diagnostic buffer using the buffer reader 22. In S17, the sequencer 20 reads the "expected value" using the buffer decoder 23 and executes a diagnosis based on the expected value using the diagnostic receiver 25. In S18, the sequencer 20 transmits the diagnostic result to the CPU 11 via the diagnostic receiver 25.

[0038] In S19, the CPU 11 obtains the diagnosis result sent from the CAN controller 13. Then, the vehicle ECU 1 ends Figure 3The CPU 11 of the vehicle ECU 1 can repeatedly execute Figure 3 The processing continues until a completion message indicating that a NULL value has been received from the diagnostic receiver 25 is received.

[0039] As described above, in the vehicle ECU 1, the CPU 11 sends a fault diagnosis execution instruction to the CAN controller 13. Upon receipt of the execution instruction, the CAN controller 13 performs a diagnosis and transmits the diagnosis results to the CPU 11. The CPU 11 can obtain the diagnosis results simply by sending the fault diagnosis execution instruction without performing any diagnostic processing. This reduces the CPU 11's processing load and memory usage compared to a scenario where the CPU 11 performs diagnostic processing itself, thus alleviating the CPU burden associated with fault diagnosis.

[0040] In other words, the CAN controller 13 in the microcomputer 10 can autonomously perform "diagnostics" such as issuing requests, receiving responses, and making decisions without requiring software. Because the sequencer 20 performs diagnostics, the CPU 11 need not perform any processing. By actively hardware-handling routine processes like diagnostics, the sequencer 20 allows CPU 11 resources to be used for value-added purposes such as application programs.

[0041] In the above embodiment, the diagnostic buffer 26 stores request-related data and response-related data as multiple data frames. The sequencer 20 then selects, based on the data contained in the data frames read from the diagnostic buffer 26, whether to send a fault diagnosis request to the target ECU 3 or to perform a diagnosis based on the response from the target ECU 3. This allows the sequencer 20 to automatically switch its actions by sequentially reading data frames. Furthermore, by storing data in the diagnostic buffer 26 of the CAN controller 13, the amount of code flashed into the flash memory 12 can be reduced, thereby reducing the amount of RAM used by the CPU 11 during operations.

[0042] In the above embodiment, when the sequencer 20 has read all the data included in the data frame from the diagnostic buffer 26, it sends completion information indicating the end of reading to the CPU 11. This allows the CPU 11 to recognize that a series of diagnostics included in the data frame has been completed.

[0043] Although the embodiments of the present invention have been described above, the present invention is not limited to the above-described embodiments.

[0044] Although in the above embodiment, the diagnostic buffer 26 stores the request-related data and the response-related data as multiple data frames, the use of data frames is not essential. The request-related data and the response-related data may also be data used to perform separate fault diagnosis.

[0045] In the above embodiment, the sequencer 20 sends completion information indicating the end of reading to the CPU 11 when the data included in all the data frames are read from the diagnostic buffer 26, but the present invention is not limited to this example. Figure 2 The last N-th data may not be "NULL".

[0046] While the sequencer 20 performs all fault diagnoses in the above embodiment, this is not limiting. For example, the CPU 11 may be assigned to perform some diagnoses where time accuracy may be lower. For example, if more diagnoses than the CAN controller 13 can perform are required, the CPU 11 may be assigned to perform the diagnoses that cannot be performed by the CAN controller 13.

[0047] In addition, it can also be set that when it is suspected that an error has occurred in the diagnosed object ECU3 as a result of the diagnosis of the CAN controller 13, a diagnostic code for diagnosing the content of the error in more detail (for example, whether it is a power short circuit or a ground fault, etc.) is prepared in advance in the flash memory 12 and executed by the CPU 11.

Claims

1. A vehicle control device comprising a CPU and a CAN controller, wherein: The CPU sends a fault diagnosis execution instruction to the CAN controller, The CAN controller includes a storage unit and a sequencer. The storage unit stores data related to the fault diagnosis request to the diagnosis object and data related to the response from the diagnosis object. The sequencer operates according to the execution instruction. The sequencer is configured to read the data from the storage unit in response to receipt of the execution instruction, send the fault diagnosis request to the diagnosis object, receive a response sent from the diagnosis object in response to the fault diagnosis request, perform diagnosis based on the received response, and send the diagnosis result to the CPU.

2. The vehicle control device according to claim 1, wherein: The storage unit stores the data related to the request and the data related to the response as a plurality of data frames respectively. The sequencer selects whether to transmit the fault diagnosis request to the diagnosis target or to perform diagnosis based on the response based on the data included in the data frame read from the storage unit.

3. The vehicle control device according to claim 2, wherein: When the sequencer has read the data included in all the data frames from the storage unit, the sequencer transmits data indicating completion of reading to the CPU.

Images