VEHICLE CONTROL DEVICE AND VEHICLE CONTROL METHOD

Abstract

A vehicle control unit is a vehicle control unit with a hypervisor capable of implementing multiple virtual machines, wherein the multiple virtual machines include a virtual management machine that manages communication between virtual machines, and a group of virtual machines, which is a virtual machine whose communication is managed by the virtual management machine, wherein the hypervisor includes a first shared memory that stores transmission data output by any virtual machine of the group of virtual machines, and a second shared memory that stores transmission data input into any virtual machine of the group of virtual machines, wherein a communication start time and a communication end time are determined for all transmission data, wherein a virtual machine,a sending source of the transmission data, which stores the transmission data in the first shared memory at a time before the communication start time of the transmission data, the virtual management machine reads the transmission data from the first shared memory at the communication start time and stores the transmission data in the second shared memory at the communication end time, and a virtual machine which is a receiving destination of the transmission data, which reads the transmission data from the second shared memory at a time after the communication end time.

Description

Technical field

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

[0002] With the increasing development and complexity of vehicle control, embodied by automated driving, the integration of vehicle control units and the continuous improvement of the vehicle control software installed within these units are essential. Accordingly, the automotive industry is shifting from a traditional distributed architecture, where a separate vehicle control unit is installed for each sensor or actuator, to a centralized zone architecture, where multiple high-performance vehicle control units are installed and integrated.When transitioning to a centralized zone architecture, it is crucial to ensure mutual interference-free operation between the components of the vehicle control software, as the software, traditionally installed on different vehicle control units, is now installed on the same unit. Therefore, attention was paid to implementing a hypervisor, a virtualization technology, within the vehicle control unit. This hypervisor enables secure hardware sharing through methods such as exclusive control or time allocation for hardware resources. This separation of hardware resources used by each component of the vehicle control software is achieved by separating those shared and used by multiple components.

[0003] PTL 1 discloses a virtualization system in which multiple virtual computers are run on a physical computer with multiple cores, wherein the virtualization system includes: multiple hardware components; a hardware control core, which is the core for controlling the operation of each of the multiple hardware components; multiple virtual computer cores, which are the cores to enable the operation of a guest operating system, which is an operating system of the virtual computer; and a shared memory, which is memory that can be accessed simultaneously and in parallel by each of the hardware control cores and the multiple virtual computer cores, wherein one virtual computer is configured to operate while occupying one or more of the virtual computer cores, and wherein the hardware control core includes a device driver unit.which controls the operation of each of the multiple hardware components by executing a device driver according to each of the multiple hardware components, the communication between the hardware control kernel and the virtual computer kernel is realized by storing data in the shared memory and reading the stored data, and the device driver unit controls the operation of the hardware based on the data stored by the virtual computer in the shared memory and stores data fed in by the hardware in the shared memory in order to make the data available to the virtual computer kernel. Citation list for patent literature

[0004] PTL 1: JP 2019-057162 A Overview of the invention Technical problem

[0005] The invention described in patent literature 1 requires further research to reduce the development costs of a vehicle control device equipped with several vehicle control software components using a hypervisor. Solution to the problem

[0006] A vehicle control device according to a first aspect of the present invention is a vehicle control device with a hypervisor capable of implementing multiple virtual machines, wherein the multiple virtual machines include a virtual management machine that manages communication between virtual machines and a group of virtual machines, the communication of which is managed by the virtual management machine. The hypervisor includes a first shared memory that stores transmission data output by any virtual machine of the group of virtual machines and a second shared memory that stores transmission data input into any virtual machine of the group of virtual machines.For all transmitted data, a communication start time and a communication end time are determined; a virtual machine, which is a sending source of the transmitted data, stores the transmitted data in the first shared memory at a time before the communication start time of the transmitted data; the virtual management machine reads the transmitted data from the first shared memory at the communication start time and stores the transmitted data in the second shared memory at the communication end time; and a virtual machine, which is a receiving destination of the transmitted data, reads the transmitted data from the second shared memory at a time after the communication end time.

[0007] A vehicle control method according to a second aspect of the present invention is a vehicle control method carried out by a vehicle control device with a hypervisor capable of realizing multiple virtual machines, wherein the multiple virtual machines include a virtual management machine that manages the communication between the virtual machines, and a group of virtual machines, the communication of which is managed by the virtual management machine, and the hypervisor includes a first shared memory that stores transmission data output by any virtual machine of the group of virtual machines, and a second shared memory that stores transmission data input into any virtual machine of the group of virtual machines.wherein a communication start time and a communication end time are determined for each part of the transmission data and the vehicle control procedure includes: storing the transmission data by a virtual machine, which is a sending source of the transmission data, at a time before the communication start time of the transmission data in the first shared memory; reading the transmission data from the first shared memory at the communication start time by the virtual management machine and storing the transmission data in the second shared memory at the communication end time; and reading the transmission data from the second shared memory by a virtual machine, which is a receiving destination of the transmission data, at a time after the communication end time. Advantageous effects of the invention

[0008] According to the present invention, the development costs of a vehicle control device equipped with several vehicle control software components can be reduced by using a hypervisor. Brief description of the drawings [ Fig. 1] Fig. Figure 1 is a hardware configuration diagram of a vehicle control unit according to a first embodiment. [ Fig. 2] Fig. Figure 2 is a software configuration diagram of the vehicle control unit according to the first embodiment. [ Fig. 3] Fig. Figure 3 is a diagram illustrating the reception of a time notification from each timer in a first CPU. [ Fig. 4] Fig. Figure 4 is a diagram illustrating the presence or absence of receiving a time notification from each timer in each CPU according to the first embodiment. [ Fig. 5] Fig. Figure 5 is a diagram illustrating an example of time window partitioning by a hypervisor. [ Fig. 6] Fig. 6 is a diagram that shows time slot allocation information in the case of Fig. 5 illustrates. [ Fig. 7] Fig. Figure 7 is a diagram illustrating an example of waiting for time slot allocation. [ Fig. 8] Fig. Figure 8 is a diagram illustrating a data flow from a first vehicle control application to a second vehicle control application installed on different facilities. [ Fig. 9] Fig. Figure 9 is a diagram illustrating a data flow from a first vehicle control application to a second vehicle control application installed on the same equipment. [ Fig. 10] Fig. Figure 10 is a diagram illustrating an example where the time allocation is fixed. [ Fig. 11] Fig. Figure 11 is a diagram illustrating the transmission of data from the first vehicle control application to the second vehicle control application. [ Fig. 12] Fig. Figure 12 is a diagram illustrating shared storage settings. [ Fig. 13] Fig. 13 is a pseudocode that defines the processing content of a communication management application accordingly Fig. 10 illustrated. [ Fig. 14] Fig. Figure 14 is a diagram illustrating the time available for reading. [ Fig. 15] Fig. Figure 15 is a diagram illustrating the time available for writing. [ Fig. 16] Fig. Figure 16 is a diagram illustrating the effect of setting a communication time schedule. [ Fig. 17] Fig. Figure 17 is a hardware configuration diagram of a vehicle control unit according to a second embodiment. [ Fig. 18] Fig. Figure 18 is a software configuration diagram of the vehicle control unit according to the second embodiment. [ Fig. 19] Fig. Figure 19 is a diagram illustrating the presence or absence of receiving a time notification from each timer in each CPU according to the second embodiment. [ Fig. 20] Fig. Figure 20 is a configuration diagram of a vehicle according to a third embodiment. [ Fig. 21] Fig. Figure 21 is a software configuration diagram of a vehicle control unit according to the third embodiment. [ Fig. 22] Fig. Figure 22 is a software configuration diagram of a second vehicle control unit. [ Fig. 23] Fig. Figure 23 is a diagram illustrating an example where the time division is fixed according to the third embodiment. [ Fig. 24] Fig. Figure 24 is a diagram illustrating setting information of the shared memory of the vehicle control unit. [ Fig. 25] Fig. 25 is a pseudocode that specifies the processing content of the communication management application. [ Fig. 26] Fig. Figure 26 is a diagram illustrating setting information of the shared memory of the second vehicle control unit. [ Fig. 27] Fig. 27 is a pseudocode that specifies the processing content of the second communication management application. [ Fig. 28] Fig. Figure 28 is a hardware configuration diagram of a vehicle control device according to a fourth embodiment. [ Fig. 29] Fig. Figure 29 is a software configuration diagram of a vehicle control device according to a fifth embodiment. Description of the embodiments-First embodiment-

