WO2023238444A1 - 監視装置及び監視方法 - Google Patents

監視装置及び監視方法 Download PDF

Info

Publication number
WO2023238444A1
WO2023238444A1 PCT/JP2023/004470 JP2023004470W WO2023238444A1 WO 2023238444 A1 WO2023238444 A1 WO 2023238444A1 JP 2023004470 W JP2023004470 W JP 2023004470W WO 2023238444 A1 WO2023238444 A1 WO 2023238444A1
Authority
WO
WIPO (PCT)
Prior art keywords
monitoring
command
virtual machine
monitoring program
control unit
Prior art date
Application number
PCT/JP2023/004470
Other languages
English (en)
French (fr)
Inventor
亮 平野
吉治 今本
Original Assignee
パナソニックＩｐマネジメント株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニックＩｐマネジメント株式会社 filed Critical パナソニックＩｐマネジメント株式会社
Priority to JP2023573307A priority Critical patent/JP7426640B1/ja
Publication of WO2023238444A1 publication Critical patent/WO2023238444A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines

Definitions

  • the present disclosure relates to a monitoring device and a monitoring method that monitor, for example, commands.
  • the monitoring device of Patent Document 1 uses a monitoring virtual machine on virtual software to monitor a virtual machine to be monitored on virtual software. For example, the monitoring device verifies the virtual machine and hypervisor to be monitored from the monitoring virtual machine at predetermined time intervals, and obtains the verification results.
  • the monitoring device of the present disclosure can monitor commands to ensure that no detections are missed.
  • FIG. 9 is a diagram illustrating an example of a flowchart of the monitoring program determination process in the embodiment.
  • FIG. 10 is a diagram illustrating an example of a flowchart of the monitoring program calling process in the embodiment.
  • FIG. 11 is a diagram illustrating an example of a flowchart of a process for determining a timeout period of a monitoring program according to an embodiment.
  • FIG. 12 is a diagram illustrating another example of a flowchart of the monitoring program determination process in the embodiment.
  • FIG. 13 is a diagram illustrating an example of a flowchart for determining the order of monitoring programs and executing the monitoring programs in the embodiment.
  • FIG. 14 is a diagram illustrating an example of a flowchart of abnormality handling processing in the embodiment.
  • Patent Document 1 The monitoring device disclosed in Patent Document 1 can detect abnormalities in other virtual machines as long as the monitoring virtual machine is not hijacked. It is difficult to respond to communications, resulting in missed detections.
  • a monitoring device in a virtualization platform that operates two or more virtual machines, and the monitoring device is a monitoring device that operates two or more virtual machines.
  • one or more monitoring programs that monitor commands sent or received by the process operate in a first virtual machine, and the monitoring device operates in a second virtual machine different from the first virtual machine.
  • a command reception unit that receives a command sent or received by a process
  • a configuration information acquisition unit that acquires configuration information of the second virtual machine
  • a monitoring program control unit that determines an execution method of the one or more monitoring programs according to the characteristics of the command, and a monitoring program control unit that obtains monitoring results of the monitoring program and detects the abnormality when the monitoring results include an abnormality. and an anomaly response unit that notifies the user.
  • the system further includes a system status acquisition unit that acquires a system status of the second virtual machine, and the monitoring program control unit further determines an execution method for the one or more monitoring programs according to the system status. Good too.
  • the execution method of one or more monitoring programs is further determined according to the system state of the second virtual machine, it is possible to execute appropriate monitoring processing according to the state of the second virtual machine.
  • the processing load of the monitoring process can be adjusted, and the monitoring process can be implemented in consideration of the real-time nature of commands, and the monitoring process for commands can be executed efficiently and effectively.
  • the execution method of the monitoring program includes at least one of the following: whether or not the monitoring program is valid, a method of calling the monitoring program, a timeout period set in the monitoring program, and an execution order of the monitoring program. It may be one.
  • the processing load of the monitoring process can be adjusted, and the monitoring process can be implemented in consideration of the real-time nature of commands.
  • the abnormality handling unit may further aggregate or tally logs indicating an abnormality of the command according to the characteristics of the command.
  • the invention further includes two or more of the monitoring program control units, and the one or more monitoring programs for the command are configured to control the one or more monitoring programs for the command when it is determined that the destination of the command is a virtual machine on the virtualization platform.
  • the execution method may be determined by one or more of the two or more monitoring program control units determined based on the identifier included in the command and the configuration information.
  • the monitoring process can be shared between two or more monitoring program control units based on the identifier and configuration information included in the command. Therefore, delays can be suppressed.
  • the two or more monitoring program control units may determine an execution method for the one or more monitoring programs depending on a system state of the second virtual machine.
  • a first monitoring program control unit assigns a first identifier to the command
  • a second monitoring program control unit assigns a first identifier to the command.
  • the execution method of the one or more monitoring programs may be determined depending on whether or not the monitoring program exists.
  • a monitoring method is a monitoring method using a monitoring device in a virtualization platform that operates two or more virtual machines, wherein the monitoring device is configured to monitor processes that are transmitted or transmitted from among the two or more virtual machines.
  • One or more monitoring programs that monitor received commands run on one running virtual machine, and the monitoring method acquires commands sent or received by a process running on a virtual machine different from the one virtual machine.
  • obtain configuration information of the virtual machine refer to characteristics of the command from an identifier included in the command, determine an execution method for the one or more monitoring programs, and obtain monitoring results of the monitoring program; , notifies you of an abnormality.
  • FIG. 1 is an overall configuration diagram of a monitoring system in an embodiment.
  • the external network 30 is, for example, the Internet.
  • the communication method of the external network 30 may be wired or wireless. Further, the wireless communication method may be the existing technology Wi-Fi (registered trademark), 3G/LTE (Long Term Evolution), Bluetooth (registered trademark), or V2X communication method.
  • the monitoring server 10 is a device that acquires monitoring results, which are information regarding the security state 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 10 is used, for example, by a security analyst at a security operation center to check monitoring results and consider countermeasures such as software updates when an abnormality occurs in the in-vehicle system 20.
  • the in-vehicle system 20 is a device that performs communication control, vehicle control, video output, etc., monitors the security state of the in-vehicle system 20, and notifies the monitoring server 10 of the security state monitoring results. Although only one in-vehicle system 20 is shown in FIG. 1, each of the one or more in-vehicle systems 20 transmits the monitoring result of the security state to the monitoring server 10. Details of the in-vehicle system 20 will be described later.
  • the integrated ECU 200 and the gateway ECU 300 are connected via a CAN 40, which is a type of CAN (Control Area Network) network protocol.
  • the network protocol used here is not limited to CAN, but may be a network protocol used in an in-vehicle system such as CAN-FD or FlexRay protocol.
  • gateway ECU 300 the steering ECU 400a, and the brake ECU 400b are connected via the CAN 41.
  • Ethernet 50 is a type of network protocol called Ethernet (registered trademark).
  • the Ethernet 50 is, for example, SOME/IP (Scalable Service-Oriented Middleware over IP) protocol.
  • SOME/IP Scalable Service-Oriented Middleware over IP
  • the network protocol used here does not have to be SOME/IP, but may be a network protocol used in an in-vehicle system such as SOME/IP-SD or CAN-XL.
  • Ethernet 51 may be the same network protocol as Ethernet 50, or may be a different network protocol.
  • the integrated ECU 200 and the monitoring server 10 are connected via an external network 30.
  • the integrated ECU 200 performs communication control that sends and receives messages via the external network 30, CAN 40, and Ethernet 50, vehicle control that instructs the gateway ECU 300 and Zone ECU 500 to control the vehicle via the CAN 40 and Ethernet 50, and controls the infotainment system and the instrument.
  • This is an ECU that outputs video to the management panel.
  • the integrated ECU 200 is an ECU that monitors the security state of the integrated ECU 200 and notifies the monitoring server 10 of the monitoring results. Note that integrated ECU 200 in this embodiment is an example of a monitoring device, and details thereof will be described later.
  • the gateway ECU 300 is an ECU that mediates messages sent and received between the integrated ECU 200, the steering ECU 400a, and the brake ECU 400b.
  • the steering ECU 400a is an ECU that controls steering by a steering wheel mounted on the vehicle.
  • the brake ECU 400b is an ECU that controls the brakes mounted on the vehicle.
  • the in-vehicle system 20 uses ECUs that control the engine and body of the vehicle to realize control such as running, turning, and stopping the vehicle.
  • the Zone ECU 500 is an ECU that mediates messages sent and received between the integrated ECU 200, the front camera ECU 600a, and the rear camera ECU 600b.
  • the front camera ECU 600a is an ECU that is mounted in the front of the vehicle and acquires images from a camera that photographs the front of the vehicle.
  • FIG. 3 is a configuration diagram of integrated ECU 200 in the embodiment.
  • the integrated ECU 200 includes an external application A100, a control application A200, a video application A300, an external virtual machine VM100, a control virtual machine VM200, a video virtual machine VM300, a virtualization platform VP100, a monitoring application A400, and a monitoring virtual machine. machine VM400.
  • the external application A100, the control application A200, and the video application A300 may be collectively referred to as an application.
  • the external virtual machine VM100, the control virtual machine VM200, the video virtual machine VM300, and the monitoring virtual machine VM400 may be collectively referred to as a virtual machine.
  • the virtualization platform VP100 is a virtual software platform such as a hypervisor, and is software that executes and manages one or more virtual machines.
  • hypervisors are classified into bare metal type hypervisors called type 1 and host type hypervisors called type 2.
  • type 1 is generally used in consideration of processing overhead by the hypervisor. Because type 1 hypervisors have small code sizes, they are less likely to contain vulnerabilities and can be assumed to be more reliable than applications or virtual machines.
  • the virtualization system is implemented by a type 1 hypervisor, but the virtualization system may also be implemented by a type 2 hypervisor.
  • the external virtual machine VM100 is an operating system that runs the external application A100.
  • the external application A100 is an application software program that communicates with the monitoring server 10 via the external network 30.
  • the video virtual machine VM300 is an operating system that operates the video application A300.
  • the video application A300 is an application software program that communicates with the ZoneECU 500 via the Ethernet 50, acquires camera video, etc., and outputs the video to the infotainment system, instrument panel, or head-up display. Camera images are also used as information to realize advanced driving support functions such as autonomous driving.
  • the monitoring virtual machine VM400 is an operating system that operates the monitoring application A400 using a virtual driver.
  • the monitoring application A400 is, for example, an application software program that monitors virtual machines other than the monitoring virtual machine VM400, the virtualization platform 100, and the like.
  • the integrated ECU 200 in this embodiment uses, for example, paravirtualization technology (virtio).
  • This paravirtualization technology is a technology that provides a standard interface to virtual machines on the virtualization platform 100, and enables high-speed communication with physical devices (storage, network devices, etc.) connected to the virtualization platform 100. do.
  • Integrated ECU 200 may be equipped with a function to monitor device connections.
  • the external virtual machine VM100 has a relatively high possibility of being hijacked by an attacker because it downloads third-party applications and is connected to external networks such as Wi-Fi and Bluetooth.
  • the control virtual machine VM200 sends and receives commands for controlling driving such as running, stopping, and turning of the car, real-time performance of the commands is required.
  • the video virtual machine VM300 requires a certain degree of real-time performance, such as displaying the camera and vehicle speed, and since there is no connection to an external network, the possibility of being hijacked is relatively low. For this reason, regarding the video virtual machine VM300, it is necessary to monitor commands at the time of reception rather than commands at the time of transmission. For these reasons, detailed monitoring is required for communications whose source is an external virtual machine, and when a control virtual machine is the source or destination, simple monitoring is desirable in order to achieve real-time performance.
  • FIG. 4 is a block diagram showing in detail the configuration of a part of integrated ECU 200 in the embodiment.
  • the external virtual machine VM100 includes a command sending/receiving unit VM101 that sends and receives commands.
  • the command transmitting/receiving unit VM101 transmits commands to virtual machines other than the external virtual machine VM100, external ECUs, external devices, and the like. Further, the command transmitting/receiving unit VM101 receives commands from virtual machines other than the external virtual machine VM100, external ECUs, external devices, and the like.
  • the video virtual machine VM300 includes a command sending/receiving unit VM301 that sends and receives commands.
  • the command transmitting/receiving unit VM301 transmits commands to virtual machines other than the external virtual machine VM100, external ECUs, external devices, and the like. Further, the command transmitting/receiving unit VM301 receives commands from a virtual machine other than the external virtual machine VM100, an external ECU, an external device, and the like.
  • the detailed monitoring program VM414 is an example of a program that performs detailed monitoring of commands acquired by the command receiving unit VM411.
  • the detailed monitoring program VM 414 may be, for example, a program that performs deep packet inspection to determine whether or not a command payload contains an abnormality. That is, detailed monitoring is, for example, deep packet inspection.
  • the monitoring application A400 includes the simple monitoring program VM413 and the detailed monitoring program VM414, the monitoring application A400 is not limited to this, and may include a plurality of monitoring programs of different types.
  • the monitoring application A400 may include a file access monitoring program and a network monitoring program.
  • the file access monitoring program is a program that monitors commands related to file access.
  • a file access monitoring program is, for example, a program that maintains a permission list of file paths that can be read and written by a specific virtual machine, and determines reading and writing of file paths other than those held in the permission list as abnormal. There may be.
  • a monitoring program using specific detection rules can be used depending on the type of command.
  • a network monitoring program is a program that monitors commands related to data sent and received via a network.
  • the command sending unit VM416 sends the command to a virtual machine other than the monitoring virtual machine VM400, an external ECU, an external device, etc., depending on the command monitoring result. If the command monitoring result includes an abnormality, the command sending unit VM 416 does not send the command to the destination of the command, and if the monitoring result of the command does not include an abnormality, it sends the command to the destination of the command. Send.
  • the system status acquisition unit VM417 acquires the system status of the target virtual machine. Details of the system status will be described later.
  • FIG. 5 is a diagram illustrating an example of a virtual command in the embodiment.
  • the virtual machine configuration information includes an identifier that identifies the virtual machine, the virtual machine's OS (Operating System) type, ASIL (Automotive Safety Integrity Level), external connection function, and timeout time. , calling method, and display function.
  • ASIL indicates the safety level of a vehicle.
  • the external connection function indicates whether the virtual machine can communicate with an external device.
  • the timeout period indicates the timeout period set for the processing of the monitoring program.
  • the calling method indicates whether the monitoring program is to be processed in series or in parallel with command transmission and reception processing. In other words, in the case of serial processing, the command transmission/reception process is executed after the monitoring program is executed for the command. When processing in parallel, execution of a monitoring program for a command and command transmission/reception processing are processed in parallel.
  • the display function indicates whether the virtual machine has a display function.
  • the OS type and external connection function may be used to determine the ease of hijacking by an attacker.
  • ASIL may be used to determine real-time performance. ASIL may be set to higher levels in the order of D, C, B, A, and QM, and it may be determined that the higher the level, the more real-time performance is required.
  • the timeout period is used to set the timeout period of the monitoring program.
  • the calling method is used to determine how to call the monitoring program. The timeout period and calling method may be determined based on real-time performance rather than for each identifier.
  • the display function may be used to display when an abnormality is detected. A virtual machine that is suspected of having an abnormality and that has a display function may execute processing to display the abnormality. As the system is updated, the virtual machine configuration information may be added, deleted, or changed. Even in this case, the monitoring program control unit may refer to the table indicating the updated configuration information.
  • the system status of a virtual machine includes an identifier that identifies the virtual machine, a startup status of the virtual machine, a system load, a virtual command load, a network status, a running status, and a running mode. and security anomalies.
  • the startup state of the virtual machine indicates whether the virtual machine has been started (that is, is being started) or whether the virtual machine is stopped.
  • the startup state may be used to confirm whether the restart has been completed when the abnormality handling unit VM 415 restarts the virtual machine.
  • the system status of a virtual machine includes the running status of a vehicle equipped with a monitoring device, the driving mode of the vehicle, the system load of the virtual machine, the system load in processing commands, the network connection status of the virtual machine, the presence or absence of security abnormalities within the virtual machine, and at least one of the presence or absence of a security abnormality in the virtual command.
  • the driving mode indicates whether the vehicle is operating automatically or manually.
  • the monitoring programs may be called in parallel so as not to affect real-time performance, since communication to the control virtual machine VM200 has a safety impact. If the driving mode indicates manual operation, the monitoring program may not be called since there is no safety impact.
  • the security abnormality indicates whether a security-related abnormality has occurred or not (that is, whether it is normal).
  • the abnormality handling unit VM 415 sets the corresponding virtual machine in an abnormal state, and in the case of an abnormal state, it is used to execute a detailed monitoring program. good.
  • the security abnormality for each virtual machine may be set based on the abnormality determination result of another program instead of the abnormality determination result of the simple program. For example, when a specific process is denied by an access control mechanism such as SELinux (Security-Enhanced Linux) within a virtual machine, the virtual machine may be set to a security abnormal state.
  • FIG. 8 is a diagram illustrating an example of a processing sequence of the monitoring virtual machine in the embodiment.
  • the monitoring program control unit VM412 determines how to call the monitoring program (that is, how to call it) (S103). For example, the monitoring program control unit VM412 determines to call the monitoring program in parallel if the received command is a command for the control virtual machine VM200, and determines to call the monitoring program in series if the received command is a command for the external virtual machine VM100. You may. This allows immediate response to communication abnormalities without delay effects. Note that a specific example of step S103 will be described later.
  • the monitoring program control unit VM412 calls the detailed monitoring program VM414 that has been determined to be executed among the one or more monitoring programs (S108). Then, monitoring processing by the detailed monitoring program VM 414 is executed (S109).
  • FIG. 9 is a diagram illustrating an example of a flowchart of the monitoring program determination process (S102) in the embodiment.
  • the determination process of the monitoring program if the target virtual machine is an external virtual machine VM100, it is possible to communicate with the outside and there is a high possibility that it will be hijacked from the outside, so the details of the communication from the external virtual machine VM100 are checked. A monitoring program may be determined. Furthermore, in the monitoring program determination process, if the target virtual machine is the control virtual machine VM200, the control virtual machine VM200 is required to have real-time performance, so the monitoring process by the monitoring program may be skipped. In addition, in the monitoring program determination process, if the target virtual machine is the video virtual machine VM300, the video virtual machine VM300 is unlikely to be directly hijacked, so even if the detailed monitoring program is executed in response to the received command. good.
  • the monitoring program control unit VM412 acquires a command from the command receiving unit VM411 (S121).
  • the monitoring program control unit VM412 determines whether the command is a sent command or a received command (S124).
  • step S124 If the command is a sent command (sent in S124), the monitoring program control unit VM412 executes step S125, and if the command is a received command (received in S124), it executes step S126.
  • step S125 the monitoring program control unit VM412 sets the detailed monitoring program to ON.
  • the detailed monitoring program is set to be executed.
  • step S126 the monitoring program control unit VM412 sets the detailed monitoring program to OFF. In other words, the detailed monitoring program is set not to be executed.
  • step S127 the monitoring program control unit VM412 sets the simple monitoring program to ON. In other words, execution of the simple monitoring program is set.
  • the monitoring program control unit VM412 determines whether the command is a sent command or a received command (S128).
  • step S129 If the command is a sent command (sent in S128), the monitoring program control unit VM412 executes step S129, and if the command is a received command (received in S128), it executes step S130.
  • step S129 the monitoring program control unit VM412 sets the detailed monitoring program to OFF. In other words, the detailed monitoring program is set not to be executed.
  • step S126 the monitoring program control unit VM412 sets the detailed monitoring program to ON.
  • the detailed monitoring program is set to be executed.
  • step S131 the monitoring program control unit VM412 sets the simple monitoring program to OFF.
  • the setting is such that the simple monitoring program is not executed.
  • the monitoring program control unit VM412 sets the detailed monitoring program to OFF (S132). In other words, the detailed monitoring program is set not to be executed.
  • ON/OFF of the simple monitoring program and ON/OFF of the detailed monitoring program may be determined according to at least one of the connection state to an external network, the driving state, and the driving mode. For example, if the virtual machine VM100 is connected to an external network, commands from the external virtual machine VM100 are suspicious, so the detailed monitoring program may be set to ON. Further, if the vehicle is running or automatically driving, commands from the video virtual machine may affect safety, so the detailed monitoring program may be set to ON.
  • FIG. 10 is a diagram showing an example of a flowchart of the monitoring program calling process (S103) in the embodiment.
  • the process of calling the monitoring program if the target virtual machine is an external virtual machine VM100, it is possible to communicate with the outside and there is a high possibility that it will be hijacked from the outside, so check the details of the communication from the external virtual machine VM100.
  • a monitoring program may be determined.
  • the target virtual machine is the control virtual machine VM200
  • the possibility that the control virtual machine VM200 will be directly hijacked is low.
  • a monitoring program may be determined to check the details of the command.
  • step S144 the monitoring program control unit VM412 sets how to call one or more monitoring programs in parallel.
  • step S147 If the command is a sent command (sent in S146), the monitoring program control unit VM412 executes step S147, and if the command is a received command (received in S146), it executes step S148.
  • step S148 the monitoring program control unit VM412 sets the method of calling one or more monitoring programs in series.
  • FIG. 11 is a diagram illustrating an example of a flowchart of the monitoring program timeout time determination process (S104) in the embodiment.
  • S104 timeout time determination process
  • the timeout period By setting the timeout period to a short time, the maximum delay can be shortened and low delay can be guaranteed, but there is a possibility that the monitoring process will not be completed. On the other hand, by setting the timeout period to a long time, more time can be used for monitoring processing, but since it takes time to send commands, there is a possibility that delays will become large.
  • the monitoring program control unit VM412 determines whether there is a security abnormality in the virtual machine that is the source of the acquired command (S162).
  • step S171 the monitoring program control unit VM412 sets the detailed monitoring program to ON.
  • the detailed monitoring program is set to be executed.
  • the monitoring program control unit VM 412 executes step S173 and installs the source virtual machine of the acquired command. If the OS type of the machine or the destination virtual machine is not RTOS (No in S172), the monitoring program determination process ends.
  • step S174 the monitoring program control unit VM412 sets the simple monitoring program and detailed monitoring program to ON. In other words, execution of the simple monitoring program and detailed monitoring program is set.
  • step S175 the monitoring program control unit VM412 determines how to call the monitoring programs in parallel (S175). Upon completion of step S175, step S176 is executed.
  • the monitoring program control unit VM412 determines how to call the monitoring programs in parallel (S178).
  • step S178 ends, the monitoring program determination process ends.
  • the monitoring program control unit VM412 determines whether the monitoring result of the monitoring process by the simple monitoring program is abnormal (S185).
  • step S186 the monitoring program control unit VM412 executes the detailed monitoring program.
  • the execution of the detailed monitoring program may be skipped by confirming the abnormality. This can reduce the time required to notify that an abnormality has occurred.
  • the abnormality handling unit VM415 acquires the monitoring results in the monitoring process (S191).
  • the abnormality handling unit VM415 determines whether the monitoring result shows one or more abnormalities (S192).
  • step S193 the abnormality handling unit VM415 groups and stores logs of monitoring results including abnormalities.
  • the grouping log is stored. Details of the grouping log will be described later.
  • the abnormality handling unit VM415 determines whether the abnormality according to the monitoring result is an abnormality detected by the monitoring process of the detailed monitoring program (S194).
  • the abnormality handling unit VM 415 determines that the abnormality according to the monitoring result is an abnormality detected by the monitoring process of the detailed monitoring program (Yes in S194), it executes step S195, and the abnormality according to the monitoring result is detected by the monitoring process of the detailed monitoring program. If it is determined that the abnormality is not detected by the process (that is, the abnormality is detected by the monitoring process of the simple monitoring program) (No in S194), the abnormality handling process ends.
  • step S195 the abnormality handling unit VM415 drops the acquired command (that is, processes the command so as not to use it). For example, the command may be discarded, or information (flag) indicating that the command cannot be used may be added. A command with information (flag) indicating that the command cannot be used will not be used by virtual machines, other devices, etc.
  • the abnormality handling unit VM415 notifies the abnormality and causes, for example, a virtual machine (video virtual machine VM300) having a display function to display a UI including the abnormality that has occurred (S196).
  • the abnormality handling unit VM 415 may drop the command only when it is determined to be abnormal in both simple monitoring and detailed monitoring, and it can definitely be determined that the abnormality is abnormal.
  • the abnormality handling unit VM 415 may change the filtering rules of the monitoring program. This allows you to drop commands in which an abnormality is detected from the next time.
  • the abnormality handling unit VM415 may restart or stop the virtual machine that is the source of the abnormal command. This can stop the attack process.
  • abnormality handling unit VM 415 may restart the entire system if there are a certain number or more of abnormal virtual machines. This enables safe startup using secure boot.
  • the abnormality handling unit VM 415 may notify and display the abnormality.
  • the abnormality handling unit VM 415 may display the abnormality on a display in the car handled by the virtual machine, or may notify the monitoring server 10 and cause the monitoring server to display the abnormality.
  • the abnormality handling unit VM 415 may decide whether to turn the monitoring program on or off based on the previous monitoring result.
  • the system state of the virtual machine may be set to have an abnormal security state, and the monitoring program may be turned on or off depending on the system state.
  • FIGS. 15 and 16 are diagrams showing examples of grouping logs in the embodiment.
  • the grouping log is a log that records, for each virtual machine, that there was an abnormality in a command for that virtual machine.
  • the grouping log includes an abnormality ID, an abnormality name, an abnormality identifier, a virtual machine identifier, a number of times, and a final time.
  • the abnormality ID indicates that the abnormality name and the virtual machine to be monitored are the same abnormality.
  • the abnormality name is the name of the type of abnormality.
  • the abnormality identifier is information that identifies an abnormality.
  • a virtual machine identifier is information that identifies a virtual machine.
  • the number of times indicates the number of times an anomaly with the same anomaly identifier has occurred.
  • the final time indicates the time when the corresponding abnormality occurred last.
  • the grouping log allows log information related to the abnormality detected by the monitoring program control unit VM 412 to be extracted.
  • analysts can perform their analyzes efficiently.
  • the grouping log may be used by a monitoring program.
  • the monitoring program periodically acquires the grouping log and determines that a particular virtual machine is abnormal when the number of times an abnormality occurs exceeds a threshold. It's okay.
  • FIG. 15 is an example of a grouping log of an abnormality that occurred in a virtual machine whose virtual machine identifier is 1.
  • FIG. 16 is an example of a grouping log of abnormalities that occur in the virtual machine whose virtual machine identifier is 2.
  • FIG. 17 is a diagram illustrating an example of a monitoring result display according to the embodiment.
  • Monitoring results displays may be used to communicate monitoring information to security analysts.
  • the monitoring result display may be generated by the monitoring server 10 by receiving the monitoring result from the in-vehicle system 20.
  • the monitoring result display is a display in which the monitoring results are expressed in a graphical user interface.
  • the monitoring result includes an identifier that identifies the virtual machine corresponding to the command, an identifier of the application corresponding to the virtual machine, and the time when the command was determined to be normal. If the command is abnormal, the monitoring result includes an identifier that identifies the virtual machine corresponding to the command, an identifier of the application corresponding to the virtual machine, and the time when the abnormality was determined.
  • thick-framed blocks indicate monitored software that has been determined to be abnormal
  • thin-framed blocks indicate monitored software that has been determined to be normal
  • FIG. 17 an abstracted system architecture of the integrated ECU 200 is displayed, and the abnormal and normal (abnormal in this case) components are emphasized and expressed so that they can be distinguished.
  • the corresponding monitoring results are displayed.
  • the security analyst can intuitively understand the component in which the abnormality has occurred, and can quickly analyze the security abnormality.
  • the vehicle identifier shown in FIG. 17 is a unique identifier given to each vehicle.
  • the ECU identifier is an identifier given to each ECU.
  • the vehicle identifier of the vehicle in which the abnormality was detected and the identifier of the ECU equipped with the virtualization platform are displayed.
  • the source of the abnormal command may be highlighted above the screen where the system architecture is displayed.
  • the abnormality detection time and the name of the detected monitoring program may be displayed.
  • the abnormality detection time is included in the abnormality notification log, and the name of the monitoring program is referenced from the identifier included in the abnormality notification log. This allows a security analyst who analyzes anomalies using the GUI of the monitoring server to easily identify the location where an anomaly occurs and understand the details of the anomaly.
  • FIG. 18 is a diagram illustrating an example of a monitoring result display in the embodiment.
  • a display frame controlled by the source of the abnormal communication may be highlighted on the display inside the vehicle.
  • the driver can easily determine whether there is an abnormality or danger, and can stop the vehicle on the roadside.
  • the abnormality may be notified by displaying a red frame on the outer frame of the cluster display and electronic mirror display that are controlled by the video virtual machine.
  • the monitoring device (integrated ECU 200) according to the present embodiment is a monitoring device in a virtualization platform that operates two or more virtual machines, and the monitoring device is a monitoring device that transmits or receives data from a process among the two or more virtual machines.
  • One or more monitoring programs that monitor commands run on a first virtual machine, and the monitoring device receives commands that are sent or received by a process that runs on a second virtual machine that is different from the first virtual machine.
  • the command only describes the L2 physical address for transmission and reception, so the monitoring program control unit cannot acquire information other than the address.
  • the monitoring virtual machine VM400 that monitors a plurality of virtual machines implemented in the integrated ECU 200 is a monitoring program on a virtualized environment, it can acquire configuration information and system status of the virtual machines to be monitored. With this information, it is possible to determine which virtual machine (which OS) the communication is from based on the address for sending and receiving the command. Furthermore, processing can be switched depending on the state of the virtual machine.
  • the abnormality handling unit VM 415 can accumulate abnormality logs for each virtual machine by using the configuration information of the virtual machine. Therefore, the time required for analysis during incident response can be reduced. Additionally, since it is possible to determine which virtual machine is abnormal based on the source of the abnormal command, it is possible to perform processing to deal with the abnormality, such as displaying an abnormality, restarting, or stopping the virtual machine.
  • the monitoring device (integrated ECU 200) further includes a system status acquisition unit VM417 that acquires the system status of the second virtual machine.
  • the monitoring program control unit VM 412 further determines how to execute one or more monitoring programs depending on the system state.
  • the execution method of one or more monitoring programs is further determined according to the system state of the second virtual machine, it is possible to execute appropriate monitoring processing according to the state of the second virtual machine.
  • the processing load of the monitoring process can be adjusted, and the monitoring process can be implemented in consideration of the real-time nature of commands, and the monitoring process for commands can be executed efficiently and effectively.
  • the characteristics of a command include the virtual machine that is the source of the command, the virtual machine that is the destination of the command, the direction of the command, file access, the OS (Operating System) type of the source or destination virtual machine, and the ASIL of the command. , a driving state of a vehicle equipped with the monitoring device, a driving mode of the vehicle, and a system state. Therefore, it is possible to perform appropriate monitoring processing according to the characteristics of the second virtual machine and the characteristics of the command.
  • the execution method of the monitoring program is at least one of whether the monitoring program is valid, a method of calling the monitoring program, a timeout period set in the monitoring program, and an execution order of the monitoring program.
  • abnormality handling unit VM 415 further generates a grouping log by aggregating or totaling logs indicating command abnormalities according to the type of command. Therefore, aggregated or tabulated abnormalities can be used for analysis.
  • the monitoring program control unit VM412 calls a detailed monitoring program that has a higher processing load than the simple monitoring program, depending on the monitoring result of the simple monitoring program among the one or more monitoring programs. For example, when an anomaly is detected by a simple monitoring program, a detailed monitoring program may be executed to obtain more detailed results about the anomaly, or when an anomaly is detected by a simple monitoring program, a detailed monitoring program may be executed. By skipping the execution of the detailed monitoring program, the processing load may be reduced and the time required for notification of an abnormality may be reduced.
  • FIG. 19 is a block diagram showing in detail the configuration of a part of integrated ECU 200 in a modified example.
  • the monitoring virtual machine VM500 Since the configuration of the monitoring virtual machine VM500 is different from the embodiment, the monitoring virtual machine VM500 will be explained.
  • the monitoring virtual machine VM500 includes a first command reception section VM501, a first monitoring program control section VM502, a first command transmission section VM503, a second command reception section VM511, a second monitoring program control section VM512, a second command transmission section VM513, It includes a simple monitoring program VM413, a detailed monitoring program VM414, an abnormality handling section VM415, a system status acquisition section VM417, and a system configuration acquisition section VM418.
  • the configurations of the simple monitoring program VM413, detailed monitoring program VM414, error handling unit VM415, system status acquisition unit VM417, and system configuration acquisition unit VM418 are the same as the configuration of the monitoring virtual machine VM400 of the embodiment. A reference numeral is given and the explanation is omitted.
  • the monitoring virtual machine VM500 differs from the monitoring virtual machine VM400 of the embodiment in that it has two command reception units, two monitoring program control units, and two command transmission units. That is, the monitoring virtual machine VM500 differs from the monitoring virtual machine VM400 in that it has two sets of a command receiving section, a monitoring program control section, and a command transmitting section. Since there are two sets of a command receiving section, a monitoring program control section, and a command transmitting section, delays in commands can be suppressed by having the two sets share the roles of monitoring processing.
  • the first command reception unit VM501, first monitoring program control unit VM502, and first command transmission unit VM503 execute processing for the video virtual machine VM300. That is, the first command reception unit VM501, first monitoring program control unit VM502, and first command transmission unit VM503 execute processing for commands transmitted or received by the process of the video virtual machine VM300.
  • the first command reception unit VM501, first monitoring program control unit VM502, and first command transmission unit VM503 are the same as the command reception unit VM411, monitoring program control unit VM412, and command transmission unit VM416 of the embodiment, respectively. It has the following functions.
  • one of the first monitoring program control unit VM502 and the second monitoring program control unit VM512 performs the monitoring process. , or the processing is shared between both the first monitoring program control unit VM502 and the second monitoring program control unit VM512.
  • the allocation of processing is determined using an allocation table, the simple monitoring program is executed in the monitoring program control unit corresponding to the virtual machine on the sending side of the command, and the detailed monitoring program is executed on the monitoring program corresponding to the virtual machine on the receiving side of the command. Delays can be suppressed by dividing the processing so that it is executed in the control unit.
  • FIG. 20 is a diagram illustrating an example of a processing sequence of a monitoring virtual machine in a modified example.
  • the first command receiving unit VM501 or the second command receiving unit VM511 receives a command from a virtual machine other than the monitoring virtual machine VM500, an external ECU, an external device, etc., and identifies the received command ( S101).
  • the system configuration acquisition unit VM418 acquires configuration information of the virtual machine that sent the command or the virtual machine that received the command, based on the identifier included in the command.
  • the system state acquisition unit VM417 may obtain the system state of the virtual machine that sent the command or the virtual machine that received the command, based on the identifier included in the command.
  • the command identifier, virtual machine configuration information, and virtual machine system state obtained in step S101 are notified to the first monitoring program control unit VM502 and the second monitoring program control unit VM512.
  • the first monitoring program control unit VM502 and the second monitoring program control unit VM512 refer to the characteristics of the command from the command identifier, and perform monitoring according to the notified configuration information and system status, and the characteristics of the command.
  • the division of programs is determined (S211).
  • the load on the first monitoring program control unit VM502 and the second monitoring program control unit VM512 can be reduced by sharing the monitoring processing so that, for example, the monitoring processing is executed on the interface side where the system load is low.
  • the first monitoring program control unit VM502 and the second monitoring program control unit VM512 call the simple monitoring program VM413 that has been determined to be executed among the one or more monitoring programs (S106). Then, monitoring processing by the simple monitoring program VM413 is executed (S107).
  • the first monitoring program control unit VM502 and the second monitoring program control unit VM512 call the corresponding application (S110).
  • the abnormality handling unit VM415 executes abnormality handling processing (S111).
  • command logging, command dropping, virtual machine restart, system restart, etc. are executed depending on the monitoring result of the monitoring processing. Note that details of step S111 will be described later.
  • the first monitoring program control unit VM502 and the second monitoring program control unit VM512 send the first command transmission unit VM503 or The command is transmitted to the second command transmitter VM513 (S112).
  • the first monitoring program control unit VM502 and the second monitoring program control unit VM512 transmit a command determined to be normal in the monitoring process to a specified destination virtual machine, external ECU, external device, etc.
  • the command is sent to the corresponding command transmitter.
  • the first monitoring program control unit VM502 and the second monitoring program control unit VM512 send commands determined as above in the monitoring process to a specified destination virtual machine, external ECU, external device, etc. It is not necessary to send the command to the corresponding command transmitter.
  • the command transmission unit corresponding to the destination transmits the commands received from the first monitoring program control unit VM502 and the second monitoring program control unit VM512 to the specified destination virtual machine, external ECU, external device, etc. (S113 ).
  • first monitoring program control unit VM502 and the second monitoring program control unit VM512 perform the processing of steps S211, S106, S108, S110, and S112, but the first monitoring program control unit VM502 and the second monitoring program control unit VM502 These processes may be performed in at least one of the monitoring program control units VM512.
  • FIG. 21 is a diagram illustrating an example of a flowchart of the monitoring program sharing process (S211) in the modified example.
  • the first monitoring program control unit VM502 or the second monitoring program control unit VM512 determines whether or not it is internal communication between virtual machines based on the obtained command (S222). In other words, the first monitoring program control unit VM502 or the second monitoring program control unit VM512 determines whether both the source and destination of the acquired command are virtual machines.
  • the first monitoring program control unit VM502 or the second monitoring program control unit VM512 determines that the communication is internal communication between virtual machines (Yes in S222), it executes step S223 and determines that the communication is not internal communication between virtual machines. If so (No in S222), the monitoring program sharing process ends.
  • the first monitoring program control unit VM502 or the second monitoring program control unit VM512 refers to the allocation determination table according to the load of the virtual command and assigns an allocation identifier.
  • FIG. 22 is a diagram illustrating an example of a division determination table in a modified example.
  • the allocation determination table includes an allocation identifier, a condition, a monitoring program control unit that executes a simple monitoring program, a monitoring program control unit that executes a detailed monitoring program, and an abnormality response unit.
  • the assignment identifier is an identifier that specifies four assignment methods.
  • the conditions are for determining one of the four sharing methods based on the virtual command load. For example, when the virtual command load on the sending side is lower than threshold 1, the simple monitoring program is executed by the first monitoring program control unit VM502, the detailed monitoring program is executed by the first monitoring program control unit VM502, and the abnormality handling process is executed by the first monitoring program control unit VM502. 1 monitoring program control unit VM502.
  • the simple monitoring program is executed by the first monitoring program control unit VM502
  • the detailed monitoring program is executed by the first monitoring program control unit VM502
  • the abnormality handling process is executed by the second monitoring program control unit VM512.
  • the simple monitoring program is executed by the first monitoring program control unit VM502
  • the detailed monitoring program is executed by the second monitoring program control unit VM512
  • the abnormality handling process is executed by the second monitoring program control unit VM512.
  • the simple monitoring program is executed by the second monitoring program control unit VM512
  • the detailed monitoring program is executed by the second monitoring program control unit VM512
  • the abnormality response is handled.
  • the process is executed by the second monitoring program control unit VM512.
  • FIG. 22 shows a method of specifying the sharing method according to the virtual command load
  • a first monitoring program control unit VM502 that receives virtual commands executes a simple monitoring program and a detailed monitoring program
  • a second monitoring program control unit VM512 that sends virtual commands executes abnormality handling processing.
  • the sharing method can be determined without referring to the virtual command load.
  • the second monitoring program control unit VM512 may identify the sharing method by referring to the assignment identifier assigned to the virtual command. .
  • the first monitoring program control unit VM502 can arbitrarily determine the allocation method.
  • the monitoring program sharing method may also be specified by data communication or data sharing between the first monitoring program control unit VM502 and the second monitoring program control unit VM512.
  • a method for allocating monitoring programs may be specified by data communication or data sharing between monitoring programs.
  • the allocation method can be dynamically determined according to the characteristics of the virtual command and the characteristics of the monitoring program.
  • the first rule is applied to the monitoring program executed by the first monitoring program control unit VM502, and the monitoring program executed by the second monitoring program control unit VM512 is applied to the second monitoring program. It is also possible to share the responsibility of applying the following rules. In this case, even if there is only one monitoring program, the processing can be shared.
  • the monitoring device integrated ECU 200
  • the monitoring device includes two or more monitoring program control units (for example, a first monitoring program control unit VM502 and a second monitoring program control unit VM512), and one or more monitoring programs in response to a command are:
  • two or more monitoring program control units for example, a first monitoring program control unit VM502 and a second monitoring program control unit VM512
  • one or more monitoring programs in response to a command are:
  • the destination of the command is a virtual machine on the virtualization platform
  • one or more of the two or more monitoring program control units is determined based on the identifier and configuration information included in the command.
  • the execution method is determined by the control unit.
  • two or more monitoring program control units determine how to execute one or more monitoring programs depending on the system state.
  • a first monitoring program control unit assigns a first identifier to a command
  • a second monitoring program control unit determines whether or not a first identifier is assigned to a command. Accordingly, a method of executing one or more monitoring programs is determined.
  • the monitoring process can be shared between two or more monitoring program control units based on the identifier and configuration information included in the command. Therefore, delays can be suppressed.
  • the monitoring device of the present disclosure has been described above based on the above embodiments and modifications thereof, the present disclosure is not limited to the embodiments and modifications thereof. Unless departing from the spirit of the present disclosure, the present disclosure may include various modifications that occur to those skilled in the art to the above embodiments and modifications.
  • each component may be configured with dedicated hardware, or may be realized by executing a software program suitable for each component.
  • Each component may be realized by a program execution unit such as a CPU (Central Processing Unit) or a processor reading and executing a software program recorded on a recording medium such as a hard disk or a semiconductor memory.
  • the software that realizes the monitoring device and the like of 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 FIGS. 8 to 14, FIG. 20, and FIG. 21, respectively.
  • the at least one device mentioned above is specifically a computer system composed 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 functions by the microprocessor operating according to a computer program.
  • a computer program is configured by combining a plurality of instruction codes indicating instructions to a computer in order to achieve a predetermined function.
  • a part or all of the components constituting at least one of the above devices may be composed of one system LSI (Large Scale Integration).
  • a system LSI is a super-multifunctional LSI manufactured by integrating multiple components onto a single chip, and specifically, it is a computer system that includes a microprocessor, ROM, RAM, etc. .
  • a computer program is stored in the RAM. The system LSI achieves its functions by the microprocessor operating according to a computer program.
  • An IC card or module is a computer system composed of a microprocessor, ROM, RAM, etc.
  • the IC card or module may include the above-mentioned super multifunctional LSI.
  • An IC card or module achieves its functions by a microprocessor operating according to a computer program. This IC card or this module may be tamper resistant.
  • the present disclosure may be the method described above. Furthermore, it may be a computer program that implements these methods using a computer, or it may be a digital signal formed from a computer program.
  • the present disclosure also provides a method for storing computer programs or digital signals on computer-readable recording media, such as flexible disks, hard disks, CD (Compact Disc)-ROMs, DVDs, DVD-ROMs, DVD-RAMs, and BDs (Blu-rays). (registered trademark) Disc), semiconductor memory, etc. Further, it may be a digital signal recorded on these recording media.
  • computer-readable recording media such as flexible disks, hard disks, CD (Compact Disc)-ROMs, DVDs, DVD-ROMs, DVD-RAMs, and BDs (Blu-rays). (registered trademark) Disc), semiconductor memory, etc. Further, it may be a digital signal recorded on these recording media.
  • the present disclosure may transmit a computer program or a digital signal via a telecommunication line, a wireless or wired communication line, a network typified by the Internet, data broadcasting, or the like.
  • the program or digital signal may be implemented by another independent computer system by recording it on a recording medium and transferring it, or by transferring the program or digital signal via a network or the like.
  • the monitoring device of the present disclosure can be applied to, for example, electronic equipment mounted on a vehicle.
  • Monitoring server 20 In-vehicle system 30 External network 40, 41 CAN 50, 51 Ethernet 200 Integrated ECU 300 Gateway ECU 400a steering ECU 400b brake ECU 500 ZoneECU 600a front camera ECU 600b rear camera ECU A100 External application A200 Control application A300 Video application A400 Monitoring application VM100 External virtual machines VM101, VM201, VM301 Command transmission/reception unit VM200 Control virtual machine VM300 Video virtual machine VM400, VM500 Monitoring virtual machine VM411 Command receiving unit VM412 Monitoring program control unit VM413 Simple monitoring Program VM414 Detailed monitoring program VM415 Abnormality handling unit VM416 Command transmitting unit VM417 System status acquiring unit VM418 System configuration acquiring unit VM501 First command receiving unit VM502 First monitoring program control unit VM503 First command transmitting unit VM511 Second command receiving unit VM512 2 Monitoring program control unit VM513 Second command transmission unit VP100 Virtualization platform VP101 Physical interface

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Debugging And Monitoring (AREA)

