Vehicle control device

Abstract

In order to provide a vehicle control device that makes is possible to obtain processing results as designed even if processing of a virtual machine is suspended by a hypervisor, the vehicle control device according to the present invention is provided with a hypervisor and a virtual machine started by the hypervisor, the virtual machine having an application and a scheduler for starting the application, and the hypervisor, the scheduler, and the application being computationally processed by one or more computation devices, wherein are provided an interruption time length monitoring unit for monitoring a processing interruption time length of suspension by the hypervisor of processing by an application in the virtual machine, and a storage unit for storing the processing suspension interruption time length monitored by the interruption time length monitoring unit, and the scheduler starts the application on the basis of a time corrected using the processing suspension interruption time length stored in the storage unit.

Description

Vehicle control device

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

[0002] Along with the advancement and complication of vehicle control represented by autonomous driving, integration of vehicle control devices and continuous improvement of vehicle control software installed in vehicle control devices are required. In accordance with this trend, the automotive industry is transitioning from the conventional 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 for integration.

[0003] In the transition to the central-zone architecture, vehicle control software that has conventionally been installed in different vehicle control devices is installed in a single vehicle control device, so it is important to establish non-interference between the respective pieces of vehicle control software. Accordingly, attention has been focused on introducing virtualization technology (hypervisor) to vehicle control devices, which separates hardware resources used by each piece of vehicle control software, and enables safe hardware sharing through methods such as exclusive control and time division for hardware resources that have to be shared and used by multiple pieces of vehicle control software.

[0004] As an example of a vehicle control device using a hypervisor, there is a technology described in Patent Document 1. The technology of Patent Document 1 is an electronic control device comprising: an arithmetic unit that executes programs; a memory accessible by the arithmetic unit; an access violation detection mechanism that monitors access from the arithmetic unit to the memory; and a time storage mechanism that stores the detection time when an access violation is detected by the access violation detection mechanism. Patent Document 1 describes that the arithmetic unit stores a switching time at the timing of switching the task to be executed, the time storage mechanism stores the time when the access violation is detected, and the arithmetic unit identifies the task that caused the access violation by comparing the switching time and the detection time. A hypervisor operates on the arithmetic unit, and the hypervisor generates an interrupt that notifies the arithmetic unit of the access violation in accordance with the detection result from the access violation detection mechanism.

[0005] Furthermore, Patent Document 2 describes an information processing system which includes a virtual machine and a hypervisor, and comprises an acquisition unit that acquires first log information including operational information representing the operating status and time information corresponding to the operational information from each of the virtual machine and the hypervisor, and a visualization unit that visualizes the first log information acquired by the acquisition unit based on a time input by the user.

[0006] International Publication No. 2023 / 119652, International Publication No. 2022 / 130942

[0007] However, with the technologies described above, the hypervisor may interrupt the processing of the virtual machine, which may prevent the processing results from being obtained as designed. Therefore, the present invention aims to provide a vehicle control device that can more effectively obtain the processing results as designed, even if the processing of the virtual machine is interrupted by the hypervisor.

[0008] To solve the above problems, one vehicle control device of the present invention comprises a hypervisor and a virtual machine started by the hypervisor, the virtual machine having an application and a scheduler that starts the application, and the hypervisor, scheduler and application are processed by one or more processing units, and comprises an interruption time length monitoring unit that monitors the length of time the processing of the virtual machine's application is interrupted by the hypervisor, and a storage unit that stores the length of time the processing interruption length monitored by the interruption time length monitoring unit, and the scheduler starts the application based on a time corrected using the length of time the processing interruption length stored in the storage unit.

[0009] According to the present invention, even if the processing of a virtual machine is interrupted by the hypervisor, the processing results are more likely to be as designed. Further features related to the present invention will become apparent from the description herein and the accompanying drawings. In addition, problems, configurations, and effects other than those described above will be revealed by the following description of embodiments.

[0010] A diagram showing the hardware configuration of the vehicle control device in Example 1. A diagram showing the software configuration of the vehicle control device in Example 1. A diagram showing the first scheduling table internally held by the first scheduler. A diagram showing the second scheduling table internally held by the second scheduler. A diagram showing the ideal timing chart of the overall processing of the vehicle control device in Example 1. A diagram showing an overview of the internal time delay of the first operating system caused by the switching between the virtual machine and the hypervisor in the first arithmetic processing unit. A diagram showing the disruption of data flow caused by the internal time delay. A diagram showing an overview of the hypervisor mechanism. A diagram showing the task activation method of the first scheduler in Example 1. A diagram showing the task activation method of the second scheduler in Example 1. A diagram showing the overall processing timing chart of the vehicle control device based on the task activation methods of the first and second schedulers in Example 1. A diagram showing the first scheduling table internally held by the first scheduler in Example 2. A diagram showing the second scheduling table internally held by the second scheduler in Example 2. A diagram showing the second scheduling table internally held by the second scheduler in Example 3. A diagram showing the overall processing timing chart of the vehicle control device based on the task activation method of the first and second schedulers in Example 3. A flowchart showing the operation of the vehicle control device in Example 4.

[0011] The following describes examples of preferred embodiments (embodiments) of the present invention. The following embodiments relate to a vehicle control device. For simplicity, the following embodiments describe a vehicle control device having three arithmetic processing units (CPUs) and two virtual machines, but the number of CPUs and virtual machines installed in the vehicle control device is not limited to this. Also, the number of tasks executed in each virtual machine is merely an example.

[0012] In the attached drawings, functionally identical elements are indicated by the same number. Furthermore, while the attached drawings illustrate embodiments in accordance with the principles of this disclosure, they are for the purpose of understanding this disclosure and are not intended to be used in any way to restrict its interpretation. The descriptions herein are merely typical examples and do not limit the claims or applications of this disclosure in any way.

[0013] [Example 1] <Configuration> Figure 1 shows the hardware configuration of the vehicle control device 1 in this example. Figure 2 shows the software configuration of the vehicle control device 1 in this example.

[0014] <Vehicle Control Device 1> The hardware configuration of the vehicle control device 1 according to this embodiment will be explained with reference to Figure 1. The vehicle control device 1 shown in Figure 1 is mounted on a vehicle 300 and controls the operation of the vehicle 300. As shown in Figure 1, the vehicle control device 1 includes a first arithmetic processing unit 2, a second arithmetic processing unit 3, a third arithmetic processing unit 4, a memory 5, and a communication peripheral 6. The first arithmetic processing unit 2, the second arithmetic processing unit 3, and the third arithmetic processing unit 4 are specifically CPUs (Central Processing Units).

[0015] Memory 5 may include ROM (Read Only Memory) and RAM (Random Access Memory). Communication peripheral 6 is peripheral circuitry for the vehicle control device 1 to communicate with the outside world, and is, for example, a CAN controller and CAN transceiver in the CAN (Controller Area Network) protocol, or a PHY (Physical layer) in the Ethernet protocol.

