Vehicle control device and vehicle control method

Abstract

To provide a vehicle control device which loads a plurality of pieces of vehicle control software using a hypervisor.SOLUTION: A vehicle control device includes a hypervisor capable of achieving a plurality of virtual machines. The plurality of virtual machines includes a management virtual machine (first virtual machine) for managing communication between the virtual machines. The hypervisor includes a first shared memory for storing communication data outputted from any one of the virtual machines, and a second shared memory for storing communication data inputted into any one of the virtual machines. A communication start time and a communication finish time are fixed for each piece of communication data, and a transmission source virtual machine stores the communication data in the first shared memory at a time point before the communication start time of the communication data, and the management virtual machine reads out the communication data from the first shared memory at the communication start time, and stores the communication data into the second shared memory at the communication finish time. A reception destination virtual machine reads out the communication data from the second shared memory at a time point later than the communication finish time.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to a vehicle control device and a vehicle control method. [Background technology]

[0002] As vehicle control, as typified by autonomous driving, becomes more sophisticated and complex, there is a demand for the integration of vehicle control devices and continuous improvement of the vehicle control software installed in the vehicle control devices. Accordingly, the automotive industry is moving from the conventional distributed architecture, in which a vehicle control device is installed for each sensor or actuator, to a central zone architecture, in which several high-performance vehicle control devices are installed and consolidated. In the transition to the central zone architecture, vehicle control software that was previously installed in different vehicle control devices is now installed in the same vehicle control device, so it is important to establish non-interference between the vehicle control software. Therefore, the introduction of a hypervisor, a virtualization technology that separates the hardware resources used by each vehicle control software and enables safe sharing of hardware by methods such as exclusive control and time sharing for hardware resources that must be shared by multiple vehicle control software, has attracted attention.

[0003] Patent Document 1 discloses a virtualization system in which a plurality of virtual computers run on a single physical computer having a plurality of cores, the system comprising a plurality of hardware pieces, a hardware control core which is the core for controlling the operation of each of the plurality of hardware pieces, a plurality of virtual computer cores which are the cores for running a guest OS which is an OS of the virtual computers, and a shared memory which is a memory which can be accessed simultaneously and in parallel by the hardware control core and each of the plurality of virtual computer cores, wherein one of the virtual computers is set to operate exclusively using one or more of the virtual computer cores, the hardware control core comprises a device driver unit which controls the operation of each of the plurality of hardware pieces by executing a device driver corresponding to each of the plurality of hardware pieces, communication between the hardware control core and the virtual computer cores is realized by saving data to the shared memory and reading out the saved data, and the device driver unit controls the operation of the hardware based on data saved by the virtual computer in the shared memory, and provides data input from the hardware to the virtual computer cores by saving it in the shared memory. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2019-057162 A Summary of the Invention [Problem to be solved by the invention]

[0005] In the invention described in Patent Document 1, there is room for consideration in reducing the development costs of a vehicle control device equipped with a plurality of vehicle control software programs using a hypervisor. [Means for solving the problem]

[0006] A vehicle control device according to a first aspect of the present invention is a vehicle control device equipped with a hypervisor capable of realizing multiple virtual machines, the multiple virtual machines including a management virtual machine that manages communication between virtual machines, and a group of virtual machines whose communications are managed by the management virtual machine, the hypervisor equipped with a first shared memory that stores communication data output from any one of the virtual machines in the virtual machine group, and a second shared memory that stores the communication data input to any one of the virtual machines in the virtual machine group, a communication start time and a communication end time are defined for each piece of communication data, a virtual machine that is a sender of the communication data stores the communication data in the first shared memory at a time before the communication start time of the communication data, the management virtual machine reads the communication data from the first shared memory at the communication start time and stores the communication data in the second shared memory at the communication end time, and a virtual machine that is a recipient of the communication data reads the communication data from the second shared memory at a time after the communication end time. A vehicle control method according to a second aspect of the present invention is a vehicle control method executed by a vehicle control device having a hypervisor capable of realizing multiple virtual machines, the multiple virtual machines including a management virtual machine that manages communication between the virtual machines, and a group of virtual machines whose communications are managed by the management virtual machine, the hypervisor having a first shared memory that stores communication data output from any of the virtual machines in the virtual machine group, and a second shared memory that stores the communication data input to any of the virtual machines in the virtual machine group, wherein a communication start time and a communication end time are defined for each of the communication data, and the vehicle control method includes a virtual machine that is a source of the communication data storing the communication data in the first shared memory at a time before the communication start time of the communication data, the management virtual machine reading out the communication data from the first shared memory at the communication start time and storing the communication data in the second shared memory at the communication end time, and a virtual machine that is a recipient of the communication data reading out the communication data from the second shared memory at a time after the communication end time. Effect of the Invention

[0007] According to the present invention, it is possible to reduce the development costs of a vehicle control device equipped with a plurality of vehicle control software programs using a hypervisor. [Brief description of the drawings]

[0008] [Figure 1] Hardware configuration diagram of a vehicle control device according to a first embodiment [Diagram 2] Software configuration diagram of a vehicle control device according to a first embodiment [Diagram 3] A diagram showing reception of time notifications from each timer in the first CPU [Figure 4] FIG. 11 is a diagram showing whether or not each CPU accepts a time notification from each timer in the first embodiment. [Diagram 5] A diagram showing an example of time window division by a hypervisor [Figure 6] FIG. 6 is a diagram showing time window allocation information in the case of FIG. 5. [Figure 7] A diagram showing an example of waiting for time window allocation [Figure 8] FIG. 13 is a diagram showing a data flow from a first vehicle control application to a second vehicle control application installed in a different device. [Figure 9] FIG. 1 is a diagram showing a data flow from a first vehicle control application to a second vehicle control application installed in the same device. [Figure 10] A diagram showing an example of fixed timing [Figure 11] FIG. 13 illustrates data transmission from a first vehicle control app to a second vehicle control app. [Figure 12] A diagram showing shared memory settings information [Figure 13] Pseudocode showing the processing of the communication management application corresponding to Figure 10 [Figure 14] Diagram showing the read margin time [Figure 15] Diagram showing write margin time [Figure 16]Diagram showing the effect of fixing communication timing [Figure 17] Hardware configuration diagram of a vehicle control device according to a second embodiment [Figure 18] Software configuration diagram of a vehicle control device according to a second embodiment [Figure 19] FIG. 13 is a diagram showing whether or not each CPU accepts a time notification from each timer in the second embodiment. [Figure 20] FIG. 11 is a configuration diagram of a vehicle according to a third embodiment. [Figure 21] Software configuration diagram of a vehicle control device according to a third embodiment [Figure 22] Software configuration diagram of the second vehicle control device [Figure 23] FIG. 13 is a diagram showing an example in which timing is fixed in the third embodiment; [Figure 24] FIG. 13 is a diagram showing shared memory setting information of a vehicle control device. [Diagram 25] Pseudocode showing the processing of the communication management app [Figure 26] FIG. 13 is a diagram showing shared memory setting information of a second vehicle control device. [Figure 27] Pseudocode showing the processing contents of the second communication management application [Figure 28] Hardware configuration diagram of a vehicle control device according to a fourth embodiment [Figure 29] Software configuration diagram of a vehicle control device according to a fifth embodiment DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] --First embodiment-- Hereinafter, a first embodiment of a vehicle control device and a vehicle control method will be described with reference to FIGS.

[0010] <Vehicle control device 500> FIG. 1 is a hardware configuration diagram of a vehicle control device 500. The vehicle control device 500 includes a first CPU 1, a second CPU 2, a third CPU 3, a fourth CPU 4, a fifth CPU 5, a memory 6, a first timer 7, a second timer 8, a third timer 9, a fourth timer 10, a fifth timer 11, and a sixth timer 12. Each of the first CPU 1 to the fifth CPU 5 is a central processing unit. Each of the first CPU 1 to the fifth CPU 5 may be a physically independent CPU, or may be different arithmetic cores in the same CPU. Each of the first CPU 1 to the fifth CPU 5 loads a program stored in a ROM (not shown) into the memory 6 and executes the program. Each of the first timer 7 to the sixth timer 12 is hardware for measuring time. The vehicle control device 500 is, for example, one electronic control unit (ECU).

[0011] 2 is a software configuration diagram of the vehicle control device 500. A first virtual machine 101, a second virtual machine 102, a third virtual machine 103, a fourth virtual machine 104, and a fifth virtual machine 105 are configured on a hypervisor 100. The first virtual machine 101 is executed by a first CPU1, the second virtual machine 102 is executed by a second CPU2, the third virtual machine 103 is executed by a third CPU3 and a fourth CPU4, and the fourth virtual machine 104 and the fifth virtual machine 105 are executed by a fifth CPU5. Hereinafter, the first virtual machine 101 is also referred to as a "management virtual machine." The second virtual machine 102 to the fifth virtual machine 105 are also referred to as a "virtual machine group."

