WO2022201597A1

WO2022201597A1 - Vehicle control device

Info

Publication number: WO2022201597A1
Application number: PCT/JP2021/035372
Authority: WO
Inventors: 朋仁蛯名
Original assignee: 日立Astemo株式会社
Priority date: 2021-03-22
Filing date: 2021-09-27
Publication date: 2022-09-29
Also published as: JPWO2022201597A1; DE112021005649T5

Abstract

A vehicle control device 10 comprising a multicore CPU 11 having at least a first core 111-1 and a second core 111-2, a shared data memory 115 configured to be accessible by each core and storing at least a communication parameter, and a monitoring IC 12 that monitors operation of the multicore CPU 11 and outputs a reset signal to the multicore CPU 11. The second core 111-2 accesses the shared data memory 115 to check the communication parameter and communicates with the outside on the basis of the communication parameter stored in the shared data memory 115 within a period from cancellation of resetting until completion of OS initialization by the first core 111-1.

Description

vehicle controller

The present invention relates to a vehicle control device, and more particularly to a vehicle control device having a multi-core CPU.
This application claims priority based on Japanese Patent Application No. 2021-046953 filed on March 22, 2021, the contents of which are incorporated herein.

In recent years, vehicles such as automobiles are equipped with a plurality of ECUs (Electronic Control Units, that is, vehicle control devices) for performing engine control, brake control, transmission control, door control, air conditioner control, etc. These ECUs communicate and cooperate with each other via an in-vehicle network to realize safe driving of the vehicle.

The ECU may have a multi-core CPU with multiple cores. In a multi-core CPU, generally, when an abnormality occurs in one of the cores, the entire multi-core CPU is reset in order to recover from the abnormal state. However, when the entire multi-core CPU is reset, there is a problem that communication is interrupted between reset release and completion of OS initialization. Also, due to the communication interruption, other ECUs will determine that there is an abnormality.

In order to solve such problems, for example, as described in Patent Document 1 below, a technology is being studied that uses an FPGA (Field Programmable Gate Array) to shorten the time from reset release to completion of OS initialization. .

JP 2013-246495 A

However, although the technology described in Patent Document 1 can shorten the time from reset release to completion of OS initialization, there is still room for improvement.

The present invention has been made to solve such technical problems, and an object of the present invention is to provide a vehicle control device that can prevent interruption of communication from reset release to completion of OS initialization.

A vehicle control device according to the present invention comprises a multi-core CPU having at least a first core and a second core, a shared data memory configured to be accessible by each core and storing at least communication parameters, and operations of the multi-core CPU. a monitoring circuit for monitoring and outputting a reset signal to the multi-core CPU, wherein the second core accesses the shared data memory from reset release to completion of OS initialization by the first core. It is characterized in that the communication parameters are confirmed, and communication with the outside is performed based on the communication parameters stored in the shared data memory.

In the vehicle control device according to the present invention, the second core accesses the shared data memory to confirm the communication parameters and saves them in the shared data memory after the reset is released until the OS initialization is completed by the first core. Since communication with the outside is performed based on the communication parameters, communication can be performed without waiting for the completion of OS initialization. As a result, it is possible to prevent interruption of communication from reset release to completion of OS initialization.

According to the present invention, it is possible to prevent disruption of communication during the period from reset release to completion of OS initialization.

1 is a configuration diagram showing a vehicle control system including a vehicle control device according to a first embodiment; FIG. FIG. 5 is a sequence diagram showing control after reset release of the vehicle control device according to the first embodiment; FIG. 9 is a sequence diagram showing control before and after resetting of the vehicle control device according to the second embodiment; FIG. 11 is a sequence diagram showing control before and after resetting of the vehicle control device according to the third embodiment;

An embodiment of a vehicle control device according to the present invention will be described below with reference to the drawings.

[First Embodiment]
FIG. 1 is a configuration diagram showing a vehicle control system provided with a vehicle control device according to the first embodiment. A vehicle control device 10 of the present embodiment is configured by an ECU, and forms a vehicle control system together with a plurality of other ECUs (ECU 20, ECU 30). Here, for example, the vehicle control device 10 is in charge of engine control, the ECU 20 is in charge of brake control, and the ECU 30 is in charge of transmission control. The vehicle control device 10, the ECU 20, and the ECU 30 are connected by an in-vehicle network 15 such as a CAN (Controller Area Network), etc., and communicate with each other through the in-vehicle network 15 to realize safe driving of the vehicle. there is

As shown in FIG. 1, the vehicle control device 10 mainly includes a multi-core CPU 11 and a monitoring IC (Integrated Circuit) 12 that monitors the operation of the multi-core CPU 11 .