[0009] The following describes a first embodiment of a vehicle control device and a vehicle control method with reference to the Fig. 1 to 16 described. <Fahrzeugsteuerungseinrichtung 500>

[0010] Fig. Figure 1 is a hardware configuration diagram of a vehicle control unit 500. The vehicle control unit 500 contains a first CPU 1, a second CPU 2, a third CPU 3, a fourth CPU 4, a fifth CPU 5, a memory 6, a first timer 7, a second timer 8, a third timer 9, a fourth timer 10, a fifth timer 11, and a sixth timer 12. Each CPU from the first CPU 1 to the fifth CPU 5 is a central processing unit. Each CPU from the first CPU 1 to the fifth CPU 5 can be a physically independent CPU or it can be another processing core within the same CPU. Each CPU from the first CPU 1 to the fifth CPU 5 develops and executes a program stored in a ROM (not shown) in memory 6. Each timer from the first timer 7 to the sixth timer 12 is time-measuring hardware. The vehicle control unit 500 is, for example, an electronic control unit (ECU).

[0011] Fig. Figure 2 is a software configuration diagram of the vehicle control unit 500. A first virtual machine 101, a second virtual machine 102, a third virtual machine 103, a fourth virtual machine 104, and a fifth virtual machine 105 are configured on the hypervisor 100. The first virtual machine 101 is run by the first CPU 1, the second virtual machine 102 is run by the second CPU 2, the third virtual machine 103 is run by the third CPU 3 and the fourth CPU 4, and the fourth virtual machine 104 and the fifth virtual machine 105 are run by the fifth CPU 5. Hereinafter, the first virtual machine 101 is also referred to as the "virtual management machine." The second virtual machine 102 through the fifth virtual machine 105 are also referred to as the "group of virtual machines."

[0012] The first virtual machine 101 contains a first operating system (OS) 106 and a communications management application 111. The second virtual machine 102 contains a second OS 107 and a first vehicle control application 112. The third virtual machine 103 contains a third OS 108 and a second vehicle control application 113. The fourth virtual machine 104 contains a fourth OS 109 and a third vehicle control application 114. The fifth virtual machine 105 contains a fifth OS 110 and a fourth vehicle control application 115. The first vehicle control application 112 through the fourth vehicle control application 115 perform some calculation related to controlling the vehicle on which the vehicle control device 500 is mounted and send a calculation result to another control application.In the following, data exchanged between vehicle control applications is referred to as "transmission data." As described later, the Communications Management Application 111 manages the transmission data. The transmission data can consist of a single piece of data or multiple data segments. The size of the transmission data is not particularly limited and can be, for example, 1 byte or 1 MB or more. <timer>

[0013] Each timer, from the first timer 7 to the sixth timer 12, has a function to inform the CPU about the time. For each timer, it is predetermined which CPU will be informed of the time. In the present embodiment, the first timer 7 is used for hypervisor 100, the second timer 8 is used for the first OS 106, the third timer 9 is used for the second OS 107, the fourth timer 10 is used for the third OS 108, the fifth timer 11 is used for the fourth OS 109, and the sixth timer 12 is used for the fifth OS 110.

[0014] Fig. Figure 3 is a diagram illustrating the reception of a time notification from a timer in the first CPU 1. Each CPU contains a notification receiver that receives a time notification from each timer. As shown in Fig. As shown in Figure 2, the first CPU 1 runs a hypervisor 100 and a first virtual machine 101, and the first virtual machine 101 contains a first OS 106. Therefore, the first CPU 1 must receive a time notification from the first timer 7 for the hypervisor 100 and must receive a time notification from the second timer 8 for the first OS 106. The first CPU 1 does not receive time notifications from any timers other than the first timer 7 and the second timer 8. Therefore, as shown in Figure 2, the first CPU 1 must receive a time notification from the first timer 7 and the second timer 8. Fig. As shown in Figure 3, in the first CPU 1, time notifications from timers other than the first timer 7 and the second timer 8 were declared invalid.

[0015] Fig. Figure 4 is a diagram showing the presence or absence of a time notification being received from a timer in each CPU. Fig. 4 indicates "YES" for the combination that receives the time notification, and "NO" for the combination that does not receive the time notification. The second CPU 2 runs a hypervisor 100 and a second virtual machine 102, and the second virtual machine 102 contains a second OS 107. Therefore, the second CPU 2 must receive a time notification from the first timer 7 for the hypervisor 100, must receive a time notification from the third timer 9 for the second OS 107, and does not receive a time notification from any other timers.

[0016] The third CPU 3 and the fourth CPU 4 are running a hypervisor 100 and a third virtual machine 103, where the third virtual machine 103 contains a third OS 108. Therefore, the third CPU 3 and the fourth CPU 4 must receive a time notification from the first timer 7 for the hypervisor 100, must receive a time notification from the fourth timer 10 for the third OS 108, and do not receive a time notification from any other timers.

[0017] The fifth CPU, 5, runs a hypervisor 100, a fourth virtual machine 104, and a fifth virtual machine 105. The fourth virtual machine 104 contains a fourth OS 109, and the fifth virtual machine 105 contains a fifth OS 110. Therefore, the fifth CPU 5 must receive a time notification from the first timer 7 for the hypervisor 100 and a time notification from the fifth timer 11 for the fourth OS 109. Furthermore, the fifth CPU 5 must receive a time notification from the sixth timer 12 for the fifth OS 110 and does not receive time notifications from any other timers. <hypervisor>

[0018] The role and operation of Hypervisor 100 are described. Hypervisor 100 configures a virtual machine and provides an environment that is logically equivalent to a situation where software exists both inside the same vehicle control unit 500 and outside the virtual machine in a different vehicle control unit, as viewed from the perspective of the software in the virtual machine. This equivalent environment is achieved through spatial and temporal separation. Spatial separation serves to isolate the use of hardware, such as memory allocation. Temporal separation serves to separate points in time so that multiple virtual machines do not use shared hardware simultaneously.

[0019] Hypervisor 100 has higher operational authority than any other software. Hypervisor 100 separates the hardware resources actually used by each virtual machine. However, for hardware resources shared by multiple virtual machines, a time window is defined to prevent multiple virtual machines from accessing the hardware resource simultaneously and causing undefined operation. During each time window, the hardware resource is used by only one previously designated virtual machine.

[0020] Regarding hardware resource separation, the hypervisor prevents access if each CPU attempts to access a memory area other than one allocated to that CPU. In the Fig. In the situation shown in Figure 2, for example, the second CPU 2 can access an area allocated to the second virtual machine 102 in memory 6, but cannot access an area allocated to the third virtual machine 103.

[0021] In the present embodiment, memory access monitoring is performed by a memory protection unit integrated into the CPU. Processing by the Hypervisor 100 occurs after the memory protection unit detects the memory access violation and executes an operation to halt the virtual machine that caused the violation. If the memory protection unit does not detect a memory access violation, the Hypervisor 100 performs no processing.

[0022] Therefore, in a case where a CPU is assigned only one virtual machine (referred to here as an "independent execution virtual machine") and the independent execution virtual machine does not share any hardware resources with other virtual machines, the following applies. That is, as long as the independent execution virtual machine does not cause a memory access violation, the application in the independent execution virtual machine behaves in the same way as if the application were running directly on the hardware resource of the vehicle control unit 500 and not via the hypervisor 100. In the case of Fig. In section 2, the first virtual machine 101, the second virtual machine 102, and the third virtual machine 103 correspond to the independently executed virtual machines described above. The first OS 106 is always executed by the first CPU 1, the second OS 107 is always executed by the second CPU 2, and the third OS 108 is always executed by the third CPU 3 and the fourth CPU 4.

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

[0024] On the other hand, the fourth virtual machine 104 and the fifth virtual machine 105 are both running on the fifth CPU 5. In this case, the hypervisor 100 uses the time window so that the fourth virtual machine 104 and the fifth virtual machine 105 do not run simultaneously. The execution times of the fourth virtual machine 104 and the fifth virtual machine 105 are determined with reference to the Fig. 5 and Fig. 6 described.

[0025] Fig. Figure 5 is a diagram illustrating an example of time-window allocation by Hypervisor 100. Hypervisor 100 switches the virtual machine running on the fifth CPU 5 every 1 ms. The first 1 ms after Hypervisor 100 is activated is a time window in which the fifth CPU 5 runs the fourth virtual machine 104. The next 1 ms is a time window for running the fifth virtual machine 105. The following 1 ms is a time window for running the fourth virtual machine 104 again.

