DE112021005649T5 - VEHICLE CONTROL DEVICE - Google Patents

Abstract

A vehicle control device 10 includes: a multi-core CPU 11 having at least a first core 111-1 and a second core 111-2; a shared data memory 115 that allows respective cores to access the shared data memory 115 and stores at least one communication parameter; and a monitoring IC 12 that monitors an operation of the multi-core CPU and outputs a reset signal to the multi-core CPU 11. The second core 111-2 checks the communication parameter by accessing the shared data memory 115 during a period from a release of reset of the multi-core CPU to completion of an operating system initialization by the first core 111-1 and conducts communication with the outside on the basis of the communication parameter stored in the shared data memory 115.

Description

Technical area

The present invention relates to a vehicle control apparatus, and more particularly to a vehicle control apparatus provided with a multi-core CPU.

The present application claims priority on the basis of Japanese Patent Application No. 2021-046953 , filed March 22, 2021, the contents of which are incorporated herein by reference in their entirety.

Technical background

In recent years, in a vehicle such as B. a motor vehicle, a plurality of electronic control units (ECU, i.e. vehicle control devices) are mounted to enable the vehicle to perform engine control, brake control, transmission control, door control, air conditioning control and the like. These ECUs communicate with each other through an in-vehicle network and thus cooperate with each other, thereby realizing safe movement and the like of the vehicle.

The ECU may include a multi-core central processing unit (a multi-core CPU) that has multiple cores. In such a multi-core CPU, generally when an abnormality occurs in one of the cores, the entire multi-core CPU is reset to recover the faulty core from an abnormal state. However, when the entire multi-core CPU is reset, a problem arises that communication is interrupted during a period from the release of the reset of the multi-core CPU to the completion of initialization of an operating system (OS). In addition, due to the interruption of communication, other ECUs determine that an abnormality has occurred in the ECU.

In order to solve such a problem, e.g. For example, as described in PTL 1 below, we are exploring a technique that shortens the time from enabling the multi-core CPU reset to completing operating system initialization using a field programmable gate array (FPGA).

Objection list

Patent literature

PTL 1: JP 2013-246495 A

Summary of the invention

Technical problem

However, although the technique described in PTL 1 can shorten the time from the release of the multi-core CPU reset to the completion of the operating system initialization, there is still room for improvement.

The present invention has been made to solve this technical problem, and it is an object of the present invention to provide a vehicle control apparatus which can prevent interruption of communication during a period from the release of resetting a multi-core CPU to the completion of the operating system initialization.

the solution of the problem

A vehicle control apparatus according to the present invention includes: a multi-core CPU having at least a first core and a second core; a shared data memory that allows the respective cores to access the shared data memory and stores at least one communication parameter; and a monitoring circuit that monitors an operation of the multi-core CPU and outputs a reset signal to the multi-core CPU, the second core during a period from the first core enabling resetting of the multi-core CPU to the completion of an operating system initialization by the first core Checks communication parameters by accessing the shared data memory and performs communication with an outside based on the communication parameter stored in the shared data memory.

In the vehicle control apparatus according to the present invention, during a period from enabling the reset of the multi-core CPU to completing operating system initialization by the first core, the second core checks the communication parameter by accessing the shared data memory and conducts communication with an outside on the basis of the communication parameter stored in the shared data memory. Accordingly, the second core can perform communication without waiting for the operating system initialization to complete. As a result, it is possible to interrupt the communication during the period from the release of the reset of the multi-core CPU to the To prevent completion of operating system initialization.

Advantageous effects of the invention

According to the present invention, it is possible to prevent the interruption of communication during the period from the release of the reset of the multi-core CPU to the completion of the operating system initialization.

Brief description of the drawings

• [ 1 ] 1 is a structural view illustrating a vehicle control system provided with a vehicle control apparatus according to a first embodiment.
• [ 2 ] 2 is a sequence diagram illustrating control after the reset release of the vehicle control device according to the first embodiment.
• [ 3 ] 3 is a sequence diagram illustrating control before and after resetting a vehicle control device according to a second embodiment.
• [ 4 ] 4 is a sequence diagram illustrating control before and after resetting a vehicle control device according to a third embodiment.

