JP2022090870A - Vehicle control device, vehicle control method and control program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To shorten the time required for verification of software of a plurality of VMs by diverting the result of verification of software shared by a plurality of VMs.
SOLUTION: When a vehicle control device 10 verifies the software of each VM, the verification of the common software obtained by the verification of the software of other VMs according to the index given in advance to the VM. If it is decided to divert the common software verification result obtained by the diversion judgment unit 310 that determines whether or not to divert the result and the verification of the software of other VMs, the verification of the software of the other VM is performed. The verification unit 330 for verifying the VM software by diverting the obtained verification result of the common software is provided.
[Selection diagram] Fig. 2

Description

The present invention relates to a vehicle control device, a vehicle control method, and a control program.

Development is being made to integrate the functions of the vehicle's ECU as software into a single control device. For example, Patent Document 1 discloses a technique for sharing a program module between virtual machines (VMs) to shorten the startup time of the VM and save memory.

Japanese Patent No. 5236637

Here, when a plurality of software having an ECU function of a vehicle is executed by one control device, it is realized by configuring a plurality of VMs (Virtual Machines). In this case, in order to verify the authenticity of the software required to configure the VM at the time of starting the ECU, as the number of VMs increases, the time required for authenticity verification increases in proportion to the number of VMs. The time to finish starting all VMs will increase.

The present invention provides a vehicle control device, a vehicle control method, and a control program that shortens the time required for verification of software of a plurality of VMs by diverting the verification results of software shared by a plurality of VMs. With the goal.

The vehicle control device according to claim 1 stores VM software that is software of a plurality of VMs (Virtual Machines) that control devices mounted on the vehicle, and common software shared by two or more of the VMs. When verifying the software of each of the VM with the storage unit, the verification result of the common software obtained in the verification of the software of the other VM is diverted according to the index given in advance to the VM. It has a verification unit and a verification unit.

In the vehicle control device according to claim 1, VM software, which is software of a plurality of VMs that control devices mounted on the vehicle, and common software shared by two or more of the VMs are stored in a storage unit. ing. In the control device of the vehicle, when the verification unit verifies the software of each of the VMs, the said is obtained by the verification of the software of the other VMs according to the index given in advance to the VMs. Use the verification results of common software. As a result, the time required for the verification of the software of a plurality of VMs can be shortened by the amount that the verification of the common software is not performed twice. That is, by diverting the result of the verification of the software shared by the plurality of VMs, the time required for the verification of the software of the plurality of VMs can be shortened.

The vehicle control device according to claim 2 is the vehicle control device according to claim 1, according to an index given in advance to the VM when verifying the software of each VM. Further provided with a diversion determination unit for determining whether or not to divert the verification result of the common software obtained in the verification of the software of the VM, the verification unit is obtained in the verification of the software of the other VM. If it is decided to divert the verification result of the common software, the verification result of the common software obtained in the verification of the software of the other VM is diverted to verify the software of the VM, and the other. When it is determined not to divert the verification result of the common software obtained in the verification of the VM software, the VM software of the VM and the common software are verified. As a result, when it is decided to divert the verification result of the common software obtained in the verification of the software of the other VM, the verification of the common software is not duplicated, so that the software of a plurality of VMs is verified. The time required for the software can be shortened.

The vehicle control device according to claim 3 is the vehicle control device according to claim 1, and the verification unit verifies the authenticity of the software of the VM. As a result, the time required for verifying the authenticity of the software of a plurality of VMs can be shortened. To verify the authenticity is to verify that it has not been tampered with.

The vehicle control device according to claim 4 is the vehicle control device according to any one of claims 1 to 3, wherein the verification unit activates the software of the plurality of VMs. Verify the VM software. As a result, the time required to start the software of a plurality of VMs can be shortened. In addition, starting the VM software means reading the VM software and the common software of the VM from the storage unit and expanding the software.

The vehicle control device according to claim 5 is the vehicle control device according to any one of claims 1 to 4, wherein the index is a functional safety index related to functional safety of the device controlled by the VM. Alternatively, it is a security index related to the security of the VM software. As a result, it is possible to achieve both functional safety of the device controlled by the VM or security of the software of the VM and reduction of the time required for verification of the software of a plurality of VMs.

