JP7707863B2 - Electronic control device, software update method, software update program, and electronic control system - Google Patents

Description

The present invention relates to an electronic control device, and primarily relates to an electronic control device for a vehicle, a method implemented by the electronic control device, a program executable by the electronic control device, and an electronic control system comprising the electronic control device.

Automobiles are equipped with various electronic control devices that are connected via an in-vehicle network. With the recent development of autonomous driving technology, the functions required of automobiles are becoming more complex, and the number of electronic control devices installed in automobiles is increasing. Therefore, it has been proposed to apply virtualization technology that can reduce the total number of electronic control devices by integrating multiple functions into a single electronic control device.

For example, Patent Document 1 discloses the construction of multiple virtual ECUs in an on-board computer using a virtualized operating system such as a hypervisor. According to the technology described in Patent Document 1, the physical resources required for the operation of terminal devices connected to the on-board computer via the ECUs are consolidated in the on-board computer, enabling efficient use of the physical resources.

JP 2020-173561 A

Here, the present inventors have found the following problem.
Since electronic control devices installed in vehicles include those that control vehicle operations such as driving and steering, it is desirable to always update them to the latest software in order to ensure the safety of the vehicle. However, even if the number of electronic control devices is reduced by using virtualization technology, if there are many virtual machines formed by virtualizing the electronic control devices, it may take a long time to update all of these virtual machines.

The present invention aims to reduce the time required to update virtual machine software.

An electronic control device according to one aspect of the present disclosure is an electronic control device having a virtual machine managed by a hypervisor, and includes a file acquisition unit (141) that acquires a file for updating software, and a storage unit (130, 144) that stores the file. The first virtual machine (140) is a virtual machine. The first virtual machine has a determination unit (146) that determines whether a first hypervisor (110) that manages the first virtual machine is the same as a second hypervisor (110, 120, 210) that manages a second virtual machine (150, 160, 230) connected to the first virtual machine, and a delivery unit (147) that delivers the file to the second virtual machine when the determination unit determines that the first hypervisor and the second hypervisor are different.

A software update method according to another aspect of the present disclosure is a software update method executed in an electronic control device having a virtual machine managed by a hypervisor, which obtains a file for updating software (S101), stores the file in a storage unit (130, 144) (S103), determines whether a first hypervisor (110) that manages a first virtual machine (140) that is the virtual machine is the same as a second hypervisor (110, 120, 210) that manages a second virtual machine (150, 160, 230) connected to the first virtual machine (S106), and delivers the file to the second virtual machine if the first hypervisor and the second hypervisor are different (S109).

A software update program according to another aspect of the present disclosure is a software update program executable on an electronic control device having a virtual machine managed by a hypervisor, which obtains a file for updating the software (S101), stores the file in a storage unit (130, 144) (S103), determines whether a first hypervisor (110) that manages a first virtual machine (140), which is the virtual machine, is the same as a second hypervisor (110, 120, 210) that manages a second virtual machine (150, 160, 230) connected to the first virtual machine (S106), and delivers the file to the second virtual machine if the first hypervisor and the second hypervisor are different (S109).

An electronic control system according to another aspect of the present disclosure is an electronic control system having a first electronic control device (10) and a second electronic control device (20), the first electronic control device having a first virtual machine (140) managed by a first hypervisor (110) includes a file acquisition unit (141) that acquires a file for updating software and a storage unit (130, 144) that stores the file, the first virtual machine includes a determination unit (146) that determines whether the first hypervisor is the same as a second hypervisor (210) that manages a second virtual machine (230) owned by the second electronic control device, and a delivery unit (147) that delivers the file to the second virtual machine when the determination unit determines that the first hypervisor and the second hypervisor are different, and the second virtual machine includes an update unit (231) that updates the second virtual machine using the file by accessing the storage unit or using the file delivered by the delivery unit.

The numbers in parentheses attached to the constituent elements of the invention described in the claims and this section indicate the correspondence between the present invention and the embodiments described below, and are not intended to limit the present invention.

The electronic control device, software update method, software update program, and electronic control system disclosed herein can reduce the time required to update software on a virtual machine.

FIG. 1 is a diagram for explaining an electronic control device according to a first and second embodiment, and an electronic control system including the electronic control device; FIG. 1 is a diagram for explaining the operation of the entire electronic control system according to the first embodiment. FIG. 1 is a diagram for explaining the operation of a distribution control unit according to the first and second embodiments. FIG. 1 is a diagram for explaining the operation of an update unit according to the first and second embodiments. FIG. 13 is a diagram for explaining a storage area of a real storage according to the second embodiment. FIG. 11 is a diagram for explaining a determination method performed by a determination unit of a first virtual machine according to the second embodiment; FIG. 10 is a diagram for explaining the operation of the entire electronic control system according to the second embodiment. FIG. 13 is a diagram for explaining a determination method performed by a determination unit of a first virtual machine in a modified example of the second embodiment. FIG. 1 is a diagram for explaining a modification of the electronic control device according to the first and second embodiments and an electronic control system including the electronic control device; FIG. 1 is a diagram for explaining a domain architecture to which the electronic control system according to the first and second embodiments is applied;

The following describes an embodiment of the present invention with reference to the drawings.

The present invention refers to the invention described in the claims or in the Means for Solving the Problems section, and is not limited to the following embodiments. Furthermore, at least the words in quotation marks refer to the words described in the claims or in the Means for Solving the Problems section, and are not limited to the following embodiments.

The configurations and methods described in the dependent claims of the claims are optional configurations and methods in the invention described in the independent claims of the claims. The configurations and methods of the embodiments corresponding to the configurations and methods described in the dependent claims, and the configurations and methods described only in the embodiments without being described in the claims, are optional configurations and methods in the present invention. The configurations and methods described in the embodiments when the description of the claims is broader than the description of the embodiments are also optional configurations and methods in the present invention in the sense that they are examples of the configurations and methods of the present invention. In either case, by being described in the independent claims of the claims, they become essential configurations and methods of the present invention.

The effects described in the embodiments are the effects when the configuration of the embodiment is an example of the present invention, and are not necessarily the effects of the present invention.

When there are multiple embodiments, the configurations disclosed in each embodiment are not limited to each embodiment, but can be combined across the embodiments. For example, a configuration disclosed in one embodiment may be combined with another embodiment. Also, the configurations disclosed in each of the multiple embodiments may be collected and combined.

The problem described in the problem that the invention is intended to solve is not a publicly known problem, but was discovered independently by the inventor, and this fact, together with the configuration and method of the present invention, affirms the inventive step of the invention.

1. Configuration common to each embodiment An electronic control device of each embodiment and an electronic control system including the electronic control device will be described with reference to Fig. 1. The electronic control device and electronic control system of each embodiment are assumed to be an in-vehicle device and an in-vehicle system "mounted" on a vehicle, which is a "moving body", but are not limited thereto.

Here, the term "mobile body" refers to an object that can move and can move at any speed. It also includes cases where the moving body is stationary. For example, it includes, but is not limited to, automobiles, motorcycles, bicycles, pedestrians, ships, aircraft, and objects mounted on these vehicles.
In addition, "mounted" includes not only the case where the device is directly fixed to the moving body, but also the case where the device is not fixed to the moving body but moves with the moving body, such as the case where the device is carried by a person riding on the moving body, or the case where the device is mounted on cargo placed on the moving body.

The electronic control system 1 is a system that is made up of multiple "electronic control devices" (hereinafter, ECUs: Electronic Control Units). Although FIG. 1 shows the electronic control system 1 that includes two ECUs (ECU10, ECU20), the system may be made up of any number of ECUs. The ECU10 and ECU20 are connected via, for example, an in-vehicle network such as a Controller Area Network (CAN) or a Local Interconnect Network (LIN), Ethernet (registered trademark), or a wireless communication network.

