Vehicle control device and communication setting method

Abstract

This invention provides a vehicle control system that incorporates virtualization technology that can suppress the reduction in CPU processing time allocated to task processing within a virtual machine. [Solution] The vehicle control device 100A includes a hypervisor 20, a plurality of virtual machines 21, 22 started by the hypervisor 20, a communication peripheral 50 that stores CAN messages (data) D used for calculations by applications 26, 30, 31 running on the virtual machines 21, 22, and an initial setup unit 40 that starts the hypervisor 20. The initial setup unit 40 sets communication setting information 41 in the communication peripheral 50 specifying the destination virtual machines 21, 22 for each CAN message D, and then starts the hypervisor 20. Based on the communication setting information 41, the communication peripheral 50 generates an interrupt to the virtual machines 21, 22 when storing a CAN message D.

Description

Technical Field

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

Background Art

[0002] Attention has been paid to introducing virtualization technology (hypervisor) into a vehicle control device. As an example of a vehicle control device using a hypervisor, Patent Document 1 describes an electronic control device including a virtual machine that accesses a virtual driver and executes processing, and a hypervisor that calls an actual driver of a peripheral based on a peripheral access request received from the virtual driver. The electronic control device further includes an access recording unit that calls a virtual driver and records a peripheral access request transmitted to the hypervisor, a state recording unit that calls an actual driver and records the state of a peripheral register, and a monitoring unit that monitors the operation of the hypervisor. The monitoring unit determines an abnormality of the hypervisor based on the records of the access recording unit and the state recording unit.

[0003] Patent Document 2 describes a control virtual computer program that causes a computer to control another virtual computer. The control virtual computer program causes the computer to execute a reception step of receiving a communication request designating a destination virtual computer from another virtual computer. The control virtual computer program causes the computer to execute a determination step of determining whether access to a message included in the communication request is permitted based on an access control rule table associating message contents with access permission. The control virtual computer program causes the computer to execute a transmission step of transmitting communication permitted by a determination unit to a destination virtual computer. The control virtual computer program causes the computer to execute a monitoring step of starting the control virtual computer and permitting only communication between the virtual computer and the control virtual computer.

Prior Art Documents

Patent Documents

[0004] [Patent Document 1] Japanese Patent Publication No. 2022-174784 [Patent Document 2] Japanese Patent Publication No. 2011-070526 [Overview of the project] [Problems that the invention aims to solve]

[0005] In the technology described in Patent Document 1, for a vehicle control device incorporating virtualization technology to function correctly, it is necessary not only that the hypervisor correctly accesses the CAN (Controller Area Network) controller, but also that the CPU (Central Processing Unit) completes the processing of each task by the deadline. Since the CPU processes tasks by switching between the hypervisor, the monitoring unit, and tasks within the virtual machine, the processing time consumed by the hypervisor and the monitoring unit reduces the CPU processing time allocated to processing tasks executed within the virtual machine, which may cause delays in the processing of tasks such as vehicle control applications executed within the virtual machine.

[0006] In the technology described in Patent Document 2, changing communication that was previously performed directly between virtual machines to go through a control virtual machine increases communication time (latency), affecting real-time performance. Furthermore, since the control virtual machine is executed by the CPU, it consumes CPU processing time, and similar to Patent Document 1, the CPU processing time allocated to task processing within the virtual machine is reduced, potentially causing delays in task processing such as vehicle control applications running within the virtual machine.

[0007] Based on the above, the present invention aims to provide a vehicle control device that incorporates virtualization technology capable of suppressing the reduction in CPU processing time allocated to task processing within a virtual machine. [Means for solving the problem]

[0008] The present invention provides a vehicle control device for solving the above problems, comprising a hypervisor, a plurality of virtual machines started by the hypervisor, a communication peripheral for storing data used for calculations of applications running on the virtual machines, and an initial setup unit for starting the hypervisor. The initial setup unit sets communication setting information specifying the destination virtual machine for each piece of data in the communication peripheral, and then starts the hypervisor. The communication peripheral generates an interrupt to the virtual machine when storing data based on the communication setting information. [Effects of the Invention]

[0009] According to the present invention, in a vehicle control device that incorporates virtualization technology, it is possible to suppress the reduction in CPU processing time allocated to task processing within the virtual machine. Further features related to the present invention will become apparent from the description herein and the accompanying drawings. Furthermore, problems, configurations, and effects other than those described above will be revealed by the following description of embodiments. [Brief explanation of the drawing]

[0010] [Figure 1] A diagram showing the hardware configuration of the vehicle control device in Example 1. [Figure 2] A diagram showing an overview of the software configuration of the vehicle control device in Example 1. [Figure 3] A flowchart illustrating the process by which an application contained within a virtual machine sends data to an external source. [Figure 4] A flowchart illustrating the process by which a virtual machine receives data from another vehicle control device in the comparative example vehicle control device. [Figure 5] A diagram illustrating the problems that occur in the vehicle control system of the comparative example. [Figure 6] This figure shows the number of unnecessary receive interrupts that occur in the vehicle control device of the comparative example. [Figure 7] A diagram showing the detailed software configuration of the vehicle control device in Example 1. [Figure 8]Flowchart of the process in which the virtual machine receives data received from another vehicle control device in the vehicle control device of Example 1. [Figure 9] Diagram showing the effects of the vehicle control device of Example 1. [Figure 10] Diagram showing details of the software configuration of the vehicle control device in Example 2. [Figure 11] Diagram showing the priority for each data in Example 2. [Figure 12] Diagram showing the priority for each data in Example 3. [Figure 13] Diagram showing details of the software configuration of the vehicle control device in Example 4.

Mode for Carrying Out the Invention

[0011] Hereinafter, this embodiment will be described with reference to the accompanying drawings. In the accompanying drawings, functionally identical elements are denoted by the same reference numerals. Note that the accompanying drawings show embodiments and implementation examples in accordance with the principles of the present disclosure, but these are for the purpose of understanding the present disclosure and are not used to limit the present disclosure in any way. The description in this specification is merely a typical example and does not limit the scope of the claims or the application examples of the present disclosure in any sense.