Description of the embodiments

Hereinafter, embodiments of a vehicle control apparatus according to the present invention will be described with reference to the drawings.

<First Embodiment>

1 is a structural view illustrating a vehicle control system provided with a vehicle control apparatus according to a first embodiment. The vehicle control device 10 according to the present embodiment is composed of an ECU, and forms a vehicle control system together with a plurality of other ECUs (an ECU 20, an ECU 30). In the present embodiment, the vehicle control device 10 is e.g. B. is responsible for engine control, the ECU 20 is responsible for brake control and the ECU 30 is responsible for controlling a transmission. The vehicle control device 10, the ECU 20 and the ECU 30 are connected to each other through an in-vehicle network 15 such as. B. a controller area network (CAN) is connected. These devices communicate with each other via the in-vehicle network 15 and cooperate with each other to realize safe movement and the like of a vehicle.

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

The multi-core CPU 11 includes a plurality of cores (a first core 111-1, a second core 111-2, ... an nth core 111-n) and a program memory (a program memory 112-1, a program memory 112-2 , ... a program memory 112-n) and data memories (a data memory 113-1, a data memory 113-2, ... a data memory 113-n) which are provided based on a one-to-one correspondence to the plurality of cores. All program memories and all data memories store a program and data for performing the function of the corresponding core. It should be noted that n is a natural number equal to 2 or more.

In the present embodiment, the program memory 112-1 corresponding to the first core 111-1 stores: an initialization program related to the initialization of an operating system (OS) to be executed after the reset is enabled; and application software for performing the processing assigned to the first core 111-1 (hereinafter referred to simply as an “application”). The program memory 112-2 corresponding to the second core 111-2 stores: a communication program related to communication processing executed after the reset is enabled; and an application for performing processing assigned to the second core 111-2.

The monitoring IC 12 corresponds to a “monitoring unit” described in the claims. The monitoring IC 12 monitors whether the multi-core CPU 11 is operating normally or not based on a signal 13 output from the multi-core CPU 11. Further, when the signal 13 is interrupted, the monitoring IC 12 determines that an abnormality has occurred in the multi-core CPU 11 and outputs a reset signal 14 to the multi-core CPU 11 to reset the multi-core CPU 11. Furthermore, immediately after a power source is provided (in other words, the power source is turned on), a power source voltage is low. Accordingly, the monitoring IC 12 can reset the multi-core CPU 11 by outputting a reset signal 14 to the multi-core CPU 11. Then the monitoring IC stops 12, after the power source voltage is stabilized, outputting the reset signal 14. As a result, the reset of the multi-core CPU 11 is enabled, so that the multi-core CPU 11 starts its operation.

The multi-core CPU 11 further includes a shared data memory 115 accessible to the respective cores and a communication device 114 connected to the respective cores. The respective cores are connected to the communication device 114 and the shared data memory 115 by means of a bus 116, respectively. The shared data storage 115 stores data such as: B. Communication parameters that are commonly shared between cores. As the communication parameters, a communication speed, a data size, a transmission cycle and the like are mentioned.

The multi-core CPU 11 may be formed of one IC or multiple ICs. Further, it is not always necessary to provide the monitoring IC 12 independently of the multi-core CPU 11, and a monitoring function corresponding to the monitoring IC 12 can be included in the multi-core CPU 11.

An operating system (OS) is installed in the vehicle control device 10 having the above-mentioned configuration, and a program related to each control processing operates 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 initialization processing after the reset is released. In the initialization processing performed by the OS, the OS performs the initialization of the device and the initialization of the application, and further executes the application.

In the multi-core CPU 11 having multiple cores, the initialization is carried out by one core to maintain the consistency of the initialization. As described above, the program memory 112-1 corresponding to the first core 111-1 stores the initialization program related to the operating system initialization performed after the reset is released. Accordingly, the first core 111-1 performs the operating system initialization processing after the release of the reset.