[0012] The first virtual machine 101 includes a first OS (Operating System) 106 and a communication management application 111. The second virtual machine 102 includes a second OS 107 and a first vehicle control application 112. The third virtual machine 103 includes a third OS 108 and a second vehicle control application 113. The fourth virtual machine 104 includes a fourth OS 109 and a third vehicle control application 114. The fifth virtual machine 105 includes a fifth OS 110 and a fourth vehicle control application 115. The first vehicle control application 112 to the fourth vehicle control application 115 perform some calculation related to the control of the vehicle equipped with the vehicle control device 500, and transmit the calculation result to the other control applications. Hereinafter, data exchanged between the vehicle control applications is called "communication data". As described later, the communication management application 111 manages the communication data. The communication data may be a single piece of data or multiple pieces of data. There is no particular limit to the size of the communication data, and it may be, for example, 1 byte or 1 MB or more.

[0013] <Timer> Each of the first timer 7 to the sixth timer 12 has a role of notifying a CPU of time. Each timer is set in advance as to which CPU it will notify of time to. In this embodiment, the first timer 7 is used for the hypervisor 100, the second timer 8 for the first OS 106, the third timer 9 for the second OS 107, the fourth timer 10 for the third OS 108, the fifth timer 11 for the fourth OS 109, and the sixth timer 12 for the fifth OS 110.

[0014] FIG. 3 is a diagram showing reception of time notifications from timers in the first CPU1. Each CPU has a notification reception unit that receives time notifications from each timer. As shown in FIG. 2, the first CPU1 executes a hypervisor 100 and a first virtual machine 101, and the first virtual machine 101 includes a first OS 106. Therefore, the first CPU1 needs to receive a time notification from a first timer 7 for the hypervisor 100, and needs to receive a time notification from a second timer 8 for the first OS 106. The first CPU1 does not receive time notifications from timers other than the first timer 7 and the second timer 8. Therefore, as shown in FIG. 3, in the first CPU1, time notifications from timers other than the first timer 7 and the second timer 8 are disabled.

[0015] Fig. 4 is a diagram showing whether each CPU accepts a time notification from a timer. In Fig. 4, "YES" is entered for combinations for which a time notification is accepted, and "NO" is entered for combinations for which a time notification is not accepted. The second CPU 2 executes a hypervisor 100 and a second virtual machine 102, and the second virtual machine 102 includes a second OS 107. Therefore, the second CPU 2 needs to accept a time notification from the first timer 7 for the hypervisor 100, needs to accept a time notification from the third timer 9 for the second OS 107, and does not accept time notifications from other timers.

[0016] The third CPU3 and the fourth CPU4 execute the hypervisor 100 and the third virtual machine 103, and the third virtual machine 103 includes a third OS 108. Therefore, the third CPU3 and the fourth CPU4 need to receive time notifications from the first timer 7 for the hypervisor 100 and need to receive time notifications from the fourth timer 10 for the third OS 108, but do not receive time notifications from other timers.

[0017] The fifth CPU 5 executes the hypervisor 100, the fourth virtual machine 104, and the fifth virtual machine 105. The fourth virtual machine 104 includes a fourth OS 109, and the fifth virtual machine 105 includes a fifth OS 110. Therefore, the fifth CPU 5 needs to accept a time notification from the first timer 7 for the hypervisor 100, and needs to accept a time notification from the fifth timer 11 for the fourth OS 109. Furthermore, the fifth CPU 5 needs to accept a time notification from the sixth timer 12 for the fifth OS 110, and does not accept time notifications from other timers.

[0018] <Hypervisor> The role and operation of the hypervisor 100 will be described. The hypervisor 100 constitutes a virtual machine, and provides an environment that is logically equivalent to a case in which software in the virtual machine exists in another vehicle control device within the same vehicle control device 500 but outside the virtual machine. The provision of this equivalent environment is achieved by spatial and temporal separation. Spatial separation is the separation of hardware usage, such as memory area division. Temporal separation is the separation of timing when hardware is shared so that multiple virtual machines do not use the shared hardware at the same time.

[0019] The hypervisor 100 has higher operational authority than any other software. The hypervisor 100 separates the hardware resources that each virtual machine actually uses. However, for hardware resources shared among multiple virtual machines, in order to prevent multiple virtual machines from simultaneously accessing the hardware resources and causing undefined behavior, a time span called a time window is set, and during each time window, only one pre-specified virtual machine is allowed to use the hardware resources.

[0020] Regarding the separation of hardware resources, when a CPU attempts to access a memory area other than that allocated to that CPU, the hypervisor 100 prohibits the access. For example, in the situation shown in Fig. 2, the second CPU 2 can access the area of ​​the memory 6 allocated for the second virtual machine 102, but cannot access the area allocated for the third virtual machine 103.

[0021] In this embodiment, memory access is monitored by a memory protection unit built into the CPU. The processing of the hypervisor 100 occurs after the memory protection unit detects a memory access violation, and performs an operation to stop the virtual machine that caused the memory access violation. When the memory protection unit does not detect a memory access violation, the hypervisor 100 does not perform any processing.

[0022] Therefore, when only one virtual machine (herein referred to as a "solo-execution virtual machine") is assigned to one CPU and the solo-execution virtual machine does not share any hardware resources with other virtual machines, the following occurs. That is, unless the solo-execution virtual machine causes a memory access violation, the application in the solo-execution virtual machine operates in the same manner as when it is executed directly on the hardware resources of the vehicle control device 500 without going through the hypervisor 100. In the case of FIG. 2, the first virtual machine 101, the second virtual machine 102, and the third virtual machine 103 correspond to the above-mentioned solo-execution virtual machines. The first OS 106 is always executed in the first CPU 1, the second OS 107 is always executed in the second CPU 2, and the third OS 108 is always executed in the third CPU 3 and the fourth CPU 4.

[0023] Therefore, when the second timer 8 notifies the time, the notification is immediately transmitted to the first OS 106, and if the notified time is the time to start the processing of the communication management application 111, the first OS 106 immediately starts the communication management application 111 and executes the processing of the communication management application 111. Similarly, when the third timer 9 notifies the time, the notification is immediately transmitted to the second OS 107, and if the notified time is the time to start the processing of the first vehicle control application 112, the second OS 107 immediately starts the first vehicle control application 112 and executes the processing of the first vehicle control application 112. Similarly, when the fourth timer 10 notifies the time, the notification is immediately transmitted to the third OS 108, and if the notified time is the time to start the processing of the second vehicle control application 113, the third OS 108 immediately starts the second vehicle control application 113 and executes the processing of the second vehicle control application 113.

[0024] Meanwhile, the fourth virtual machine 104 and the fifth virtual machine 105 both run on the fifth CPU 5. In this case, the hypervisor 100 uses a time window to prevent the fourth virtual machine 104 and the fifth virtual machine 105 from running simultaneously. The execution timing of the fourth virtual machine 104 and the fifth virtual machine 105 will be described with reference to Figures 5 and 6.

[0025] 5 is a diagram showing an example of time window division by the hypervisor 100. The hypervisor 100 switches the virtual machine executed by the fifth CPU 5 every 1 ms. The first 1 ms after the hypervisor 100 starts is a time window in which the fifth CPU 5 executes the fourth virtual machine 104. The next 1 ms is a time window in which the fifth virtual machine 105 executes. The further next 1 ms is a time window in which the fourth virtual machine 104 is executed again.

[0026] 5, the time window in which the fourth virtual machine 104 is executed is denoted as "WT4," and the time window in which the fifth virtual machine 105 is executed is denoted as "WT5." In this manner, the hypervisor 100 periodically allocates time windows to each virtual machine for the fifth CPU 5. This allocation method is determined in advance before starting the virtual machines, and is written as time window allocation information 1000 and stored inside the hypervisor 100.

[0027] Fig. 6 is a diagram showing time window allocation information 1000 in the case of Fig. 5. The time window allocation information 1000 includes a time window number for identifying each time window, the time width of the time window, and information on the virtual machine executed by the fifth CPU 5 in the time window. Note that, in this embodiment, the time width of all the time windows is the same at 1 ms, but the time width may be different for each time window.