[0012] Each of the examples shown below relates to a vehicle control device mounted on a vehicle. Hereinafter, examples (embodiments) of preferred embodiments of the present invention will be described. For simplicity, in this embodiment, the case where CAN (Controller Area Network) is used as the communication protocol will be described, but 10BASE-T1S in which CAN frames are mapped to Ethernet frames and other broadcast-type communication protocols may also be used.

[0013] [Example 1] <Hardware Configuration> FIG. 1 is a diagram showing the hardware configuration of the vehicle control device 100A in the first embodiment. Hereinafter, the hardware configuration of the vehicle control device 100A according to the first embodiment will be described with reference to FIG. 1. However, the vehicle control device 100A of this embodiment has the same configuration as a conventional vehicle control device as a hardware configuration. The vehicle control device 100A includes a microcomputer 8. The microcomputer 8 has a first CPU (Central Processing Unit) 1, a second CPU 2, a third CPU 3, a memory 5, and a communication peripheral 50. The memory 5 includes a ROM (Read Only Memory) and a RAM (Random Access Memory). The communication peripheral 50 includes a CAN controller 6 and a CAN transceiver 9. In this embodiment, the number of CPU cores included in the microcomputer 8 is set to 3, but this embodiment is also applicable when the number of cores is other than 3.

[0014] The CAN controller 6 includes a transmission data storage unit 12, a reception data storage unit 13, and a communication setting information storage unit 14. In this embodiment, the transmission data storage unit 12 includes three transmission data storage units, and the reception data storage unit 13 includes three reception data storage units. The transmission data storage unit 12 includes a first transmission data storage unit 121, a second transmission data storage unit 122, and a third transmission data storage unit 123. The reception data storage unit 13 includes a first reception data storage unit 131, a second reception data storage unit 132, and a third reception data storage unit 133. Note that the transmission data storage unit 12 may include more transmission data storage units, and the reception data storage unit 13 may include more reception data storage units. <~

[0015] Each component included in the microcomputer 8, namely the first CPU 1, the second CPU 2, the third CPU 3, the memory 5, and the communication peripheral 50, is connected by an internal bus 7. The CAN controller 6 is connected to the CAN bus 10 via the CAN transceiver 9 and performs CAN communication with another vehicle control device 11. In this embodiment, there is one other vehicle control device 11, but there may be two or more.

[0016] When the CAN controller 6 receives data to be transmitted from the vehicle control device 100A and stores it in the data transmission storage unit 12, it starts the data transmission process to the CAN bus 10 using the CAN transceiver 9. When another vehicle control device 11 transmits data to the CAN bus 10, the data is stored in the data reception storage unit 13 via the CAN transceiver 9. When data is stored in any of the first data reception storage unit 131, the second data reception storage unit 132, or the third data reception storage unit 133, the CAN controller 6 can generate a receive interrupt for the first CPU 1, the second CPU 2, and the third CPU 3.

[0017] The CAN controller 6 can configure communication settings information. Communication settings information specifies which of the first, second, and third received data storage units 131, 132, and 133 should store a received CAN message (data) based on the ID (identifier) ​​of the CAN message. Furthermore, communication settings information also specifies which of the first, second, and third received data storage units 133, which stored the received CAN message, should generate a receive interrupt after saving the CAN message, based on the ID (identifier) ​​of the CAN message.

[0018] Regarding which of the first, second, and third data storage units 133 the received CAN message will be stored, it is possible to specify that the message be stored in all three units, in two of the three units, or not in any of them.

[0019] For the first CPU1, second CPU2, and third CPU3 that generate receive interrupts, it is possible to specify that all three CPUs interrupt, two of the three CPUs interrupt, or none of the three CPUs interrupt.

[0020] Communication settings information is stored in the communication settings information storage unit 14, and the CAN controller 6 operates according to the communication settings information stored in the communication settings information storage unit 14. If there is no communication settings information stored in the communication settings information storage unit 14, the CAN controller 6 stores all received CAN messages in the third received data storage unit 133 and generates receive interrupts for all of the first CPU 1, second CPU 2, and third CPU 3.

[0021] <Software Configuration> Figure 2 is a diagram showing an overview of the software configuration of the vehicle control device 100A in this embodiment. The overview of the software configuration of the vehicle control device 100A in this embodiment will be explained below using Figure 2. The vehicle control device 100A is virtualized by the hypervisor 20 to configure virtual machines 21 and 22. Virtual machine 21 is processed by the first CPU 1, and virtual machine 22 is processed by the second CPU 2 and the third CPU 3.

[0022] Virtual machine 21 includes a vehicle control application 26, a first OS (Operating System) 27, and a first virtual received data storage unit 35. The first OS 27 includes a first transmission request reception unit 28 and a first received interrupt reception unit 29. Virtual machine 22 includes a vehicle control application 30, a vehicle control application 31, a second OS 32, and a second virtual received data storage unit 36. The second OS 32 includes a second transmission request reception unit 33 and a second received interrupt reception unit 34. Application 30, the second transmission request reception unit 33, and the second received interrupt reception unit 34 are processed by the second CPU 2. Application 31 is processed by the third CPU 3.

[0023] The hypervisor 20 includes a reception processing unit 23, a first transmission request processing unit 24, and a second transmission request processing unit 25. The reception processing unit 23 is processed by one CPU. In this embodiment, the reception processing unit 23 is processed by the first CPU 1. Since the virtual machine 21 is processed by the first CPU 1, the first transmission request processing unit 24 is processed by the first CPU 1. Since the virtual machine 22 is processed by the second CPU 2, the second transmission request processing unit 25 is processed by the second CPU 2.

[0024] <CAN Transmission Processing> FIG. 3 is a flowchart of a process in which the application 26 included in the virtual machine 21 transmits data to the outside of the virtual machine 21. Hereinafter, the process in which the application 26 included in the virtual machine 21 transmits data to the outside of the virtual machine 21 will be described using FIG. 3. In the following data transmission process, although the effects of this embodiment do not occur, it will be described for understanding the operation.

[0025] The first OS 27 starts the application 26 (S111). The application 26 performs processing (S112). For example, when the application 26 is an application related to engine control, the application 26 performs fuel injection processing. In order to transmit data on the fuel injection amount to another vehicle control device 11, the application 26 calls the first transmission request reception unit 28.