On the other hand, the program memory 112-2 corresponding to the second core 111-2 stores the communication program related to the communication processing performed after the reset is enabled. Accordingly, the second core 111-2 performs the communication processing after the reset release. When performing the communication processing according to the communication program executed after the reset is released, the second core 111-2 accesses the shared data memory 115 to check the communication parameter and further conducts communication with the outside based on the Communication parameter stored in the shared data memory 115. The communication processing of the second core 111-2 is executed in parallel with the operating system initialization processing by the first core 111-1.

Then, at a time when the operating system initialization processing by the first core 111-1 is completed and the application in the first core 111-1 starts, the communication is switched. That is, the communication program of the second core 111-2 is stopped and the communication processing carried out by the first core 111-1 is started.

The following describes the control after the reset is enabled in the vehicle control device 10 with reference to 2 described. In this embodiment, description will be made using an example in which a processing sequence such as: B. enabling reset by turning on the power source, operating system initialization, communication and application execution. In 2 Steps S211 to S214 are processing performed by the first core 111-1, and steps S221 to S225 are processing performed by the second core 111-2.

As in 2 As illustrated, after the reset is enabled by turning on the power source, the first core 111-1 first starts the OS (step S211) and then performs the operating system initialization processing (step S212). At this time, the second core 111-2 performs the respective processing in parallel with the processing performed by the first core 111-1.

Specifically, the second core 111-2 first accesses the shared data memory 115 and checks the communication parameter (step S221). Checking the communication parameter in this step checks whether a normal communication parameter is set in the shared data memory 115 or not. The Value in shared data memory 115 immediately after the power source is turned on (ie, immediately after the reset is enabled) is an indeterminate value and therefore the normal communication parameter is not set. Accordingly, the second core 111-2 performs processing for initializing the communication parameter (step S222). Subsequently, the second core 111-2 starts communication with an external device (e.g., the ECU 20 or the ECU 30) via the communication device 114 based on the initialized communication parameter (step S223).