Here, the "electronic control device" may be configured as a so-called information processing device, for example, that is mainly composed of semiconductor devices and has a volatile storage unit such as a CPU (Central Processing Unit) and a RAM (Random Access Memory). In this case, the information processing device may further have a non-volatile storage unit such as a flash memory, a network interface unit connected to a communication network, etc. Furthermore, such an information processing device may be a packaged semiconductor device (element), or may be configured such that each semiconductor device is wired and connected on a wiring board.

The ECU 10 is, for example, an ECU based on a platform that allows dynamic function expansion, called the Adaptive Platform (hereinafter, AP) in AUTOSAR (AUTomotive Open System ARchitecture). The AP is a platform that is mainly suitable for ECUs for autonomous driving. The ECU 20 is, for example, an ECU based on a platform that optimizes static functions, called the Classic Platform (hereinafter, CP) in AUTOSAR. The CP is a platform that is mainly suitable for ECUs for vehicle control.

Each of the ECUs 10 and 20 that make up the electronic control system 1 has one or more virtual machines managed by a hypervisor. The configuration of the ECUs 10 and 20 and the virtual machines installed in each ECU is described below. In the diagram, the virtual machines are abbreviated as VM (Virtual Machine).

(1) Regarding ECU 10 ECU 10 includes a hypervisor (HV) 110, a hypervisor 120, a plurality of virtual machines (140, 150, 160) managed by these hypervisors, and a real storage 130 which is hardware.

Hypervisor 110 and hypervisor 120 are software that virtualizes ECU 10. In the example of FIG. 1, a first virtual machine 140 and a second virtual machine 150 are constructed on hypervisor 110, and a third virtual machine 160 is constructed on hypervisor 120. The virtual machines constructed on the hypervisors are virtually "connected" to each other.

Here, "connecting" virtual machines refers to a state in which virtual machines can exchange data with each other, and includes cases in which virtual machines realized on the same hardware are virtually connected, as well as cases in which virtual machines realized on different hardware are connected via a network, etc. Also, a state in which data exchange is possible does not necessarily mean that data exchange is actually possible. For example, it is a state in which data exchange is possible even if one of the virtual machines is temporarily stopped due to some kind of trouble or is in a sleep state.

The real storage (corresponding to a "storage unit") 130 is a hardware memory, and may be a volatile memory such as an SRAM or DRAM, or a non-volatile memory such as a ROM, flash memory, or a hard disk. The virtual storage of the first virtual machine 140 to the third virtual machine 160 described below is realized by virtualizing the storage area of the real storage 130. The real storage 130 is a storage area managed by the hypervisor of the ECU 10. Although one real storage 130 is shown in FIG. 1, the real storage 130 may be realized by multiple storages.

The real storage 130 stores the update files that have been split by the file splitting unit 145, which will be described later. The area of the real storage 130 where the update files are stored may be a shared storage area shared by multiple virtual machines, or may be a virtual storage area realized by virtualizing the storage area of the real storage 130. However, since the shared storage area is shared by multiple virtual machines, there is a risk of security being reduced. Therefore, when saving update files in the shared storage area, it is desirable that each virtual machine be able to access the shared storage area only when updating the virtual machine software using the update file saved in the shared storage area. In other words, when updating is not performed using the update file saved in the shared storage area, access from the virtual machine to the shared storage area is restricted.

(i) Regarding the first virtual machine 140

The first virtual machine 140 managed by the hypervisor 110 has a file acquisition unit 141, a delivery control unit 142, an update unit 143, and a virtual storage 144.

The file acquisition unit 141 acquires files from a server device provided outside the vehicle control system 1 using OTA (Over The Air) or wired communication. The files acquired by the file acquisition unit 141 include an update file for updating the software of a virtual machine, and may be, for example, an update file group including multiple update files for updating multiple virtual machines. The file may further include information identifying the virtual machine whose software should be updated. The file acquisition unit 141 transfers the acquired update file group to the distribution control unit 142. The file acquisition unit 141 is also referred to as an OTA client. The update file for updating the software of a virtual machine may be one that updates the software that realizes the virtual machine, as well as one that updates applications or software installed on the virtual machine.

The distribution control unit 142 performs a series of processes required to distribute the file transferred from the file acquisition unit 141 to the virtual machine to be updated. The distribution control unit 142 realizes a file division unit 145, a determination unit 146, a distribution unit 147, and an update instruction unit 148. The distribution control unit 142 executes, for example, some or all of the functions referred to as a UCM (Update and Configuration Management) master in AUTOSAR.

The file division unit 145 performs a parsing process to divide the update files transferred from the file acquisition unit 141 into update files for each virtual machine. The parsed update files are stored in the real storage 130.

The determination unit 146 determines which of the multiple virtual machines connected to the first virtual machine 140 is the virtual machine to be updated. Whether or not the virtual machine is the virtual machine to be updated can be determined based on information that identifies the virtual machine to be updated and that is included in the file acquired by the file acquisition unit 141. In the following embodiment, a case will be described in which all the virtual machines shown in FIG. 1 are the virtual machines to be updated.

The determination unit 146 further determines whether to deliver the update file to the virtual machine to be updated. The method by which the determination unit 146 determines whether to deliver the update file to the virtual machine to be updated will be described later in the first and second embodiments.

When determining which virtual machines are to be updated and whether to distribute the update file, the determination unit 146 may perform a search process to inquire about information about the virtual machines from each virtual machine. For example, the determination unit 146 transmits a search signal to the virtual machines connected to the first virtual machine 140, inquiring about information about the hypervisor that manages the virtual machines, the ECU in which the virtual machines are installed, or the functions and configuration of the ECU.

When the software update is completed for all virtual machines to be updated, the determination unit 146 notifies the file acquisition unit 141 that the update is complete.

When the determination unit 146 determines that the update file should be distributed, the distribution unit 147 distributes the update file divided by the file division unit 145 to the virtual machine by sending it via a communication network. The distribution unit 147 may distribute the update file to the virtual machine upon receiving a distribution instruction from the determination unit 146. Note that in this disclosure, "distributing" the update file includes not only sending the update file via a communication network, but also moving the storage area of the update file to an area accessible by a specific virtual machine.

The update instruction unit 148 instructs each virtual machine to be updated to update the virtual machine software. For virtual machines for which the determination unit 146 has determined that an update file should be delivered, the update instruction unit 148 instructs the virtual machine software to be updated using the update file delivered by the delivery unit 147. For virtual machines for which the determination unit 146 has determined that an update file should not be delivered, the update instruction unit 148 instructs the virtual machine software to be updated using the update file stored in the real storage 130 by accessing the real storage 130.

The update instruction of the update instruction unit 148 may indicate an address indicating the destination of the update file. For example, the update instruction may indicate the address of the destination of the update file, thereby indirectly instructing that the software of the virtual machine be updated using the update file. Furthermore, the update instruction may indicate the address of the real storage 130 in which the update file is stored, thereby indirectly instructing that the software of the virtual machine be updated using the update file stored in the real storage 130 by accessing the real storage 130. The update instruction may further include information indicating whether to distribute the update file to the virtual machine.

The update unit 143 updates the software of the first virtual machine 140 based on instructions from the update instruction unit 148. When the update process of the software of the first virtual machine 140 is completed, the update unit 143 notifies the delivery control unit 142 that the update is complete. The update unit 143 and update units 151, 161, and 231 of other virtual machines described below, for example, execute some or all of the functions called UCM subordinate in AUTOSAR.

The virtual storage 144 is a storage area virtually provided in the first virtual machine 140 by virtualizing the storage area of the real storage 130. Therefore, files stored in the virtual storage 144 are also considered to be files stored in the real storage 130. The same applies to the virtual storage 152 of the second virtual machine 150 and the virtual storage 162 of the third virtual machine 160 described below.

(ii) Regarding the second virtual machine 150 and the third virtual machine 160 The second virtual machine 150, like the first virtual machine 140, is a virtual machine managed by the hypervisor 110. The second virtual machine 150 includes an update unit 151 and a virtual storage 152.