The multi-core CPU 11 includes a plurality of cores (first core 111-1, second core 111-2, . . . n-th core 111-n) and a program memory (program memory 112-1, program memory 112-2, . . . program memory 112-n) and data memory (data memory 113-1, data memory 113-2, . Each program memory and each data memory store programs and data for performing the functions of the corresponding core. Note that n is a natural number of 2 or more.

In this embodiment, the program memory 112-1 corresponding to the first core 111-1 contains an initialization program for initializing the OS (Operating System) to be executed after the reset is released, and an initialization program assigned to the first core 111-1. Application software (hereinafter simply referred to as "application") for performing the processing is stored. A program memory 112-2 corresponding to the second core 111-2 stores a communication program relating to communication processing to be executed after reset release and an application for performing processing assigned to the second core 111-2. there is

The monitoring IC 12 corresponds to the "monitoring unit" described in the claims, and monitors whether the multi-core CPU 11 is operating normally based on the signal 13 output from the multi-core CPU 11. Further, when the signal 13 is interrupted, the monitor IC 12 can output the reset signal 14 to the multi-core CPU 11 assuming that the multi-core CPU 11 is abnormal, and reset the multi-core CPU 11 . Furthermore, immediately after power-on (in other words, power-on), the power supply voltage is low, so the monitoring IC 12 can output the reset signal 14 to the multi-core CPU 11 to reset the multi-core CPU 11 . After the power supply voltage is stabilized, the monitor IC 12 stops outputting the reset signal 14 . As a result, the reset of the multi-core CPU 11 is released, and the multi-core CPU 11 starts operating.

The multi-core CPU 11 further comprises a shared data memory 115 accessible by each core, and a communication device 114 connected to each core. Each core is respectively connected to communication device 114 and shared data memory 115 via bus 116 . The shared data memory 115 stores data such as communication parameters shared between cores. Communication parameters include communication speed, data size, and transmission cycle.

The multi-core CPU 11 may be composed of one IC, or may be composed of a plurality of ICs. Also, the monitoring IC 12 does not necessarily have to be provided independently from the multi-core CPU 11 , and a monitoring function corresponding to the monitoring IC 12 may be incorporated into the multi-core CPU 11 .

The vehicle control device 10 configured as described above is equipped with an OS, and programs related to each control process operate under the control of the OS. Then, when the multi-core CPU 11 is reset due to an abnormality or the like, the OS performs an initialization process after canceling the reset. In the OS initialization process, the OS initializes devices and applications, and further executes applications.

In addition, in the multi-core CPU 11 having multiple cores, initialization is performed by one core in order to maintain initialization consistency. As described above, the program memory 112-1 corresponding to the first core 111-1 stores an initialization program for initializing the OS to be executed after the reset is released. performs OS initialization processing after reset release.

On the other hand, since the program memory 112-2 corresponding to the second core 111-2 stores a communication program related to communication processing to be executed after the reset is released, the second core 111-2 executes the communication processing after the reset is released. conduct. At that time, the second core 111-2 accesses the shared data memory 115 to confirm the communication parameters by the communication program executed after the reset is released, and furthermore, based on the communication parameters saved in the shared data memory 115, Communicate with the outside world. The communication processing of the second core 111-2 is executed in parallel with the initialization processing of the OS by the first core 111-1.

Then, when the OS initialization process by the first core 111-1 is completed and the application in the first core 111-1 is activated, the communication is switched. That is, the communication program of the second core 111-2 is stopped, and communication processing led by the first core 111-1 is started.

The control after reset cancellation in the vehicle control device 10 will be described below based on FIG. Here, an example of a series of processes from reset release by power-on to OS initialization, communication, and application execution will be described. In FIG. 2, steps S211 to S214 are processes performed by the first core 111-1, and steps S221 to S225 are processes performed by the second core 111-2.

As shown in FIG. 2, after the reset is released by turning on the power, the first core 111-1 first activates the OS (step S211), and then performs OS initialization processing (step S212). At this time, the second core 111-2 performs each process in parallel with the process of the first core 111-1.

Specifically, the second core 111-2 first accesses the shared data memory 115 and confirms the communication parameters (step S221). Confirmation of the communication parameters in this step is confirmation of whether or not normal communication parameters are set in the shared data memory 115 . Since the values in the shared data memory 115 are indefinite immediately after the power is turned on (in other words, immediately after the reset is released), normal communication parameters are not set. Therefore, the second core 111-2 performs communication parameter initialization processing (step S222). Subsequently, the second core 111-2 starts communication with an external device (eg, the ECU 20 or the ECU 30) via the communication device 114 based on the initialized communication parameters (step S223).

Then, when the OS initialization process by the first core 111-1 is completed, the first core 111-1 activates an application related to communication (step S213). At this time, the second core 111-2 performs communication switching processing (step S224). Specifically, the communication program of the second core 111-2 is stopped, and communication processing led by the first core 111-1 is performed. Subsequently, the first core 111-1 and the second core 111-2 execute their respective applications (steps S214 and S225).

According to the vehicle control device 10 of the present embodiment, the second core 111-2 accesses the shared data memory 115 for communication during the period from reset cancellation by turning on the power to completion of OS initialization by the first core 111-1. After the parameters are confirmed and the communication parameters are initialized, communication with the external device is performed based on the initialized communication parameters, so communication is possible without waiting for the completion of OS initialization. As a result, it is possible to prevent interruption of communication from reset release to completion of OS initialization. Furthermore, this makes it possible to avoid an abnormality determination from another ECU due to a communication interruption.

[Second embodiment]
A vehicle control device 10 according to the second embodiment has the same structure as that of the first embodiment, but differs from the first embodiment in the control contents of the vehicle control device 10 . Only the differences will be described below.

In the past, different functions such as engine control and motor control were controlled by separate ECUs. In recent years, integration of ECUs having different functions has been promoted in order to make devices more compact and to reduce costs. Further, in the integrated ECU, even if an abnormality occurs in a certain function, it is required to continue the operation of other functions.

When an abnormality occurs, there is a method of resolving it by software-initializing the function in which the anomaly occurred, but there is also a method of resolving the anomaly by hardware-resetting the entire multi-core CPU. In the present embodiment, a method of resolving an abnormality by resetting the entire multi-core CPU in terms of hardware is adopted. Prior to resetting the entire multi-core CPU 11, the communication parameters currently in use are saved in the shared data memory 115, and after the reset is released, communication is performed based on the saved communication parameters currently in use. Continuity of communication before and after can be maintained. The abnormality referred to in this embodiment is an abnormality that can be detected via a sensor or the like attached to the vehicle. Resets resulting from such anomalies are therefore intended resets.

The control before and after resetting of the vehicle control device according to this embodiment will be described below based on FIG. In FIG. 3, steps S311 to S315 are processes performed by the first core 111-1, and steps S321 to S325 are processes performed by the second core 111-2.

As shown in FIG. 3, when the first core 111-1 detects an abnormality (step S311), it instructs the second core 111-2 to save the currently used communication parameters. The second core 111-2 stores the currently used communication parameters based on the instruction from the first core 111-1 (step S321). At this time, the second core 111-2 stores the currently used communication parameters in the shared data memory 115 instead of the data memory 113-2 corresponding to the second core 111-2. Here, communication parameters stored in shared data memory 115 are assumed to be communication parameters 331 .

Subsequently, the first core 111-1 transmits an instruction to generate a reset to the monitoring IC 12 (step S312). Subsequently, the multicore CPU 11 is reset.

After the reset is released, the first core 111-1 first starts up the OS (step S313), and then performs OS initialization processing (step S314). At this time, the second core 111-2 performs each process in parallel with the process of the first core 111-1.

Specifically, the second core 111-2 accesses the shared data memory 115 and checks the communication parameters 331 stored in the shared data memory 115 (step S322). The confirmation of the communication parameters in this step is confirmation that the values in the memory are not undefined immediately after the power is turned on. Subsequently, the second core 111-2 refers to the communication parameter 331 and performs communication parameter restoration processing (step S323). Subsequently, the second core 111-2 starts communication with an external device (for example, the ECU 20 or the ECU 30) via the communication device 114 based on the restored communication parameter (that is, the communication parameter 331) (step S324).

When the OS initialization process by the first core 111-1 is completed, the first core 111-1 activates an application related to communication and the like (step S315), and the second core 111-1 111-2 performs communication switching processing (step S325). After that, each process described in the first embodiment is performed.

According to the vehicle control device 10 of this embodiment, in addition to obtaining the same effects as those of the first embodiment, the following effects are obtained. That is, the communication parameters currently in use are stored in the shared data memory 115 before resetting, and the second core 111-2 is set to the shared data memory 115 after the reset is released until the OS initialization by the first core 111-1 is completed. Since communication is performed based on the currently used communication parameters saved in the , it is possible to maintain continuity of communication before and after the reset. In addition, in the technique described in Patent Document 1, only initial communication is performed after the reset is canceled, so it is considered that there is a problem in that the continuity of communication cannot be maintained before and after the reset. According to the vehicle control device 10 of the present embodiment, it is possible to solve the technical problem described in Patent Document 1 above.

In this embodiment, in order to distinguish whether the communication parameter is a normal value or the undefined value in the memory immediately after the power is turned on, each data related to the communication parameter is duplicated or a checksum or hash is added. etc., can be used.

Also, in this embodiment, a communication program may be further stored in the shared data memory 115 in addition to the communication parameters. In this way, complicated communication processing can be dealt with, so communication including variable values, for example, is also possible. Further, shared data memory 115 may store a program that interprets and executes a script, such as a communication program written in a script language. In this way, even complicated communication processing can be handled.

[Third Embodiment]
A vehicle control device 10 according to the third embodiment has the same structure as that of the first embodiment, but differs from the first embodiment in the processing contents of the vehicle control device 10 . Only the differences will be described below.

FIG. 4 is a sequence diagram showing control before and after resetting of the vehicle control device according to the third embodiment. In FIG. 4, steps S411 to S414 are processes performed by the first core 111-1, and steps S421 to S424 are processes performed by the second core 111-2.

As shown in FIG. 4, the first core 111-1 first performs processing for saving default values of communication parameters (step S411). The default value of the communication parameter is the value of the communication parameter that is used when resetting occurs due to an unexpected abnormality, and is set in advance. A communication pattern indicating that the reset is due to an unexpected abnormality is preliminarily incorporated in this default value. Default values are stored in shared data memory 115 using the techniques described above to distinguish them from indeterminate values in memory. Here, the default values stored in shared data memory 115 are assumed to be communication parameters 431 .

Then, when an unexpected abnormality occurs in the multi-core CPU 11, the monitoring IC 12 outputs a reset signal 14 to the multi-core CPU 11. The multi-core CPU 11 is thereby reset.

After the reset is released, the first core 111-1 first starts up the OS (step S412), and then performs OS initialization processing (step S413). At this time, the second core 111-2 performs each process in parallel with the process of the first core 111-1.

Specifically, the second core 111-2 accesses the shared data memory 115, confirms the communication parameter 431 stored in the shared data memory 115, and checks that it is not an undefined value in the memory (step S421). ), and acquires the communication parameter 431 (step S422). As a result, the default value set in step S411 is acquired.