[0028] The hypervisor 100 receives a time notification from the first timer 7, and at time 0, assigns a time window with a time window number of 1 included in the time window allocation information 1000. Thereafter, when the hypervisor 100 receives a time notification of 1 ms from the first timer 7, it suspends the execution of the fourth virtual machine 104 by the fifth CPU 5, and starts the execution of the fifth virtual machine 105. Further thereafter, when the hypervisor 100 receives a time notification of 2 ms from the first timer 7, it suspends the execution of the fifth virtual machine 105, and since it has reached the end of the time window allocation information 1000, it returns to the beginning, and starts the execution of the fourth virtual machine 104 with the time window number set to "1" again. In this way, the fourth virtual machine 104 and the fifth virtual machine 105 are alternately executed by the fifth CPU 5 every 1 ms.

[0029] <Processing timing fluctuations due to waiting for time window allocation> 7 is a diagram showing an example of waiting for a time window allocation. In this embodiment, a time window wait may occur in the fourth virtual machine 104 and the fifth virtual machine 105 sharing the fifth CPU 5. The fourth virtual machine 104 and the fifth virtual machine 105 each include a third vehicle control application 114 and a fourth vehicle control application 115 to be processed in a 5 ms cycle. The fourth OS 109 mounted on the fourth virtual machine 104 sets the fifth timer 11 when it is first started by the hypervisor 100. After this, the fifth timer 11 notifies the fifth CPU 5 of the time every 5 ms counting from the timing at which it is set.

[0030] When the fourth OS 109 confirms receipt of the time notification from the fifth timer 11, it determines that the third vehicle control application 114 should be executed, and starts the third vehicle control application 114. Similarly, the fifth OS 110 mounted on the fifth virtual machine 105 sets the sixth timer 12 when started up for the first time by the hypervisor 100, and thereafter, the sixth timer 12 notifies the fifth CPU 5 of the time every 5 ms counting from the timing when the sixth timer 12 was set.

[0031] When the fifth OS 110 confirms receipt of the time notification from the sixth timer 12, it determines that the fourth vehicle control application 115 should be executed and starts the fourth vehicle control application 115. As shown in FIG. 5 and FIG. 6, the hypervisor 100 allocates the first 1 ms to the fourth virtual machine 104 and allocates the next 1 ms to the fifth virtual machine 105. In FIG. 7, the time periods during which each virtual machine is not executed are indicated by hatching with dots. Specifically, the time periods during which the fourth virtual machine 104 is not executed are time periods between 1 ms and 2 ms, between 3 ms and 4 ms, between 5 ms and 6 ms, etc. The time periods during which the fifth virtual machine 105 is not executed are opposite to those of the fourth virtual machine 104, and are time periods between 0 ms and 1 ms, 2 ms and 3 ms, etc.

[0032] The fifth timer 11 starts counting the time from 0 ms, which is the time when the fourth OS 109 is first activated. The sixth timer 12 starts counting the time from 1 ms, which is the time when the fifth OS 110 is first activated. The fifth timer 11 notifies the fifth CPU 5 of the time at 5 ms, after 5 ms has elapsed. However, the time window allocated to the fifth virtual machine 105 is between 5 ms and 6 ms. Therefore, the third vehicle control application 114 is activated after the hypervisor 100 switches the time window to the fourth virtual machine 104 at 6 ms. Specifically, this is the time when the fourth OS 109 confirms that the fifth CPU 5 has received the time notification from the fifth timer 11 after the time window is switched.

[0033] Therefore, the processing of the third vehicle control application 114 starts at time 6 ms. In this way, the timing of application processing may vary due to waiting for time window allocation. The next time the fifth timer 11 notifies the time is at time 10 ms. Since a time window is allocated to the fourth virtual machine 104 from time 10 ms to 11 ms, the fourth OS 109 confirms the time notification from the fifth timer 11 and immediately starts processing the third vehicle control application 114. The operation is similar for the fifth virtual machine 105. As described above, when the hypervisor 100 shares a CPU with multiple virtual machines, the timing of application processing varies due to waiting for time window allocation.

[0034] <Latency fluctuation before and after integration> In order to mount vehicle control software that was previously mounted on different vehicle control devices on the same vehicle control device, a hypervisor 100 is used.

[0035] 8 is a diagram showing a data flow from the first vehicle control application 112 mounted on different devices to the second vehicle control application 113 as in the conventional configuration. In this conventional configuration, the first vehicle control application 112 is mounted on the pre-integration first vehicle control device 13, and the second vehicle control application 113 is mounted on the pre-integration second vehicle control device 14. The pre-integration first vehicle control device 13 and the pre-integration second vehicle control device 14 are connected by a communication bus 118. The communication bus 118 uses a known communication protocol such as CAN (Controller Area Network) or IEEE802.3.

[0036] The first vehicle control application 112 and the second vehicle control application 113 are both executed every 10 ms. Since the second vehicle control application 113 performs processing using the processing result of the first vehicle control application 112, the second vehicle control application 113 needs to receive the processing result from the first vehicle control application 112 via the communication bus 118. The pre-integration first vehicle control device 13 includes a first communication driver 116. Note that the first communication driver 116 may be executed by a CPU core different from that of the first vehicle control application 112. The first communication driver 116 is also started every 10 ms, and the first communication driver 116 stores the latest processing result of the first vehicle control application 112 in, for example, a packet and transmits it to the communication bus 118.

[0037] The pre-integration second vehicle control device 14 includes a second communication driver 117. The second communication driver 117 may be executed by a CPU core different from that of the second vehicle control application 113. When a packet arrives, the second communication driver 117 extracts data from the packet and stores the extracted data in a receiving port prepared for the second vehicle control application 113. The second vehicle control application 113 is started every 10 ms, and extracts and processes data stored in the receiving port. Therefore, as shown in the lower part of FIG. 8, the time (latency) from when the processing of the first vehicle control application 112 starts to when the processing of the second vehicle control application 113 ends using the processing result is approximately just under 30 ms.

[0038] FIG. 9 is a diagram showing a data flow from the first vehicle control application 112 to the second vehicle control application 113 in a case where the first vehicle control application 112 and the second vehicle control application 113 are mounted on the same vehicle control device 500 as in this embodiment. However, the timing of data transfer in this diagram is different from that in this embodiment. In a case where the first vehicle control application 112 and the second vehicle control application 113 are integrated using the hypervisor 100 and mounted on the same vehicle control device 500, the shared memory 119 is used for data transfer. The applications and OS in the second virtual machine 102 and the third virtual machine 103 can access this shared memory 119. In this case, unlike the example shown in FIG. 8, no data transfer occurs via the communication bus 118, so the second vehicle control application 113 can access the data immediately after the first vehicle control application 112 stores the data in the shared memory 119.

[0039] Therefore, when the first vehicle control application 112 and the second vehicle control application 113 are activated every 10 ms, as shown in the lower part of Fig. 9, the time (latency) from when the processing of the first vehicle control application 112 starts to when the processing of the second vehicle control application 113 ends using the processing result of the first vehicle control application 112 is approximately 20 ms. This is shorter by about 10 ms compared to the case of Fig. 8. Therefore, it can be said that Fig. 9 shows that the latency is shortened when vehicle control software that was conventionally mounted on different vehicle control devices is mounted on the same vehicle control device without any special ingenuity. Due to the shortening of the latency, the processing result of the first vehicle control application 112 that the second vehicle control application 113 refers to is advanced by one cycle, and the processing result may change before and after the integration.

[0040] <Fixing communication timing between virtual machines> As shown in Fig. 7, when multiple virtual machines share the same CPU, fluctuations in processing timing occur due to waiting for time window allocation by the hypervisor 100. Also, as shown in Fig. 8 and Fig. 9, fluctuations in latency occur due to communication between vehicle control devices being replaced by memory sharing, which is communication within the vehicle control device. It is costly to verify that these fluctuations do not affect the running of the vehicle.

[0041] Therefore, in this embodiment, the timing at which communication is started between the virtual machines (hereinafter referred to as "communication start timing" or "communication start time") and the timing at which communication is ended (hereinafter referred to as "communication end timing" or "communication end time") are fixed in advance. By fixing the timing at which communication is started and ended between the virtual machines in advance, it is possible to ensure that the vehicle control device 500 is operating normally by satisfying the following two conditions. The first condition is that each virtual machine stores data in the shared memory before the fixed communication start timing. The second condition is that each virtual machine reads data from the shared memory after the fixed communication end timing. This localizes the verification range from the entire vehicle control device 500 to each virtual machine.

