Vehicle control device

Abstract

To provide a vehicle control device capable of reducing the load on a CPU associated with failure diagnosis as compared with a case where the CPU itself performs the diagnostic processing.SOLUTION: A vehicle ECU 1 is a vehicle control device including a CPU 11 and a CAN controller 13. The CPU 11 transmits an execution instruction for failure diagnosis to the CAN controller 13. The CAN controller 13 includes: a diagnostic buffer 26 that stores data related to a failure diagnosis request for a diagnostic target and data related to a response from the diagnostic target; and a sequencer 20 that operates in response to the execution instruction. The sequencer 20 reads data from the diagnostic buffer 26 upon receiving the execution instruction, transmits the failure diagnosis request to a diagnostic target ECU 3, receives a response transmitted from the diagnostic target ECU 3 in response to the failure diagnosis request, performs diagnosis on the basis of the received response, and transmits a diagnostic result to the CPU 11.SELECTED DRAWING: Figure 1

Description

[Technical Field]

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

[0002] For example, Patent Document 1 describes an apparatus that includes a processor that processes input information and generates a failure prediction report for one or more moving parts. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2016-061293 Summary of the Invention [Problem to be solved by the invention]

[0004] In devices such as those of the above-described conventional technology, the issuance of a diagnosis request for fault diagnosis and the setting of a diagnosis response are executed by a CPU based on code stored in a flash memory, etc. However, in recent years, with the demand for an expansion of the software processed by the CPU, the processing load on the CPU and the amount of memory used tend to increase, and it is desirable to reduce the burden on the CPU associated with fault diagnosis. [Means for solving the problem]

[0005] One aspect of the present invention is a vehicle control device that includes a CPU and a CAN controller, in which the CPU sends an instruction to execute a fault diagnosis to the CAN controller, and the CAN controller has a storage unit that stores data regarding a request for a fault diagnosis for the object to be diagnosed and data regarding a response from the object to be diagnosed, and a sequencer that operates in response to the execution instruction, and the sequencer is configured to read data from the storage unit in response to receiving the execution instruction, send a request for a fault diagnosis to the object to be diagnosed, receive a response sent from the object to be diagnosed in response to the request for fault diagnosis, perform a diagnosis based on the received response, and send the results of the diagnosis to the CPU.

[0006] In a vehicle control device according to one aspect of the present invention, a CPU transmits a fault diagnosis execution instruction to a CAN controller, and the CAN controller performs the diagnosis based on the received execution instruction and transmits the diagnosis results to the CPU. The CPU can obtain the diagnosis results without performing the diagnostic process by simply transmitting the fault diagnosis execution instruction. This reduces the CPU processing load and memory usage compared to when the CPU itself performs the diagnostic process, thereby reducing the burden on the CPU associated with the fault diagnosis.

[0007] In one embodiment, the storage unit may store request data and response data as multiple data frames, and the sequencer may select whether to send a 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. In this case, the sequencer can automatically switch its operation by sequentially reading the data frames.

[0008] In one embodiment, when the sequencer has read all of the data included in the data frame from the storage unit, it may send data indicating the end of reading to the CPU, allowing the CPU to recognize that the series of diagnoses included in the data frame has ended. [Effects of the Invention]

[0009] According to the present invention, it is possible to reduce the load on the CPU associated with fault diagnosis compared to when the CPU itself performs the diagnosis process. [Brief explanation of the drawings]

[0010] [Figure 1] 1 is a block diagram showing an example of the configuration of a control device for a vehicle according to an embodiment; [Figure 2] FIG. 2 is a diagram illustrating an example of a data frame. [Figure 3] FIG. 4 is a sequence diagram illustrating an example of a diagnostic process for a control device of a vehicle. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0012] Fig. 1 is a block diagram showing an example of the configuration of a vehicle control device according to an embodiment. As shown in Fig. 1, a vehicle ECU (Electronic Control Unit) 1 (vehicle control device) according to this embodiment is an electronic control unit (microcomputer) mounted on a vehicle such as a passenger car. The vehicle ECU 1 is connected to various ECUs, such as those for the transmission, ABS, doors, and actuators, via a CAN bus 2, and performs integrated control of the vehicle. The CAN bus 2 is a CAN (Controller Area Network) communication network within the vehicle that performs data communication according to a predetermined CAN communication protocol.