Subsequently, the second core 111-2 starts communication with an external device (eg, the ECU 20 or the ECU 30) via the communication device 114 based on the obtained communication parameters 431 (step S423). Since the communication parameter 431 incorporates a communication pattern indicating a reset due to an unexpected abnormality, the other ECUs (ECU 20 and ECU 30) can grasp it with the vehicle control device 10. FIG.

Then, when the OS initialization process by the first core 111-1 is completed, as described in the first embodiment, the first core 111-1 activates an application related to communication (step S414), The core 111-2 performs communication switching processing (step S424). After that, each process described in the first embodiment is performed.

In the vehicle control device 10 of the present embodiment, the first core 111-1 presets default values of communication parameters and stores them in the shared data memory 115. FIG. When resetting occurs due to an unexpected abnormality, the second core 111-2 performs communication based on the default value, thereby enabling communication without waiting for completion of OS initialization. As a result, it is possible to prevent interruption of communication from reset release to completion of OS initialization. In addition, as a result, it is possible to avoid an abnormality determination from another ECU due to the communication interruption.

In this embodiment, the default values of the communication parameters are set by the first core 111-1 in step S411. For example, only the flag is set. may be transmitted to the second core 111-2.

Further, in the above three embodiments, the reset pattern due to power-on (first embodiment), the intended reset pattern (second embodiment), and the reset pattern due to an unexpected abnormality (third embodiment). explained each. For example, if communication data to other ECUs is sent with an identification number or the like for identifying each of the above three patterns, it is possible to clearly inform the other ECUs whether the vehicle control device 10 is normal or abnormal.