The vehicle control method according to claim 6 stores VM software, which is software of a plurality of VMs (Virtual Machines) that control devices mounted on the vehicle, and common software shared by two or more of the VMs. When the computer including the storage unit verifies the software of each of the VMs, the verification of the common software obtained by the verification of the software of the other VMs according to the index given in advance to the VMs. It has a verification step, which diverts the results.

The vehicle control method according to claim 6 is the verification of the software of the other VM according to the index given in advance to the VM when the software of each VM is verified by the verification step. The obtained verification result of the common software is diverted. As a result, the time required for the verification of the software of a plurality of VMs can be shortened by the amount that the verification of the common software is not performed twice. That is, by diverting the result of the verification of the software shared by the plurality of VMs, the time required for the verification of the software of the plurality of VMs can be shortened.

The control program according to claim 7 is a storage unit that stores VM software that is software of a plurality of VMs (Virtual Machines) that control devices mounted on a vehicle, and common software shared by two or more VMs. When verifying the software of each of the VMs on a computer including the above, the verification result of the common software obtained by the verification of the software of the other VMs is obtained according to the index given in advance to the VM. Execute the process including the verification step to be diverted.

The control program according to claim 7 is obtained by verifying the software of the other VM according to the index given in advance to the VM when the software of each VM is verified by the verification step. In addition, the verification result of the common software will be diverted. As a result, the time required for the verification of the software of a plurality of VMs can be shortened by the amount that the verification of the common software is not performed twice. That is, by diverting the result of the verification of the software shared by the plurality of VMs, the time required for the verification of the software of the plurality of VMs can be shortened.

According to the present invention, the time required for verification of software of a plurality of VMs can be shortened by diverting the result of verification of software shared by a plurality of VMs.

It is a block diagram which shows the hardware composition of the vehicle which concerns on 1st Embodiment. It is a block diagram which shows the example of the functional structure of the vehicle of 1st Embodiment. It is a flowchart which shows the flow of the activation process in 1st Embodiment. It is a flowchart (specific example of FIG. 3) which shows the flow of the start processing in 1st Embodiment. It is a block diagram which shows the example of the functional structure of the vehicle of 2nd Embodiment. It is a block diagram which shows the example of the functional structure of the vehicle of 3rd Embodiment. It is a block diagram which shows the example of the functional structure of the vehicle of 4th Embodiment. It is a block diagram which shows the example of the functional structure of the vehicle of 5th Embodiment. It is a flowchart which shows the flow of the activation process in 5th Embodiment. It is a flowchart which shows the flow of the start processing in another example of 5th Embodiment. It is a block diagram which shows the example of the functional structure of the vehicle in another example of an embodiment. It is a flowchart which shows the flow of the start processing in another example of an embodiment.

[First Embodiment]
FIG. 1 is a block diagram showing a control system of the vehicle 12 according to the first embodiment.

(Constitution)
As shown in FIG. 1, the vehicle 12 according to the first embodiment is connected to an ECU (Electronic Control Unit) 20 as a vehicle control device (hereinafter, simply referred to as a “control device”) 10 and an ECU 20. It is configured to include the vehicle-mounted device group 16. The in-vehicle device group 16 is sensors provided on the vehicle 12, and includes sensors mounted on each part of the body and each part of the engine. Further, the in-vehicle device group 16 is drive devices provided in the vehicle 12, and includes motors, valves, and actuators mounted on each body part and each engine part.

The ECU 20 includes a CPU (Central Processing Unit) 20A, a ROM (Read Only Memory) 20B, a RAM (Random Access Memory) 20C, a communication I / F (Inter Face) 20D, an input / output I / F (Inter Face) 20E, and a storage 20F. And the security module 20G are included. The CPU 20A, ROM 20B, RAM 20C, communication I / F20D, input / output I / F20E, storage 20F, and security module 20G are connected to each other so as to be communicable with each other via the bus 20H.

The CPU 20A is a central arithmetic processing unit that executes various programs and controls each unit. That is, the CPU 20A reads the program from the ROM 20B and executes the program using the RAM 20C as a work area. In the present embodiment, a plurality of CPU 20A itself may be provided (so-called multiprocessor), or the CPU 20A may have a plurality of cores (so-called multicore).

