Control device and control method for vehicle, and recording medium having control program recorded

Abstract

This invention relates to a vehicle control device, a vehicle control method, and a recording medium recording a control program. The vehicle control device includes: a reuse determination unit that, when verifying the software of each virtual machine (VM), determines whether to reuse the verification results of common software obtained from the verification of other VMs based on pre-assigned indicators to the VMs; and a verification unit that, when determining that the verification results of common software obtained from the verification of other VMs should be reused, uses the verification results of common software obtained from the verification of other VMs and verifies the VM's software.

Description

Technical Field

[0001] This disclosure relates to vehicle control devices, vehicle control methods, and recording media containing control programs. Background Technology

[0002] Development is underway to integrate the functions of a vehicle's ECU into a single control unit as software. For example, Japanese Patent No. 5236367 discloses a technique for reducing VM startup time and saving memory by sharing program modules between virtual machines (VMs).

[0003] Here, in the case where multiple software programs with the functions of the vehicle's ECU are executed by a single control device, this can be achieved by constructing multiple VMs (Virtual Machines). In this case, since the reliability of the software required to construct the VMs is verified during ECU startup, the time spent on reliability verification increases proportionally with the number of VMs as the number of VMs increases, resulting in an increase in the time until all VMs have started up. Summary of the Invention

[0004] The purpose of this disclosure is to provide a vehicle control device, a vehicle control method, and a recording medium containing a control program, which reduce the time spent verifying software shared by multiple VMs by re-using the verification results of software shared by multiple VMs.

[0005] The first method relates to a vehicle control device, comprising: a storage unit that stores software of multiple Virtual Machines (VMs) for controlling devices mounted on the vehicle, i.e., VM software, and common software shared by two or more of the VMs; and a verification unit that, when verifying the software of each VM, uses the verification results of the common software obtained from the verification of the software of other VMs based on pre-assigned indicators to the VMs.

[0006] In the vehicle control device of the first embodiment, the storage unit stores software for multiple virtual machines (VMs) that control devices mounted on the vehicle, as well as common software shared by two or more of the VMs. In this vehicle control device, when the software of each VM is verified by the verification unit, the verification results of the common software obtained from the verification of the other VMs are used, based on pre-assigned indicators to the VMs. This reduces the time spent verifying the software of multiple VMs and eliminates the need for repeated verification of the common software. In other words, by using the verification results of the software shared by multiple VMs, the time spent verifying the software of multiple VMs can be reduced.

[0007] The vehicle control device of the second embodiment is based on the vehicle control device of the first embodiment. It further includes a reuse determination unit that, when verifying the software of each VM, determines whether to reuse the verification results of the common software obtained from the verification of other VMs based on pre-assigned indicators to the VM. If it is determined that the verification results of the common software obtained from the verification of other VMs should be reused, the verification unit uses the verification results of the common software obtained from the verification of other VMs and verifies the software of the VM. If it is determined that the verification results of the common software obtained from the verification of other VMs should not be reused, the verification unit verifies both the VM software of the VM and the common software. Therefore, when it is determined that the verification results of the common software obtained from the verification of other VMs should be reused, the verification of the common software is not repeated, thus shortening the time spent verifying the software of multiple VMs.

[0008] The control device for the vehicle in the third embodiment is based on the control device for the vehicle in the first or second embodiment, and the verification unit verifies the reliability of the software of the VM. This reduces the time spent verifying the reliability of the software of multiple VMs. Verifying reliability refers to verifying that the software has not been tampered with.

[0009] The vehicle control device of the fourth method is based on the vehicle control device of any of the methods 1 to 3. When the software of the multiple VMs is started, the verification unit verifies the software of each VM. This reduces the time spent starting the software of the multiple VMs. Starting the VM software refers to reading the VM software and common software from the storage unit and expanding them.

[0010] The vehicle control device of the fifth method is based on the vehicle control device of any of the methods 1 to 4. The aforementioned indicators are functional safety indicators related to the functional safety of the equipment controlled by the VM or security indicators related to the security of the VM's software. Therefore, it is possible to balance the functional safety of the equipment controlled by the VM or the security of the VM's software with a reduction in the time spent verifying the software of multiple VMs.