[0042] FIG. 10 is a diagram showing an example in which the timing is fixed. In this diagram, the same hatching indicates that there is a data exchange relationship. With reference to FIG. 10, a case in which the processing result of the first vehicle control application 112 is passed to the second vehicle control application 113 will be described. The first vehicle control application 112 and the second vehicle control application 113 are executed every 10 ms from time 0 ms. The timing at which the processing result of the first vehicle control application 112 starts to be communicated to the second vehicle control application 113 is defined as the time at which the first vehicle control application 112 is next started. For example, the processing result of a process started at time 0 ms starts to be communicated at 10 ms, and the processing result of a process started at time 10 ms starts to be communicated at 20 ms.

[0043] The time when the processing result reaches the second vehicle control application 113, that is, the communication end timing, is set to be the time after the communication start timing when the second vehicle control application 113 is next activated. For example, if the communication starts at time 10 ms, the communication ends at time 20 ms, and if the communication starts at time 20 ms, the communication ends at time 30 ms. As a result, the latency from the start of processing of the first vehicle control application 112 to the end of processing of the second vehicle control application 113 is just under 30 ms, which is the same as in FIG. 8 and does not cause latency fluctuation.

[0044] By setting the start and end times of communication in this manner, if the first vehicle control application 112 completes processing before the start of the communication start timing, i.e., within 10 ms after being launched, the latency can be fixed at just under 30 ms, similar to that in Fig. 8. As described above, the timing at which the first vehicle control application 112 starts communicating the processing result is set to the time at which the first vehicle control application 112 is next launched, but this is primarily intended to make the latency approximately the same as that in Fig. 8. In addition, the determination of this timing is also based on the premise that the execution time of each application should be shorter than the execution cycle of each application.

[0045] Similarly, referring to Fig. 10, a case will be described where the processing result of the third vehicle control application 114 is passed to the second vehicle control application 113. The third vehicle control application 114 and the fourth vehicle control application 115 are executed at a cycle of 5 ms from time 0 ms. The processing results of the third vehicle control application 114 and the fourth vehicle control application 115 are communicated at the timing when each of them is next executed. The communication end timing is the time when the second vehicle control application 113 is next activated after the communication start timing. However, while the second vehicle control application 113 is executed at a cycle of 10 ms, the third vehicle control application 114 and the fourth vehicle control application 115 are executed at a cycle of 5 ms, which is twice as frequent.

[0046] Therefore, for example, the processing result of the third vehicle control application 114 and the fourth vehicle control application 115 used by the second vehicle control application 113, which starts processing at time 20 ms, has the following two candidates. The first candidate is the processing result of the third vehicle control application 114 and the fourth vehicle control application 115, which started processing at time 10 ms. The second candidate is the processing result of the third vehicle control application 114 and the fourth vehicle control application 115, which started processing at time 15 ms.

[0047] The decision as to which processing result should be adopted is based on which is closer to the data flow before integration. This decision, i.e., the timing to start communication and the timing to end communication, may be determined by a human designer, or may be replaced in part or entirely by automatic processing. In the example shown in the figure, the processing results of the third vehicle control application 114 and the fourth vehicle control application 115, which started processing at time 10 ms, are used by the second vehicle control application 113, which starts processing at time 20 ms.

[0048] In this case, the processing results of the third vehicle control application 114 and the fourth vehicle control application 115 at the time 5 ms or the time 15 ms may be transmitted, or the execution of the application itself may be omitted. When transmitting these processing results, the values ​​written in the shared memory as the transmission results are not read by the second vehicle control application 113 because new values ​​are written in the shared memory before the second vehicle control application 113 next reads them. In this way, as long as the third vehicle control application 114 completes the processing before the start of the communication start timing, that is, within 5 ms from being started, regardless of whether or not there is a wait for a time window allocation by the hypervisor 100, the latency can be fixed to just under 20 ms.

[0049] A method for fixing the timing of starting and ending communication between virtual machines as shown in Fig. 10 will be described below. When communication is directly performed between virtual machines as shown in Figs. 7 to 9, it is unavoidable to wait for time window allocation or to experience fluctuations in latency due to changes in the communication path. Therefore, the first virtual machine 101 is made to occupy the first CPU1, the first virtual machine 101 is not equipped with a vehicle control application but is equipped with a communication management application 111, and all communication between the virtual machines, i.e., memory sharing, is made to go through the first virtual machine 101.

[0050] FIG. 11 is a diagram showing data transmission from the first vehicle control application 112 to the second vehicle control application 113. Specifically, FIG. 11 is a diagram showing a method in which the first vehicle control application 112 of the second virtual machine 102 transmits data to the second vehicle control application 113 of the third virtual machine 103 via the communication management application 111 of the first virtual machine 101. In this embodiment, a first shared memory 120 and a second shared memory 121 are provided for each piece of data transmitted and received between virtual machines. The first shared memory 120 is a memory shared between the data transmission source and the communication management application 111, and the second shared memory 121 is a memory shared between the communication management application 111 and the data reception destination. The first shared memory 120 can also be called a "sending shared memory" since it is used by the transmission source application to transmit data. The second shared memory 121 can also be called a "receiving shared memory" since it is used by the reception destination application to receive data.

[0051] In the example shown in FIG. 11, the first shared memory 120 is shared between the first vehicle control application 112 and the communication management application 111 of the second virtual machine 102, and the second shared memory 121 is shared between the communication management application 111 and the second vehicle control application 113 of the third virtual machine 103. The first shared memory 120 is set to be writable by the data sender and readable by the communication management application 111. The second shared memory 121 is set to be writable by the communication management application 111 and readable by the second vehicle control application 113 of the third virtual machine 103. Similarly, the first shared memory 120 and the second shared memory 121 are provided for data transmitted from the third vehicle control application 114 of the fourth virtual machine 104 to the second vehicle control application 113 and data transmitted from the fourth vehicle control application 115 of the fifth virtual machine 105 to the second vehicle control application 113, respectively.

[0052] 12 is a diagram showing shared memory setting information 1001. The shared memory setting information 1001 is setting information including an address of a memory shared among a plurality of virtual machines, the read / write authority of each virtual machine, and an identifier of each shared memory. The hypervisor 100 sets a shared memory in accordance with the shared memory setting information 1001. The shared memory ID "1" is a first shared memory 120 shared between the first vehicle control application 112 and the communication management application 111 of the second virtual machine 102. The shared memory ID "2" is a second shared memory 121 shared between the communication management application 111 of the first virtual machine 101 and the second vehicle control application 113 of the third virtual machine 103.

[0053] The shared memory ID "3" is a first shared memory 120 shared between the third vehicle control application 114 and the communications management application 111 of the fourth virtual machine 104. The shared memory ID "4" is a second shared memory 121 shared between the communications management application 111 of the first virtual machine 101 and the second vehicle control application 113 of the third virtual machine 103. The shared memory ID "5" is a first shared memory 120 shared between the first vehicle control application 112 and the communications management application 111 of the fifth virtual machine 105. The shared memory ID "6" is a second shared memory 121 shared between the communications management application 111 of the first virtual machine 101 and the second vehicle control application 113 of the third virtual machine 103.

[0054] Fig. 13 is a pseudo code showing the processing contents of the communication management application 111 corresponding to Fig. 10. The processing contents of the communication management application 111 at each time corresponding to the description in Fig. 10 are as follows. In the following explanation, "n" indicates an integer. The time (10*n) ms is the timing at which data communication from the first vehicle control application 112 starts. The time (10*(n-1)) ms is the time at which data communication of the data generated by the first vehicle control application 112 to the second vehicle control application 113 ends. The time (10*(n-1)) ms is the time at which data communication of the data generated by the third vehicle control application 114 to the second vehicle control application 113 ends.

[0055] The time (10*(n-1)) ms is the time when the data communication of the data generated by the fourth vehicle control application 115 to the second vehicle control application 113 ends. The time (10*n)+5 ms is the time when the third vehicle control application 114 starts communicating the data generated immediately before (i.e., when launched at time (10*n) ms). Similarly, the time (10*n)+5 ms is the time when the fourth vehicle control application 115 starts communicating the data generated immediately before (i.e., when launched at time (10*n) ms).

[0056] In order to realize the processes at each time point described above, the communication management application 111 is started at 5 ms intervals, and the process contents are changed each time the application is started. In Fig. 13, this is implemented using an integer variable counter. First, as an initialization process, the counter is initialized to "0". In addition, a variable is prepared in which the communication management application 111 temporarily stores data generated by the first vehicle control application 112, the third vehicle control application 114, and the fourth vehicle control application 115. The communication management application 111 is implemented using a function Com_Manage_App(). To start at 5 ms intervals, Com_Manage_App() is registered in OS_Task(5ms), which is a list of 5 ms periodic tasks in the first OS 106.

