Monitoring device and monitoring method

Abstract

An integrated ECU (200) that is a monitoring device comprises: a virtual command generation unit (120) that acquires a physical signal and converts the physical signal into a virtual command; a virtual command notification unit (110) that transmits the virtual command to a control virtual machine (VM100); and a virtual command preparation unit (140) that, after the virtual command has been transmitted to the control virtual machine (VM100) by the virtual command notification unit (110), causes a first command monitoring unit (130a) to carry out monitoring of the virtual command.

Description

Technical Field

[0001] The present disclosure relates to a monitoring device and a monitoring method for monitoring, for example, commands.

Background Art

[0002] The monitoring device of Patent Document 1 monitors a virtual machine to be monitored on virtual software using a virtual machine for monitoring on the virtual software. For example, the monitoring device verifies the virtual machine to be monitored and the hypervisor from the virtual machine for monitoring at predetermined time intervals and obtains the verification results.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the monitoring device of Patent Document 1 described above, since verification is performed at predetermined time intervals, if an unauthorized command is transmitted to the virtual machine during that time interval, it is difficult to immediately detect the abnormality of the command. On the other hand, if the predetermined time interval is shortened, that is, if the commands transmitted to the virtual machine are sequentially monitored in advance, there is a possibility that a delay will occur in the transmission of the commands.

[0005] Therefore, the present disclosure provides a monitoring device and the like that can suppress communication delays caused by sequential monitoring of commands.

Means for Solving the Problems

[0006] A monitoring device according to one aspect of the present disclosure is a monitoring device for monitoring virtual commands, which are commands to a virtual machine, and comprises: a virtual command generation unit that acquires a physical signal and converts the physical signal into a virtual command; a virtual command notification unit that transmits the virtual command to the virtual machine; and a virtual command preparation unit that, after the virtual command has been transmitted to the virtual machine by the virtual command notification unit, causes a command monitoring unit to perform monitoring of the virtual command.

[0007] These comprehensive or specific embodiments may be implemented as a system, method, integrated circuit, computer program, or recording medium such as a computer-readable CD-ROM, or as any combination of a system, method, integrated circuit, computer program, and recording medium. Furthermore, the recording medium may be a non-temporary recording medium. [Effects of the Invention]

[0008] The monitoring device of this disclosure can suppress communication delays caused by sequential monitoring of commands.

[0009] Further advantages and effects of one aspect of this disclosure will be made apparent from the specification and drawings. Such advantages and / or effects are provided by several embodiments and configurations described in the specification and drawings, but not all configurations are necessarily provided to obtain those advantages and effects. [Brief explanation of the drawing]

[0010] [Figure 1] Figure 1 is an overall diagram of the monitoring system in the embodiment. [Figure 2] Figure 2 is a block diagram showing an example of the configuration of an integrated ECU in an embodiment. [Figure 3] Figure 3 is a block diagram showing in detail some of the configurations of the integrated ECU in the embodiment. [Figure 4] Figure 4 shows an example of a virtual command in the embodiment. [Figure 5] Figure 5 shows an example of the internal configuration of a virtual command in an embodiment. [Figure 6] Figure 6 is a block diagram showing an example of a detailed configuration of a virtualization platform in an embodiment. [Figure 7] Figure 7 is a block diagram showing an example of the configuration of the virtual command preparation unit in the embodiment. [Figure 8] Figure 8 is a flowchart showing an example of processing operation by the virtualization platform of the integrated ECU in the embodiment. [Figure 9] Figure 9 shows an example of virtual command duplication by the virtual command notification unit in the embodiment. [Figure 10] Figure 10 is a flowchart showing an example of a delayed processing task performed by the virtual command preparation unit in the embodiment. [Figure 11] Figure 11 shows an example of a log recorded by the virtual command preparation unit in the embodiment. [Figure 12] Figure 12 is a flowchart showing an example of the monitoring switching process by the virtual command preparation unit in the embodiment. [Figure 13] Figure 13 is a block diagram showing an example of a detailed configuration of a virtualization platform in a modified embodiment. [Figure 14] Figure 14 is a block diagram showing an example of the configuration of the virtual command preparation unit in a modified embodiment. [Figure 15] Figure 15 is a block diagram showing an example of the configuration of the virtual command generation unit in a modified embodiment. [Figure 16] Figure 16 is a flowchart showing an example of processing operation by the virtualization platform of the integrated ECU in a modified embodiment. [Figure 17] Figure 17 is a sequence diagram showing the processing operation by multiple components included in the integrated ECU in a modified example of the embodiment. [Figure 18]FIG. 18 is a diagram showing an example of an image displayed on a display by a screen output unit of a video virtual machine in a modification of the embodiment.

MODE FOR CARRYING OUT THE INVENTION

[0011] (Knowledge on which the present disclosure is based) In the monitoring device of Patent Document 1 described above, as described above, it is difficult to immediately detect an abnormality. And if the commands transmitted to the virtual machine are sequentially monitored in advance, there is a possibility that a delay will occur in the transmission of those commands. Also, a technique has been proposed for detecting unauthorized communication by replicating packets such as commands input to the mirror port and monitoring the replicated packets. That is, that technique is a technique for performing port mirroring in an IDS (Intrusion Detection System). However, this port mirroring has a problem that an overhead associated with replication occurs.

[0012] In order to solve such problems, a monitoring device according to one aspect of the present disclosure is a monitoring device that monitors virtual commands that are commands to a virtual machine, and includes a virtual command generation unit that acquires a physical signal and converts the physical signal into the virtual command, a virtual command notification unit that transmits the virtual command to the virtual machine, and a virtual command preparation unit that causes a command monitoring unit to execute monitoring of the virtual command after the virtual command has been transmitted to the virtual machine by the virtual command notification unit.

[0013] Thereby, since the monitoring of the virtual command is delayed and the virtual command is transmitted first, it is possible to suppress the communication delay caused by the sequential monitoring of the virtual command. Also, when it is determined that the virtual command is abnormal after the virtual command has been transmitted first, it is possible to appropriately suppress the occurrence or spread of an abnormality by prohibiting the transmission of subsequent virtual commands having the same characteristics as the virtual command.

[0014] Furthermore, when the virtual command preparation unit causes the command monitoring unit to perform monitoring of the virtual commands, it may access a buffer storing at least a portion of each of the one or more virtual commands, determine whether an identifier indicating that monitoring will be performed after transmission to the virtual machine is attached to at least a portion of each of the one or more virtual commands, and cause the command monitoring unit to perform monitoring of the virtual commands to which the identifier is attached.

