Vehicle control device and vehicle control method

Abstract

This vehicle control device comprises a hypervisor capable of implementing a plurality of virtual machines. The plurality of virtual machines include: a management virtual machine for managing communication between virtual machines; and a virtual machine group comprising virtual machines in which communication is managed by the management virtual machine. The hypervisor comprises: a first shared memory for storing communication data that is outputted from any virtual machine in the virtual machine group; and a second shared memory for storing communication data that is inputted to any virtual machine in the virtual machine group. For each communication data, a communication starting time and a communication ending time are determined, and the virtual machine that is the transmission source of the communication data stores the communication data in the first shared memory at a time before the communication starting time of the communication data. The management virtual machine reads out the communication data from the first shared memory at the communication starting time, and stores the communication data in the second shared memory at the communication ending time. The virtual machine that is the reception destination of the communication data reads out the communication data from the second shared memory at a time after the communication ending time.

Description

Vehicle control device and vehicle control method

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

[0002] As vehicle control, as exemplified by autonomous driving, becomes more sophisticated and complex, the integration of vehicle control devices and continuous improvement of the vehicle control software installed in those devices are required. Accordingly, the automotive industry is transitioning from the traditional distributed architecture, in which a separate vehicle control device is installed for each sensor and actuator, to a central zone architecture, in which several high-performance vehicle control devices are installed and consolidated. In this transition, vehicle control software that was previously installed in different vehicle control devices is now installed in the same vehicle control device, so ensuring non-interference between the vehicle control software is important. Therefore, the introduction of a hypervisor, a virtualization technology, into vehicle control devices that separates the hardware resources used by each vehicle control software and enables safe sharing of hardware resources that must be shared by multiple vehicle control software using techniques such as mutual exclusion and time sharing, has attracted attention.

[0003] Patent Document 1 discloses a virtualization system in which multiple virtual computers run on a single physical computer having multiple cores, the system comprising: multiple pieces of hardware; a hardware control core that is the core for controlling the operation of each of the multiple pieces of hardware; multiple virtual computer cores that are the cores on which a guest OS that is an OS for the virtual computers runs; and a shared memory that is memory that can be accessed simultaneously and in parallel by the hardware control core and each of the multiple virtual computer cores, wherein one virtual computer is configured to operate exclusively with one or more of the virtual computer cores; the hardware control core has a device driver unit that controls the operation of each of the multiple pieces of hardware by executing a device driver corresponding to each of the multiple pieces of hardware; communication between the hardware control core and the virtual computer cores is achieved by saving data to the shared memory and reading 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.

[0004] Japanese Patent Application Publication No. 2019-057162

[0005] In the invention described in Patent Document 1, there is room for consideration in reducing the development costs of a vehicle control device that uses a hypervisor and has multiple pieces of vehicle control software installed.