Abstract

２以上の仮想マシンを動作させる仮想化プラットフォームにおける監視装置であって、監視装置は、２以上の仮想マシンのうち、プロセスが送信または受信するコマンドを監視する１以上の監視プログラムが動作する第１仮想マシンにて動作し、監視装置は、第１仮想マシンと異なる第２仮想マシンにて動作するプロセスが送信または受信するコマンドを受信するコマンド受信部（ＶＭ４１１）と、第２仮想マシンの構成情報を取得する構成情報取得部と、コマンドに含まれる識別子からコマンドの特性を参照し、構成情報及びコマンドの特性に応じて１以上の監視プログラムの実行方法を決定する監視プログラム制御部（ＶＭ４１２）と、監視プログラムの監視結果を取得して、監視結果に異常が含まれる場合に異常を通知する異常対応部（ＶＭ４１５）と、を備える。

Description

監視装置及び監視方法
　本開示は、例えばコマンドなどを監視する監視装置および監視方法に関する。
　特許文献１の監視装置は、仮想ソフトウェア上の監視用の仮想マシンを用いて、仮想ソフトウェア上の監視対象の仮想マシンを監視する。例えば、監視装置は、所定の時間間隔ごとに、監視用の仮想マシンから監視対象の仮想マシンおよびハイパーバイザを検証し、その検証結果を取得する。
特開２０１９－１４４７８５号公報
　本開示は、検知漏れがないようにコマンドを監視することができる監視装置などを提供する。
　本開示の一態様に係る監視装置は、２以上の仮想マシンを動作させる仮想化プラットフォームにおける監視装置であって、前記監視装置は、前記２以上の仮想マシンのうち、プロセスが送信または受信するコマンドを監視する１以上の監視プログラムが動作する第１仮想マシンにて動作し、前記監視装置は、前記第１仮想マシンと異なる第２仮想マシンにて動作するプロセスが送信または受信するコマンドを受信するコマンド受信部と、前記第２仮想マシンの構成情報を取得する構成情報取得部と、前記コマンドに含まれる識別子から前記コマンドの特性を参照し、前記構成情報及び前記コマンドの特性に応じて前記１以上の監視プログラムの実行方法を決定する監視プログラム制御部と、前記監視プログラムの監視結果を取得して、前記監視結果に異常が含まれる場合に前記異常を通知する異常対応部と、を備える。
　なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。また、記録媒体は、非一時的な記録媒体であってもよい。
　本開示の監視装置は、検知漏れがないようにコマンドを監視することができる。
　本開示の一態様における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施の形態並びに明細書および図面に記載された構成によってそれぞれ提供されるが、その利点および効果を得るために必ずしも全ての構成が提供される必要はない。
図１は、実施の形態における監視システムの全体構成図である。 図２は、実施の形態における車載システムの構成図を示す図である。 図３は、実施の形態における統合ＥＣＵの構成図である。 図４は、実施の形態における統合ＥＣＵの一部の構成を詳細に示すブロック図である。 図５は、実施の形態における仮想コマンドの一例を示す図である。 図６は、実施の形態における仮想マシンの構成情報の一例を示す図である。 図７は、実施の形態における仮想マシンのシステム状態の一例を示す図である。 図８は、実施の形態における監視仮想マシンの処理シーケンスの一例を示す図である。 図９は、実施の形態における監視プログラムの決定処理のフローチャートの一例を示す図である。 図１０は、実施の形態における監視プログラムの呼び出し処理のフローチャートの一例を示す図である。 図１１は、実施の形態における監視プログラムのタイムアウト時間の決定処理のフローチャートの一例を示す図である。 図１２は、実施の形態における監視プログラムの決定処理のフローチャートの他の一例を示す図である。 図１３は、実施の形態における監視プログラムの順序の決定及び監視プログラムの実行処理のフローチャートの一例を示す図である。 図１４は、実施の形態における異常対応処理のフローチャートの一例を示す図である。 図１５は、実施の形態におけるグルーピングログの一例を示す図である。 図１６は、実施の形態におけるグルーピングログの一例を示す図である。 図１７は、実施の形態における監視結果表示の一例を示す図である。 図１８は、実施の形態における監視結果表示の一例を示す図である。 図１９は、変形例における統合ＥＣＵの一部の構成を詳細に示すブロック図である。 図２０は、変形例における監視仮想マシンの処理シーケンスの一例を示す図である。 図２１は、変形例における監視プログラムの分担処理のフローチャートの一例を示す図である。 図２２は、変形例における分担の決定テーブルの一例を示す図である。
　（本開示の基礎となった知見）
　上記特許文献１の監視装置では、監視用の仮想マシンが乗っ取られない限り、他の仮想マシンの異常を検知できるが、定期的な検証であるため、検証のインターバル期間における不正なファイル操作またはネットワーク通信に対応することが難しく、検知の漏れが生じる。
　このような課題を解決するために、本開示の一態様に係る監視装置は、２以上の仮想マシンを動作させる仮想化プラットフォームにおける監視装置であって、前記監視装置は、前記２以上の仮想マシンのうち、プロセスが送信または受信するコマンドを監視する１以上の監視プログラムが動作する第１仮想マシンにて動作し、前記監視装置は、前記第１仮想マシンと異なる第２仮想マシンにて動作するプロセスが送信または受信するコマンドを受信するコマンド受信部と、前記第２仮想マシンの構成情報を取得する構成情報取得部と、前記コマンドに含まれる識別子から前記コマンドの特性を参照し、前記構成情報及び前記コマンドの特性に応じて前記１以上の監視プログラムの実行方法を決定する監視プログラム制御部と、前記監視プログラムの監視結果を取得して、前記監視結果に異常が含まれる場合に前記異常を通知する異常対応部と、を備える。
　これによれば、第２仮想マシンの構成情報及びコマンドの特性に応じて１以上の監視プログラムの実行方法を決定するため、第２仮想マシンの特性及びコマンドの特性に応じた適切な監視処理を実行することができる。これにより、監視処理の処理負荷を調整でき、また、コマンドのリアルタイム性が考慮された監視処理を実現することができ、コマンドへの監視処理を効率よく効果的に実行することができる。
　また、さらに、前記第２仮想マシンのシステム状態を取得するシステム状態取得部を備え、前記監視プログラム制御部は、さらに前記システム状態に応じて、前記１以上の監視プログラムの実行方法を決定してもよい。
　これによれば、さらに、第２仮想マシンのシステム状態に応じて１以上の監視プログラムの実行方法を決定するため、第２仮想マシンの状態に応じた適切な監視処理を実行することができる。これにより、監視処理の処理負荷を調整でき、また、コマンドのリアルタイム性が考慮された監視処理を実現することができ、コマンドへの監視処理を効率よく効果的に実行することができる。
　また、前記コマンドの特性は、前記コマンドの送信元または送信先の仮想マシン、前記コマンドの送信元または送信先の電子制御装置、前記コマンドの送信方向、前記コマンドに含まれるファイル操作のアクセス先、前記コマンドに含まれるファイル操作の種類、前記送信元または前記送信先の仮想マシンのＯＳ（Operating System）種別、前記送信元または前記送信先の仮想マシンの外部接続機能の有無、前記コマンドのＡＳＩＬ、及び、前記コマンドの車両制御への影響の少なくとも１つであってもよい。
　このため、第２仮想マシンの特性及びコマンドの特性に応じた適切な監視処理を実行することができる。
　また、前記システム状態は、前記監視装置を備える車両の走行状態、前記車両の走行モード、前記仮想マシンのシステム負荷、前記コマンドの処理におけるシステム負荷、前記仮想マシンのネットワーク接続状態、前記仮想マシン内のセキュリティ異常の有無、及び、仮想コマンドのセキュリティ異常の有無の少なくとも１つである。
　また、前記監視プログラムの実行方法は、前記監視プログラムが有効であるか否か、前記監視プログラムの呼び出し方法、前記監視プログラムに設定されているタイムアウト時間、及び、前記監視プログラムの実行順序の少なくとも１つであってもよい。
　これにより、監視処理の処理負荷を調整でき、また、コマンドのリアルタイム性が考慮された監視処理を実現することができる。
　また、前記異常対応部は、さらに、前記コマンドの特性に応じて前記コマンドの異常を示すログを集約または集計してもよい。
　このため、集約または集計した異常を分析に利用することができる。
　また、前記監視プログラム制御部は、前記１以上の監視プログラムのうちの簡易監視プログラムの監視結果に応じて、前記簡易監視プログラムよりも処理負荷が高い詳細監視プログラムを呼び出してもよい。
　また、さらに、２以上の前記監視プログラム制御部を備え、前記コマンドに対する前記１以上の監視プログラムは、前記コマンドの送信先が前記仮想化プラットフォーム上の仮想マシンであると判定された場合に、前記２以上の監視プログラム制御部のうち、前記コマンドに含まれる識別子及び前記構成情報に基づいて決定された１以上の監視プログラム制御部によって実行方法が決定されてもよい。
　このため、コマンドに含まれる識別子及び構成情報に基づいて、監視処理を２以上の監視プログラム制御部で分担することができる。よって、遅延を抑えることができる。
　また、前記２以上の前記監視プログラム制御部は、前記第２仮想マシンのシステム状態に応じて前記１以上の監視プログラムの実行方法を決定してもよい。
　また、前記２以上の前記監視プログラム制御部のうち、第１監視プログラム制御部は、前記コマンドに第１識別子を付与し、第２監視プログラム制御部は、前記コマンドに第１識別子が付与されているか否かに応じて、前記１以上の監視プログラムの実行方法を決定してもよい。
　本開示の一態様に係る監視方法は、２以上の仮想マシンを動作させる仮想化プラットフォームにおける監視装置による監視方法であって、前記監視装置は、前記２以上の仮想マシンのうち、プロセスが送信または受信するコマンドを監視する１以上の監視プログラムが動作する一の仮想マシンにて動作し、前記監視方法は、前記一の仮想マシンと異なる仮想マシンにて動作するプロセスが送信または受信するコマンドを取得し、前記仮想マシンの構成情報を取得し、前記コマンドに含まれる識別子から前記コマンドの特性を参照し、前記１以上の監視プログラムの実行方法を決定し、前記監視プログラムの監視結果を取得して、異常を通知する。
　これによれば、第２仮想マシンの構成情報及びコマンドの特性に応じて１以上の監視プログラムの実行方法を決定するため、第２仮想マシンの特性及びコマンドの特性に応じた適切な監視処理を実行することができる。これにより、監視処理の処理負荷を調整でき、また、コマンドのリアルタイム性が考慮された監視処理を実現することができ、コマンドへの監視処理を効率よく効果的に実行することができる。
　以下、実施の形態について、図面を参照しながら具体的に説明する。
　なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置および接続形態、ステップ、ステップの順序などは、一例であり、本開示を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
　また、各図は、模式図であり、必ずしも厳密に図示されたものではない。また、各図において、同じ構成部材については同じ符号を付している。
　（実施の形態）
　［監視システムの全体構成図］
　図１は、実施の形態における監視システムの全体構成図である。
　監視システムは、監視サーバー１０と、車載システム２０とを備える。監視サーバー１０と車載システム２０とは、外部ネットワーク３０を介して接続される。
　外部ネットワーク３０は、例えば、インターネットである。外部ネットワーク３０の通信方法は、有線であっても無線であってもよい。また、無線通信方式は既存技術であるＷｉ－Ｆｉ（登録商標）や、３Ｇ／ＬＴＥ（Long Term Evolution）やＢｌｕｅｔｏｏｔｈ（登録商標）、Ｖ２Ｘ通信方式であってもよい。
　監視サーバー１０は、車載システム２０から車載システム２０のセキュリティ状態に関する情報である監視結果を取得して、グラフィカルユーザーインターフェースを用いて監視結果を表示する装置である。監視サーバー１０は、例えば、セキュリティオペレーションセンターにて、セキュリティ分析官が監視結果を確認して、車載システム２０において異常が発生した場合にソフトウェア更新などの対策を検討する際に利用される。
　車載システム２０は、通信の制御、車両の制御、及び、映像の出力などを実施し、車載システム２０のセキュリティ状態を監視し、監視サーバー１０へセキュリティ状態の監視結果を通知する装置である。図１では、車載システム２０は１台のみ記載しているが、１以上の車載システム２０それぞれが、監視サーバー１０へセキュリティ状態の監視結果を送信する。車載システム２０の詳細は後述する。
　［車載システム２０の全体構成図］
　図２は、実施の形態における車載システムの構成図を示す図である。
　車載システム２０は、統合ＥＣＵ２００と、ゲートウェイＥＣＵ３００と、ステアリングＥＣＵ４００ａと、ブレーキＥＣＵ４００ｂと、ＺｏｎｅＥＣＵ５００と、フロントカメラＥＣＵ６００ａと、リアカメラＥＣＵ６００ｂとを備える。
　統合ＥＣＵ２００と、ゲートウェイＥＣＵ３００とは、ネットワークプロトコルの一種のＣＡＮ（Control Area Network）であるＣＡＮ４０を介して接続される。ここで利用されるネットワークプロトコルは、ＣＡＮに限らずに、ＣＡＮ－ＦＤや、ＦｌｅｘＲａｙプロトコルなどの車載システムで利用されるネットワークプロトコルであってもよい。
　また、ゲートウェイＥＣＵ３００と、ステアリングＥＣＵ４００ａと、ブレーキＥＣＵ４００ｂとは、ＣＡＮ４１を介して接続される。
　また、統合ＥＣＵ２００と、ＺｏｎｅＥＣＵ５００とは、ネットワークプロトコルの一種のＥｔｈｅｒｎｅｔ（商標登録）のプロトコルであるイーサネット５０を介して接続される。イーサネット５０は、例えば、ＳＯＭＥ／ＩＰ（Scalable Service-Oriented MiddlewarE over IP）プロトコルである。ここで利用されるネットワークプロトコルは、ＳＯＭＥ／ＩＰでなくとも、ＳＯＭＥ／ＩＰ－ＳＤや、ＣＡＮ－ＸＬなど車載システムで利用されるネットワークプロトコルであってもよい。
　また、ＺｏｎｅＥＣＵ５００と、フロントカメラＥＣＵ６００ａと、リアカメラＥＣＵ６００ｂとは、イーサネット５１を介して接続される。イーサネット５１は、イーサネット５０と同じネットワークプロトコルであってもよいし、異なるネットワークプロトコルであってもよい。
　また、統合ＥＣＵ２００と、監視サーバー１０とは、外部ネットワーク３０を介して接続される。
　統合ＥＣＵ２００は、外部ネットワーク３０、ＣＡＮ４０及びイーサネット５０を介してメッセージを送受信する通信制御と、ＣＡＮ４０及びイーサネット５０を介してゲートウェイＥＣＵ３００及びＺｏｎｅＥＣＵ５００へ車両の制御を指示する車両制御と、インフォテイメントシステムやインストルメントパネルへの映像出力とを実施するＥＣＵである。また、統合ＥＣＵ２００は、統合ＥＣＵ２００のセキュリティ状態を監視し、監視サーバー１０へ監視結果を通知するＥＣＵである。なお、本実施の形態における統合ＥＣＵ２００は、監視装置の一例であって、その詳細は後述する。
　ゲートウェイＥＣＵ３００は、統合ＥＣＵ２００と、ステアリングＥＣＵ４００ａ及びブレーキＥＣＵ４００ｂとの間で送受信されるメッセージを仲介するＥＣＵである。
　ステアリングＥＣＵ４００ａは、車両に搭載されるステアリングによる操舵を制御するＥＣＵである。
　ブレーキＥＣＵ４００ｂは、車両に搭載されるブレーキを制御するＥＣＵである。
　車載システム２０は、ステアリングＥＣＵ４００ａ及びブレーキＥＣＵ４００ｂの他に、車両のエンジンやボディを制御するＥＣＵを用いて車両の走る、曲がる、止まるといった制御を実現する。
　ＺｏｎｅＥＣＵ５００は、統合ＥＣＵ２００と、フロントカメラＥＣＵ６００ａ及びリアカメラＥＣＵ６００ｂとの間で送受信されるメッセージを仲介するＥＣＵである。
　フロントカメラＥＣＵ６００ａは、車両の前方に搭載され、車両の前方を撮影するカメラの映像を取得するＥＣＵである。
　リアカメラＥＣＵ６００ｂは、車両の後方に搭載され、車両の後方を撮影するカメラの映像を取得するＥＣＵである。
　図２では、フロントカメラＥＣＵとリアカメラＥＣＵのみが記載されているが、ＧＰＳなどの各種センサー情報を収集するＥＣＵを用いて、自動運転やアダプティブクルーズコントロール、自動駐車などの先進運転支援機能を実現してもよい。
　［統合ＥＣＵの構成図］
　図３は、実施の形態における統合ＥＣＵ２００の構成図である。統合ＥＣＵ２００は、外部アプリＡ１００と、制御アプリＡ２００と、映像アプリＡ３００と、外部仮想マシンＶＭ１００と、制御仮想マシンＶＭ２００と、映像仮想マシンＶＭ３００と、仮想化プラットフォームＶＰ１００と、監視アプリＡ４００と、監視仮想マシンＶＭ４００とを備える。なお、以下では、外部アプリＡ１００と、制御アプリＡ２００と、映像アプリＡ３００を総称してアプリケーションと呼ぶことがある。また、外部仮想マシンＶＭ１００と、制御仮想マシンＶＭ２００と、映像仮想マシンＶＭ３００と、監視仮想マシンＶＭ４００とを総称して仮想マシンと呼ぶことがある。
　仮想化プラットフォームＶＰ１００は、ハイパーバイザ等の仮想ソフトウェア基盤であり、１以上の仮想マシンを実行及び管理するソフトウェアである。一般に、ハイパーバイザは、タイプ１と呼ばれるベアメタル型ハイパーバイザと、タイプ２と呼ばれるホスト型とに区別される。組み込みシステムでは、一般に、ハイパーバイザによる処理のオーバーヘッドを考慮して、タイプ１が用いられる。タイプ１のハイパーバイザは、コードサイズが小さいため、脆弱性を含む可能性が低く、アプリケーションや仮想マシンと比較して信頼できると想定できる。
　実施の形態では、仮想化システムがタイプ１のハイパーバイザにより実現される例について説明するが、仮想化システムは、タイプ２のハイパーバイザにより実現されてもよい。
　外部仮想マシンＶＭ１００は、外部アプリＡ１００を動作させるオペレーティングシステムである。外部アプリＡ１００は、外部ネットワーク３０を介して監視サーバー１０と通信するアプリケーションソフトウェアプログラムである。
　制御仮想マシンＶＭ２００は、制御アプリＡ２００を動作させるオペレーティングシステムである。制御アプリＡ２００は、ＣＡＮ４０を介してゲートウェイＥＣＵ３００と通信し、車載システム２０を備える車両の走行に関する動作を制御するアプリケーションソフトウェアプログラムである。
　映像仮想マシンＶＭ３００は、映像アプリＡ３００を動作させるオペレーティングシステムである。映像アプリＡ３００は、イーサネット５０を介してＺｏｎｅＥＣＵ５００と通信し、カメラの映像などを取得し、インフォテイメントシステムやインストルメントパネル、ヘッドアップディスプレイに映像を出力するアプリケーションソフトウェアプログラムである。また、カメラ映像は自動運転などの先進運転支援機能を実現するための情報としても利用される。
　監視仮想マシンＶＭ４００は、仮想ドライバを用いて監視アプリＡ４００を動作させるオペレーティングシステムである。監視アプリＡ４００は、例えば、監視仮想マシンＶＭ４００以外の仮想マシン、仮想化プラットフォーム１００などを監視するアプリケーションソフトウェアプログラムである。
　なお、本実施の形態における統合ＥＣＵ２００では、例えば、準仮想化技術(virtio)が用いられている。この準仮想化技術は、仮想化プラットフォーム１００上の仮想マシンへ標準的なインタフェースを提供する技術であり、仮想化プラットフォーム１００が接続する物理デバイス(ストレージ、ネットワークデバイスなど)と高速な通信を可能にする。
　なお、図３では記載が省略されているが、燃料や給電状態、給油状態を管理する機能、事故などシステム異常が発生した場合に緊急アラートを発呼する機能、車両診断を制御する機能、外部デバイス接続を監視する機能が統合ＥＣＵ２００に搭載されてもよい。
　なお、外部仮想マシンＶＭ１００はサードパーティアプリのダウンロードや、Ｗｉ－ＦｉやＢｌｕｅｔｏｏｔｈなど外部ネットワークとの接続があるため、攻撃者に乗っ取られる可能性が比較的高い。制御仮想マシンＶＭ２００は自動車の走る、止まる、曲がるなど走行に関する制御をおこなうコマンドを送受信するため、コマンドのリアルタイム性が必要とされる。映像仮想マシンＶＭ３００は、ディスプレイを制御するため、カメラや車速の表示など一定のリアルタイム性が必要であり、外部ネットワークとの接続がないため、乗っ取られる可能性は比較的低い。このため、映像仮想マシンＶＭ３００については、送信時のコマンドよりも受信時コマンドの監視が必要とされる。これらから、外部仮想マシンが送信元である通信は詳細な監視が必要であり、制御仮想マシンが送信元または送信先である場合は、リアルタイム性を達成するために、簡易な監視が望ましい。
　［統合ＥＣＵの構成図の詳細］
　図４は、実施の形態における統合ＥＣＵ２００の一部の構成を詳細に示すブロック図である。
　外部仮想マシンＶＭ１００は、コマンドの送受信を実行するコマンド送受信部ＶＭ１０１を備える。コマンド送受信部ＶＭ１０１は、外部仮想マシンＶＭ１００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどへコマンドを送信する。また、コマンド送受信部ＶＭ１０１は、外部仮想マシンＶＭ１００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどからコマンドを受信する。
　制御仮想マシンＶＭ２００は、コマンドの送受信を実行するコマンド送受信部ＶＭ２０１を備える。コマンド送受信部ＶＭ２０１は、制御仮想マシンＶＭ２００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどへコマンドを送信する。また、コマンド送受信部ＶＭ２０１は、外部仮想マシンＶＭ１００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどからコマンドを受信する。
　映像仮想マシンＶＭ３００は、コマンドの送受信を実行するコマンド送受信部ＶＭ３０１を備える。コマンド送受信部ＶＭ３０１は、外部仮想マシンＶＭ１００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどへコマンドを送信する。また、コマンド送受信部ＶＭ３０１は、外部仮想マシンＶＭ１００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどからコマンドを受信する。
　監視仮想マシンＶＭ４００の監視アプリＡ４００は、コマンド受信部ＶＭ４１１、監視プログラム制御部ＶＭ４１２、簡易監視プログラムＶＭ４１３、詳細監視プログラムＶＭ４１４、異常対応部ＶＭ４１５、コマンド送信部ＶＭ４１６、システム状態取得部ＶＭ４１７、及び、システム構成取得部ＶＭ４１８を備える。
　コマンド受信部ＶＭ４１１は、監視仮想マシンＶＭ４００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどからコマンドを受信する。コマンド受信部ＶＭ４１１は、監視仮想マシンＶＭ４００以外の仮想マシン、つまり、外部仮想マシンＶＭ１００、制御仮想マシンＶＭ２００、及び、映像仮想マシンＶＭ３００のうちの少なくとも１つの対象仮想マシン（第２仮想マシン）において動作するプロセスが送信または受信するコマンドを取得する。
　監視プログラム制御部ＶＭ４１２は、コマンド受信部ＶＭ４１１により取得されたコマンドに含まれる識別子からコマンドの特性を参照して、コマンドの特性を特定する。そして、監視プログラム制御部ＶＭ４１２は、システム構成取得部ＶＭ４１８により取得された対象仮想マシンの構成を示す構成情報、及び、コマンドの特性に応じて、１以上の監視プログラムの実行方法を決定する。監視プログラム制御部ＶＭ４１２は、さらに、システム状態取得部ＶＭ４１７により取得された、対象仮想マシンのシステム状態に応じて、１以上の監視プログラムの実行方法を決定してもよい。なお、１以上の監視プログラムの実行方法の詳細については後述する。
　簡易監視プログラムＶＭ４１３は、コマンド受信部ＶＭ４１１により取得されたコマンドの簡易的な監視を行うプログラムの一例である。簡易監視プログラムＶＭ４１３は、例えば、パケットのヘッダフィールドをチェックし、許可リストでフィルタリングするＦｉｒｅｗａｌｌを行うプログラムであってもよいし、パケットの統計情報のみを取得して、通信ペアごとの通信量から異常を判定するフロー検知を行うプログラムであってもよい。つまり、簡易的な監視は、例えば、Ｆｉｒｅｗａｌｌ、フロー検知などである。
　詳細監視プログラムＶＭ４１４は、コマンド受信部ＶＭ４１１により取得されたコマンドの詳細な監視を行うプログラムの一例である。詳細監視プログラムＶＭ４１４は、例えば、コマンドのペイロードに異常が含まれているか否かを判定するDeep packet inspectionを行うプログラムであってもよい。つまり、詳細な監視は、例えば、Deep packet inspectionなどである。
　なお、監視アプリＡ４００は、簡易監視プログラムＶＭ４１３及び詳細監視プログラムＶＭ４１４を備えるとしたが、これに限らずに、種類が異なる複数の監視プログラムを備えていればよい。例えば、監視アプリＡ４００は、ファイルアクセス監視プログラム及びネットワーク監視プログラムを備えてもよい。ファイルアクセス監視プログラムは、ファイルアクセスに関するコマンドを監視するプログラムである。ファイルアクセス監視プログラムは、例えば、特定の仮想マシンが読み書き可能なファイルパスを許可リストとして保持して、許可リストに保持されているファイルパス以外の読み出し及び書き込みを異常と判定する処理を行うプログラムであってもよい。この場合、ファイルアクセス監視プログラムとしては、コマンドの種別に応じて、具体的な検知ルールを用いた監視プログラムが利用できる。ネットワーク監視プログラムは、ネットワークを介して授受するデータに関するコマンドを監視するプログラムである。
　また、簡易監視プログラムＶＭ４１３と詳細監視プログラムＶＭ４１４は、保持するルールが異なる同一の監視プログラムであってもよい。
　異常対応部ＶＭ４１５は、監視プログラムの監視結果を取得して、監視結果に異常が含まれる場合に異常を通知する。
　コマンド送信部ＶＭ４１６は、コマンドの監視結果に応じて、当該コマンドを監視仮想マシンＶＭ４００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどへ送信する。コマンド送信部ＶＭ４１６は、コマンドの監視結果に異常が含まれていれば当該コマンドを当該コマンドの宛先へ送信せず、コマンドの監視結果に異常が含まれていなければ当該コマンドを当該コマンドの宛先へ送信する。
　システム状態取得部ＶＭ４１７は、対象仮想マシンのシステム状態を取得する。システム状態の詳細は後述する。
　システム構成取得部ＶＭ４１８は、対象仮想マシンの構成情報を取得する。システム構成取得部ＶＭ４１８は、構成情報取得部の一例である。構成情報の詳細は後述する。
　仮想化プラットフォームＶＰ１００は、物理インタフェースＶＰ１０１を備える。物理インタフェースＶＰ１０１は、監視サーバー１０と、外部仮想マシンＶＭ１００、制御仮想マシンＶＭ２００、映像仮想マシンＶＭ３００、及び、監視仮想マシンＶＭ４００との間の通信を制御する。
　［仮想コマンド］
　図５は、実施の形態における仮想コマンドの一例を示す図である。
　仮想コマンドは、例えば図５に示すように、シーケンス番号などの番号と、コマンド種別用のヘッダと、ヘッダｈ１、ヘッダｈ２、およびペイロードとを含む。コマンド種別用のヘッダは、コマンド種別として例えばファイル操作、パケット送信、パケット受信などを示す。ヘッダｈ１は、仮想コマンドの送信先を示す。ヘッダｈ２は、仮想コマンドの送信元を示す。送信先または送信元は、ストレージデバイスであってもよく、外部ＥＣＵであってもよい。ペイロードには、ファイルパス、データ、ステアリング制御のデータ、制御値、アップデート内容、バイナリデータなどが含まれる。なお、ファイル操作には、データの読み取り要求または書き込み要求の２種類があり、ファイル操作の種類を識別するための情報がヘッダｈ１に格納されてもよい。
　［仮想マシンの構成情報］
　図６は、実施の形態における仮想マシンの構成情報の一例を示す図である。構成情報は、コマンドに含まれる識別子毎に、関連するシステムの構成情報を取得するためのテーブルである。
　仮想マシンの構成情報は、例えば図６に示すように、仮想マシンを識別する識別子と、仮想マシンのＯＳ（Operating System）種別と、ＡＳＩＬ（Automotive Safety Integrity Level）と、外部接続機能と、タイムアウト時間と、呼び出し方と、ディスプレイ表示機能とを含む。ＡＳＩＬは、自動車の安全レベルを示す。外部接続機能は、仮想マシンが外部デバイスとの間で通信接続可能か否かを示す。タイムアウト時間は、監視プログラムの処理に設定されるタイムアウト時間を示す。呼び出し方は、監視プログラムをコマンドの送受信処理に対して直列で処理するか、並列で処理するかを示す。つまり、直列で処理する場合、監視プログラムがコマンドに対して実行された後に、コマンドの送受信処理が実行される。並列で処理する場合、コマンドに対する監視プログラムの実行と、コマンド送受信処理とが並列で処理される。ディスプレイ表示機能は、仮想マシンが表示機能を有するか否かを示す。
　構成情報のうち、ＯＳ種別及び外部接続機能は、攻撃者の乗っ取られやすさの判断に用いられてもよい。ＡＳＩＬは、リアルタイム性の判断に用いられてもよい。ＡＳＩＬは、Ｄ、Ｃ、Ｂ、Ａ、ＱＭの順に高いレベルに設定され、高いほどリアルタイム性が必要と判断されてもよい。タイムアウト時間は、監視プログラムのタイムアウト時間の設定に用いられる。呼び出し方は、監視プログラムの呼び出し方の決定に用いられる。タイムアウト時間及び呼び出し方は、識別子ごとではなくリアルタイム性に基づいて決定されてもよい。ディスプレイ表示機能は、異常検知時に表示するために用いられてもよい。異常発生が疑われ、かつ、表示機能を有する仮想マシンは、異常を表示する処理を実行してもよい。システムの更新にともなって、仮想マシンの構成情報には、追加、削除、及び、変更のいずれかが行われる可能性がある。この場合であっても、監視プログラム制御部は、更新された構成情報を示すテーブルを参照すればよい。
　［仮想マシンのシステム状態］
　図７は、実施の形態における仮想マシンのシステム状態の一例を示す図である。仮想マシンのシステム状態は、仮想マシン毎のシステム状態を取得して保持するデータベースである。システム状態は、各仮想マシンに問い合わせることで得られてもよいし、仮想化プラットフォームＶＰ１００に問い合わせることで得られてもよい。システム状態は、問い合わせて得られた情報に基づいて更新されてもよい。
　仮想マシンのシステム状態は、例えば、図７に示すように、仮想マシンを識別する識別子と、仮想マシンの起動状態と、システム負荷と、仮想コマンド負荷と、ネットワーク状態と、走行状態と、走行モードと、セキュリティ異常とを含む。仮想マシンの起動状態は、仮想マシンが起動済み（つまり起動中）であるか、仮想マシンが停止中であるかを示す。起動状態は、異常対応部ＶＭ４１５で仮想マシンを再起動した場合に、再起動完了したか確認するために用いられてもよい。仮想マシンのシステム状態は、監視装置を備える車両の走行状態、車両の走行モード、仮想マシンのシステム負荷、コマンドの処理におけるシステム負荷、仮想マシンのネットワーク接続状態、仮想マシン内のセキュリティ異常の有無、及び、仮想コマンドのセキュリティ異常の有無の少なくとも１つである。
　システム負荷は、ＣＰＵ及びメモリの少なくとも一方の使用率である。システム負荷は、低い場合に詳細な監視プログラムをＯＮにし、高い場合にＯＦＦにする判断で用いられてもよい。システム負荷は、例えば、低、中、及び、高のいずれかであるかを示す。中は、低よりも負荷が高いことを示し、高は、中よりも負荷が高いことを示す。システム負荷は、上記の３段階の場合に限らずに、低、高の２段階で示されてもよい。この場合、高は、低よりも負荷が高いことを示す。
　仮想コマンド負荷は、仮想コマンドに関する処理の負荷である。仮想コマンド負荷が高いことは、監視プログラムを並列で呼び出す、または、複数の監視プログラムで処理を分担するという判断に用いられてもよい。また、仮想コマンド負荷が低いことは、監視プログラムを直列で呼び出しても、詳細監視プログラムを呼び出しても仮想コマンドの遅延等の影響が小さいと判断されてもよい。仮想コマンド負荷は、例えば、低、中、及び、高の何れであるかを示す。中は、低よりも負荷が高いことを示し、高は、中よりも負荷が高いことを示す。仮想コマンド負荷は、上記の３段階の場合に限らずに、低、高の２段階で示されてもよい。この場合、高は、低よりも負荷が高いことを示す。
　ネットワーク状態は、外部機器への通信接続が、接続済み（つまり接続中）であるか未接続であるかを示す。ネットワーク状態は、外部機器への通信機能を有する仮想マシンのみで示される。ネットワーク状態は、接続済みの場合に、乗っ取られやすいと判断して詳細な監視プログラムをＯＮにするための判断で用いられてもよい。
　走行状態は、車両が走行中であるか、停止中であるかを示す。走行状態が走行中を示す場合、制御仮想マシンＶＭ２００への通信は安全影響があるため、監視プログラムは、リアルタイム性に影響を与えないように並列で呼び出されてもよい。走行状態が停止中を示す場合、安全影響がないので監視プログラムは呼び出されなくてもよい。一方で、走行状態が停止中を示す場合はシステム負荷が低いため、全ての監視プログラムが呼び出されてもよい。
　走行モードは、車両が自動運転中であるか手動運転中であるかを示す。走行モードが自動車運転中を示す場合、制御仮想マシンＶＭ２００への通信は安全影響があるため、監視プログラムは、リアルタイム性に影響を与えないように並列で呼び出されてもよい。走行モードが手動運転中を示す場合、安全影響がないので監視プログラムは呼び出されなくてもよい。
　セキュリティ異常は、セキュリティに関する異常が発生しているか、異常が発生していないか（つまり、正常か）を示す。セキュリティ異常は、簡易プログラムで異常であると判定された場合に、異常対応部ＶＭ４１５が該当仮想マシンを異常状態に設定し、異常状態の場合に詳細な監視プログラムを実行するために用いられてもよい。なお、仮想マシンごとのセキュリティ異常は、簡易プログラムの異常判定結果でなく、他のプログラムによる異常判定結果に基づいて設定されてもよい。例えば、仮想マシン内のＳＥＬｉｎｕｘ（Ｓｅｃｕｒｉｔｙ－Ｅｎｈａｎｃｅｄ　Ｌｉｎｕｘ）などのアクセスコントロール機構によって特定の処理が拒否された場合に該当仮想マシンがセキュリティ異常状態に設定されてもよい。
　［監視仮想マシンの処理シーケンス］
　図８は、実施の形態における監視仮想マシンの処理シーケンスの一例を示す図である。
　図８に示すように、コマンド受信部ＶＭ４１１は、監視仮想マシンＶＭ４００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどからコマンドを受信し、受信したコマンドを識別する（Ｓ１０１）。これにより、システム構成取得部ＶＭ４１８は、コマンドに含まれる識別子に基づいて、コマンドを送信した仮想マシン、または、コマンドを受信した仮想マシンの構成情報を取得する。また、システム状態取得部ＶＭ４１７は、コマンドに含まれる識別子に基づいて、コマンドを送信した仮想マシン、または、コマンドを受信した仮想マシンのシステム状態を取得してもよい。ステップＳ１０１により得られた、コマンドの識別子、仮想マシンの構成情報、及び、仮想マシンのシステム状態は、監視プログラム制御部ＶＭ４１２へ通知される。
　次に、監視プログラム制御部ＶＭ４１２は、コマンドの識別子からコマンドの特性を参照し、通知された構成情報及びシステム状態と、コマンドの特性とに応じて、当該コマンドに対して実行すべき１以上の監視プログラムを決定する（Ｓ１０２）。具体的には、監視プログラム制御部ＶＭ４１２は、受信したコマンドに対して実行すべき１以上の監視プログラムのそれぞれについて実行するか否か（つまり、各監視プログラムのＯＮ／ＯＦＦ）を決定してもよい。監視プログラム制御部ＶＭ４１２は、例えば、外部接続する外部仮想マシンＶＭ１００に対するコマンドであれば全ての監視プログラムを実行すると決定してもよい。また、監視プログラム制御部ＶＭ４１２は、例えば、外部接続しない映像仮想マシンＶＭ３００に対するコマンドであれば一部の監視プログラムのみを実行し、必須でない処理を削減してもよい。また、監視プログラム制御部ＶＭ４１２は、例えば、受信時ならFirewallのみの簡易監視プログラムを実行し、送信時は簡易監視プログラム及び詳細監視プログラム（つまりFirewall＋ペイロード監視）を実行すると決定してもよい。つまり、仮想マシン単位ではなく通信単位で監視プログラムを変更してもよい。例えば、監視プログラム制御部ＶＭ４１２は、車両の制御に影響するコマンドに対してのみ監視プログラムを実行し、制御に影響しないコマンドに対しては監視プログラムを実行しなくてもよい。また、監視プログラム制御部ＶＭ４１２は、コマンドの種別がファイル操作である場合は、システム影響が小さい読み取り要求やシステム影響が大きい書き込み要求などのファイル操作の種類に応じて監視プログラムを変更してもよい。このように、脅威の大きさに応じて処理を削減できる。なお、ステップＳ１０２の具体例は、後述する。ここで、コマンドの特性は、コマンドの送信元または送信先の仮想マシン、コマンドの送信先または送信先の電子制御装置、コマンドの送信方向、コマンドに含まれるファイル操作のアクセス先、送信元または送信先の仮想マシンのＯＳ（Operating System）種別、送信元または送信先の仮想マシンの外部接続機能の有無、コマンドのＡＳＩＬ、及び、コマンドの車両制御への影響の少なくとも１つである。コマンドの特性は、監視装置を備える車両の走行状態、車両の走行モード、及び、システム状態の少なくとも１つを含んでいてもよい。
　次に、監視プログラム制御部ＶＭ４１２は、監視プログラムの呼び出し方法（つまり、呼び出し方）を決定する（Ｓ１０３）。監視プログラム制御部ＶＭ４１２は、例えば、受信したコマンドが、制御仮想マシンＶＭ２００に対するコマンドであれば監視プログラムを並列で呼び出すと決定し、外部仮想マシンＶＭ１００に対するコマンドであれば監視プログラムを直列で呼び出すと決定してもよい。これにより、遅延影響がない通信の異常に即時対応できる。なお、ステップＳ１０３の具体例は、後述する。
　次に、監視プログラム制御部ＶＭ４１２は、監視プログラムのタイムアウト時間を決定する（Ｓ１０４）。監視プログラム制御部ＶＭ４１２は、例えば、受信したコマンドが、制御仮想マシンＶＭ２００に対するコマンドであればタイムアウト時間を短時間に設定し、外部仮想マシンＶＭ１００に対するコマンドであればタイムアウト時間を長時間に設定してもよい。これにより、通信遅延を保証できる。なお、ステップＳ１０４の具体例は、後述する。
　次に、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムの実行の順序を決定する（Ｓ１０５）。監視プログラム制御部ＶＭ４１２は、例えば、簡易監視プログラム（Firewall）で異常と判定された場合のみ、詳細監視プログラム（ペイロード監視）の実行を決定してもよいし、詳細監視プログラムの実行のスキップを決定してもよい。これにより、処理負荷の高い監視の処理回数を削減できる。なお、ステップＳ１０５の具体例は後述する。
　次に、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムのうち実行すると決定された簡易監視プログラムＶＭ４１３の呼び出しを行う（Ｓ１０６）。そして、簡易監視プログラムＶＭ４１３による監視処理が実行される（Ｓ１０７）。
　次に、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムのうち実行すると決定された詳細監視プログラムＶＭ４１４の呼び出しを行う（Ｓ１０８）。そして、詳細監視プログラムＶＭ４１４による監視処理が実行される（Ｓ１０９）。
　次に、監視プログラム制御部ＶＭ４１２は、対応アプリの呼び出しを行う（Ｓ１１０）。これにより、異常対応部ＶＭ４１５は、異常対応処理を実行する（Ｓ１１１）。異常対応処理では、監視処理の監視結果に応じて、コマンドのロギング、コマンドのドロップ、仮想マシンの再起動、システムの再起動などが実行される。なお、ステップＳ１１１の詳細は後述する。
　次に、監視プログラム制御部ＶＭ４１２は、受信したコマンドを指定の宛先の仮想マシン、外部ＥＣＵ、外部デバイスなどに送信するために、コマンド送信部ＶＭ４１６へ送信する（Ｓ１１２）。監視プログラム制御部ＶＭ４１２は、例えば、監視処理において正常と判定されたコマンドを指定の宛先の仮想マシン、外部ＥＣＵ、外部デバイスなどに送信するために、コマンド送信部ＶＭ４１６へ送信する。監視プログラム制御部ＶＭ４１２は、例えば、監視処理において以上と判定されたコマンドを指定の宛先の仮想マシン、外部ＥＣＵ、外部デバイスなどに送信するために、コマンド送信部ＶＭ４１６へ送信しなくてもよい。そして、コマンド送信部ＶＭ４１６は、監視プログラム制御部ＶＭ４１２から受信したコマンドを指定の宛先の仮想マシン、外部ＥＣＵ、外部デバイスなどに送信する（Ｓ１１３）。
　［監視プログラムの決定］
　図９は、実施の形態における監視プログラムの決定処理（Ｓ１０２）のフローチャートの一例を示す図である。監視プログラムの決定処理では、対象の仮想マシンが外部仮想マシンＶＭ１００である場合、外部と通信可能であり外部から乗っ取られる可能性が高いため、外部仮想マシンＶＭ１００からの通信の詳細をチェックするように監視プログラムが決定されてもよい。また、監視プログラムの決定処理では、対象の仮想マシンが制御仮想マシンＶＭ２００である場合、制御仮想マシンＶＭ２００にはリアルタイム性が要求されるため、監視プログラムによる監視処理がスキップされてもよい。また、監視プログラムの決定処理では、対象の仮想マシンが映像仮想マシンＶＭ３００である場合、映像仮想マシンＶＭ３００は直接乗っ取られる可能性は低いので、受信するコマンドに対して詳細監視プログラムが実行されてもよい。
　図９に示すように、監視プログラム制御部ＶＭ４１２は、コマンド受信部ＶＭ４１１からコマンドを取得する（Ｓ１２１）。
　次に、監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元または送信先の仮想マシンのＯＳ種別を判定する（Ｓ１２２）。
　監視プログラム制御部ＶＭ４１２は、コマンドの送信元または送信先の仮想マシンのＯＳ種別がＡｎｄｒｏｉｄである場合（Ｓ１２２でＡｎｄｒｏｉｄ）、ステップＳ１２３を実行し、当該ＯＳ種別がＬｉｎｕｘ（登録商標）である場合（Ｓ１２２でＬｉｎｕｘ）、ステップＳ１２７を実行し、当該ＯＳ種別がＲＴＯＳである場合（Ｓ１２２でＲＴＯＳ）、ステップＳ１３１を実行する。
　ステップＳ１２３において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラムをＯＮに設定する。つまり、簡易監視プログラムを実行することが設定される。
　次に、監視プログラム制御部ＶＭ４１２は、コマンドが送信されたコマンドであるか受信されたコマンドであるかを判定する（Ｓ１２４）。
　監視プログラム制御部ＶＭ４１２は、コマンドが送信されたコマンドである場合（Ｓ１２４で送信）、ステップＳ１２５を実行し、コマンドが受信されたコマンドである場合（Ｓ１２４で受信）、ステップＳ１２６を実行する。
　ステップＳ１２５において、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＮに設定する。つまり、詳細監視プログラムを実行することが設定される。
　ステップＳ１２６において、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＦＦに設定する。つまり、詳細監視プログラムを実行しないことが設定される。
　ステップＳ１２７において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラムをＯＮに設定する。つまり、簡易監視プログラムを実行することが設定される。
　次に、監視プログラム制御部ＶＭ４１２は、コマンドが送信されたコマンドであるか受信されたコマンドであるかを判定する（Ｓ１２８）。
　監視プログラム制御部ＶＭ４１２は、コマンドが送信されたコマンドである場合（Ｓ１２８で送信）、ステップＳ１２９を実行し、コマンドが受信されたコマンドである場合（Ｓ１２８で受信）、ステップＳ１３０を実行する。
　ステップＳ１２９において、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＦＦに設定する。つまり、詳細監視プログラムを実行しないことが設定される。
　ステップＳ１２６において、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＮに設定する。つまり、詳細監視プログラムを実行することが設定される。
　ステップＳ１３１において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラムをＯＦＦに設定する。つまり、簡易監視プログラムを実行しないことが設定される。
　次に、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＦＦに設定する（Ｓ１３２）。つまり、詳細監視プログラムを実行しないことが設定される。
　このようにして、取得したコマンドに対する仮想マシンのＯＳ種別と、コマンドが送信されたか受信されたかを示す、コマンドの送受信状態とに応じて、コマンドに対して、簡易監視プログラムを実行するか否か、及び、詳細監視プログラムを実行するか否かが決定されてもよい。
　なお、外部のネットワークへの接続状態、走行状態、及び、走行モードの少なくとも１つに応じて簡易監視プログラムのＯＮ／ＯＦＦ及び詳細監視プログラムのＯＮ／ＯＦＦが判断されてもよい。例えば、外部のネットワークへ接続中であれば、外部仮想マシンＶＭ１００からのコマンドは疑わしいので、詳細監視プログラムがＯＮに設定されてもよい。また、走行中または自動運転中であれば、映像仮想マシンからのコマンドは安全に影響がある可能性があるため、詳細監視プログラムがＯＮに設定されてもよい。
　［監視プログラムの呼び出し］
　図１０は、実施の形態における監視プログラムの呼び出し処理（Ｓ１０３）のフローチャートの一例を示す図である。監視プログラムの呼び出し処理では、対象の仮想マシンが外部仮想マシンＶＭ１００である場合、外部と通信可能であり外部から乗っ取られる可能性が高いため、外部仮想マシンＶＭ１００からの通信の詳細をチェックするように監視プログラムが決定されてもよい。また、監視プログラムの決定処理では、対象の仮想マシンが制御仮想マシンＶＭ２００である場合、制御仮想マシンＶＭ２００は直接乗っ取られる可能性が低いため、外部仮想マシンＶＭ１００、外部ＥＣＵ、外部デバイスなどから受信したコマンドの詳細をチェックするように監視プログラムが決定されてもよい。
　図１０に示すように、監視プログラム制御部ＶＭ４１２は、コマンドを取得する（Ｓ１４１）。なお、ステップＳ１４１は、ステップＳ１２１と同じ処理であるため、省略されてもよい。
　次に、監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元または送信先の仮想マシンのＯＳ種別を判定する（Ｓ１４２）。なお、ステップＳ１４２は、ステップＳ１２２と同じ処理であるため、省略されてもよい。
　監視プログラム制御部ＶＭ４１２は、コマンドの送信元または送信先の仮想マシンのＯＳ種別がＡｎｄｒｏｉｄである場合（Ｓ１４２でＡｎｄｒｏｉｄ）、ステップＳ１４３を実行し、当該ＯＳ種別がＬｉｎｕｘである場合（Ｓ１４２でＬｉｎｕｘ）、ステップＳ１４６を実行し、当該ＯＳ種別がＲＴＯＳである場合（Ｓ１４２でＲＴＯＳ）、ステップＳ１４９を実行する。
　ステップＳ１４３において、監視プログラム制御部ＶＭ４１２は、コマンドが送信されたコマンドであるか受信されたコマンドであるかを判定する。
　監視プログラム制御部ＶＭ４１２は、コマンドが送信されたコマンドである場合（Ｓ１４３で送信）、ステップＳ１４４を実行し、コマンドが受信されたコマンドである場合（Ｓ１４３で受信）、ステップＳ１４５を実行する。
　ステップＳ１４４において、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムの呼び出し方を並列に設定する。
　ステップＳ１４５において、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムの呼び出し方を直列に設定する。
　ステップＳ１４６において、監視プログラム制御部ＶＭ４１２は、コマンドが送信されたコマンドであるか受信されたコマンドであるかを判定する。
　監視プログラム制御部ＶＭ４１２は、コマンドが送信されたコマンドである場合（Ｓ１４６で送信）、ステップＳ１４７を実行し、コマンドが受信されたコマンドである場合（Ｓ１４６で受信）、ステップＳ１４８を実行する。
　ステップＳ１４７において、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムの呼び出し方を並列に設定する。
　ステップＳ１４８において、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムの呼び出し方を直列に設定する。
　ステップＳ１４９において、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムの呼び出し方を並列に設定する。
　監視プログラムの呼び出し方が直列に設定される場合、コマンドを送信先に送信する前に監視処理を実行するため、異常検知した場合に即座にコマンドを停止できる。つまり、直列で監視プログラムを呼び出す場合、監視処理が終了するまでコマンドの送信が停止してしまう。一方で、監視プログラムの呼び出し方が並列に設定される場合、コマンドの監視処理を待たずにコマンドを送信先に送信することができる。
　［監視プログラムのタイムアウト時間の決定］
　図１１は、実施の形態における監視プログラムのタイムアウト時間の決定処理（Ｓ１０４）のフローチャートの一例を示す図である。監視プログラムのタイムアウト時間の決定処理では、監視対象の仮想マシンが制御仮想マシンＶＭ２００である場合、制御仮想マシンＶＭ２００にはリアルタイム性が要求されるため、監視プログラムによる監視処理のタイムアウト時間が短時間に設定されてもよい。
　図１１に示すように、監視プログラム制御部ＶＭ４１２は、コマンドを取得する（Ｓ１５１）。なお、ステップＳ１５１は、ステップＳ１２１、ステップＳ１４１と同じ処理であるため、省略されてもよい。
　次に、監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元または送信先の仮想マシンのＯＳ種別を判定する（Ｓ１５２）。なお、ステップＳ１５２は、ステップＳ１２２及びステップＳ１４２と同じ処理であるため、省略されてもよい。
　監視プログラム制御部ＶＭ４１２は、コマンドの送信元または送信先の仮想マシンのＯＳ種別がＡｎｄｒｏｉｄである場合（Ｓ１５２でＡｎｄｒｏｉｄ）、ステップＳ１５３を実行し、当該ＯＳ種別がＬｉｎｕｘである場合（Ｓ１５２でＬｉｎｕｘ）、ステップＳ１５４を実行し、当該ＯＳ種別がＲＴＯＳである場合（Ｓ１５２でＲＴＯＳ）、ステップＳ１５５を実行する。
　ステップＳ１５３において、監視プログラム制御部ＶＭ４１２は、監視処理のタイムアウト時間を長時間に設定する。
　ステップＳ１５４において、監視プログラム制御部ＶＭ４１２は、監視処理のタイムアウト時間を長時間に設定する。
　ステップＳ１５５において、監視プログラム制御部ＶＭ４１２は、監視処理のタイムアウト時間を短時間に設定する。
　タイムアウト時間は、短時間に設定されることで、最大遅延を短くできるため低遅延を保証できるが、監視処理が終わらない可能性もある。一方で、タイムアウト時間は、長時間に設定されることで、監視処理に時間を多く使えるが、コマンド送信に時間がかかるため遅延が大きくなる可能性がある。
　［監視プログラムの決定（別の例）］
　図１２は、実施の形態における監視プログラムの決定処理（Ｓ１０２）のフローチャートの他の一例を示す図である。
　図１２に示すように、監視プログラム制御部ＶＭ４１２は、コマンド受信部ＶＭ４１１からコマンドを取得する（Ｓ１６１）。
　次に、監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元の仮想マシンのセキュリティ異常があるか否かを判定する（Ｓ１６２）。
　監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元の仮想マシンのセキュリティ異常があると判定した場合（Ｓ１６２でＹｅｓ）、ステップＳ１６３を実行し、取得したコマンドの送信元の仮想マシンのセキュリティ異常がないと判定した場合（Ｓ１６２でＮｏ）、ステップＳ１６５を実行する。
　ステップＳ１６３において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラムをＯＮに設定する。つまり、簡易監視プログラムを実行することが設定される。
　次に、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＮに設定する（Ｓ１６４）。つまり、詳細監視プログラムを実行することが設定される。
　ステップＳ１６５において、監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元の仮想マシンのシステム処理負荷が高いか低いかを判定する。
　監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元の仮想マシンのシステム処理負荷が低いと判定した場合（Ｓ１６５で低）、ステップＳ１６６を実行し、取得したコマンドの送信元の仮想マシンのシステム処理負荷が高いと判定した場合（Ｓ１６５で高）、ステップＳ１６８を実行する。
　ステップＳ１６６において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラムをＯＮに設定する。つまり、簡易監視プログラムを実行することが設定される。
　次に、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＮに設定する（Ｓ１６７）。つまり、詳細監視プログラムを実行することが設定される。
　ステップＳ１６８において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラムをＯＦＦに設定する。つまり、簡易監視プログラムを実行しないことが設定される。
　次に、監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元の仮想マシンが外部ネットワークに接続済みであるか否かを判定する（Ｓ１６９）。
　監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元の仮想マシンが外部ネットワークに接続済みでないと判定した場合（Ｓ１６９でＮｏ）、ステップＳ１７０を実行し、取得したコマンドの送信元の仮想マシンが外部ネットワークに接続済みであると判定した場合（Ｓ１６９でＹｅｓ）、ステップＳ１７１を実行する。
　ステップＳ１７０において、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＦＦに設定する。つまり、詳細監視プログラムを実行しないことが設定される。
　ステップＳ１７１において、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＮに設定する。つまり、詳細監視プログラムを実行することが設定される。
　ステップＳ１７０またはステップＳ１７１が終了すると、監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元の仮想マシンまたは送信先の仮想マシンのＯＳ種別がＲＴＯＳか否かを判定する（Ｓ１７２）。
　監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元の仮想マシンまたは送信先の仮想マシンのＯＳ種別がＲＴＯＳである場合（Ｓ１７２でＹｅｓ）、ステップＳ１７３を実行し、取得したコマンドの送信元の仮想マシンまたは送信先の仮想マシンのＯＳ種別がＲＴＯＳでない場合（Ｓ１７２でＮｏ）、監視プログラムの決定処理を終了する。
　ステップＳ１７３において、監視プログラム制御部ＶＭ４１２は、車両の走行状態が走行中であるか停止中であるかを判定する。
　監視プログラム制御部ＶＭ４１２は、車両の走行状態が走行中であると判定した場合（Ｓ１７３で走行中）、ステップＳ１７４を実行し、車両の走行状態が停止中であると判定した場合（Ｓ１７３で停止中）、ステップＳ１７６を実行する。
　ステップＳ１７４において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラム及び詳細監視プログラムをＯＮに設定する。つまり、簡易監視プログラム及び詳細監視プログラムを実行することが設定される。
　次に、監視プログラム制御部ＶＭ４１２は、監視プログラムの呼び出し方を並列に決定する（Ｓ１７５）。ステップＳ１７５が終了するとステップＳ１７６が実行される。
　ステップＳ１７６において、監視プログラム制御部ＶＭ４１２は、車両の走行モードが自動運転であるか手動運転であるかを判定する。
　監視プログラム制御部ＶＭ４１２は、車両の走行モードが自動運転であると判定した場合（Ｓ１７６で自動運転）、ステップＳ１７７を実行し、車両の走行モードが手動運転であると判定した場合（Ｓ１７６で手動運転）、監視プログラムの決定処理を終了する。
　ステップＳ１７７において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラム及び詳細監視プログラムをＯＮに設定する。つまり、簡易監視プログラム及び詳細監視プログラムを実行することが設定される。
　次に、監視プログラム制御部ＶＭ４１２は、監視プログラムの呼び出し方を並列に決定する（Ｓ１７８）。ステップＳ１７８が終了すると監視プログラムの決定処理を終了する。
　［監視プログラムの順序の決定］
　図１３は、実施の形態における監視プログラムの順序の決定及び監視プログラムの実行処理（Ｓ１０５～Ｓ１０９）のフローチャートの一例を示す図である。
　図１３に示すように、監視プログラム制御部ＶＭ４１２は、コマンド受信部ＶＭ４１１からコマンドを取得する（Ｓ１８１）。なお、ステップＳ１８１は、ステップＳ１２１、ステップＳ１４１、及び、ステップＳ１５１と同じ処理であるため、省略されてもよい。
　次に、監視プログラム制御部ＶＭ４１２は、複数の監視プログラムが直列で呼び出されるか否かを判定する（Ｓ１８２）。
　監視プログラム制御部ＶＭ４１２は、複数の監視プログラムが直列で呼び出されないと判定した場合（Ｓ１８２でＮｏ）、ステップＳ１８３を実行し、複数の監視プログラムが直列で呼び出されると判定した場合（Ｓ１８２でＹｅｓ）、ステップＳ１８４を実行する。なお、複数の監視プログラムが直列で呼び出されない場合とは、１つの監視プログラムが呼び出される場合と、複数の監視プログラムが並列で呼び出される場合とを含む。
　ステップＳ１８３において、監視プログラム制御部ＶＭ４１２は、ＯＮに設定された監視プログラム（簡易監視プログラム及び詳細監視プログラムの少なくとも一方）を実行する。
　ステップＳ１８４において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラムを実行する。
　次に、監視プログラム制御部ＶＭ４１２は、簡易監視プログラムによる監視処理の監視結果が異常であるか否かを判定する（Ｓ１８５）。
　監視プログラム制御部ＶＭ４１２は、簡易監視プログラムによる監視処理の監視結果が異常であると判定した場合（Ｓ１８５でＹｅｓ）、ステップＳ１８６を実行し、簡易監視プログラムによる監視処理の監視結果が異常でない（つまり正常である）と判定した場合（Ｓ１８５でＮｏ）、監視プログラムの順序の決定処理を終了する。
　ステップＳ１８６において、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムを実行する。
　このように、監視プログラムの順序の決定処理を実行することで、例えば、簡易監視プログラムによる監視結果が異常の場合のみ詳細監視プログラムを実行するため、より詳細な異常を検出することができる。
　なお、簡易監視プログラムによる監視結果が異常の場合には異常を確定させることで、詳細監視プログラムの実行をスキップしてもよい。これにより、異常が発生したことを通知するまでに要する時間を削減することができる。
　［異常対応処理］
　図１４は、実施の形態における異常対応処理（Ｓ１１１）のフローチャートの一例を示す図である。
　図１４に示すように、異常対応部ＶＭ４１５は、監視処理における監視結果を取得する（Ｓ１９１）。
　次に、異常対応部ＶＭ４１５は、監視結果が１以上異常であるか否かを判定する（Ｓ１９２）。
　異常対応部ＶＭ４１５は、監視結果が１以上異常であると判定した場合（Ｓ１９２でＹｅｓ）、ステップＳ１９３を実行し、監視結果が１以上異常でない、つまり、異常がなかった場合（Ｓ１９２でＮｏ）、異常対応処理を終了する。なお、異常応答処理の要否はこのように閾値（１以上）によって判断してもよいし、多数決で判断してもよいし、統計処理アルゴリズムによって判断をしてもよい。さらに、仮想マシンのシステム状態に含まれる、仮想マシンの起動状態と、システム負荷と、仮想コマンド負荷と、ネットワーク状態と、走行状態と、走行モードと、セキュリティ異常のうち少なくとも１つを考慮して判断してもよい。これにより、信頼性と確実性の高い異常対応処理を実現できる。
　ステップＳ１９３において、異常対応部ＶＭ４１５は、異常を含む監視結果のログをグルーピングして記憶する。つまり、グルーピングログを記憶する。グルーピングログの詳細は後述する。
　次に、異常対応部ＶＭ４１５は、監視結果による異常が詳細監視プログラムの監視処理により検出された異常であるか否かを判定する（Ｓ１９４）。
　異常対応部ＶＭ４１５は、監視結果による異常が詳細監視プログラムの監視処理により検出された異常であると判定した場合（Ｓ１９４でＹｅｓ）、ステップＳ１９５を実行し、監視結果による異常が詳細監視プログラムの監視処理により検出された異常でない（つまり簡易監視プログラムの監視処理により検出された異常である）と判定した場合（Ｓ１９４でＮｏ）、異常対応処理を終了する。
　ステップＳ１９５において、異常対応部ＶＭ４１５は、取得したコマンドをドロップさせる（つまり、コマンドを利用しないように処理する）。例えば、コマンドを破棄してもよいし、コマンドが利用できないことを示す情報（フラグ）を付与してもよい。コマンドが利用できないことを示す情報（フラグ）が付与されたコマンドは、仮想マシン、他の機器などに利用されない。
　次に、異常対応部ＶＭ４１５は、異常を通知して、例えば、表示機能を有する仮想マシン（映像仮想マシンＶＭ３００）に発生した異常を含むＵＩを表示させる（Ｓ１９６）。
　なお、異常対応部ＶＭ４１５は、簡易監視及び詳細監視の両方において異常であり、確実に異常と判定できた場合のみコマンドをドロップしてもよい。
　また、異常対応部ＶＭ４１５は、監視プログラムのフィルタリングルールを変更してもよい。これにより、次回から異常を検出されたコマンドをドロップできる。
　また、異常対応部ＶＭ４１５は、異常なコマンドの送信元である仮想マシンを再起動または停止してもよい。これにより、攻撃プロセスを止めることができる。
　また、異常対応部ＶＭ４１５は、異常な仮想マシンが一定数以上ある場合、システム全体を再起動してもよい。これにより、セキュアブートによりセーフティ起動が可能になる。
　また、異常対応部ＶＭ４１５は、異常を通知して表示してもよい。異常対応部ＶＭ４１５は、仮想マシンが担当する車内のディスプレイに異常を表示させてもよいし、または、監視サーバー１０へ通知して監視サーバーにて異常を表示させてもよい。
　また、異常対応部ＶＭ４１５は、前回の監視結果に基づいて、監視プログラムのＯＮ／ＯＦＦを決定してもよい。この場合、仮想マシンのシステム状態をセキュリティ状態が異常であると設定し、システム状態に応じて、監視プログラムのＯＮ／ＯＦＦを設定してもよい。
　［グルーピングログ］
　図１５及び図１６は、実施の形態におけるグルーピングログの一例を示す図である。
　グルーピングログは、仮想マシン毎に当該仮想マシンに対するコマンドに異常があったことを記録したログである。図１５及び図１６に示すように、グルーピングログは、異常ＩＤと、異常名と、異常識別子と、仮想マシン識別子と、回数と、最終時刻とを含む。異常ＩＤは、異常名及び監視対象の仮想マシンが同じ異常であることを示す。異常名は、異常の種類の名称である。異常識別子は、異常を識別する情報である。仮想マシン識別子は、仮想マシンを識別する情報である。回数は、同じ異常識別子の異常が発生した回数を示す。最終時刻は、最後に該当する異常が発生した時刻を示す。
　このように、グルーピングログによって、監視プログラム制御部ＶＭ４１２が検出した異常に関連するログ情報を抽出できるため、異常対応部ＶＭ４１５が監視サーバー１０へグルーピングログを送信し、監視サーバー１０のグラフィカルユーザーインターフェース上にグルーピングログを表示することで、分析官の分析を効率的に実現できる。
　また、グルーピングログは監視プログラムで利用されてもよく、例えば、監視プログラムがグルーピングログを定期的に取得し、特定の仮想マシンの異常の発生回数が閾値を超えた場合に異常であると判定してもよい。
　図１５は、仮想マシン識別子が１である仮想マシンにおいて発生した異常のグルーピングログの一例である。図１６は、仮想マシン識別子が２である仮想マシンにおいて発生した異常のグルーピングログの一例である。
　［監視サーバーにおける異常の表示例］
　図１７は、実施の形態における監視結果表示の一例を示す図である。
　監視結果表示は、セキュリティ分析官へ監視情報を伝達するために利用されてもよい。監視結果表示は、監視サーバー１０が車載システム２０から監視結果を受信することで監視サーバーにより生成されてもよい。監視結果表示は、監視結果がグラフィカルユーザーインターフェースにおいて表現された表示である。
　監視結果は、コマンドが正常であった場合には、コマンドに対応する仮想マシンを特定する識別子と、当該仮想マシンに対応するアプリの識別子と、正常判定した時刻とを含む。監視結果は、コマンドが異常であった場合には、コマンドに対応する仮想マシンを特定する識別子と、当該仮想マシンに対応するアプリの識別子と、異常判定した時刻とを含む。
　なお、図１７において、太枠のブロックは異常であると判定された監視対象のソフトウェアを示し、細枠のブロックは正常であると判定された監視対象のソフトウェアを示す。
　図１７において、統合ＥＣＵ２００の抽象化されたシステムアーキテクチャが表示されており、異常及び正常の一方（ここでは異常）の構成要素が強調されて区別できるように表現されており、構成要素の下部に対応する監視結果が表示されている。これにより、セキュリティ分析官は直感的に異常が発生した構成要素を理解することができるため、セキュリティ異常の解析を迅速に実施できる。
　図１７に示される車両識別子は車両ごとに付与されるユニークな識別子である。ＥＣＵ識別子はＥＣＵごとに付与される識別子である。この場合、異常が検出された車両の車両識別子と、仮想化プラットフォームが搭載されたＥＣＵの識別子とが表示される。異常なコマンドの送信元は、システムアーキテクチャが表示された画面の上に強調表示されてもよい。また、異常検出時刻と検出した監視プログラムの名称が表示されてもよい。異常検知時刻は、異常通知のログに含まれ、監視プログラムの名称は、異常通知のログに含まれる識別子から参照される。これにより、監視サーバーのＧＵＩを用いて異常を分析するセキュリティ分析官が、異常が発生している箇所の特定と異常の内容を容易に把握できる。
　［統合ＥＣＵにおける異常の表示例］
　図１８は、実施の形態における監視結果表示の一例を示す図である。
　図１８に示されるように、車両内のディスプレイ上に、異常な通信の送信元が制御するディスプレイの枠が強調表示されてもよい。これにより、ドライバが容易に異常と危険性を判断でき、車両を路肩に停止することができる。例えば、映像仮想マシンが異常な場合に、映像仮想マシンが制御するクラスターディスプレイと電子ミラーディスプレイとの外枠に赤枠を表示することで異常を通知してもよい。
　［効果など］
　本実施の形態に係る監視装置（統合ＥＣＵ２００）は、２以上の仮想マシンを動作させる仮想化プラットフォームにおける監視装置であって、監視装置は、２以上の仮想マシンのうち、プロセスが送信または受信するコマンドを監視する１以上の監視プログラムが動作する第１仮想マシンにて動作し、監視装置は、第１仮想マシンと異なる第２仮想マシンにて動作するプロセスが送信または受信するコマンドを受信するコマンド受信部ＶＭ４１１と、第２仮想マシンの構成情報を取得するシステム構成取得部ＶＭ４１８と、コマンドに含まれる識別子からコマンドの特性を参照し、構成情報及びコマンドの特性に応じて１以上の監視プログラムの実行方法を決定する監視プログラム制御部ＶＭ４１２と、監視プログラムの監視結果を取得して、監視結果に異常が含まれる場合に異常を通知する異常対応部ＶＭ４１５と、を備える。
　これによれば、第２仮想マシンの構成情報及びコマンドの特性に応じて１以上の監視プログラムの実行方法を決定するため、第２仮想マシンの特性及びコマンドの特性に応じた適切な監視処理を実行することができる。これにより、監視処理の処理負荷を調整でき、また、コマンドのリアルタイム性が考慮された監視処理を実現することができ、コマンドへの監視処理を効率よく効果的に実行することができる。
　通常、コマンドには送受信のＬ２　物理アドレスしか記載がないため、監視プログラム制御部では、アドレスの他の情報の取得はできない。統合ＥＣＵ２００において実現される複数の仮想マシンを監視する監視仮想マシンＶＭ４００は、仮想化環境上の監視プログラムであるため、監視対象の仮想マシンの構成情報とシステム状態とを取得できる。これらの情報によって、コマンドの送受信のアドレスから、どの仮想マシン（どのＯＳ）からの通信であるかを判定できる。さらに、仮想マシンの状態に応じて、処理を切り替えることができる。
　従来技術では、監視結果のログを全て蓄積するが、どの仮想マシンからのログであるか識別ができないため、インシデントレスポンスの際の分析に時間を要する。本実施の形態にかかる異常対応部ＶＭ４１５は、仮想マシンの構成情報を用いることで、異常ログを仮想マシンごとに蓄積することができる。このため、インシデントレスポンスの際の分析に要する時間を削減することができる。また、異常なコマンドの送信元からどの仮想マシンが異常かわかるため、該当仮想マシンでの異常表示、再起動、停止などの異常に対処するための処理を実行できる。
　例えば、監視装置（統合ＥＣＵ２００）は、さらに、第２仮想マシンのシステム状態を取得するシステム状態取得部ＶＭ４１７を備える。監視プログラム制御部ＶＭ４１２は、さらにシステム状態に応じて、１以上の監視プログラムの実行方法を決定する。
　これによれば、さらに、第２仮想マシンのシステム状態に応じて１以上の監視プログラムの実行方法を決定するため、第２仮想マシンの状態に応じた適切な監視処理を実行することができる。これにより、監視処理の処理負荷を調整でき、また、コマンドのリアルタイム性が考慮された監視処理を実現することができ、コマンドへの監視処理を効率よく効果的に実行することができる。
　例えば、コマンドの特性は、コマンドの送信元の仮想マシン、コマンドの送信先の仮想マシン、コマンドの送信方向、ファイルアクセス、送信元または送信先の仮想マシンのＯＳ（Operating System）種別、コマンドのＡＳＩＬ、監視装置を備える車両の走行状態、車両の走行モード、及び、システム状態の少なくとも１つである。このため、第２仮想マシンの特性及びコマンドの特性に応じた適切な監視処理を実行することができる。
　また、監視プログラムの実行方法は、監視プログラムが有効であるか否か、監視プログラムの呼び出し方法、監視プログラムに設定されているタイムアウト時間、及び、監視プログラムの実行順序の少なくとも１つである。これにより、監視処理の処理負荷を調整でき、また、コマンドのリアルタイム性が考慮された監視処理を実現することができる。
　また、異常対応部ＶＭ４１５は、さらに、コマンドの種別に応じてコマンドの異常を示すログを集約または集計することでグルーピングログを生成する。このため、集約または集計した異常を分析に利用することができる。
　また、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムのうちの簡易監視プログラムの監視結果に応じて、簡易監視プログラムよりも処理負荷が高い詳細監視プログラムを呼び出す。例えば、簡易監視プログラムで異常が検知された場合に詳細監視プログラムを実行することで、異常についてより詳細な結果が得られるように処理されてもよいし、簡易監視プログラムで異常が検知された場合に詳細監視プログラムの実行をスキップすることで処理負荷を低減し、異常の通知までに要する時間を削減してもよい。
　（変形例）
　［統合ＥＣＵの構成の詳細］
　図１９は、変形例における統合ＥＣＵ２００の一部の構成を詳細に示すブロック図である。
　実施の形態と比較して監視仮想マシンＶＭ５００の構成が異なるため、監視仮想マシンＶＭ５００について説明する。
　監視仮想マシンＶＭ５００は、第１コマンド受信部ＶＭ５０１、第１監視プログラム制御部ＶＭ５０２、第１コマンド送信部ＶＭ５０３、第２コマンド受信部ＶＭ５１１、第２監視プログラム制御部ＶＭ５１２、第２コマンド送信部ＶＭ５１３、簡易監視プログラムＶＭ４１３、詳細監視プログラムＶＭ４１４、異常対応部ＶＭ４１５、システム状態取得部ＶＭ４１７、及び、システム構成取得部ＶＭ４１８を備える。簡易監視プログラムＶＭ４１３、詳細監視プログラムＶＭ４１４、異常対応部ＶＭ４１５、システム状態取得部ＶＭ４１７、及び、システム構成取得部ＶＭ４１８の構成は、実施の形態の監視仮想マシンＶＭ４００が備える構成と同様であるため、同じ符号を付し説明を省略する。
　監視仮想マシンＶＭ５００は、２つのコマンド受信部と、２つの監視プログラム制御部と、２つのコマンド送信部とを有する点が実施の形態の監視仮想マシンＶＭ４００と異なる。つまり、監視仮想マシンＶＭ５００は、コマンド受信部、監視プログラム制御部、及び、コマンド送信部を２組有する点が監視仮想マシンＶＭ４００と異なる。コマンド受信部、監視プログラム制御部、及び、コマンド送信部を２組有するため、２組に監視処理の役割分担をさせることでコマンドが遅延することを抑制できる。
　第１コマンド受信部ＶＭ５０１、第１監視プログラム制御部ＶＭ５０２、及び、第１コマンド送信部ＶＭ５０３は、映像仮想マシンＶＭ３００用の処理を実行する。つまり、第１コマンド受信部ＶＭ５０１、第１監視プログラム制御部ＶＭ５０２、及び、第１コマンド送信部ＶＭ５０３は、映像仮想マシンＶＭ３００のプロセスで送信または受信されるコマンドに対する処理を実行する。第１コマンド受信部ＶＭ５０１、第１監視プログラム制御部ＶＭ５０２、及び、第１コマンド送信部ＶＭ５０３は、それぞれ、実施の形態のコマンド受信部ＶＭ４１１、監視プログラム制御部ＶＭ４１２、及び、コマンド送信部ＶＭ４１６と同様の機能を有する。
　第２コマンド受信部ＶＭ５１１、第２監視プログラム制御部ＶＭ５１２、及び、第２コマンド送信部ＶＭ５１３は、外部仮想マシンＶＭ１００用の処理を実行する。つまり、第２コマンド受信部ＶＭ５１１、第２監視プログラム制御部ＶＭ５１２、及び、第２コマンド送信部ＶＭ５１３は、外部仮想マシンＶＭ１００のプロセスで送信または受信されるコマンドに対する処理を実行する。第２コマンド受信部ＶＭ５１１、第２監視プログラム制御部ＶＭ５１２、及び、第２コマンド送信部ＶＭ５１３は、それぞれ、実施の形態のコマンド受信部ＶＭ４１１、監視プログラム制御部ＶＭ４１２、及び、コマンド送信部ＶＭ４１６と同様の機能を有する。
　映像仮想マシンＶＭ３００から外部仮想マシンＶＭ１００への仮想マシン間の内部通信である場合に、映像仮想マシンＶＭ３００からの送信時の監視プログラムの設定に基づいて、第１監視プログラム制御部ＶＭ５０２によって簡易監視プログラムと詳細監視プログラムが実行されてもよい。また、外部仮想マシンＶＭ１００の受信時の監視プログラム設定に基づいて、第１監視プログラム制御部ＶＭ５０２によって簡易監視プログラムと詳細監視プログラムが実行されてもよい。
　この場合、同じコマンドに対して、同じ監視プログラムを実行することは非効率であるため、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２のうちの一方の監視プログラム制御部で監視処理を実行したり、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２の両方で処理を分担したりする。処理の分担は分担テーブルを用いて決定され、簡易監視プログラムはコマンドの送信側の仮想マシンに対応する監視プログラム制御部において実行され、詳細監視プログラムはコマンドの受信側の仮想マシンに対応する監視プログラム制御部において実行されるように分担処理することで、遅延を抑えられる。
　［監視仮想マシンの処理シーケンス］
　図２０は、変形例における監視仮想マシンの処理シーケンスの一例を示す図である。
　図２０に示すように、第１コマンド受信部ＶＭ５０１または第２コマンド受信部ＶＭ５１１は、監視仮想マシンＶＭ５００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどからコマンドを受信し、受信したコマンドを識別する（Ｓ１０１）。これにより、システム構成取得部ＶＭ４１８は、コマンドに含まれる識別子に基づいて、コマンドを送信した仮想マシン、または、コマンドを受信した仮想マシンの構成情報を取得する。また、システム状態取得部ＶＭ４１７は、コマンドに含まれる識別子に基づいて、コマンドを送信した仮想マシン、または、コマンドを受信した仮想マシンのシステム状態を取得してもよい。ステップＳ１０１により得られた、コマンドの識別子、仮想マシンの構成情報、及び、仮想マシンのシステム状態は、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２へ通知される。
　次に、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２は、コマンドの識別子からコマンドの特性を参照し、通知された構成情報及びシステム状態と、コマンドの特性とに応じて、監視プログラムの分担を決定する（Ｓ２１１）。第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２は、例えば、システム負荷の低いインタフェース側で、監視処理を実行するように監視処理を分担することで、負荷を軽減できる。
　次に、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２は、１以上の監視プログラムのうち実行すると決定された簡易監視プログラムＶＭ４１３の呼び出しを行う（Ｓ１０６）。そして、簡易監視プログラムＶＭ４１３による監視処理が実行される（Ｓ１０７）。
　次に、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２は、１以上の監視プログラムのうち実行すると決定された詳細監視プログラムＶＭ４１４の呼び出しを行う（Ｓ１０８）。そして、詳細監視プログラムＶＭ４１４による監視処理が実行される（Ｓ１０９）。
　次に、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２は、対応アプリの呼び出しを行う（Ｓ１１０）。これにより、異常対応部ＶＭ４１５は、異常対応処理を実行する（Ｓ１１１）。異常対応処理では、監視処理の監視結果に応じて、コマンドのロギング、コマンドのドロップ、仮想マシンの再起動、システムの再起動などが実行される。なお、ステップＳ１１１の詳細は後述する。
　次に、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２は、受信したコマンドを指定の宛先の仮想マシン、外部ＥＣＵ、外部デバイスなどに送信するために、第１コマンド送信部ＶＭ５０３または第２コマンド送信部ＶＭ５１３へ送信する（Ｓ１１２）。第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２は、例えば、監視処理において正常と判定されたコマンドを指定の宛先の仮想マシン、外部ＥＣＵ、外部デバイスなどに送信するために、送信先に対応するコマンド送信部へ送信する。第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２は、例えば、監視処理において以上と判定されたコマンドを指定の宛先の仮想マシン、外部ＥＣＵ、外部デバイスなどに送信するために、送信先に対応するコマンド送信部へ送信しなくてもよい。そして、送信先に対応するコマンド送信部は、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２から受信したコマンドを指定の宛先の仮想マシン、外部ＥＣＵ、外部デバイスなどに送信する（Ｓ１１３）。
　なお、上記では、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２がステップＳ２１１、Ｓ１０６、Ｓ１０８、Ｓ１１０、及びＳ１１２の処理を行うとしたが、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２の少なくとも一方においてこれらの処理が行われればよい。
　［監視プログラムの分担］
　図２１は、変形例における監視プログラムの分担処理（Ｓ２１１）のフローチャートの一例を示す図である。
　図２１に示すように、第１監視プログラム制御部ＶＭ５０２または第２監視プログラム制御部ＶＭ５１２は、第１コマンド受信部ＶＭ５０１または第２コマンド受信部ＶＭ５１１において受信されたコマンドを取得する（Ｓ２２１）。
　次に、第１監視プログラム制御部ＶＭ５０２または第２監視プログラム制御部ＶＭ５１２は、取得したコマンドに基づいて、仮想マシン間の内部通信であるか否かを判定する（Ｓ２２２）。つまり第１監視プログラム制御部ＶＭ５０２または第２監視プログラム制御部ＶＭ５１２は、取得したコマンドの送信元及び送信先の両方が仮想マシンであるか否かを判定する。
　第１監視プログラム制御部ＶＭ５０２または第２監視プログラム制御部ＶＭ５１２は、仮想マシン間の内部通信であると判定した場合（Ｓ２２２でＹｅｓ）、ステップＳ２２３を実行し、仮想マシン間の内部通信でないと判定した場合（Ｓ２２２でＮｏ）、監視プログラムの分担処理を終了する。
　ステップＳ２２３において、第１監視プログラム制御部ＶＭ５０２または第２監視プログラム制御部ＶＭ５１２は、仮想コマンドの負荷に応じて分担の決定テーブルを参照し、分担識別子を付与する。
　次に、第１監視プログラム制御部ＶＭ５０２または第２監視プログラム制御部ＶＭ５１２は、分担識別子に従って決定した監視プログラムを実行する（Ｓ２２４）。
　［分担の決定テーブル］
　図２２は、変形例における分担の決定テーブルの一例を示す図である。
　図２２に示すように、分担の決定テーブルは、分担識別子と、条件と、簡易監視プログラムを実行する監視プログラム制御部と、詳細監視プログラムを実行する監視プログラム制御部と、異常対応部とを含む。分担識別子は、４つの分担方法を特定する識別子である。条件は、仮想コマンド負荷に基づいて４つの分担方法のうちの１つを決定するための条件である。例えば、送信側の仮想コマンド負荷が閾値１より低い場合、簡易監視プログラムは第１監視プログラム制御部ＶＭ５０２により実行され、詳細監視プログラムは第１監視プログラム制御部ＶＭ５０２により実行され、異常対応処理は第１監視プログラム制御部ＶＭ５０２により実行される。また、例えば、送信側の仮想コマンド負荷が閾値１以上閾値２より低い場合、簡易監視プログラムは第１監視プログラム制御部ＶＭ５０２により実行され、詳細監視プログラムは第１監視プログラム制御部ＶＭ５０２により実行され、異常対応処理は第２監視プログラム制御部ＶＭ５１２により実行される。また、例えば、送信側の仮想コマンド負荷が閾値２以上閾値３より低い場合、簡易監視プログラムは第１監視プログラム制御部ＶＭ５０２により実行され、詳細監視プログラムは第２監視プログラム制御部ＶＭ５１２により実行され、異常対応処理は第２監視プログラム制御部ＶＭ５１２により実行される。また、例えば、送信側の仮想コマンド負荷が閾値３以上である場合、簡易監視プログラムは第２監視プログラム制御部ＶＭ５１２により実行され、詳細監視プログラムは第２監視プログラム制御部ＶＭ５１２により実行され、異常対応処理は第２監視プログラム制御部ＶＭ５１２により実行される。
　なお、図２２では仮想コマンド負荷に応じて分担方法を特定する方法を示したが、仮想コマンドの通信方向または送信先、送信元に応じて分担方法を特定してもよい。例えば、仮想コマンドを受信する第１監視プログラム制御部ＶＭ５０２にて簡易監視プログラムと詳細監視プログラムを実行し、仮想コマンドを送信する第２監視プログラム制御部ＶＭ５１２にて、異常対応処理を実行する。この場合、仮想コマンド負荷を参照することなく分担方法を決定できる。
　また、第１監視プログラム制御部ＶＭ５０２にて仮想コマンドに分担識別子を付与することで、第２監視プログラム制御部ＶＭ５１２が仮想コマンドに付与された分担識別子を参照して分担方法を特定してもよい。この場合、第１監視プログラム制御部ＶＭ５０２が分担方法を任意に決定できる。なお、仮想コマンドに分担識別子を付与する方法以外にも第１監視プログラム制御部ＶＭ５０２と第２監視プログラム制御部ＶＭ５１２との間のデータ通信やデータ共有によって監視プログラムの分担方法を特定してもよく、監視プログラム間のデータ通信やデータ共有によって監視プログラムの分担方法を特定してもよい。この場合、仮想コマンドの特性と監視プログラムの特性とに応じて動的に分担方法を決定できる。
　また、監視プログラムが複数の監視ルールを保持する場合、第１監視プログラム制御部ＶＭ５０２が実行する監視プログラムに第１のルールを適用し、第２監視プログラム制御部ＶＭ５１２が実行する監視プログラムが第２のルールを適用するという分担を実施してもよい。この場合、監視プログラムが一つであっても処理を分担できる。
　［効果など］
　変形例に係る監視装置（統合ＥＣＵ２００）は、２以上の監視プログラム制御部（例えば、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２）を備え、コマンドに対する１以上の監視プログラムは、コマンドの送信先が仮想化プラットフォーム上の仮想マシンであると判定された場合に、２以上の監視プログラム制御部のうち、コマンドに含まれる識別子及び構成情報に基づいて決定された１以上の監視プログラム制御部によって実行方法が決定される。
　例えば、２以上の監視プログラム制御部は、システム状態に応じて１以上の監視プログラムの実行方法を決定する。
　例えば、２以上の監視プログラム制御部のうち、第１監視プログラム制御部は、コマンドに第１識別子を付与し、第２監視プログラム制御部は、コマンドに第１識別子が付与されているか否かに応じて、１以上の監視プログラムの実行方法を決定する。
　このため、コマンドに含まれる識別子及び構成情報に基づいて、監視処理を２以上の監視プログラム制御部で分担することができる。よって、遅延を抑えることができる。
　以上、本開示の監視装置について、上記実施の形態およびその変形例に基づいて説明したが、本開示は、その実施の形態および変形例に限定されるものではない。本開示の趣旨を逸脱しない限り、当業者が思いつく各種変形を上記実施の形態および変形例に施したものも本開示に含まれてもよい。
　なお、上記実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵ（Central Processing Unit）またはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記各実施の形態の監視装置などを実現するソフトウェアは、図８～図１４、図２０及び図２１のそれぞれに示すフローチャートまたはシーケンス図の各ステップをコンピュータに実行させるコンピュータプログラムである。
　なお、以下のような場合も本開示に含まれる。
　（１）上記の少なくとも１つの装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。そのＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、上記の少なくとも１つの装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
　（２）上記の少なくとも１つの装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
　（３）上記の少なくとも１つの装置を構成する構成要素の一部または全部は、その装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。ＩＣカードまたはモジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。ＩＣカードまたはモジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ＩＣカードまたはモジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
　（４）本開示は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、コンピュータプログラムからなるデジタル信号であるとしてもよい。
　また、本開示は、コンピュータプログラムまたはデジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ（Compact Disc）－ＲＯＭ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されているデジタル信号であるとしてもよい。
　また、本開示は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
　また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
　本開示の監視装置は、例えば車両に搭載された電子機器などに適用することができる。
　１０　　監視サーバー
　２０　　車載システム
　３０　　外部ネットワーク
　４０、４１　　ＣＡＮ
　５０、５１　　イーサネット
２００　　統合ＥＣＵ
３００　　ゲートウェイＥＣＵ
４００ａ　ステアリングＥＣＵ
４００ｂ　ブレーキＥＣＵ
５００　　ＺｏｎｅＥＣＵ
６００ａ　フロントカメラＥＣＵ
６００ｂ　リアカメラＥＣＵ
Ａ１００　外部アプリ
Ａ２００　制御アプリ
Ａ３００　映像アプリ
Ａ４００　監視アプリ
ＶＭ１００　外部仮想マシン
ＶＭ１０１、ＶＭ２０１、ＶＭ３０１　コマンド送受信部
ＶＭ２００　制御仮想マシン
ＶＭ３００　映像仮想マシン
ＶＭ４００、ＶＭ５００　監視仮想マシン
ＶＭ４１１　コマンド受信部
ＶＭ４１２　監視プログラム制御部
ＶＭ４１３　簡易監視プログラム
ＶＭ４１４　詳細監視プログラム
ＶＭ４１５　異常対応部
ＶＭ４１６　コマンド送信部
ＶＭ４１７　システム状態取得部
ＶＭ４１８　システム構成取得部
ＶＭ５０１　第１コマンド受信部
ＶＭ５０２　第１監視プログラム制御部
ＶＭ５０３　第１コマンド送信部
ＶＭ５１１　第２コマンド受信部
ＶＭ５１２　第２監視プログラム制御部
ＶＭ５１３　第２コマンド送信部
ＶＰ１００　仮想化プラットフォーム
ＶＰ１０１　物理インタフェース