[0026] In Fig. The time window for running the fourth virtual machine 104 is designated "WT4", and the time window for running the fifth virtual machine 105 is designated "WT5". In this way, the hypervisor 100 periodically assigns a time window to each virtual machine for the fifth CPU 5. This allocation procedure is determined in advance, before the virtual machine is activated, is described as Time Window Allocation Information 1000, and is stored in the hypervisor 100.

[0027] Fig. Figure 6 is a diagram showing the time slot allocation information 1000 in the case of Fig. Figure 5 illustrates this. The time slot allocation information 1000 contains a time slot number to identify each time slot, a time slot width, and information about a virtual machine running on the fifth CPU 5 in the time slot. In the present embodiment, the time widths of all time slots are 1 ms and are the same, but the time widths can be different for each time slot.

[0028] Hypervisor 100 receives a time notification from the first timer 7 and, at time 0, assigns a time slot with a time slot number 1, which is contained in the time slot assignment information 1000. Subsequently, when it receives a time notification with a time of 1 ms from the first timer 7, Hypervisor 100 interrupts the execution of the fourth virtual machine 104 by the fifth CPU 5 and starts the execution of the fifth virtual machine 105. Furthermore, when it receives a time notification with a time of 2 ms from the first timer 7, Hypervisor 100 interrupts the execution of the fifth virtual machine 105, returns to the beginning to reach the end of the time slot assignment information 1000, resets the time slot number to "1", and starts the execution of the fourth virtual machine 104.In this way, the fourth virtual machine 104 and the fifth virtual machine 105 are executed alternately by the fifth CPU 5 every 1 ms. <Verarbeitungszeiteinteilungsabweichung aufgrund des Wartens auf die Zeitfensterzuweisung>

[0029] Fig. Figure 7 is a diagram illustrating an example of waiting for time slot allocation. In the present embodiment, waiting for a time slot can occur at the fourth virtual machine 104 and the fifth virtual machine 105, which share the fifth CPU 5. The fourth virtual machine 104 and the fifth virtual machine 105 each contain a third vehicle control application 114 and a fourth vehicle control application 115, respectively, which are to be processed in a 5 ms cycle. The fourth OS 109, installed on the fourth virtual machine 104, sets the fifth timer 11 when it is first activated by the hypervisor 100. Thereafter, the fifth timer 11 notifies the fifth CPU 5 of the time every 5 ms from the set time.

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

[0031] Upon confirmation of receipt of the time notification from the sixth timer 12, the fifth OS 110 determines that the fourth vehicle control application 115 should be executed and starts the fourth vehicle control application 115. As described in the Fig. 5 and Fig. As shown in Figure 6, hypervisor 100 assigns the first 1 ms to the fourth virtual machine 104 and the next 1 ms to the fifth virtual machine 105. Fig. 7 is a time zone in which each virtual machine is not running, indicated by dot hatching. Specifically, the time zone in which the fourth virtual machine 104 is not running is a time zone between 1 ms and 2 ms, between 3 ms and 4 ms, between 5 ms and 6 ms, or the like. A time zone in which the fifth virtual machine 105 is not running is the opposite of that of the fourth virtual machine 104 and is a time zone such as 0 ms to 1 ms and 2 ms to 3 ms.

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

[0033] Therefore, the third vehicle control application, 114, begins processing at time 6 ms. As described above, the application's processing time allocation can vary due to waiting for the time window allocation. Next, the fifth timer, 11, reports the time at 10 ms. Since the fourth virtual machine, 104, has a time window allocated between 10 ms and 11 ms, the fourth OS, 109, acknowledges the time notification from the fifth timer, 11, and immediately starts processing the third vehicle control application, 114. The same applies to the fifth virtual machine, 105. As described above, in a case where the CPU is shared by multiple virtual machines, the hypervisor, 100, changes the application's processing time allocation due to waiting for the time window allocation. <Latenzschwankung vor und nach der Integration>

[0034] The Hypervisor 100 is used to install vehicle control software, which is conventionally installed on different vehicle control units, on the same vehicle control unit.

[0035] Fig. Figure 8 is a diagram illustrating a data flow from the first vehicle control application 112 to the second vehicle control application 113, which, as in the conventional configuration, are installed on different devices. In this conventional configuration, the first vehicle control application 112 is installed on the first vehicle control device 13 prior to integration, and the second vehicle control application 113 is installed on the second vehicle control device 14 prior to integration. The first vehicle control device 13 prior to integration and the second vehicle control device 14 prior to integration are connected by a communication bus 118. The communication bus 118 uses, for example, a well-known communication protocol such as a Controller Area Network (CAN) or IEEE 802.3.

[0036] Both the first vehicle control application 112 and the second vehicle control application 113 are executed every 10 ms. Since the second vehicle control application 113 performs processing using the processing result of the first vehicle control application 112, the second vehicle control application 113 must receive the processing result from the first vehicle control application 112 via the communication bus 118. The first vehicle control unit 13, prior to integration, contains a first communication driver 116. The first communication driver 116 can be executed by a CPU core different from that of the first vehicle control application 112. The first communication driver 116 is also started every 10 ms, and the first communication driver 116 stores the latest processing result of the first vehicle control application 112, for example, in a packet and sends the packet to the communication bus 118.

[0037] The second vehicle control unit 14, prior to integration, contains a second communication driver 117. The second communication driver 117 can be executed by a CPU core different from that of the second vehicle control application 113. When the packet arrives, the second communication driver 117 extracts data from the packet and stores the extracted data in a receive port prepared for the second vehicle control application 113. The second vehicle control application 113 is started every 10 ms and extracts data stored in the receive port for processing. Therefore, as described below, Fig. Figure 8 shows the time (latency) from the start of processing of the first vehicle control application 112 to the end of processing of the second vehicle control application 113 using the processing result slightly less than 30 ms.

[0038] Fig. Figure 9 is a diagram illustrating a data flow from the first vehicle control application 112 to the second vehicle control application 113 when the first vehicle control application 112 and the second vehicle control application 113 are installed on the same vehicle control unit 500, as in the present embodiment. However, the data transmission / receive timing in this drawing differs from that of the present embodiment. When the first vehicle control application 112 and the second vehicle control application 113 are integrated using the hypervisor 100 and installed on the same vehicle control unit 500, a shared memory 119 is used for data exchange. The applications and the operating system in the second virtual machine 102 and the third virtual machine 103 can access the shared memory 119.In this case, the second vehicle control application 113 can be used, unlike the one in . Fig. In the example shown in Figure 8, the data can be accessed immediately after the first vehicle control application 112 has stored the data in the shared memory 119, since the data is not transmitted via the communication bus 118.

[0039] Therefore, if the first vehicle control application 112 and the second vehicle control application 113 are started every 10 ms, as shown in the lower part of Fig. As shown in Figure 9, the time (latency) from the start of processing by the first vehicle control application 112 to the end of processing by the second vehicle control application 113, using the processing result, is slightly less than 20 ms. This is about 10 ms shorter than in the case of Fig. 8. Therefore, it can be said that Fig. Figure 9 illustrates that the latency is reduced without any special ingenuity when the vehicle control software, which is conventionally installed on different vehicle control units, is installed on the same vehicle control unit. Due to the reduction in latency, the processing result of the first vehicle control application 112, referenced by the second vehicle control application 113, can be advanced by one cycle, and the processing result can change both before and after the integration. <Festsetzung der Kommunikationszeiteinteilung zwischen virtuellen Maschinen>

[0040] As in Fig. As shown in Figure 7, in a case where multiple virtual machines share the same CPU, the processing time allocation varies due to waiting for the hypervisor to allocate a time slot 100 times. Furthermore, as shown in the Fig. 8 and Fig. Figure 9 shows that communication between the vehicle control units is replaced by memory sharing, which represents the communication at the vehicle control unit, resulting in variable latency. It requires considerable effort to verify that these fluctuations do not affect the vehicle's operation.

[0041] Therefore, in the present embodiment, the timing of the start of communication between virtual machines (hereinafter referred to as the "communication start time schedule" or "communication start time") and the timing of the end of communication (hereinafter referred to as the "communication end time schedule" or "communication end time") are predetermined. By predetermining the timing of the start and end of communication between the virtual machines, it is possible to ensure that the vehicle control unit 500 operates normally when the following two conditions are met. The first condition is that each virtual machine stores data in the shared memory before the predetermined communication start time. The second condition is that data is read from the shared memory after the predetermined communication end time.As a result, the verification area is localized from the entire vehicle control unit 500 to each individual virtual machine.