[0015] This allows for the correct identification of virtual commands that are to be monitored, and prevents unnecessary processing such as monitoring virtual commands that are not intended for monitoring.

[0016] Furthermore, the virtual command preparation unit may determine whether the buffer's storage area has been reused, and if it determines that it has been reused, it may record that a virtual command was missed.

[0017] This allows for proper management of virtual commands.

[0018] Furthermore, the virtual command notification unit may duplicate a portion of the virtual command, assign the identifier to the duplicated portion of the virtual command, and store the portion of the virtual command to which the identifier has been assigned in the buffer.

[0019] This reduces the overhead associated with replication.

[0020] The embodiments will be described in detail below with reference to the drawings.

[0021] The embodiments described below are all comprehensive or specific examples. The numerical values, shapes, materials, components, arrangement and connection configurations of components, steps, and the order of steps shown in the following embodiments are examples only and are not intended to limit this disclosure. Furthermore, among the components in the following embodiments, those not described in the independent claim representing the highest-level concept will be described as optional components.

[0022] Furthermore, each figure is a schematic diagram and not necessarily a strictly accurate representation. Also, the same reference numeral is used for the same component in each figure.

[0023] (Embodiment) Figure 1 is an overall diagram of the monitoring system in this embodiment.

[0024] The monitoring system in this embodiment comprises a communication base station 1, a web server 2, a monitoring module management server 3, a monitoring server 4, and an in-vehicle system 20.

[0025] The communication base station 1 is connected to the web server 2, the monitoring module management server 3, the monitoring server 4, and the in-vehicle system 20, and relays communication between each of these servers and the in-vehicle system 20. These may be connected via an external network. For example, the external network is the internet. The communication method of the external network may be wired or wireless. The wireless communication method may be an existing technology such as Wi-Fi (registered trademark), 3G / LTE (Long Term Evolution), Bluetooth (registered trademark), or V2X communication method. The web server 2 provides, for example, a website related to unauthorized communications. The monitoring module management server 3 manages, for example, the monitoring modules in the in-vehicle system 20. The monitoring server 4 monitors for unauthorized or abnormal activity in the in-vehicle system 20. For example, the monitoring server 4 is a device that acquires monitoring results, which are information regarding the security status of the in-vehicle system 20, from the in-vehicle system 20 and displays the monitoring results using a graphical user interface. The monitoring server 4 is used, for example, at the security operations center, where security analysts can review the monitoring results and consider countermeasures such as software updates if an anomaly occurs in the in-vehicle system 20.

[0026] The in-vehicle system 20 is a device that controls communication, controls the vehicle, outputs video, monitors the security status of the in-vehicle system 20, and notifies the monitoring server 4 of the security status monitoring results. In Figure 1, only one in-vehicle system 20 is shown, but one or more in-vehicle systems 20 may each send security status monitoring results to the monitoring server 4.

[0027] The in-vehicle system 20 includes an integrated ECU 200, a gateway ECU 300, a steering ECU 400a, a brake ECU 400b, a Zone ECU 500, a front camera ECU 600a, and a rear camera ECU 600b.

[0028] The integrated ECU 200 and the gateway ECU 300 are connected via CAN40, which is a type of network protocol called CAN (Control Area Network). The network protocol used here is not limited to CAN; it may also be a network protocol used in automotive systems, such as CAN-FD or the FlexRay protocol.

[0029] Furthermore, the gateway ECU300, the steering ECU400a, and the brake ECU400b are connected via CAN41.

[0030] Furthermore, the integrated ECU200 and ZoneECU500 are connected via Ethernet 50, which is a type of network protocol called Ethernet (trademarked). Ethernet 50 is, for example, the SOME / IP (Scalable Service-Oriented Middleware over IP) protocol. The network protocol used here does not have to be SOME / IP; it may be any network protocol used in automotive systems, such as SOME / IP-SD or CAN-XL.

[0031] Furthermore, ZoneECU500, front camera ECU600a, and rear camera ECU600b are connected via Ethernet 51. Ethernet 51 may use the same network protocol as Ethernet 50, or it may use a different network protocol.

[0032] Furthermore, the integrated ECU 200, web server 2, monitoring module management server 3, and monitoring server 4 are connected via an external network, communication base station 1, etc.

[0033] The integrated ECU 200 is an ECU that performs communication control, sending and receiving messages via an external network, communication base station 1, CAN 40, and Ethernet 50; vehicle control, instructing the gateway ECU 300 and Zone ECU 500 to control the vehicle via CAN 40 and Ethernet 50; and video output to the infotainment system and instrument panel. The integrated ECU 200 also monitors the security status of the integrated ECU 200 and notifies the monitoring server 4 of the monitoring results. In this embodiment, the integrated ECU 200 is an example of a monitoring device, and its details will be described later.

[0034] The gateway ECU 300 is an ECU that mediates messages sent and received between the integrated ECU 200 and the steering ECU 400a and brake ECU 400b.

[0035] The steering ECU 400a is an ECU that controls the steering of the vehicle using the steering wheel. The brake ECU 400b is an ECU that controls the brakes installed in the vehicle.

[0036] The in-vehicle system 20 uses ECUs that control the vehicle's engine and body, in addition to the steering ECU 400a and brake ECU 400b, to control the vehicle's acceleration, turning, and braking.

[0037] The ZoneECU500 is an ECU that mediates messages sent and received between the integrated ECU200 and the front camera ECU600a and rear camera ECU600b. The front camera ECU600a is an ECU that acquires video from a camera mounted at the front of the vehicle that captures the area in front of the vehicle. The rear camera ECU600b is an ECU that acquires video from a camera mounted at the rear of the vehicle that captures the area behind the vehicle.

[0038] Although Figure 1 only shows the front camera ECU and rear camera ECU, advanced driver assistance functions such as autonomous driving, adaptive cruise control, and automatic parking may be implemented using ECUs that collect various sensor information such as GPS. Furthermore, the messages mentioned above may be packets or commands.

[0039] Figure 2 is a block showing an example of the configuration of the integrated ECU200.

[0040] The integrated ECU200 includes a network interface N1, a virtualization platform 100, a control virtual machine VM100, a video virtual machine VM200, and a monitoring virtual machine VM300. Note that the control virtual machine VM100, the video virtual machine VM200, and the monitoring virtual machine VM300 may each be collectively referred to as "virtual machines" below.

