Communication control device, communication control program, and electronic control device
The communication control device addresses inefficient communication between virtual machines by designating a master VM for direct access, facilitating efficient communication and reducing arbitration overhead.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- DENSO CORP
- Filing Date
- 2022-09-27
- Publication Date
- 2026-07-29
AI Technical Summary
Existing communication methods between virtual machines in integrated ECUs do not support efficient communication and increase data transmission time due to arbitration processes.
A communication control device that designates a master virtual machine to access a communication device directly, with other virtual machines communicating via shared memory and a relay unit, eliminating the need for access arbitration between virtual machines.
Enables efficient communication between multiple virtual machines without arbitration processing, reducing data transmission time and software modification effort.
Smart Images
Figure 0007896441000001 
Figure 0007896441000002 
Figure 0007896441000003
Abstract
Description
Technical Field
[0001] The present invention relates to a communication control device for controlling communication by a plurality of virtual machines operating on a computer, a communication control program to be executed by the communication control device, and an electronic control device including the communication control device.
Background Art
[0002] For example, a plurality of electronic control units are mounted on a vehicle such as an automobile, and these plurality of electronic control units communicate with each other and cooperate to perform various processes. In this specification, the electronic control unit may be abbreviated as ECU. In recent years, since the number of ECUs mounted on vehicles has been increasing, a method of integrating a plurality of ECUs into one has been implemented.
[0003] In the integrated ECU, which is an ECU integrated in this way, the functions of a plurality of ECUs that conventionally operated independently are mounted as virtual machines. Patent Document 1 discloses a communication method in an integrated ECU. In the method described in Patent Document 1, when a CAN transmission request arrives from a virtual machine, arbitration is performed in a virtual device that serves as an I / F between the virtual machine and the peripheral devices of the CPU in the integrated ECU, and access is made to the CAN controller. Note that CAN is an abbreviation for Controller Area Network and is a registered trademark.
Prior Art Documents
Patent Documents
[0004]
Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0005] The prior art disclosed in Patent Document 1 does not take into account CAN communication between virtual machines, making it impossible to perform the same type of communication that was performed between ECUs before integration. Furthermore, in the prior art disclosed in Patent Document 1, since transmission requests from virtual machines are arbitrated within the virtual device, the overhead of CAN data transmission time is increased by the time required for this arbitration process.
[0006] The present invention has been made in view of the above circumstances, and its purpose is to provide a communication control device, a communication control program, and an electronic control device that can communicate between multiple virtual machines without requiring access arbitration processing between virtual machines. [Means for solving the problem]
[0007] The communication control device described in claim 1 controls communication between a plurality of virtual machines (10 to 13) operating on a computer (3). In this case, one of the plurality of virtual machines is designated as the master VM (10), and the virtual machines other than the master VM are designated as slave VMs (11 to 13). The communication control device comprises a physical communication driver (7), a virtual communication driver (9), and a relay unit (8). The physical communication driver is provided on the master VM and accesses a communication device (6) for communicating with an external device located outside the computer to send and receive communication data, which is data related to communication between the master VM and the external device. The virtual communication driver is provided on each of the plurality of virtual machines and sends and receives communication data between each of the plurality of virtual machines. The relay unit is provided on the master VM and relays communication between each of the plurality of virtual machines and the external device.
[0008] The computer has shared memory (5) shared by each of the multiple virtual machines. The virtual communication driver virtually sends and receives communication data using the shared memory. When the relay unit receives communication data sent from a slave VM, it performs either a receive process to receive the communication data or a transmit process to send the communication data to an external device via the physical communication driver, depending on the destination of the communication data. Specifically, the relay unit performs a receive process if the destination of the communication data sent from the slave VM is the master VM, and performs a transmit process if the destination is an external device. The computer has a register (23) that stores a flag indicating whether or not a communication data reception interrupt has occurred for each of the multiple virtual machines. When communication data is sent and received between multiple virtual machines, the virtual communication driver of the sending machine, which is the virtual machine that sends the communication data, writes the communication data to shared memory and updates the flag corresponding to the receiving machine, which is the virtual machine that receives the communication data, to indicate that a reception interrupt has occurred. When the flag corresponding to the receiving machine is updated to indicate that a reception interrupt has occurred, the virtual communication driver of the receiving machine reads and receives the communication data written to shared memory.
[0009] In the above configuration, multiple virtual machines consist of a master VM that directly accesses the communication device to communicate with external devices, and slave VMs that communicate with external devices via the master VM without directly accessing the communication device. In other words, in this case, only the master VM among the multiple virtual machines accesses the communication device. To put it another way, in the above configuration, the virtual machines that access the communication device are limited to the master VM. In this way, by limiting the virtual machines that access the communication device with the above configuration, the process of mediating access to the communication device between virtual machines can be eliminated.
[0010] Furthermore, in the above configuration, virtual communication is performed via shared memory between the master VM and the slave VMs, and between the slave VMs themselves, enabling communication between multiple virtual machines. Therefore, this configuration offers the excellent advantage of enabling communication between multiple virtual machines while eliminating the need for access arbitration processing between virtual machines. [Brief explanation of the drawing]
[0011] [Figure 1] This diagram schematically shows the configuration related to communication between an integrated ECU and an external device according to one embodiment. [Figure 2]This figure schematically shows an example of the structure of an interrupt source flag register according to one embodiment. [Figure 3] This diagram schematically shows an example of the configuration of a virtual CAN driver and a CAN_ID filter definition table according to one embodiment. [Figure 4] A diagram illustrating an example of specific operation by relay software according to one embodiment. [Figure 5] This diagram schematically shows the contents of the relay processing performed by the relay software according to one embodiment. [Figure 6] A diagram illustrating an example of receive interrupt control according to one embodiment. [Figure 7] This diagram schematically shows the configuration related to communication between multiple conventional ECUs before they were integrated into a single ECU. [Modes for carrying out the invention]
[0012] The following describes embodiments of the communication control device, communication control program, and electronic control device with reference to the drawings. <Conventional configuration of multiple ECUs> First, the configuration related to communication between multiple conventional ECUs before they are integrated into a single integrated ECU will be explained with reference to Figure 7. In the conventional configuration shown in Figure 7, four ECUs, ECU-A101, ECU-B102, ECU-C103, and ECU-D104, are shown as examples of multiple ECUs mounted in the vehicle. However, the multiple ECUs mounted in the vehicle may be two or three ECUs, or five or more ECUs.
[0013] ECU-A101, ECU-B102, ECU-C103, and ECU-D104 are, for example, the engine ECU, air conditioning ECU, central gateway ECU, and body ECU, and are each independently provided. ECU-A101, ECU-B102, ECU-C103, and ECU-D104 each have one microcomputer 105. In this specification, microcomputer may be abbreviated as microcontroller.
[0014] The microcontroller 105 includes a CPU (not shown in the diagram) and various peripherals as its hardware. These peripherals include a CAN controller 106 for CAN communication. ECU-A101, ECU-B102, ECU-C103, and ECU-D104 are connected via a CAN bus 107, which is a bus communication line, enabling them to communicate with each other via CAN.
[0015] ECU-A101 is equipped with ECU-A application A1 to implement its main function. In this specification, the term "application" may be abbreviated as "app". ECU-B102 is equipped with ECU-B app A2 to implement its main function. ECU-C103 is equipped with ECU-C app A3 to implement its main function. ECU-D104 is equipped with ECU-D app A4 to implement its main function. In the following description, ECU-A app A1, ECU-B app A2, ECU-C app A3, and ECU-D app A4 may be abbreviated as app A1, app A2, app A3, and app A4, respectively.
[0016] ECU-A101, ECU-B102, ECU-C103, and ECU-D104 are all equipped with a CAN driver 108. The CAN driver 108 controls the CAN controller 106 to perform data communication with other ECUs via the CAN bus 107. Applications A1, A2, A3, A4, and the CAN driver 108 are all implemented by the CPU of the microcontroller 105 executing computer programs stored in a non-transitional physical storage medium and performing processing corresponding to those programs; in other words, they are implemented by software.
[0017] In the above configuration, when any one of the ECUs performs CAN communication, the CAN driver 108 provided in that ECU controls the CAN controller 106 to perform data communication. A plurality of ECUs, namely ECU-A 101, ECU-B 102, ECU-C 103, and ECU-D 104, are connected as nodes on the CAN bus 107, and CAN data, which is communication data transmitted onto the CAN bus 107 by any one of them, can be received by all the ECUs connected to the CAN bus 107.
[0018] <Configuration of the integrated ECU of this embodiment> As shown in FIG. 1, the integrated ECU 1 of this embodiment is mounted on a vehicle such as an automobile, and the functions of a plurality of ECUs that conventionally operated independently are mounted on a single chip of a microcomputer 3 via a hypervisor 2. In this case, the functions of the plurality of ECUs are mounted in units of virtual machines. In this specification, the hypervisor may be abbreviated as HV, and the virtual machine may be abbreviated as VM.
[0019] The integrated ECU 1 has functions corresponding to three ECUs, namely ECU-A 101, ECU-B 102, and ECU-C 103, in the conventional configuration. The integrated ECU 1 may have functions corresponding to two ECUs, or may have functions corresponding to four or more ECUs. In this embodiment, the ECU-D 104 is provided independently as in the conventional case without being integrated into the integrated ECU 1. The integrated ECU 1 and the ECU-D 104 are connected via a CAN bus 4, which is a bus communication line, and thereby CAN communication can be performed between them.
[0020] The integrated ECU1 has four VMs: VM10, VM11, VM12, and VM13. In this case, the function of ECU-A101 is realized by VM11, the function of ECU-B102 is realized by VM12, and the function of ECU-C103 is realized by VM13. In other words, in this case, VM11 has application A1, VM12 has application A2, and VM13 has application A3. VM10 has the function of a gateway ECU, but it may have the function of another ECU instead or in addition to it.
[0021] HV2 is used to run VM10 to VM13 on microcontroller 3. Microcontroller 3 is an example of a computer and its hardware includes a CPU (not shown), various peripherals, and shared memory 5 shared by each of the VM10 to VM13. The various peripherals include a CAN controller 6 for CAN communication. The CAN controller 6 is used for CAN communication with an external device located outside microcontroller 3 and is an example of a communication device. In this embodiment, ECU-D104 corresponds to the external device described above. Although not shown, the external device described above includes all ECUs except the integrated ECU 1 connected to the CAN bus 4.
[0022] In this embodiment, one of the four VMs (VM10 to VM13) provided by the integrated ECU1, VM10, is designated as the master VM, while the other VMs (VM11 to VM13) are designated as slave VMs. Therefore, in the following description, VM10 may be referred to as the master VM, and VM11 to VM13 may be collectively referred to as slave VMs.
[0023] VM10 is equipped with a CAN driver 7 and relay software 8. The CAN driver 7 has the same functionality as the conventional CAN driver 108. That is, the CAN driver 7 accesses the CAN controller 6 to send and receive CAN data, which is data related to CAN communication, between VM10 and ECU-D104, and is an example of a physical communication driver. In this embodiment, CAN communication is an example of communication, and CAN data is an example of communication data. The relay software 8 relays CAN communication between each of the multiple VM10 to VM13 and ECU-D104, and is an example of a relay unit.
[0024] Each of VM10 to VM13 is equipped with a virtual CAN driver 9. The virtual CAN driver 9 sends and receives CAN data between each of the VM10 to VM13 and is an example of a virtual communication driver. The virtual CAN driver 9 virtually sends and receives CAN data using shared memory 5. In this case, the virtual CAN driver 9 is mounted on a virtual communication channel module 21 that accesses shared memory 5 to send and receive CAN data. In this specification, the virtual communication channel module may be abbreviated as VCC.
[0025] In this case, VCC21 is included in HV2 and is provided for each of VM10 to VM13. That is, each virtual CAN driver 9 installed in VM10 to VM13 is connected to its corresponding VCC21. With this configuration, for example, CAN data sent by application A1 on VM11 can be sent to application A2 on VM12, application A3 on VM13, and so on. In other words, with this configuration, a virtual CAN bus that enables CAN communication between VM10 to VM13 can be realized.
[0026] In this configuration, a communication control device 22 is configured to control CAN communication by multiple VM10-VM13 operating on the microcontroller 3, using a CAN driver 7 provided on the master VM, virtual CAN drivers 9 provided on each of the multiple VM10-VM13, relay software 8 provided on the master VM, and VCC21 provided on HV2. In this case, the integrated ECU1 is an example of an electronic control unit comprising a microcontroller 3, VM10-VM13 operating on the microcontroller 3, and the communication control device 22.
[0027] In the integrated ECU1 with the above configuration, HV2 and VM10~VM13 are all realized by the CPU of the microcontroller 3 executing computer programs stored in a non-transitional physical storage medium and performing processing corresponding to those computer programs; in other words, they are realized by software. Of the above computer programs, the program that realizes the function of the communication control device 22, that is, the program that the communication control device 22 executes, corresponds to the communication control program.
[0028] Microcontroller 3 is equipped with an interrupt flag register 23. The interrupt flag register 23 is an example of a register that stores interrupt flags, which are flags indicating whether or not a CAN data reception interrupt has occurred for each of VM10 to VM13. Note that in the following explanation, the interrupt flag register may be simply referred to as a register.
[0029] Register 23 has a structure as shown in Figure 2, for example. Specifically, Register 23 contains the interrupt source flag state for each of the interrupt destination VMs, VM10 to VM13. The interrupt source flag state represents the state of the interrupt source flag and is one of two states: "ON," which indicates that a CAN data receive interrupt has occurred, or "OFF," which indicates that a CAN data receive interrupt has not occurred. As will be described in detail later, in the above configuration, CAN data is transmitted and received between VM10 to VM13 by receive interrupt control using the interrupt source flag stored in Register 23.
[0030] In configurations that perform physical CAN communication, such as the conventional configuration shown in Figure 7, each ECU generally has a CAN controller 106 that filters CAN_IDs, thereby discarding CAN data not addressed to itself and receiving only CAN data addressed to itself. However, in a configuration that performs virtual CAN communication, as in the configuration of this embodiment, VM10 to VM13, which have the same functions as conventional ECUs, do not have a CAN controller.
[0031] Therefore, in the configuration of this embodiment, the virtual CAN driver 9 in VM10 to VM13 is provided with a CAN_ID filtering function. In other words, in this case, as shown in Figure 3, the virtual CAN driver 9 in each of VM10 to VM13 is equipped with a CAN_ID filter 24. The CAN_ID filter 24 is an example of a filter that allows CAN data destined for predetermined VMs to pass through among the received CAN data, while discarding other CAN data, and is implemented in software. In the following description, the CAN_ID filter may be simply referred to as a filter.
[0032] In this embodiment, VM10 to VM13 are assigned a CAN_ID, which is identification information representing the destination in each CAN communication. In this case, VM10 is assigned "CAN_ID=0", VM11 is assigned "CAN_ID=1", VM12 is assigned "CAN_ID=2", and VM13 is assigned "CAN_ID=3". In this case, the CAN data is also assigned a CAN_ID to represent its destination.
[0033] For a slave VM, it is basically sufficient to receive only CAN data destined for its own device. Therefore, the filter 24 provided by the slave VM's virtual CAN driver 9 is designed to allow at least CAN data destined for its own device, that is, CAN data whose destination is the CAN_ID of the VM on which it is installed, to pass through, while discarding all other CAN data.
[0034] On the other hand, the master VM not only transmits CAN data addressed to itself, but also relays CAN data to external devices such as the ECU-D, so it is basically necessary to be able to receive all CAN data. Therefore, the filter 24 provided by the master VM's virtual CAN driver 9 is a filter that allows at least CAN data addressed to itself and all CAN data addressed to slave VMs, that is, CAN data whose destination is one of the CAN_IDs from VM11 to VM13, to pass through, while discarding all other CAN data.
[0035] Filter 24 includes a CAN_ID filter definition table that defines which CAN_IDs are passable, i.e., receivable. The CAN_ID filter definition table is as shown in Figure 3, for example. As shown in Figure 3, the CAN_ID filter definition table defines receivable IDs as CAN data with "CAN_ID=1" assigned to it, i.e., CAN data destined for VM11, and CAN data with "CAN_ID=3" assigned to it, i.e., CAN data destined for VM11.
[0036] Thus, filter 24 is equipped with a CAN_ID filter definition table, and it decides whether to pass or discard CAN data according to the definitions in that table. For example, filter 24 equipped with a CAN_ID filter definition table as shown in Figure 3 will pass CAN data with "CAN_ID=1" assigned to it, i.e., CAN data destined for VM11, and discard CAN data with "CAN_ID=2" assigned to it, i.e., CAN data destined for VM12.
[0037] Next, we will explain the communication operation in the integrated ECU1 of the above configuration. [1] Specific examples of operation using relay software When the relay software 8 receives CAN data transmitted from the slave VM, it performs either a receive process to receive the CAN data according to the destination of the CAN data, or a transmit process to send the CAN data to the external device ECU-D via the CAN driver 7. The destination of the CAN data is one of the ECUs other than the integrated ECU1 connected to each VM and the CAN bus 4.
[0038] For example, when CAN data is transmitted from VM11, the CAN data will be transmitted sequentially in the flow shown by the black arrows in Figure 4. That is, the virtual CAN driver 9 of VM11 transmits CAN data via VCC21 and shared memory 5, i.e., transmits CAN data via virtual CAN communication. When the virtual CAN driver 9 of VM10 receives the CAN data transmitted from VM11 via VCC21 and shared memory 5, it transmits the received CAN data to the relay software 8.
[0039] The relay software 8 performs a reception process if the destination of the received CAN data is the master VM, and performs a transmission process if the destination is an external device such as the ECU-D. In the transmission process, the CAN driver 7 of VM10 controls the CAN controller 6 to transmit the CAN data sent from VM11 via virtual CAN communication through the CAN bus 4, that is, via physical CAN communication.
[0040] Each time the relay software 8 receives CAN data, it performs a relay process as shown in Figure 5. First, in step S101, the destination of the received CAN data is confirmed. After step S101, the process proceeds to step S102, where it is determined whether the destination of the CAN data is the master VM. If the destination of the CAN data is the master VM, the result in step S102 is "YES", and the process proceeds to step S103. In step S103, the reception process described above is performed.
[0041] On the other hand, if the destination of the CAN data is not the master VM, that is, if the destination of the CAN data is an external device such as the ECU-D, the result in step S102 is "NO", and the process proceeds to step S104. In step S104, the transmission process described above is executed. After the execution of step S103 or S104, the relay process performed by the relay software 8 is completed.
[0042] [2] Receive interrupt control Receive interrupt control is performed when CAN data is sent and received between VM10 to VM13, and specifically, the control is as follows: First, the virtual CAN driver 9 of the transmitting machine, which is one of the VMs from VM10 to VM13 that sends CAN data, writes the CAN data to shared memory 5. At the same time, the virtual CAN driver 9 of the transmitting machine updates the interrupt source flag corresponding to the receiving machine, which is one of the VMs from VM10 to VM13 that receives CAN data, from "OFF" to "ON". Subsequently, when the interrupt source flag corresponding to the receiving machine is updated from "OFF" to "ON", the virtual CAN driver 9 of the receiving machine reads and receives the CAN data written to shared memory 5.
[0043] For example, when CAN data is sent from VM11 to VM12, receive interrupt control is performed and a receive interrupt occurs as shown in Figure 6. First, as shown in Figure 6 (1), the virtual CAN driver 9 of VM11 writes the CAN data to be sent to the shared memory 5. Next, as shown in Figure 6 (2), the virtual CAN driver 9 of VM11 updates the interrupt source flag in register 23 corresponding to VM12 from "OFF" to "ON".
[0044] As the interrupt source flag is updated in this way, the microcontroller 3 issues an interrupt to VM12, as shown in Figure 6 (3). At this time, the interrupt source flag corresponding to VM12 is reset from "ON" to "OFF" by hardware processing. Then, as shown in Figure 6 (4), the virtual CAN driver 9 of VM12 performs a receive process within the interrupt context, reading and receiving the CAN data written to the shared memory 5.
[0045] According to the embodiment described above, the following effects can be obtained. The multiple VMs provided by the integrated ECU1 of this embodiment consist of VM10, which is a master VM that directly accesses the CAN controller 6 to communicate with external devices, and VM11 to VM13, which are slave VMs that communicate with external devices via the master VM without directly accessing the CAN controller 6.
[0046] In other words, in this case, only VM10, the master VM among the four VMs VM10 to VM13, is able to access the CAN controller 6. To put it another way, in the above configuration, access to the CAN controller 6 is limited to the master VM. Thus, with the above configuration, by limiting which VMs can access the CAN controller 6, the process of mediating access to the CAN controller 6 between VMs can be eliminated.
[0047] Furthermore, in the above configuration, virtual communication is performed between the master VM and the slave VM, and between the slave VMs themselves, via the shared memory 5 of the microcontroller 3, thereby enabling communication between multiple VMs. Therefore, the configuration of this embodiment provides the excellent effect of enabling communication between multiple VMs while eliminating the need for access arbitration processing between VMs.
[0048] In this embodiment, the four VM10 to VM13 are equipped with a virtual CAN driver 9 that virtually sends and receives CAN data using the shared memory 5 of the microcontroller 3. With this configuration, the physical CAN communication that was performed between the ECUs before integration can be replaced with virtual CAN communication via the shared memory 5.
[0049] In this embodiment, the relay software 8 provided by the master VM relays CAN communication between each of VM10 to VM13 and the external device without arbitration when it receives CAN data. Therefore, according to this embodiment, there is virtually no waiting time for CAN communication between each of VM10 to VM13 and the external device.
[0050] The software constituting the integrated ECU1 in this embodiment can be modified only in the parts related to CAN communication compared to the software constituting the ECU before integration shown in Figure 7. Therefore, according to this embodiment, it is possible to localize the parts of the software that need to be changed when integrating ECUs that previously operated independently, thereby reducing the amount of work required for software modification.
[0051] In this embodiment, the virtual CAN driver 9 provided by VM10 to VM13 is mounted on VCC21, which accesses the shared memory 5 of the microcontroller 3 to send and receive CAN data, which is communication data. In this way, VCC21, which is the part that handles communication between VMs, and the communication protocol part are separated, and as a result, even if a protocol other than CAN is applied as the communication protocol, the aforementioned effect of localizing the changes to the software can be obtained.
[0052] In this embodiment, the virtual CAN driver 9 provided by VM10 to VM13 includes a software filter 24 that allows CAN data destined for predetermined VMs to pass through while discarding other CAN data. In other words, in this embodiment, the virtual CAN driver 9 performs processing equivalent to the hardware filtering performed in conventional configurations using physical CAN. This makes it possible to reduce the amount of CAN data processed by applications A1, A2, A3, etc., to the same extent as in conventional configurations using physical CAN.
[0053] (Other embodiments) It should be noted that the present invention is not limited to the embodiments described above and shown in the drawings, and can be arbitrarily modified, combined, or expanded without departing from its essence. The numerical values and other figures shown in the above embodiments are illustrative and not limiting.
[0054] The present invention is not limited to applications that control CAN communication by multiple VMs operating on a microcontroller 3 that constitutes an integrated ECU 1 mounted on a vehicle, but can be applied to all applications that control communication by multiple VMs operating on a computer.
[0055] This disclosure is described in accordance with the embodiments, but it is understood that this disclosure is not limited to such embodiments or structures. This disclosure also includes various modifications and variations within the equivalence. In addition, various combinations and forms, as well as other combinations and forms that include only one, more, or fewer of those elements, fall within the scope and concept of this disclosure.
[0056] The control unit and its method described herein may be implemented by a dedicated computer provided by configuring a processor and memory programmed to perform one or more functions embodied by a computer program. Alternatively, the control unit and its method described herein may be implemented by a dedicated computer provided by configuring a processor by one or more dedicated hardware logic circuits. Alternatively, the control unit and its method described herein may be implemented by one or more dedicated computers configured by a combination of a processor and memory programmed to perform one or more functions and a processor configured by one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by the computer on a computer-readable non-transitional tangible recording medium.
[0057] This disclosure includes, in addition to the invention described in the claims, the following inventions: [1] A communication control device (22) that controls communication between multiple virtual machines (10-13) running on a computer (3), If one of the aforementioned multiple virtual machines is designated as the master VM (10), and the other virtual machines are designated as slave VMs (11-13), A physical communication driver (7) is provided on the master VM and accesses a communication device (6) for communicating with an external device located outside the computer to send and receive communication data, which is data related to the communication, between the master VM and the external device. A virtual communication driver (9) is provided in each of the plurality of virtual machines and sends and receives the communication data between each of the plurality of virtual machines, A relay unit (8) is provided in the master VM and relays communication between each of the plurality of virtual machines and the external device, Equipped with, The computer includes a shared memory (5) shared by each of the multiple virtual machines, The virtual communication driver virtually sends and receives the communication data using the shared memory. The relay unit is a communication control device that, upon receiving the communication data transmitted from the slave VM, performs either a receiving process to receive the communication data according to the destination of the communication data, or a transmitting process to transmit the communication data to the external device via the physical communication driver. [2] The communication control device described in [1] is mounted on a virtual communication channel module (21) that accesses the shared memory to send and receive communication data. [3] The computer includes a register (23) in which a flag is stored indicating whether or not a communication data reception interrupt has occurred for each of the plurality of virtual machines. When the communication data is sent and received between the aforementioned multiple virtual machines, The virtual communication driver of the transmitting machine, which is one of the multiple virtual machines that transmits the communication data, writes the communication data to the shared memory and updates the flag corresponding to the receiving machine, which is one of the multiple virtual machines that receives the communication data, to a state indicating that a receive interrupt has occurred. The communication control device according to [1] or [2], wherein the virtual communication driver of the receiving machine reads and receives the communication data written to the shared memory when the flag corresponding to the receiving machine is updated to indicate that a receive interrupt has occurred. [4] The communication control device according to any one of the claims [1] to [3], wherein the virtual communication driver includes a software filter (24) that allows predetermined communication data destined for the virtual machine to pass through the received communication data and discards the other communication data. [5] The communication control device described in [4], wherein the filter provided in the virtual communication driver of the master VM allows all communication data destined for the slave VMs to pass through. [Explanation of Symbols]
[0058] 1...Integrated ECU, 2...Hypervisor, 3...Microcomputer, 5...Shared memory, 6...CAN controller, 7...CAN driver, 8...Timer, 10-13...Virtual machine, 23...Interrupt source flag register, 24...CAN_ID filter.
Claims
1. A communication control device (22) that controls communication between multiple virtual machines (10 to 13) running on a computer (3), If one of the above-mentioned multiple virtual machines is designated as the master VM (10), and the other virtual machines are designated as slave VMs (11-13), A physical communication driver (7) is provided on the master VM and accesses a communication device (6) for communicating with an external device located outside the computer to send and receive communication data, which is data related to the communication, between the master VM and the external device. A virtual communication driver (9) is provided in each of the plurality of virtual machines and sends and receives the communication data between each of the plurality of virtual machines, A relay unit (8) is provided in the master VM and relays communication between each of the plurality of virtual machines and the external device, Equipped with, The computer includes a shared memory (5) shared by each of the multiple virtual machines, The virtual communication driver virtually sends and receives the communication data using the shared memory. When the relay unit receives the communication data transmitted from the slave VM, it performs either a receiving process to receive the communication data according to the destination of the communication data, or a transmitting process to transmit the communication data to the external device via the physical communication driver. The computer includes a register (23) in which a flag is stored indicating whether or not a communication data reception interrupt has occurred for each of the plurality of virtual machines. When the communication data is sent and received between the aforementioned multiple virtual machines, The virtual communication driver of the transmitting machine, which is one of the multiple virtual machines that transmits the communication data, writes the communication data to the shared memory and updates the flag corresponding to the receiving machine, which is one of the multiple virtual machines that receives the communication data, to a state indicating that a receive interrupt has occurred. The virtual communication driver of the receiving machine is a communication control device that reads and receives the communication data written to the shared memory when the flag corresponding to the receiving machine is updated to indicate that a receive interrupt has occurred.
2. The communication control device according to claim 1, wherein the virtual communication driver is mounted on a virtual communication channel module (21) that accesses the shared memory to send and receive communication data.
3. The communication control device according to claim 1 or 2, wherein the virtual communication driver includes a software filter (24) that allows predetermined communication data destined for the virtual machine to pass through the received communication data and discards the other communication data.
4. The communication control device according to claim 3, wherein the filter provided in the virtual communication driver of the master VM allows all communication data destined for the slave VM to pass through.
5. A communication control program to be executed by a communication control device (22) that controls communication by multiple virtual machines (10 to 13) running on a computer (3), If one of the above-mentioned multiple virtual machines is designated as the master VM (10), and the other virtual machines are designated as slave VMs (11-13), The communication control device includes a physical communication driver (7) that accesses a communication device (6) provided on the master VM for communicating with an external device located outside the computer, and sends and receives communication data, which is data related to the communication, between the master VM and the external device. The computer includes a shared memory (5) shared by each of the multiple virtual machines, For each of the plurality of virtual machines, a process is performed to implement the function of a virtual communication driver (9) that sends and receives the communication data between each of the plurality of virtual machines, The master VM is given a process to enable it to function as a relay unit (8) that relays communication between each of the multiple virtual machines and the external device, Make it run, The virtual communication driver virtually sends and receives the communication data using the shared memory. When the relay unit receives the communication data transmitted from the slave VM, it performs either a receiving process to receive the communication data according to the destination of the communication data, or a transmitting process to transmit the communication data to the external device via the physical communication driver. The computer includes a register (23) in which a flag is stored indicating whether or not a communication data reception interrupt has occurred for each of the plurality of virtual machines. When the communication data is sent and received between the aforementioned multiple virtual machines, The virtual communication driver of the transmitting machine, which is one of the multiple virtual machines that transmits the communication data, writes the communication data to the shared memory and updates the flag corresponding to the receiving machine, which is one of the multiple virtual machines that receives the communication data, to a state indicating that a receive interrupt has occurred. The virtual communication driver of the receiving machine is a communication control program that reads and receives the communication data written to the shared memory when the flag corresponding to the receiving machine is updated to indicate that a receive interrupt has occurred.
6. An electronic control device (1) comprising a computer (3), a plurality of virtual machines (10 to 13) operating on the computer, and a communication control device (22) that controls communication between the plurality of virtual machines, If one of the above-mentioned multiple virtual machines is designated as the master VM (10), and the other virtual machines are designated as slave VMs (11-13), The communication control device is A physical communication driver (7) is provided on the master VM and accesses a communication device (6) for communicating with an external device located outside the computer to send and receive communication data, which is data related to the communication, between the master VM and the external device. A virtual communication driver (9) is provided in each of the plurality of virtual machines and sends and receives the communication data between each of the plurality of virtual machines, A relay unit (8) is provided in the master VM and relays communication between each of the plurality of virtual machines and the external device, Equipped with, The computer includes a shared memory (5) shared by each of the multiple virtual machines, The virtual communication driver virtually sends and receives the communication data using the shared memory. When the relay unit receives the communication data transmitted from the slave VM, it performs either a receiving process to receive the communication data according to the destination of the communication data, or a transmitting process to transmit the communication data to the external device via the physical communication driver. The computer includes a register (23) in which a flag is stored indicating whether or not a communication data reception interrupt has occurred for each of the plurality of virtual machines. When the communication data is sent and received between the aforementioned multiple virtual machines, The virtual communication driver of the transmitting machine, which is one of the multiple virtual machines that transmits the communication data, writes the communication data to the shared memory and updates the flag corresponding to the receiving machine, which is one of the multiple virtual machines that receives the communication data, to a state indicating that a receive interrupt has occurred. The virtual communication driver of the receiving machine is an electronic control device that reads and receives the communication data written to the shared memory when the flag corresponding to the receiving machine is updated to indicate that a receive interrupt has occurred.