[0042] Fig. Figure 10 is a diagram illustrating an example where the communication time schedule is fixed. In the drawing, the same hatching indicates that the data exchange relationship is established. A case in which the processing result of the first vehicle control application 112 is delivered to the second vehicle control application 113 is described with reference to Fig. As described in section 10, the first vehicle control application 112 and the second vehicle control application 113 are executed every 10 ms starting from time 0 ms. The time to start transmitting the processing result from the first vehicle control application 112 to the second vehicle control application 113 is defined as the time at which the first vehicle control application 112 is next started. For example, the transmission of a processing result from a process that started at time 0 ms is started at 10 ms, and the transmission of a processing result from a process that started at time 10 ms is started at 20 ms.

[0043] Then, the time at which the processing result reaches the second vehicle control application 113, that is, the communication end time, is the time after the communication start time and at which the second vehicle control application 113 is next started. For example, if communication starts at time 10 ms, communication ends at time 20 ms, and if communication starts at time 20 ms, communication ends at time 30 ms. Consequently, the latency from the start of processing by the first vehicle control application 112 to the end of processing by the second vehicle control application 113 is slightly less than 30 ms, and no latency fluctuation occurs as described in [reference missing]. Fig. 8 up.

[0044] By setting the communication start and end times in this way, the latency can be reduced to slightly less than 30 ms, as in Fig. 8 will be set if the first vehicle control application 112 has completed processing before the start of the communication start time, that is, within 10 ms after it has started. As described above, the time at which the transmission of the processing result of the first vehicle control application 112 is started is set to the time at which the first vehicle control application 112 is next started, but the maximum goal is to make the latency essentially equal to that in Fig. 8 to generate. The determination of the timing is also based on the assumed knowledge that the execution time of each application should be shorter than the execution cycle of each application.

[0045] Similarly, with reference to Fig. Figure 10 describes a case in which the processing result of the third vehicle control application 114 is delivered to the second vehicle control application 113. The third vehicle control application 114 and the fourth vehicle control application 115 are executed at 5 ms intervals, starting from time 0 ms. The transmission of the processing results of the third vehicle control application 114 and the fourth vehicle control application 115 is initiated at the time each of them is scheduled to execute next. The communication end time is after the communication start time and is the time when the second vehicle control application 113 is scheduled to start next. However, while the second vehicle control application 113 executes with a cycle of 10 ms, the third vehicle control application 114 and the fourth vehicle control application 115 execute twice as frequently, with a cycle of 5 ms.

[0046] Therefore, for example, the following two processing results from the third vehicle control application 114 and the fourth vehicle control application 115, which are used by the second vehicle control application 113, whose processing is currently starting at 20 ms, are candidates. The first candidate is the processing results from the third vehicle control application 114 and the fourth vehicle control application 115, which started processing at 10 ms. The second candidate is the processing results from the third vehicle control application 114 and the fourth vehicle control application 115, which started processing at 15 ms.

[0047] The processing result to be adopted is determined based on whether it is closer to the data flow before integration. This determination, that is, the communication start time and communication end time, can be made by a person who is a designer, or it can be partially or completely replaced by automated processing. In the example shown in this drawing, the processing results of the third vehicle control application 114 and the fourth vehicle control application 115, which started processing 10 ms ago, are used by the second vehicle control application 113, which starts processing 20 ms ago.

[0048] In this case, the processing results of the third vehicle control application 114 and the fourth vehicle control application 115 can be transmitted at 5 ms and 15 ms, respectively, or the application execution itself can be omitted. When these processing results are transmitted, a value written to shared memory as a transmission result is not read by the second vehicle control application 113, because a new value is written to shared memory until the second vehicle control application 113 reads the value next. In this way, the latency can be set to slightly less than 20 ms, regardless of whether the hypervisor 100 waits for the time slot allocation or not, if the third vehicle control application 114 completes processing before the start of the communication start time, that is, within 5 ms of start.

[0049] The following describes a procedure for implementing the setting of the start and end times of communication between virtual machines, as in Fig. 10 illustrated, described. As in the Fig. As shown in Figures 7 to 9, if communication between virtual machines is performed directly, fluctuations in latency due to waiting for time slot allocation or a change in the communication path cannot be avoided. Therefore, the first virtual machine 101 is instructed to occupy the first CPU 1, whereby the first virtual machine 101 is not installed with the vehicle control application but with the communication management application 111, and all communication between virtual machines, i.e., the shared memory usage, is carried out via the first virtual machine 101.

[0050] Fig. Figure 11 is a diagram illustrating the transmission of data from the first vehicle control application 112 to the second vehicle control application 113. In particular, Fig. Figure 11 shows a diagram illustrating a method in which the first vehicle control application 112 of the second virtual machine 102 sends data from the first virtual machine 101 to the second vehicle control application 113 of the third virtual machine 103 via the communication management application 111. In the present embodiment, a first shared memory 120 and a second shared memory 121 are provided for all data to be sent and received between the virtual machines. The first shared memory 120 is a memory shared by the data sending source and the communication management application 111, and the second shared memory 121 is a memory shared by the communication management application 111 and the data receiving destination.Since the sending source application uses the first shared memory 120 for data transmission, the first shared memory can also be referred to as the "shared send memory." Since the receiving destination application uses the second shared memory 121 for data reception, the second shared memory can also be referred to as the "shared receive memory."

[0051] At the in Fig. In the example shown, the first shared memory 120 is shared by the first vehicle control application 112 of the second virtual machine 102 and the communication management application 111, and the second shared memory 121 is shared by the communication management application 111 and the second vehicle control application 113 of the third virtual machine 103. The first shared memory 120 is configured to be writable by a data transmission source and readable by the communication management application 111. The second shared memory 121 is configured to be writable by the communication management application 111 and readable by the second vehicle control application 113 of the third virtual machine 103.Similarly, the first shared memory 120 and the second shared memory 121 are intended for data sent from the third vehicle control application 114 of the fourth virtual machine 104 to the second vehicle control application 113, and for data sent from the fourth vehicle control application 115 of the fifth virtual machine 105 to the second vehicle control application 113, respectively.

[0052] Fig. Figure 12 is a diagram illustrating shared memory configuration information 1001. Shared memory configuration information 1001 includes the address of the memory shared by multiple virtual machines, the read / write permissions of each virtual machine, and the identifier of each shared memory location. The hypervisor 100 configures the shared memory according to shared memory configuration information 1001. Shared memory ID "1" is the first shared memory location 120, which is shared by the first vehicle control application 112, the second virtual machine 102, and the communication management application 111.The shared memory ID “2” is the second shared memory 121, which is shared by the communication management application 111 of the first virtual machine 101 and the second vehicle control application 113 of the third virtual machine 103.

[0053] Shared memory ID "3" is the first shared memory 120, shared by the third vehicle control application 114, the fourth virtual machine 104, and the communication management application 111. Shared memory ID "4" is the second shared memory 121, shared by the communication management application 111, the first virtual machine 101, and the second vehicle control application 113, the third virtual machine 103. Shared memory ID "5" is the first shared memory 120, shared by the first vehicle control application 112, the fifth virtual machine 105, and the communication management application 111.The shared memory ID “6” is the second shared memory 121, which is shared by the communication management application 111 of the first virtual machine 101 and the second vehicle control application 113 of the third virtual machine 103.

[0054] Fig. 13 is a pseudocode that represents the processing content of the communication management application 111 accordingly. Fig. 10 illustrates the processing content of the communication management application 111 at any given time according to the description of Fig. 10 is as follows. In the following description, however, "n" represents an integer. The time (10*n) ms is the communication start time of the data from the first vehicle control application 112. The time (10*(n-1)) ms is the time at which the data transmission of the data generated by the first vehicle control application 112 to the second vehicle control application 113 ends. The time (10*(n-1)) ms is the time at which the data transmission of the data generated by the third vehicle control application 114 to the second vehicle control application 113 ends.

[0055] The time (10*(n-1)) ms is the time at which the data transmission of the data generated by the fourth vehicle control application 115 to the second vehicle control application 113 ends. The time (10*n)+5 ms is the time at which the third vehicle control application 114 begins transmitting data generated immediately before (that is, if it is started at time (10*n) ms). Similarly, the time (10*n)+5 ms is the time at which the fourth vehicle control application 115 begins transmitting data generated immediately before (that is, if it is started at time (10*n) ms).

