Vehicle control system

Abstract

This vehicle control system provides a vehicle that can more effectively obtain processing results as designed, even if the processing of the virtual machine is interrupted by the hypervisor. [Solution] A vehicle control device comprising 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 being processed by one or more processing units, comprises an interruption time 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 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.

Description

[Technical Field]

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

[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 line with this trend, the automotive industry is shifting from the conventional distributed architecture, in which individual vehicle control devices are 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 the same vehicle control device, so it is important to establish non-interference between the vehicle control software. Accordingly, introduction of virtualization technology (hypervisor) to vehicle control devices has attracted attention. This technology separates hardware resources used by each vehicle control software, and enables safe sharing of hardware for hardware resources that have to be shared and used by multiple vehicle control software through methods such as exclusive control and time-division multiplexing.

[0004] An example of a vehicle control device using a hypervisor is the technology described in Patent Document 1. The technology in Patent Document 1 is an electronic control device comprising an arithmetic unit that executes a program, 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 the switching time when switching tasks to be executed, the time storage mechanism stores the time when an 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 is operating in the arithmetic unit, and the hypervisor generates an interrupt to notify the arithmetic unit of the access violation according to the detection result by 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. [Prior art documents] [Patent Documents]

[0006] [Patent Document 1] International Publication No. 2023 / 119652 [Patent Document 2] International Publication No. 2022 / 130942 [Overview of the project] [Problems that the invention aims to solve]

[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. [Means for solving the problem]

[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. [Effects of the Invention]

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

[0010] [Figure 1] A diagram showing the hardware configuration of the vehicle control device in Example 1. [Figure 2] A diagram showing the software configuration of the vehicle control device in Example 1. [Figure 3] A diagram showing the first scheduling table internally maintained by the first scheduler. [Figure 4] A diagram showing the second scheduling table internally maintained by the second scheduler. [Figure 5] This figure shows an ideal timing chart for the overall processing of the vehicle control device in Example 1. [Figure 6] A diagram illustrating the internal time delay of the first operating system caused by the switching between the virtual machine and the hypervisor in the first processing unit. [Figure 7] This diagram illustrates data flow disruptions caused by internal time delays. [Figure 8] A diagram illustrating the overview of how hypervisors work. [Figure 9] This figure shows the task initiation method of the first scheduler in Example 1. [Figure 10] This figure shows the task initiation method of the second scheduler in Example 1. [Figure 11] This figure shows the timing chart of the overall processing of the vehicle control device based on the task activation methods of the first scheduler and the second scheduler in Example 1. [Figure 12] This figure shows the first scheduling table internally held by the first scheduler in Example 2. [Figure 13] This figure shows the second scheduling table internally maintained by the second scheduler in Example 2. [Figure 14] This figure shows the second scheduling table internally held by the second scheduler in Example 3. [Figure 15] This figure shows the timing chart of the overall processing of the vehicle control device using the task activation method of the first scheduler and the second scheduler according to Example 3. [Figure 16] A flowchart illustrating the operation of the vehicle control device in Example 4. [Modes for carrying out the invention]

[0011] Hereinafter, examples of preferred embodiments (working examples) of the present invention will be described. The present working example described below relates to a vehicle control device. For simplicity, the following working example will be described with an example in which two virtual machines are installed in a vehicle control device having three arithmetic processing units (CPUs: Central Processing Units), however, the number of CPUs and virtual machines installed in the vehicle control device is not limited thereto. Furthermore, the number of tasks executed in each virtual machine is also merely an example.

[0012] Note that in the accompanying drawings, functionally identical elements are denoted by the same reference numerals. In addition, although the accompanying drawings show working examples in accordance with the principles of the present disclosure, these are provided for the purpose of understanding the present disclosure, and are by no means used for interpreting the present disclosure in a limited manner. The description in the present specification is merely a typical example, and does not limit the scope of claims or application examples of the present disclosure in any sense.

[0013] Working Example 1 <Configuration> FIG. 1 is a diagram showing a hardware configuration of a vehicle control device 1 according to the present working example. FIG. 2 is a diagram showing a software configuration of the vehicle control device 1 according to the present working example.

[0014] <Vehicle Control Device 1> The hardware configuration of the vehicle control device 1 according to the present working example will be described with reference to FIG. 1. The vehicle control device 1 shown in FIG. 1 is mounted on a vehicle 300 and controls the operation of the vehicle 300. As shown in FIG. 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. Specifically, the first arithmetic processing unit 2, the second arithmetic processing unit 3, and the third arithmetic processing unit 4 are 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 can be at the user level or kernel level. Kernel-level programs are those provided as part of the first operating system 103. User-level programs are those that exist outside of the first operating system 103 but are launched on it.

[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. While the user process is running, it can call services (system services) provided by the kernel process. 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 automatically started 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 an external location outside 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 an external location outside the vehicle control device 1.

[0027] <First scheduling table 201> Figure 3 shows the first scheduling table 201 internally maintained by the first scheduler 104. The first scheduling table 201 includes information on the child processes that the first scheduler 104 should start, as well as 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 similar functionality to 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 for the second operating system 105. That is, the second scheduler 106 is automatically started 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 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 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 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 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 internally held by the second scheduler 106. The second scheduling table 202 includes information on the child processes that the second scheduler 106 should start, as well as 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 50ms and the offset as 25ms. Therefore, the second scheduler 106 starts the second vehicle control task 112 at times 25ms, 75ms, 125ms, etc. Similarly, in Figure 4, the period of the third vehicle control task 113 is described as 50ms and the offset as 50ms. Therefore, the second scheduler 106 starts the third vehicle control task 113 at times 50ms, 100ms, 150ms, etc. Also, in Figure 4, the period of the second communication task 122 is described as 50ms and the offset as 20ms. Therefore, the second scheduler 106 starts the second communication task 122 at times 20ms, 70ms, 120ms, etc.

[0041] <Ideal timing chart for the entire vehicle control device 1> Figure 5 shows an ideal timing chart of 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 described above. The same shaded rectangles in Figure 5 represent the data flow.

[0042] Specifically, the first vehicle control task 111, which is started at time 0, writes vehicle speed data, which is read by the first communication task 121, which is started at time 10, and transmits it to the second virtual machine 102 (and outside the vehicle control device 1). The data transmitted by the first communication task is read by the second communication task 122, which is started at time 20. The data read by the second communication task 122 is used by the second vehicle control task 112, which is started 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, which is started at time 50.

[0043] <Internal time delay of the first operating system 103> Figure 6 is a diagram illustrating the internal time delay of the first operating system 103 caused by the switching between the first virtual machine 101 and the hypervisor 100 in the first arithmetic processing unit 2. As shown in Figure 2, the first arithmetic processing unit 2 runs both the hypervisor 100 and the first virtual machine 101. Normally, the first arithmetic processing unit 2 runs the first virtual machine 101, but when the first virtual machine 101 requests processing from the hypervisor 100, it runs the hypervisor 100 until the processing is completed.

[0044] As shown in Figure 6, in this embodiment, when the first communication task 121 transmits data on the speed of the vehicle 300 to the outside of the vehicle control device 1 using the communication peripheral 6, the processing of the first arithmetic processing unit 2 switches from the first virtual machine 101 to the hypervisor 100. As described above, the hypervisor 100 performs the transmission process using the communication peripheral 6, and once this is complete, the processing of the first arithmetic processing unit 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 remains in a stopped state while the first processing unit 2 is performing processing on the hypervisor 100.

[0046] As described above, the first operating system 103 has a system service that provides the time. This provision of the time is performed by a time counter kept inside the first operating system 103, which periodically counts up based on an interrupt from, for example, a crystal oscillator mounted on the vehicle control device 1, and refers to the value of the time counter.

[0047] However, when the first operating system 103 is stopped, interrupts from the crystal oscillator are disabled, and the time counter does not increment. As a result, even though actual time has passed, the first operating system 103 treats the time while the first virtual machine 101 is stopped as not having elapsed, so the time provided by the first operating system 103 lags behind the actual elapsed time.

[0048] <Internal time delay of the second operating system 105> Similarly, when the second communication task 122 transmits target trajectory data to the outside of the vehicle control device 1 using the communication peripheral 6, the execution of processing by the second arithmetic processing unit 3 and the third arithmetic processing unit 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] <Data flow disruption caused by internal time delays> Figure 7 illustrates the disruption of data flow caused by internal time delays. In Figure 7, the internal time of the first operating system 103 is 14ms behind 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 1ms behind.

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

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

[0052] Therefore, the second communication task 122 is unable to acquire data on the vehicle 300's speed, and the subsequent second vehicle control task 112 and third vehicle control task 113 are unable to 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 initiated at 70ms in the internal time of the second operating system 105, i.e., 70+1=71ms 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 illustrating the overview 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 (process scheduling record) based on the internal time 170 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 whether the second arithmetic processing unit 3 and the third arithmetic processing unit 4 are processing the hypervisor 100, the hypervisor 100 is always running. Thus, 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 activation by the first scheduler 104 in this embodiment> Figure 9 shows the task startup method of the first scheduler 104 in this embodiment. Figure 9 shows how 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 the 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 present invention> Figure 10 shows the task startup method of the second scheduler 106 in this embodiment. Figure 10 shows how the second scheduler 106 in this embodiment starts 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 accurately.

[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 read / write 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, resulting in the effect of obtaining processing results 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 references 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 referenced value of the 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 in Embodiment 2 of the present invention will now be described. The vehicle control device of this embodiment has the hardware configuration shown in Figure 1 and the software configuration shown in Figure 2. The difference between this embodiment and Embodiment 1 is that the first scheduler 104 and the second scheduler 106 perform deadline monitoring. Components similar to those in Embodiment 1 are denoted by the same reference numerals and their descriptions are omitted.

[0077] <The necessity of deadline monitoring> For data to be correctly transferred 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 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 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 (e.g., vehicle speed data and target trajectory data) are sent and received. However, since the size of each data point 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 internally held by the first scheduler 104 in this embodiment. The first scheduling table 201 includes information on 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 first application to use the first arithmetic processing unit 2, 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 second application to use the first arithmetic processing unit 2, 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 0ms, and the subsequent task, the first communication task 121, is started for the first time at 10ms. Therefore, 10ms - 0ms = 10ms 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 only receives vehicle speed data and transmits target trajectory data generated by the third vehicle control task 113 during subsequent activations. The upper limit time length is not calculated for the second communication task 122 if no subsequent tasks are set.

[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 its 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 detect 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 using the second scheduler 106> Deadline monitoring by the second scheduler 106 is the same as that by the first scheduler 104.

[0091] <Subtraction of the maximum time length in the first scheduler 104> As described in Example 1, the first virtual machine 101 may experience interruptions in processing 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 maximum time limit for the first vehicle control task 111 to use the first arithmetic processing unit 2 remains at 10ms 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 10ms, 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 1ms, the upper limit time length is changed to 10ms - 1ms = 9ms. If the duration for which the first vehicle control task 111 uses the first arithmetic processing unit 2 is 9ms 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] <Subtraction of the maximum time length in the second scheduler 106> The deduction of the upper limit time length by the second scheduler 106 is the same as the deduction of the upper limit 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 exceed the upper limit time limit and use the first arithmetic processing unit 2, the first scheduler 104 will either stop or degrade applications 141 and 142. Therefore, even if applications 141 and 142 exceed the upper limit time limit and use the first arithmetic processing unit 2, 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 now be described. The difference from the second embodiment is that a total upper limit time length for which 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, when a subsequent task is set, indicates whether or not to set the total upper limit time length by using the total time that the current task and the subsequent task use the second arithmetic processing unit 3 and the third arithmetic processing unit 4 together.

[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 combination 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—to use the second arithmetic processing unit 3 and the third arithmetic processing unit 4 does not exceed the total upper limit time.

[0103] <Second Scheduler 106> In this embodiment, the second scheduler 106, if 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 from the time the preceding task starts to the time the subsequent task starts (deadline) as the upper limit time.

[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 20ms, which is before the time the third vehicle control task 113 is first started. Therefore, the deadline for the third vehicle control task 113 is 20 + 50 = 70ms, 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 = 45ms.

[0106] <Timing chart when summing the maximum time duration> Figure 15 is a timing chart showing 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=14ms. The third vehicle control task 113 completes processing at time 68ms. Since the third vehicle control task 113 was started at time 56ms, the third vehicle control task 113 used the second arithmetic processing unit 3 and the third arithmetic processing unit 4 for 68-56=12ms.

[0108] The 12ms during which the third vehicle control task 113 used the second processing unit 3 and the third processing unit 4 is less than the 14ms limit on the maximum time 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 completes its processing before the second communication task 122 is activated at time 70ms. 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 70ms 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 had 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 that the second vehicle control task 112 and the third vehicle control task 113 use the second arithmetic processing unit 3 and the third arithmetic processing unit 4. 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 56ms, 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, for example, by 10ms and started at time 60ms. This requires delaying the time when the second communication task 122 transmits the target trajectory data from 70ms to 80ms.

[0111] However, this means that the time lag between when the camera detects an obstacle and when 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 some 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 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. Therefore, it has the effect of preventing the stopping and degradation of the second vehicle control task 112, the third vehicle control task 113 and the vehicle control device 1 due to exceeding the upper limit time, which is 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 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 now be described. The difference between this embodiment and Embodiment 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 Examples 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 instead of constantly reading the first processing interruption time length 132, it does not use the resources of the first arithmetic processing unit 2 when it is in an event waiting state. The first time correction unit 134 is released from waiting state when it receives a time correction notification from the first operating system 103, 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 disables 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 instead of constantly reading the second processing interruption time length 136, 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, 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 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. [Explanation of Symbols]

[0129] 1. Vehicle control system 2. First arithmetic processing unit 3. Second arithmetic processing unit 4. Third processing unit 5 memory 6 Communication Peripherals 100 Hypervisors 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 Monitoring Unit 132 First processing interruption time length 133 First storage unit (shared memory) 134 First time correction unit 135 Second Interruption Time Monitoring Unit 136 Second processing interruption time 137 Second storage unit (shared memory) 138 Second time correction unit 141, 142, 143, 144, 145 Applications 151,152 Startup Process 161,162,163,164,165 child processes 170,171,172 internal time 180 Process Scheduling Records 201 First scheduling table 202 Second Scheduling Table 300 vehicles

Claims

1. Hypervisor and The virtual machine launched by the aforementioned hypervisor, Equipped with, The virtual machine includes an application and a scheduler for launching the application. It has, The hypervisor, the scheduler, and the application are a vehicle control device whose calculations are performed by one or more processing units, An interruption time monitoring unit monitors the length of time the application processing on the virtual machine is interrupted by the hypervisor. A storage unit that stores the processing interruption time length monitored by the interruption time length monitoring unit, Equipped with, The vehicle control device is characterized in that the scheduler starts the application based on a time corrected using the processing interruption time length stored in the storage unit.

2. A vehicle control device according to claim 1, The maximum time limit for which the processing unit can be used for the aforementioned application is determined in advance. The vehicle control device is characterized in that, if the processing of the application is interrupted by the hypervisor during processing, the scheduler shortens the upper limit time for the interrupted application using the processing interruption time length stored in the storage unit.

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

4. A vehicle control device according to claim 2, When the two applications of the virtual machine use the arithmetic processing unit in succession, The total maximum time limit for which the arithmetic processing unit can be used is predetermined, when a preceding task is configured for the preceding application that uses the arithmetic processing unit first among two applications that use the arithmetic processing unit consecutively, and a succeeding task is configured for the succeeding application that uses the arithmetic processing unit second among two applications that use the arithmetic processing unit consecutively. The aforementioned prior application has a defined startup start time, The aforementioned scheduler, If the corrected time matches the startup start time, the preceding application is started. The subsequent application is launched after the processing of the preceding application is completed. A vehicle control device characterized by monitoring whether the total time that the preceding application and the succeeding application use the processing unit exceeds the total upper limit time.

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

6. In the vehicle control device according to claim 5, The virtual machine has a time correction unit, which is a different startup process from the scheduler. The vehicle control device is characterized in that 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. In the vehicle control device according to claim 6, The interruption time monitoring unit sends a time correction notification to the time correction unit when the processing interruption time of the application on the virtual machine exceeds a threshold. A vehicle control device characterized in that, 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 length.

Images