The third virtual machine 160 is different from the first virtual machine 140 and the second virtual machine 150 and is a virtual machine managed by the hypervisor 120. The third virtual machine 160 has an update unit 161 and a virtual storage 162.

The update unit 151 and the update unit 161 update the software of each virtual machine based on an update instruction from the update instruction unit 148 of the first virtual machine 140. When the software update process is completed, the update unit 151 and the update unit 161 notify the delivery control unit 142 of the first virtual machine 140 that the update has been completed.

Virtual storage 152 and virtual storage 162 are storage areas virtually provided in second virtual machine 150 and third virtual machine 160, respectively. When an update file is distributed from distribution unit 147 of first virtual machine 140, the update file is stored in each of virtual storages 152 and 162.

As described above, the second virtual machine 150 and the third virtual machine 160 are virtually connected to the first virtual machine 140, and data can be exchanged between these virtual machines.

(2) Regarding the ECU 20 The ECU 20 includes a hypervisor 210 , a real storage 220 which is hardware, and a fourth virtual machine 230 which is managed by the hypervisor 210 .

ECU10 and ECU20 are connected via an in-vehicle network, and the first virtual machine 140 of ECU10 and the fourth virtual machine 230 of ECU20 are virtually connected via the in-vehicle network.

The hypervisor 210 is software that virtualizes the ECU 20. The fourth virtual machine 230 is built on the hypervisor 210.

The real storage 220, like the real storage 130 of the ECU 10, is a hardware memory, and is a volatile memory such as SRAM or DRAM, a ROM, a flash memory, or a non-volatile memory such as a hard disk.

The fourth virtual machine 230 of the ECU 20 has an update unit 231 and a virtual storage 232, similar to the second virtual machine 150 and the third virtual machine 160 described above.

The update unit 231 updates the software of the fourth virtual machine 230 based on an update instruction from the update instruction unit 148 of the first virtual machine 140, and when the software update process is completed, notifies the delivery control unit 142 of the first virtual machine 140 that the update has been completed.

The virtual storage 232 is a storage area that is virtually provided in the real storage 220. When an update file is distributed from the distribution unit 147, the update file may be stored in the virtual storage 232.

(3) Summary The configurations of the electronic control device and the electronic system common to the first and second embodiments have been described above.
1 shows an example in which the ECU 10 has two hypervisors (110, 120) and the ECU 20 has one hypervisor (210), but the number of hypervisors is merely an example and is not limited thereto. In other words, the ECU 10 may have only one hypervisor and the ECU 20 may have two or more hypervisors. In addition, the number of virtual machines built on the hypervisors is also arbitrary.

In addition, although a configuration has been described in which only the first virtual machine 140 has the functions of a file acquisition unit and a distribution control unit, other virtual machines may also have these functions, similar to the first virtual machine 10.

2. Embodiment 1
In this embodiment, a configuration will be described in which it is determined whether or not to deliver an update file to a virtual machine to be updated depending on whether the hypervisor of the virtual machine to be updated satisfies a predetermined condition.

(1) Configuration of the First Virtual Machine 140 The determination unit 146 of this embodiment determines whether the hypervisor (corresponding to the "first hypervisor") 110 that manages the first virtual machine 140 (corresponding to the "first virtual machine") having the delivery control unit 142 is the same as the hypervisor (corresponding to the "second hypervisor") that manages the virtual machine to be updated (corresponding to the "second virtual machine"). If it is determined that the hypervisors are the same, the determination unit 146 determines that the update file will not be delivered to the virtual machine to be updated. On the other hand, if it is determined that the hypervisors are different, the determination unit 146 determines that the update file will be delivered to the virtual machine to be updated.

Here, "same" includes cases where the hypervisor is the same, as well as cases where the functions and actions are the same even if the hypervisor is different.

The determination unit 146 determines whether the hypervisor 110 is the same as the hypervisor that manages the virtual machine to be updated, based on a response signal from each virtual machine in response to a search signal sent to the update unit of each virtual machine. Therefore, the response signal in this embodiment includes information that can identify the hypervisor that manages each virtual machine, such as a hypervisor identification ID.

The determination unit 146 may also send a search signal to the update unit 143 of the first virtual machine 140 in the same manner as to the update units of other virtual machines. In this case, the determination unit 146 naturally determines, based on the response signal from the update unit 143, that the hypervisor 110 is the same as the hypervisor that manages the first virtual machine 140, which is the virtual machine to be updated.

In the example of FIG. 1, the hypervisor that manages the first virtual machine 140 and the hypervisor that manages the second virtual machine 150 are both hypervisor 110, and are the same. Therefore, the determination unit 146 determines not to distribute the update file to the second virtual machine 150.

The hypervisor 110 that manages the first virtual machine 140 and the hypervisor 120 that manages the third virtual machine 160 are different hypervisors. Therefore, the determination unit 146 determines that the update file should be delivered to the third virtual machine 160.

Similarly, the hypervisor 110 that manages the first virtual machine 140 and the hypervisor 210 that manages the fourth virtual machine 230 are different hypervisors. Therefore, the determination unit 146 determines that the update file should be delivered to the fourth virtual machine 230.

In the following embodiment, a configuration is described in which the determination unit 146 determines whether the hypervisor 110 is the same as the hypervisor that manages the virtual machine to be updated, based on the response signal. However, the determination unit 146 may determine the hypervisor without relying on the response signal. For example, in an in-vehicle system, if it is known in advance which hypervisor manages each virtual machine, it is assumed that the file acquisition unit 141 and the delivery control unit 142 have information on the virtual machines and the hypervisors that manage each virtual machine in advance. In such a case, the determination unit 146 may determine whether the hypervisor 110 is the same as the hypervisor that manages the virtual machine to be updated, based on an instruction from the file acquisition unit 141 or information held by the delivery control unit 142, without using the response signal.

In this embodiment, the two hypervisors (110, 120) of the ECU 10 are different hypervisors. However, if the hypervisors 110, 120 are provided on one host OS, the determination unit 146 may determine that the hypervisors 110, 120 are the same. If multiple hypervisors are provided on one host OS, the guest OSs built on each hypervisor can access the same area in the real storage 130. In this case, the hypervisors 110, 120 have the same functions and actions in that they build guest OSs that can access the same area. In this way, if the functions and actions of the hypervisors 110, 120 are the same, the determination unit 146 may determine that the two hypervisors are "the same."

The delivery unit 147 delivers the update file only to virtual machines to which the determination unit 146 has determined that the update file should be delivered, since the hypervisor 110 is different from the hypervisor that manages the virtual machines to be updated. Therefore, the delivery unit 147 of this embodiment delivers the update file to the third virtual machine 160 and the fourth virtual machine 230.

The update instruction unit 148 instructs the update unit of the virtual machine to be updated to update the software of the virtual machine. The update instruction unit 148 instructs the update unit 143 of the first virtual machine 140 and the update unit 151 of the second virtual machine 150 to access the real storage 130 and update the software of the second virtual machine 150 by using the update file stored in the real storage 130.
In addition, the update instruction unit 148 instructs the update unit 161 of the third virtual machine 160 and the update unit 231 of the fourth virtual machine 230 to update the software of each virtual machine using the update file distributed by the distribution unit 147.

(2) Configuration of second virtual machine 150 When the update unit 151 of the second virtual machine 150 receives an update instruction from the update instruction unit 148, it accesses the real storage 130, refers to the update file stored in the real storage 130, and updates the software of the second virtual machine 150 using the update file.

(3) Configuration of the Third Virtual Machine 160 The virtual storage 162 of the third virtual machine 160 stores the update file distributed from the distribution unit 147 .
When the update unit 161 of the third virtual machine 160 receives the update instruction from the update instruction unit 148 , the update unit 161 updates the software of the third virtual machine 160 by using the update file stored in the virtual storage 162 .