[0016] The vehicle control device 1 according to this embodiment has the software configuration shown in Figure 2. As shown in Figure 2, the vehicle control device 1 comprises a hypervisor 100, a first virtual machine 101 started by the hypervisor 100, and a second virtual machine 102 started by the hypervisor 100. The first virtual machine 101 and the second virtual machine 102 are configured on the hypervisor 100, with the first virtual machine 101 being executed by the first arithmetic processing unit 2 and the second virtual machine 102 being executed by the second arithmetic processing unit 3 and the third arithmetic processing unit 4, respectively.

[0017] The first virtual machine 101 has applications 141 and 142, and a first scheduler 104 that starts applications 141 and 142. The second virtual machine 102 has applications 143, 144 and 145, and a second scheduler 106 that starts applications 143, 144 and 145. The first virtual machine 101 has a first operating system 103. The second virtual machine 102 has a second operating system 105.

[0018] The hypervisor 100 is processed by the first arithmetic processing unit 2, the second arithmetic processing unit 3, and the third arithmetic processing unit 4. The first scheduler 104 is processed by the first arithmetic processing unit 2. The second scheduler 106 is processed by the second arithmetic processing unit 3 and the third arithmetic processing unit 4. Applications 141 and 142 are processed by the first arithmetic processing unit 2. Applications 143, 144, and 145 are processed by the second arithmetic processing unit 3 and the third arithmetic processing unit 4.

[0019] As described above, the first virtual machine 101 includes a first operating system (OS) 103, a first scheduler 104, and a first vehicle control task 111 configured for application 141. These will be described below.

[0020] <First Operating System 103> The first operating system 103 executes programs as processes. Programs are of the user level and kernel level. Kernel-level programs are programs provided as part of the first operating system 103. User-level programs are programs that are outside the first operating system 103 and are launched on the first operating system 103.

[0021] Kernel-level programs are executed as kernel processes on the first operating system 103. User-level programs are executed as user processes on the first operating system 103. Kernel processes are automatically created and started when the vehicle control device 1 is started. Kernel processes can start user processes. In particular, the first user process started by a kernel process is called the startup process.

[0022] By specifying an arbitrary user process as the startup process, that specified user process is automatically started immediately after the first operating system 103 has finished booting. The user process can call services (system services) provided by the kernel process while it is running. An example of a system service in the first operating system 103 is the provision of the time.

[0023] <First Scheduler 104, First Vehicle Control Task 111, First Communication Task 121> The first scheduler 104 is a user process in the first operating system 103 and is designated as the startup process of the first operating system 103. That is, the first scheduler 104 is started automatically after the first operating system 103 starts up. The first vehicle control task 111 configured for application 141 and the first communication task 121 configured for application 142 are child processes of the first scheduler 104. That is, the first vehicle control task 111 and the first communication task 121 are started by instructions from the first scheduler 104.

[0024] The first vehicle control task 111 is a task that performs processing for the vehicle control device 1 to control the vehicle 300, for example, by measuring the speed of the vehicle 300. The first communication task 121 is a task that performs communication between the first virtual machine 101 and the second virtual machine 102, and between the first virtual machine 101 and the outside of the vehicle control device 1. In this embodiment, the first communication task 121 transmits the speed of the vehicle 300 measured by the first vehicle control task 111 to the second virtual machine 102 and the outside of the vehicle control device 1.

[0025] Within the first virtual machine 101, there is a shared memory (not shown) shared between the first vehicle control task 111 and the first communication task 121. The first vehicle control task 111, which is started by the first scheduler 104, writes the measured vehicle speed to the shared memory at the end of its processing. The first communication task 121, which is started by the first scheduler 104, reads the value written to the shared memory at the beginning of its processing, and then transmits the read value to the second virtual machine 102 and the outside of the vehicle control device 1.

[0026] When the first communication task 121 transmits to the second virtual machine 102, the first communication task 121 uses the inter-virtual machine communication function provided by the hypervisor 100. When the first communication task 121 transmits to the outside of the vehicle control device 1, the first communication task 121 passes data regarding the speed of the vehicle 300 to be transmitted to the hypervisor 100 and requests the hypervisor 100 to access the communication peripheral 6 shown in Figure 1. After confirming that the communication peripheral 6 is not being used by the second virtual machine 102, the hypervisor 100 uses the communication peripheral 6 to transmit the data regarding the speed of the vehicle 300 to the outside of the vehicle control device 1.

[0027] <First Scheduling Table 201> Figure 3 shows the first scheduling table 201 held internally by the first scheduler 104. The first scheduling table 201 includes information on the child processes that the first scheduler 104 should start, and the period and offset for when each child process should be started. In this embodiment, the child processes that the first scheduler 104 should start are the first vehicle control task 111 and the first communication task 121. The offset represents the time when the child process should be first started.

[0028] In Figure 3, the period of the first vehicle control task 111 is described as 50 ms and the offset as 0 ms. Therefore, the first scheduler 104 starts the first vehicle control task 111 at times 50 ms, 100 ms, 150 ms, etc. Similarly, in Figure 3, the period of the first communication task 121 is described as 50 ms and the offset as 10 ms. Therefore, the first scheduler 104 starts the first communication task 121 at times 10 ms, 60 ms, 110 ms, 160 ms, etc.

[0029] <Second Operating System 105> The second operating system 105, shown in Figure 2, has the same functions as the first operating system 103 and executes programs as processes.

[0030] <Second scheduler 106, second vehicle control task 112, third vehicle control task 113, second communication task 122> The second scheduler 106 is a user process in the second operating system 105 and is designated as the startup process of the second operating system 105. That is, the second scheduler 106 is started automatically after the second operating system 105 starts up.

[0031] The second vehicle control task 112 configured for application 143, the third vehicle control task 113 configured for application 144, and the second communication task 122 configured for application 145 are child processes of the second scheduler 106. That is, the second vehicle control task 112, the third vehicle control task 113, and the second communication task 122 are started by instructions from the second scheduler 106.

[0032] The second vehicle control task 112 and the third vehicle control task 113 are tasks that perform processing for the vehicle control device 1 to control the vehicle 300. For example, the second vehicle control task 112 is the process of identifying the location of obstacles around the vehicle 300 based on images acquired from a camera mounted on the vehicle 300 and information on the speed of the vehicle 300 received from the first vehicle control task 111 of the first virtual machine 101. The third vehicle control task 113 is the process of generating a target travel trajectory for the vehicle 300 based on the location of the obstacles identified by the second vehicle control task 112.

[0033] The second communication task 122 is responsible for communication between the second virtual machine 102 and the first virtual machine 101, and between the second virtual machine 102 and the outside of the vehicle control device 1. In this embodiment, the second communication task 122 acquires data on the speed of the vehicle 300 received from the first vehicle control task 111, and transmits the target driving trajectory generated by the third vehicle control task 113 to the outside of the vehicle control device 1.

[0034] Within the second virtual machine 102, there is a shared memory (not shown) shared between the second vehicle control task 112 and the second communication task 122. Furthermore, within the second virtual machine 102, there is a shared memory (not shown) shared between the third vehicle control task 113 and the second communication task 122. Additionally, within the second virtual machine 102, there is a shared memory (not shown) shared between the second vehicle control task 112 and the third vehicle control task 113.