[0056] To implement the processing described above at all times, the communication management application 111 is started in a 5 ms cycle, and the processing content is changed for each number of starts. Fig. In section 13, this is implemented using the integer variable `counter`. Initially, `counter` is initialized to "0" as an initialization step. Furthermore, the communication management application `111` prepares variables for the temporary storage of data generated by the first vehicle control application `112`, the third vehicle control application `114`, and the fourth vehicle control application `115`. The communication management application `111` is implemented using a function `Com_Manage_App()`. To start on a 5 ms cycle, `Com_Manager_App()` is registered in `OS_Task(5 ms)`, which is a list of 5 ms cycle tasks, in the first `OS` (`106`).

[0057] The function Com_Manage_App() is started once every 5 ms by the first OS 106. The processing content of the function Com_Manage_App() changes depending on the number of starts. At the time of the first start of the function Com_Manage_App(), the variable counter has the initial value "0", and therefore the remainder after division by "2" is zero, and the condition "counter & 2 == 0" is satisfied. First, the shared memory ID "2, 4, 6" is accessed and data is written. The function Write is a function that takes a shared memory ID to be written as its first argument and data to be written as its second argument. This is the processing to complete the data transfer from the first vehicle control application 112, the third vehicle control application 114, and the fourth vehicle control application 115 to the second vehicle control application 113.

[0058] Next, shared memory ID "1" is accessed to read data. The "Read" function takes the shared memory ID to be read as its first argument and the address of the variable where the read data should be stored as its second argument. This is the processing required to start the data transfer from the first vehicle control application 112 to the second vehicle control application 113.

[0059] At the time of the second call to the Com_Manage_App() function, the process proceeds to the "else" condition, since the condition "counter & 2 == 0" described above is not met, and the shared memory ID "3, 5" is accessed to read data. This involves processing the initiation of data transmission from the third vehicle control application 114 and the fourth vehicle control application 115 to the second vehicle control application 113. On the third call to the Com_Manage_App() function, the condition "counter & 2 == 0" is met; on the fourth call, the "else" condition is met, and the processing is repeated in a similar manner.

[0060] Fig. Figure 14 is a diagram illustrating a read tolerance time to prevent access conflicts when receiving data from another virtual machine. The communication management application 111 writes data to the second shared memory 121 at the communication end time. If the communication end time and the application using the transmitted data start in the memory at the same time, access conflicts can occur, and the data may become unstable or corrupted. Therefore, the application reading data from the second shared memory 121 does not access it immediately after it starts, but rather after a certain period of time has elapsed. This elapsed time is called the "read tolerance time."

[0061] It is ensured that the communication management application 111 has written the data to the second shared memory 121 by accessing the second shared memory after the read tolerance time has elapsed following startup. The read tolerance time can be a time sufficient for the communication management application 111 to write data. Since the processing time of the vehicle control application varies depending on the vehicle environment and driving situation, it is generally not easy to set the optimal read tolerance time.However, since the communication management application 111 only reads and writes data to the shared memory, and the data to be read and written is predetermined by the shared memory's setting information 1001, the processing time required for reading and writing is constant, regardless of the vehicle environment and driving situation. In the present embodiment, the read tolerance time is set to "1 ms".

[0062] Fig. Figure 15 is a diagram illustrating a write tolerance time to prevent access conflicts when data is sent to another virtual machine. The communication management application 111 reads data from the first shared memory 120 at communication start time. However, there is some time between when the communication management application 111 is started by the first OS 106 at communication start time and when the communication management application accesses the first shared memory 120 to read data. If, during this time, the vehicle control application, which writes data to the first shared memory 120, saves a new processing result, data consistency will not be maintained.

[0063] In Fig. At time 10 ms, the communication management application 111 accesses the first shared memory 120 and reads data generated by the first vehicle control application 112, which started at time 0 ms. However, the data generated by the first vehicle control application 112, which started 10 ms earlier, is lost in the first shared memory 120. Therefore, if the processing is completed very quickly, the application writing data to the first shared memory 120 does not write the data immediately, but only after a certain period of time has elapsed. This elapsed time is called the "write tolerance time".

[0064] The application checks the time before writing, and if the write tolerance time has not elapsed since startup, the application waits until the write tolerance time has expired and then writes. Ensuring the write tolerance time guarantees that the communication management application 111 has read the data stored in the first shared memory 120 with the previous value. The write tolerance time can be any time sufficient for the communication management application 111 to read the data. Since the processing time of the vehicle control application is generally variable depending on the vehicle environment and driving situation, setting the optimal write tolerance time is not straightforward.

[0065] However, since the communication management application 111 only reads and writes data in the shared memory, and the data to be read and written is predetermined by the shared memory's setting information 1001, the processing time required for reading and writing is constant regardless of the vehicle environment and driving situation. In the present embodiment, the write tolerance time is set to "3 ms". Since the communication management application 111, as described in Fig. Figure 13 shows a process of reading the first shared memory 120 after writing to the second shared memory 121, and in the present embodiment the write tolerance time is set longer than the read tolerance time.

[0066] Fig. Figure 16 is a diagram illustrating the effect of setting the communication schedule by conducting communication through the communication management application 111. As shown in the upper part of Fig. As shown in Figure 16, the data generated by the first vehicle control application 112, if not processed by the communication management application 111, are used by the second vehicle control application 113 immediately after the data are stored, currently within 10 ms, resulting in a delay of one of the values ​​shown in Figure 16. Fig. The conventional case shown in Figure 8 leads to a different result. Furthermore, the communication start time is the time at which the processing of the first vehicle control application 112 is completed, and the first vehicle control application 112 cannot determine the communication start time because the processing time varies depending on the vehicle environment and driving situation.

[0067] On the other hand, the communication start time and communication end time vary, as shown in the lower part of Fig. Figure 16 shows that this does not occur in the case of the communication management application 111, even if the time at which the processing of the first vehicle control application 112 is completed varies. This is because the communication start time is the time at which the communication management application 111 reads the processing result of the first vehicle control application 112 into the first shared memory 120. This is because the communication end time is the time at which the communication management application 111 writes data to the second shared memory 121. As described above, the communication start and end times can be fixed.

[0068] According to the first embodiment described above, the following operational effects can be achieved. (1) The vehicle control unit 500 includes a hypervisor 100 capable of implementing multiple virtual machines, from the first virtual machine 101 to the fifth virtual machine 105. The first virtual machine 101 manages communication between virtual machines. Communication between the second virtual machine 102 and the fifth virtual machine 105, i.e., the group of virtual machines, is managed by the first virtual machine 101. The hypervisor 100 includes a first shared memory 120, which stores transmission data output by any virtual machine in the group of virtual machines, and a second shared memory 121, which stores transmission data input into any virtual machine in the group of virtual machines. A communication start time and a communication end time are defined for all transmission data.The virtual machine that is the source of the transmission data stores the transmission data in the first shared memory 120 at a time before the start time of the communication. The virtual management machine reads the transmission data from the first shared memory 120 at the start time of the communication and stores the transmission data in the second shared memory 121 at the end time of the communication. The virtual machine that is the destination of the transmission data reads the transmission data from the second shared memory 121 at a time after the end time of the communication.

[0069] Therefore, the development costs for the vehicle control unit 500, in which several parts of the vehicle control software are installed, can be reduced by using the hypervisor 100. Specifically, if, after the transmission start and end times have been set, the following two points are confirmed, it is possible to ensure that the vehicle control unit 500 is functioning correctly, and this has the effect of simplifying verification. The first point is that the vehicle control application on each virtual machine has stored data in the first shared memory 120 before the set communication start time. The second point is that the data has been extracted from the second shared memory 121 after the read tolerance time has elapsed from the set communication end time.

[0070] (2) The first shared memory 120 and the second shared memory 121 are designated for each part of the transmission data. The first shared memory 120 can be written to by the virtual machine sending the transmission data and can be read by the virtual management machine. The second shared memory 121 can be written to by the virtual management machine and read by the virtual machine receiving the transmission data. Therefore, an access violation can be prevented by appropriately restricting access to the memory.

[0071] (3) The vehicle control unit 500 contains several CPU cores, from the first CPU 1 to the fifth CPU 5. In a case where the execution of several virtual machines is assigned to the same CPU core, the hypervisor 100 executes the assigned virtual machines in a predefined order, as described in the Fig. 5 and Fig. Figure 6 illustrates this, thereby performing a time allocation between the virtual machines. The first CPU, 1, is assigned to the first virtual machine, 101, and the second CPU, 2, through the fifth CPU, 5, are assigned to the group of virtual machines. Therefore, multiple virtual machines can be run by one CPU by applying the time allocation method. (Modification 1)