The ROM 20B stores various programs and various data. The control program 200 is stored in the ROM 20B of the present embodiment. The control program 200 is a program for performing the activation process described later. Further, the ROM 20B stores a common software group 210 shared by a plurality of VMs.

The RAM 20C temporarily stores a program or data as a work area.

The communication I / F 20D is an interface for connecting to another device provided in the vehicle 12. For the interface, a communication standard such as CAN (Control Area Network) or Ethernet (registered trademark) is used.

The input / output I / F 20E is an interface for communicating with the in-vehicle device group 16 mounted on the vehicle 12.

The VM activation order list 220 is stored in the storage 20F. The VM activation order list 220 is a list that defines the activation order of each VM when each VM is activated. Further, a predetermined index is given to each VM in the VM activation order list 220. As an index, for example, the system safety requirement level required for VM is used. Here, the system safety requirement level is the safety level required for the VM from the combination of the type of problem caused by the malfunction or failure of the ECU and the probability of occurrence. In the case of vehicles, the level of safety is defined in ISO 26262 as ASIL (Automotive Safety Industry Level) for the vehicle's electronic control system. Specifically, a system safety requirement level "high" is given to a VM that may cause harm to the human body or cause physical damage due to a system abnormality. On the other hand, a VM that does not require system safety, that is, a VM that does not have the possibility of causing harm to the human body or causing property damage due to a system abnormality, is given a system safety requirement level of "low". ing. The other VMs are given the system safety requirement level "medium".

Further, the storage 20F stores a VM software group 230 for constituting each of two or more VMs. The two or more VM software group 230 includes, for example, a multimedia VM software group 230A for configuring a multimedia VM described later, a body control VM software group 230B for configuring a body control VM described later, and an automatic body control VM software group 230B described later. It includes the automatic operation control VM software group 230C for configuring the operation control VM. The VM software group 230 further includes the VM software group 230 according to the application.

The storage 20F is realized by a ROM, a hard disk, or various Flash devices (SSD (Solid State Drive), eMMC (embedded MultiMediaCard), SD (Secure Digital), and the like).

The security module 20G verifies the authenticity of software by hardware, and is, for example, TPM (Trusted Platform Module) or HSM (Hardware Security Module). The security module 20G verifies the authenticity of the software by, for example, performing encryption or decryption using a stored key and an encryption or decryption accelerator, or performing an operation such as a hash value.

FIG. 2 is a block diagram showing an example of the functional configuration of the ECU 20. Each functional configuration is realized by the CPU 20A reading the control program 200 stored in the ROM 20B and executing the control program 200.

As shown in FIG. 2, the ECU 20 has two or more VM 110s and a VM component 300. The VM110 includes, for example, a multimedia VM110A, a body control VM110B and an automated operation control VM110C.

The VM110 realized in the ECU 20 is not limited to this, and may further include the VM110 according to the application.

The VM component 300 has a function of virtually configuring each VM 110. This VM configuration unit 300 is realized by the function of a so-called hypervisor, reads out the VM start-up order list 220 from the storage 20F at the time of start-up, and according to the start-up order defined in the VM start-up order list 220, the VM software group 230 and The common software group 210 is read out, and the VM 110 is started. Specifically, the VM component 300 deploys the VM software group 230 and the common software group 210 in the RAM 20C, and activates the VM 110.

The VM component unit 300 further includes an activation VM determination unit 310, a diversion determination unit 320, a verification unit 330, and an activation unit 340.

The start-up VM determination unit 310 determines the start-up VM 110 according to the start-up order specified in the VM start-up order list 220, and acquires the system safety requirement level of the VM 110.

The diversion determination unit 320 is obtained by verifying the VM software group 230 of another VM 110 according to the system safety requirement level given in advance to the VM 110 when verifying the VM software group 230 of each VM 110. In addition, it is determined whether or not to divert the verification result of the common software group 210. Specifically, the diversion determination unit 320 determines that the verification result of the common software group 210 is not diverted when the system safety requirement level of the VM110 is "high". For example, since the body control VM110B is given the system safety requirement level "high", it is determined not to divert the verification result of the common software group 210 for the body control VM110B.