[0011] The sixth method relates to a vehicle control method, which includes the following verification step: a computer, which stores software (i.e., VM software) for multiple VMs that control devices mounted on the vehicle and common software shared by two or more of the VMs, verifies the common software obtained from the verification of the software of other VMs based on pre-assigned indicators to the VMs.

[0012] The vehicle control method of the sixth method, when verifying the software of each VM through a verification step, uses the verification results of the common software obtained from the verification of the software of other VMs, based on pre-assigned indicators to the VMs. This reduces the time spent verifying the software of multiple VMs and eliminates the need for repeated verification of the common software. In other words, by using the verification results of software shared by multiple VMs, the time spent verifying the software of multiple VMs can be shortened.

[0013] The seventh method is a non-transitory recording medium that records a control program that causes a computer, including a storage unit, to execute a verification step, wherein the storage unit stores software of multiple Virtual Machines (VMs) that control devices mounted in a vehicle, i.e., VM software, and common software shared by two or more of the VMs. The verification step refers to the verification result of the common software obtained by applying pre-assigned indicators to the software of other VMs when verifying the software of each VM.

[0014] The seventh method, using a non-transitory recording medium containing control programs, verifies the software of each of the aforementioned VMs through a verification step. It then uses the verification results of the common software obtained from the verification of the software of other VMs, based on pre-assigned metrics to the VMs. This reduces the time spent verifying the software of multiple VMs by eliminating the need for repeated verification of the common software. In other words, by using the verification results of software shared by multiple VMs, the time spent verifying the software of multiple VMs can be shortened.

[0015] According to this disclosure, by using the verification results of software shared by multiple VMs, the time spent on verifying software across multiple VMs can be shortened. Attached Figure Description

[0016] The embodiments of this disclosure are described in detail based on the following figures, wherein:

[0017] Figure 1 This is a block diagram illustrating the hardware structure of the vehicle according to the first embodiment.

[0018] Figure 2 This is a block diagram illustrating an example of the functional structure of the vehicle according to the first embodiment.

[0019] Figure 3 This is a flowchart illustrating the startup process in the first embodiment.

[0020] Figure 4 This is a flowchart illustrating the startup process in the first embodiment. Figure 3 specific examples).

[0021] Figure 5 This is a block diagram illustrating an example of the functional structure of the vehicle according to the second embodiment.

[0022] Figure 6 This is a block diagram illustrating an example of the functional structure of the vehicle according to the third embodiment.

[0023] Figure 7 This is a block diagram illustrating an example of the functional structure of the vehicle according to the fourth embodiment.

[0024] Figure 8 This is a block diagram illustrating an example of the functional structure of the vehicle according to the fifth embodiment.

[0025] Figure 9 This is a flowchart illustrating the startup process in the fifth embodiment.

[0026] Figure 10 This is a flowchart illustrating the startup process in another example of the fifth embodiment.

[0027] Figure 11 This is a block diagram illustrating an example of the functional structure of a vehicle in other embodiments of the implementation.

[0028] Figure 12 This is a flowchart illustrating the startup process in other examples of implementation methods. Detailed Implementation

[0029] [First Implementation]

[0030] Figure 1 This is a block diagram illustrating the control system of the vehicle 12 according to the first embodiment.

[0031] (constitute)

[0032] like Figure 1 As shown, the vehicle 12 according to the first embodiment is configured to include an ECU (Electronic Control Unit) 20, which serves as a vehicle control device (hereinafter referred to as "control device") 10, and an on-board equipment group 16 connected to the ECU 20. The on-board equipment group 16 consists of sensors installed in the vehicle 12, including sensors installed in various parts of the vehicle body and engine. In addition, the on-board equipment group 16 consists of drive devices installed in the vehicle 12, including motors, valves, and actuators installed in various parts of the vehicle body and engine.

[0033] ECU 20 is configured to include a CPU (Central Processing Unit) 20A, a ROM (Read Only Memory) 20B, a RAM (Random Access Memory) 20C, a communication I / F (Interface) 20D, an input / output I / F (Interface) 20E, a storage device 20F, and a safety module 20G. The CPU 20A, ROM 20B, RAM 20C, communication I / F 20D, input / output I / F 20E, storage device 20F, and safety module 20G are connected via a bus 20H and are capable of communicating with each other. The CPU 20A is an example of a processor.