[0041] Network interface N1 has the function of providing a communication interface between server 5 and virtualization platform 100. Server 5 includes at least one of the following: web server 2, monitoring module management server 3, and monitoring server 4.

[0042] The virtualization platform 100 is a virtual software infrastructure such as a hypervisor, and is software that runs and manages one or more virtual machines. Generally, hypervisors are classified into two types: Type 1, which is a bare-metal hypervisor, and Type 2, which is a host-based hypervisor. In embedded systems, Type 1 is generally used to account for the processing overhead of the hypervisor. Because Type 1 hypervisors have a small code size, they are less likely to contain vulnerabilities and can be assumed to be more reliable compared to applications and virtual machines. The virtualization platform 100 may also be a hypervisor that utilizes a MicroKernel. In this case, the virtualization platform 100 is implemented as a process. In the case of a Type 1 virtualization platform 100, it is implemented as a process of the service OS (Operating System), that is, as a process of one virtual machine. In this embodiment, the type of the virtualization platform 100 is not particularly limited and may be any type.

[0043] The virtualization platform 100 comprises a first virtual device C100, a second virtual device C200, a third virtual device C300, a physical device control unit C400, and a storage device M1. The first virtual device C100, the second virtual device C200, and the third virtual device C300 may each be collectively referred to as a virtual device below.

[0044] The physical device control unit C400 is connected to the server 5 via the network interface N1, and further connected to the first virtual device C100, the second virtual device C200, and the third virtual device C300. Such a physical device control unit C400 controls, for example, communication between the server 5 and the first virtual device C100, the second virtual device C200, and the third virtual device C300.

[0045] The storage device M1 holds monitoring modules to be loaded into the first virtual device C100, the second virtual device C200, and the third virtual device C300, respectively. During the initialization of the virtualization platform 100, the multiple monitoring modules held in storage device M1 are associated with the first virtual device C100, the second virtual device C200, and the third virtual device C300, respectively, according to a configuration file. This configuration file defines which monitoring module is configured for which virtual device. Furthermore, multiple monitoring modules may be loaded and deployed within a single virtual device.

[0046] The first virtual device C100, the second virtual device C200, and the third virtual device C300 are connected to the control virtual machine VM100, the video virtual machine VM200, and the monitoring virtual machine VM300, respectively. These virtual devices monitor and control communication between the physical device control unit C400 and the virtual machines.

[0047] The control virtual machine VM100 is an operating system that runs the control application A100 using the first virtual driver D100. The control application A100 is an application software program that communicates with the gateway ECU300 via CAN40 and controls the driving operations of a vehicle equipped with the in-vehicle system 20.

[0048] The video virtual machine VM200 is an operating system that runs the video application A200 using the second virtual driver D200. The video application A200 is an application software program that communicates with ZoneECU500 via Ethernet 50, acquires camera footage, and outputs the footage to the infotainment system, instrument panel, head-up display, etc. The camera footage is also used as information to realize advanced driver assistance functions such as autonomous driving.

[0049] The monitoring virtual machine VM300 is an operating system that runs the monitoring application A300 using the third virtual driver D300. The monitoring application A300 is an application software program that monitors virtual machines other than the monitoring virtual machine VM300, the virtualization platform 100, etc.

[0050] In this embodiment, the integrated ECU 200 employs, for example, paravirtualization technology (virtio). This paravirtualization technology provides a standard interface to virtual machines on the virtualization platform 100, enabling high-speed communication with physical devices (storage, network devices, etc.) to which the virtualization platform 100 connects.

[0051] Figure 3 is a block diagram that shows in detail some of the components of the integrated ECU200.

[0052] For example, as shown in Figure 3, the first virtual device C100 of the virtualization platform 100 includes a virtual command receiving unit C101 and a virtual command transmitting unit C102. The virtual command receiving unit C101 receives virtual commands transmitted from the first virtual driver D100 of the control virtual machine VM100, converts the virtual commands into, for example, physical signals, and transmits the physical signals to the physical device control unit C400.

[0053] The virtual command transmission unit C102 receives a physical signal transmitted from the physical device control unit C400, converts the physical signal into a virtual command, and sends the virtual command to the first virtual driver D100 of the control virtual machine VM100. The first virtual driver D100 receives the virtual command. The virtual command transmission unit C102 also monitors the virtual command, for example, using a monitoring module loaded into the virtual command transmission unit C102. Based on the monitoring results, the virtual command transmission unit C102 may determine whether the state of the virtual command or the first virtual device C100 is normal or abnormal, and notify the screen output unit 11 of the video virtual machine VM200 of the abnormal determination result.

[0054] The video virtual machine VM200 operates the screen output unit 11. The screen output unit 11 displays the abnormality detection result notified by the virtual command transmission unit C102 on the display installed in the vehicle. For example, the screen output unit 11 reflects the abnormality detection result in the icon displayed on the display. Such abnormality detection results may be notified to the screen output unit 11 periodically.

[0055] Figure 4 shows an example of a virtual command.

[0056] For example, multiple virtual commands generated by the conversion by the virtual command transmission unit C102 are stored in a buffer within the virtualization platform 100 or the virtual command transmission unit C102. These virtual commands include a number such as a sequence number, a header for the command type, header h1, header h2, and payload, as shown in Figure 4, for example. The header for the command type indicates the command type, such as file operation, packet transmission, or packet reception. Header h1 indicates whether the virtual command is a delayed command or a normal command. A delayed command is a virtual command whose monitoring is delayed, or a replicated virtual command. A normal command is a virtual command whose monitoring is not delayed. Alternatively, a normal command is a virtual command that has not been replicated, or the original virtual command from which it was replicated. Header h2 indicates the destination or source of the virtual command. The destination or source may be a storage device or an external ECU. The payload includes the file path, data, steering control data, control values, update details, binary data, etc. Furthermore, the buffer for recording virtual commands can be implemented using a ring buffer or a list structure, allowing for the storage of multiple commands. Additionally, providing separate buffers for sending, receiving, and saving data enables efficient data processing.

[0057] Figure 5 shows an example of the internal structure of a virtual command.

[0058] A virtual command includes multiple parameters and communication data. These parameters may indicate the sequence number described above, or they may be included in a command type header, such as header h1 or header h2. The parameters may also indicate the data size of the virtual command. Furthermore, the parameters may indicate the status of the virtual command. The status indicates whether the memory area for the virtual command stored in the buffer is occupied, and whether the virtual command is a delayed command. In other words, part of the status is indicated by the aforementioned header h1.