[0013] The diagnosis target ECU 3 is one of these various ECUs that is the target of failure diagnosis for 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 sequentially.

[0014] The vehicle ECU 1 includes a CPU 11 (Central Processing Unit), a flash memory 12 serving as a ROM (Read Only Memory), and a RAM (Random Access Memory). For example, the vehicle ECU 1 loads a program stored in the flash memory 12 into the RAM and executes the program loaded into the RAM with the CPU 11, thereby realizing various functions. The vehicle ECU 1 may be composed of multiple electronic units.

[0015] The vehicle ECU 1 includes a CAN controller 13. The CAN controller 13 is a device that provides an interface between the vehicle ECU 1 and the CAN bus 2. Based on commands from the CPU 11, the CAN controller 13 performs data communication with other ECUs, such as the ECU 3 to be diagnosed, in accordance with the CAN communication protocol. The CAN controller 13 has functions such as data transmission and reception and error detection. For example, a CAN transceiver, a CAN interface chip, or the like may be used as the CAN controller 13. Note that, between the CPU 11 and the CAN controller 13, there are no particular limitations on the protocol as long as they are within the same chip, and signals can be transmitted via interrupts, a bus, or the like.

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

[0017] The sequencer 20 is a programmable logic controller (PLC) that operates in response to various instructions from the CPU 11. The sequencer 20 is suitable for tasks that require a real-time response. The sequencer 20 operates in response to an instruction from the CPU 11 to execute a fault diagnosis. The functional configuration of the sequencer 20 will be described later.

[0018] The diagnostic buffer 26 is a memory area for storing data used in fault diagnosis. The diagnostic buffer 26 includes a non-volatile memory area. The diagnostic buffer 26 stores data related to a request for fault diagnosis of the diagnosis target ECU 3, which is the target of diagnosis, and data related to a response from the diagnosis target ECU 3. These data may be written from factory equipment, for example, during the manufacture of the vehicle or the vehicle ECU 1.

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

[0020] FIG. 2 is a diagram illustrating an example of a data frame. As illustrated in FIG. 2, the diagnostic buffer 26 may store data related to a request for fault diagnosis of the ECU 3 to be diagnosed and data related to a response from the ECU 3 to be diagnosed as a plurality of data frames corresponding to N-1 fault diagnoses. One data frame corresponds to one row of the table in FIG. 2. The data related to the request for fault diagnosis may be CAN message data including an ID corresponding to the type of the ECU 3 to be diagnosed and data for the fault diagnosis. The data related to the response may be CAN message data including an ID corresponding to the type of the ECU 3 to be diagnosed and an expected value expected as a response. The expected value refers to a response value sent by the ECU 3 to be diagnosed after receiving the data for fault diagnosis when the ECU 3 to be diagnosed is normal.

[0021] In the example of FIG. 2, one data frame includes data specifying "whether it is a request or a response to a fault diagnosis," data specifying "whether it is a command to cause the ECU 3 to send a request or an expected value to be expected as a response," and a wait time. N-1 sets of such data frames are set in advance and are used for N-1 consecutive fault diagnoses. The last Nth data is set to "NULL" to indicate that the N-1th fault diagnose has been completed.

[0022] The sequencer 20 includes a timer 21, a buffer reader 22, a buffer decoder 23, a diagnostic transfer 24, and a diagnostic receiver 25 as functional components.

[0023] The timer 21 measures time using a counter generated by a clock provided in the CAN controller 13. The timer 21 starts operating, for example, when it receives an instruction to perform fault diagnosis from the CPU 11. The timer 21 operates in synchronization with the clock provided in the CAN controller 13 and controls the timing of data read by the buffer reader 22, etc. The timer 21 plays a role in accurately managing the timing of CAN communication and synchronizing data transmission and reception. This makes it possible to prevent a decrease in the accuracy of the processing time required to perform, for example, the transmission of a fault diagnosis request during fault diagnosis by the CAN controller 13. For example, unlike the CPU 11, it is possible to ensure accuracy on the order of μsec.