[0034] CPU 20A is the central processing unit, which executes various programs and controls various parts. That is, CPU 20A reads programs from ROM 20B and uses RAM 20C as the working area to execute the programs. In this embodiment, there may be multiple CPUs 20A (so-called multiprocessors), or CPU 20A may have multiple cores (so-called multicores).

[0035] ROM 20B stores various programs and data. In this embodiment, ROM 20B stores a control program 200. The control program 200 is a program used to perform the startup process described later. In addition, ROM 20B stores a common software group 210 shared by multiple VMs.

[0036] RAM20C is used as a working area to temporarily store programs or data.

[0037] The Communication I / F20D is an interface for connecting to other devices located in vehicle 12. This interface can use communication standards such as CAN (Controller Area Network) and Ethernet (registered trademark).

[0038] The input / output I / F20E is an interface used to communicate with the on-board equipment group 16 mounted on the vehicle 12.

[0039] The storage device 20F stores a VM startup sequence list 220. The VM startup sequence list 220 specifies the startup order of each VM when it is started. The VM startup sequence list 220 also assigns predetermined indicators to each VM. For example, a system safety requirement level for the VM can be used. Here, the system safety requirement level is the level of safety required for the VM based on a combination of the types and probabilities of problems caused by ECU malfunctions, faults, etc. In the case of vehicles, the safety level is defined as ASIL (Automotive Safety Integrity Level) for the electronic control system of a vehicle in ISO 26262. Specifically, VMs that have the potential to cause harm to humans or damage to property due to system malfunctions are assigned a "high" system safety requirement level. On the other hand, VMs that do not require system safety, i.e., VMs that do not have the potential to cause harm to humans or damage to property due to system malfunctions, are assigned a "low" system safety requirement level. All other VMs are assigned a "medium" system safety requirement level.

[0040] Additionally, storage 20F stores two or more VM software groups 230 for each of the VMs. These two or more VM software groups 230 include, for example, a multimedia VM software group 230A for constituting the multimedia VM described later, a body control VM software group 230B for constituting the body control VM described later, and an autonomous driving control VM software group 230C for constituting the autonomous driving control VM described later. Furthermore, the VM software group 230 also includes VM software groups 230 corresponding to specific applications.

[0041] The storage device 20F can be implemented using ROM, hard disk, or various flash memory devices (SSD (Solid State Drive), eMMC (embedded Multi Media Card), SD (Secure Digital), etc.).

[0042] The security module 20G is used to verify software reliability through hardware, such as a TPM (Trusted Platform Module) or HSM (Hardware Security Module). For example, the security module 20G verifies software reliability by performing encryption or decryption using the stored key and an encryption or decryption accelerator, or by performing hash calculations.

[0043] Figure 2This is a block diagram illustrating an example of the functional structure of ECU20. Each functional structure is implemented by CPU20A reading and executing the control program 200 stored in ROM20B.

[0044] like Figure 2 As shown, the ECU20 has two or more VMs 110 and a VM component 300. The VMs 110 include, for example, a multimedia VM 110A, a body control VM 110B, and an autonomous driving control VM 110C.

[0045] Furthermore, the VM110 implemented in ECU20 is not limited to this and may also include VM110 corresponding to the application.

[0046] The VM configuration unit 300 has the function of virtually configuring each VM 110. This VM configuration unit 300 is implemented through a so-called hypervisor function, which, at startup, reads the VM startup order list 220 from memory 20F, and reads the VM software group 230 and the common software group 210 according to the startup order specified in the VM startup order list 220, and then starts the VM 110. Specifically, the VM configuration unit 300 expands the VM software group 230 and the common software group 210 in RAM 20C to start the VM 110.

[0047] The VM configuration unit 300 also includes a VM startup determination unit 310, a reuse determination unit 320, a verification unit 330, and a startup unit 340.

[0048] The VM startup determination unit 310 determines the VM110 to be started based on the startup order specified in the VM startup order list 220, and obtains the system security requirement level of the VM110.

[0049] When verifying the VM software group 230 of each VM110, the decision-making unit 320 determines whether to use the verification results of the common software group 210 obtained from the verification of the VM software groups 230 of other VM110s, based on the system security requirement level pre-assigned to that VM110. Specifically, if the system security requirement level of that VM110 is "high", the decision-making unit 320 decides not to use the verification results of the common software group 210. For example, since the system security requirement level of the body control VM110B is assigned to "high", it is decided not to use the verification results of the common software group 210 for the body control VM110B.