Claims (11)

  1. 　２以上の仮想マシンを動作させる仮想化プラットフォームにおける監視装置であって、
    　前記監視装置は、前記２以上の仮想マシンのうち、プロセスが送信または受信するコマンドを監視する１以上の監視プログラムが動作する第１仮想マシンにて動作し、
    　前記監視装置は、
    　前記第１仮想マシンと異なる第２仮想マシンにて動作するプロセスが送信または受信するコマンドを受信するコマンド受信部と、
    　前記第２仮想マシンの構成情報を取得する構成情報取得部と、
    　前記コマンドに含まれる識別子から前記コマンドの特性を参照し、前記構成情報及び前記コマンドの特性に応じて前記１以上の監視プログラムの実行方法を決定する監視プログラム制御部と、
    　前記監視プログラムの監視結果を取得して、前記監視結果に異常が含まれる場合に前記異常を通知する異常対応部と、を備える、
    　監視装置。
  2. 　さらに、
    　前記第２仮想マシンのシステム状態を取得するシステム状態取得部を備え、
    　前記監視プログラム制御部は、さらに前記システム状態に応じて、前記１以上の監視プログラムの実行方法を決定する
    　請求項１に記載の監視装置。
  3. 　前記コマンドの特性は、前記コマンドの送信元または送信先の仮想マシン、前記コマンドの送信元または送信先の電子制御装置、前記コマンドの送信方向、前記コマンドに含まれるファイル操作のアクセス先、前記コマンドに含まれるファイル操作の種類、前記送信元または前記送信先の仮想マシンのＯＳ（Operating System）種別、前記送信元または前記送信先の仮想マシンの外部接続機能の有無、前記コマンドのＡＳＩＬ、及び、前記コマンドの車両制御への影響の少なくとも１つである
    　請求項１に記載の監視装置。
  4. 　前記システム状態は、前記監視装置を備える車両の走行状態、前記車両の走行モード、前記仮想マシンのシステム負荷、前記コマンドの処理におけるシステム負荷、前記仮想マシンのネットワーク接続状態、前記仮想マシン内のセキュリティ異常の有無、及び、仮想コマンドのセキュリティ異常の有無の少なくとも１つである
    　請求項２に記載の監視装置。
  5. 　前記監視プログラムの実行方法は、前記監視プログラムが有効であるか否か、前記監視プログラムの呼び出し方法、前記監視プログラムに設定されているタイムアウト時間、及び、前記監視プログラムの実行順序の少なくとも１つである
    　請求項１から４のいずれか１項記載の監視装置。
  6. 　前記異常対応部は、さらに、前記コマンドの特性に応じて前記コマンドの異常を示すログを集約または集計する
    　請求項１から５のいずれか１項に記載の監視装置。
  7. 　前記監視プログラム制御部は、前記１以上の監視プログラムのうちの簡易監視プログラムの監視結果に応じて、前記簡易監視プログラムよりも処理負荷が高い詳細監視プログラムを呼び出す
    　請求項１から６のいずれか１項に記載の監視装置。
  8. 　さらに、
    　２以上の前記監視プログラム制御部を備え、
    　前記コマンドに対する前記１以上の監視プログラムは、前記コマンドの送信先が前記仮想化プラットフォーム上の仮想マシンであると判定された場合に、前記２以上の監視プログラム制御部のうち、前記コマンドに含まれる識別子及び前記構成情報に基づいて決定された１以上の監視プログラム制御部によって実行方法が決定される
    　請求項１から７のいずれか１項に記載の監視装置。
  9. 　前記２以上の前記監視プログラム制御部は、前記第２仮想マシンのシステム状態に応じて前記１以上の監視プログラムの実行方法を決定する
    　請求項８に記載の監視装置。
  10. 　前記２以上の前記監視プログラム制御部のうち、第１監視プログラム制御部は、前記コマンドに第１識別子を付与し、第２監視プログラム制御部は、前記コマンドに第１識別子が付与されているか否かに応じて、前記１以上の監視プログラムの実行方法を決定する
    　請求項８または９に記載の監視装置。
  11. 　２以上の仮想マシンを動作させる仮想化プラットフォームにおける監視装置による監視方法であって、
    　前記監視装置は、前記２以上の仮想マシンのうち、プロセスが送信または受信するコマンドを監視する１以上の監視プログラムが動作する一の仮想マシンにて動作し、
    　前記監視方法は、
    　前記一の仮想マシンと異なる仮想マシンにて動作するプロセスが送信または受信するコマンドを取得し、
    　前記仮想マシンの構成情報を取得し、
    　前記コマンドに含まれる識別子から前記コマンドの特性を参照し、前記１以上の監視プログラムの実行方法を決定し、
    　前記監視プログラムの監視結果を取得して、異常を通知する
    　監視方法。