(4) Configuration of Fourth Virtual Machine 230 The real storage 220 or the virtual storage 232 of the fourth virtual machine 230 stores the update file distributed from the distribution unit 147. The update file may be stored in either the real storage 220 or the virtual storage 232.
When the update unit 231 of the fourth virtual machine 230 receives the update instruction from the update instruction unit 148 , it updates the software of the fourth virtual machine 230 using the update file stored in the real storage 220 or the virtual storage 232 .

(5) Operation of Electronic Control System 1 Next, the operation related to updating software of a virtual machine will be described with reference to Figures 2 to 4. Figure 2 is a diagram showing the operation of the entire electronic control system 1. Figure 3 shows the operation of the distribution control unit 142 of the first virtual machine 140, and Figure 4 shows the operation of the update unit of each virtual machine. The symbols shown in Figure 2 correspond to the symbols shown in Figures 3 and 4, and the same symbols indicate the same processing.

The operations of the distribution control unit 142 and the update unit shown in Figures 3 and 4 can also be considered as the operations of each electronic control unit (ECU 10, ECU 20). The operations of each electronic control unit do not only indicate the software update method executed by the electronic control unit, but also indicate the processing procedure of the software update program that can be executed by the electronic control unit. These processes are not limited to the order shown in Figures 2 to 4. In other words, the order may be changed as long as there are no constraints, such as a relationship in which a certain step uses the result of the previous step. The same applies to Figure 7 in embodiment 2.

First, the operation of the distribution control unit 142 will be mainly described with reference to FIG. 2 and FIG.
The distribution control unit 142 receives the update file group transferred from the file acquisition unit 141 (FIGS. 2 and 3: S101). The update file group is files for updating the software of the virtual machine, and is the file acquired by the file acquisition unit 141 from a server device external to the electronic control system 1.
The file division unit 145 of the distribution control unit 142 performs a parsing process to divide the update files received in S101 into update files for each virtual machine (FIGS. 2 and 3: S102).
The file division unit 145 stores the updated files divided in S102 in the real storage 130 (FIGS. 2 and 3: S103).
The determination unit 146 of the distribution control unit 142 transmits a search signal to each virtual machine inquiring about information about the virtual machine in order to determine whether to distribute the update file to the virtual machine to be updated (FIGS. 2 and 3: S104).

The determination unit 146 receives response signals sent from the update units (143, 151, 161, 231) of the first to fourth virtual machines (Figures 2 and 3: S105).

Based on the response signal received in S105, the determination unit 146 determines whether to deliver the update file to the virtual machine to be updated (FIGS. 2 and 3: S106). As described above, the determination unit 146 in this embodiment determines not to deliver the update file if the hypervisor 110 that manages the first virtual machine 140 and the hypervisor that manages the virtual machine to be updated are the same, and determines to deliver the update file if the hypervisors are different.

Here, if it is determined in S106 that the update file will not be distributed, the update instruction unit 148 of the distribution control unit 142 sends an update instruction to update the virtual machine software by accessing the real storage 130 (Figures 2 and 3: S107).
On the other hand, if it is determined in S106 that the update file is to be distributed, the update instruction unit 148 of the distribution control unit 142 sends an update instruction to instruct the virtual machine to update the software using the update file distributed by the distribution unit 147 (Figures 2 and 3: S108).
The distribution unit 147 of the distribution control unit 142 distributes the update file to the virtual machine determined in S106 to be distributed with the update file, i.e., the virtual machine determined to have the same hypervisor as the hypervisor managing the virtual machine to be updated (FIGS. 2 and 3: S109). The distribution unit 147 of this embodiment distributes the update file to the third virtual machine 160 and the fourth virtual machine 230.

The update unit of each virtual machine performs update processing (S110). The update processing in the update unit will be described later.

The distribution control unit 142 receives an update completion notification indicating that the update process has been completed from the update unit of each virtual machine for which the update process of S110 has been completed (Figures 2 and 3: S111).

When the distribution control unit 142 receives a notification from the update unit of each virtual machine indicating that the update process has been completed, it notifies the file acquisition unit 141 that the update process of each virtual machine has been completed (Figures 2 and 3: S112).

Next, the operation of the update unit of each virtual machine will be mainly described with reference to FIG. 2 and FIG.
The update units (143, 151, 161, 231) of the first to fourth virtual machines receive the search signal transmitted from the determination unit 146 in S104 (S201).
Each update unit transmits a response signal to the inquiry of the search signal to the determination unit 146 (S202).

Next, the update unit receives the update instruction sent from the update instruction unit 148 in S107 and S108 (S203). Here, if the update instruction received in S203 is an update instruction by accessing real storage (S204: Yes), that is, if the update instruction is sent from the update instruction unit 148 in S107, the update unit updates the virtual machine using the update file stored in the real storage 130 (S110). In this embodiment, the update unit 143 of the first virtual machine 140 and the update unit 151 of the second virtual machine 150 receive the update instruction of S107. Therefore, the update unit 143 and the update unit 151 access the real storage 130 and update the first virtual machine 140 and the second virtual machine 150, respectively, using the update file stored in the real storage 130 (S110).

On the other hand, if the update instruction received in S203 is not an update instruction for accessing real storage (S204: No), i.e., if the update instruction was sent from the update instruction unit 148 in S108, the update unit receives the update file distributed in S109 (S205). In this embodiment, the update unit 161 of the third virtual machine 160 and the update unit 231 of the fourth virtual machine 230 receive the update instruction in S108, and further receive the update file distributed in S109 (S205). Then, the update unit 161 and the update unit 231 use the update file received in S205 to update the software of the virtual machine (S110).

When the update process of S110 is completed, the update unit of each virtual machine sends an update completion notification to the distribution control unit 142 indicating that the update process has been completed (S206).

(6) Summary According to the above configuration, a virtual machine that controls the distribution of update files for updating virtual machine software distributes update files only to virtual machines managed by a hypervisor different from the hypervisor that manages the virtual machine, and does not distribute update files to virtual machines managed by the same hypervisor. This makes it possible to omit the process of distributing update files to some virtual machines, thereby reducing the load on the distribution process and shortening the time required to update virtual machine software.
Furthermore, by omitting the process of distributing update files to some virtual machines, the amount of communication between ECUs can be reduced, thereby reducing the load and congestion on communication lines.

(7) Modification 1 of the First Embodiment
1, the configuration in which the ECU 10 has two hypervisors (hypervisor 110, hypervisor 120) has been described. For example, in the case where the ECU is equipped with multiple microprocessors such as a dual processor, a configuration in which one ECU has multiple hypervisors is assumed.

However, each ECU constituting the electronic control system 1 may be a single processor, and all the ECUs may have only one hypervisor. In such a case, a configuration in which each ECU constituting the electronic control system 1 has multiple hypervisors is not anticipated. Therefore, the determination unit 146 may determine whether the hypervisor 110 managing the first virtual machine 140 is the same as the hypervisor managing each virtual machine by determining whether the ECU having the virtual machine with the distribution control unit 142 is the same as the ECU having the virtual machine to be updated.

For example, the determination unit 146 transmits a search signal to each virtual machine inquiring about the device ID of the ECU in which the virtual machine is installed. Then, based on the response signal from each virtual machine, the determination unit 146 determines whether the ECU 10 having the first virtual machine 140 is the same as the ECU having the virtual machine to be updated. Here, if the determination unit 146 determines that they are the same ECU, it determines that the hypervisor 110 managing the first virtual machine 140 is the same as the hypervisor to be updated.

According to this modified example, by determining the ECU, it is possible to determine whether the hypervisor that manages the virtual machine that controls the distribution of the update file is the same as the hypervisor that manages the virtual machine to be updated, making it easier to determine whether to distribute the update file to the virtual machine to be updated.