[0035] The second communication task 122, which is started by the second scheduler 106, acquires vehicle speed data using the inter-virtual machine communication function at the beginning of its processing and writes the acquired data to the shared memory between itself and the second vehicle control task 112. At the end of its processing, it reads the target driving trajectory data from the shared memory between itself and the third vehicle control task 113 and transmits it to the outside of the vehicle control device 1.

[0036] When the second communication task 122 transmits to the outside of the vehicle control device 1, the second communication task 122 passes the target trajectory data to be transmitted to the hypervisor 100 and requests the hypervisor 100 to access the communication peripheral 6 shown in Figure 1. After confirming that the communication peripheral 6 is not being used by the first virtual machine 101, the hypervisor 100 uses the communication peripheral 6 to transmit the target trajectory data to the outside of the vehicle control device 1.

[0037] The second vehicle control task 112, which is activated by the second scheduler 106, reads a value written to the shared memory between itself and the second scheduler 106 at the beginning of its own processing, then performs processing to identify surrounding obstacles, and at the end of its own processing, writes the position information of the surrounding obstacles to the shared memory between itself and the third vehicle control task 113.

[0038] The third vehicle control task 113, which is activated by the second scheduler 106, reads obstacle position information from the shared memory between itself and the second vehicle control task 112 at the beginning of its processing, then generates a target travel trajectory, and finally stores the generated target travel trajectory in the shared memory between itself and the second communication task 122.

[0039] <Second Scheduling Table 202> Figure 4 shows the second scheduling table 202 held internally by the second scheduler 106. The second scheduling table 202 includes information on the child processes that the second scheduler 106 should start, and the period and offset for which each child process should be started. In this embodiment, the child processes that the second scheduler 106 should start are the second vehicle control task 112, the third vehicle control task 113, and the second communication task 122.

[0040] In Figure 4, the period of the second vehicle control task 112 is described as 50 ms and the offset as 25 ms. Therefore, the second scheduler 106 starts the second vehicle control task 112 at times 25 ms, 75 ms, 125 ms, etc. Similarly, in Figure 4, the period of the third vehicle control task 113 is described as 50 ms and the offset as 50 ms. Therefore, the second scheduler 106 starts the third vehicle control task 113 at times 50 ms, 100 ms, 150 ms, etc. Also, in Figure 4, the period of the second communication task 122 is described as 50 ms and the offset as 20 ms. Therefore, the second scheduler 106 starts the second communication task 122 at times 20 ms, 70 ms, 120 ms, etc.

[0041] <Ideal Timing Chart for the Entire Vehicle Control Device 1> Figure 5 shows an ideal timing chart for the overall processing of the vehicle control device 1 in this embodiment. The first scheduler 104 and the second scheduler 106 start each task at the times mentioned above. The same shaded rectangles in Figure 5 represent the data flow.

[0042] That is, the first communication task 121 activated at time 10 reads the vehicle speed data written by the first vehicle control task 111 activated at time 0, and transmits the data to the second virtual machine 102 (and the outside of the vehicle control device 1). The second communication task 122 activated at time 20 reads the data transmitted by the first communication task. The data read by the second communication task 122 is used by the second vehicle control task 112 activated at time 25 to generate obstacle position information. The obstacle position information generated by the second vehicle control task 112 is used by the third vehicle control task 113 activated at time 50.

[0043] <Delay of internal time of first operating system 103> FIG. 6 is a diagram outlining the delay of the internal time of the first operating system 103 caused by switching between the first virtual machine 101 and the hypervisor 100 in the first arithmetic processing device 2. As shown in FIG. 2, the first arithmetic processing device 2 executes the hypervisor 100 and the first virtual machine 101. The first arithmetic processing device 2 normally executes the first virtual machine 101, but when processing is requested from the first virtual machine 101 to the hypervisor 100, it executes the hypervisor 100 until the processing is completed.

[0044] As shown in FIG. 6, in the case of the present embodiment, when the first communication task 121 uses the communication peripheral 6 to transmit speed data of the vehicle 300 to the outside of the vehicle control device 1, the processing of the first arithmetic processing device 2 is switched from the first virtual machine 101 to the hypervisor 100. As described above, the hypervisor 100 performs transmission processing using the communication peripheral 6, and when this processing is completed, the processing of the first arithmetic processing device 2 returns from the hypervisor 100 to the first virtual machine 101.

[0045] However, since the first operating system 103 runs inside the first virtual machine 101, the first operating system 103 is in a stopped state while the first arithmetic processing device 2 performs processing of the hypervisor 100.

[0046] As described above, the first operating system 103 has a system service that provides time. The time is provided by referencing the value of a time counter held inside the first operating system 103, which is periodically incremented based on, for example, an interrupt from a crystal oscillator mounted on the vehicle control device 1.

[0047] However, when the first operating system 103 is in a stopped state, the interrupt from the crystal oscillator becomes invalid, and the time counter does not perform counting up. As a result, although actual time has elapsed, within the first operating system 103, no time is considered to have elapsed while the first virtual machine 101 was stopped, so the time provided by the first operating system 103 lags behind the actual elapsed time.

[0048] <Delay in internal time of second operating system 105> Similarly, when the second communication task 122 transmits target travel trajectory data to the outside of the vehicle control device 1 using the communication peripheral 6, execution of processing by the second arithmetic processing device 3 and the third arithmetic processing device 4 is transferred from the second virtual machine 102 to the hypervisor 100, so the time provided by the second operating system 105 lags behind the actual elapsed time.

[0049] <Disorder of data flow caused by delay in internal time> FIG. 7 is a diagram showing disorder of data flow caused by delay in internal time. FIG. 7 shows a case where the internal time of the first operating system 103 is delayed by 14 ms from the actual time elapsed since the moment the vehicle control device 1 was started, and the internal time of the second operating system 105 is delayed by 1 ms.

[0050] As shown in FIG. 7, speed data of a vehicle 300 generated by the first vehicle control task 111 started at time 0 ms according to the internal time of the first operating system 103 is passed to the first communication task 121 started at time 10 ms according to the internal time of the first operating system 103, and is transmitted to the second virtual machine 102.

[0051] However, the time 13 ms in the internal time of the first operating system 103, when the processing of the first communication task 121 is completed, is 13 + 14 = 27 ms in actual time. The second communication task 122 in the second virtual machine 102 has already been completed at 23 ms in the internal time of the second operating system 105, which is 23 + 1 = 24 ms in actual time.

[0052] Therefore, the second communication task 122 cannot acquire data on the speed of the vehicle 300, and the subsequent second vehicle control task 112 and third vehicle control task 113 cannot start processing. Consequently, the flow of data exchanged between each task deviates from that shown in Figure 5.

[0053] The speed data of the vehicle 300 is acquired by a second communication task 122 which is activated at 70 ms in the internal time of the second operating system 105, i.e., 70 + 1 = 71 ms in actual time, and is subsequently processed by a second vehicle control task 112 and a third vehicle control task 113.

[0054] As a result, the time from when the first vehicle control task 111 acquires vehicle speed data until when the second vehicle control task 112 generates obstacle position information is extended by 50 ms compared to Figure 5. Therefore, in the second vehicle control task 112, there is an inconsistency between the time when the image is acquired from the camera mounted on the vehicle and the time when the vehicle speed information received from the first virtual machine 101 is generated. Consequently, the second vehicle control task 112 cannot generate correct obstacle position information. This may affect the control of the vehicle 300.