When the system safety requirement level of the VM 110 is "medium", the diversion determination unit 320 determines to divert the verification result of the common software group 210 obtained in the verification of the VM software group 230 of another VM 110. do. For example, since the automatic operation control VM110C is given the system safety requirement level "medium", it is determined that the verification result of the common software group 210 is diverted to the automatic operation control VM110C.

The diversion determination unit 320 determines that the VM software group 230 of the VM 110 is not verified when the system safety requirement level of the VM is “low”. For example, since the multimedia VM 110A is given the system safety requirement level "low", it is decided not to verify the multimedia VM software group 230A.

The verification unit 330 verifies the authenticity of the VM software group 230 of each VM 110 when a plurality of VM 110s are activated. At this time, if the verification unit 330 determines not to divert the verification result of the common software group 210 obtained in the verification of the VM software group 230 of the other VM 110, the verification unit 330 verifies the VM software group 230 of the other VM 110. The authenticity of the VM software group 230 of the VM 110 is verified without diverting the verification result of the common software group 210 obtained in. For example, when it is determined that the verification result of the common software group 210 is not diverted, the verification unit 330 verifies the authenticity of the VM software group 230 and the common software group 210 of the VM 110 by using the security module 20G. ..

When the verification unit 330 determines that the verification result of the common software group 210 is diverted, the verification unit 330 verifies the authenticity of the VM software group 230 of the VM 110 by using the security module 20G, and verifies the common software group 210. Omit.

When the verification unit 330 determines that the VM software group 230 is not verified, the verification unit 330 omits the verification of the VM software group 230 and the common software group 210 of the VM 110.

When the authenticity of the VM software group 230 and the common software group 210 of the VM 110 is successfully verified for each VM 110, the activation unit 340 expands the VM software group 230 and the common software group 210 of the VM 110 into the RAM 20C. , Activate the VM110.

(Control flow)
In the present embodiment, an example of the flow of the activation process executed by the ECU 10 will be described with reference to the flowchart of FIG.

In step S100 of FIG. 3, the CPU 20A activates the hypervisor as software.

In step S101, the start-up VM determination unit 310 determines the start-up VM 110 according to the start-up order specified in the VM start-up order list 220, and acquires the system safety requirement level of the VM 110.

In step S102, the activation VM determination unit 310 determines whether or not there is a VM 110 that has not been activated. If the VM110 to be activated in step S101 is determined, the process proceeds to step S103. On the other hand, if the VM110 to be activated in step S101 is not determined, the activation process is terminated.

In step S103, the diversion determination unit 320 determines whether the system safety requirement level of the VM 110 to be activated is "high", "medium", or "low". If the system safety requirement level of the VM110 to be activated is "high", the process proceeds to step S105. If the system safety requirement level of the VM110 to be activated is "medium", the process proceeds to step S104. If the system safety requirement level of the VM110 to be activated is "low", the process proceeds to step S109.

In step S104, the diversion determination unit 320 determines whether or not the common software group 210 has been verified in the verification of the other VM 110. If the common software group 210 has been verified in the verification of the other VM 110, the diversion determination unit 320 determines that the verification result of the common software group 210 will be diverted, and proceeds to step S107. If the common software group 210 has not been verified in the verification of another VM110, the process proceeds to step S105.

In step S105, the verification unit 330 verifies the authenticity of the common software group 210 by using the security module 20G.

In step S106, the verification unit 330 determines whether or not the verification result of step S105 is a verification result of authenticity. If the verification result in step S105 is not genuine, the process proceeds to step S110, the CPU 20A outputs a start error, and ends the start process. On the other hand, if the verification result in step S105 is the verification result that it is genuine, the process proceeds to step S107.

In step S107, the verification unit 330 verifies the authenticity of the VM software group 230 of the VM 110 by using the security module 20G.

In step S108, the verification unit 330 determines whether or not the verification result of step S107 is a verification result of authenticity. If the verification result in step S107 is not genuine, the process proceeds to step S110. On the other hand, if the verification result in step S107 is a verification result indicating that it is genuine, the process proceeds to step S109.