Although the embodiments of the present invention have been described in detail above, the present invention is not limited to the above-described embodiments, and various designs can be made without departing from the spirit of the invention described in the claims. Changes can be made.

10 vehicle control device 11 multi-core CPU
12 monitoring IC (monitoring unit)
13 signal 14 reset signal 15 in-

vehicle network

20, 30 ECU
111-1 1st core 111-2 2nd core 111-n nth core 112-1, 112-2, . . . 112-n program memory 113-1, 113-2, . shared data memory 116 bus

Claims

a multi-core CPU having at least a first core and a second core;
a shared data memory configured to be accessible by each core and storing at least communication parameters;
a monitoring unit that monitors the operation of the multi-core CPU and outputs a reset signal to the multi-core CPU;
with
The second core accesses the shared data memory to confirm communication parameters during a period from reset release to completion of OS initialization by the first core, and based on the communication parameters saved in the shared data memory. A vehicle control device, characterized in that it communicates with the outside through a
The shared data memory stores currently used communication parameters before resetting,
2. The vehicle control device according to claim 1, wherein the second core communicates with the outside based on currently used communication parameters stored in the shared data memory.
The vehicle control device according to claim 1 or 2, wherein the shared data memory further stores a program for communication.
The vehicle control device according to claim 1 or 2, wherein the shared data memory further stores a program for interpreting and executing a script.
the shared data memory further stores default values for communication parameters;
The vehicle control device according to any one of claims 1 to 4, wherein when reset due to an unexpected abnormality, said second core communicates with the outside based on said default value.