[0055] <Hypervisor 100> Figure 8 is a diagram showing an overview of the mechanism of the hypervisor 100 in this embodiment. As mentioned above, the first scheduler 104 is a process of the first operating system 103. The first vehicle control task 111 and the first communication task 121 are child processes of the first scheduler 104. The first virtual machine 101 itself, which includes the first scheduler 104, the first vehicle control task 111 and the first communication task 121, is also a process of the hypervisor 100.

[0056] As shown in Figure 8, in this embodiment, the hypervisor 100 has the function of providing an internal time 170 and recording the times when each process is started and terminated based on the internal time 170 (process scheduling record) as a system service.

[0057] Since the first virtual machine 101 is a process on the hypervisor 100, the hypervisor 100 is always running whether the first arithmetic processing unit 2 is processing the first virtual machine 101 or the first arithmetic processing unit 2 is processing the hypervisor 100. Similarly, the second scheduler 106 is a process of the second operating system 105, and the second vehicle control task 112, the third vehicle control task 113, and the second communication task 122 are child processes of the second scheduler 106, but the second virtual machine 102 itself, which includes these, is also a process of the hypervisor 100.

[0058] Therefore, whether the second arithmetic processing unit 3 and the third arithmetic processing unit 4 are processing the second virtual machine 102 or the second arithmetic processing unit 3 and the third arithmetic processing unit 4 are processing the hypervisor 100, the hypervisor 100 is always running. Therefore, if the first scheduler 104 refers to the internal time 170 of the hypervisor 100 instead of the internal time 171 of the first operating system 103, it is thought that a time delay in the first operating system 103 caused by interruptions by the hypervisor 100 will not occur, and scheduling similar to that in Figure 5 can be achieved.

[0059] Similarly, if the second scheduler 106 refers to the internal time 170 of the hypervisor 100 instead of the internal time 172 of the second operating system 105, it is thought that a time delay in the second operating system 105 caused by interruptions by the hypervisor 100 can be avoided, and scheduling similar to that in Figure 5 can be achieved.

[0060] <Task Startup by the First Scheduler 104 in This Embodiment> Figure 9 is a diagram showing the task startup method of the first scheduler 104 in this embodiment. Figure 9 shows the method by which the first scheduler 104 in this embodiment starts each task by referring to the time. As shown in Figure 9, in this embodiment, a first interruption time length monitoring unit 131 is provided on the hypervisor 100. The first interruption time length monitoring unit 131 is registered in the startup process of the hypervisor 100 and is executed as one of the processes on the hypervisor 100 immediately after the hypervisor 100 starts up.

[0061] The first interruption time monitoring unit 131 monitors the length of time the processing of applications 141 and 142 of the first virtual machine 101 was interrupted by the hypervisor 100. Specifically, the first interruption time monitoring unit 131 uses system services provided by the hypervisor 100 to refer to the internal time 170 of the hypervisor 100 and the process scheduling record 180, in particular the record of the start and end times of processing of the processes running the first virtual machine 101. The hypervisor 100 calculates the length of time the first virtual machine 101 was interrupted by the hypervisor 100 and sets it as the first processing interruption time length 132.

[0062] A shared memory is set up between the hypervisor 100 and the first virtual machine 101, and this is designated as the first storage unit 133. The first interruption time length monitoring unit 131 stores the first processing interruption time length 132 in the first storage unit 133. The first interruption time length monitoring unit 131 repeats this process until the processing of the vehicle control device 1 is completed. In addition to the first scheduler 104, the first time correction unit 134 is registered in the startup process of the first operating system 103 in the first virtual machine 101.

[0063] In other words, the first virtual machine 101 has a first time correction unit 134, which is a different startup process from the first scheduler 104. The first time correction unit 134 accesses the first storage unit 133 to read the first processing interruption time length 132 and passes the read value of the first processing interruption time length 132 to the first scheduler 104. In other words, the first time correction unit 134 constantly refers to the first processing interruption time length 132 of the applications 141 and 142 of the first virtual machine 101 stored in the first storage unit 133 and shares the referenced value with the first scheduler 104.

[0064] The first time correction unit 134 repeats this process until the processing of the first virtual machine 101 is completed. The first scheduler 104 starts applications 141 and 142 based on the time corrected using the first processing interruption time length 132 stored in the first storage unit 133.

[0065] The first scheduler 104 adds the value described in the first processing interruption time length 132 received from the first time correction unit 134 to the internal time 171 of the first operating system 103, which is obtained by the system services provided by the first operating system 103, to determine the corrected current time. The first scheduler 104 starts the first vehicle control task 111 and the first communication task 121 when the corrected current time matches the period and offset described in the first scheduling table 201 shown in Figure 3.

[0066] <Task Activation by the Second Scheduler 106 in the Invention> Figure 10 is a diagram showing the task activation method of the second scheduler 106 in this embodiment. Figure 10 shows the method by which the second scheduler 106 in this embodiment activates each task by referring to the time. As shown in Figure 10, in this embodiment, a second interruption time length monitoring unit 135 is provided on the hypervisor 100. The second interruption time length monitoring unit 135 is registered in the startup process of the hypervisor 100 and is executed as one of the processes on the hypervisor 100 immediately after the hypervisor 100 starts up.

[0067] The second interruption time monitoring unit 135 uses system services provided by the hypervisor 100 to refer to the internal time 170 of the hypervisor 100 and the process scheduling record 180, in particular the record of the start and end times of processing of the process running the second virtual machine 102. The hypervisor 100 calculates the length of time that the second virtual machine 102 was interrupted by the hypervisor 100 and sets it as the second processing interruption time length 136.

[0068] A shared memory is set up between the hypervisor 100 and the second virtual machine 102, and this is designated as the second storage unit 137. The second interruption time length monitoring unit 135 stores the second processing interruption time length 136 in the second storage unit 137. The second interruption time length monitoring unit 135 repeats this process until the processing of the vehicle control device 1 is completed. In this embodiment, the second interruption time length monitoring unit 135 is described as a separate process from the first interruption time length monitoring unit 131, but the first interruption time length monitoring unit 131 and the second interruption time length monitoring unit 135 may be executed as a single, identical process on the hypervisor 100.

[0069] The second time correction unit 138 is registered in addition to the second scheduler 106 in the startup process of the second operating system 105 within the second virtual machine 102. The second time correction unit 138 accesses the second storage unit 137 to read the second processing interruption time length 136 and passes the read value to the second scheduler 106. In other words, the second time correction unit 138 constantly refers to the second processing interruption time length 136 of applications 143, 144, and 145 of the second virtual machine 102 stored in the second storage unit 137, and shares the value of the referenced second processing interruption time length 136 with the second scheduler 106. The second time correction unit 138 repeats this process until the processing of the second virtual machine 102 is completed.

[0070] The second scheduler 106 adds the value described in the second processing interruption time length 136 received from the second time correction unit 138 to the internal time 172 of the second operating system 105, which is obtained by the system services provided by the second operating system 105, to determine the corrected current time. The second scheduler 106 starts the second vehicle control task 112, the third vehicle control task 113, and the second communication task 122 if the corrected current time matches the period and offset described in the second scheduling table 202 shown in Figure 4.