[0059] The communication data is stored in the payload described above. For example, the communication data includes L2 headers, L3 headers, L4 headers, and data. The L2 header is the MAC (Media Access Control address) header, the L3 header is the IP (Internet Protocol) header, and the L4 header is the TCP (Transmission Control Protocol) header. The data indicates the file path, control value, etc., as described above.

[0060] Such virtual commands may also be sent as packets.

[0061] Figure 6 is a block diagram showing an example of a detailed configuration of the virtualization platform 100.

[0062] As described above, the virtualization platform 100 includes a virtual command transmission unit C102 and a physical device control unit C400, as well as an anomaly response unit 150. The anomaly response unit 150 receives notification of an anomaly determination result from the virtual command transmission unit C102. If the notified anomaly determination result indicates an anomaly, the anomaly response unit 150 prohibits the transmission of virtual commands corresponding to that anomaly determination result, i.e., virtual commands following the virtual command determined to be an anomaly, to the virtual machine. In other words, the anomaly response unit 150 prohibits the transmission of virtual commands to the virtual machine by the virtual command generation unit 120 and the virtual command notification unit 110, which will be described later. The anomaly response unit 150 may also record a log indicating the anomaly determination result.

[0063] The virtual command transmission unit C102 comprises a virtual command notification unit 110, a virtual command generation unit 120, a virtual command preparation unit 140, and a first command monitoring unit 130a. The virtual command generation unit 120 receives a physical signal from the physical device control unit C400 and converts that physical signal into a virtual command. In other words, a virtual command is generated by this conversion. The virtual command generation unit 120 then transmits the virtual command to the virtual command notification unit 110. Alternatively, the virtual command generation unit 120 may store the generated virtual command in a buffer provided in, for example, the virtual command transmission unit C102.

[0064] The virtual command notification unit 110 receives a virtual command from the virtual command generation unit 120 and sends the virtual command to the first virtual driver D100 of the control virtual machine VM100. In other words, the virtual command notification unit 110 notifies the first virtual driver D100 of the virtual command. When the virtual command notification unit 110 notifies the first virtual driver D100 of the virtual command, it decides whether or not to delay the monitoring of the virtual command by the first command monitoring unit 130a. If it decides to delay the monitoring, the virtual command notification unit 110 sends the virtual command to the first virtual driver D100 before any monitoring is performed on that virtual command. On the other hand, if it decides not to delay the monitoring, the virtual command notification unit 110 waits without sending the virtual command so that monitoring of the virtual command is performed before sending the virtual command to the first virtual driver D100. Then, after the monitoring is performed, the virtual command notification unit 110 sends the virtual command to the first virtual driver D100. Such a virtual command notification unit 110 can be said to include a monitoring delay determination unit in order to determine whether or not to delay monitoring. Alternatively, the virtual command notification unit 110 may determine whether or not to delay monitoring based on the above-mentioned parameters of the virtual command.

[0065] Furthermore, the virtual command notification unit 110 saves and duplicates the virtual command in order to have the first command monitoring unit 130a monitor it. The duplicated virtual command is treated as the delayed command described above. The virtual command notification unit 110 changes the parameters of the duplicated virtual command to parameters that indicate a delayed command. In other words, the virtual command notification unit 110 marks the delayed command. The virtual command notification unit 110 may duplicate all virtual commands generated by the virtual command generation unit 120, or it may duplicate only one of the multiple virtual commands each time multiple virtual commands are generated.

[0066] Furthermore, the transmission and reception of virtual commands within the virtual command transmission unit C102 may be performed, for example, via a buffer provided in the virtual command transmission unit C102.

[0067] The virtual command preparation unit 140 reserves a memory area for the virtual command generated by the virtual command generation unit 120 so that the virtual command is stored in the buffer. This completes the preparation of the virtual command. Furthermore, the virtual command preparation unit 140 retrieves the virtual command stored in the buffer as a delayed command and causes the first command monitoring unit 130a to monitor that virtual command. At this time, if there are other command monitoring units besides the first command monitoring unit 130a, the virtual command preparation unit 140 may switch the command monitoring unit used for monitoring. In this case, it can be said that the virtual command preparation unit 140 also has a first monitoring switching unit. In addition, the processing by the virtual command preparation unit 140 for monitoring the virtual command is performed in parallel with the transmission of other virtual commands by the virtual command notification unit 110.

[0068] Figure 7 is a block diagram showing an example of the configuration of the virtual command preparation unit 140.

[0069] The virtual command preparation unit 140 comprises a receive buffer initialization unit 141, a delayed command determination unit 142, a first monitoring switching unit 143, and a first monitoring call unit 144. The receive buffer initialization unit 141 initializes a memory area to secure a memory area for storing virtual commands in the buffer. The receive buffer initialization unit 141 then notifies the virtual command generation unit 120 of the address of the initialized memory area. As a result, the virtual command generation unit 120 stores the generated virtual command in the memory area of ​​the buffer specified by the notified address.

[0070] The delayed command determination unit 142 determines whether or not a delayed command is included in the one or more virtual commands stored in the buffer. If the delayed command determination unit 142 determines that a delayed command is included, it retrieves the delayed command from the buffer and outputs it to the first monitoring switching unit 143. The first monitoring switching unit 143 identifies the first command monitoring unit 130a as the command monitoring unit corresponding to that delayed command. The first monitoring switching unit 143 then causes the first monitoring call unit 144, which is associated with the first command monitoring unit 130a, to execute a call to the first command monitoring unit 130a. The first monitoring call unit 144 calls the first command monitoring unit 130a, and the called first command monitoring unit 130a monitors the delayed command. The buffer memory area where the monitored delayed command was stored is treated as a target for initialization by the receive buffer initialization unit 141.

[0071] Furthermore, if the virtual command transmission unit C102 has multiple command monitoring units, the virtual command preparation unit 140 may have multiple monitoring call units that are associated one-to-one with those multiple command monitoring units. In this case, the first monitoring switching unit 143 switches the command monitoring unit used to monitor the delayed command by selecting one command monitoring unit for the delayed command from among the multiple command monitoring units. The first monitoring switching unit 143 then causes the monitoring call unit associated with the selected command monitoring unit to execute a call to that command monitoring unit. As a result, the called command monitoring unit monitors the delayed command.

[0072] Figure 8 is a flowchart illustrating an example of the processing operation of the integrated ECU 200 by the virtualization platform 100. In this disclosure, the virtualization platform 100 may be described as a virtualization PF, as shown in Figure 8.