[0024] The buffer reader 22 reads data from the diagnostic buffer 26. When the counter of the timer 21 reaches a predetermined counter number, the buffer reader 22 reads data from the diagnostic buffer 26. The predetermined counter number is, for example, Nc, the "wait time" set in the diagnostic buffer 26. Nc is an integer that represents the predetermined counter number.

[0025] 2, for example, and obtains one row of data in the table of FIG. 2 in each read up to N-1 times. In the Nth read, buffer reader 22 obtains a NULL value. Diagnostic buffer 26 is, for example, a ring buffer, and buffer reader 22 may return to the first read after the Nth read.

[0026] The buffer decoder 23 interprets the current process as a "command" or an "expected response value" based on the contents (one line of data) of the diagnostic buffer 26 that have been read out. When the current "command" is read, the buffer decoder 23 transmits data relating to a request for a fault diagnosis of the ECU 3 to be diagnosed to the diagnostic transfer 24. When the "expected value" is read this time, the buffer decoder 23 transmits the expected value data to the diagnostic receiver 25 as a response.

[0027] The diagnostic transfer 24 is a transmitter for transmitting message data between the CAN controller 13 and the CAN bus 2. The diagnostic transfer 24 issues a transmission command for fault diagnosis (diagnosis) to the CAN bus 2. When the buffer decoder 23 reads out a "command," the diagnostic transfer 24 issues a transmission command conforming to the CAN communication protocol to the CAN bus 2 so as to transmit data relating to the received request for fault diagnosis of the ECU 3 to be diagnosed.

[0028] 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 diagnosis target ECU 3, and transmits the diagnosis result to the CPU 11. When the "expected value" is read by the buffer decoder 23, the diagnostic receiver 25 compares whether the response received from the diagnosis target ECU 3 matches the received expected value, and obtains the comparison result as a "diagnosis result (OK or NG)." When the received response does not match the expected value, the diagnostic receiver 25 obtains the ID of the diagnosis target ECU 3 that was the subject of the diagnosis as "error information (mismatched ID)." The diagnostic receiver 25 transmits the diagnosis result and the error information to the CPU 11.

[0029] When the buffer reader 22 acquires a NULL value as a result of the Nth read, the diagnostic receiver 25 may transmit completion information indicating that the NULL value was received to the CPU 11. The completion information is data indicating the completion of reading the data frame. The completion information may be information (e.g., a different ID) different from the information transmitted to the CPU 11 for each of the 1st to N-1th reads by the buffer reader 22. The information transmitted to the CPU 11 for each of the 1st to N-1th reads may include the number of processes remaining up to the Nth read. Alternatively, the completion information may be information preset such that a predetermined ID is transmitted and the CPU 11 recognizes, for example, that "when this ID is received, there are three processes remaining."

[0030] [Vehicle ECU1 processing] Next, an example of the processing of the vehicle ECU 1 will be described with reference to Fig. 3. Fig. 3 is a sequence diagram showing an example of the diagnostic processing of the vehicle control device. The processing shown in Fig. 3 is executed, for example, at a predetermined diagnostic timing while the vehicle ECU 1 is in operation.

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

[0032] In S12, the sequencer 20 of the CAN controller 13 counts the wait 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 a "command" using the buffer decoder 23, and transmits data related to a request for fault diagnosis to the ECU 3 to be diagnosed using the diagnostic transfer 24.

[0033] In step S15, the ECU 3 to be diagnosed transmits response data in response to the received data relating to the request for failure diagnosis.

[0034] 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 response value using the diagnostic receiver 25. In S18, the sequencer 20 transmits the diagnostic result to the CPU 11 using the diagnostic receiver 25.

[0035] In S19, the CPU 11 acquires the diagnosis result transmitted from the CAN controller 13. After that, the vehicle ECU 1 ends the process of Fig. 3. The CPU 11 of the vehicle ECU 1 may repeatedly execute the process of Fig. 3 until it receives completion information from the diagnostic receiver 25 indicating that a NULL value has been received.