[0057] The function Com_Manage_App() is started once every 5 ms by the first OS 106. The processing contents of the function Com_Manage_App() change depending on the number of times it is started. When the function Com_Manage_App() is started for the first time, the variable counter has an initial value of "0", so the remainder when it is divided by "2" is zero, and the condition "counter & 2 == 0" is satisfied, and the shared memory IDs "2, 4, 6" are accessed and data is written. The function Write is a function that takes the shared memory ID to be written as a first argument and the data to be written as a second argument. This is processing to end data communication from the first vehicle control application 112, the third vehicle control application 114, and the fourth vehicle control application 115 to the second vehicle control application 113.

[0058] Next, the shared memory ID "1" is accessed to read the data. The function Read takes the shared memory ID to be read as the first argument, and the address of the variable in which the read data should be stored as the second argument. This is a process for starting data communication from the first vehicle control application 112 to the second vehicle control application 113.

[0059] When the function Com_Manage_App() is launched for the second time, the above-mentioned condition "counter & 2 == 0" is not satisfied, so the process proceeds to the condition "else", where the shared memory IDs "3, 5" are accessed and the data is read. This is a process for starting data communication from the third vehicle control application 114 and the fourth vehicle control application 115 to the second vehicle control application 113. When the function Com_Manage_App() is launched for the third time, the condition "counter & 2 == 0" is satisfied, and when it is launched for the fourth time, the condition "else" is satisfied, and so on.

[0060] 14 is a diagram showing a read margin time for preventing access contention when receiving data from another virtual machine. The communication management application 111 writes data to the second shared memory 121 at the communication end timing. If an application that uses the communicated data is started in memory at the same time as the communication end timing, an access contention occurs, and the data may become undefined or may be corrupted. Therefore, an application that reads data from the second shared memory 121 does not access the second shared memory 121 immediately after being started, but accesses it after a certain time has passed. This elapsed time is called the "read margin time."

[0061] By the application accessing the second shared memory 121 after the read margin time has elapsed after startup, it is guaranteed that the communication management application 111 has already written data to the second shared memory 121. The read margin time may be any time that is sufficient for the communication management application 111 to write data. In general, the processing time of a vehicle control application varies depending on the vehicle surroundings and driving conditions, so it is not easy to set an optimal read margin time. However, since the communication management application 111 only reads and writes data in the shared memory, and the data to be read and written is determined in advance by the shared memory setting information 1001, the processing time required for reading and writing is constant regardless of the vehicle surroundings and driving conditions. In this embodiment, the read margin time is set to "1 ms".

[0062] 15 is a diagram showing a write margin time for preventing access contention when transmitting data to another virtual machine. The communication management application 111 reads data from the first shared memory 120 at the communication start timing. However, there is some time between when the communication management application 111 is started by the first OS 106 at the communication start timing and when it accesses the first shared memory 120 and reads the data. If the vehicle control application that writes data to the first shared memory 120 stores new processing results during this time, data consistency will not be maintained.

[0063] 15, at time 10 ms, the communication management application 111 accesses the first shared memory 120 to read data generated by the first vehicle control application 112 activated at time 0 ms. However, data generated in the first shared memory 120 by the first vehicle control application 112 activated at time 10 ms prior to that is lost. Therefore, an application that writes data to the first shared memory 120 does not immediately write data to the first shared memory 120 when processing is completed in a very short time, but writes the data after a certain period of time has elapsed. This elapsed time is called the "write margin time."

[0064] The application checks the time before writing, and if the write margin time has not elapsed since startup, it waits until the write margin time has elapsed before writing. Ensuring this write margin time ensures that the communication management application 111 has read the previous value data stored in the first shared memory 120. The write margin time may be any time that is sufficient for the communication management application 111 to read the data. In general, the processing time of a vehicle control application varies depending on the vehicle's surrounding environment and driving conditions, so it is not easy to set an optimal write margin time.

[0065] However, since the communication management application 111 only reads and writes data in the shared memory, and the data to be read and written is determined in advance by the shared memory setting information 1001, the processing time required for reading and writing is constant regardless of the vehicle surrounding environment or driving conditions. In this embodiment, the write margin time is set to "3 ms." As shown in Fig. 13, the communication management application 111 writes data to the second shared memory 121 and then reads data from the first shared memory 120, so in this embodiment, the write margin time is set to be longer than the read margin time.

[0066] Fig. 16 is a diagram showing the effect of fixing the communication timing by performing communication via the communication management application 111. As shown in the upper part of Fig. 16, when communication is not performed via the communication management application 111, data generated by the first vehicle control application 112 is used by the second vehicle control application 113 10 ms immediately after the data is stored, resulting in a processing result different from that in the conventional case shown in Fig. 8. In addition, the timing of communication start is the timing of completion of processing of the first vehicle control application 112, and since the processing time of the first vehicle control application 112 varies depending on the vehicle surrounding environment and driving conditions, the communication start timing cannot be fixed.

[0067] 16, when communication goes through the communication management application 111, the communication start timing and communication end timing do not change even if the timing at which the processing of the first vehicle control application 112 is completed changes. This is because the communication start timing is the timing at which the communication management application 111 reads the processing result of the first vehicle control application 112 into the first shared memory 120. The communication end timing is the timing at which the communication management application 111 writes data into the second shared memory 121. In this way, the communication start and end timings can be fixed.

[0068] According to the above-described first embodiment, the following advantageous effects can be obtained. (1) The vehicle control device 500 includes a hypervisor 100 capable of implementing a plurality of virtual machines, a first virtual machine 101 to a fifth virtual machine 105. The first virtual machine 101 manages communication between the virtual machines. The second virtual machine 102 to the fifth virtual machine 105, i.e., the virtual machine group, have their communications managed by the first virtual machine 101. The hypervisor 100 includes a first shared memory 120 that stores communication data output from any one of the virtual machines in the virtual machine group, and a second shared memory 121 that stores communication data input to any one of the virtual machines in the virtual machine group. A communication start time and a communication end time are determined for each piece of communication data. A virtual machine that is a source of communication data stores the communication data in the first shared memory 120 at a time before the communication start time of the communication data. The management virtual machine reads the communication data from the first shared memory 120 at the communication start time, and stores the communication data in the second shared memory 121 at the communication end time. A virtual machine that is a recipient of the communication data reads the communication data from the second shared memory 121 at a time after the communication end time.

[0069] Therefore, the development cost of the vehicle control device 500 equipped with multiple vehicle control software programs using the hypervisor 100 can be reduced. Specifically, by fixing the timing of starting and ending communication and confirming the following two points, it is possible to guarantee that the vehicle control device 500 operates normally, which has the effect of facilitating verification. The first point is that the vehicle control application on each virtual machine has already stored data in the first shared memory 120 before the fixed communication start timing. The second point is that the data has already been retrieved from the second shared memory 121 after the read margin time has elapsed from the fixed communication end timing.

[0070] (2) The first shared memory 120 and the second shared memory 121 are provided for each communication data. The first shared memory 120 is writable by the virtual machine that transmits the communication data and is readable by the management virtual machine. The second shared memory 121 is writable by the management virtual machine and is readable by the virtual machine that receives the communication data. Therefore, access violations can be prevented by applying appropriate access restrictions to the memory.

[0071] (3) The vehicle control device 500 has multiple CPU cores, a first CPU1 to a fifth CPU5. When the hypervisor 100 assigns the execution of multiple virtual machines to the same CPU core, it executes the assigned virtual machines in a pre-fixed order as shown in Figs. 5 and 6, thereby performing time sharing among the virtual machines. The first CPU1 is assigned to the first virtual machine 101, and the second CPU2 to the fifth CPU5 are assigned to the virtual machine group. Therefore, it is possible to operate multiple virtual machines on one CPU by adopting a time sharing method.

[0072] (Variation 1) In the above-described first embodiment, each of the communication management applications 111 and the vehicle control applications runs on a virtual machine. However, a container may be used instead of the virtual machine. In this case, a container engine is used instead of the hypervisor 100. The vehicle control device 500 includes one operating system, and the container engine runs on this operating system, and the container engine executes each container.

[0073] --Second embodiment-- A second embodiment of a vehicle control device and a vehicle control method will be described with reference to Figs. 17 to 19. In the following description, the same components as those in the first embodiment are denoted by the same reference numerals, and differences will be mainly described. Points that are not particularly described are the same as those in the first embodiment. This embodiment differs from the first embodiment mainly in that the first CPU 1 does not occupy the first virtual machine 101 that has the communication management application 111 installed therein.

[0074] <Vehicle control device 500> 17 is a diagram showing a hardware configuration of a vehicle control device 500A in the second embodiment. The vehicle control device 500A includes a first CPU 1, a second CPU 2, a third CPU 3, a memory 6, and a first timer .