[0073] First, the virtualization platform 100 initializes a variable N that indicates the order in which virtual commands will be generated (step S1). For example, the virtualization platform 100 initializes the variable N to N=1. Then, the virtualization platform 100 creates a memory area for the virtual command N within the buffer (step S2). The virtual command N is the Nth virtual command indicated by the variable N mentioned above.

[0074] Next, the virtual command preparation unit 140 performs processing on the virtual command (N-1) (step S3). That is, the virtual command preparation unit 140 performs processing to cause the first command monitoring unit 130a to monitor the virtual command (N-1). The virtual command (N-1) is the (N-1)th virtual command. Also, if N-1=0, step S3 is skipped. Specifically in step S3, the virtual command preparation unit 140 determines whether the delayed command, which is the saved and duplicated virtual command (N-1), exists in the buffer. This determination may be based on whether or not the virtual command (N-1) is marked. Whether or not there is a marking may be whether or not the virtual command is indicated as a delayed command by the header h1 in Figure 4 or the parameters in Figure 5.

[0075] Next, the physical device control unit C400 receives a physical signal N from the network interface N1 (step S4). The physical signal N is a signal for generating a virtual command N, a signal that forms the basis of the virtual command N, or a signal before conversion to a virtual command N. The virtual command generation unit 120 then receives the physical signal N from the physical device control unit C400 and converts the physical signal N into a virtual command N (step S5).

[0076] Next, the virtual command notification unit 110 determines whether to delay monitoring of virtual command N, and if it does, it saves and duplicates the virtual command N. Furthermore, the virtual command notification unit 110 notifies the virtual command preparation unit 140 that the duplicated virtual command N has been stored in the buffer as a delayed command. At this time, the virtual command notification unit 110 increments the aforementioned variable N and sends the virtual command to a virtual machine, such as the control virtual machine VM100 (step S6).

[0077] The virtualization platform 100 then determines whether or not to terminate the process (step S7). If it determines not to terminate (No in step S7), it repeatedly executes the process from step S2. On the other hand, if the virtualization platform 100 determines to terminate the process (Yes in step S7), it terminates that process.

[0078] As described above, the monitoring device, which is the integrated ECU 200 in this embodiment, is a monitoring device that monitors virtual commands, which are commands to a virtual machine, and comprises a virtual command generation unit 120, a virtual command notification unit 110, and a virtual command preparation unit 140. The virtual command generation unit 120 acquires a physical signal and converts that physical signal into a virtual command. The virtual command notification unit 110 sends the virtual command to the virtual machine. After the virtual command has been sent to the virtual machine by the virtual command notification unit 110, the virtual command preparation unit 140 causes the command monitoring unit to perform monitoring of that virtual command.

[0079] This delays the monitoring of virtual commands, allowing them to be sent first, thus suppressing communication delays caused by sequential monitoring of virtual commands. Furthermore, if a virtual command is determined to be abnormal after it has been sent, the transmission of subsequent virtual commands with similar characteristics can be prohibited, thereby appropriately suppressing the occurrence or escalation of the abnormality. In other words, even though it is difficult to completely prevent the transmission of virtual commands determined to be abnormal to virtual machines, it is possible to perform sequential monitoring of virtual commands while eliminating communication delays. To put it another way, it is possible to appropriately monitor virtual commands while suppressing a decrease in communication performance.

[0080] Furthermore, in this embodiment, when the virtual command preparation unit 140 instructs the command monitoring unit to monitor virtual commands, it accesses a buffer that stores at least a portion of each of one or more virtual commands. The virtual command preparation unit 140 then determines whether an identifier indicating that monitoring will be performed after transmission to the virtual machine is attached to at least a portion of each of the one or more virtual commands. The identifier is, for example, a parameter indicating that the virtual command is a delayed command. The virtual command preparation unit 140 then instructs the command monitoring unit to monitor the virtual commands to which the identifier is attached. This makes it possible to correctly identify the virtual commands to be monitored and suppress the occurrence of unnecessary processing such as monitoring virtual commands that are not to be monitored.

[0081] Figure 9 shows an example of virtual command duplication by the virtual command notification unit 110.

[0082] As shown in Figure 9, the virtual command notification unit 110 may duplicate the entire virtual command, or it may duplicate only a part of the virtual command. For example, the virtual command notification unit 110 may duplicate only the part of the virtual command other than the communication data, i.e., multiple parameters. Alternatively, the virtual command notification unit 110 may duplicate only the multiple parameters and the area containing the L2 header and L3 header of the communication data. Note that the multiple parameters may also include parameters indicating the communication direction of the packet.

[0083] For example, the virtual command notification unit 110 may switch the scope of its replication depending on the buffer usage (or load). Specifically, if the buffer usage is below a threshold, the virtual command notification unit 110 replicates the entire virtual command. On the other hand, if the buffer usage is above a threshold, the virtual command notification unit 110 may replicate only a portion of the virtual command. Alternatively, if the first command monitoring unit 130a is executing a behavior detection algorithm that does not require inspection of all virtual commands, the processing load can be reduced by decreasing the frequency of selecting virtual commands to be inspected or monitored.

[0084] In this embodiment, the virtual command notification unit 110 duplicates a portion of the virtual command, assigns the aforementioned identifier to the duplicated portion of the virtual command, and stores the portion of the virtual command to which the identifier is assigned in a buffer. This reduces the overhead associated with duplication. The identifier assigned at this time is a parameter indicating that the virtual command is a delayed command, as described above. If a parameter indicating that the virtual command is a normal command is already assigned to the virtual command, the virtual command notification unit 110 overwrites that parameter with the aforementioned identifier when duplicating a portion of the virtual command. In other words, the virtual command notification unit 110 marks the portion of the duplicated virtual command.

[0085] Figure 10 is a flowchart showing an example of a delayed processing task performed by the virtual command preparation unit 140.

[0086] First, the virtual command preparation unit 140 reads the parameters of the virtual command in the buffer (step S11). Then, based on the parameters it reads, the virtual command preparation unit 140 determines whether or not the memory area of ​​the virtual command in the buffer has been reused (step S13). For example, if the flag or sequence number, which is a parameter it reads, does not match the flag or sequence number of another virtual command, the virtual command preparation unit 140 determines that the memory area of ​​that virtual command has been reused. In other words, it is determined that there is a corrupted virtual command due to the reuse of that memory area. The reuse of memory area may also be determined by numerical checks such as the checksum of the virtual command, or by comparing the saved command with the command before saving.