(8) Modification 2 of the First Embodiment
In the above-described embodiment, it is assumed that the hypervisor 110 included in the ECU 10 is different from the hypervisor 210 included in the ECU 20. However, a common hypervisor may be configured to manage virtual machines across the ECUs.

In this modified example 2, the hypervisor 110 provided in the ECU 10 and the hypervisor 210 provided in the ECU 20 are the same hypervisor, and the first virtual machine 140 and the fourth virtual machine 230 are managed by the same hypervisor. Since the hypervisor 110 that manages the first virtual machine 140 and the hypervisor 210 that manages the fourth virtual machine 230 are the same, the determination unit 146 in this modified example 2 determines not to distribute the update file to the fourth virtual machine 230.

Since the update file is not distributed to the fourth virtual machine 230, the update unit 231 of the fourth virtual machine 230 accesses the real storage 130 provided in the ECU 10, and updates the software of the fourth virtual machine 230 using the update file stored in the real storage 130.

3. Embodiment 2
In this embodiment, a configuration for determining whether to distribute an update file based on a safety level indicating the safety of a virtual machine that controls the distribution of the update file and a safety level indicating the safety of the virtual machine to be updated will be described, focusing on the differences from embodiment 1.

(1) Configuration of ECU 10 Fig. 5 is a diagram showing the real storage 130 of the ECU 10 of this embodiment. The real storage 130 of this embodiment has storage areas with five security levels.

The safety level in this embodiment is set based on, for example, the Automotive Safety Integrity Level (ASIL). ASIL is an index that classifies vehicles according to their functional safety, as defined by the ISO26262 standard. ASIL is classified into stages, ASIL-A, ASIL-B, ASIL-C, and ASIL-D, in order of decreasing safety level. Furthermore, when it is not necessary to apply specific functional safety, quality management called QM (Quality Management) is applied. QM indicates a safety level lower than ASIL-A. ASIL and QM are assigned to hardware and software, respectively.

In the example shown in FIG. 5, the real storage 130 has storage areas for QM, ASIL-A, ASIL-B, ASIL-C, and ASIL-D. The storage areas of the real storage 130 used by the virtual machine of the ECU 10 correspond to the safety level of the virtual machine itself or each configuration of the virtual machine. For example, if the safety level of the virtual machine is ASIL-A, the storage area of the real storage 130 used by the virtual machine is the storage area for ASIL-A among the storage areas shown in FIG. 5. Even if the safety level of the virtual machine is ASIL-A, if the configuration with the highest independence among the virtual machine's configurations is ASIL-B, the configuration may use the storage area for ASIL-B.

Each virtual machine or configuration of a virtual machine cannot access a storage area in the real storage 130 with a higher safety level than its own. For example, a virtual machine with a safety level of ASIL-B cannot access a storage area for ASIL-C or ASIL-D.

In the following embodiment, a configuration is described in which a safety level indicating the safety of a virtual machine is used to determine whether to distribute an update file. Here, the safety level indicating the safety of a virtual machine may be the safety level of the virtual machine assigned to the virtual machine, or may be the safety level assigned to a specific configuration that the virtual machine has. For example, the safety level assigned to the distribution control unit 142 of the first virtual machine 140 may be used as the safety level of the first virtual machine 140, and the safety level assigned to the update unit 151 of the second virtual machine 150 may be used as the safety level of the second virtual machine 150.

As another example, the safety level of a virtual machine may be, for example, a value equal to the lowest safety level among the safety levels assigned to each configuration of the virtual machine. In this case, in the first virtual machine 140, if the safety levels of the file acquisition unit 141, the delivery control unit 142, and the virtual storage 144 are ASIL-C and the safety level of the update unit 143 is ASIL-B, the safety level for the first virtual machine 140 will be ASIL-B.

In the following, this embodiment will be described assuming that the safety level of the first virtual machine 140 is ASIL-B, the safety level of the second virtual machine 150 is ASIL-A, the safety level of the third virtual machine is ASIL-C, and the safety level of the fourth virtual machine is QM.

(2) Configuration of the First Virtual Machine 140 The determining unit 146 of this embodiment transmits a search signal inquiring about the security level of each virtual machine to each virtual machine, and receives a response signal indicating the security level of each virtual machine from each virtual machine.

The determination unit 146 determines whether to distribute the update file to the virtual machine to be updated based on a safety level A (corresponding to a "first safety level") indicating the safety of the first virtual machine 140 having the distribution control unit 142 and a safety level B (corresponding to a "second safety level") indicating the safety of the virtual machine to be updated.

Figure 6 shows how the determination unit 146 determines whether to distribute or not distribute an update file based on the safety level A of the first virtual machine 140 and the safety level B of the virtual machine to be updated.

Figure 6 shows an example of determining whether or not to distribute an update file based on the virtual machine's own safety level A and safety level B, but as described above, safety level A may be the safety level assigned to the distribution control unit 142 of the first virtual machine 140, and safety level B may be the safety level assigned to the update unit of the virtual machine to be updated.

Figure 6 shows that when safety level A of the first virtual machine 140 is "higher" than safety level B of the virtual machine to be updated, the determination unit 146 determines that the update file is to be delivered to the virtual machine to be updated. As described above, when safety level A of the first virtual machine is higher than safety level B of the virtual machine to be updated, the update unit of the virtual machine to be updated cannot access the storage area of the real storage 130 used by the first virtual machine 140. Therefore, when the update unit of the virtual machine to be updated cannot access the storage area of the real storage 130 used by the first virtual machine 140, the determination unit 146 determines that the update file is to be delivered.

Here, "than" includes both cases where the value is the same as the comparison target and cases where it is not.

Note that the table in FIG. 6 shows an example in which it is determined that the update file is to be delivered only when the storage area of the real storage 130 used by the first virtual machine 140 cannot be accessed, but the configuration may also be such that the update file is delivered even when safety level A is equal to safety level B.

The determination unit 146 can identify the safety level of the virtual machine to be updated based on the response signal from each virtual machine in response to the search signal sent to the update unit of each virtual machine. Therefore, the response signal in this embodiment includes information indicating the safety level of each virtual machine.

The determination unit 146 may also send a search signal to the update unit 143 of the first virtual machine 140, in the same manner as to the update units of the other virtual machines. In this case, the determination unit 146 naturally determines, based on the response signal from the update unit 143, that the safety level of the first virtual machine 140 and the safety level of the virtual machine to be updated are the same.

In the example of this embodiment, the safety level (ASIL-B) of the first virtual machine 140 is higher than the safety level (ASIL-A) of the second virtual machine 150 and the safety level (QM) of the fourth virtual machine 230. Therefore, the determination unit 146 determines to distribute the update file to the second virtual machine 150 and the fourth virtual machine 230.
On the other hand, since the safety level (ASIL-B) of the first virtual machine 140 is lower than the safety level (ASIL-C) of the third virtual machine 160 , the determining unit 146 determines not to distribute the updated file to the third virtual machine 160 .

The update instruction unit 148 instructs the second virtual machine 150 and the fourth virtual machine 230 to update the virtual machine software using the update file distributed by the distribution unit 147. On the other hand, the update instruction unit 148 instructs the first virtual machine 140 and the third virtual machine 160 to update the virtual machine software using the update file stored in the real storage 130 by accessing the storage area of ASIL-B in the real storage 130.

(3) Configuration of the Second Virtual Machine 150 The virtual storage 152 of the second virtual machine 150 stores the update file distributed from the distribution unit 147 .
When the update unit 151 of the second virtual machine 150 receives the update instruction from the update instruction unit 148 , the update unit 151 updates the software of the second virtual machine 150 by using the update file stored in the virtual storage 152 .
The virtual storage 152 is a virtualized area of the storage area of the real storage 130 , which is an ASIL-A storage area corresponding to the safety level of the second virtual machine 150 .

(4) Configuration of third virtual machine 160 The update unit 161 of the third virtual machine 160 accesses the storage area of ASIL-B in the real storage 130, refers to the update file stored in the real storage 130, and updates the software of the third virtual machine 160 using the update file.