[0026] The first transmission request reception unit 28 receives transmission data (fuel injection amount) from the application 26 and requests data transmission to the hypervisor 20 (S113). At this time, the first CPU 1 may transition from the guest mode for processing the virtual machine 21 to the host mode for processing the hypervisor 20 (this is generally called VMExit). The hypervisor 20 receives a data transmission request and transmission data from the virtual machine 21 and activates the first transmission request processing unit 24 (S114).

[0027] The first transmission request processing unit 24 checks whether the second transmission request processing unit 25 is accessing the transmission data storage unit 12 (S115). This is because the second transmission request processing unit 25 is executed on the second CPU 2 and accepts data transmission requests from the virtual machine 22, so mutual exclusion control is performed to prevent the first CPU 1 and the second CPU 2 from accessing the transmission data storage unit 12 simultaneously and causing a conflict.

[0028] If the second transmission request processing unit 25 is in use (S116), the first transmission request processing unit 24 returns to S115 and waits for the transmission data storage unit 12 to be released. If the second transmission request processing unit 25 is not in use (S116), the first transmission request processing unit 24 proceeds to S117. The first transmission request processing unit 24 copies and stores the transmission data in the transmission data storage unit 12 (S117). As a result, the CAN controller 6 starts transmitting data to the CAN bus 10 via the CAN transceiver 9.

[0029] The first transmission request processing unit 24 checks whether the second receive interrupt receiver 34 is accessing the second virtual received data storage unit 36 ​​(S118). This is because the second receive interrupt receiver 34 is executed by the second CPU 2 and accepts data reception requests to the virtual machine 22, so mutual exclusion control is performed to prevent the first CPU 1 and the second CPU 2 from accessing the second virtual received data storage unit 36 ​​simultaneously and causing a conflict. If the second receive interrupt receiver 34 is accessing the second virtual received data storage unit 36 ​​(S119), the process returns to S118 and waits for the second virtual received data storage unit 36 ​​to be released. If the second receive interrupt receiver 34 is not accessing the second virtual received data storage unit 36 ​​(S119), the first transmission request processing unit 24 proceeds to S120.

[0030] The first transmission request processing unit 24 copies the transmission data and stores it in the second virtual received data storage unit 36, and the second received interrupt reception unit 34 continues (S120). This transmits the data to each virtual machine other than virtual machine 21 (in this embodiment, only virtual machine 22) that is mounted on the vehicle control device 100A.

[0031] The hypervisor 20 returns after completing processing, and the first CPU 1 resumes processing from the next instruction (program counter) after application 26 calls the first transmission request receiver 28 to transmit fuel injection amount (S121). At this time, the first CPU 1 may transition from host mode, which processes the hypervisor 20, to guest mode, which processes the virtual machine 21 (this is generally called VMEntry). The process by which application 30 or application 31 contained in the virtual machine 22 transmits data to the outside of the virtual machine 22 is the same as above. According to the above, the transmission data storage unit 12 contained in the CAN controller 6 can be shared between the virtual machine 21 and the virtual machine 22 without conflict.

[0032] <CAN reception processing in comparative example> Figure 4 is a flowchart of the process by which virtual machines 21 and 22 receive data from another vehicle control device 11 in the comparative example vehicle control device 200 shown in Figure 5. As communication setting information, communication setting information that specifies that all received data is stored in the first received data storage unit 131, a receive interrupt is generated for the first CPU 1, and no receive interrupt is generated for the second CPU 2 is stored in the communication setting information storage unit 14 (S201). This is because, as described above, the receive processing unit 23 is processed by the first CPU 1, and the second CPU 2 does not need a receive interrupt from the CAN controller 6.

[0033] When the CAN controller 6 receives data from another vehicle control device 11 via the CAN transceiver 9, it generates a receive interrupt for the hypervisor 20 (S202). If the first CPU 1 is running application 26 or first OS 27, it interrupts it and starts the hypervisor 20 (S203). At this time, the first CPU 1 may transition from guest mode to host mode (VMExit). The hypervisor 20 accepts the receive interrupt and starts the receive processing unit 23 (S204). The receive processing unit 23 retrieves the received data from the first received data storage unit 131 (S205).

[0034] The receiving processing unit 23 checks whether the second receiving interrupt receiver 34 is accessing the second virtual received data storage unit 36 ​​(S206). This is because the second receiving interrupt receiver 34 is executed by the second CPU 2 and accepts data reception requests to the virtual machine 22, so mutual exclusion control is performed to prevent the first CPU 1 and the second CPU 2 from accessing the second virtual received data storage unit 36 ​​simultaneously and causing a conflict. If the second receiving interrupt receiver 34 is accessing the unit (S207), the receiving processing unit 23 returns to S206 and waits for the second virtual received data storage unit 36 ​​to be released. If the second receiving interrupt receiver 34 is not accessing the unit (S207), the receiving processing unit 23 proceeds to S208.

[0035] The receiving processing unit 23 copies the received data and stores it in the second virtual received data storage unit 36, and generates a receive interrupt in the second receive interrupt receiving unit 34 (S208). After this, the second CPU 2 activates the second receive interrupt receiving unit 34 to analyze the received data. If the received data is needed by application 30, it is passed to application 30; if the received data is needed by application 31, it is passed to application 31; and if it is not needed by either application 30 or 31, the received data is discarded and the processing of the second receive interrupt receiving unit 34 ends.

[0036] The reception processing unit 23 copies the received data and stores it in the first virtual received data storage unit 35, and generates a receive interrupt in the first receive interrupt reception unit 29 (S209). The hypervisor 20 returns because it has finished processing and performs the processing of the first receive interrupt reception unit 29 (S210). At this time, the first CPU 1 may transition from host mode to guest mode (VMEntry).

[0037] After this, in the first CPU1, the first receive interrupt receiver 29 is activated to analyze the received data. If the received data is necessary for application 26, it is passed to application 26. If it is not necessary, the received data is discarded, and the processing of the first receive interrupt receiver 29 ends. Processing resumes from the next instruction (program counter) that was interrupted in S203. In the above data reception processing, virtual machine 22 processes first and virtual machine 21 processes second, but virtual machine 21 may process first and virtual machine 22 may process second. The order of processing is determined by the code in the hypervisor 20.