[0050] When the system security requirement level of VM110 is "medium", the decision unit 320 decides to use the verification results of the common software group 210 obtained from the verification of VM software group 230 of other VM110s. For example, since the system security requirement level of the autonomous driving control VM110C is assigned to "medium", the verification results of the common software group 210 are used for the autonomous driving control VM110C.

[0051] If the system security requirement level of the VM is "low", the judgment unit 320 decides not to perform the verification of the VM software group 230 of the VM110. For example, since the multimedia VM110A is assigned a system security requirement level of "low", it is decided not to perform the verification of the multimedia VM software group 230A.

[0052] When multiple VMs 110 are started, the verification unit 330 verifies the reliability of the VM software group 230 of each VM 110. At this time, if it is decided not to use the verification results of the common software group 210 obtained from the verification of the VM software group 230 of other VMs 110, the verification unit 330 verifies the reliability of the VM software group 230 of that VM 110 without using the verification results of the common software group 210 obtained from the verification of the VM software group 230 of other VMs 110. For example, if it is decided not to use the verification results of the common software group 210, the verification unit 330 uses the security module 20G to verify the reliability of the VM software group 230 of that VM 110 and the common software group 210.

[0053] If it is decided to use the verification results of the common software group 210, the verification unit 330 uses the security module 20G to verify the reliability of the VM software group 230 of the VM110, and omits the verification of the common software group 210.

[0054] If it is decided not to perform verification of VM software group 230, the verification unit 330 omits the verification of VM software group 230 and common software group 210 of VM 110.

[0055] For each VM110, if the reliability of the VM software group 230 and the common software group 210 of the VM110 is successfully verified, the startup unit 340 expands the VM software group 230 and the common software group 210 of the VM110 in RAM 20C and starts the VM110.

[0056] (Control process)

[0057] use Figure 3 The flowchart illustrates an example of the startup process performed by ECU10 in this embodiment.

[0058] exist Figure 3 In step S100, CPU20A starts the super administrator program as software.

[0059] In step S101, the VM startup determination unit 310 determines the VM110 to be started according to the startup order specified in the VM startup order list 220, and obtains the system security requirement level of the VM110.

[0060] In step S102, the VM determination unit 310 is activated to determine whether there is an unactivated VM110. If it is determined that the VM110 to be activated in step S101 is present, the process proceeds to step S103. On the other hand, if it is not determined that the VM110 to be activated in step S101 is present, the startup process ends.

[0061] In step S103, the determination unit 320 determines whether the system security requirement level of the VM110 to be started is "high," "medium," or "low." If the system security requirement level of the VM110 to be started is "high," proceed to step S105. If the system security requirement level of the VM110 to be started is "medium," proceed to step S104. If the system security requirement level of the VM110 to be started is "low," proceed to step S109.

[0062] In step S104, the validation determination unit 320 determines whether the common software group 210 has been validated in the validation of other VMs 110. If the common software group 210 has been validated in the validation of other VMs 110, the validation determination unit 320 determines that the validation result for the common software group 210 is valid and proceeds to step S107. If the common software group 210 has not been validated in the validation of other VMs 110, proceeds to step S105.

[0063] In step S105, the verification unit 330 uses the security module 20G to verify the reliability of the common software group 210.

[0064] In step S106, the verification unit 330 determines whether the verification result of step S105 is authentic. If the verification result of step S105 is unauthentic, the process proceeds to step S110, where the CPU 20A outputs a startup error and terminates the startup process. On the other hand, if the verification result of step S105 is authentic, the process proceeds to step S107.

[0065] In step S107, the verification unit 330 uses the security module 20G to verify the authenticity of the VM software group 230 of the VM110.

[0066] In step S108, the verification unit 330 determines whether the verification result of step S107 is reliable. If the verification result of step S107 is unreliable, the process proceeds to step S110. On the other hand, if the verification result of step S107 is reliable, the process proceeds to step S109.

[0067] In step S109, the startup unit 340 expands the VM software group 230 and the common software group 210 of the VM110 to be started in RAM 20C to start the VM110, and then returns to step S101 above.