PCT/JP2023/004470 2022-06-10 2023-02-09 監視装置及び監視方法 WO2023238444A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023573307A JP7426640B1 (ja) 2022-06-10 2023-02-09 監視装置及び監視方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022094337 2022-06-10
JP2022-094337 2022-06-10

Publications (1)

Publication Number Publication Date
WO2023238444A1 true WO2023238444A1 (ja) 2023-12-14

Family

ID=89117917

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/004470 WO2023238444A1 (ja) 2022-06-10 2023-02-09 監視装置及び監視方法

Country Status (2)

Country Link
JP (1) JP7426640B1 (ja)
WO (1) WO2023238444A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100125667A1 (en) * 2008-11-19 2010-05-20 Vmware, Inc. Dynamic configuration of virtual machines
JP2013175075A (ja) * 2012-02-27 2013-09-05 Fujitsu Ltd データ収集方法、情報処理システムおよびプログラム
JP2021090160A (ja) * 2019-12-05 2021-06-10 パナソニックＩｐマネジメント株式会社 情報処理装置、異常検知方法およびコンピュータプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100125667A1 (en) * 2008-11-19 2010-05-20 Vmware, Inc. Dynamic configuration of virtual machines
JP2013175075A (ja) * 2012-02-27 2013-09-05 Fujitsu Ltd データ収集方法、情報処理システムおよびプログラム
JP2021090160A (ja) * 2019-12-05 2021-06-10 パナソニックＩｐマネジメント株式会社 情報処理装置、異常検知方法およびコンピュータプログラム