(5) Configuration of Fourth Virtual Machine 230 The real storage 220 or the virtual storage 232 of the fourth virtual machine 230 stores the update file distributed from the distribution unit 147. The update file may be stored in either the real storage 220 or the virtual storage 232. Upon receiving an update instruction from the update instruction unit 148, the update unit 231 of the fourth virtual machine 230 updates the software of the fourth virtual machine 230 by using the update file stored in the real storage 220 or the virtual storage 232.

(6) Operation of the Virtual Machines in the Electronic Control System 1, the ECU 10, and the ECU 20 Fig. 7 shows the operation of the entire electronic control system 1 of this embodiment. The operation of the delivery control unit 142 and the operation of the update unit of the first virtual machine 140 of this embodiment are the same as those of the first embodiment shown in Figs. 3 and 4, and will be described with reference to Figs. 3 and 4.

The processes of S101 to S112 shown in FIG. 7 are the same as the processes of the electronic control system 1 of the first embodiment shown in FIG. 2. However, in S106 of this embodiment, the method of determining whether the determination unit 146 of the first virtual machine 140 delivers the update file to the virtual machine to be updated is different from that of the first embodiment. In S106 of this embodiment, the determination unit 146 determines whether to deliver the update file to the virtual machine to be updated based on the safety level of the first virtual machine 140 and the safety level of the virtual machine to be updated. As described above, in this embodiment, the safety level of the first virtual machine 140 is higher than the safety levels of the second virtual machine 150 and the fourth virtual machine 230, so the determination unit 146 determines to deliver the update file to the second virtual machine 150 and the fourth virtual machine 230. In addition, the safety level of the first virtual machine 140 is lower than the safety level of the third virtual machine 160, so the determination unit 146 determines not to deliver the update file to the third virtual machine 160.

The update instruction unit 148 of the distribution control unit 142 instructs the update unit 143 of the first virtual machine 140 and the update unit 161 of the third virtual machine 160 to update the software of the virtual machines by accessing the storage area of ASIL-B in the real storage 130 (Figures 7 and 3: S107).
The update instruction unit 148 further instructs the update unit 151 of the second virtual machine 150 and the update unit 231 of the fourth virtual machine 230 to update the software of the virtual machines using the update file distributed by the distribution unit 147 (Figure 7, Figure 3: S108).
The distribution unit 147 of the distribution control unit 142 distributes the update file to the second virtual machine 150 and the fourth virtual machine 230 (FIG. 7, FIG. 3: S109).

The update unit 143 of the first virtual machine 140 receives the update instruction sent from the update instruction unit 148 in S107 (S203). Since this update instruction is an update instruction for accessing real storage (S204: Yes), the update unit 143 accesses the storage area of ASIL-B in the real storage 130 to update the first virtual machine 140 using the update file stored in the real storage 130 (FIGS. 7 and 4: S110).
Similarly, when the update unit 161 of the third virtual machine 160 receives the update instruction sent from the update instruction unit 148 in S107 (S203, S204: Yes), it accesses the storage area of ASIL-B in the real storage 130 and updates the third virtual machine 160 using the update file stored in the real storage 130 (Figures 7 and 4: S110).

On the other hand, the update unit 151 of the second virtual machine 150 receives the update instruction sent from the update instruction unit 148 in S108 (S203). Since this update instruction is not an update instruction for accessing real storage (S204: No), the update unit 151 further receives the update file distributed from the distribution unit 147 (S205). Based on the update instruction, the update unit 151 updates the second virtual machine 150 using the update file distributed from the distribution unit 147 (FIGS. 7 and 4: S110).
Similarly, the update unit 231 of the fourth virtual machine 230 receives the update instruction sent from the update instruction unit 148 in S108 (S203, S204: No), and receives the update file distributed from the distribution unit 147 (S205). Then, the update unit 231 updates the fourth virtual machine 230 using the update file distributed from the distribution unit 147 based on the update instruction (FIGS. 7 and 4: S110).

(7) Summary According to the above configuration, a virtual machine that controls the distribution of update files for updating virtual machine software distributes update files only to virtual machines having a higher safety level than the virtual machine, and does not distribute update files to virtual machines having a safety level equal to or lower than the virtual machine. This makes it possible to omit the process of distributing update files to some virtual machines, thereby reducing the load on the distribution process and shortening the time required to update the virtual machine software.

(8) Modification 1 of the Second Embodiment
In the above-described second embodiment, the configuration has been described in which the update file is delivered only when the safety level of the first virtual machine 140 is higher than the safety level of the virtual machine to be updated. However, the configuration may be such that the update file is delivered only when the safety level of the first virtual machine 140 is different from the safety level of the virtual machine to be updated.

Figure 8 shows how the determination unit 146 of this variant example 1 determines whether to distribute or not distribute an update file based on the safety level A of the first virtual machine 140 and the safety level B of the virtual machine to be updated.

In the example shown in FIG. 8, when the safety level A of the first virtual machine 140 and the safety level B of the virtual machine to be updated are different, the determination unit 146 determines that the update file is to be delivered to the virtual machine to be updated. On the other hand, when the safety level A of the first virtual machine 140 and the safety level B of the virtual machine to be updated are equal, the determination unit 146 determines that the update file is not to be delivered to the virtual machine to be updated.

As in the second embodiment described above, if the safety level of the first virtual machine 140 is ASIL-B, the safety level of the second virtual machine 150 is ASIL-A, the safety level of the third virtual machine is ASIL-C, and the safety level of the fourth virtual machine is QM, the safety level of the first virtual machine 140 and the safety levels of the second to fourth virtual machines are all different. Therefore, the determination unit 146 determines that the update file should be distributed to all of the second to fourth virtual machines. Then, it determines that the update file should not be distributed only to the first virtual machine itself.

In this modified example, the virtual machines that can access the real storage storage area used by the virtual machine that controls the distribution of update files are limited to virtual machines that are to be updated and have the same level of security, and access from virtual machines with different levels of security is restricted, thereby ensuring the security of the real storage.

(9) Modification 2 of the Second Embodiment
The above-mentioned first and second embodiments have been described as different embodiments, but in this modification, the features of the first embodiment are applied to the second embodiment.

The determination unit 146 of this modified example determines whether to distribute an update file to the virtual machine to be updated based on whether the hypervisor 110 that manages the first virtual machine 140 is the same as the hypervisor that manages the virtual machine to be updated, as well as the safety level of the first virtual machine 140 and the safety level of the virtual machine to be updated.

For example, the determination unit 146 determines to deliver the update file to the virtual machine to be updated when the hypervisor 110 that manages the first virtual machine 140 is different from the hypervisor that manages the virtual machine to be updated and the safety level of the first virtual machine 140 is higher than the safety level of the virtual machine to be updated.

Alternatively, the determination unit 146 may select either the determination method described in embodiment 1 or the determination method described in embodiment 2 to determine whether to distribute the update file to each virtual machine.

4. Modifications of the Electronic Control Unit and the Electronic Control System In this section, modifications of the configurations of the electronic control unit and the electronic control system common to the first and second embodiments will be described.

In the above example, for example, a case was described in which ECU10 is an AP-based ECU and ECU20 is a CP-based ECU. However, each virtual machine built in the ECU may have a platform such as AP or CP.

Figure 9 is a diagram illustrating an example in which each virtual machine has its own platform (hereinafter, PF). In Figure 9, the description of each function realized by the distribution control unit 142 is omitted, but similar to Figure 1, the distribution control unit 142 realizes a file division unit 145, a determination unit 146, a distribution unit 147, and an update instruction unit 148.

In FIG. 9, the first virtual machine 140 has a first PF 1401, the second virtual machine 150 has a second PF 1501, the third virtual machine 160 has a third PF 1601, and the fourth virtual machine 230 has a fourth PF 2301. FIG. 9 further shows applications (1402, 1502, 1602, 2302) running on the PFs of each virtual machine.