[0075] Fig. 18 is a diagram showing the software configuration of a vehicle control device 500A in the second embodiment. The difference from Fig. 2 in the first embodiment is the number of CPUs shown at the bottom of the figure. A first virtual machine 101, a second virtual machine 102, a third virtual machine 103, a fourth virtual machine 104, and a fifth virtual machine 105 are configured on a hypervisor 100A. It is not specified in advance whether each virtual machine is executed by the first CPU1, the second CPU2, or the third CPU3.

[0076] 19 is a diagram showing whether each CPU accepts a time notification from each timer. All of the first CPU1, the second CPU2, and the third CPU3 accept a time notification from the first timer .

[0077] <Hypervisor> The role and operation of the hypervisor 100A will be described. The hypervisor 100A has higher operation authority than any other software, and starts with a higher priority than any other software. The hypervisor 100A notifies each virtual machine of the time notified by the first timer 7. The OS installed in each virtual machine judges whether or not each vehicle control application or communication management application 111 needs to be started at the notified time, and if it judges that it needs to be started, sends a start request for the virtual machine to the hypervisor 100A. When the hypervisor 100A receives the start request, it provides the virtual machine with one of the first CPU1, second CPU2, and third CPU3 that is not currently being used by another virtual machine, that is, allows the virtual machine to use it.

[0078] Each virtual machine processes each vehicle control application or communication management application 111 using a CPU provided by the hypervisor 100A, and when the processing ends, each virtual machine returns the CPU to the hypervisor 100A. When each virtual machine requests the provision of a CPU from the hypervisor 100A, it can specify the number of CPU cores it requests. In this embodiment, the third virtual machine 103 requests two CPU cores from the hypervisor 100A, and the other virtual machines request one CPU core.

[0079] When the first CPU1, second CPU2, and third CPU3 are all being used by virtual machines, and another virtual machine (hereinafter referred to as a "newly requesting virtual machine") requests the provision of a CPU, the hypervisor 100A performs arbitration according to the set priority. That is, if the new requesting virtual machine has a lower priority than any of the virtual machines currently using the CPU (hereinafter referred to as "in-use virtual machines"), the hypervisor 100A makes the new requesting virtual machine wait until any of the in-use virtual machines returns the CPU to the hypervisor 100A. Also, if the new requesting virtual machine has a higher priority than a certain in-use virtual machine, the hypervisor 100A forcibly suspends the use of the CPU by the virtual machine with the lower priority, returns the CPU to the hypervisor 100A, and provides the returned CPU to the new requesting virtual machine.

[0080] <Fixing communication timing between virtual machines> In this embodiment, the first virtual machine 101 on which the communication management application 111 is installed is assigned a higher priority than any of the second virtual machine 102, the third virtual machine 103, the fourth virtual machine 104, and the fifth virtual machine 105. This allows the communication management application 111 to read and write data from the first shared memory 120 and the second shared memory 121 at fixed communication start and end timings, regardless of the presence or absence of a CPU request from the other virtual machines.

[0081] According to the above-described second embodiment, the following advantageous effects can be obtained. (4) The hypervisor 100A can specify startup priorities for multiple virtual machines. When the hypervisor 100A receives startup requests from one or more virtual machines at the same time, it executes the virtual machines with the highest startup priority first, and when the hypervisor 100A receives a startup request from a virtual machine with a high startup priority while a virtual machine with a low startup priority is running, it interrupts the startup of the virtual machine with the low priority and starts the virtual machine with the high startup priority. A startup priority higher than that of any of the virtual machines is set for the first virtual machine 101. Therefore, when the number of CPU cores mounted on the vehicle control device 500 is limited, the communication timing can be fixed without occupying the CPU for the communication management application 111.

[0082] --Third embodiment-- A vehicle control device and a vehicle control method according to a third embodiment will be described with reference to Figs. 20 to 27. In the following description, the same components as those in the first embodiment are given the same reference numerals, and differences will be mainly described. Points that are not particularly described are the same as those in the first embodiment. This embodiment differs from the first embodiment mainly in that the vehicle control device transmits and receives data to and from the outside.

[0083] 20 is a configuration diagram of a vehicle 300 in the third embodiment. The vehicle 300 includes a vehicle control device 500 and a second vehicle control device 200. The vehicle control device 500 and the second vehicle control device 200 are connected via a communication bus 118 so as to be able to communicate with each other.

[0084] 21 is a diagram showing a software configuration of a vehicle control device 500B in the present embodiment. The difference from FIG. 2 in the first embodiment is that the first virtual machine 101 includes a first communication driver 116, and the hypervisor 100B includes a time synchronization unit 122.

[0085] 22 is a software configuration diagram of the second vehicle control device 200. The second vehicle control device 200 has a sixth CPU 15, a seventh CPU 16, an eighth CPU 17, a sixth OS 18, a second communication management application 123, a fifth vehicle control application 19, a sixth vehicle control application 20, and a second communication driver 117.

[0086] The sixth OS 18 has a time synchronization unit 122 that synchronizes time with the vehicle control device 500B. The second communication management application 123 is executed by the sixth CPU 15, and communicates with the vehicle control device 500B using the second communication driver 117. The fifth vehicle control application 19 is executed by the seventh CPU 16, and the sixth vehicle control application 20 is executed by the eighth CPU 17. The processing result of the fifth vehicle control application 19 is sent to the second vehicle control application 113 mounted on the vehicle control device 500B, and the sixth vehicle control application 20 uses the processing result of the fourth vehicle control application 115 mounted on the vehicle control device 500B.

[0087] In this embodiment, communication data exchanged between different devices is also called "inter-device communication data." The inter-device communication data is stored in the first shared memory 120 or the second shared memory 121, just like the communication data. The time at which the communication management application 111 or the second communication management application 123 reads the inter-device communication data from the first shared memory 120 is also called the "inter-device communication start time." The time at which the communication management application 111 or the second communication management application 123 writes the inter-device communication data to the second shared memory 121 is also called the "inter-device communication end time."

[0088] The vehicle control device 500B and the second vehicle control device 200 have their times synchronized with each other by a time synchronization unit 122. The fifth vehicle control application 19 is started by the sixth OS 18 at the same timing as the first vehicle control application 112 and the second vehicle control application 113, and is processed every 10 ms by the seventh CPU 16. The sixth vehicle control application 20 is started by the sixth OS 18 at the same timing as the third vehicle control application 114 and the fourth vehicle control application 115, and is processed every 5 ms by the eighth CPU 17.

[0089] Fig. 23 is a diagram showing an example in which timing is fixed in this embodiment. In the following description, "n" indicates an integer. The processing result of the fifth vehicle control application 19 started at time (10*n) ms is that the communication start timing is time 10*(n+1) ms and the communication end timing is time 10*(n+2) ms. The processing result of the fourth vehicle control application 115 started at time (10*n) ms is that the communication start timing is time (10*n+5) ms and the communication end timing is time (10n+15) ms.

[0090] <Fixing communication timing between virtual machines and vehicle control devices> In this embodiment, in addition to communication between virtual machines, communication between vehicle control devices using the communication bus 118 is also performed via the communication management application 111 and the second communication management application 123. When data is transmitted from the fifth vehicle control application 19 to the second vehicle control application 113, the second communication management application 123 first acquires the data from the fifth vehicle control application 19. Then, the second communication management application 123 transmits the data to the communication bus 118 using the second communication driver 117. The communication management application 111 of the vehicle control device 500B receives data from the communication bus 118 using the first communication driver 116, and passes the received data to the second vehicle control application 113.

[0091] At this time, the communication start timing is the timing when the second communication management application 123 retrieves the data generated by the fifth vehicle control application 19, i.e., the timing when the shared memory between the second communication management application 123 and the fifth vehicle control application 19 is accessed. Also, the communication end timing is the timing when the communication management application 111 passes data to the second vehicle control application 113, i.e., the timing when the shared memory between the communication management application 111 and the second vehicle control application 113 is accessed.

[0092] Similarly, when data is transmitted from the fourth vehicle control application 115 to the sixth vehicle control application 20, first the communication management application 111 acquires the data from the fourth vehicle control application 115. Then, the communication management application 111 transmits the data to the communication bus 118 using the first communication driver 116. The second communication management application 123 of the second vehicle control device 200 receives the data from the communication bus 118 using the second communication driver 117, and passes the received data to the sixth vehicle control application 20.