[0087] Here, if the virtual command preparation unit 140 determines that the virtual command has already been reused (Yes in step S13), it records that there are missing parameters in the virtual command (step S15). On the other hand, if the virtual command preparation unit 140 determines that the virtual command has not already been reused (No in step S13), it processes the virtual command with the loaded parameters as a normal virtual command (step S14). In other words, the virtual command preparation unit 140 has the command monitoring unit perform monitoring of the virtual command and records the log.

[0088] Figure 11 shows an example of a log recorded by the virtual command preparation unit 140.

[0089] For example, in step S15 of Figure 10, the virtual command preparation unit 140 records that there was a virtual command missed at the timestamp "1.00020" as "Packet Missed," as shown in Figure 11.

[0090] Thus, in this embodiment, the virtual command preparation unit 140 determines whether or not the buffer's storage area has been reused, and if it determines that it has been reused, it records that a virtual command was missed. This allows for proper management of virtual commands.

[0091] Figure 12 is a flowchart showing an example of the monitoring switching process performed by the virtual command preparation unit 140.

[0092] First, the first monitoring switching unit 143 sets the variable M to 1 (step S21). Next, the first monitoring switching unit 143 causes the Mth monitoring call unit to call the Mth command monitoring unit (step S22). The Mth monitoring call unit is the Mth monitoring call unit defined by the variable M. If M=1, the Mth monitoring call unit is the first monitoring call unit 144. Similarly, the Mth command monitoring unit is the Mth command monitoring unit defined by the variable M. If M=1, the Mth command monitoring unit is the first command monitoring unit 130a. Next, the first monitoring switching unit 143 determines whether or not the Mth command monitoring unit exists as a result of the call in step S22 (step S23). If the first monitoring switching unit 143 determines that the Mth command monitoring unit does not exist (No. in step S23), it terminates the monitoring switching process. On the other hand, if the first monitoring switching unit 143 determines that the M command monitoring unit exists (Yes in step S23), it further determines whether or not that M command monitoring unit is registered as an executable command monitoring unit (step S24).

[0093] If the first monitoring switch unit 143 determines that the M command monitoring unit is registered as an executable command monitoring unit (Yes in step S24), it causes the M command monitoring unit to perform virtual command monitoring via the M monitoring call unit (step S25). The first monitoring switch unit 143 then increments the variable M (step S26). On the other hand, if the first monitoring switch unit 143 determines in step S24 that the M command monitoring unit is not registered as an executable command monitoring unit (No in step S24), it skips the process in step S25 and executes the process in step S26. After the first monitoring switch unit 143 finishes the process in step S26, it repeats the process from step S22 onwards.

[0094] (modified version) Figure 13 is a block diagram showing an example of a detailed configuration of the virtualization platform 100 in this modified example.

[0095] In this modified example, the virtual command generation unit 120 of the virtualization platform 100, like the virtual command preparation unit 140, calls a command monitoring unit and instructs the command monitoring unit to perform monitoring of virtual commands. In this modified example, the virtualization platform 100 further includes a second command monitoring unit 130b as a command monitoring unit called by the virtual command generation unit 120. Here, if there are other command monitoring units besides the second command monitoring unit 130b as command monitoring units called by the virtual command generation unit 120, the virtual command generation unit 120 may switch the command monitoring unit used for monitoring. In this case, it can also be said that the virtual command generation unit 120 includes a second monitoring switching unit.

[0096] For example, each of the multiple command monitoring units, including the first command monitoring unit 130a and the second command monitoring unit 130b, may perform different types of monitoring. In one specific example, the second command monitoring unit 130b monitors all virtual commands. More specifically, the second command monitoring unit 130b performs monitoring based on pattern matching used in IDS (Intrusion Detection System) or IPS (Intrusion Prevention System). On the other hand, the first command monitoring unit 130a monitors only a portion of the virtual commands. For example, the first command monitoring unit 130a may record statistics on the communication of virtual commands and perform monitoring processing on the results of those statistics. Alternatively, the first command monitoring unit 130a and the second command monitoring unit 130b may divide the work between monitoring that requires blocking of virtual commands for IPS and monitoring that does not require blocking of virtual commands for IDS. Furthermore, the first command monitoring unit 130a may continuously measure virtual commands and generate monitoring rules, and the second command monitoring unit 130b may execute a process (IDS / IPS) to detect abnormal commands. This prevents the virtual command generation unit 120 from being delayed by the monitoring rule generation process, which is not critical to delays.

[0097] Thus, in this modified example, different monitoring functions, such as the first command monitoring unit 130a and the second command monitoring unit 130b, coexist. For example, the data areas within virtual commands monitored by the first command monitoring unit 130a and the second command monitoring unit 130b may be different from each other. In one specific example, the first command monitoring unit 130a may monitor the Ethernet frame (trademark registered) of the virtual command, and the second command monitoring unit 130b may monitor the VirtIO header of the virtual command. Alternatively, the first command monitoring unit 130a and the second command monitoring unit 130b may monitor different data sections of virtual commands.

[0098] Figure 14 is a block diagram showing an example of the configuration of the virtual command preparation unit 140 in this modified example. Figure 15 is a block diagram showing an example of the configuration of the virtual command generation unit 120 in this modified example.

[0099] The virtual command preparation unit 140 further includes a second monitoring call unit 145, as shown in Figure 14. In the example in Figure 14, a configuration is shown in which the first command monitoring unit 130a is called.

[0100] As shown in Figure 15, the virtual command generation unit 120 includes a receive buffer initialization unit 121, a delayed command determination unit 122, a second monitoring switching unit 123, a first monitoring call unit 144, and a second monitoring call unit 145. The second monitoring call unit 145 calls the second command monitoring unit 130b, and the called second command monitoring unit 130b monitors delayed commands. In the example in Figure 15, a configuration in which the second command monitoring unit 130b is called is shown.

[0101] Furthermore, the receive buffer initialization unit 121, the delayed command determination unit 122, and the second monitoring switching unit 123, all provided in the virtual command generation unit 120, perform the same processing as the receive buffer initialization unit 141, the delayed command determination unit 142, and the first monitoring switching unit 143, all provided in the virtual command preparation unit 140. In other words, when the virtual command generation unit 120 generates a virtual command, it generates a delayed command by duplicating the virtual command for monitoring purposes. This delayed command is stored in a buffer. The delayed command determination unit 122 determines whether or not a delayed command is included among the one or more virtual commands stored in the buffer. If the delayed command determination unit 122 determines that a delayed command is included, it retrieves the delayed command from the buffer and outputs it to the second monitoring switching unit 123.