There are various types of PFs other than AP and CP, and any PF can be applied as the first to fourth PFs (1401, 1501, 1601, 2301). For example, the first PF 1401 can apply an AP, the second PF 1501 can apply a CP, and the third PF 1601 can apply a PF other than AP or CP, so that multiple virtual machines with different PFs can coexist in one ECU. By coexisting multiple virtual machines with different PFs in one ECU in this way, it becomes possible to integrate multiple functions in one ECU, and ultimately to reduce the total number of ECUs.

In such a configuration, the OS of the virtual machine may be configured, for example, to be provided between the hypervisor and the PF, or to be integrated with the hypervisor or included in the PF.

The update unit of each virtual machine updates the software of the virtual machine, but in the configuration of FIG. 9, the update unit may update the PF or an application running on the PF as an update of the software of the virtual machine. For example, the update unit 143 updates the first PF 1401 or the first application 1402.

Note that FIG. 9 illustrates the file acquisition unit 141 as being included in the first application 1402, and the distribution control unit 142 and update unit 143 as being included in the first PF 1041. However, software included in the first PF 1401 may realize some or all of the functions of the file acquisition unit 141, or the first application 1402 may realize some or all of the functions of the distribution control unit 142 and update unit 143. Similarly, the second to fourth applications (1502, 1602, 2302) may realize some or all of the functions of their respective update units (151, 161, 231).

Figure 9 further shows that the actual storage 130 of the ECU 10 has three storage areas, namely, a shared storage area 131, a software storage area 132, and a distribution file storage area 133.

The shared storage area 131 is an area for storing update files acquired by the file acquisition unit 141 and parsed by the file division unit 145. The software storage area 132 is an area for storing software that configures virtual machines, such as the first to third PFs 1401, 1501, 1601 and the first to third applications 1402, 1502, 1602. The distributed file storage area 133 is an area for storing update files distributed from the distribution unit 147. By virtualizing the distributed file storage area 133, virtual storage is constructed in each virtual machine.

In this modified example, an update unit instructed to update the software of a virtual machine using an update file stored in real storage 130 accesses shared storage area 131 and uses the update file stored in shared storage area 131 to update the software of the virtual machine, i.e., the software stored in software storage area 132. In contrast, an update unit instructed to update the software of a virtual machine using an update file distributed by distribution unit 147 updates the software stored in software storage area 132 using the update file distributed from distribution unit 147 and stored in distribution file storage area 133.

The real storage 220 of the ECU 20, like the real storage 130, has a software storage area 222 and a distributed file storage area 223. However, since the ECU 20 does not need to store update files acquired by the file acquisition unit, the real storage 220 does not have a storage area equivalent to the shared storage area 131. Like the software storage area 132 and the distributed file storage area 133, the software storage area 222 and the distributed file storage area 223 store the software that constitutes the virtual machine and the update files distributed from the distribution unit 147, respectively.

Note that while FIG. 9 illustrates real storage 130 as including all of shared storage area 131, software storage area 132, and distribution file storage area 133, real storage 130 may be realized by a number of different storages. For example, in this modified example, software storage area 132 is non-volatile memory, but shared storage area 131 and distribution file storage area 133 may be either non-volatile memory or volatile memory. Thus, shared storage area 131 and distribution file storage area 133 may each be provided in the storage area of real storage 130, which is volatile memory, and software storage area 132 may be provided in the storage area of real storage 130, which is non-volatile memory.

5. Application to Domain Architecture Next, a configuration example in which the electronic control system 1 in the first and second embodiments is applied to a domain architecture will be described. In the domain architecture, a plurality of ECUs are classified into groups called domains according to their functions, roles, or network connections, and a domain controller ECU (hereinafter, DC-ECU) that manages and controls a plurality of ECUs belonging to the same domain is arranged for each domain. In the domain architecture, ECUs can be organized and integrated according to functions and networks, so that in a system composed of a large number of ECUs such as an in-vehicle system, not only is it easy to update ECUs in the future, but it is also possible to suppress the total number of ECUs, which is increasing.

(1) Overview of Domain Architecture Fig. 10 is a diagram showing a simplified domain architecture. The domain architecture shown in Fig. 10 includes DC-ECUs 30A and 30B, a gateway ECU (hereinafter, GW-ECU) 40, and ECUs 50A, 51A, 50B, and 51B.

Furthermore, the domain architecture shown in FIG. 10 has two domains, the first domain 2A has DC-ECU 30A and ECUs 50A and 51A, and the second domain 2B has DC-ECU 30B and ECUs 50B and 51B. As mentioned above, domains are classified according to the ECU functions and networks. In the case of an in-vehicle system, for example, there are domains that control the vehicle drive system, domains that control autonomous driving, and domains that control entertainment devices such as in-vehicle televisions and in-vehicle computers.

The DC-ECU 30A controls the ECUs 50A and 51A belonging to the first domain 2A, and the DC-ECU 30B controls the ECUs 50B and 51B belonging to the second domain 2B. For example, if the first domain 2A is a domain that controls autonomous driving, the DC-ECU 30A controls the ECUs 50A and 51A, such as a camera ECU, a radar ECU, a lidar ECU, a locator ECU, or an ECU equipped with various autonomous driving applications. The DC-ECU 30A may further have a sensor fusion application that integrates sensor information output from the ECUs 50A and 51A, and may provide output from the sensor fusion application to the ECUs 50A and 51A.

The GW-ECU 40 is an ECU that functions as a gateway device in the in-vehicle network. The GW-ECU 40 is connected to multiple buses and is connected to other ECUs via each bus. The GW-ECU 40 relays communications between domains, for example. The GW-ECU 40 also functions as a gateway between the outside of the vehicle and the domains.

Note that in FIG. 10, DC-ECU 30A, GW-ECU 40, ECUs 50A, and 51A are depicted as different ECUs, but the functions of each of the above-mentioned ECUs may be integrated into another ECU. For example, some of the functions of ECUs 50A and 51A may be integrated into DC-ECU 30A. In this case, the functions integrated into DC-ECU 30A may be realized by a virtual machine installed in DC-ECU 30A.

(2) Example of Application of Domain Architecture to Electronic Control System 1 In the above embodiment, the electronic control system 1 having the ECU 10 and the ECU 20 has been described. Here, when the domain architecture of FIG. 10 is applied to the electronic control system 1, it is preferable that the ECU 10 that acquires the update file and distributes the update file to other virtual machines is configured as the DC-ECUs 30A and 30B (corresponding to the "domain controller") of FIG. 10. In this case, the DC-ECUs 30A and 30B of the domain architecture each issue an update instruction to an ECU belonging to the same domain, and distribute the update file as necessary. Therefore, the DC-ECUs 30A and 30B do not issue an update instruction or distribute an update file to a virtual machine of an ECU belonging to a different domain.

For example, when the ECU 10 is configured as DC-ECU 30A, update instructions and update files are not distributed to the ECUs (DC-ECU 30B, ECUs 50B, 51B) included in the second domain 2B. The ECUs that access the actual storage 130 of the ECU 10 are limited to ECUs that belong to the same domain, i.e., the first domain 2A. Similarly, the ECU 10 configured as DC-ECU 30B does not distribute update instructions and update files to the ECUs included in the first domain 2A.

By making the electronic control system 1 a domain architecture, communication between ECUs can be limited to the same or related domains, which reduces the amount of communication in the entire in-vehicle network and ultimately improves the responsiveness of the in-vehicle network.

Furthermore, by restricting access from ECUs in different domains, it is possible to prevent unauthorized access to different domains, even if, for example, an ECU in one domain is under attack from the outside.