[0072] In the first embodiment described above, both the communication management application 111 and the vehicle control application each run on the virtual machine. However, a container can also be used instead of the virtual machine. In this case, a container engine is used instead of the hypervisor 100. Then the vehicle control unit 500 contains an operating system, the container engine runs on the operating system, and the container engine executes each container. -Second embodiment-

[0073] A second embodiment of a vehicle control device and a vehicle control method is described with reference to the Fig. Sections 17 to 19 describe the following. In the following description, the same components as in the first embodiment are designated by the same reference numerals, and the main differences are described. Points not specifically described are the same as in the first embodiment. The present embodiment differs from the first embodiment mainly in that the first CPU 1 does not occupy the first virtual machine 101 on which the communication management application 111 is installed. <Fahrzeugsteuerungseinrichtung 500>

[0074] Fig. Figure 17 is a diagram illustrating a hardware configuration of a vehicle control unit 500A according to the second embodiment. The vehicle control unit 500A includes a first CPU 1, a second CPU 2, a third CPU 3, a memory 6, and a first timer 7.

[0075] Fig. Figure 18 is a diagram illustrating a software configuration of a vehicle control unit 500A according to the second embodiment. The difference to Fig. 2. In the first embodiment, the number of CPUs shown in the lower part of the drawing is determined by the number of CPUs. A first virtual machine 101, a second virtual machine 102, a third virtual machine 103, a fourth virtual machine 104, and a fifth virtual machine 105 are configured on the hypervisor 100A. Which of the first CPU 1, the second CPU 2, and the third CPU 3 runs each virtual machine is not predetermined.

[0076] Fig. Figure 19 is a diagram illustrating the presence or absence of a time notification being received from each timer in each CPU. The first CPU 1, the second CPU 2, and the third CPU 3 all receive a time notification from the first timer 7. <hypervisor>

[0077] The role and operation of Hypervisor 100A are described. Hypervisor 100A has higher operational authority than any other software and starts with a higher priority than any other software. Hypervisor 100A notifies each virtual machine of the time reported by the first Timer 7. The operating system installed in each virtual machine determines whether or not it is necessary to start each vehicle control application or communication management application 111 at the reported time and sends a start request from the virtual machine to Hypervisor 100A if it determines that a start is necessary. Upon receiving the start request, Hypervisor 100A makes available one of the CPUs from the first CPU 1, the second CPU 2, and the third CPU 3 that is not currently being used by another virtual machine; that is, it allows the virtual machine to use it.

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

[0079] If the first CPU 1, the second CPU 2, and the third CPU 3 are all being used by the virtual machine, and another virtual machine (hereinafter referred to as the "newly requested virtual machine") requests the CPU, Hypervisor 100A performs arbitration according to the established priority. That is, if the newly requested virtual machine has a lower priority than any of the virtual machines (hereinafter referred to as the "used virtual machine") currently using the CPU, the newly requested virtual machine is made to wait until one of the used virtual machines releases the CPU back to Hypervisor 100A.Furthermore, in a case where the newly requested virtual machine has a higher priority than a particular virtual machine in use, the use of the CPU by the virtual machine with the lower priority is forcibly suspended, the CPU is returned to Hypervisor 100A, and the returned CPU is made available to the newly requested virtual machine. <Festsetzung der Kommunikationszeiteinteilung zwischen virtuellen Maschinen>

[0080] In the present embodiment, the first virtual machine 101, on which the communication management application 111 is installed, is assigned a higher priority than any of the second virtual machine 102, the third virtual machine 103, the fourth virtual machine 104, and the fifth virtual machine 105. Accordingly, the communication management application 111 can read from and write data to the first shared memory 120 and the second shared memory 121 at the specified communication start time and communication end time, regardless of whether or not a CPU provisioning request is made by another virtual machine.

[0081] According to the second embodiment described above, the following operational effects can be achieved. (4) The Hypervisor 100A can assign a start priority to several virtual machines. In a case where a start request is received simultaneously from one or more virtual machines, the Hypervisor 100A executes the virtual machines sequentially, starting with a virtual machine with a high start priority. In a case where a start request is received from a virtual machine with a high start priority while a virtual machine with a low start priority is starting, the Hypervisor suspends the start of the virtual machine with the low start priority in order to start the virtual machine with the high start priority. A start priority higher than that of any other virtual machine in the group is set for the first virtual machine, 101.Therefore, if the number of CPU cores installed on the vehicle control unit (500) is limited, the communication time allocation can be set without using the CPU for the communication management application (111). -Third embodiment-

[0082] A vehicle control device and a vehicle control method according to a third embodiment are described with reference to the Fig. Sections 20 to 27 describe the following. In the following description, the same components as in the first embodiment are designated by the same reference numerals, and the main differences are described. Points not specifically described are the same as in the first embodiment. The present embodiment differs from the first embodiment mainly in that a vehicle control unit exchanges data with the outside world.

[0083] Fig. Figure 20 is a configuration diagram of a vehicle 300 according to the third embodiment. The vehicle 300 includes a vehicle control unit 500 and a second vehicle control unit 200. The vehicle control unit 500 and the second vehicle control unit 200 are connected by a communication bus 118, enabling them to communicate with each other.

[0084] Fig. Figure 21 is a diagram illustrating a software configuration of a vehicle control unit 500B according to the present embodiment. The difference to Fig. 2 in the first embodiment consists in that a first virtual machine 101 contains a first communication driver 116 and a hypervisor 100B contains a time synchronization unit 122.

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

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

[0087] In the present embodiment, transmission data exchanged between different facilities is also referred to as "inter-facility transmission data". Similar to the transmission data, the inter-facility transmission data is stored in the first shared memory 120 or the second shared memory 121. The time at which the communication management application 111 or the second communication management application 123 reads the inter-facility transmission data from the first shared memory 120 is also referred to as the "inter-facility communication start time".The time during which the communication management application 111 or the second communication management application 123 writes the inter-institutional transmission data to the second shared storage 121 is also referred to as the "end time of inter-institutional communication".

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

[0089] Fig. Figure 23 is a diagram illustrating an example where the timing is fixed in the present embodiment. In the following description, “n” represents an integer. In the processing result of the fifth vehicle control application 19, started at time (10*n) ms, the time 10*(n+1) ms is set as the communication start time and the time 10*(n+2) ms is set as the communication end time. In the processing result of the fourth vehicle control application 115, started at time (10*n) ms, the time (10*n+5) ms is set as the communication start time and the time (10n+15) ms is set as the communication end time. <Festsetzung der Kommunikationszeiteinteilung zwischen virtuellen Maschinen und zwischen Fahrzeugsteuerungseinrichtungen>

[0090] In the present embodiment, in addition to communication between virtual machines, communication between vehicle control units is also carried out using the communication bus 118 via the communication management application 111 and the second communication management application 123. When data is sent from the fifth vehicle control application 19 to the second vehicle control application 113, the second communication management application 123 first acquires data from the fifth vehicle control application 19. Then, the second communication management application 123 sends data to the communication bus 118 using the second communication driver 117. The communication management application 111 of the vehicle control unit 500B receives data from the communication bus 118 using the first communication driver 116 and forwards the received data to the second vehicle control application 113.

[0091] At this time, the communication start time is the time at which the second communication management application 123 extracts the data generated by the fifth vehicle control application 19; that is, the time at which the second communication management application accesses the memory shared by the second communication management application 123 and the fifth vehicle control application 19. The communication end time is the time at which the communication management application 111 delivers data to the second vehicle control application 113; that is, the time at which the communication management application accesses the memory shared by the communication management application 111 and the second vehicle control application 113.

[0092] Similarly, when data is sent from the fourth vehicle control application 115 to the sixth vehicle control application 20, the communication management application 111 first obtains data from the fourth vehicle control application 115. Then, the communication management application 111 sends data to the communication bus 118 using the first communication driver 116. The second communication management application 123 of the second vehicle control unit 200 receives data from the communication bus 118 using the second communication driver 117 and delivers the received data to the sixth vehicle control application 20.

[0093] The communication start time is the time at which the communication management application 111 extracts the data generated by the fourth vehicle control application 115; that is, the time at which the communication management application accesses the memory shared by the communication management application 111 and the fourth vehicle control application 115. The communication end time is the time at which the second communication management application 123 delivers data to the sixth vehicle control application 20; that is, the time at which the second communication management application accesses the memory shared by the second communication management application 123 and the sixth vehicle control application 20.