[0038] According to the above, from the perspective of the software included in the virtual machine 21, the first virtual received data storage unit 35 is equivalent to the received data storage unit 13 (first received data storage unit 131) included in the CAN controller 6. Also, from the perspective of the software included in the virtual machine 22, the second virtual received data storage unit 36 ​​is equivalent to the received data storage unit 13 (first received data storage unit 131) included in the CAN controller 6.

[0039] <Problems with the CAN reception processing in the comparative example> Figure 5 illustrates a problem occurring in the vehicle control device of the comparative example. In CAN communication, each message frame is assigned an ID, which the receiving end uses to determine what kind of data it is. Figure 5 shows the situation where a CAN message (data) D with ID 200 is sent from another vehicle control device 11 and reaches the CAN transceiver 9 of the vehicle control device 200.

[0040] CAN message ID200 is used by virtual machine 21 but not by virtual machine 22. For example, CAN message D ID200 is data that specifies the target engine speed, and virtual machine 21 (application 26) performs engine control, while virtual machine 22 (applications 30 and 31) performs body control. In this case, CAN message D ID200 is necessary for virtual machine 21 but unnecessary for virtual machine 22.

[0041] Here, the role of the hypervisor 20 is to provide virtual environments equivalent to the real environment for virtual machines 21 and 22, and it does not care what applications 26, 30, and 31 the virtual machines 21 and 22 configured by the hypervisor 20 are. In this embodiment, the real environment refers to the transmit data storage unit 12 and the receive data storage unit 13 (first receive data storage unit 131) of the CAN controller 6. In this embodiment, the virtual environment refers to the transmit data storage unit 12, the first virtual receive data storage unit 35, and the second virtual receive data storage unit 36 ​​of the CAN controller 6, which are mutually controlled by the hypervisor 20. CAN communication is a broadcast type that transmits data to all nodes, and the selection of data is performed on the receiving side.

[0042] Therefore, when the CAN message with ID200 reaches the CAN controller 6, the hypervisor 20 copies the data to all of the first virtual received data storage units 35 and the second virtual received data storage units, and generates a receive interrupt for each of the virtual machines 21 and 22.

[0043] As a result, particularly in the virtual machine 22, as shown by the thick arrow in Figure 5, the second receive interrupt receiver 34 accesses the second virtual received data storage unit 36 ​​and retrieves CAN message D. The second OS 32 analyzes the CAN message D, confirms that CAN message D with ID 200 is not used by either application 30 or application 31, and performs filtering to discard the received CAN message.

[0044] The retrieval process from the second virtual received data storage unit 36 ​​by the second receive interrupt reception unit 34 and the filtering process by the second OS 32 are handled as software by the second CPU 2. Therefore, these processes unnecessarily consume the processing time of the second CPU 2.

[0045] Figure 6 shows the number of unnecessary receive interrupts that occur in the vehicle control device 200 of the comparative example. Assuming a load rate of 65% on the CAN bus 10, a communication speed of 1 megabit per second, and a data size of 8 bytes that can be transmitted in one CAN frame, (1,000,000 × 0.65) / (8 × 8) = 10,156 CAN messages D flow through the CAN bus 10 per second. Of these, one virtual machine 21 uses 5,000 CAN messages D and the other virtual machine 22 uses 6,000 CAN messages D.

[0046] At this time, one virtual machine 21 experiences 10156 - 5000 = 5156 unnecessary receive interrupts per second due to the reception of unused CAN message D, and the other virtual machine 22 experiences 10156 - 6000 = 4156 unnecessary receive interrupts per second due to the reception of unused CAN message D. In virtual machine 21, this consumes the processing time of the first CPU 1. In virtual machine 22, this consumes the processing time of the second CPU 2. Due to the processing time of these unnecessary receive interrupts, the processing time of the first OS 27 and second OS 32 or applications 26, 30, and 31 included in virtual machines 21 and 22 is shortened, negatively impacting the performance of the vehicle control device 200, such as deadline misses and increased latency.

[0047] <CAN reception processing according to this embodiment> Figure 7 is a diagram showing the detailed software configuration of the vehicle control device 100A in this embodiment. As shown in Figure 7, the vehicle control device 100A comprises a hypervisor 20, virtual machines 21 and 22, applications 26, 30, and 31, a communication peripheral 50, and an initial setup unit 40. The virtual machines 21 and 22 are started by the hypervisor 20. The applications 26, 30, and 31 run on the virtual machines 21 and 22. The communication peripheral 50 stores data used for calculations by the applications 26, 30, and 31. The initial setup unit 40 starts the hypervisor 20.

[0048] The CAN controller 6 uses a received data storage unit 13 not just one first received data storage unit 131, but as many units as there are virtual machines 21 and 22. In this embodiment, the first received data storage unit 131 and the second received data storage unit 132 are used. The initial setup unit 40 sets communication setting information 41, which is information indicating which ID of CAN message D each application 26, 30, and 31 included in virtual machines 21 and 22 needs to receive, and stores it in the communication setting information storage unit 14.

[0049] Specifically, the initial setup unit 40 stores the CAN message D used by the virtual machine 21 in the first received data storage unit 131. After the received data is stored in the first received data storage unit 131, it sets communication setting information 41 to generate an interrupt for the first CPU 1 and stores the communication setting information 41 in the communication setting information storage unit 14. The initial setup unit 40 also stores the CAN message D used by the virtual machine 22 in the second received data storage unit 132. After the received data is stored in the second received data storage unit 132, it sets communication setting information 41 to generate an interrupt for the second CPU 2 and stores the communication setting information 41 in the communication setting information storage unit 14.

[0050] The saving of communication setting information 41 to the communication setting information storage unit 14 is performed before the hypervisor 20 starts up as an initial setting for the vehicle control device 100A to start up. In addition, the first receive interrupt reception unit 29 is modified to accept receive interrupts from the first received data storage unit 131 instead of receive interrupts from the hypervisor 20's receive processing unit 23, and the processing is also modified to access the first received data storage unit 131 instead of the first virtual received data storage unit 35.