As another example, the ECU 10 may be configured as the GW-ECU 40 (corresponding to a "gateway device") in FIG. 10. In this case, the ECU 20 is configured as DC-ECUs 30A, 30B or ECUs 50A, B, 51A, B. In this case, only the actual storage 130 of the GW-ECU 40 will be accessed by ECUs belonging to various domains. Therefore, similar to the case where the ECU 10 is configured as a DC-ECU, even if an ECU belonging to one domain is under attack from the outside, it is possible to prevent unauthorized access to different domains.

6. Summary The features of the electronic control device and the electronic control system including the electronic control device in each embodiment of the present invention have been described above.

The terms used in each embodiment are merely examples and may be replaced with synonymous terms or terms with equivalent functions.

The block diagrams used to explain the embodiments classify and organize the device configuration by function. The blocks showing each function are realized by any combination of hardware or software. In addition, since they show functions, such block diagrams can also be understood as disclosures of method inventions and program inventions that realize the methods.

The order of the functional blocks that can be understood as processes, flows, and methods described in each embodiment may be changed as long as there are no constraints, such as a relationship in which one step uses the results of another step that precedes it.

The terms 1st, 2nd, through Nth (N is an integer) used in each embodiment and in the claims are used to distinguish between two or more configurations or methods of the same type, and do not limit the order or superiority or inferiority.

The electronic control device in each embodiment is assumed to be an electronic control device that is installed in a vehicle, but the electronic control device of the present invention can be applied to any electronic control system, except as specifically limited by the claims.

Examples of the form of the device of the present invention are as follows.
Examples of the component form include a semiconductor element, an electronic circuit, a module, and a microcomputer.
Examples of semi-finished products include an electronic control unit (ECU) and a system board.
Finished product forms include mobile phones, smartphones, tablets, personal computers (PCs), workstations, and servers.
Other examples include devices with communication functions, such as video cameras, still cameras, and car navigation systems.

Additionally, necessary functions such as antennas and communication interfaces may be added to each device.

In addition, the present invention can be realized not only by dedicated hardware having the configuration and functions described in each embodiment, but also as a combination of a program for implementing the present invention recorded on a recording medium such as a memory or hard disk, and general-purpose hardware having a dedicated or general-purpose CPU and memory capable of executing the program.

Programs stored in non-transient, physical recording media (e.g., external storage devices (hard disks, USB memory, CDs/BDs, etc.) or internal storage devices (RAM, ROM, etc.)) of dedicated or general-purpose hardware can also be provided to the dedicated or general-purpose hardware via the recording media, or via a communication line from a server without using a recording media. This makes it possible to always provide the latest functions through program upgrades.

The electronic control device of the present invention has been described as an on-board electronic control device that is primarily installed in automobiles, but it can be applied to any moving object, such as motorcycles, ships, trains, and aircraft. It can also be applied to any product that includes a microcomputer, not just moving objects.

1 Electronic control system, 10 Electronic control device, 110 Hypervisor, 120 Hypervisor, 130 Real storage, 140 First virtual machine, 141 File acquisition unit, 144 Virtual storage, 146 Determination unit, 147 Distribution unit, 148 Update instruction unit, 150 Second virtual machine, 160 Third virtual machine, 210 Hypervisor, 230 Fourth virtual machine

Claims (16)

An electronic control device having a virtual machine managed by a hypervisor,
A file acquisition unit (141) for acquiring a file for updating software;
A storage unit (130, 144) for storing the file;
Equipped with
The first virtual machine (140) is a virtual machine.
a determination unit (146) that determines whether a first hypervisor (110) that manages the first virtual machine is the same as a second hypervisor (110, 120, 210) that manages a second virtual machine (150, 160, 230) connected to the first virtual machine;
a delivery unit (147) that delivers the file to the second virtual machine when the determination unit determines that the first hypervisor and the second hypervisor are different;
An electronic control device (10). The first virtual machine further comprises:
an update unit (143) that updates software of the first virtual machine using the file by accessing the storage unit;
The electronic control device according to claim 1. The first virtual machine further includes an update instruction unit (148) that instructs the second virtual machine to update;
The update instruction unit is
instructing, when the determination unit determines that the first hypervisor and the second hypervisor are different, to update software of the second virtual machine using the file distributed by the distribution unit;
instructing, when the determination unit determines that the first hypervisor and the second hypervisor are the same, to update software of the second virtual machine using the file by accessing the storage unit;
The electronic control device according to claim 1. In a case where the plurality of virtual machines owned by the electronic control device are managed by one hypervisor, the determination unit determines that the first hypervisor and the second hypervisor are the same when determining that the second virtual machine is a virtual machine owned by the electronic control device.
The electronic control device according to claim 1. the first hypervisor and the second hypervisor are the same hypervisor;
The storage unit is a storage unit (130) managed by the hypervisor.
The electronic control device according to claim 1. The first virtual machine and the second virtual machine can access the storage unit only when updating the first virtual machine and the second virtual machine using the file stored in the storage unit.
6. The electronic control device according to claim 5. The storage unit is a storage unit (144) realized by the first virtual machine.
The electronic control device according to claim 1. The determination unit further determines whether to deliver the file to the second virtual machine based on a first safety level indicating a safety level related to the first virtual machine and a second safety level indicating a safety level related to the second virtual machine.
The electronic control device according to claim 1 . The first virtual machine comprises:
A platform (1401);
An application (1402) that runs on the platform;
The electronic control device according to claim 1 , further comprising: The electronic control device further includes the second virtual machine (150, 160),
The second virtual machine has a second platform (1501, 1601) different from the first platform, which is the platform;
The electronic control device according to claim 9. The electronic control device is mounted on a moving object.
11. An electronic control device according to any one of claims 1 to 10. 1. A software update method executed on an electronic control device having a virtual machine managed by a hypervisor, comprising:
A file for updating the software is obtained (S101).
The file is stored in a storage unit (130, 144) (S103).
determining whether a first hypervisor (110) that manages a first virtual machine (140) that is the virtual machine is the same as a second hypervisor (110, 120, 210) that manages a second virtual machine (150, 160, 230) connected to the first virtual machine (S106);
When the first hypervisor and the second hypervisor are different, the file is delivered to the second virtual machine (S109);
How to update software. A software update program executable on an electronic control device having a virtual machine managed by a hypervisor, comprising:
A file for updating the software is obtained (S101).
The file is stored in a storage unit (130, 144) (S103).
determining whether a first hypervisor (110) that manages a first virtual machine (140) that is the virtual machine is the same as a second hypervisor (110, 120, 210) that manages a second virtual machine (150, 160, 230) connected to the first virtual machine (S106);
When the first hypervisor and the second hypervisor are different, the file is delivered to the second virtual machine (S109);
A software update program that causes the electronic control unit to execute a process .
An electronic control system having a first electronic control unit (10) and a second electronic control unit (20),
The first electronic control device having a first virtual machine (140) managed by a first hypervisor (110),
A file acquisition unit (141) for acquiring a file for updating software;
A storage unit (130, 144) for storing the file;
The first virtual machine comprises:
a determination unit (146) that determines whether the first hypervisor is the same as a second hypervisor (210) that manages a second virtual machine (230) of the second electronic control device;
a delivery unit (147) that delivers the file to the second virtual machine when the determination unit determines that the first hypervisor and the second hypervisor are different;
having
The second virtual machine comprises:
an update unit (231) that updates the second virtual machine using the file by accessing the storage unit or using the file distributed by the distribution unit;
Electronic control system (1). The electronic control system has a domain (2A, 2B) including the first electronic control device and the second electronic control device,
The first electronic control device is a domain controller (30A, 30B) that controls the electronic control devices included in the domain.
15. The electronic control system of claim 14. The electronic control system has a domain (2A, 2B) including the second electronic control device,
The first electronic control device is a gateway device (40) connected to a plurality of buses;
The second electronic control device is a domain controller (30A, 30B) that controls the electronic control devices included in the domain and is connected to the gateway device via one of the plurality of buses, or the electronic control device (50A, 51A, 50B, 51B) that is controlled by the domain controller.
15. The electronic control system of claim 14.