[0094] Fig. Figure 24 is a diagram illustrating the configuration information 1001 of the shared memory of the vehicle control unit 500B in the present embodiment. The shared memory IDs “1” through “6” are the same as in the first embodiment. Shared memory ID “7” is the second shared memory 121, shared by the communication management application 111 of the first virtual machine 101 and the second vehicle control application 113 of the third virtual machine 103. Shared memory ID “8” is the first shared memory 120, shared by the fourth vehicle control application 115 of the fifth virtual machine 105 and the communication management application 111.

[0095] Fig. Figure 25 is a pseudocode that shows the processing content of the communication management application 111 of the vehicle control unit 500B in the present embodiment. In the present embodiment, as shown in Fig. Figure 23 shows that the time (10*n) ms is the end-of-communication time for data from the fifth vehicle control application 19. Furthermore, the time (10*n)+5 ms is the time at which the transmission of data is initiated, data that was generated when the fourth vehicle control application 115 was started immediately prior, that is, at time (10*n) ms. Therefore, if the condition "counter & 2 == 0" in the function Com_Manage_App() is met, the shared memory ID "7" is accessed and data is written. This is the processing to terminate the data transmission from the fifth vehicle control application 19 to the second vehicle control application 113.

[0096] If the condition "else" in the function Com_Manage_App() is true, the following three processing steps are performed. First, data generated by the fourth vehicle control application (115) is read by accessing shared memory ID "3". Second, the data is sent to the second vehicle control unit (200) via communication bus (118). Third, the fifth vehicle control application (19) reads data that has already started sending and arrived at the second vehicle control unit (200) 5 ms earlier, and stores the data in the variable tmp_data_from_app_5. The stored data is intended to be written to shared memory ID "7" when the function Com_Manage_App() is started after 5 ms. The function SendCanData takes as its argument data to be sent to communication bus (118).The ReadCanData function takes as an argument the address of a variable that stores data received from communication bus 118.

[0097] Fig. Figure 26 is a diagram illustrating the setting information 1001 of the shared memory of the second vehicle control unit 200 in the present embodiment. Shared memory ID “1” is the first shared memory 120 shared by the fifth vehicle control application 19 and the second communication management application 123. Shared memory ID “2” is the second shared memory 121 shared by the second communication management application 123 and the sixth vehicle control application 20.

[0098] Fig. 27 is a pseudocode that shows the processing content of the second communication management application 123 of the second vehicle control unit 200 in the present embodiment. In the present embodiment, as in Fig. Figure 23 shows that the time (10*n) ms is the communication start time of the data from the fifth vehicle control application 19. The time (10*n)+5 ms is the time at which the transmission of the data generated when the fourth vehicle control application 115 was started at time (10*n)-15 ms is completed. Therefore, if the condition "counter & 2 == 0" in the function Com_Manage_App2() is met, the shared memory ID "1" is first accessed to read data, and the read data is sent to the vehicle control unit 500B via the communication bus 118. This is the processing of the start of data transmission from the fifth vehicle control application 19 to the second vehicle control application 113.

[0099] Then, the fourth vehicle control application 115 reads data that has started being sent and arrived at vehicle control unit 500B 5 ms earlier, and stores the data in the variable tmp_data_from_app_4. If the "else" condition in the function Com_Manage_App2() is true, the transmission from the fourth vehicle control application 115 to the sixth vehicle control application 20 is terminated by writing the data stored in the variable tmp_data_from_app_4 to the shared memory ID "2".

[0100] According to the third embodiment described above, the following operational effects can be achieved.

[0101] (5) The vehicle control unit 500B includes a first communication driver 116, which communicates with the second vehicle control unit 200 via the communication bus 118. The second vehicle control unit 200 includes a second communication management application 123, which manages communication between applications, a sixth operating system 18, and a second application group defined by several applications. The sixth operating system 18 executes the second management application and the second application group. The sixth operating system 18 includes a first shared memory 120, which stores transmission data issued by any application of the second application group.The Hypervisor 100B contains a second shared memory 121, also referred to as the receive-side shared memory, which stores cross-device transmission data fed by the second vehicle control unit 200 into any virtual machine in the group of virtual machines. A start time and an end time for the cross-device communication are determined for each part of the cross-device communication data. One of the applications in the second application group, which is the sending source of the cross-device transmission data, stores the cross-device transmission data in a send-side shared memory at a time prior to the start time of the cross-device communication.The second communication management application 123 reads the cross-device transmission data from the first shared memory 120 in the second vehicle control unit 200 at the start time of the cross-device communication and sends the cross-device transmission data via the communication bus 118 to the first virtual machine 101 before the end time of the cross-device communication. The first virtual machine 101 stores the cross-device transmission data in the second shared memory 121 of the vehicle control unit 500B at the end time of the cross-device communication. The virtual machine that is the receiving destination of the cross-device transmission data reads the cross-device transmission data from the second shared memory 121 at a time after the end time of the cross-device communication.Therefore, even when the vehicle control unit 500B communicates with the outside world of the vehicle control unit 500B, the start and end times of the communication can be set and the verification can be easily carried out.

[0102] It can also be said that the present embodiment includes the following communication system. The communication system is a communication system comprising a first vehicle control unit and a second vehicle control unit connected via a communication bus, wherein the first vehicle control unit includes a first hypervisor capable of implementing a first virtual management machine that manages communication between applications and a group of virtual machines, defined by multiple virtual machines, each of which has an application; the second vehicle control unit includes a second management application that manages communication between applications, an operating system, and a second group of applications defined by multiple applications; and the operating system executes the second management application and the second group of applications.The first hypervisor contains a receive-side shared memory that stores transmission data fed into any virtual machine of the group of virtual machines, and the operating system contains a send-side shared memory that stores the transmission data output by any application of the second application group, a start time and an end time of the cross-site communication are determined for each part of the transmission data, each application of the second application group, as the sending source of the transmission data, stores the transmission data in the send-side shared memory at a time before the start time of the cross-site communication of the transmission data.The second management application reads the transmission data from the sending-side shared memory at the start time of the cross-institutional communication and sends the transmission data to the first virtual management machine via the communication bus before the end time of the cross-institutional communication. The first virtual management machine stores the transmission data in the sending-side shared memory at the end time of the cross-institutional communication, and a virtual machine, as the receiving destination of the transmission data, reads the transmission data from the receiving-side shared memory at a time after the end time of the cross-institutional communication. (Modification of the third embodiment)

[0103] In the third embodiment described above, the second vehicle control unit 200 does not contain a virtual machine. However, the second vehicle control unit 200 may contain a virtual machine. -Fourth embodiment-

[0104] A vehicle control device and a vehicle control method according to a fourth embodiment are described with reference to Fig. 28. In the following description, the same components as in the first embodiment are designated by the same reference numerals, and mainly differences are described. Items not specifically described are the same as in the first embodiment. The present embodiment differs from the first embodiment mainly in that each vehicle control application writes data with an added timestamp to the first shared memory 120.

[0105] Fig. Figure 28 is a diagram illustrating a hardware configuration of a vehicle control unit 500C according to the present embodiment. Fig. In embodiment 28, a log storage unit 124 has been added compared to the first embodiment. The log storage unit 124 is a non-volatile memory.

[0106] When writing data to the first shared memory 120, the first vehicle control application 112, the third vehicle control application 114, and the fourth vehicle control application 115, according to the present embodiment, write timestamp information in addition to the data to be sent. The timestamp information is a time or the number of data write operations. The communication management application 111, according to the present embodiment, checks the timestamp information when reading data from the first shared memory 120. If the timestamp information has not been updated since the last data read, the communication management application 111 performs the following processing.That is, the communication management application 111 determines that a delay has occurred in the vehicle control application, which has not updated the timestamp information, and generates the data and records the information of the vehicle control application in the log storage unit 124.

[0107] According to the fourth embodiment described above, the following operational effects can be achieved.

[0108] (6) The vehicle control unit 500C includes a log storage unit 124, which stores a log. The virtual machine contained in the virtual machine group stores transmission data and identification data in the first shared memory 120, which is capable of identifying a time schedule with which the transmission data is generated. The virtual management machine checks the identification data when it extracts the transmission data from the first shared memory 120 at the communication start time and records the identification data in the log storage unit 124 if the identification data has not been updated since the previous communication end time. Therefore, it is possible to determine and record that the vehicle control application has committed a time-based error. -Fifth embodiment-

[0109] A vehicle control device and a vehicle control method according to a fifth embodiment are described with reference to Fig. 29. In the following description, the same components as in the first embodiment are designated by the same reference numerals, and the main differences are described. Points not specifically described are the same as in the first embodiment. The present embodiment differs from the first embodiment mainly in that a protocol is sent to a server.