[0036] As described above, in the vehicle ECU 1, the CPU 11 transmits an instruction to execute a fault diagnosis to the CAN controller 13, and the CAN controller 13 performs the diagnosis based on the received instruction and transmits the diagnosis results to the CPU 11. By transmitting the instruction to execute a fault diagnosis, the CPU 11 can obtain the diagnosis results without performing the diagnostic process. This reduces the processing load and memory usage of the CPU 11 compared to when the CPU 11 itself performs the diagnostic process, and makes it possible to reduce the load on the CPU associated with the fault diagnosis.

[0037] In other words, the CAN controller 13 of the microcomputer 10 can independently perform "diagnosis" such as issuing requests, receiving responses, and making judgments without software. Because the sequencer 20 performs the diagnosis, the CPU 11 does not need to perform the processing. In this way, routine processing such as diagnosis is actively performed by the sequencer 20 in hardware, allowing the resources of the CPU 11 to be used for value-added purposes such as applications.

[0038] In the above embodiment, the diagnostic buffer 26 stores request data and response data as multiple data frames, and the sequencer 20 selects whether to send a fault diagnosis request to the diagnosis target ECU 3 based on the data contained in the data frame read from the diagnostic buffer 26, or to perform diagnosis based on the response from the diagnosis target ECU 3. As a result, the sequencer 20 can automatically switch its operation by sequentially reading the data frames. Note that storing data in the diagnostic buffer 26 of the CAN controller 13 reduces the amount of code flashed to the flash memory 12 and also reduces the amount of RAM used by the CPU 11 during calculations.

[0039] In the above embodiment, when the sequencer 20 has read all of the data included in the data frame from the diagnostic buffer 26, it transmits completion information indicating the end of reading to the CPU 11. This allows the CPU 11 to recognize that the series of diagnoses included in the data frame has ended.

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

[0041] In the above embodiment, the diagnostic buffer 26 stores the request data and the response data as multiple data frames, but the use of data frames is not essential. The request data and the response data may be data for performing a single fault diagnosis.

[0042] In the above embodiment, when all the data included in the data frame has been read from the diagnostic buffer 26, the sequencer 20 transmits completion information indicating the end of reading to the CPU 11. However, this is not limiting. In this case, the last Nth data in FIG. 2 does not have to be "NULL."

[0043] In the above embodiment, all of the fault diagnoses were performed by the sequencer 20, but this is not limiting. For example, the CPU 11 may be responsible for some of the diagnoses that may require lower time accuracy. For example, if more diagnoses than the CAN controller 13 can perform are required, the CPU 11 may be responsible for the diagnoses that the CAN controller 13 could not perform.

[0044] In addition, when an error in the ECU 3 to be diagnosed is suspected as a result of the diagnosis of the CAN controller 13, diagnostic code for diagnosing the content of the error in more detail (for example, determining whether it is a power fault or a ground fault) may be prepared in the flash memory 12 and executed by the CPU 11. [Explanation of symbols]

[0045] 1...vehicle ECU (vehicle control device), 3...diagnosis target ECU (diagnosis target), 11...CPU, 13...CAN controller, 20...sequencer, 26...diagnosis buffer (storage unit).

Claims

1. A vehicle control device including a CPU and a CAN controller, The CPU transmits an instruction to the CAN controller to perform a fault diagnosis; the CAN controller has a storage unit that stores data related to a request for the fault diagnosis of a diagnostic object and data related to a response from the diagnostic object, and a sequencer that operates in response to the execution instruction; The sequencer is configured to read the data from the storage unit in response to receiving the execution instruction, send the fault diagnosis request to the diagnosis target, receive a response sent from the diagnosis target in response to the fault diagnosis request, perform a diagnosis based on the received response, and send the result of the diagnosis to the CPU.

2. the storage unit stores the data regarding the request and the data regarding the response as a plurality of data frames, 2. The vehicle control device according to claim 1, wherein the sequencer selects whether to send the fault diagnosis request to the diagnosis target or to perform the 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 the sequencer transmits data indicating completion of reading to the CPU when all of the data included in the data frame has been read from the storage unit.

Images