[0068] use Figure 4 The flowchart illustrates a specific example of the startup process performed by ECU10. Here, we will take the case where the VM startup sequence list 220 specifies that the multimedia VM110A, body control VM110B, and automatic driving control VM110C are started sequentially as an example.

[0069] In steps S101A to S109A, the multimedia VM110A is selected as the VM110 to be started, in accordance with the above... Figure 3 Steps S101 to S109 are processed in the same way. At this time, since the system security requirement level of the multimedia VM110A is "low", in step S103A, it is determined that the system security requirement level of the multimedia VM110A to be started is "low". Therefore, no reliability verification is performed on either the multimedia VM software group 230A or the common software group 210, and the process proceeds to step S109A.

[0070] Then, in steps S101B to S109B, the vehicle body control VM110B is selected as the VM110 to be activated, in conjunction with the above... Figure 3 Steps S101 to S109 are processed in the same way. 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 started is "high". In steps S105B and S107B, the reliability of both the body control VM software group 230B and the common software group 210 is verified.

[0071] Then, in steps S101C to S109C, the automatic driving control VM110C is selected as the VM110 to be activated, in conjunction with the above... Figure 3 Steps S101 to S109 are processed similarly. At this time, since the system safety requirement level of the autonomous driving control VM110C is "medium," it is determined in step S103C that the system safety requirement level of the autonomous driving control VM110C to be activated is "medium." Furthermore, 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 reliability of the autonomous driving control VM software group 230C is verified.

[0072] (Summary of the first implementation method)

[0073] In the control device 10 of this embodiment, by using the verification results of a common software group shared by multiple VMs, the time spent on verifying the software group of multiple VMs can be shortened.

[0074] Furthermore, the control device 10 in this embodiment can balance the functional safety of the device controlled by the VM with the reduction of the time spent on verifying the software of multiple VMs.

[0075] Furthermore, in the control device 10 of this embodiment, to ensure safety in case of ECU failure, verification is performed during ECU startup to confirm that there is no tampering in the VM software group. It is assumed that the verification of the common software group performed during ECU startup has been completed under specific conditions, thus shortening the startup time. Moreover, the verification of the common software group is re-verified based on the required security level of the VM, thereby ensuring the safety of the system.

[0076] Furthermore, for VMs with high system security requirements, there is a possibility that system anomalies could cause harm to humans or damage to property. Before the VM starts, the ECU20 uses a security module to verify whether the VM software group 230 and the common software group 210 constituting the VM have been tampered with due to certain important factors. On the other hand, for VMs that do not require system security, i.e., VMs that do not have the possibility of causing harm to humans or damage to property due to system anomalies, software reliability verification is not necessary, so software group reliability verification is not performed in order to shorten VM startup time.

[0077] [Second Implementation]

[0078] In the first embodiment, the ECU 20 is provided with a ROM 20B. In contrast, the second embodiment differs from the first embodiment in that the ECU 20 is not provided with a ROM 20B. The differences from the first embodiment will be described below. Furthermore, identical reference numerals are used to refer to the same structures, and descriptions are omitted.

[0079] like Figure 5 As shown, the ECU20 of this embodiment is configured to include a CPU20A, RAM20C, communication I / F20D, input / output I / F20E, storage 20F, and safety module 20G.

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

[0081] In this embodiment, the same effects as in the first embodiment can be achieved.

[0082] [Third Implementation]

[0083] In the first embodiment, a storage device 20F is provided in the ECU 20. In contrast, the third embodiment differs from the first embodiment in that the storage device 20F is not provided in the ECU 20. Hereinafter, the differences from the first embodiment will be described. Furthermore, the same reference numerals are used to refer to the same structures, and descriptions are omitted.

[0084] like Figure 6 As shown, the ECU20 of this embodiment is configured to include a CPU20A, a ROM20B, a RAM20C, a communication I / F20D, an input / output I / F20E, and a safety module 20G.

[0085] The ROM 20B stores a VM boot order list 220 and two or more VM software groups 230.

[0086] In this embodiment, the same effects as in the first embodiment can be achieved.

[0087] [Fourth Implementation]

[0088] In the fourth embodiment, unlike the first embodiment, an EEPROM (Electrically Erasable Programmable Read-Only Memory) 420B is used instead of the ROM 20B. The differences from the first embodiment will be described below. Furthermore, the same reference numerals are used to refer to the same structures, and descriptions are omitted.