[0051] Similarly, the second receive interrupt receiving unit 34 is modified to accept receive interrupts from the second received data storage unit 132 instead of the receive processing unit 23 of the hypervisor 20, and the processing is also modified to access the second received data storage unit 132 instead of the second virtual received data storage unit 36.

[0052] In other words, the initial setup unit 40 sets communication setting information 41, which specifies the destination virtual machines 21 and 22 for each CAN message (data) D, in the communication peripheral 50, and then starts the hypervisor 20. Based on the communication setting information 41, the communication peripheral 50 generates an interrupt to the virtual machines 21 and 22 when storing the CAN message D. In this embodiment, the communication peripheral 50 includes a plurality of first received data storage units 131 and second received data storage units 132. Note that in Figure 7, for the sake of explanation, the third received data storage unit 133 is omitted from the illustration.

[0053] As described below, the first received data storage unit 131 and the second received data storage unit 132 generate interrupts for different virtual machines 21 and 22. The initial setup unit 40 associates the multiple first received data storage units 131 and the second received data storage units 132 with each virtual machine 21 and 22, and sets the communication setting information 41 to the communication peripheral so that the CAN message (data) D used for calculations by the application 26 running on one of the multiple virtual machines 21 and 22 is stored in the first received data storage unit 131 corresponding to that virtual machine 21.

[0054] Furthermore, in this embodiment, an interrupt that occurs when a CAN message (data) D is stored in the first received data storage unit 131 corresponding to one virtual machine 21 is input to the one virtual machine 21 without going through the hypervisor 20. The one virtual machine 21 obtains the CAN message D from the corresponding first received data storage unit 131.

[0055] Figure 8 is a flowchart of the process by which virtual machines 21 and 22 receive data received from another vehicle control device 11 in the vehicle control device 100A of Embodiment 1. As shown in Figure 8, when the ignition of the vehicle on which the vehicle control device 100A is installed is turned on (S301), the initial setup unit 40 sets the communication setting information 41 to the communication peripheral 50 (S302). After setting the communication setting information 41 to the communication peripheral 50, the initial setup unit 40 starts the hypervisor (S303). Note that if the ignition of the vehicle on which the vehicle control device 100A is installed is not turned on (S301), the initial setup unit 40 will not start operating.

[0056] When the CAN controller 6 receives a CAN message (data) D from another vehicle control device 11, it generates a receive interrupt in the first CPU 1 that operates the virtual machine 21 or the second CPU 2 that operates the virtual machine 22, according to the communication setting information 41 stored in the communication setting information storage unit 14.

[0057] When a receive interrupt occurs in the first CPU1 that runs the virtual machine 21 (S305), the first CPU1 accepts the receive interrupt and processes the first receive interrupt receiver 29 of the virtual machine 21 (S306). If no receive interrupt occurs in the first CPU1 (S305), the first CPU1 continues processing the application 26 or the first OS 27.

[0058] When a receive interrupt occurs in the second CPU2 that runs the virtual machine 22 (S307), the second CPU2 accepts the receive interrupt and processes the second receive interrupt receiver 34 of the virtual machine 22 (S308). If no receive interrupt occurs in the second CPU2 (S307), the second CPU2 continues processing application 30, application 31, or the second OS 32.

[0059] Figure 9 shows the effect of the vehicle control device 100A in this embodiment. As in Figure 5, assume that CAN message D with ID 200, used by virtual machine 21 but not by virtual machine 22, is received via CAN transceiver 9. The CAN controller 6 stores CAN message D with ID 200 in the first received data storage unit 131 according to the communication setting information 41 stored in the communication setting information storage unit 14, and also generates a receive interrupt for virtual machine 21 operated by the first CPU 1.

[0060] In the virtual machine 21 operated by the first CPU 1, the first receive interrupt receiver 29 is activated, accesses the first received data storage unit 131 to retrieve the received data, i.e., CAN message D with ID 200, and passes the received data from the first OS 27 to the application 26.

[0061] In this case, unlike in Figure 5, no receive interrupt occurs in the virtual machine 22 operated by the second CPU 2. Therefore, even if the CAN controller 6 receives a CAN message with ID 200, the virtual machine 22 can continue processing application 30, application 31, or the second OS 32. This reduces the number of unnecessary receive interrupts that occurred 4156 times per second in the case of Figure 6.

[0062] Furthermore, in the virtual machine 21 operated by the first CPU 1, the first receive interrupt receiver 29 directly accesses the first received data storage unit 131, eliminating the need for the processing switch (VMExit, VMEntry) between the virtual machine 21 and the hypervisor 20 described above using Figure 4. This shortens the time from when the CAN transceiver 9 receives CAN message D with ID 200 until the received data reaches the application 26, and also reduces the receiving processing load on the first CPU 1. The same effect can be obtained when CAN message D is received that is used by virtual machine 22 but not by virtual machine 21.

[0063] According to this embodiment, by changing the processing of the communication peripheral 50 for each CAN message (data) D used by each of the virtual machines 21 and 22, it is possible to avoid the consumption of processing time of the first CPU 1 and second CPU 2 due to unnecessary receive interrupts when data that the virtual machines 21 and 22 do not use is received. Furthermore, when a CAN message D used by virtual machine 21 is received, the virtual machines 21 and 22 directly access the communication peripheral 50, eliminating the need for processing switching between the virtual machines 21 and 22 and the hypervisor 20, thereby reducing the load on the first CPU 1 and second CPU 2 required for reception and enabling the received data to be transmitted to applications 26, 30, and 31 in a short time.

[0064] With the increasing sophistication and complexity of vehicle control, exemplified by autonomous driving, there is a growing need for the integration of vehicle control systems and the continuous improvement of the vehicle control software installed within them. Consequently, the automotive industry is shifting from the conventional distributed architecture, where a separate vehicle control system is installed for each sensor and actuator, to a centralized, zone-type architecture that integrates several high-performance vehicle control systems.

[0065] In transitioning to a central zone architecture, vehicle control software that was previously installed in different vehicle control systems will now be installed in the same system, making it crucial to establish non-interference between the vehicle control software. Therefore, there is growing interest in introducing virtualization technology (hypervisor) into the vehicle control system that separates the hardware resources used by each vehicle control software, and enables secure sharing of hardware resources that must be shared by multiple vehicle control software systems through methods such as mutual exclusion and time-sharing.