Then, when the operating system initialization processing by the first core 111-1 is completed, the first core 111-1 starts an application related to communication or the like (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 the communication processing performed by the first core 111-1 is performed. Subsequently, the first core 111-1 and the second core 111-2 execute respective applications (steps S214 and S225).

In the vehicle control device 10 according to the present embodiment, the second core 111-2 checks the communication parameter by accessing the shared data memory 115 during a period from enabling the reset by turning on the power source to completing operating system initialization by the first core 111-1 performs the initialization processing of the communication parameter and then performs communication with the external device based on the initialized communication parameter. Accordingly, the second core can perform communication without waiting for the operating system initialization to complete. As a result, it is possible to prevent the interruption of communication during the period from the release of the reset of the multi-core CPU to the completion of the operating system initialization. Furthermore, by performing such processing, it is possible to avoid the abnormal determination of other ECUs derived from the communication interruption.

<Second Embodiment>

The vehicle control device 10 according to the second embodiment has the same structure as the vehicle control device 10 according to the first embodiment. However, the second embodiment differs from the first embodiment in the content of control performed by the vehicle control device 10. Only the points different between the first embodiment and the second embodiment will be described below.

Traditionally, various functions such as: B. an engine control and an engine control z. B. different ECUs are provided to carry out the respective controls. In recent years, the integration of ECUs having various functions has been favored to realize device compactness, manufacturing cost reduction, and the like. The integrated ECU is required even if an abnormality occurs in a particular function to continue operation of other functions.

When an anomaly occurs, a method is considered where the anomaly is solved by initializing a function where the anomaly occurred in software. However, a method is also considered whereby the anomaly is solved by resetting the entire multi-core CPU in hardware. In the present embodiment, a method is adopted in which an abnormality in hardware is resolved by resetting the entire multi-core CPU. In the method, before resetting the entire multi-core CPU 11, the currently used communication parameters are stored in the shared data memory 115, and the communication is performed based on the currently used communication parameters stored after the reset is released as described above. By performing such processing, continuity of communication before and after reset can be maintained. In the present embodiment, the abnormality is an abnormality that can be detected using a sensor or the like mounted on the vehicle. Accordingly, the reset derived from such an anomaly is an intentional reset.

Hereinafter, the control before and after the reset release in the vehicle control apparatus according to the present invention will be described with reference to 3 described. In 3 Steps S311 to S315 are processing performed by the first core 111-1, and steps S321 to S325 are processing performed by the second core 111-2.

As in 3 As illustrated, after detecting an anomaly (step S311), the first core 111-1 instructs the second core 111-2 to counter to save currently used communication parameters. The second core 111-2 stores the currently used communication parameters based on the command from the first core 111-1 (step S321). At this time, the second core 111-2 stores the currently used communication parameters not in the data memory 113-2 corresponding to the second core 111-2, but in the shared data memory 115. At this time, the communication parameters stored in the shared data memory 115 are stored, referred to as communication parameters 331.

Subsequently, the first core 111-1 sends a command to the monitor IC 12 to cause the monitor IC 12 to generate a reset (step S312). The multi-core CPU 11 is then reset.

After the reset is enabled, the first core 111-1 first starts the OS (step S313) and then performs the operating system initialization processing (step S314). At this time, the second core 111-2 performs the respective processing in parallel with the processing performed by the first core 111-1.

Specifically, the second core 111-2 accesses the shared data memory 115 and checks the communication parameter 331 stored in the shared data memory 115 (step S322). Checking the communication parameter in this step is checking that the value of the communication parameter is not an indeterminate value in memory immediately after the power source is turned on. Subsequently, the second core 111-2 refers to the communication parameters 331 and performs feedback processing of the communication parameters (step S323). Subsequently, the second core 111-2 starts communication with an external device (e.g., the ECU 20 or the ECU 30) via the communication device 114 based on the returned communication parameters (i.e., the communication parameters 331) (step S324).

Then, when the operating system initialization processing by the first core 111-1 is completed as described in the first embodiment, the first core 111-1 starts an application related to communication or the like (step S315) and the second core 111-2 performs communication switching processing (step S325). Thereafter, the respective processing described in the first embodiment is performed.

According to the vehicle control device 10 of the present embodiment, substantially the same advantageous effects as the vehicle control device 10 of the above-mentioned first embodiment can be obtained, and further, the following advantageous effects can be obtained. That is, before the reset, the currently used communication parameters are stored in the shared data memory 115 and the second core 111-2 conducts communication based on the first core 111-1 during a period from the release of the reset to the completion of the operating system initialization currently used communication parameters stored in shared data memory 115. Accordingly, the continuity of communication can be maintained before and after the reset. In the technique described in the above-mentioned PTL 1, only the initial communication is performed after the reset release. Accordingly, it is considered that a problem occurs that the continuity of communication before and after reset cannot be maintained. According to the vehicle control device 10 of the present embodiment, the problem of the technique described in PTL 1 can be solved.

In the present embodiment, in order to distinguish whether the communication parameters in the memory immediately after the power source is turned on are normal values or indeterminate values, it is possible to use a known method such as: B. to use duplicating each piece of data related to the communication parameter or adding a checksum or a spread value.

Furthermore, in the present embodiment, the communication program can also be stored in the shared data memory 115 in addition to the communication parameters. With such a configuration, the vehicle control device can also handle complicated communication processing and therefore, e.g. B. communication, which also contains variable values, is possible. Additionally, a program that interprets and executes a script may be stored in shared data storage 115. In this case, e.g. B. a communication program that is described in a script language is saved. With such processing, it is possible to handle complicated communication processing.

<Third Embodiment>

The vehicle control device 10 according to a third embodiment has the same structure as the vehicle control device 10 according to the first embodiment. However, the third embodiment differs from the first embodiment in the content of processing performed by the vehicle control device 10. Only the points different between the first embodiment and the second embodiment will be described below.

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

As in 4 As illustrated, first, the first core 111-1 performs processing of storing default values of communication parameters (step S411). The default values of the communication parameters are values of the communication parameters that are used in case the reset occurs due to an unexpected anomaly. The default values of the communication parameter are set in advance. A communication pattern indicating that the reset is a reset due to an unexpected anomaly is pre-included in this default value. The default values are stored in the shared data store 115 using the above-mentioned method for distinguishing the default values from indeterminate values in memory. At this time, the default parameters stored in the shared data memory 115 are referred to as 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. With such processing, the multi-core CPU 11 is reset.

After the reset is enabled, the first core 111-1 first starts the OS (step S412) and then performs the operating system initialization processing (step S413). At this time, the second core 111-2 performs the respective processing in parallel with the processing performed by the first core 111-1.

Specifically, the second core 111-2 accesses the shared data memory 115, checks the communication parameters 431 stored in the shared data memory 115, checks that the communication parameters 431 are not indeterminate values in the memory (step S421), and detects the Communication parameter 431 (step S422). With such processing, the default value set in step S411 is detected.

Subsequently, the second core 111-2 starts communication with an external device (e.g., the ECU 20 or the ECU 30) via the communication device 114 based on the detected communication parameters 431 (step S423). The communication pattern indicating that the reset is a reset due to the unexpected abnormality is included in the communication parameter 431, and the other ECUs (the ECU 20 and the ECU 30) can recognize such a reset by the vehicle control device 10.

Then, when the operating system initialization processing performed by the first core 111-1 is completed as described in the first embodiment, the first core 111-1 starts an application related to communication or the like (step S414 ) and the second core 111-2 performs communication switching processing (step S424). Thereafter, the respective processing described in the first embodiment is performed respectively.

In the vehicle control device 10 according to the present embodiment, the first core 111-1 sets default values of the communication parameters in advance and stores the default values in the shared data memory 115. Then, when the reset occurs due to an unexpected abnormality, the second core 111-2 conducts communication based on the default values. Accordingly, the vehicle control device can perform communication without waiting for the operating system initialization to complete. As a result, it is possible to prevent the interruption of communication during the period from the release of the reset of the multi-core CPU to the completion of the operating system initialization. Furthermore, by performing such processing, it is possible to avoid abnormal determination of other ECUs derived from the interruption of communication.

In the present embodiment, the default values of the communication parameters are set by the first core 111-1 in step S411. However, z. B. in step S411 only a flag is set and in step S421 if the Flag is detected, fixed communication parameters are sent to the second core 111-2.

Further, in the above-mentioned three embodiments, the description has been made with respect to the reset pattern based on turning on the power source (first embodiment), the intended reset pattern (second embodiment), and the reset pattern derived from an unexpected abnormality (third embodiment), respectively. , performed. For example, by sending communication data to other ECUs with identification numbers or the like that can identify the above-mentioned three patterns, it is possible to clearly notify other ECUs whether the vehicle control device 10 is normal or abnormal.

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

Reference symbol list

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

First core

111-2

Second core

111-n

nth core

112-1, 112-2, ... 112-n

Program memory

113-1, 113-2, ... 113-n

Data storage

114

Communication device

115

Shared data storage

116

bus

QUOTES INCLUDED IN THE DESCRIPTION

This list of documents listed by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• JP 2021046953 [0002]
• JP 2013246495 A [0006]

Claims (5)

Vehicle control device comprising: a multi-core CPU having at least a first core and a second core; a shared data memory that allows the respective cores to access the shared data memory and stores at least one communication parameter; and a monitoring unit that monitors operation of the multi-core CPU and outputs a reset signal to the multi-core CPU, wherein the second core checks the communication parameter by accessing the shared data memory during a period from a release of resetting the multi-core CPU to completion of an operating system initialization by the first core, and communicates with an outside based on the communication parameter stored in the shared data memory is stored. Vehicle control device Claim 1 , wherein the shared data memory stores a currently used communication parameter before resetting the multi-core CPU, and the second core performs communication with an outside based on a currently used communication parameter stored in the shared data memory. Vehicle control device Claim 1 or 2 , wherein the shared data memory further stores a program for performing communication. Vehicle control device Claim 1 or 2 , wherein the shared data storage further stores a program that interprets and executes a script. Vehicle control device according to one of the Claims 1 until 4 , wherein the shared data memory further stores a default value of a communication parameter, and the second core communicates with the outside based on the default value in a case where the reset of the multi-core CPU is performed due to an unexpected abnormality.

Images