In step S109, the activation unit 340 expands the VM software group 230 and the common software group 210 of the VM 110 to be activated into the RAM 20C, activates the VM 110, and returns to the above step S101.

A specific example of the flow of the activation process executed by the ECU 10 will be described with reference to the flowchart of FIG. Here, a case where it is specified in the VM activation order list 220 that the multimedia VM110A, the body control VM110B, and the automatic operation control VM110C are activated in this order will be described as an example.

In steps S101A to S109A, the multimedia VM110A is set as the VM110 to be activated, and the same processing as in steps S101 to S109 of FIG. 3 is performed. At this time, since the system safety requirement level of the multimedia VM110A is "low", it is determined in step S103A that the system safety requirement level of the multimedia VM110A to be activated is "low", and the multimedia VM software group. The process proceeds to step S109A without verifying the authenticity of either the 230A or the common software group 210.

Then, in steps S101B to S109B, the body control VM110B is set as the VM110 to be activated, and the same processing as in steps S101 to S109 of FIG. 3 is performed. At this time, since the system safety requirement level of the body control VM110B is "high", it is determined in step S103B that the system safety requirement level of the body control VM110B to be activated is "high", and steps S105B and S107B are determined. In, the authenticity of both the body control VM software group 230B and the common software group 210 is verified.

Then, in steps S101C to S109C, the automatic operation control VM110C is set as the VM110 to be activated, and the same processing as in steps S101 to S109 of FIG. 3 is performed. At this time, since the system safety requirement level of the automated driving control VM110C is "medium", it is determined in step S103C that the system safety requirement level of the automated driving control VM110C to be activated is "medium". Further, in step S104C, it is determined that the common software group 210 has been verified in the verification of the body control VM110B, and the process proceeds to step S107. Then, in step S107C, the authenticity of the automated operation control VM software group 230C is verified.

(Summary of the first embodiment)
In the control device 10 of the present embodiment, the time required for the verification of the software group of a plurality of VMs can be shortened by diverting the verification result of the common software group shared by the plurality of VMs.

Further, in the control device 10 of the present embodiment, it is possible to achieve both functional safety of the device controlled by the VM and shortening of the time required for verification of software of a plurality of VMs.

Further, in the control device 10 of the present embodiment, it is verified that the software group of the VM is not tampered with at the time of starting the ECU in order to ensure the safety at the time of the failure of the ECU. It is recognized that the verification of the common software group performed at the time of starting the ECU has been verified under specific conditions, and while shortening the startup time, the verification of the common software group is repeated according to the level of safety required for the VM. Decide whether to verify and ensure the safety of your system.

In addition, for VMs with a high system safety requirement level, there is a possibility that a system abnormality may cause harm to the human body or cause physical damage, and the VM software group that composes the VM before starting the VM. The ECU 20 verifies whether the 230 and the common software group 210 have been tampered with by some factor by using the security module. On the other hand, for VMs that do not require system safety, that is, VMs that are unlikely to cause harm to the human body or cause property damage due to system abnormalities, the authenticity verification of the software is not essential. In order to shorten the VM startup time, the authenticity of the software group will not be verified.

[Second Embodiment]
In the first embodiment, the ECU 20 is provided with the ROM 20B. On the other hand, the second embodiment is different from the first embodiment in that the ROM 20B is not provided in the ECU 20. Hereinafter, the differences from the first embodiment will be described. The same components are designated by the same reference numerals, and the description thereof will be omitted.

As shown in FIG. 5, the ECU 20 of the present embodiment includes a CPU 20A, a RAM 20C, a communication I / F 20D and an input / output I / F 20E, a storage 20F, and a security module 20G.

The control program 200 and the common software group 210 are stored in the storage 20F.

Also in this embodiment, the same effect as that of the first embodiment can be obtained.

[Third Embodiment]
In the first embodiment, the storage 20F is provided in the ECU 20. On the other hand, the third embodiment is different from the first embodiment in that the storage 20F is not provided in the ECU 20. Hereinafter, the differences from the first embodiment will be described. The same components are designated by the same reference numerals, and the description thereof will be omitted.

As shown in FIG. 6, the ECU 20 of the present embodiment includes a CPU 20A, a ROM 20B, a RAM 20C, a communication I / F 20D, an input / output I / F 20E, and a security module 20G.