[0066] In this embodiment, the initial setup unit 40 sets communication setting information 41, which specifies the destination virtual machines 21 and 22 for each CAN message (data) D, in the communication peripheral 50, and then starts the hypervisor 20. Based on the communication setting information 41, the communication peripheral 50 generates an interrupt to the virtual machines 21 and 22 when storing the CAN message D. In other words, each of the virtual machines 21 and 22 directly receives the CAN message (data) D from the communication peripheral 50, so latency does not deteriorate.

[0067] Furthermore, the communication peripheral 50 includes multiple first received data storage units 131 and second received data storage units 132, and the first received data storage units 131 and second received data storage units 132 generate interrupts for different virtual machines 21 and 22. The initial setup unit 40 associates the multiple first received data storage units 131 and second received data storage units 132 with each virtual machine 21 and 22, and sets communication setting information 41 in the communication peripheral 50 so that CAN messages (data) D used for calculations of an application running on one of the multiple virtual machines 21 and 22 are stored in either the first received data storage unit 131 or second received data storage unit 132 corresponding to that virtual machine 21 or 22.

[0068] In other words, each virtual machine 21 and 22 can generate a receive interrupt from the communication peripheral 50 only when the CAN message D used by the virtual machine 21 or 22 is received by the communication peripheral 50. If the CAN message D used by the other virtual machines 21 or 22 is received by the communication peripheral 50, no receive interrupt is generated. Therefore, filtering of CAN message D by the first CPU1 and second CPU2 within virtual machines 21 and 22 is unnecessary.

[0069] Furthermore, an interrupt that occurs when a CAN message (data) D is stored in either the first received data storage unit 131 or the second received data storage unit 132 corresponding to a single virtual machine 21 or 22 is input to the single virtual machine 21 or 22 without going through the hypervisor 20, and the single virtual machine 21 or 22 retrieves the CAN message D from either the first received data storage unit 131 or the second received data storage unit 132 corresponding to it.

[0070] In other words, the process of determining whether or not to generate a receive interrupt when CAN message D is received is performed by the communication peripheral 50, not by the first CPU1 or second CPU2. Therefore, the reduction in CPU processing time allocated to task processing of applications 26, 30, 31, etc., within virtual machines 21, 22 can be suppressed.

[0071] Furthermore, the initial setup unit 40 sets the communication setting information 41, which specifies the destination virtual machines 21 and 22 for each CAN message (data) D, in the communication peripheral 50, and then starts the hypervisor 20. Therefore, since the hardware communication peripheral 50 is set before the software hypervisor 20 is started, malfunctions of the vehicle control device 100A can be prevented.

[0072] When the ignition of a vehicle equipped with the vehicle control device 100A is turned on, the initial setup unit 40 sets the communication setting information 41 to the communication peripheral 50 and then starts the hypervisor 20. Therefore, when the ignition of a vehicle in which the vehicle control device 100A is to start is turned on, the hardware communication peripheral 50 is set before the software hypervisor 20 is started, thus preventing malfunctions of the vehicle control device 100A.

[0073] [Example 2] The following describes the vehicle control device according to Embodiment 2. Figure 10 is a diagram showing the detailed software configuration of the vehicle control device 100B in Embodiment 2. The difference between the vehicle control device 100B in this embodiment and the vehicle control device 100A in Embodiment 1 is that the upper limit of the number of communication setting information 41 that can be set in the communication peripheral 50 is less than the number of CAN messages D flowing through the CAN bus 10.

[0074] Furthermore, the initial setup unit 40 determines which CAN message D to set the communication setting information 41 on the communication peripheral 50 based on the priority of each CAN message (data) D. Here, priority refers to the ranking of CAN message D that prioritize setting the communication setting information 41, and the CAN message D with the highest priority will be given priority in setting the communication setting information 41.

[0075] The priority is determined by the reception frequency of CAN message D, and the initial setting unit 40 determines which CAN message to set the communication setting information 41 to the communication peripheral 50, prioritizing CAN message D with the highest reception frequency. Note that components similar to those in Embodiment 1 are denoted by the same reference numerals and their descriptions are omitted.

[0076] The initial setup unit 40 stores the communication setting information 41 in the communication setting information storage unit 14. In this embodiment, 150 CAN messages D flow from other vehicle control devices 11 to the CAN bus 10, and according to the specifications of the CAN controller 6, the communication setting information 41 can be set for 100 CAN messages D.

[0077] As shown in Figure 11, the 150 CAN messages D are arranged in descending order of reception frequency, and the communication setting information is configured for each CAN message D in that order. In the example in Figure 11, CAN messages D with smaller numbers in the priority column have higher priority. Also, in the example in Figure 11, reception frequency refers to the number of CAN messages D received per unit of time.

[0078] For example, CAN message D with ID 012 is received most frequently, and this CAN message D is used only by the virtual machine 21. In this case, the communication setting information 41 is configured to store CAN message D with ID 012 in the first received data storage unit 131.

[0079] The second most frequently received CAN message D is CAN message D with ID 044, and this CAN message D is used only by the virtual machine 22. In this case, the communication setting information 41 is set to store CAN message D with ID 044 in the second received data storage unit 132.

[0080] The 100th most frequently received CAN message D is CAN message D with ID 077, and this CAN message D is not used by either virtual machine 21 or virtual machine 22. In this case, the communication setting information 41 is set so that CAN message D with ID 127 is not stored in either the first received data storage unit 131 or the second received data storage unit 132. As described above, the communication setting information 41 is set for the top 100 most frequently received CAN message D messages.

[0081] In CAN communication, the ID also serves as the priority, and CAN messages D with smaller IDs have higher priority. Therefore, if there are multiple CAN messages D with the same reception frequency, it is best to set the communication setting information 41 starting with the CAN message D with the smaller ID.