[0102] The second monitoring switching unit 123 identifies the second command monitoring unit 130b as the command monitoring unit corresponding to the delayed command. The second monitoring switching unit 123 then causes the second monitoring call unit 145, which is associated with the second command monitoring unit 130b, to call the second command monitoring unit 130b. The second monitoring call unit 145 calls the second command monitoring unit 130b, and the called second command monitoring unit 130b monitors the delayed command. The virtual command generation unit 120 then sends a virtual command to the virtual command notification unit 110 if the monitoring by the second command monitoring unit 130b determines that the delayed command is not abnormal. In other words, in this modified example, when a virtual command is generated, monitoring of that virtual command by the second command monitoring unit 130b is performed before the processing in the above embodiment is executed.

[0103] The receive buffer initialization unit 121 initializes the memory area of ​​the buffer where the monitored delayed command was stored. This initialized memory area is then used to store subsequent virtual commands or delayed commands.

[0104] Alternatively, the virtual command generation unit 120 may have the second command monitoring unit 130b monitor the physical signal before it is converted into a virtual command, rather than generating a virtual command. In this case, when the virtual command generation unit 120 receives a physical signal transmitted from the physical device control unit C400, it stores the physical signal in a buffer. Then, if monitoring is performed on the physical signal, the virtual command generation unit 120 generates a delayed signal by duplicating the physical signal and stores the delayed signal in the buffer. The delayed command determination unit 122 determines whether the physical signal stored in the buffer is a delayed signal. The virtual command generation unit 120 then has the second command monitoring unit 130b monitor the delayed signal instead of generating a delayed command.

[0105] Figure 16 is a flowchart showing an example of the processing operation of the integrated ECU 200 by the virtualization platform 100 in this modified example.

[0106] In this modified example, the virtualization platform 100 executes the processes of steps S1 to S4, S6, and S7 shown in Figure 8 of the above embodiment. In this modified example, the virtualization platform 100 executes the process of step S5a instead of the process of step S5 shown in Figure 8.

[0107] Specifically, in step S4, when the physical signal N is received by the physical device control unit C400 (step S4), the virtual command generation unit 120 converts the physical signal N into a virtual command N (step S5a). At this time, the virtual command generation unit 120 uses the second monitoring switching unit 123 to cause the second command monitoring unit 130b to perform monitoring of the virtual command. The virtual command that is the target of this monitoring can also be said to be a delayed command. If the monitoring determines that the virtual command is not abnormal, the virtualization platform 100 executes the processes of steps S6 and S7, as in the embodiment described above. As mentioned above, in step S5a, a physical signal may be monitored instead of a virtual command.

[0108] Figure 17 is a sequence diagram showing the processing operation by multiple components included in the integrated ECU 200 in this modified example. The multiple components of the integrated ECU 200 are the physical device control unit C400, the transmission processing unit 160, the first command monitoring unit 130a, the second command monitoring unit 130b, the abnormality response unit 150, and the first virtual driver D100. The transmission processing unit 160 is a component that includes the virtual command notification unit 110, the virtual command generation unit 120, and the virtual command preparation unit 140 within the virtual command transmission unit C102.

[0109] First, in this modified example, the physical device control unit C400 identifies the virtual command (step S101). Specifically, when the physical device control unit C400 receives a physical signal, it determines whether or not a delay in monitoring is necessary for the virtual command generated from that physical signal. In the above embodiment, the determination of whether or not to delay such monitoring is made by the virtual command notification unit 110, but as in this modified example, it may be made by the physical device control unit C400 or by other components. Also, in the example shown in Figure 17, it is determined in step S101 that a delay in the monitoring process is unnecessary.

[0110] Next, the transmission processing unit 160 selects a monitoring program (step S102). The monitoring program is, for example, the monitoring module described above. In step S102, the transmission processing unit 160 selects, for example, two monitoring programs. Next, the transmission processing unit 160 selects a method for calling the selected monitoring program (step S103). That is, the transmission processing unit 160 selects a method for calling the second command monitoring unit 130b, which will perform monitoring using the selected monitoring program. This selects the second monitoring call unit 145. Then, the transmission processing unit 160 calls the monitoring program using that call method (step S104). In other words, the transmission processing unit 160 calls the second command monitoring unit 130b using the second monitoring call unit 145. The called second command monitoring unit 130b performs monitoring of virtual commands using the selected monitoring program described above (step S105).

[0111] Next, the transmission processing unit 160 selects a method for calling the remaining monitoring program from the two monitoring programs selected in step S102 (step S106). In other words, the transmission processing unit 160 selects a method for calling the first command monitoring unit 130a, which will perform monitoring using that remaining monitoring program. This selects the first monitoring call unit 144. Then, the transmission processing unit 160 calls the monitoring program using that call method (step S107). In other words, the transmission processing unit 160 calls the first command monitoring unit 130a using the first monitoring call unit 144. The called first command monitoring unit 130a performs monitoring of virtual commands using the remaining monitoring program described above (step S108).

[0112] Then, if the transmission processing unit 160 determines that a virtual command is abnormal based on the monitoring in steps S105 and S108, it calls an abnormality response application, which is an application software program (step S109). This call invokes the abnormality response unit 150, which uses the abnormality response application. As a result, the abnormality response unit 150 performs abnormality response processing (S110). The abnormality response unit 150 performs abnormality response processing based, for example, on the abnormality determination results of the first command monitoring unit 130a and the second command monitoring unit 130b. Specifically, the transmission processing unit 160 performs filtering using the IP address, TCP session, virtual machine (VM) ID, etc., of the virtual command determined to be abnormal, for example, on multiple virtual commands stored in a buffer. Then, the transmission processing unit 160 sends the virtual command obtained through this filtering to the server 5. Note that such filtering may be performed on data other than virtual commands.

[0113] Next, once the above-mentioned abnormality handling process is completed, or once the monitoring process in steps S105 and S108 determines that the virtual command is normal, the transmission processing unit 160 sends the virtual command to the virtual machine (step S111). In a specific example, the transmission processing unit 160 sends it to the first virtual driver D100 of the control virtual machine VM100. Upon receiving the virtual command, the first virtual driver D100 executes the processing corresponding to that virtual command (step S112).

[0114] Figure 18 shows an example of an image displayed on a screen by the screen output unit 11 of the video virtual machine VM200. The display may be a display installed in a vehicle equipped with the in-vehicle system 20, or it may be a display of a mobile device or the like.