[0071] Figure 11 is a diagram showing the overall processing timing chart of the vehicle control device 1 according to the task activation method of the first scheduler 104 and the second scheduler 106 in this embodiment. According to this embodiment, even if the processing of the first virtual machine 101 or the second virtual machine 102 is interrupted by the hypervisor 100, the internal time 171 of the first operating system 103 and the internal time 172 of the second operating system 105 are corrected by the internal time 170 of the hypervisor 100, so that processing results as designed can be obtained more easily.

[0072] In other words, in this embodiment, while the vehicle control device 1 is running, the internal times 171 and 172 between the first virtual machine 101 and the second virtual machine 102 are synchronized. This prevents disruption of the data reading and writing order due to time delays caused by interruptions of the first virtual machine 101 and the second virtual machine 102 by the hypervisor 100. As a result, data shared among the multiple first arithmetic processing units 2, second arithmetic processing units 3, and third arithmetic processing units 4 is always read and written in the designed order, and the processing results are obtained as designed.

[0073] Furthermore, this embodiment can be applied when the first scheduler 104 is the startup process of the first operating system 103 of the first virtual machine 101, and applications 141 and 142 are child processes of the first scheduler 104. Also, this embodiment can be applied when the second scheduler 106 is the startup process of the second operating system 105 of the second virtual machine 102, and applications 143, 144, and 145 are child processes of the second scheduler 106. Therefore, it is suitable for a vehicle control device 1 in which a large number of applications 141, 142, 143, 144, and 145 run on multiple first virtual machines 101 and second virtual machines 102 in a short period of time.

[0074] In this embodiment, the first virtual machine 101 has a first time correction unit 134, which is a different startup process from the first scheduler 104. The first time correction unit 134 refers to the first processing interruption time length 132 of the applications 141 and 142 of the first virtual machine 101 stored in the first storage unit 133, and shares the value of the referenced first processing interruption time length 132 with the first scheduler 104.

[0075] Similarly, the second virtual machine 102 has a second time correction unit 138, which is a different startup process from the second scheduler 106. The second time correction unit 138 refers to the second processing interruption time length 136 of the applications 143, 144, and 145 of the second virtual machine 102 stored in the second storage unit 137, and shares the value of the referenced second processing interruption time length 136 with the second scheduler 106. Therefore, the configuration of this embodiment can be realized on the side of the first virtual machine 101 and the second virtual machine 102 by modifying the startup processes of the first operating system 103 and the second operating system 105.

[0076] [Example 2] A vehicle control device 1 according to Example 2 of the present invention will be described. The vehicle control device of this example has the hardware configuration shown in Figure 1 and the software configuration shown in Figure 2. The difference between this example and Example 1 is that the first scheduler 104 and the second scheduler 106 perform deadline monitoring. Components similar to those in Example 1 are denoted by the same reference numerals and their descriptions are omitted.

[0077] <Necessity of Deadline Monitoring> In order for data to be correctly passed between tasks, not only is time synchronization necessary, but the processing time of each task must also be completed by the deadline. For example, in the timing chart shown in Figure 5, the first vehicle control task 111 is started at time 0ms by the first scheduler 104, and the first communication task 121 is started at time 10ms. However, in order for the first communication task 121, which is started at time 10ms, to read the vehicle speed data and send it to the second virtual machine 102, the first vehicle control task 111 must complete its processing by time 10ms at the latest.

[0078] Therefore, the deadline for the first vehicle control task 111 to obtain the desired processing result as the vehicle control device 1 is 10 ms, and the maximum time length during which the first vehicle control task 111 can use the first arithmetic processing unit 2 is 10 ms, between time 0 ms and time 10 ms. Similarly, the maximum time length during which the second vehicle control task 112 can use the second arithmetic processing unit 3 and the third arithmetic processing unit 4 is 25 ms, from time 25 ms to time 50 ms. Similarly, the maximum time length during which the third vehicle control task 113 can use the second arithmetic processing unit 3 and the third arithmetic processing unit 4 is 50 ms, from time 50 ms to time 70 ms.

[0079] Since the processing load of the vehicle control task can fluctuate due to the vehicle's condition and surrounding environment, it is desirable to check whether the upper limit time is exceeded (deadline monitoring). Regarding the first communication task 121 and the second communication task 122, predetermined data (for example, vehicle 300 speed data and target trajectory data) are sent and received. However, since the size of each data is usually fixed in advance, the time these communication tasks use the first arithmetic processing unit 2, the second arithmetic processing unit 3, and the third arithmetic processing unit 4 is generally constant, and it is not necessary to consider the upper limit time for using the first arithmetic processing unit 2, the second arithmetic processing unit 3, and the third arithmetic processing unit 4.

[0080] <First Scheduling Table 201> Figure 12 shows the first scheduling table 201 that the first scheduler 104 in this embodiment internally holds. The first scheduling table 201 includes information on the period and offset, as well as information on subsequent tasks and information on the upper limit of the time length. A subsequent task is a task that uses data generated by its own task.

[0081] For example, let's assume that two applications 141 and 142 of the first virtual machine 101 use the first arithmetic processing unit 2 consecutively. Of the two applications 141 and 142 that use the first arithmetic processing unit 2 consecutively, the first vehicle control task 111 configured for application 141, which is the preceding application that uses the first arithmetic processing unit 2 first, is designated as the preceding task. Of the two applications 141 and 142 that use the first arithmetic processing unit 2 consecutively, the second task configured for application 142, which is the succeeding application that uses the first arithmetic processing unit 2 secondly, is designated as the succeeding task.

[0082] The first scheduler 104 can calculate the maximum time each task can use the first arithmetic processing unit 2 by referring to the information of subsequent tasks. In the case of Figure 12, the first vehicle control task 111 is started for the first time at 0 ms, and the first communication task 121, which is a subsequent task, is started for the first time at 10 ms. Therefore, 10 ms - 0 ms = 10 ms is calculated as the maximum time for the first vehicle control task 111. The maximum time is not calculated for the first communication task 121, for which no subsequent tasks are set. In other words, in this embodiment, the maximum time for which the first arithmetic processing unit 2 can be used for application 141 is predetermined.

[0083] <Second Scheduling Table 202> Figure 13 shows the second scheduling table 202 internally held by the second scheduler 106 in this embodiment. The first scheduling table 201 includes information on the period and offset, as well as information on the subsequent task and the upper limit time length. In the case of Figure 13, the time at which the second vehicle control task 112 is first started is 25 ms, and the time at which the subsequent task, the third vehicle control task 113, is first started is 50 ms. Therefore, 50 ms - 25 ms = 25 ms is calculated as the upper limit time length of the second vehicle control task 112.

[0084] Similarly, the time at which the third vehicle control task 113 is first activated is 50 ms, and the time at which the subsequent task, the second vehicle control task 112, is first activated is 20 ms. In this case, since the first activation time of the subsequent task arrives earlier, we refer to the second activation time of the subsequent task, which is 20 + 50 = 70 ms, and calculate that 70 ms - 50 ms = 20 ms is the upper limit duration of the third vehicle control task 113.