[0082] All CAN messages D other than the top 100 most frequently received CAN messages D are configured to be received by the third received data storage unit 133. In other words, as described above regarding the hardware configuration, if there is no communication configuration information 41 stored in the communication configuration information storage unit 14, the CAN controller 6 stores all received CAN messages in the third received data storage unit 133 and generates receive interrupts for all of the first CPU 1, second CPU 2, and third CPU 3. Note that this setting to receive CAN messages D in the third received data storage unit 133 is not communication configuration information 41, which indicates which IDs of CAN messages D applications 26, 30, and 31 included in virtual machines 21 and 22 need to receive, and therefore is not subject to the above-mentioned limitation on the number of configurable communication configuration information 41.

[0083] Furthermore, the first received data storage unit 131 generates a receive interrupt in the first receive interrupt reception unit 29. The second received data storage unit 132 generates a receive interrupt in the second receive interrupt reception unit 34. The third received data storage unit 133 generates a receive interrupt in the receive processing unit 23 of the hypervisor 20.

[0084] In other words, in this embodiment, similar to Embodiment 1, the communication peripheral 50 includes a plurality of first received data storage units 131, second received data storage units 132, and third received data storage units 133. The first received data storage units 131 and second received data storage units 132 generate interrupts for different virtual machines 21 and 22. However, at least one of the plurality of first received data storage units 131, second received data storage units 132, and third received data storage units 133 is a third received data storage unit 133 that does not correspond to any of the virtual machines 21 and 22.

[0085] The third received data storage unit 133, which does not correspond to either virtual machine 21 or 22, generates an interrupt for the hypervisor 20. The initial setup unit 40 configures the communication peripheral 50 so that CAN messages (data) D for which communication setting information 41 was not set are stored in the third received data storage unit 133, which does not correspond to either virtual machine 21 or 22.

[0086] Using Figure 4, in the same procedure as described above, the reception processing unit 23 of the hypervisor 20 copies and stores the CAN message D in the first virtual reception data storage unit 35, and then generates a reception interrupt in the first reception interrupt reception unit 29. Similarly, the reception processing unit 23 performs mutual exclusion control, copies and stores the CAN message D in the second virtual reception data storage unit 36, and then generates a reception interrupt in the second reception interrupt reception unit 34.

[0087] When the first OS27 and the second OS32 retrieve CAN message D from the first virtual received data storage unit 35 and the second virtual received data storage unit 36, they check whether the retrieved CAN message D is data to be used by applications 26, 30, and 31, and then pass CAN message D to applications 26, 30, and 31.

[0088] According to this embodiment, with respect to CAN messages D received by the third received data storage unit 133, there is a possibility that unnecessary receive interrupts may occur in the virtual machines 21 and 22. However, since these CAN messages D are received infrequently, even if there is an upper limit on the number of configurable communication setting information 41, the number of unnecessary receive interrupts will decrease, and the consumption of CPU processing time due to unnecessary receive interrupts will be suppressed.

[0089] [Example 3] The following describes the vehicle control device according to Embodiment 3. The difference between this embodiment and Embodiment 2 is that the communication setting information 41 is set based on the importance assigned to each CAN message (data) D, rather than the reception frequency.

[0090] In other words, in this embodiment, priority is determined by the importance of CAN message D. Importance means, for example, that CAN message D is likely or frequently used in many applications such as applications 26, 30, and 31. The initial setup unit 40 determines which CAN message D to set the communication setting information 41 to the communication peripheral 50, prioritizing them in order of increasing importance. Note that components similar to those in Embodiment 2 are denoted by the same reference numerals and their descriptions are omitted.

[0091] The initial setup unit 40 stores the communication setting information 41 in the communication setting information storage unit 14. In this embodiment, 150 CAN messages D flow from other vehicle control devices 11 to the CAN bus 10, and according to the specifications of the CAN controller 6, the communication setting information 41 can be set for 100 CAN messages D.

[0092] As shown in Figure 12, at this time, the 150 CAN messages D are arranged in descending order of their IDs, and the communication setting information 41 is set for the CAN messages D with the largest IDs first. For example, suppose that the 150 CAN messages D use IDs ranging from 1 to 150. In the example in Figure 12, a smaller number in the importance column indicates a higher importance.

[0093] At this time, for CAN messages D with IDs 150, 149, 148...51, reception rules are set to store them in either the first received data storage unit 131 or the second received data storage unit 132, depending on the virtual machines 21 and 22 that use those CAN messages D.

[0094] Furthermore, if the virtual machines 21 and 22 do not use any of the top 100 least important CAN messages D, the communication setting information 41 is configured to ensure that those CAN messages D are not stored in either the first received data storage unit 131 or the second received data storage unit 132. Similar to the above embodiment 2, all other CAN messages D, except for the top 100 least important CAN messages D, are configured to be received by the third received data storage unit 133.

[0095] In this embodiment, although the CAN messages D received by the third received data storage unit 133 may cause unnecessary receive interrupts for the virtual machines 21 and 22, these CAN messages D are of high importance. Therefore, these CAN messages D are likely to be used or are frequently used by many applications such as applications 26, 30, and 31, and even if these CAN messages D are ultimately unnecessary data, the disadvantage to the virtual machines 21 and 22 is minimal. Accordingly, in this embodiment, even if there is an upper limit on the number of configurable communication setting information 41, the number of occurrences of unnecessary receive interrupts is reduced, and the consumption of CPU processing time due to unnecessary receive interrupts is suppressed.

[0096] [Example 4] The following describes the vehicle control device according to Embodiment 4. Figure 10 is a diagram showing the detailed software configuration of the vehicle control device 100C in Embodiment 4. The difference between the vehicle control device 100C in this embodiment and the vehicle control device 100A in Embodiment 1 is that the vehicle control device 100C receives the update program 44 from the server 42.

[0097] The vehicle control device 100C has an update information receiving unit 43, which is connected to a server 42. The server 42 sends an update program 44 to the update information receiving unit 43 that updates at least one of the virtual machines 21 and 22. The update information receiving unit 43 updates at least one of the virtual machines 21 and 22 according to the update program 44. Note that the server 42 is intended to be a processing device that can send and receive information with a communication device via a communication line, etc., and does not refer to hardware such as a personal computer or embedded information device.

[0098] In addition to the update program 44, the server 42 sends communication configuration information 41 corresponding to the update program 44 to the update information receiving unit 43 along with the update program 44. The communication configuration information 41 corresponding to the update program 44 is the information of CAN message D used by virtual machines 21 and 22, respectively, after the program update.