[0089] like Figure 7 As shown, the ECU20 of this embodiment is configured to include a CPU20A, an EEPROM420B, a RAM20C, a communication I / F20D, an input / output I / F20E, a memory 20F, and a safety module 20G.

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

[0091] In this embodiment, the same effects as in the first embodiment can be achieved.

[0092] [Fifth Implementation]

[0093] Compared to the first embodiment, the fifth embodiment differs in that the ECU 20 is equipped with a safety module 20I in addition to the safety module 20G. The differences from the first embodiment will be described below. Furthermore, identical reference numerals are used to refer to the same structures, and descriptions are omitted.

[0094] (constitute)

[0095] like Figure 8 As shown, the ECU20 of this embodiment is configured to include a CPU20A, a ROM20B, a RAM20C, a communication I / F20D, an input / output I / F20E, a storage 20F, a safety module 20G, and a safety module 20I.

[0096] When starting the software of multiple VMs, the verification unit 330 uses security module 20G and security module 20I to verify the reliability of the software of each VM in parallel.

[0097] (Control process)

[0098] In this embodiment, using Figure 9 The flowchart illustrates an example of the startup process performed by ECU10. Furthermore, processes identical to those described in the above embodiment are labeled with the same reference numerals and their descriptions are omitted.

[0099] exist Figure 9 In step S100, CPU20A starts the super administrator program as software.

[0100] In step S101, the VM startup determination unit 310 determines the VM110 to be started according to the startup order specified in the VM startup order list 220, and obtains the system security requirement level of the VM110. Here, two VM110s to be started are determined.

[0101] In step S102, the VM determination unit 310 is activated to determine whether there is an unactivated VM110. If it is determined that the VM110 to be activated in step S101 is present, the process proceeds to step S500. On the other hand, if it is not determined that the VM110 to be activated in step S101 is present, the startup process ends.

[0102] In step S500, CPU 20A executes the startup process of the two VMs 110 to be started in parallel. This step S500 uses security modules 20G and 20I to perform the startup processes of the two VMs 110 in parallel as described above. Figure 3 The same process applies to steps S103 to S110. Then, return to step S101.

[0103] In this embodiment, the same effects as in the first embodiment can be achieved.

[0104] In addition, it enables the parallelization of VM110 startup, which can shorten the VM startup time while ensuring safety.

[0105] [Remark]

[0106] Furthermore, while the fifth embodiment described above exemplifies the parallelization of VM110 startup, it is not a limitation. The verification of software group reliability can also be parallelized. Utilizing... Figure 10 The flowchart illustrates an example of the startup process performed by ECU10 in this situation. Furthermore, processes identical to those described in the above embodiment are labeled with the same reference numerals and their descriptions are omitted.

[0107] exist Figure 10 In step S104, the judgment unit 320 determines whether the common software group 210 has been verified in the verification of other VMs 110. If the common software group 210 has been verified in the verification of other VMs 110, the judgment unit 320 determines that the verification result related to the common software group 210 is used, and proceeds to step S107. If the common software group 210 has not been verified in the verification of other VMs 110, proceeds to step S600.

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

[0109] In step S601, the verification unit 330 determines whether the verification result of step S107 or S600 is reliable. If the verification result of step S107 or S600 is unreliable, the process proceeds to step S110. On the other hand, if the verification result of step S107 or S600 is reliable, the process proceeds to step S109.

[0110] Furthermore, in the above implementation, the system safety requirement level is set to three levels: "high," "medium," and "low." However, the system safety requirement level can be further subdivided according to the characteristics or safety requirements of the ECU. In ISO 26262, ASIL consists of five levels: four levels (A to D) plus an external factor. Whether to adopt the verification results of common software group 210 can be determined based on which of these five levels is being applied.

[0111] Furthermore, in the above embodiment, the example described is the verification of the reliability of both VM software group 230 and common software group 210 when starting the VM with the highest security requirement level, but it is not limited to this. When subdividing the security requirement levels, the verification of the reliability of both VM software group 230 and common software group 210 can be performed up to the first two levels.