Also Published As

Publication number Publication date
JP7426640B1 (ja) 2024-02-02
JPWO2023238444A1 (ja) 2023-12-14

Similar Documents

Publication Publication Date Title
US11599349B2 (en) Gateway device, in-vehicle network system, and firmware update method
US20230060267A1 (en) Detecting anomalies online using controller processing activity
CN105981336B (zh) 不正常检测电子控制单元、车载网络系统以及不正常检测方法
US11165851B2 (en) System and method for providing security to a communication network
US11842185B2 (en) Gateway device, in-vehicle network system, and firmware update method
CN105892444B (zh) 通过虚拟机自省进行安全事件检测
US10380057B2 (en) Data storage device
US11785023B2 (en) Vehicle abnormality detection device and vehicle abnormality detection method
US20220291944A1 (en) Information processing device, anomaly detection method, and computer-readable recording medium
JP7241281B2 (ja) 情報処理装置、制御方法及びプログラム
US8875278B2 (en) Dynamic allocation of network security credentials for alert notification recipients
JP7426640B1 (ja) 監視装置及び監視方法
US10992677B2 (en) Reputation-based device registry
WO2023100168A1 (en) Detection and mitigation of cyber attacks on aimed at vehicle's diagnostic sessions
WO2024070044A1 (ja) 検証システム、検証方法、及び、プログラム
WO2022254520A1 (ja) インテグリティ検証装置およびインテグリティ検証方法
JP2007028037A (ja) 故障検知診断対処装置、故障検知診断対処システムおよび故障検知診断対処方法
WO2023233711A1 (ja) 情報処理方法、異常判定方法、および、情報処理装置
WO2021241415A1 (ja) 異常検知システム及び異常検知方法
US20240067193A1 (en) Vehicle control using serverless functions
WO2023238438A1 (ja) 監視装置および監視方法
CN112204926B (zh) 数据通信控制装置、非易失性存储器以及车辆控制系统
WO2024100930A1 (ja) 情報提供方法及び情報処理装置
WO2021247150A1 (en) Bi-directional interpositioning of virtual hardware

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23819432

Country of ref document: EP

Kind code of ref document: A1