[0115] For example, the screen output unit 11 displays an indicator e1 on the display that indicates the abnormality detection result, as shown in Figure 18(a). If the abnormality detection result indicates an abnormality, the screen output unit 11 displays a red indicator e1, and if the abnormality detection result indicates a normal condition, the screen output unit 11 displays a green indicator e1. The screen output unit 11 may also display a string on the display that indicates the abnormality detection result and the content of the abnormality response process, as shown in Figure 18(b). For example, the string may be an alert message such as "Communication has been blocked because an abnormality was detected in the video equipment." Note that the image shown in Figure 18 may be displayed on the display not only in this modified example but also in the above embodiment.

[0116] The monitoring device of this disclosure has been described above based on the embodiments and their modifications, but this disclosure is not limited to these embodiments and modifications. Any modifications to the embodiments and modifications that a person skilled in the art could conceive of, without departing from the spirit of this disclosure, may also be included in this disclosure.

[0117] In the above embodiments, each component may be implemented by dedicated hardware or by executing a software program suitable for each component. Each component may also be implemented by a program execution unit such as a CPU (Central Processing Unit) or processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory. Here, the software that implements the monitoring device, etc., in each of the above embodiments is a computer program that causes a computer to execute each step of the flowchart or sequence diagram shown in Figures 8, 10, 12, 16, and 17, respectively.

[0118] The following cases are also included in this disclosure.

[0119] (1) The at least one device described above is specifically a computer system consisting of a microprocessor, ROM, RAM, hard disk unit, display unit, keyboard, mouse, etc. A computer program is stored in the RAM or hard disk unit. The at least one device described above achieves its function by the operation of the microprocessor in accordance with the computer program. Here, the computer program is composed of a combination of multiple instruction codes that indicate instructions to the computer in order to achieve a predetermined function.

[0120] (2) Some or all of the components constituting at least one of the above-described devices may be made up of a single system LSI (Large Scale Integration). The system LSI is a multi-functional LSI manufactured by integrating multiple components onto a single chip, and specifically, it is a computer system comprising a microprocessor, ROM, RAM, etc. The RAM stores a computer program. The system LSI achieves its function by operating the microprocessor in accordance with the computer program.

[0121] (3) Some or all of the components constituting at least one of the above-described devices may consist of an IC card or a standalone module that is detachable from the device. The IC card or module is a computer system consisting of a microprocessor, ROM, RAM, etc. The IC card or module may include the above-described multi-function LSI. The IC card or module achieves its function by the operation of the microprocessor in accordance with a computer program. The IC card or module may be tamper-resistant.

[0122] (4) The disclosure may also be the methods described above. Alternatively, it may be a computer program that implements these methods using a computer, or a digital signal consisting of a computer program.

[0123] Furthermore, this disclosure may also refer to a computer program or digital signal recorded on a computer-readable recording medium, such as a flexible disk, hard disk, CD (Compact Disc)-ROM, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray® Disc), semiconductor memory, etc. Alternatively, it may refer to a digital signal recorded on such a recording medium.

[0124] Furthermore, this disclosure may also include the transmission of computer programs or digital signals via telecommunications lines, wireless or wired communication lines, networks such as the Internet, data broadcasting, etc.

[0125] Alternatively, the program or digital signal may be carried out by another independent computer system by recording and transferring it on a recording medium, or by transferring the program or digital signal via a network or the like. [Industrial applicability]

[0126] The monitoring device described herein can be applied, for example, to electronic equipment mounted in a vehicle. [Explanation of symbols]

[0127] 1. Communication base station 2 Web Server 3. Monitoring module management server 4. Monitoring Server 5 servers 11. Screen output section 20 In-vehicle systems 40, 41 CAN 50, 51 Ethernet 100 virtualization platforms 110 Virtual Command Notification Unit 120 Virtual Command Generation Unit 121 Receive buffer initialization section 122 Delay command determination unit 123 Second Monitoring Switching Unit 130a First Command Monitoring Unit 130b Second Command Monitoring Unit 140 Virtual Command Preparation Unit 141 Receive buffer initialization section 142 Delay command determination unit 143 First Monitoring Switching Unit 144 1st monitoring call section 145 2nd monitoring call section 150 Anomaly Response Department 160 Transmission Processing Unit 200 Integrated ECU (Monitoring Unit) 300 Gateway ECUs 400a Steering ECU 400b Brake ECU 500 Zone ECU 600a Front Camera ECU 600b Rear Camera ECU A100 Control App A200 Video App A300 Monitoring App C100 First Virtual Device C101 Virtual Command Receiver C102 Virtual Command Sending Unit C200 Second Virtual Device C300 3rd Virtual Device C400 Physical Device Control Unit D100 1st Virtual Driver D200 Second Virtual Driver D300 3rd Virtual Driver h1, h2 headers M1 Storage Device N1 Network Interface VM100 Control Virtual Machine VM200 Video Virtual Machine VM300 monitoring virtual machine

Claims

1. A monitoring device that monitors virtual commands, which are commands to virtual machines, A virtual command generation unit that acquires a physical signal and converts the physical signal into a virtual command, A virtual command notification unit that sends the virtual command to the virtual machine, After the virtual command is sent to the virtual machine by the virtual command notification unit, the virtual command preparation unit causes the command monitoring unit to perform monitoring of the virtual command, A monitoring device equipped with the following features.

2. The virtual command preparation unit, When the command monitoring unit is instructed to monitor the virtual command, Access a buffer that stores at least a portion of each of one or more virtual commands, Determine whether at least a portion of each of the one or more virtual commands is assigned an identifier indicating that monitoring will be performed after it is sent to the virtual machine. The command monitoring unit is instructed to monitor the virtual command to which the identifier has been assigned. The monitoring device according to claim 1.

3. The virtual command preparation unit further, Determine whether the memory area of ​​the buffer has been reused, and if it has been reused, record that a virtual command was lost. The monitoring device according to claim 2.

4. The virtual command notification unit further, A portion of the virtual command is duplicated, the identifier is assigned to the duplicated portion of the virtual command, and the portion of the virtual command to which the identifier has been assigned is stored in the buffer. The monitoring device according to claim 2 or 3.

5. A monitoring method for monitoring virtual commands, which are commands issued to virtual machines, A physical signal is acquired, and the physical signal is converted into the virtual command. The virtual command is sent to the virtual machine, After the virtual command is sent to the virtual machine, the command monitoring unit is instructed to monitor the virtual command. Monitoring method.

Images