[0099] The update information receiving unit 43 updates the applications 26, 30, and 31 of the virtual machines 21 and 22 to the update program 44, and also updates the communication setting information 41 used by the initial setup unit 40 to the communication setting information 41 corresponding to the update program 44. In other words, the update information receiving unit 43 sends the communication setting information 41 corresponding to the update program 44 to the initial setup unit 40. The initial setup unit 40 replaces the existing communication setting information 41 and updates the communication setting information stored in the communication setting information storage unit 14 of the CAN controller 6.

[0100] Furthermore, the timing at which the update information receiving unit 43 transmits the communication setting information 41 corresponding to the update program 44 to the initial setting unit 40 may be when the ignition of the vehicle equipped with the vehicle control device 100C is turned on. Also, the timing at which the initial setting unit 40 updates the communication setting information stored in the communication setting information storage unit 14 of the CAN controller 6 may be when the ignition of the vehicle equipped with the vehicle control device 100C is turned on.

[0101] According to this embodiment, even if the software included in the vehicle control device 100C is updated and the CAN message (data) D used by each of the virtual machines 21 and 22 changes, the CPU processing time can continue to be suppressed by avoiding the generation of unnecessary receive interrupts and switching of processing between the hypervisor 20 and the virtual machines 21 and 22.

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

[0103] 1 First CPU 2 Second CPU 3 Third CPU 5 memory 6 CAN controller 7 Internal bus 8 Microcomputers 9 CAN transceiver 10 CAN bus 11. Vehicle control system 12. Data storage section for transmitted data 13 Received data storage unit 14 Communication settings information storage unit 20 Hypervisor 21,22 Virtual Machines 23 Receiving Processing Unit 24 First Transmission Request Processing Unit 25 Second transmission request processing unit 26 Applications 27 First OS 28 First Transmission Request Reception Department 29 First Receive Interrupt Reception Unit 30 Applications 31 Applications 32 Second OS 33 Second Transmission Request Reception Unit 34 Second Receive Interrupt Reception Unit 35 First virtual received data storage unit 36 Second virtual received data storage unit 40 Initial setting section 41 Communication settings information 42 servers 43 Update Information Receiving Unit 44 Updates 50 Communication Peripherals 100A, 100B, 100C Vehicle Control Device 121 First transmission data storage unit 122 Second Transmission Data Storage Unit 123 Third Transmission Data Storage Unit 131 First Received Data Storage Unit 132 Second Received Data Storage Unit 133 Third Received Data Storage Unit 200 Vehicle control system D CAN message (data)

Claims

1. Hypervisor and Multiple virtual machines launched by the aforementioned hypervisor, A communication peripheral that stores data used for calculations of the application running on the virtual machine, The system includes an initial setup unit for starting the hypervisor, The initial setup unit sets the communication setting information specifying the destination virtual machine for each piece of data on the communication peripheral, and then starts the hypervisor. The communication peripheral generates an interrupt to the virtual machine when storing the data, based on the communication configuration information. A vehicle control device characterized by the following features.

2. A vehicle control device according to claim 1, The aforementioned communication peripheral includes multiple received data storage units, The received data storage unit generates interrupts for each of the different virtual machines, The initial setup unit associates a plurality of received data storage units with each of the virtual machines, and sets the communication setting information on the communication peripheral such that the data used for calculations of an application running on one of the plurality of virtual machines is stored in the received data storage unit corresponding to one of the virtual machines. A vehicle control device characterized by the following features.

3. A vehicle control device according to claim 2, An interrupt that occurs when the data is stored in the received data storage unit corresponding to one of the virtual machines is input to the one of the virtual machines without going through the hypervisor. One of the virtual machines acquires the data from the corresponding received data storage unit. A vehicle control device characterized by the following features.

4. A vehicle control device according to claim 1, The initial setup unit determines the data to be set on the communication peripheral based on the priority of each piece of data. A vehicle control device characterized by the following features.

5. A vehicle control device according to claim 4, The aforementioned priority is determined by the frequency of receiving the aforementioned data. The initial setup unit determines the data to set the communication setting information on the communication peripheral, prioritizing the data with the highest reception frequency. A vehicle control device characterized by the following features.

6. A vehicle control device according to claim 4, The aforementioned priority is determined by the importance of the aforementioned data. The initial setup unit determines the data to set the communication setting information on the communication peripheral, prioritizing the data in order of decreasing importance. A vehicle control device characterized by the following features.

7. A vehicle control device according to claim 4, The aforementioned communication peripheral includes multiple received data storage units, The received data storage unit generates interrupts for each of the different virtual machines, At least one of the plurality of received data storage units is a received data storage unit that does not correspond to any of the virtual machines, The received data storage unit, which does not correspond to any of the aforementioned virtual machines, generates an interrupt to the hypervisor. The initial setup unit configures the communication peripheral such that the data for which the communication setting information was not set is stored in the received data storage unit which does not correspond to any of the virtual machines. A vehicle control device characterized by the following features.

8. A vehicle control device according to claim 1, It has an update information receiving unit connected to a server, The server transmits the communication configuration information corresponding to the update program along with the update program to the update information receiving unit. The update information receiving unit updates the application to the update program and updates the communication settings information used by the initial setup unit to the communication settings information corresponding to the update program. A vehicle control device characterized by the following features.

9. A vehicle control device according to claim 1, When the ignition of the vehicle equipped with the vehicle control device is turned on, the initial setup unit sets the communication setting information to the communication peripheral and then starts the hypervisor. A vehicle control device characterized by the following features.

10. Hypervisor and Multiple virtual machines launched by the aforementioned hypervisor, A communication peripheral that stores data used for calculations of the application running on the virtual machine, A communication setting method in a vehicle control device comprising an initial setting unit for activating the hypervisor, The initial setup unit includes the step of setting communication setting information specifying the destination virtual machine for each piece of data on the communication peripheral, After the step of setting the communication setting information on the communication peripheral, the initial setup unit performs the step of starting the hypervisor, Following the step of starting the hypervisor, the communication peripheral generates an interrupt to the virtual machine when storing the data based on the communication configuration information, A communication setting method characterized by comprising the following:

Images