[0093] At this time, the communication start timing is the timing when the communication management application 111 retrieves the data generated by the fourth vehicle control application 115, i.e., the timing when the shared memory between the communication management application 111 and the fourth vehicle control application 115 is accessed. The communication end timing is the timing when the second communication management application 123 passes the data to the sixth vehicle control application 20, i.e., the timing when the shared memory between the second communication management application 123 and the sixth vehicle control application 20 is accessed.

[0094] 24 is a diagram showing the shared memory setting information 1001 of the vehicle control device 500B in this embodiment. The shared memory IDs "1" to "6" are the same as those in the first embodiment. The shared memory ID "7" is the second shared memory 121 shared between the communication management application 111 of the first virtual machine 101 and the second vehicle control application 113 of the third virtual machine 103. The shared memory ID "8" is the first shared memory 120 shared between the fourth vehicle control application 115 of the fifth virtual machine 105 and the communication management application 111.

[0095] FIG. 25 is a pseudo code showing the processing contents of the communication management application 111 of the vehicle control device 500B in this embodiment. In this embodiment, as shown in FIG. 23, the time (10*n) ms is the timing to end the communication of data from the fifth vehicle control application 19. Also, the time (10*n)+5 ms is the time to start communication of data generated when the fourth vehicle control application 115 was started immediately before, that is, at the time (10*n) ms. Therefore, when the condition "counter & 2 == 0" is satisfied in the function Com_Manage_App(), the shared memory ID "7" is accessed and data is written. This is a process to end the data communication from the fifth vehicle control application 19 to the second vehicle control application 113.

[0096] When the condition "else" is satisfied in the function Com_Manage_App(), the following three processes are performed. First, the shared memory ID "3" is accessed to read the data generated by the fourth vehicle control application 115. Second, the data is transmitted to the second vehicle control device 200 via the communication bus 118. Third, the fifth vehicle control application 19 reads the data that started to be transmitted and arrived at the second vehicle control device 200 5 ms ago, and stores it in the variable tmp_data_from_app_5. This stored data becomes the data that is written by accessing the above-mentioned shared memory ID "7" when the function Com_Manage_App() is started 5 ms later. The function SendCanData takes the data to be transmitted to the communication bus 118 as an argument. The function ReadCanData takes the address of a variable that stores the data received from the communication bus 118 as an argument.

[0097] 26 is a diagram showing the shared memory setting information 1001 of the second vehicle control device 200 in this embodiment. The shared memory ID "1" is the first shared memory 120 shared between the fifth vehicle control application 19 and the second communication management application 123. The shared memory ID "2" is the second shared memory 121 shared between the second communication management application 123 and the sixth vehicle control application 20.

[0098] FIG. 27 is a pseudo code showing the processing contents of the second communication management application 123 of the second vehicle control device 200 in this embodiment. In this embodiment, as shown in FIG. 23, the time (10*n) ms is the timing to start communication of data from the fifth vehicle control application 19. The time (10*n)+5 ms is the time to end communication of data generated when the fourth vehicle control application 115 is started at the time (10*n)-15 ms. Therefore, when the condition "counter & 2 == 0" is satisfied in the function Com_Manage_App2(), first, the shared memory ID "1" is accessed to read data, and the read data is transmitted to the vehicle control device 500B via the communication bus 118. This is processing to start data communication from the fifth vehicle control application 19 to the second vehicle control application 113.

[0099] Then, the fourth vehicle control application 115 reads the data that started to be transmitted 5 ms earlier and arrived in the vehicle control device 500B, and stores it in the variable tmp_data_from_app_4. If the condition "else" is satisfied in the function Com_Manage_App2(), the data stored in the variable tmp_data_from_app_4 is written to the shared memory ID "2", thereby ending communication from the fourth vehicle control application 115 to the sixth vehicle control application 20.

[0100] According to the above-described third embodiment, the following advantageous effects can be obtained. (5) The vehicle control device 500B includes a first communication driver 116 that communicates with the second vehicle control device 200 via a communication bus 118. The second vehicle control device 200 includes a second communication management application 123 that manages communication between applications, a sixth OS 18, and a second application group that is a plurality of applications. The sixth OS 18 executes the second management application and the second application group. The sixth OS 18 includes a first shared memory 120 that stores communication data output by any application in the second application group. The hypervisor 100B includes a second shared memory 121, also called a receiving-side shared memory, that stores device-to-device communication data input from the second vehicle control device 200 to any virtual machine in the virtual machine group. An inter-device communication start time and an inter-device communication end time are determined for each piece of device-to-device communication data. Any application in the second application group that is the source of the device-to-device communication data stores the device-to-device communication data in the sending-side shared memory at a time before the device-to-device communication start time of the device-to-device communication data. The second communication management application 123 reads out inter-device communication data from the first shared memory 120 in the second vehicle control device 200 at the inter-device communication start time, and transmits the inter-device communication data to the first virtual machine 101 via the communication bus 118 before the inter-device communication end time. The first virtual machine 101 stores the inter-device communication data in the second shared memory 121 of the vehicle control device 500B at the inter-device communication end time. The virtual machine that is the recipient of the inter-device communication data reads out the inter-device communication data from the second shared memory 121 at a time after the inter-device communication end time. Therefore, even when the vehicle control device 500B communicates with the outside of the vehicle control device 500B, the timing of the start and end of communication can be fixed, making verification easier.

[0101] This embodiment can also be said to include the following communication system. This communication system includes a first vehicle control device and a second vehicle control device connected by a communication bus, in which the first vehicle control device includes a first management virtual machine that manages communication between applications, and a first hypervisor that can realize a virtual machine group that is a plurality of virtual machines each including an application, the second vehicle control device includes a second management app that manages communication between applications, an operating system, and a second application group that is a plurality of applications, the operating system executes the second management app and the second application group, the first hypervisor includes a receiver-side shared memory that stores communication data input to any one of the virtual machines in the virtual machine group, and the operating system executes any one of the applications in the second application group. a sending-side shared memory that stores the communication data output by a first management application and a second management application, wherein an inter-device communication start time and an inter-device communication end time are defined for each of the communication data, and any one of the applications of the second application group that is a source of the communication data stores the communication data in the sending-side shared memory at a time prior to the inter-device communication start time of the communication data, the second management application reads the communication data from the sending-side shared memory at the inter-device communication start time and transmits the communication data to the first management virtual machine via the communication bus prior to the inter-device communication end time, the first management virtual machine stores the communication data in the sending-side shared memory at the inter-device communication end time, and a virtual machine that is a recipient of the communication data reads the communication data from the receiving-side shared memory at a time after the inter-device communication end time.

[0102] (Modification of the third embodiment) In the above-described third embodiment, the second vehicle control device 200 does not include a virtual machine. However, the second vehicle control device 200 may include a virtual machine.

[0103] --Fourth embodiment-- A fourth embodiment of a vehicle control device and a vehicle control method will be described with reference to Fig. 28. In the following description, the same components as those in the first embodiment are given the same reference numerals, and differences will be mainly described. Points that are not particularly described are the same as those in the first embodiment. This embodiment differs from the first embodiment mainly in that each vehicle control application writes a timestamp to the first shared memory 120.

[0104] Fig. 28 is a diagram showing a hardware configuration of a vehicle control device 500C in this embodiment. In Fig. 28, a log storage unit 124 is added as compared to the first embodiment. The log storage unit 124 is a non-volatile memory.

[0105] In the present embodiment, the first vehicle control application 112, the third vehicle control application 114, and the fourth vehicle control application 115 write time stamp information in addition to the data to be transmitted when writing data to the first shared memory 120. The time stamp information is the time or the number of times the data is written. In the present embodiment, the communication management application 111 checks the time stamp information when reading data from the first shared memory 120. If the time stamp information has not been updated since the last time the data was read, the communication management application 111 performs the following process. That is, the communication management application 111 determines that a delay has occurred in the vehicle control application that generates the data and has not updated the time stamp information, and records information about the vehicle control application in the log storage unit 124.

[0106] According to the above-described fourth embodiment, the following advantageous effects can be obtained. (6) The vehicle control device 500C includes a log storage unit 124 that stores logs. A virtual machine included in the virtual machine group stores, in the first shared memory 120, identification data capable of identifying the timing at which the communication data was generated together with the communication data. The management virtual machine checks the identification data when retrieving the communication data from the first shared memory 120 at the communication start time, and records the identification data in the log storage unit 124 if the identification data has not been updated since the previous communication end time. This makes it possible to detect and record the occurrence of a deadline miss in the vehicle control app.

[0107] --Fifth embodiment-- A fifth embodiment of a vehicle control device and a vehicle control method will be described with reference to Fig. 29. In the following description, the same components as those in the first embodiment are given the same reference numerals, and differences will be mainly described. Points that are not particularly described are the same as those in the first embodiment. This embodiment differs from the fourth embodiment mainly in that a log is transmitted to a server.