[0085] Note that the second communication task 122 only receives vehicle speed data from the first communication task 121 during its initial activation, and from the second activation onward, it receives vehicle speed data and transmits target trajectory data generated by the third vehicle control task 113. For the second communication task 122, which does not have a subsequent task set, the upper limit time length is not calculated.

[0086] <First Vehicle Control Task 111, Second Vehicle Control Task 112, and Third Vehicle Control Task 113> The first vehicle control task 111, the second vehicle control task 112, and the third vehicle control task 113 notify the first scheduler 104 or the second scheduler 106 of the completion of their processing when they have finished their own processing. The first vehicle control task 111, which is started by the first scheduler 104, notifies the first scheduler 104 of the completion of their processing. The second vehicle control task 112 and the third vehicle control task 113, which are started by the second scheduler 106, notify the second scheduler 106 of the completion of their processing.

[0087] <Deadline Monitoring by the First Scheduler 104> When the first scheduler 104 starts a task for which an upper limit time has been calculated, it monitors whether the task is using the first arithmetic processing unit 2 beyond the upper limit time. Specifically, after starting the first vehicle control task 111 at time 0ms, it checks whether it has received a processing completion notification from the first vehicle control task 111 by time 10ms, which is 10ms later. If it has not received a processing completion notification, it can be detected that the first vehicle control task 111 is using the first arithmetic processing unit 2 beyond the upper limit time.

[0088] When the first vehicle control task 111 uses the first arithmetic processing unit 2 beyond the upper limit time, the vehicle control device 1 cannot obtain the correct processing result. For this reason, when applications 141 and 142 use the first arithmetic processing unit 2 beyond the upper limit time, the first scheduler 104 either stops or degrades applications 141 and 142.

[0089] Specifically, the first scheduler 104 may request the hypervisor 100 to stop the entire first virtual machine 101 or vehicle control device 1. Alternatively, the first scheduler 104 may perform a degraded operation in which it temporarily stops and terminates the first vehicle control task 111, calculates the vehicle speed data of the vehicle 300 by simply estimating it from past vehicle speed data, passes it to the first communication task 121, and then starts the first vehicle control task 111 as usual at the next startup timing calculated from the first scheduling table 201.

[0090] <Deadline Monitoring by the Second Scheduler 106> Deadline monitoring by the second scheduler 106 is the same as that by the first scheduler 104.

[0091] <Deduction of upper limit time in the first scheduler 104> As described in Example 1, there are periods when the processing of the first virtual machine 101 is interrupted by the hypervisor 100. If the first virtual machine 101 is interrupted by the hypervisor 100 while the first vehicle control task 111 is executing, the upper limit time for which the first vehicle control task 111 can use the first arithmetic processing unit 2 is kept at 10 ms without considering the interruption time. In this case, by the time the first vehicle control task 111 has used the first arithmetic processing unit 2 for 10 ms, the subsequent first communication task 121 has already been started, and the vehicle control device 1 cannot obtain the correct processing result.

[0092] Therefore, in this embodiment, if the processing of applications 141 and 142 is interrupted by the hypervisor 100, the first scheduler 104 shortens the upper limit time for the interrupted applications 141 and 142 using the first processing interruption time length 132 stored in the first storage unit 133.

[0093] Specifically, the first scheduler 104 subtracts the value specified in the first processing interruption time length 132 from the upper limit time length to obtain a new upper limit time length. For example, if the first processing interruption time length 132 is specified as 1 ms, the upper limit time length is changed to 10 ms - 1 ms = 9 ms. If the time duration for which the first vehicle control task 111 uses the first arithmetic processing unit 2 is 9 ms or less, the first vehicle control task 111 will be completed before the subsequent first communication task 121 starts, and the correct processing result can be obtained.

[0094] <Deducting the upper limit of the time length by the second scheduler 106> The deduction of the upper limit of the time length by the second scheduler 106 is the same as the deduction of the upper limit of the time length by the second scheduler 106.

[0095] According to this embodiment, even if the first virtual machine 101 or the second virtual machine 102 is interrupted by the hypervisor 100, the deadline monitoring by the first scheduler 104 and the second scheduler 106 functions normally, and it is possible to confirm that each vehicle control task is adhering to the processing time deadline (deadline) required to obtain the correct processing result.

[0096] According to this embodiment, if applications 141 and 142 use the first arithmetic processing unit 2 for longer than the upper limit time, the first scheduler 104 either stops or degrades applications 141 and 142. Therefore, even if applications 141 and 142 use the first arithmetic processing unit 2 for longer than the upper limit time, the vehicle control device 1 can more easily obtain correct processing results.

[0097] Furthermore, according to this embodiment, if the processing of applications 141 and 142 is interrupted by the hypervisor 100 during processing, the first scheduler 104 shortens the upper limit time for the interrupted applications 141 and 142 using the first processing interruption time length 132 stored in the first storage unit 133. As a result, the preceding task is more likely to be completed before the subsequent task starts, allowing the vehicle control device 1 to obtain more correct processing results.

[0098] [Example 3] A vehicle control device 1 in a third embodiment of the present invention will be described. The difference from the second embodiment is that the total upper limit of the time that the second arithmetic processing unit 3 and the third arithmetic processing unit 4 can be used is set for the sum of the processing times of the second vehicle control task 112 and the third vehicle control task 113.

[0099] <Second Scheduling Table 202> Figure 14 shows the second scheduling table 202 internally held by the second scheduler 106 in this embodiment. The second scheduling table 202 in this embodiment includes information on the period, offset, and subsequent tasks, as well as information on the summation flag. The summation flag is a binary flag that indicates whether or not to set the total upper limit time length by using the total time that the current task and the subsequent tasks use the second arithmetic processing unit 3 and the third arithmetic processing unit 4 together, when a subsequent task is set.

[0100] The task following the second vehicle control task 112 is the third vehicle control task 113, and since the summation flag is set to 1 (enabled), the second scheduler 106 monitors whether the combined time of the second vehicle control task 112 and the third vehicle control task 113 using the second arithmetic processing unit 3 and the third arithmetic processing unit 4 does not exceed the total upper limit time.

[0101] On the other hand, the task following the third vehicle control task 113 is the second communication task 122, and since the summation flag is 0 (invalid), the second scheduler 106 does not sum the time used by the second arithmetic processing unit 3 and the third arithmetic processing unit 4 between the third vehicle control task 113 and the second communication task 122, but instead monitors the usage time of each.

[0102] In this embodiment, the third vehicle control task 113 has already been combined with the second vehicle control task 112. Therefore, if the combined flag for the third vehicle control task 113 is set to 1, the second scheduler 106 monitors whether the combined time of the three tasks—the second vehicle control task 112, the third vehicle control task 113, and the second communication task 122—does not exceed the total upper limit time for using the second arithmetic processing unit 3 and the third arithmetic processing unit 4.