The VM boot order list 220 and two or more VM software groups 230 are stored in the ROM 20B.

Also in this embodiment, the same effect as that of the first embodiment can be obtained.

[Fourth Embodiment]
The fourth embodiment differs from the first embodiment in that an EEPROM (Electrically Erasable Project Read-Only Memory) 420B is provided instead of the ROM 20B. Hereinafter, the differences from the first embodiment will be described. The same components are designated by the same reference numerals, and the description thereof will be omitted.

As shown in FIG. 7, the ECU 20 of the present embodiment includes a CPU 20A, an EEPROM 420B, a RAM 20C, a communication I / F 20D, an input / output I / F 20E, a storage 20F, and a security module 20G.

The control program 200 and the common software group 210 are stored in the EEPROM 20B.

Also in this embodiment, the same effect as that of the first embodiment can be obtained.

[Fifth Embodiment]
The fifth embodiment is different from the first embodiment in that the security module 20I is provided in the ECU 20 in addition to the security module 20G. Hereinafter, the differences from the first embodiment will be described. The same components are designated by the same reference numerals, and the description thereof will be omitted.

(Constitution)
As shown in FIG. 8, the ECU 20 of the present embodiment includes a CPU 20A, a ROM 20B, a RAM 20C, a communication I / F 20D, an input / output I / F 20E, a storage 20F, a security module 20G, and a security module 20I.

When starting the software of a plurality of VMs, the verification unit 330 verifies the authenticity of the software of each VM in parallel by using the security module 20G and the security module 20I.

(Control flow)
In the present embodiment, an example of the flow of the activation process executed by the ECU 10 will be described with reference to the flowchart of FIG. The same processes as those in the above embodiment are designated by the same reference numerals, and the description thereof will be omitted.

In step S100 of FIG. 9, the CPU 20A activates the hypervisor as software.

In step S101, the start-up VM determination unit 310 determines the start-up VM 110 according to the start-up order specified in the VM start-up order list 220, and acquires the system safety requirement level of the VM 110. Here, two VM110s to be activated are determined.

In step S102, the activation VM determination unit 310 determines whether or not there is a VM 110 that has not been activated. If the VM110 to be activated in step S101 is determined, the process proceeds to step S500. On the other hand, if the VM110 to be activated in step S101 is not determined, the activation process is terminated.

In step S500, the CPU 20A executes the boot processing of the two VM 110s to be booted in parallel. In this step S500, the security module 20G and the security module 20I are used for the two VMs 110 to be activated, and the same processing as in steps S103 to S110 of FIG. 3 is performed in parallel. Then, the process returns to step S101.

Also in this embodiment, the same effect as that of the first embodiment can be obtained.

In addition, it is possible to parallelize the activation of the VM 110, and it is possible to shorten the activation time of the VM while maintaining the security.

[remarks]
In the fifth embodiment, the case where the activation of the VM 110 is parallelized has been described as an example, but the present invention is not limited to this. The verification of the authenticity of the software group may be parallelized. An example of the flow of the activation process executed by the ECU 10 in this case will be described with reference to the flowchart of FIG. The same processes as those in the above embodiment are designated by the same reference numerals, and the description thereof will be omitted.

In step S104 of FIG. 10, the diversion determination unit 320 determines whether or not the common software group 210 has been verified in the verification of another VM 110. If the common software group 210 has been verified in the verification of the other VM 110, the diversion determination unit 320 determines that the verification result of the common software group 210 will be diverted, and proceeds to step S107. If the common software group 210 has not been verified in the verification of another VM110, the process proceeds to step S600.

In step S600, the verification unit 330 performs verification of the authenticity of the VM software group 230 using the security module 20G and verification of the authenticity of the common software group 210 using the security module 20I in parallel.

In step S601, the verification unit 330 determines whether or not the verification result of step S107 or S600 is a verification result of authenticity. If the verification result in step S107 or S600 is not genuine, the process proceeds to step S110. On the other hand, if the verification result in step S107 or S600 is a verification result that is genuine, the process proceeds to step S109.