[0108] 29 is a diagram showing a software configuration of the vehicle control device 500 in this embodiment. The first virtual machine 101 includes the first OS 106, the communication management application 111, and the log transmission application 125. The log transmission application 125 has a function of transmitting log information stored in the log storage unit 124 to a server outside the vehicle. The log transmission application 125 is preemptive, that is, even if the first OS 106 interrupts the process midway, the first OS 106 can resume the process from the interrupted point by starting the log transmission application 125 again. The first OS 106 starts the log transmission application 125 with a lower priority than the communication management application 111.

[0109] According to the above-mentioned fifth embodiment, the following advantageous effects can be obtained. (7) The vehicle control device 500D includes a log transmission application 125 that transmits the identification data stored in the log storage unit 124 to an external server. Therefore, by transmitting deadline miss occurrence information to the server, the cause of the deadline miss can be analyzed and the vehicle control application can be improved.

[0110] (8) The management virtual machine further executes a process that has a lower priority than both the process of reading communication data from the first shared memory 120 at the communication start time and the process of storing communication data in the second shared memory 121 at the communication end time, and that can be interrupted and resumed. Therefore, by installing the log transmission application 125 in the first virtual machine 101, it is not necessary to newly install a CPU for log transmission, and the log transmission process does not inhibit the access of the communication management application 111 to the first shared memory 120 and the second shared memory 121, and the timing of starting and ending communication can be fixed.

[0111] In each of the above-mentioned embodiments and modifications, the configuration of the functional blocks is merely an example. Some functional configurations shown as separate functional blocks may be integrated, or a configuration shown in one functional block diagram may be divided into two or more functions. In addition, some of the functions of each functional block may be provided by other functional blocks.

[0112] In the above-described embodiments and modifications, the programs are stored in a ROM (not shown), but the programs may be stored in a non-volatile storage device. The vehicle control device 500 may include an input / output interface (not shown), and the programs may be read from another device via the input / output interface and a medium available to the vehicle control device 500 when necessary. The medium here refers to, for example, a storage medium that is detachable from the input / output interface, or a communication medium, that is, a network such as a wired, wireless, or optical network, or a carrier wave or digital signal that propagates through the network. Some or all of the functions realized by the programs may be realized by a hardware circuit or an FPGA.

[0113] The above-mentioned embodiments and modifications may be combined with each other. Although various embodiments and modifications have been described above, the present invention is not limited to these. Other aspects that are conceivable within the scope of the technical idea of ​​the present invention are also included in the scope of the present invention. [Explanation of symbols]

[0114] 100, 100A: Hypervisor 101: First virtual machine 102: Second virtual machine 111: Communication management app 116: First communication driver 117: Second communication driver 118: Communication bus 120: First shared memory 121: Second shared memory 123: Second communication management app 124: Log storage section 125: Log sending app 200: Second vehicle control device 500, 500A, 500B, 500C, 500D: Vehicle control device

Claims

1. A vehicle control device equipped with a hypervisor capable of implementing multiple virtual machines, the plurality of virtual machines include a management virtual machine that manages communications between the virtual machines, and a group of virtual machines that are virtual machines whose communications are managed by the management virtual machine; the hypervisor comprises a first shared memory that stores communication data output from any one of the virtual machines of the virtual machine group, and a second shared memory that stores the communication data input to any one of the virtual machines of the virtual machine group; A communication start time and a communication end time are set for each of the communication data, the virtual machine that is a transmission source of the communication data stores the communication data in the first shared memory at a time prior to the communication start time of the communication data; the management virtual machine reads the communication data from the first shared memory at the communication start time and stores the communication data in the second shared memory at the communication end time; The vehicle control device, wherein the virtual machine that is the recipient of the communication data reads out the communication data from the second shared memory at a time that is after the communication end time.

2. The vehicle control device according to claim 1, the first shared memory and the second shared memory are provided for each of the communication data, the first shared memory is writable by any one of the virtual machines in the virtual machine group that transmits the communication data, and is readable by the management virtual machine; A vehicle control device, wherein the second shared memory is writable by the management virtual machine and readable by any one of the virtual machines in the virtual machine group that receives the communication data.

3. The vehicle control device according to claim 2, It has multiple CPU cores, When the hypervisor assigns execution of a plurality of virtual machines to the same CPU core, the hypervisor executes the assigned virtual machines in a pre-fixed order, thereby performing time sharing among the virtual machines; A first CPU core is assigned to the management virtual machine, The vehicle control device, wherein one or more CPU cores different from the first CPU core are assigned to the virtual machine group.

4. The vehicle control device according to claim 2, the hypervisor is capable of assigning startup priorities to the plurality of virtual machines, and when a startup request is received simultaneously from one or more virtual machines, the hypervisor executes the virtual machines in order starting from the virtual machine with the highest startup priority, and when a startup request is received from the virtual machine with the highest startup priority while the virtual machine with the lowest startup priority is being started, the hypervisor interrupts the startup of the virtual machine with the lowest priority being started and starts the virtual machine with the highest startup priority; The vehicle control device sets the startup priority of the management virtual machine higher than any of the virtual machines.

5. The vehicle control device according to claim 3, A log storage unit for storing the log is further provided, a virtual machine included in the virtual machine group stores, in the first shared memory, the communication data together with identification data capable of identifying a timing at which the communication data was generated; A vehicle control device, wherein the management virtual machine checks the identification data when retrieving the communication data from the first shared memory at the communication start time, and records the identification data in the log storage unit if the identification data has not been updated since the previous communication end time.

6. The vehicle control device according to claim 5, The vehicle control device further includes a data transmission unit that transmits the identification data stored in the log storage unit to an external server.

7. The vehicle control device according to claim 4, A log storage unit for storing the log is further provided, a virtual machine included in the virtual machine group stores, in the first shared memory, the communication data together with identification data capable of identifying a timing at which the communication data was generated; A vehicle control device, wherein the management virtual machine checks the identification data when retrieving the communication data from the first shared memory at the communication start time, and records the identification data in the log storage unit if the identification data has not been updated since the previous communication end time.

8. The vehicle control device according to claim 7, The vehicle control device further includes a data transmission unit that transmits the identification data stored in the log storage unit to an external server.

9. The vehicle control device according to claim 3, A vehicle control device, wherein the management virtual machine further executes a process that has a lower priority than both the process of reading the communication data from the first shared memory at the communication start time and the process of storing the communication data in the second shared memory at the communication end time, and that can be interrupted and resumed.

10. The in-vehicle device according to claim 1, Further comprising a communication driver that communicates with a second vehicle control device, which is another device, via a communication bus; the second vehicle control device includes a second management application that manages communication between applications, an operating system, and a second application group that is a plurality of applications; the operating system executes the second management app and the second application group; the operating system includes a transmission-side shared memory that stores the communication data output by any one of the second application groups; the hypervisor further includes a receiver-side shared memory for storing inter-device communication data input from the second vehicle control device to any one of the virtual machines in the virtual machine group; An inter-device communication start time and an inter-device communication end time are defined for each of the inter-device communication data, Any one of the applications of the second application group that is a transmission source of the device-to-device communication data stores the device-to-device communication data in the transmission-side shared memory at a time prior to the device-to-device communication start time of the device-to-device communication data; the second management application reads the inter-device communication data from the transmission-side shared memory at the inter-device communication start time, and transmits the inter-device communication data to the management virtual machine via the communication bus before the inter-device communication end time; The management virtual machine stores the inter-device communication data in the receiving-side shared memory at the inter-device communication end time; The vehicle control device, wherein a virtual machine that is a recipient of the inter-device communication data reads the inter-device communication data from the receiving-side shared memory at a time that is later than the inter-device communication end time.

11. Equipped with a hypervisor that can realize multiple virtual machines, the plurality of virtual machines include a management virtual machine that manages communications between the virtual machines, and a group of virtual machines that are virtual machines whose communications are managed by the management virtual machine; A vehicle control method executed by a vehicle control device including: a first shared memory that stores communication data output from any one of the virtual machines of the virtual machine group; and a second shared memory that stores the communication data input to any one of the virtual machines of the virtual machine group, A communication start time and a communication end time are set for each of the communication data, a virtual machine that is a transmission source of the communication data stores the communication data in the first shared memory at a time prior to the communication start time of the communication data; the management virtual machine reading the communication data from the first shared memory at the communication start time and storing the communication data in the second shared memory at the communication end time; The vehicle control method includes a virtual machine that is a recipient of the communication data reading the communication data from the second shared memory at a time after the communication end time.

Images