[0110] Fig. Figure 29 is a diagram illustrating a software configuration of a vehicle control unit 500D according to the present embodiment. The first virtual machine 101 contains a first operating system 106, a communication management application 111, and a log sending application 125. The log sending application 125 has the function of sending the log information stored in the log storage unit 124 to a server outside the vehicle. The log sending application 125 is preemptive, meaning that even if processing by the first operating system 106 is suspended midway through, processing can be resumed from the point at which it was suspended if the first operating system 106 restarts the log sending application 125. The first operating system 106 starts the log sending application 125 with a lower priority than the communication management application 111.

[0111] According to the fifth embodiment described above, the following operational effects can be achieved.

[0112] (7) The vehicle control unit 500D includes a protocol sending application 125 which sends the identification data stored in the protocol storage unit 124 to an external server. Therefore, by sending the information about the occurrence of the deadline error to the server, it is possible to analyze the cause of the deadline error and to improve the vehicle control application.

[0113] (8) The virtual management machine continues to perform processing that has a lower priority than either the processing to read the transmission data from the first shared memory 120 at the communication start time or the processing to store the transmission data in the second shared memory 121 at the communication end time, and which is capable of pausing and resuming processing. Because the protocol transmission application 125 is installed on the first virtual machine 101, it is not necessary to reinstall a CPU for protocol transmission, and it is possible to maintain the timing of the communication start and end without the protocol transmission processing preventing the communication management application 111 from accessing the first shared memory 120 and the second shared memory 121.

[0114] In the embodiments and modifications described above, the configuration of the function block is merely an example. Some function configurations, represented as separate function blocks, may be configured integrally, or a configuration shown in a function block diagram may be split into two or more functions. Furthermore, some of the functions of each function block may be contained within another function block.

[0115] In each of the embodiments and modifications described above, the program is stored in the ROM (not shown), but the program may also be stored in a non-volatile memory device. Furthermore, the vehicle control unit 500 may include an input / output interface (not shown), and a program may, if necessary, be read from another device via a medium accessible through the input / output interface and the vehicle control unit 500. This medium may include, for example, a storage medium removable from the input / output interface, or a communication medium, such as a wired, wireless, or optical network, or a carrier wave, or a digital signal propagating through the network.Some or all of the functions implemented by the program can be implemented by a hardware circuit or an FPGA.

[0116] The embodiments and modifications described above can be combined. Although various embodiments and modifications have been described above, the present invention is not limited to these. Other embodiments conceivable within the scope of the present invention are also included. Reference symbol list 100, 100A Hypervisor 101 first virtual machine 102 second virtual machine 111 Communication Management Application 116 first communication driver 117 second communication driver 118 Communication bus 120 first shared storage 121 second shared storage 123 second communication management application 124 log storage unit 125 Protocol sending application 200 second vehicle control unit 500, 500A, 500B, 500C, 500D Vehicle control unit QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] JP 2019-057162 A

[0004] < / hypervisor> < / hypervisor> < / timer>

Claims

Vehicle control device comprising a hypervisor capable of realizing multiple virtual machines, wherein the multiple virtual machines include a virtual management machine that manages communication between virtual machines, and a group of virtual machines representing a virtual machine whose communication is managed by the virtual management machine; the hypervisor includes a first shared memory that stores transmission data output by any virtual machine of the group of virtual machines, and a second shared memory that stores transmission data input into any virtual machine of the group of virtual machines; a communication start time and a communication end time are determined for all transmission data; a virtual machine that is a transmission source of the transmission data.The virtual management machine stores the transmission data in the first shared memory at a time before the communication start time, reads the transmission data from the first shared memory at the communication start time and stores the transmission data in the second shared memory at the communication end time, and a virtual machine that is a receiving destination for the transmission data reads the transmission data from the second shared memory at a time after the communication end time. Vehicle control device according to claim 1, wherein the first shared memory and the second shared memory are provided for each part of the transmission data, the first shared memory being writable by each virtual machine of the group of virtual machines that sends the transmission data and readable by the virtual management machine, and the second shared memory being writable by the virtual management machine and readable by each virtual machine of the group of virtual machines that receives the transmission data. Vehicle control device according to claim 2, wherein multiple CPU cores are provided, the hypervisor, when assigning the execution of multiple virtual machines to the same CPU core, executes the assigned virtual machines in a predetermined sequence in order to perform a time split between the virtual machines, a first CPU core is assigned to the virtual management machine, and one or more CPU cores different from the first CPU core are assigned to the group of virtual machines. Vehicle control device according to claim 2, wherein the hypervisor is able to assign a start priority to the multiple virtual machines, executes virtual machines sequentially from a virtual machine with a higher start priority when it simultaneously receives a start request from one or more virtual machines, and suspends the start of a virtual machine with a lower priority during startup in order to start a virtual machine with a higher start priority when, during the start of a virtual machine with a lower start priority, a start request is received from a virtual machine with a higher start priority, and sets the start priority for the virtual management machine higher than for each of the group of virtual machines. Vehicle control device according to claim 3, further comprising: a log storage unit which stores a log, wherein the virtual machine included in the group of virtual machines stores in the first shared memory the transmission data and identification data which is able to identify a time schedule with which the transmission data is generated, and the virtual management machine checks the identification data when it extracts the transmission data from the first shared memory at the communication start time, and records the identification data in the log storage unit if the identification data has not been updated since the previous communication end time. Vehicle control device according to claim 5, further comprising: a data transmission unit that sends the identification data stored in the log storage unit to an external server. Vehicle control device according to claim 4, further comprising: a log storage unit which stores a log, wherein the virtual machine included in the group of virtual machines stores in the first shared memory the transmission data and identification data which is able to identify a time schedule with which the transmission data is generated, and the virtual management machine checks the identification data when it extracts the transmission data from the first shared memory at the communication start time, and records the identification data in the log storage unit if the identification data has not been updated since the previous communication end time. Vehicle control device according to claim 7, further comprising: a data transmission unit that sends the identification data stored in the log storage unit to an external server. Vehicle control device according to claim 3, wherein the virtual management machine further performs processing that has a lower priority than the processing of reading the transmission data from the first shared memory at the communication start time and the processing of storing the transmission data in the second shared memory at the communication end time, and which is able to suspend and resume the processing. Vehicle control device according to claim 1, further comprising: a communication driver that communicates with a second vehicle control device, which is another device, via a communication bus, wherein the second vehicle control device comprises a second management application that manages communication between applications, an operating system, and a second application group comprising multiple applications, wherein the operating system executes the second management application and the second application group, the operating system comprises a send-side shared memory that stores the transmission data output by any application of the second application group, and the hypervisor further comprises a receive-side shared memory.which stores cross-device transmission data fed by the second vehicle control unit into any virtual machine of the group of virtual machines, contains, for each part of the cross-device transmission data a start time of the cross-device communication and an end time of the cross-device communication are determined, each application of the second application group as a sending source of the cross-device transmission data stores the cross-device transmission data in the sending-side shared memory at a time before the start time of the cross-device communication of the cross-device transmission data,The second management application reads the cross-institutional transmission data from the sending-side shared memory at the start time of the cross-institutional communication and sends the cross-institutional transmission data to the virtual management machine via the communication bus before the end time of the cross-institutional communication. The virtual management machine stores the cross-institutional transmission data in the receiving-side shared memory at the end time of the cross-institutional communication. A virtual machine that is a receiving destination for the cross-institutional transmission data reads the cross-institutional transmission data from the receiving-side shared memory at a time after the end time of the cross-institutional communication. A vehicle control method executed by a vehicle control device containing a hypervisor capable of realizing multiple virtual machines, wherein the multiple virtual machines include a virtual management machine that manages communication between virtual machines and a group of virtual machines whose communication is managed by the virtual management machine, and the hypervisor includes a first shared memory that stores transmission data output by any virtual machine of the group of virtual machines and a second shared memory that stores transmission data fed into any virtual machine of the group of virtual machines, wherein a communication start time and a communication end time are determined for each part of the transmission data.and the vehicle control procedure includes: storing the transmission data in the first shared memory at a time before the communication start time of the transmission data by a virtual machine that is a sending source of the transmission data; reading the transmission data by the virtual management machine from the first shared memory at the communication start time and storing the transmission data in the second shared memory at the communication end time; and reading the transmission data from the second shared memory at a time after the communication end time by a virtual machine that is a receiving destination of the transmission data.

Images