[0103] <Second Scheduler 106> In this embodiment, the second scheduler 106, when the summation flag is enabled for a certain preceding task in the second scheduling table 202, starts the subsequent task of the preceding task immediately after the preceding task finishes, regardless of the period and offset information set for the subsequent task of the preceding task. It also monitors the total time that the preceding task and its subsequent task use the second arithmetic processing unit 3 and the third arithmetic processing unit 4, and sets the time length from the time the preceding task starts to the time the subsequent task starts (deadline) as the upper limit time length.

[0104] In Figure 14, the task following the second vehicle control task 112 is the third vehicle control task 113, and the summation flag is enabled for the second vehicle control task 112. The time when the second vehicle control task 112 is first started is 25 ms. The time when the third vehicle control task 113, which is the task following the second vehicle control task 112, is first started is 50 ms.

[0105] The second communication task 122, which is the successor task to the third vehicle control task 113, is first started at 20 ms. This is before the time when the third vehicle control task 113 is first started. Therefore, the deadline for the third vehicle control task 113 is 20 + 50 = 70 ms, which is the time when the second communication task 122 is started for the second time. Accordingly, the total upper limit of time that the second vehicle control task 112 and the third vehicle control task 113 can use the second arithmetic processing unit 3 and the third arithmetic processing unit 4 together is calculated to be 70 - 25 = 45 ms.

[0106] <Timing Chart When Summing Up Upper Limit Time Lengths> Figure 15 is a diagram showing the timing chart of the overall processing of the vehicle control device 1 according to the task activation method of the first scheduler 104 and the second scheduler 106 in this embodiment. In Figure 15, the second vehicle control task 112 is activated by the second scheduler 106 at time 25 ms. The second vehicle control task 112 completes processing at time 56 ms, so the second arithmetic processing unit 3 and the third arithmetic processing unit 4 have been used for 56 - 25 = 31 ms. Immediately after this, the second scheduler 106 activates the third vehicle control task 113.

[0107] The maximum time that the third vehicle control task 113 can use the second arithmetic processing unit 3 and the third arithmetic processing unit 4 is 45 - 31 = 14 ms. The third vehicle control task 113 completes processing at time 68 ms. Since the third vehicle control task 113 was started at time 56 ms, the third vehicle control task 113 used the second arithmetic processing unit 3 and the third arithmetic processing unit 4 for 68 - 56 = 12 ms.

[0108] The 12 ms during which the third vehicle control task 113 used the second processing unit 3 and the third processing unit 4 is less than the 14 ms upper limit time that the third vehicle control task 113 can use the second processing unit 3 and the third processing unit 4. Therefore, the third vehicle control task 113 finishes processing before the second communication task 122 is activated at time 70 ms. Thus, the target trajectory data generated by the third vehicle control task 113 is transmitted to the outside of the vehicle control device 1 by the second communication task 122, which is activated at time 70 ms by the second scheduler 106, as in Figure 11.

[0109] In Embodiment 1 shown in Figure 11, the time at which the third vehicle control task 113 was started by the second scheduler 106 was 50 ms, so the second vehicle control task 112 needed to complete its processing before 50 ms. On the other hand, in this embodiment shown in Figure 15, an upper limit is set on the total time used by the second arithmetic processing unit 3 and the third arithmetic processing unit 4 by the second vehicle control task 112 and the third vehicle control task 113 combined. Therefore, even if the processing of the second vehicle control task 112 is extended beyond 50 ms, the vehicle control device 1 can obtain the desired processing result if the processing of the third vehicle control task 113 is completed within the combined upper limit time.

[0110] In the method of Embodiment 2, even if the second vehicle control task 112 is completed at time 56 ms, in order to obtain the desired processing result, it is necessary to change the second scheduling table 202 so that the third vehicle control task 113 is shifted by, for example, 10 ms later and started at time 60 ms. This requires delaying the time when the second communication task 122 transmits the target driving trajectory data from 70 ms to 80 ms.

[0111] However, this means that the time lag between the time the camera detects an obstacle and the vehicle control device 1 generates target driving trajectory data that avoids the obstacle is extended by 10 ms, which may affect the control of the vehicle 300. In this embodiment, by combining the time used by the second arithmetic processing unit 3 and the third arithmetic processing unit 4 between the second vehicle control task 112 and the third vehicle control task 113, it is possible to address the extension of processing time for part of the second vehicle control task 112 and the third vehicle control task 113 without increasing the time lag.

[0112] According to this embodiment, even if the processing of a part of the second vehicle control task 112 and the third vehicle control task 113 is extended, the processing result will not be affected as long as the other parts of the second vehicle control task 112 and the third vehicle control task 113 complete processing within the total upper limit time length. Therefore, it has the effect of preventing the second vehicle control task 112, the third vehicle control task 113, and the vehicle control device 1 from stopping and degrading due to exceeding the upper limit time length determined by deadline monitoring. Furthermore, it has the effect of suppressing the increase in the time lag from input to output to the vehicle control device 1 that occurs when the upper limit time length of each vehicle control is set to a sufficiently long length in order to prevent exceeding the deadline.

[0113] [Example 4] A vehicle control device 1 in a fourth embodiment of the present invention will be described. The difference between this embodiment and Example 1 is that the first interruption time length monitoring unit 131 and the second interruption time length monitoring unit 135 transmit time correction notifications to the first time correction unit 134 and the second time correction unit 138.

[0114] <Use of the First Arithmetic Processing Unit 2, etc. by the First Time Correction Unit 134 and the Second Time Correction Unit 138> In Embodiments 1 and 2, the first time correction unit 134 was registered in the startup process of the first operating system 103 and referenced the first processing interruption time length 132. Similarly, the second time correction unit 138 was registered in the startup process of the second operating system 105 and constantly referenced the second processing interruption time length 136. This is an infinite loop process and therefore consumes the resources of the first arithmetic processing unit 2, the second arithmetic processing unit 3, and the third arithmetic processing unit 4.

[0115] Since the first time correction unit 134, the first scheduler 104, and the first vehicle control task 111 are each executed in parallel as processes on the first operating system 103, the more resources the first time correction unit 134 consumes of the first arithmetic processing unit 2, the longer the time it takes for the first vehicle control task 111 to complete processing, making it more likely for deadline errors to occur. The same applies to the second time correction unit 138.

[0116] On the other hand, the first vehicle control task 111 inside the first virtual machine 101 cannot determine whether the first virtual machine 101 on which it is installed is stopped by the hypervisor 100. The same applies to the second virtual machine 102. Therefore, in this embodiment, time correction is performed by notifying the first virtual machine 101, etc., of an event (time correction notification) from an external source, etc., when time correction becomes necessary.

[0117] <First Time Correction Unit 134> The first time correction unit 134 is started in the startup process of the first operating system 103, but does not constantly read the first processing interruption time length 132. When it enters an event waiting state, it does not use the resources of the first arithmetic processing unit 2. When the first time correction unit 134 receives a time correction notification from the first operating system 103, it is released from waiting, reads the first processing interruption time length 132, and performs time correction on the first scheduler 104. Once time correction is complete, the first time correction unit 134 returns to an event waiting state.

[0118] <First Interruption Time Monitoring Unit 131> The first interruption time monitoring unit 131 obtains the internal time 170 and the process scheduling record 180 from the hypervisor 100 and calculates the first processing interruption time 132 of the first virtual machine 101. If the calculated value of the first processing interruption time 132 exceeds a threshold, the first interruption time monitoring unit 131 saves the first processing interruption time 132 to the first storage unit 133 and notifies the first virtual machine 101 of a time correction notification to perform time correction.