Further, in the above embodiment, the system safety requirement level is set to three levels of "high", "medium", and "low", but the system safety requirement level is further increased according to the characteristics and safety requirements of the ECU. It may be subdivided. In ISO26262, ASIL has 4 stages from A to D and 5 stages consisting of non-target. Depending on which of these five stages, it may be determined whether or not to divert the verification result of the common software group 210.

Further, in the above embodiment, the case where the authenticity of both the VM software group 230 and the common software group 210 is verified when the VM having the highest safety requirement level is activated has been described as an example, but the present invention is limited to this. Not done. When the safety requirement level is subdivided, the authenticity of both the VM software group 230 and the common software group 210 may be verified up to the upper two levels.

Further, in the above embodiment, the common software group 210 is set as one, but it is possible that a plurality of common software groups 210 exist depending on the content of the VM to be activated. In this case, as shown in FIG. 11, the ROM 20B stores the common software group 210AB and the common software group 210CD. For example, the common software group 210AB is shared by the multimedia VM110A and the body control VM110B, and the common software group 210CD is shared by the automatic operation control VM110C and another VM110. In this case, it is necessary to further specify the information of the common software group 210 related to the VM 110 for each VM 110 in the VM activation order list 220. Further, the VM component 300 needs to store which common software group 210 has been subjected to authenticity verification at which system safety requirement level VM is started.

Further, in the above embodiment, the case where the authenticity of the common software group 210 is verified and then the authenticity of the VM software group 230 is verified has been described as an example, but the present invention is not limited to this. The order of the verification of the authenticity of the common software group 210 and the verification of the authenticity of the VM software group 230 may be changed. In this case, as shown in FIG. 12, in step S103, whether the system safety requirement level of the VM 110 to be activated by the diversion determination unit 320 is "high", "medium", or "low". Is determined. If the system safety requirement level of the VM110 to be activated is "medium" or "high", the process proceeds to step S107. If the system safety requirement level of the VM110 to be activated is "low", the process proceeds to step S109.

In step S107, the verification unit 330 verifies the authenticity of the VM software group 230 of the VM 110 by using the security module 20G.

In step S108, the verification unit 330 determines whether or not the verification result of step S107 is a verification result of authenticity. If the verification result in step S107 is not genuine, the process proceeds to step S110. On the other hand, if the verification result in step S107 is a verification result indicating that it is genuine, the process proceeds to step S104.

In step S104, the diversion determination unit 320 determines whether or not the common software group 210 has been verified in the verification of the other VM 110. If the common software group 210 has been verified in the verification of another VM 110, the diversion determination unit 320 determines that the verification result of the common software group 210 will be diverted, and proceeds to step S109. If the common software group 210 has not been verified in the verification of another VM110, the process proceeds to step S105.

In step S105, the verification unit 330 verifies the authenticity of the common software group 210 by using the security module 20G.

In step S106, the verification unit 330 determines whether or not the verification result of step S105 is a verification result of authenticity. If the verification result in step S105 is not genuine, the process proceeds to step S110, the CPU 20A outputs a start error, and ends the start process. On the other hand, if the verification result in step S105 is the verification result that it is genuine, the process proceeds to step S109.

Further, in the above embodiment, the case where the safety requirement level is used as an index given to each VM 110 has been described as an example, but the present invention is not limited to this. As an index given to each VM 110, for example, the security level of the software of the VM 110 may be given. In this case, if the software security level is high, it is determined that the authenticity verification result of the common software group 210 obtained in the verification of other VM110s is diverted, while if the software security level is low, it is determined to be diverted. The authenticity of the VM software group 230 and the common software group 210 of the VM 110 is verified without diverting the verification result of the authenticity of the common software group 210 obtained in the verification of the other VM 110.

Further, in the above embodiment, the case of verifying the authenticity of the VM software group 230 and the common software group 210 of each VM 110 has been described as an example, but the present invention is not limited thereto. For example, the validity of the issuers of the VM software group 230 and the common software group 210 of each VM 110 may be verified.

Further, in the above embodiment, the case where the VM 110 is started based on the VM start order list 220 has been described as an example, but the present invention is not limited to this. The activation order of the VM 110 may be fixed in the control program 200. In this case, it is not necessary to determine the VM 110 to be activated in the activation process. Alternatively, the startup VM determination unit 310 may scan the VM software group 230 in the storage 20F or the ROM 20B without using the VM startup order list 220 to determine the startup order of the VM 110.