[0112] Furthermore, while the above embodiment exemplifies a single common software group 210, the existence of multiple common software groups 210 may be considered depending on the content of the VM to be started. In this case, such as Figure 11 As shown, ROM 20B stores common software groups 210AB and 210CD. For example, the multimedia VM110A shares common software group 210AB with the body control VM110B, while the autonomous driving control VM110C shares common software group 210CD with other VMs 110. In this case, the VM startup sequence list 220 needs to specify information about the common software group 210 associated with each VM 110. Furthermore, the VM configuration unit 300 needs to store information about which common software group 210 was used for reliability verification during VM startup at which system safety requirement level.

[0113] Furthermore, in the above embodiment, the example described is the verification of the reliability of the common software group 210 followed by the verification of the reliability of the VM software group 230, but it is not limited to this. The order of verifying the reliability of the common software group 210 and the VM software group 230 can also be changed. In this case, as... Figure 12 As shown, in step S103, the determination unit 320 determines whether the system security requirement level of the VM110 to be started is "high," "medium," or "low." If the system security requirement level of the VM110 to be started is "medium" or "high," proceed to step S107. If the system security requirement level of the VM110 to be started is "low," proceed to step S109.

[0114] In step S107, the verification unit 330 uses the security module 20G to verify the reliability of the VM software group 230 of the VM110.

[0115] In step S108, the verification unit 330 determines whether the verification result of step S107 is reliable. If the verification result of step S107 is unreliable, the process proceeds to step S110. On the other hand, if the verification result of step S107 is reliable, the process proceeds to step S104.

[0116] In step S104, the judgment unit 320 determines whether the common software group 210 has been verified in the verification of other VMs 110. If the common software group 210 has been verified in the verification of other VMs 110, the judgment unit 320 determines that the verification result related to the common software group 210 is used, and proceeds to step S109. If the common software group 210 has not been verified in the verification of other VMs 110, proceeds to step S105.

[0117] In step S105, the verification unit 330 uses the security module 20G to verify the reliability of the common software group 210.

[0118] In step S106, the verification unit 330 determines whether the verification result of step S105 is reliable. If the verification result of step S105 is unreliable, the process proceeds to step S110, where the CPU 20A outputs a startup error and terminates the startup process. On the other hand, if the verification result of step S105 is reliable, the process proceeds to step S109.

[0119] Furthermore, in the above embodiment, the example described uses the security requirement level as the indicator assigned to each VM110, but it is not limited to this. For example, the security level of the software of each VM110 can also be assigned as the indicator. In this case, if the security level of the software is high, it is determined that the verification result of the reliability of the common software group 210 obtained from the verification of other VM110s is used. On the other hand, if the security level of the software is low, the reliability of the VM software group 230 and the common software group 210 of the VM110 is verified, instead of using the verification result of the reliability of the common software group 210 obtained from the verification of other VM110s.

[0120] Furthermore, in the above embodiment, the example described is the verification of the reliability of the VM software group 230 and the common software group 210 of each VM 110, but it is not limited to this. For example, the appropriateness of the issuer of the VM software group 230 and the common software group 210 of each VM 110 can also be verified.

[0121] Furthermore, in the above embodiment, the case where VM110 is gradually started based on VM boot order list 220 has been described as an example, but it is not limited to this. The boot order of VM110 can also be fixed within the control program 200. In this case, it is not necessary to determine which VM110 to be started within the boot process. Alternatively, the VM startup determination unit 310 can scan the VM software group 230 in the memory 20F or ROM 20B to determine the boot order of VM110 without using VM boot order list 220.

[0122] Furthermore, in the above embodiment, the processing of the CPU 20A reading and executing software (program) can be performed by various processors other than the CPU. Examples of such processors include FPGAs (Field-Programmable Gate Arrays) and processors with dedicated circuit structures designed for specific processing, such as PLDs (Programmable Logic Devices) and ASICs (Application Specific Integrated Circuits). Additionally, each process can be executed by one of these various processors, or by a combination of two or more processors of the same or different types (e.g., multiple FPGAs and a combination of a CPU and an FPGA). Moreover, the hardware configuration of these various processors is more specifically a circuit that incorporates circuit elements such as semiconductor components.

[0123] Furthermore, in the above embodiments, the method described is that the program is pre-stored (installed) on a computer-readable non-transitory recording medium. For example, in ECU 20, the control program 200 is pre-stored in ROM 20B. However, it is not limited to this; the programs may also be stored in storage devices such as HDD (Hard Disk Drive) and SSD. Additionally, the programs may be provided by recording on non-transitory recording media such as CD-ROM (Compact Disc Read Only Memory), DVD-ROM (Digital Versatile Disc Read Only Memory), and USB (Universal Serial Bus) storage. Alternatively, the programs may be downloaded from an external device via a network.