[0119] <First Virtual Machine 101> When the first virtual machine 101 receives a time correction notification, it disables the time correction notification in preparation for the next time correction notification, and then notifies the first operating system 103 of the time correction notification.

[0120] <First Operating System 103> When the first operating system 103 receives a time correction notification, it invalidates the time correction notification in preparation for the next time correction notification, and then notifies the first time correction unit 134 of the time correction notification.

[0121] <Second Time Correction Unit 138> The second time correction unit 138 is started in the startup process of the second operating system 105, but does not constantly read the second processing interruption time length 136. Instead, it does not use the second arithmetic processing unit 3 and the third arithmetic processing unit 4 when it is in an event waiting state. When the second time correction unit 138 receives a time correction notification from the second operating system 105, it is released from waiting state, reads the second processing interruption time length 136, and performs time correction on the second scheduler 106. Once time correction is complete, the second time correction unit 138 returns to an event waiting state.

[0122] <Second Interruption Time Monitoring Unit 135> The second interruption time monitoring unit 135 obtains the internal time 170 and the process scheduling record 180 from the hypervisor 100 and calculates the second processing interruption time 136 of the second virtual machine 102. If the calculated value of the second processing interruption time 136 exceeds a threshold, the second interruption time monitoring unit 135 saves the second processing interruption time 136 to the second storage unit 137 and notifies the second virtual machine 102 of a time correction notification to perform time correction.

[0123] <Second Virtual Machine 102> When the second virtual machine 102 receives a time correction notification, it disables the time correction notification in preparation for the next time correction notification, and then notifies the second operating system 105 of the time correction notification.

[0124] <Second operating system 105> When the second operating system 105 receives a time correction notification, it disables the time correction notification in preparation for the next time correction notification, and then notifies the second time correction unit 138 of the time correction notification.

[0125] Figure 16 is a flowchart showing the operation of the vehicle control device 1 of this embodiment. As shown in Figure 16, the operation of the first virtual machine 101 will be described below. The first interruption time length monitoring unit 131 determines whether the first processing interruption time length 132 of the applications 141 and 142 of the first virtual machine 101 has exceeded a threshold (S101).

[0126] If the first processing interruption time length 132 exceeds a threshold (S101), the first interruption time length monitoring unit 131 sends a time correction notification to the first time correction unit 134 (S102). The first time correction unit 134 determines whether or not it has received the time correction notification (S103). If the first time correction unit 134 has received the time correction notification (S103), the first scheduler 104 starts applications 141 and 142 based on the time corrected using the first processing interruption time length 132 (S104).

[0127] According to this embodiment, the time that the time correction tasks of the first virtual machine 101 and the second virtual machine 102 use the resources of the first arithmetic processing unit 2, the second arithmetic processing unit 3, and the third arithmetic processing unit 4 is reduced, and the resources of the first arithmetic processing unit 2, the second arithmetic processing unit 3, and the third arithmetic processing unit 4 are allocated more to the processes that process the first vehicle control task 111, the second vehicle control task 112, the third vehicle control task 113, the first scheduler 104, and the second scheduler 106, thereby shortening the time from the start to the completion of the processing of the first vehicle control task 111, the second vehicle control task 112, and the third vehicle control task 113.

[0128] It should be noted that the present invention is not limited to the embodiments described above, and various modifications are included. For example, the embodiments described above are described in detail to make the present invention easier to understand, and are not necessarily limited to those having all the configurations described. Furthermore, it is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, and replace parts of the configuration of each embodiment with other configurations. In addition, some or all of the above configurations, functions, processing units, processing means, etc., may be implemented in hardware, for example by designing them as integrated circuits, or they may all be implemented in software.

[0129] 1 Vehicle control device 2 First arithmetic processing unit 3 Second arithmetic processing unit 4 Third arithmetic processing unit 5 Memory 6 Communication peripheral 100 Hypervisor 101 First virtual machine 102 Second virtual machine 103 First operating system 104 First scheduler 105 Second operating system 106 Second scheduler 111 First vehicle control task 112 Second vehicle control task 113 Third vehicle control task 121 First communication task 122 Second communication task 131 First interruption time length monitoring unit 132 First processing interruption time length 133 First storage unit (shared memory) 134 First time correction unit 135 Second interruption time length monitoring unit 136 Second processing interruption time length 137 Second storage unit (shared memory) 138 Second time correction unit 141, 142, 143, 144, 145 Applications 151, 152 Startup Processes 161, 162, 163, 164, 165 Child Processes 170, 171, 172 Internal Time 180 Process Scheduling Record 201 First Scheduling Table 202 Second Scheduling Table 300 Vehicles

Claims

1. A vehicle control device comprising: a hypervisor; a virtual machine started by the hypervisor; the virtual machine having an application; a scheduler for starting the application; and the hypervisor, the scheduler, and the application being processed by one or more arithmetic processing units, wherein the vehicle control device comprises: an interruption time monitoring unit that monitors the length of time the processing of the application on the virtual machine is interrupted by the hypervisor; and a storage unit that stores the length of time the interruption time monitored by the interruption time monitoring unit; and the scheduler starts the application based on a time corrected using the length of time the interruption time stored in the storage unit.

2. A vehicle control device according to claim 1, wherein the maximum time length for which the arithmetic processing unit can be used for the application is predetermined, and the scheduler shortens the maximum time length for the interrupted application by the hypervisor when the processing of the application is interrupted by the hypervisor, using the processing interruption time length stored in the storage unit.

3. A vehicle control device according to claim 2, wherein when the application uses the processing unit for a period exceeding the upper limit time, the scheduler either stops the application or degrades it.

4. A vehicle control device according to claim 2, wherein when two applications of the virtual machine use the arithmetic processing unit consecutively, a predetermined total maximum time for which the preceding task configured for the preceding application that uses the arithmetic processing unit first and the succeeding task configured for the succeeding application that uses the arithmetic processing unit second among the two applications that use the arithmetic processing unit consecutively can use the arithmetic processing unit is determined in advance, the preceding application has a start time, the scheduler starts the preceding application when the corrected time matches the start time, starts the succeeding application after the processing of the preceding application is completed, and monitors whether the total time the preceding application and the succeeding application use the arithmetic processing unit exceeds the total maximum time.

5. A vehicle control device according to claim 1, characterized in that the virtual machine has an operating system, the scheduler is the startup process of the operating system, and the application is a child process of the scheduler.

6. A vehicle control device according to claim 5, wherein the virtual machine has a time correction unit which is a different startup process from the scheduler, and the time correction unit refers to the processing interruption time length of the application of the virtual machine stored in the storage unit, and shares the value of the referenced processing interruption time length with the scheduler.

7. A vehicle control device according to claim 6, wherein the interruption time monitoring unit sends a time correction notification to the time correction unit when the processing interruption time of the application of the virtual machine exceeds a threshold, and when the time correction unit receives the time correction notification, the scheduler starts the application based on the time corrected using the processing interruption time.

Images