[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, wherein the multiple virtual machines include 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, and the hypervisor is equipped with a first shared memory that stores communication data output from any of the virtual machines in the group of virtual machines, and a second shared memory that stores the communication data input to any of the virtual machines in the group of virtual machines, wherein a communication start time and a communication end time are defined for each of the communication data, and 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, and 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 that includes 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 including a first shared memory that stores communication data output from any one of the virtual machines in the group of virtual machines, and a second shared memory that stores the communication data input to any one of the virtual machines in the group of virtual machines, wherein a communication start time and a communication end time are defined for each piece of communication data, the virtual machine that is the 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 the virtual machine that is the recipient of the communication data reads the communication data from the second shared memory at a time after the communication end time.

[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.

[0008] 1. A hardware configuration diagram of a vehicle control device in a first embodiment. 2. A software configuration diagram of a vehicle control device in a first embodiment. 3. A diagram showing reception of time notifications from each timer in a first CPU. 4. A diagram showing whether or not reception of time notifications from each timer in each CPU in a first embodiment is present. 5. A diagram showing an example of time window division by a hypervisor. 6. A diagram showing time window allocation information in the case of FIG. 5. 7. A diagram showing an example of waiting for time window allocation. 8. A diagram showing a data flow from a first vehicle control application to a second vehicle control application installed in a different device. 9. A diagram showing a data flow from a first vehicle control application to a second vehicle control application installed in the same device. 10. A diagram showing an example of fixed timing. 11. A diagram showing data transmission from a first vehicle control application to a second vehicle control application. 12. A diagram showing shared memory setting information. 13. A pseudo-simulation diagram showing the processing contents of a communication management application corresponding to FIG. 10. 1. A diagram showing the code reading margin time; 2. A diagram showing the write margin time; 3. A diagram showing the effect of fixing the communication timing; 4. A hardware configuration diagram of a vehicle control device in a second embodiment; 5. A software configuration diagram of a vehicle control device in a second embodiment; 6. A diagram showing whether or not time notifications are accepted from each timer in each CPU in the second embodiment; 7. A vehicle configuration diagram in a third embodiment; 8. A software configuration diagram of a vehicle control device in a third embodiment; 9. A software configuration diagram of a second vehicle control device; 10. A diagram showing an example of fixing the timing in the third embodiment; 11. A diagram showing shared memory setting information of a vehicle control device; 12. Pseudo code showing the processing contents of a communication management application; 13. A diagram showing shared memory setting information of a second vehicle control device; 14. Pseudo code showing the processing contents of a second communication management application; 15. A hardware configuration diagram of a vehicle control device in a fourth embodiment; 16. A software configuration diagram of a vehicle control device in a fifth embodiment

[0009] First Embodiment A first embodiment of a vehicle control device and a vehicle control method will be described below with reference to FIGS.

[0010] <Vehicle Control Device 500> FIG. 1 is a hardware configuration diagram of the 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 (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, a single 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 CPU 1, the second virtual machine 102 is executed by a second CPU 2, the third virtual machine 103 is executed by a third CPU 3 and a fourth CPU 4, and the fourth virtual machine 104 and the fifth virtual machine 105 are executed by a fifth CPU 5. Hereinafter, the first virtual machine 101 will also be referred to as a "management virtual machine." The second virtual machine 102 to the fifth virtual machine 105 will also be referred to as a "virtual machine group."

[0012] The first virtual machine 101 includes a first operating system (OS) 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 kind of calculation related to the control of the vehicle equipped with the vehicle control device 500 and transmit the calculation results to other control applications. Hereinafter, data exchanged between vehicle control applications will be referred to as "communication data." As will be 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] <Timers> Each of the first timer 7 to the sixth timer 12 has the role of notifying the CPU of the time. The CPU to which each timer notifies the time is set in advance. 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 CPU 1. Each CPU has a notification reception unit that receives time notifications from each timer. As shown in FIG. 2, the first CPU 1 runs a hypervisor 100 and a first virtual machine 101, and the first virtual machine 101 includes a first OS 106. Therefore, the first CPU 1 needs to receive time notifications from the first timer 7 for the hypervisor 100 and from the second timer 8 for the first OS 106. The first CPU 1 does not receive time notifications from timers other than the first timer 7 and the second timer 8. Therefore, as shown in FIG. 3, time notifications from timers other than the first timer 7 and the second timer 8 are disabled in the first CPU 1.

[0015] 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, which 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, and needs to accept a time notification from the third timer 9 for the second OS 107, but does not accept time notifications from other timers.

[0016] The third CPU 3 and the fourth CPU 4 run a hypervisor 100 and a third virtual machine 103, and the third virtual machine 103 includes a third OS 108. Therefore, the third CPU 3 and the fourth CPU 4 need to receive time notifications from the first timer 7 for the hypervisor 100 and 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 a hypervisor 100, a fourth virtual machine 104, and a 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 configures a virtual machine and provides an environment that is logically equivalent to a situation in which software within the virtual machine resides in another vehicle control device within the same vehicle control device 500 but outside the virtual machine. This equivalent environment is provided by spatial and temporal separation. Spatial separation refers to separating the use of hardware, such as memory area division. Temporal separation refers to separating the timing when hardware is shared so that multiple virtual machines do not use the shared hardware simultaneously.

[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 that are shared among multiple virtual machines, a time interval called a time window is set to prevent multiple virtual machines from simultaneously accessing the hardware resources and causing undefined behavior, and only one pre-specified virtual machine is allowed to use the hardware resources during each time window.

[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 Figure 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 hypervisor 100 performs processing after the memory protection unit detects a memory access violation, and stops the virtual machine that caused the memory access violation. If 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 applications in the solo execution virtual machine behave the same as when they are 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 solo execution virtual machines. The first OS 106 is always executed by the first CPU 1, the second OS 107 is always executed by the second CPU 2, and the third OS 108 is always executed by the third CPU 3 and the fourth CPU 4.

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

[0024] Meanwhile, the fourth virtual machine 104 and the fifth virtual machine 105 are both executed 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 executing 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 is executed. The 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 way, the hypervisor 100 periodically allocates time windows to each virtual machine for the fifth CPU 5. This allocation method is determined in advance before the virtual machines are started, and is described 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 about the virtual machine executed by the fifth CPU 5 in the time window. Note that, in this embodiment, the time width of all 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 allocates a time window with time window number 1 included in the time window allocation information 1000 at time 0. 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 again with the time window number set to "1". 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 Fluctuation Due to Waiting for Time Window Allocation> Figure 7 is a diagram showing an example of waiting for time window allocation. In this embodiment, waiting for a time window may occur in the fourth virtual machine 104 and the fifth virtual machine 105, which share 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 that are to be processed at 5 ms intervals. The fourth OS 109 installed in the fourth virtual machine 104 sets a fifth timer 11 when it is first started by the hypervisor 100. Thereafter, the fifth timer 11 notifies the fifth CPU 5 of the time every 5 ms, starting from the timing at which the fifth timer 11 was 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 installed in the fifth virtual machine 105 sets the sixth timer 12 when started 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 at which 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 FIGS. 5 and 6 , the hypervisor 100 allocates the first 1 ms to the fourth virtual machine 104 and the next 1 ms to the fifth virtual machine 105. In FIG. 7 , the time periods in which each virtual machine is not executed are indicated by hatching with dots. Specifically, the time periods in which the fourth virtual machine 104 is not executed include time periods between 1 ms and 2 ms, between 3 ms and 4 ms, and between 5 ms and 6 ms. The time periods in which the fifth virtual machine 105 is not executed are opposite to the time periods in which the fourth virtual machine 104 is not executed, such as time periods between 0 ms and 1 ms and between 2 ms and 3 ms.

[0032] The fifth timer 11 starts counting the time from 0 ms, when the fourth OS 109 is first activated. The sixth timer 12 starts counting the time from 1 ms, 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 have elapsed. However, the time window allocated to the fifth virtual machine 105 is from 5 ms to 6 ms. Therefore, the third vehicle control application 114 is launched after the hypervisor 100 switches the time window to the fourth virtual machine 104 at 6 ms. Specifically, this is the point in 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 has been switched.

[0033] Therefore, the processing of the third vehicle control application 114 starts at 6 ms. In this way, the processing timing of an application may fluctuate due to waiting for a time window to be allocated. The next time the fifth timer 11 notifies the time is 10 ms. Because a time window is allocated to the fourth virtual machine 104 from 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 same operation applies to the fifth virtual machine 105. As described above, when the hypervisor 100 shares a CPU among multiple virtual machines, the processing timing of an application may fluctuate due to waiting for a time window to be allocated.

[0034] <Latency Fluctuation Before and After Integration> The hypervisor 100 is used to install vehicle control software that was previously installed in different vehicle control devices into the same vehicle control device.

[0035] 8 is a diagram showing a data flow from a first vehicle control application 112 to a second vehicle control application 113 mounted on different devices, as in a 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, for example.

[0036] The first vehicle control application 112 and the second vehicle control application 113 are both executed every 10 ms. The second vehicle control application 113 performs processing using the processing result of the first vehicle control application 112, and therefore 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 the packet to the communication bus 118.

[0037] The pre-integration second vehicle control device 14 includes a second communication driver 117. Note that 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, extracts the data stored in the receiving port, and processes it. 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 results is approximately 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 when the first vehicle control application 112 and the second vehicle control application 113 are installed in the same vehicle control device 500, as in the present embodiment. However, the timing of data exchange in this diagram differs from that in the present embodiment. When the first vehicle control application 112 and the second vehicle control application 113 are integrated using the hypervisor 100 and installed in the same vehicle control device 500, a shared memory 119 is used for data exchange. This shared memory 119 can be accessed by applications and OSs in the second virtual machine 102 and the third virtual machine 103. In this case, unlike the example shown in FIG. 8 , data transfer via the communication bus 118 does not occur. Therefore, 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 launched every 10 ms, the time (latency) from when the processing of the first vehicle control application 112 starts until 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, as shown in the lower part of FIG. 9 . This is approximately 10 ms shorter than 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 previously installed in different vehicle control devices is installed in the same vehicle control device without any special ingenuity. Due to the shortened latency, the processing result of the first vehicle control application 112 referenced by the second vehicle control application 113 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 Figure 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. Furthermore, as shown in Figures 8 and 9, fluctuations in latency occur when communication between vehicle control devices is replaced by memory sharing, which is communication within the vehicle control device. It requires a lot of cost to verify that these fluctuations do not affect vehicle driving.

[0041] Therefore, in this embodiment, the timing at which communication between virtual machines starts (hereinafter referred to as "communication start timing" or "communication start time") and the timing at which communication ends (hereinafter referred to as "communication end timing" or "communication end time") are fixed in advance. By fixing the timing at which communication between virtual machines starts and ends 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 scope from the entire vehicle control device 500 to each virtual machine.

[0042] FIG. 10 is a diagram showing an example in which timing is fixed. In this diagram, the same hatching indicates a data exchange relationship. Referring 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 starting 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 launched. 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, i.e., the communication end timing, is set to the time after the communication start timing when the second vehicle control application 113 is next launched. For example, if communication starts at 10 ms, it ends at 20 ms, and if communication starts at 20 ms, it ends at 30 ms. As a result, the latency from the start of processing by the first vehicle control application 112 to the end of processing by the second vehicle control application 113 is just under 30 ms, which is the same as in FIG. 8 and does not cause latency fluctuations.

[0044] By setting the communication start and end times 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 to just under 30 ms, as in Fig. 8. As described above, the timing at which communication of the processing result of the first vehicle control application 112 starts is set to the time when the first vehicle control application 112 is next launched, with the primary objective being to make the latency approximately the same as in Fig. 8. Furthermore, 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 in which 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 5 ms intervals starting from 0 ms. Communication of the processing results of the third vehicle control application 114 and the fourth vehicle control application 115 is initiated when each of them is next executed. The communication end timing is the time when the second vehicle control application 113 is next launched, after the communication start timing. However, while the second vehicle control application 113 is executed at a 10 ms interval, the third vehicle control application 114 and the fourth vehicle control application 115 are executed at a 5 ms interval, which is twice as frequent.

[0046] Therefore, for example, the processing results of the third vehicle control application 114 and the fourth vehicle control application 115 used by the second vehicle control application 113 that starts processing at 20 ms have 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 that started processing at 10 ms; and The second candidate is the processing result of the third vehicle control application 114 and the fourth vehicle control application 115 that started processing at 15 ms.

[0047] The decision as to which processing result should be adopted is based on whether it is closer to the data flow before integration. This decision, i.e., the timing of starting and ending communication, may be made by a human designer, or may be partially or completely automated. 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 10 ms, are used by the second vehicle control application 113, which starts processing at 20 ms.

[0048] In this case, the processing results of the third vehicle control application 114 and the fourth vehicle control application 115 at 5 ms or 15 ms may be transmitted, or execution of the application itself may be omitted. When transmitting these processing results, the values ​​written to the shared memory as the transmission results are not read by the second vehicle control application 113 because new values ​​are written to 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 processing before the start of the communication start timing, i.e., within 5 ms after being launched, regardless of whether or not the hypervisor 100 waits for a time window to be allocated.

[0049] A method for fixing the timing of starting and ending communication between virtual machines as shown in Figure 10 will be described below. When communication is performed directly between virtual machines, as shown in Figures 7 to 9, latency fluctuations due to waiting for time window allocation and changes in the communication path are unavoidable. Therefore, the first virtual machine 101 occupies the first CPU 1, and the first virtual machine 101 is equipped with a communication management application 111 instead of a vehicle control application, and all communication between the virtual machines, i.e., memory sharing, is routed through the first virtual machine 101.

[0050] FIG. 11 illustrates data transmission from the first vehicle control application 112 to the second vehicle control application 113. Specifically, FIG. 11 illustrates 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 memory shared between the data sender and the communication management application 111, and the second shared memory 121 is memory shared between the communication management application 111 and the data receiver. The first shared memory 120 can also be called a "sending shared memory" because it is used by the sender application to send data. The second shared memory 121 can also be called a "receiving shared memory" because it is used by the receiver application to receive data.

[0051] 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 set for data sent by the third vehicle control application 114 of the fourth virtual machine 104 to the second vehicle control application 113, and for data sent by 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 the address of memory shared among multiple virtual machines, the read / write permissions of each virtual machine, and the identifier of each shared memory. The hypervisor 100 sets the shared memory in accordance with the shared memory setting information 1001. The shared memory ID "1" is the 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 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.

[0053] The shared memory ID "3" is the first shared memory 120 shared between the third vehicle control application 114 of the fourth virtual machine 104 and the communication management application 111. The shared memory ID "4" 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 "5" is the first shared memory 120 shared between the first vehicle control application 112 of the fifth virtual machine 105 and the communication management application 111. The shared memory ID "6" 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.

[0054] FIG. 13 is pseudocode showing the processing content of the communication management application 111 corresponding to FIG. 10. The processing content of the communication management application 111 at each time corresponding to the description in FIG. 10 is as follows. In the following description, "n" represents 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 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 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 fourth vehicle control application 115 ends transmitting data generated by the fourth vehicle control application 115 to the second vehicle control application 113. The time (10*n)+5 ms is the time when the third vehicle control application 114 starts transmitting 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 transmitting data generated immediately before (i.e., when launched at time (10*n) ms).

[0056] To achieve the processing at each time point described above, the communication management application 111 is started at a 5 ms cycle, and the processing content changes each time the application is started. In FIG. 13 , this is implemented using an integer variable, counter. First, as an initialization process, counter is initialized to "0." Furthermore, variables are 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 the function Com_Manage_App(). To start at a 5 ms cycle, 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 invoked once every 5 ms by the first OS 106. The processing content of the function Com_Manage_App() changes depending on the number of times it is invoked. When the function Com_Manage_App() is first invoked, the variable counter has an initial value of "0," so the remainder when divided by "2" is zero, and the condition "counter & 2 == 0" is satisfied. The function first accesses the shared memory IDs "2, 4, 6" and writes data. The function Write takes the shared memory ID to be written as its first argument and the data to be written as its second argument. This is processing to terminate 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 of the read target as its first argument and the address of the variable in which the read data should be stored as its second argument. This is processing to start 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 processing to start 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 the 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 launched in memory at the same time as the communication end timing, an access contention occurs, which may cause the data to become undefined or corrupted. Therefore, an application that reads data from the second shared memory 121 does not access the second shared memory 121 immediately after launch, but rather after a certain period of time has elapsed. This elapsed time is called the "read margin time."

[0061] By waiting until the read margin time has elapsed after the application has started before accessing the second shared memory 121, it is guaranteed that the communication management application 111 has already written the data to the second shared memory 121. The read margin time need only be long enough for the communication management application 111 to write the data. Generally, 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 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's surrounding environment 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 timing of starting communication. However, there is a certain amount of time between when the communication management application 111 is started by the first OS 106 at the timing of starting communication and when it accesses the first shared memory 120 and reads the data. If a 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 that was started at time 0 ms. However, data generated in the first shared memory 120 by the first vehicle control application 112 that was started at time 10 ms prior to this is lost. Therefore, an application that writes data to the first shared memory 120 does not write the data to the first shared memory 120 immediately if processing is completed in a very short time, but writes the data after a certain period of time has elapsed. This elapsed period of 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, waits until the write margin time has elapsed before writing. Ensuring this write margin time ensures that the communication management application 111 has already 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. Generally, 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 predetermined by the shared memory setting information 1001, the processing time required for reading and writing is constant regardless of the vehicle's surrounding environment or driving conditions. In this embodiment, the write margin time is set to "3 ms." As shown in Figure 13, the communication management application 111 writes data to the second shared memory 121 and then reads data from the first shared memory 120. Therefore, in this embodiment, the write margin time is set 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 does not go via the communication management application 111, the 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 of the conventional case shown in Fig. 8. Furthermore, the timing of communication start is the timing when processing by the first vehicle control application 112 is completed, and since the processing time of the first vehicle control application 112 varies depending on the vehicle surrounding environment and driving conditions, the timing of communication start cannot be fixed.

[0067] 16, when communication goes through the communication management application 111, the timing of starting and ending communication does not change even if the timing of completing the processing of the first vehicle control application 112 changes. The communication start timing is the timing when 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 when the communication management application 111 writes data into the second shared memory 121. As described above, the timing of starting and ending communication can be fixed.

[0068] The first embodiment described above provides the following advantageous effects. (1) The vehicle control device 500 includes a hypervisor 100 capable of implementing multiple virtual machines, namely, a first virtual machine 101 to a fifth virtual machine 105. The first virtual machine 101 manages communication between the virtual machines. The first virtual machine 101 manages communication between the second virtual machine 102 to the fifth virtual machine 105, i.e., the virtual machine group. The hypervisor 100 includes a first shared memory 120 that stores communication data output from one of the virtual machines in the virtual machine group, and a second shared memory 121 that stores communication data input to 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 the sender 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. The virtual machine that is the 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 costs of the vehicle control device 500 equipped with multiple pieces of vehicle control software using the hypervisor 100 can be reduced. Specifically, by fixing the timing of the start and end of communication and confirming the following two points, it is possible to guarantee that the vehicle control device 500 will operate 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 elapse of a read margin time from the fixed communication end timing.

[0070] (2) The first shared memory 120 and the second shared memory 121 are provided for each type of communication data. The first shared memory 120 is writable by the virtual machine that sends 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 CPU 1 to a fifth CPU 5. 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 Figures 5 and 6, thereby performing time sharing among the virtual machines. The first CPU 1 is assigned to the first virtual machine 101, and the second CPU 2 to the fifth CPU 5 are assigned to the virtual machine group. Therefore, by adopting a time sharing method, multiple virtual machines can be operated by one CPU.

[0072] (Variation 1) In the first embodiment described above, the communication management application 111 and the vehicle control application each run on a virtual machine. However, a container may be used instead of a 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 Figures 17 to 19. In the following description, the same components as 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 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.

[0074] 17 is a diagram showing the 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 7.

[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 will be executed by the first CPU 1, the second CPU 2, or the third CPU 3.

[0076] 19 is a diagram showing whether each CPU accepts a time notification from each timer. The first CPU 1, the second CPU 2, and the third CPU 3 all accept a time notification from the first timer 7.

[0077] <Hypervisor> The role and operation of the hypervisor 100A will be described. The hypervisor 100A has higher operating 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 determines whether or not each vehicle control application or communication management application 111 needs to be started at the notified time, and if it determines that startup is necessary, sends a virtual machine startup request to the hypervisor 100A. Upon receiving the startup request, the hypervisor 100A provides, i.e., allows the virtual machine to use, one of the first CPU 1, second CPU 2, and third CPU 3 that is not currently being used by another virtual machine.

[0078] Each virtual machine processes the vehicle control application or communication management application 111 using the CPU provided by the hypervisor 100A, and when the processing is completed, 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 CPU 1, the second CPU 2, and the third CPU 3 are all being used by virtual machines and another virtual machine (hereinafter referred to as the "newly requesting virtual machine") requests the provision of a CPU, the hypervisor 100A arbitrates 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 the "using virtual machines"), the hypervisor 100A makes the new requesting virtual machine wait until one of the using virtual machines returns the CPU to the hypervisor 100A. Furthermore, if the new requesting virtual machine has a higher priority than a using virtual machine, the hypervisor 100A forcibly suspends the use of the CPU by the lower-priority virtual machine, 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 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 the fixed communication start and end timings, regardless of whether there is a CPU request from the other virtual machines.

[0081] The second embodiment described above provides the following advantageous effects. (4) The hypervisor 100A can assign startup priorities to multiple virtual machines. When the hypervisor 100A receives startup requests from one or more virtual machines simultaneously, it executes the virtual machines in order of startup priority. If the hypervisor 100A receives a startup request from a virtual machine with a higher startup priority while a virtual machine with a lower startup priority is running, it interrupts the startup of the virtual machine with the lower priority and starts the virtual machine with the higher 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 installed in the vehicle control device 500 is limited, communication timing can be fixed without occupying the CPU for the communication management application 111.

[0082] -Third embodiment- A third embodiment of a vehicle control device and a vehicle control method will be described with reference to Figures 20 to 27. In the following description, the same components as 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 in the first embodiment. This embodiment differs from the first embodiment mainly in that the vehicle control device exchanges data with the outside.

[0083] 20 is a configuration diagram of a vehicle 300 according to 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 the software configuration of a vehicle control device 500B according to the present embodiment. The difference from the first embodiment shown in FIG. 2 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 installed in the vehicle control device 500B, and the sixth vehicle control application 20 uses the processing result of the fourth vehicle control application 115 installed in the vehicle control device 500B.

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

[0088] The vehicle control device 500B and the second vehicle control device 200 have their times synchronized 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] 23 is a diagram showing an example in which timing is fixed in this embodiment. In the following description, "n" represents an integer. The processing result of the fifth vehicle control application 19 launched 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 launched 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 between vehicle control devices> In the present 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 sent 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 sends 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 second communication management application 123 accesses the shared memory between the second communication management application 123 and the fifth vehicle control application 19. 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 sent from the fourth vehicle control application 115 to the sixth vehicle control application 20, the communication management application 111 first acquires the data from the fourth vehicle control application 115. Then, the communication management application 111 sends 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 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 pseudocode showing the processing content 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 communication of data from the fifth vehicle control application 19. Furthermore, the time (10*n) + 5 ms is the time to start communication of data generated when the fourth vehicle control application 115 was launched immediately before, i.e., at the time (10*n) ms. Therefore, if 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 processing to end data communication from the fifth vehicle control application 19 to the second vehicle control application 113.

[0096] If 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 began transmission 5 ms ago and arrived at the second vehicle control device 200, and stores it in the variable tmp_data_from_app_5. This stored data will be 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 as an argument the data to be transmitted to the communication bus 118. The function ReadCanData takes as an argument the address of a variable that stores the data received from the communication bus 118.

[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 pseudocode showing the processing details 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 when data communication from the fifth vehicle control application 19 starts. The time (10*n) + 5 ms is the time when communication of data generated when the fourth vehicle control application 115 is started at the time (10*n) - 15 ms ends. Therefore, when the condition "counter & 2 == 0" is satisfied in the function Com_Manage_App2(), the shared memory ID "1" is first accessed to read data, and the read data is then 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] The fourth vehicle control application 115 then reads the data that began transmitting 5 ms earlier and arrived at the vehicle control device 500B, and stores the data 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] The third embodiment described above provides the following advantageous effects. (5) The vehicle control device 500B includes a first communication driver 116 that communicates with the second vehicle control device 200 via the 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 consisting of 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 referred to as a receiving-side shared memory, that stores inter-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 defined for each piece of inter-device communication data. Any application in the second application group that is the sender of the inter-device communication data stores the inter-device communication data in the sending-side shared memory at a time before the inter-device communication start time of the inter-device communication data. The second communication management application 123 reads 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 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 an external device, 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, wherein 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 virtual machine in the virtual machine group, and the operating system executes any application in the second application group. a sending-side shared memory that stores the communication data output by each application, wherein an inter-device communication start time and an inter-device communication end time are defined for each piece of communication data, wherein one of the applications in the second application group that is a sender of the communication data stores the communication data in the sending-side shared memory at a time before 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 before 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 third embodiment described above, 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 denoted by the same reference numerals, and differences will be mainly described. Points that are not specifically 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 the hardware configuration of a vehicle control device 500C in this embodiment. In Fig. 28, compared to the first embodiment, a log storage unit 124 is added. 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 timestamp information in addition to the data to be transmitted when writing data to the first shared memory 120. The timestamp information is the time or the number of times the data was written. In the present embodiment, the communication management application 111 checks the timestamp information when reading data from the first shared memory 120. If the timestamp 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 the timestamp information has not been updated and that a delay has occurred in the vehicle control application that generates the data, 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 a virtual machine group stores, in the first shared memory 120, identification data that can identify the timing at which the communication data was generated along with communication data. The management virtual machine checks the identification data when retrieving 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 denoted by the same reference numerals, and differences will be mainly described. Points that are not specifically described are the same as those in the first embodiment. This embodiment differs from the fourth embodiment mainly in that a log is sent to a server.

[0108] 29 is a diagram showing the software configuration of the vehicle control device 500 in this embodiment. The first virtual machine 101 includes a first OS 106, a communication management application 111, and a 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, meaning that even if the first OS 106 interrupts processing midway, the first OS 106 can resume processing from the interrupted point by restarting the log transmission application 125. The first OS 106 starts the log transmission application 125 with a lower priority than the communication management application 111.

[0109] According to the fifth embodiment described above, 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, it is possible to analyze the cause of the deadline miss and improve the vehicle control application.

[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 install a new CPU for log transmission, and the log transmission process can maintain fixed timing for starting and ending communication without interfering with access by the communication management application 111 to the first shared memory 120 and the second shared memory 121.

[0111] In the above-described embodiments and modifications, the functional block configurations are merely examples. Some functional configurations shown as separate functional blocks may be integrated, or a configuration shown in a single functional block diagram may be divided into two or more functions. Furthermore, 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. Furthermore, the vehicle control device 500 may be provided with an input / output interface (not shown), and the programs may be loaded from another device as needed via the input / output interface and a medium available to the vehicle control device 500. Here, the medium refers to, for example, a storage medium detachable from the input / output interface, or a communication medium, i.e., a wired, wireless, or optical network, or a carrier wave or digital signal propagating through the network. Furthermore, some or all of the functions realized by the programs may be realized by a hardware circuit or an FPGA.

[0113] The above-described 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 embodiments conceivable within the scope of the technical concept of the present invention are also included within the scope of the present invention.

[0114] DESCRIPTION OF SYMBOLS 100, 100A: Hypervisor 101: First virtual machine 102: Second virtual machine 111: Communication management application 116: First communication driver 117: Second communication driver 118: Communication bus 120: First shared memory 121: Second shared memory 123: Second communication management application 124: Log storage unit 125: Log transmission application 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 realizing multiple virtual machines, the multiple virtual machines including a management virtual machine that manages communications between the 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 group of virtual machines, and a second shared memory that stores the communication data input to any one of the group of virtual machines, 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.

2. A vehicle control device as described in claim 1, wherein 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, and the second shared memory is writable by the management virtual machine and is readable by any one of the virtual machines in the virtual machine group that receives the communication data.

3. A vehicle control device as described in claim 2, having multiple CPU cores, wherein when the hypervisor assigns the execution of multiple virtual machines to the same CPU core, it executes the assigned virtual machines in a pre-fixed order to perform time sharing among the virtual machines, a first CPU core is assigned to the management virtual machine, and one or more CPU cores different from the first CPU core are assigned to the group of virtual machines.

4. A vehicle control device as described in claim 2, wherein the hypervisor is capable of assigning startup priorities to the multiple virtual machines, and when startup requests are received from one or more virtual machines simultaneously, the hypervisor executes the virtual machines with the highest startup priority in order, and when a startup request is received from a virtual machine with the high startup priority while a virtual machine with a low startup priority is being started, the hypervisor interrupts the startup of the virtual machine with the low priority that is currently running and starts the virtual machine with the high startup priority, and sets the startup priority for the management virtual machine higher than that of any of the virtual machines.

5. A vehicle control device as described in claim 3, further comprising a log storage unit for storing logs, wherein a virtual machine included in the group of virtual machines stores in the first shared memory, together with the communication data, identification data capable of identifying the timing at which the communication data was generated, and 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. A vehicle control device according to claim 5, further comprising a data transmission unit that transmits the identification data stored in the log storage unit to an external server.

7. A vehicle control device as described in claim 4, further comprising a log storage unit for storing logs, wherein a virtual machine included in the group of virtual machines stores in the first shared memory, together with the communication data, identification data capable of identifying the timing at which the communication data was generated, and 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. A vehicle control device according to claim 7, further comprising a data transmission unit that transmits the identification data stored in the log storage unit to an external server.

9. A vehicle control device as described in claim 3, 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. An in-vehicle device according to claim 1, further comprising a communication driver for communicating with a second vehicle control device which is another device via a communication bus, the second vehicle control device comprising a second management app for managing communication between applications, an operating system, and a second application group which is a plurality of applications, the operating system executes the second management app and the second application group, the operating system comprises a sending side shared memory for storing the communication data output by any application of the second application group, the hypervisor further comprises a receiving side shared memory for storing inter-device communication data input from the second vehicle control device to any virtual machine of 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, one of the applications of the second application group which is a source of the inter-device communication data stores the inter-device communication data in the sending side shared memory at a time prior to the inter-device communication start time of the inter-device communication data, the second management app reads the inter-device communication data from the sending 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 prior to the inter-device communication end time, A vehicle control device, wherein the management virtual machine stores the inter-device communication data in the receiving shared memory at the inter-device communication end time, and a virtual machine that is a recipient of the inter-device communication data reads the inter-device communication data from the receiving shared memory at a time after the inter-device communication end time.

11. A vehicle control method executed by a vehicle control device comprising: a hypervisor capable of realizing a plurality of virtual machines, the plurality of virtual machines including a management virtual machine that manages communications between the virtual machines, and a group of virtual machines which are virtual machines whose communications are managed by the management virtual machine, the hypervisor comprising a first shared memory that stores communication data output from any one of the group of virtual machines, and a second shared memory that stores the communication data input to any one of the group of virtual machines, the vehicle control method comprising: 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 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.

Images