[0124] The processing flow described in the above embodiments is also an example. Unnecessary steps can be deleted, new steps can be added, and the processing order can be changed without departing from the main idea.

Claims

1. A vehicle control device, wherein, have: The storage unit stores software for multiple VMs that control devices mounted in the vehicle, i.e., VM software, as well as common software shared by two or more of the VMs; and The verification department, when verifying the software of each VM, uses the verification results of the common software obtained from the verification of the software of other VMs, based on the pre-assigned indicators to the VM. It also includes a reuse determination unit that, when verifying the software of each VM, determines whether to reuse the verification results of the common software obtained from the verification of the software of other VMs based on pre-assigned indicators to the VM. The reuse determination unit decides whether to reuse the verification results of the common software obtained from the verification of other VMs' software based on the pre-assigned system security requirement level for the VM. If the system security requirement level of the VM is "high," it decides not to reuse the verification results of the common software; if the system security requirement level of the VM is "medium," it decides to reuse the verification results of the common software obtained from the verification of other VMs' software; if the system security requirement level of the VM is "low," it decides not to perform software verification for the VM. When it is decided to use the verification results of the common software obtained from the verification of the software in other VMs, the verification unit uses the verification results of the common software obtained from the verification of the software in other VMs to verify the software of the VM. When it is decided that the verification result of the common software obtained in the verification of other VMs' software will not be used, the verification unit verifies the VM software of the VM and the common software.

2. The vehicle control device according to claim 1, wherein, The verification unit verifies the reliability of the software in the VM.

3. The vehicle control device according to claim 1, wherein, When the software of the plurality of VMs is started, the verification unit verifies the software of each of the VMs.

4. A method for controlling a vehicle, wherein, The verification process includes the following: a computer in a storage unit that stores software (i.e., VM software) that controls devices mounted in a vehicle, as well as common software shared by two or more of the VMs, verifies the software of each VM by using the verification results of the common software obtained from the verification of the software of other VMs, based on pre-assigned indicators to the VMs. It also includes a process of determining, when verifying the software of each VM, whether to use the verification results of the common software obtained from the verification of the software of other VMs, based on pre-assigned metrics to the VM. The decision to use the common software verification results obtained from the verification of other VMs' software is based on the pre-assigned system security requirement level for the VM. If the VM's system security requirement level is "high," the decision is not to use the common software verification results. If the VM's system security requirement level is "medium," the decision is to use the common software verification results obtained from the verification of other VMs' software. If the VM's system security requirement level is "low," the decision is not to perform software verification for the VM. If it is determined that the verification results of the common software obtained from the verification of the software in other VMs should be used, then the verification results of the common software obtained from the verification of the software in other VMs should be used to verify the software of the VM. When it is decided not to use the verification results of the common software obtained in the verification of other VMs, the VM software of the VM and the common software are verified.

5. A non-transitory recording medium, wherein, The system contains a control program for causing a computer, including a storage unit, to execute a verification process, wherein the storage unit stores software (VMs) for controlling devices mounted in a vehicle, as well as common software shared by two or more of the VMs. The verification process refers to using the verification results of the common software obtained from the verification of the software of other VMs, based on pre-assigned metrics to each VM, during the verification of the software of each VM. It also includes a process of determining, when verifying the software of each VM, whether to use the verification results of the common software obtained from the verification of the software of other VMs, based on pre-assigned metrics to the VM. The decision to use the common software verification results obtained from the verification of other VMs' software is based on the pre-assigned system security requirement level for the VM. If the VM's system security requirement level is "high," the decision is not to use the common software verification results. If the VM's system security requirement level is "medium," the decision is to use the common software verification results obtained from the verification of other VMs' software. If the VM's system security requirement level is "low," the decision is not to perform software verification for the VM. If it is determined that the verification results of the common software obtained from the verification of the software in other VMs should be used, then the verification results of the common software obtained from the verification of the software in other VMs should be used to verify the software of the VM. When it is decided not to use the verification results of the common software obtained in the verification of other VMs, the VM software of the VM and the common software are verified.

Images