Further, the processing in which the CPU 20A reads and executes the software (program) in the above embodiment may be executed by various processors other than the CPU. In this case, the processor includes a PLD (Programmable Logic Device) whose circuit configuration can be changed after manufacturing an FPGA (Field-Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), and the like. An example is a dedicated electric circuit or the like, which is a processor having a circuit configuration designed exclusively for it. Further, each process may be executed by one of these various processors, or a combination of two or more processors of the same type or different types (for example, a plurality of FPGAs, and a combination of a CPU and an FPGA, etc.). ) May be executed. Further, the hardware-like structure of these various processors is, more specifically, an electric circuit in which circuit elements such as semiconductor elements are combined.

Further, in the above embodiment, the program has been described in a manner in which the program is pre-stored (installed) in a non-temporary recording medium that can be read by a computer. For example, in the ECU 20, the control program 200 is stored in the ROM 20B in advance. However, the present invention is not limited to this, and each program may be stored in a storage such as an HDD (Hard Disk Drive) and an SSD. In addition, each program is recorded on a non-temporary recording medium such as a CD-ROM (Compact Disc Read Only Memory), a DVD-ROM (Digital Versaille Disc Read Only Memory), and a USB (Universal Serial Bus) memory. May be provided. Further, each program may be downloaded from an external device via a network.

The processing flow described in the above embodiment is also an example, and unnecessary steps may be deleted, new steps may be added, or the processing order may be changed within a range that does not deviate from the gist.

10 Vehicle control device 12 Vehicle 20 ECU
20B ROM (storage unit)
20F storage (storage unit)
110 VM (Virtual Machine)
110A multimedia VM
110B body control VM
110C automatic operation control VM
200 Control program 210, 210AB, 210CD Common software group (common software)
220 Boot order list 230 VM software group (VM software)
230A Multimedia VM software group 230B Body control VM software group 230C Automatic operation control VM software group 300 VM component unit 320 Diversion judgment unit 330 Verification unit 340 Startup unit

Claims (7)

A storage unit that stores VM software, which is software of a plurality of VMs (Virtual Machines) that control devices mounted on a vehicle, and common software shared by two or more VMs.
When verifying the software of each of the VMs, a verification unit that diverts the verification results of the common software obtained in the verification of the software of the other VMs according to the index given in advance to the VM. ,
Vehicle control device. When verifying the software of each VM, whether or not to divert the verification result of the common software obtained in the verification of other VM software according to the index given in advance to the VM. Further equipped with a diversion judgment unit to determine
The verification unit
If it is decided to divert the verification result of the common software obtained in the verification of the software of the other VM, the verification result of the common software obtained in the verification of the software of the other VM is diverted. Then, verify the VM software and
The vehicle control device according to claim 1, wherein when it is determined not to divert the verification result of the common software obtained in the verification of the other VM software, the VM software of the VM and the common software are verified. .. The vehicle control device according to claim 1 or 2, wherein the verification unit verifies the authenticity of the VM software. The vehicle control device according to any one of claims 1 to 3, wherein the verification unit verifies the software of each of the VMs when the software of the plurality of VMs is activated. The vehicle control device according to any one of claims 1 to 4, wherein the index is a functional safety index related to the functional safety of the device controlled by the VM, or a security index related to the security of the software of the VM. A computer including a VM software that is software of a plurality of VMs (Virtual Machines) that control devices mounted on a vehicle, and a storage unit that stores common software shared by two or more VMs.
When verifying the software of each of the VMs, a verification step of diverting the verification result of the common software obtained in the verification of the software of the other VMs according to the index given in advance to the VM is performed. How to control the vehicle to be equipped. A computer including a VM software that is software of a plurality of VMs (Virtual Machines) that control devices mounted on a vehicle, and a storage unit that stores common software shared by two or more VMs.
When verifying the software of each of the VMs, a verification step of diverting the verification result of the common software obtained in the verification of the software of the other VMs according to the index given in advance to the VM is performed. A control program for executing the including processing.

Images