Electronic control device and abnormality determination method

Abstract

To detect an abnormality occurred in a hypervisor based on an input and an output of the hypervisor whose internal logic is not disclosed.SOLUTION: An electronic control apparatus includes: a virtual machine that accesses a first virtual driver and performs processing; a hypervisor that calls a first real driver of a first peripheral based on a peripheral access request received from the first virtual driver; an access recording unit that calls the first virtual driver and records the peripheral access request transmitted to the hypervisor; status recording unit that calls the first real driver and records a status of a register of the first peripheral; and a monitor unit that monitors an operation of the hypervisor. The monitor unit determines an abnormality of the hypervisor based on a record in the access recording unit and a record in the status recording unit.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to an electronic control device. [Background technology]

[0002] By using a hypervisor, multiple control software applications that run on different OSs (Operating Systems) can be mounted on a single microcomputer. Technologies for monitoring a hypervisor include those described in JP 2019-144785 (Patent Document 1) and JP 2014-106587 (Patent Document 2). Patent Document 1 describes a monitoring program that places a monitoring virtual machine used to monitor multiple monitoring targets including virtualization software on virtualization software, acquires the results of a predetermined test executed by the monitoring virtual machine at a predetermined interval, determines whether or not the monitoring virtual machine is abnormal from the acquired test results, acquires the predetermined states of the multiple monitoring targets if the monitoring virtual machine is abnormal, and outputs the determination result of whether or not the monitoring virtual machine is abnormal and the predetermined states of the multiple monitoring targets (see abstract).

[0003] Patent Document 2 also describes a method for a hypervisor and a first guest OS to share an I / O device, the I / O device having a physical function and a virtual function, the hypervisor having a physical driver that uses the physical function, and the first guest OS having a virtual driver that uses the virtual function, the hypervisor acquiring the status of the I / O device via the physical driver, the first guest OS monitoring the hypervisor and, when a predetermined state is reached, starting a sub-physical driver that operates the I / O device, and the first guest OS performing transmission and reception via a queue preset in memory. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP2019-144785A [Patent Document 2] JP2014-106587A Summary of the Invention [Problem to be solved by the invention]

[0005] In electronic control devices that integrate multiple control software applications that run on different operating systems into one microcomputer (hardware), virtualization software called a hypervisor is used. The hypervisor provides a virtual machine as an environment for operating the operating system and the control software applications. A virtual machine is a unit that sets access rights to the CPU (Central Processing Unit), memory area, and peripherals such as a CAN (Controller Area Network) controller and an A / D (Analog / Digital) converter mounted on a microcomputer. From the perspective of the guest OS and control software applications in each virtual machine, it is logically equivalent to a CPU, memory area, and peripherals that are not granted access rights existing on another microcomputer. In general, in order to ensure the safety and reliability of an electronic control device, it is required to monitor whether the hardware and software that constitute the electronic control device are operating normally and no abnormalities are occurring during the operation of the electronic control device. In particular, in electronic control devices that use a hypervisor, it is required to monitor the operation of the hypervisor.

[0006] According to Patent Document 1, a monitoring virtual machine is installed as a virtual machine, and the monitoring virtual machine periodically executes a test pattern and acquires the internal state (normal / abnormal) of the hypervisor. Based on the execution result of the test pattern and the acquired result of the internal state of the hypervisor, it is possible to determine whether an abnormality has occurred in the electronic control device and, if an abnormality has occurred, to identify the extent of the effect of the abnormality. However, since the hypervisor monitoring in Patent Document 1 is performed by acquiring the normal or abnormal state determined by the hypervisor itself, it does not take into consideration the case where the abnormal state is not appropriately determined by the hypervisor due to an abnormality occurring in the hypervisor, and normal operation of the hypervisor is not guaranteed. In addition, since it is necessary to acquire the internal state of the hypervisor, it cannot be applied to a third-party hypervisor whose internal state is not disclosed.

[0007] Patent Document 2 describes a method in which a counter (watchdog timer) is provided for a hypervisor, a requirement is imposed that the counter counts up or down within a predetermined period, and if the counter is not updated within the predetermined period, it is determined that an abnormality has occurred in the hypervisor. This makes it possible to detect an unexpected stop of the hypervisor, or a deadlock or livelock that has occurred in the hypervisor. However, in order to apply this method, it is necessary to impose a requirement on the counter update on the hypervisor. In addition, since the count update process of the watchdog timer is generally set to a high priority, if the priority of the counter update process within the hypervisor is higher than the processing priority of the task that is causing the deadlock or livelock, the deadlock or livelock cannot be detected.

[0008] Therefore, the present invention aims to monitor a hypervisor and detect abnormalities that occur in the hypervisor based only on the input and output of the hypervisor, whose internal logic is not made public, such as a hypervisor made by a third party. [Means for solving the problem]

[0009] A representative example of the invention disclosed in the present application is as follows: That is, an electronic control device includes a virtual machine that accesses a first virtual driver to execute processing, a hypervisor that calls a first real driver of a first peripheral based on a peripheral access request received from the first virtual driver, an access recording unit that calls the first virtual driver and records the peripheral access request transmitted to the hypervisor, a status recording unit that calls the first real driver and records the status of a register of the first peripheral, and a monitoring unit that monitors the operation of the hypervisor, and the monitoring unit judges an abnormality of the hypervisor based on the records of the access recording unit and the records of the status recording unit. Effect of the Invention

[0010] According to one aspect of the present invention, it is possible to detect an abnormality in a hypervisor without accessing the internal state of the hypervisor. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief description of the drawings]

[0011] [Figure 1] FIG. 2 is a diagram illustrating a hardware configuration of an electronic control device according to the first embodiment. [Diagram 2] FIG. 2 is a diagram illustrating a software configuration of the electronic control device of the first embodiment. [Diagram 3] 11 is a diagram illustrating an overview of a process flow when a first control software application of the first embodiment uses a first peripheral. [Figure 4] FIG. 11 is a diagram showing an overview of a process flow when a first control software application of the first embodiment uses a shared peripheral. [Diagram 5] FIG. 13 is a diagram illustrating an example of peripheral access request information according to the first embodiment. [Figure 6] FIG. 13 is a diagram illustrating an example of peripheral access result information according to the first embodiment. [Figure 7]FIG. 11 is a diagram showing an overview of a process flow when the second control software application of the first embodiment uses the second peripheral. [Figure 8] FIG. 11 is a diagram showing an overview of a process flow when the second control software application of the first embodiment uses a shared peripheral. [Figure 9] FIG. 13 is a diagram illustrating an example of peripheral access record information according to the first embodiment. [Figure 10] FIG. 13 is a diagram illustrating an example of peripheral state record information according to the first embodiment. [Figure 11] 13 is a diagram illustrating an outline of a processing flow of a hypervisor monitoring program according to the first embodiment. [Figure 12] FIG. 13 is a diagram illustrating an example of peripheral desired state information according to the first embodiment. [Figure 13] 13 is a diagram illustrating a process of generating peripheral desired state information in step S1 of the hypervisor monitoring program of the first embodiment. FIG. [Figure 14] 13 is a diagram illustrating a process of generating peripheral desired state information in step S1 of the hypervisor monitoring program of the first embodiment. FIG. [Figure 15] FIG. 11 is a diagram illustrating a software configuration of an electronic control device according to a second embodiment. [Figure 16] FIG. 11 is a diagram illustrating an outline of a processing flow of a hypervisor monitoring program according to the second embodiment. [Figure 17] FIG. 13 is a diagram illustrating a hardware configuration of an electronic control device according to a third embodiment. [Figure 18] FIG. 13 is a diagram illustrating a software configuration of an electronic control device according to a third embodiment. [Figure 19] FIG. 13 is a diagram showing an overview of a process flow when a first control software application of the third embodiment uses a CAN controller that is a shared peripheral. [Figure 20] FIG. 13 is a diagram illustrating a CAN ledger according to the third embodiment. [Figure 21] FIG. 13 is a diagram illustrating an outline of a process flow of a monitoring result storage program according to the fourth embodiment. [Figure 22] FIG. 23 is a diagram illustrating an example of hypervisor abnormality occurrence time information according to the fourth embodiment. [Figure 23] FIG. 13 is a diagram illustrating an outline of the process in step S7 of the monitoring result storage program according to the fourth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] This embodiment relates to an electronic control device, and more particularly to an electronic control device in which a plurality of control software applications are integrated on one microcomputer.

[0013] An example of a preferred embodiment (Example) of the present invention will be described below. For the sake of explanation, in this Example, an example in which two control software applications, a first control software application and a second control software application, are integrated into one electronic control device will be described, but the present invention is not limited to this, and a third control software application and a fourth control software application may also be integrated into one electronic control device. EXAMPLES

[0014] <Configuration> FIG. 1 is a diagram illustrating a hardware configuration of an electronic control device according to a first embodiment.

[0015] <Electronic Control Unit 0> The electronic control device of this embodiment will be described with reference to Fig. 1. The electronic control device 0 has a microcomputer 900 and a power supply circuit 901. The microcomputer 900 is composed of a CPU (Central Processing Unit) 1 that performs arithmetic processing, peripherals 2 which are a group of peripheral devices mounted on the electronic control device 0, a memory 3 that stores software, and a bus 4 that connects the CPU 1, the peripherals 2, and the memory 3 and enables access from the CPU 1 to the peripherals 2 and the memory 3.

[0016] A power input terminal of the microcomputer 900 is connected to a power supply circuit 901. The microcomputer 900 starts up when it receives power supply from the power supply circuit 901. The microcomputer 900 has a self-reset signal output terminal. When the microcomputer 900 outputs a digital signal from the self-reset signal output terminal, the power supply circuit 901 stops the power supply to the microcomputer 900.

[0017] <cpu1> The CPU 1 has two cores, a first CPU core 101 and a second CPU core 102. For the sake of explanation, the number of CPU cores is two, but this is not limiting, and the number may be, for example, one or three or more.

[0018] <Peripheral 2> The peripherals 2 are devices that input and output data and signals to and from the inside or outside of the microcomputer 900, and include a shared peripheral 201 accessed by both the first control software application 10 (i.e., the first CPU core 101) and the second control software application 15 (i.e., the second CPU core 102), a first peripheral 202 accessed only by the first control software application 10 (i.e., the first CPU core 101), and a second peripheral 203 accessed only by the second control software application 15 (i.e., the second CPU core 103). The peripherals 2 are a general name for peripheral circuits other than the CPU 1 and memory 3 mounted on the microcomputer 900, and specifically include a CAN (Controller Area Network) controller, an analog-digital converter, a direct memory access controller, a GPIO (General Purpose Input / Output), and the like mounted on the microcomputer 900.

[0019] <Memory 3> The memory 3 includes a ROM, which is a non-volatile storage element, and a RAM, which is a volatile storage element. The ROM stores unchanging programs (e.g., BIOS) and the like. The RAM is a high-speed, volatile storage element such as a DRAM (Dynamic Random Access Memory), and stores programs executed by the CPU 1 and data used when the programs are executed.

[0020] For simplicity, in this embodiment, it is assumed that the shared peripheral 201 includes a digital output port 2011 , the first peripheral 202 includes an analog output port 2021 , and the second peripheral 203 includes a digital input port 2031 .

[0021] 2 is a diagram showing the software configuration of the electronic control unit of the first embodiment. The software shown in FIG.

[0022] <Software configuration> The following process is executed by either the first CPU core 101 or the second CPU core 102 of the CPU1.

[0023] A host OS (Operating System) 5 is mounted on the microcomputer 900. The host OS 5 starts a hypervisor 6, a hypervisor monitoring program 17, and a register value acquisition program 18. The hypervisor 6 is started according to a start-up method determined by the hypervisor 6. The hypervisor monitoring program 17 and the register value acquisition program 18 start at a 5 millisecond cycle and acquire information for monitoring. For simplicity, the start-up cycle is set to 5 milliseconds in this embodiment, but this is not limiting and start-up may be performed at other timings. The hypervisor 6 may be configured as software executed on the host OS 5, or may be configured as hardware implemented in the microcomputer 900.

[0024] The hypervisor 6 configures a first virtual machine 7 and a second virtual machine 8 and starts them up by a method determined by the hypervisor 6. For simplicity, the number of virtual machines is set to two in this embodiment, but the number is not limited to this and may be one or three or more.

[0025] In the first virtual machine 7, a first guest OS 9, a first control software application 10, a virtual driver 11, a peripheral access request recording program 19, and an analog output port driver 12 are executed. In the second virtual machine 8, a second guest OS 13, a second control software application 15, a virtual driver 11, and a digital input port driver 14 are executed. The peripheral access request recording program 19 is executed on the first virtual machine 7, but may be executed on the second virtual machine 8. In other words, it is sufficient that at least one peripheral access request recording program 19 is executed on the hypervisor 6.

[0026] <First Virtual Machine 7> The operation of the software in the first virtual machine 7 will be described. When the hypervisor 6 configures the first virtual machine 7, the first virtual machine 7 starts a first guest OS 9. The first guest OS 9 starts a first control software application 10. The first control software application 10 uses a digital output port 2011 which is a shared peripheral 201 and an analog output port 2021 which is a first peripheral 202.

[0027] FIG. 3 is a diagram showing an overview of the process flow when the first control software application 10 uses the first peripheral 202. As shown in FIG.

[0028] <Access from the first virtual machine 7 to the first peripheral 202> In order for the first control software application 10 to access the analog output port 2021, which is the first peripheral 202, an analog output port driver 12 is used. That is, when the first control software application 10 calls the analog output port driver 12 by specifying 5V as an argument as a peripheral access request, the analog output port driver 12 accesses the register of the analog output port 2021, sets a value for setting the output voltage value to 5V in a predetermined register of the microcomputer 900, and returns normal termination to the first control software application 10.

[0029] FIG. 4 is a diagram showing an outline of the process flow when the first control software application 10 uses the shared peripheral 201.

[0030] <Access from the first virtual machine 7 to the shared peripheral 201> In order for the first control software application 10 to access the digital output port 2011, which is the shared peripheral 201, the peripheral access request recording program 19, the virtual driver 11, the hypervisor 6, and the digital output port driver 16 are used. That is, the first control software application 10 calls the peripheral access request recording program 19 by specifying H as an argument as a peripheral access request. The peripheral access request recording program 19 records the peripheral access request information 51 by the first control software application 10, and calls the virtual driver 11 by specifying H as an argument. The virtual driver 11 executes a process (generally called VMExit) for changing the processing context of the CPU 1 from the first virtual machine 7 to the hypervisor 6. The hypervisor 6 checks the usage status of the digital output port 2011. That is, if the second virtual machine 8 is not using the digital output port 2011, the hypervisor 6 calls the digital output port driver 16 for accessing the digital output port 2011 by specifying H as an argument. When the second virtual machine 8 is using the digital output port 2011, the argument H is stored in a buffer prepared inside the hypervisor 6 and waits, and after the second virtual machine 8 has finished using the digital output port 2011, the argument H is retrieved from the buffer and the digital output port driver 16 is called with the retrieved argument.

[0031] The digital output port driver 16 accesses the register of the digital output port 2011, sets a value in a predetermined register of the microcomputer 900 for setting the output value to H (High, 1), and returns a normal end to the hypervisor 6. When the hypervisor 6 receives the normal end return from the digital output port driver 16, it executes a process (generally called VMEntry) for changing the processing context of the CPU 1 from the hypervisor 6 to the first virtual machine 7. When the virtual driver 11 receives the normal end information from the hypervisor 6, it calls the peripheral access request recording program 19. The peripheral access request recording program 19 records the peripheral access result information 52 for the first control software application 10, and returns a normal end to the first control software application 10.

[0032] FIG. 5 is a diagram showing an example of peripheral access request information 51 by the first control software application 10. As shown in FIG.

[0033] <Peripheral access request information 51 by first control software application 10> The peripheral access request information 51 by the first control software application 10 includes the time when the first control software application 10 called the peripheral access request recording program 19, the peripheral requested access by the call, and information on the arguments added to the call.

[0034] FIG. 6 is a diagram showing an example of peripheral access result information 52 for the first control software application 10. As shown in FIG.

[0035] <Peripheral access result information 52 for first control software application 10> The peripheral access result information 52 for the first control software application 10 includes the time when the hypervisor 6 returned information to the virtual driver 11 indicating that the processing was completed successfully, information on the peripheral processed by the hypervisor 6, and information on the processing result.

[0036] <Second virtual machine 8> The operation of the software in the second virtual machine 8 will be described. When the hypervisor 6 configures the second virtual machine 8, the second virtual machine 8 starts the second guest OS 13. The second guest OS 13 starts the second control software application 15. The second control software application 15 uses the digital output port 2011 which is the shared peripheral 201 and the digital input port 2031 which is the second peripheral 203.

[0037] FIG. 7 is a diagram showing an outline of a process flow when the second control software application 15 uses the second peripheral 203.

[0038] <Access from the second virtual machine 8 to the second peripheral 203> In order for the second control software application 15 to access the digital input port 2031, which is the second peripheral 203, the digital input port driver 14 is used. That is, when the second control software application 15 calls the digital input port driver 14 as a peripheral access request, the digital input port driver 14 accesses the register of the digital input port 2031, reads the value of a predetermined register of the microcomputer 900, and returns the result of the read to the second control software application 15.

[0039] FIG. 8 is a diagram showing an outline of a process flow when the second control software application 15 uses the shared peripheral 201.

[0040] <Access from the second virtual machine 8 to the shared peripheral 201> In order for the second control software application 15 to access the digital output port 2011, which is the shared peripheral 201, the virtual driver 11, the hypervisor 6, and the digital output port driver 16 are used. That is, the first control software application 10 calls the virtual driver 11 by specifying H as an argument as a peripheral access request. The virtual driver 11 executes a process (generally called VMExit) for changing the processing context of the CPU 1 from the second virtual machine 8 to the hypervisor 6. The hypervisor 6 checks the usage status of the digital output port 2011. That is, if the first virtual machine 7 is not using the digital output port 2011, the hypervisor 6 calls the digital output port driver 16 for accessing the digital output port 2011 with H as an argument. When the first virtual machine 7 is using the digital output port 2011, the hypervisor 6 stores argument H in a buffer prepared inside the hypervisor 6 and waits, and after the first virtual machine 7 has finished using the digital output port 2011, the hypervisor 6 retrieves argument H from the buffer and calls the digital output port driver 16 with the retrieved argument.

[0041] The digital output port driver 16 accesses the register of the digital output port 2011, sets a value in a predetermined register of the microcomputer 900 for setting the output value to H (High, 1), and returns normal termination to the hypervisor 6. Upon receiving the normal termination return from the digital output port driver 16, the hypervisor 6 executes a process (generally referred to as VMEntry) for changing the processing context of the CPU 1 from the hypervisor 6 to the first virtual machine 7. Upon receiving the normal termination information from the hypervisor 6, the virtual driver 11 returns normal termination to the first control software application 10.

[0042] <Peripheral access request recording program 19> The peripheral access request recording program 19 generates peripheral access request information 51 by the first control software application 10 when the first control software application 10 sends out a peripheral access request, as shown in Fig. 4. Also, the peripheral access request recording program 19 generates peripheral access result information 52 for the first control software application 10 when the virtual driver 11 receives information from the hypervisor 6 that the operation has been normally terminated, as shown in Fig. 4. Furthermore, the peripheral access request recording program 19 is repeatedly started at a predetermined timing (for example, at a cycle of 100 milliseconds) by the first guest OS 9, generates peripheral access record information 53 that integrates the peripheral access request information 51 by the first control software application 10 and the peripheral access result information 52 for the first control software application 10, and writes the peripheral access record information 53 in a memory area that the hypervisor monitoring program 17 can refer to.

[0043] FIG. 9 is a diagram showing an example of the peripheral access record information 53. As shown in FIG.

[0044] <Peripheral access record information 53> The peripheral access record information 53 includes the time when the first control software application 10 called the peripheral access request record program 19, the peripheral to which the access request was made, information on the arguments added to the request, the time when the hypervisor 6 sent information to the virtual driver 11 indicating that the peripheral access request was successfully processed, and information on the processing result by the hypervisor 6.

[0045] <Register value acquisition program 18> The register value acquisition program 18 is repeatedly started at a predetermined timing (for example, at a cycle of 5 milliseconds) by the host OS 5. Each time the register value acquisition program 18 is started, it calls the digital output port driver 16 to acquire the value of a predetermined register of the microcomputer 900 indicating the state of the digital output port 2011 which is the shared peripheral 201, generates peripheral state record information 54, and writes the generated peripheral state record information 54 into a memory area which can be referenced by the hypervisor monitoring program 17. The register value acquisition program 18 is executed on the host OS 5, but may be executed on the hypervisor 6.

[0046] FIG. 10 is a diagram showing an example of the peripheral state record information 54. As shown in FIG.

[0047] <Peripheral Status Record Information 54> The peripheral state record information 54 includes information on the peripheral that is the target of processing by the register value acquisition program 18, the time when the register value acquisition program 18 called the peripheral (digital output port driver 16), and the register value acquired by the call.

[0048] FIG. 11 is a diagram showing an outline of the processing flow of the hypervisor monitoring program 17. As shown in FIG.

[0049] <Hypervisor monitoring program 17> The hypervisor monitoring program 17 calculates the value that the register value should take based on the peripheral access record information 53, and if this value does not match the peripheral status record information 54, it determines that an abnormality has occurred in the hypervisor 6.

[0050] In step S1, the hypervisor monitoring program 17 generates peripheral desired state information 55 based on all information included in the peripheral access record information 53 and state confirmation time information included in the peripheral state record information 54.

[0051] In step S2, the hypervisor monitoring program 17 compares the peripheral state record information 54 with the peripheral desired state information 55 to determine whether the state of the hypervisor 6 is normal or abnormal.

[0052] FIG. 12 is a diagram showing an example of the peripheral desired state information 55. As shown in FIG.

[0053] <Peripheral desired state information 55> The peripheral desired state information 55 includes information on the value of the peripheral register at the time when the register value acquisition program 18 called the digital output port driver 16 and the time calculated based on the peripheral access record information 53 .

[0054] FIG. 13 is a diagram illustrating the peripheral desired state information generating process in step S1 of the hypervisor monitoring program 17. As shown in FIG.

[0055] <Step S1> In this embodiment, the initial values ​​of the registers are undefined.

[0056] According to the peripheral access record information 53, the first control software application 10 sends a peripheral access request with an argument of H at time 10:00. There is overhead between when the first control software application 10 sends the peripheral access request and when the register value of the digital output port driver 16 is actually operated according to the flow shown in Fig. 4. The length of this overhead cannot be predicted, but the hypervisor response time information in the peripheral access record information 53 calculates that the register value is set to H at some time between time 10:00 and time 16:00.

[0057] Similarly, according to the peripheral access record information 53, the first control software application 10 sends a peripheral access request with an argument of L at time 25:00. There is overhead between when the first control software application 10 sends the peripheral access request and when the value of the register of the digital output port driver 16 is actually operated according to the flow shown in Fig. 4. The length of this overhead cannot be predicted, but it is calculated from the hypervisor response time information in the peripheral access record information 53 that the value of the register is set to L at some time between time 25:00 and time 32:00.

[0058] Therefore, the peripheral desired state information 55 is generated as shown in Fig. 12. That is, at time 12:10, either the initial value, which is an indefinite value, is maintained, or the register value is set to H in accordance with the peripheral access request transmitted at time 10:00, and the register value can be either H or L. At time 17:10, which is after time 16:00, the register value is H, and at time 22:10, the register value continues to be H. At time 27:10, either the register value continues to be H, or the register value is set to L in accordance with the peripheral access request transmitted at time 25:00, and the register value can be either H or L. At time 32:10, which is after time 32:00, the register value is calculated to be L, and at time 37:10, the register value continues to be L.

[0059] FIG. 14 is a diagram illustrating the peripheral desired state information generating process in step S1 of the hypervisor monitoring program 17. As shown in FIG.

[0060] <Step S2> In step S2, the hypervisor monitoring program 17 compares the peripheral desired state information 55 with the peripheral state record information 54, and determines that an abnormality has occurred in the hypervisor 6 when the peripheral register value at each time calculated by the peripheral desired state information 55 is different from the register value recorded in the peripheral state record information 54. That is, in the case shown in FIG. 14, at time 32:10, the register value should be L according to the peripheral desired state information 55, but the actual register value is H according to the peripheral state record information 54, so that an abnormality in the hypervisor 6 is detected. This indicates that the first control software application 10 transmits a peripheral access request to set the digital output port 2011 to L, and the hypervisor 6 responds to the first control software application 10 that the process has been normal, but in reality the value of the digital output port 2011 remains unchanged at H.

[0061] According to this embodiment, even if the internal logic of the hypervisor 6 is not disclosed, the hypervisor 6 monitors from outside the hypervisor 6 whether the processing requested by the control software applications 10 and 15 in the virtual machines 7 and 8 is being executed correctly by recording the change in the value of the register of the microcomputer 900 operated by the hypervisor 6. Therefore, it is possible to detect an abnormality of the hypervisor 6 based on the input and output of the hypervisor 6 without accessing the internal state of the hypervisor 6. In other words, even if the hypervisor 6 returns a normal processing to the virtual machines 7 and 8, it is possible to detect an abnormality of the hypervisor 6 if the processing is not actually being executed normally.

[0062] Furthermore, since an abnormality in the hypervisor 6 is determined based on a discrepancy between the actual value and the expected value of the register, extra processing such as test patterns is not required, and the impact on the actual processing can be suppressed. EXAMPLES

[0063] An electronic control device and method according to a second embodiment of the present invention will be described. The second embodiment differs from the first embodiment in that a monitoring result storage program 20 is added to the software configuration. The same components as those in the first embodiment are given the same reference numerals and their description will be omitted.

[0064] 15 is a diagram showing the software configuration of the electronic control unit of the second embodiment. The software shown in FIG.

[0065] <Software configuration> The host OS 5 is mounted on the microcomputer 900. The host OS 5 starts the hypervisor 6, the hypervisor monitoring program 17, and the register value acquisition program 18. The host OS 5 also checks the value of the abnormality detection flag 56 repeatedly at a predetermined timing (for example, at a cycle of 5 milliseconds), and when it is confirmed that the abnormality detection flag 56 is True, it rewrites the abnormality detection flag 56 to False and then starts the monitoring result storage program 20.

[0066] <Anomaly detection flag 56> The abnormality detection flag 56 is a variable that takes one of two values, True or False.

[0067] FIG. 16 is a diagram showing an outline of the processing flow of the hypervisor monitoring program 17.

[0068] <Step S3> In step S3, the hypervisor monitoring program 17 branches the process according to whether the determination result in step S2 is normal or abnormal. That is, if the determination result in step S2 is normal, the process ends without doing anything, and if the determination result in step S2 is abnormal, the process proceeds to step S4.

[0069] <Step S4> In step S4, the hypervisor monitoring program 17 changes the value of the abnormality detection flag 56 to True, and ends the process.

[0070] <Monitoring result storage program 20> The monitoring result storage program 20 stores the peripheral access record information 53 , the peripheral state record information 54 , and the peripheral desired state information 55 in a non-volatile memory area inside the memory 3 of the microcomputer 900 .

[0071] According to this embodiment, by referencing the non-volatile memory area, the peripheral access record information 53, the peripheral status record information 54, and the peripheral desired status information 55 can be used as debugging information to identify the reason why an abnormality was detected in the hypervisor 6 and the operating pattern in which the abnormality occurred in the hypervisor 6. EXAMPLES

[0072] An electronic control device and method according to a third embodiment of the present invention will be described. The third embodiment differs from the first embodiment in that a different virtual driver is used to extract the peripheral access record information 53. The same components as those in the first embodiment are given the same reference numerals and their description will be omitted.

[0073] <Configuration> FIG. 17 is a diagram illustrating a hardware configuration of an electronic control unit according to the third embodiment.

[0074] <Peripheral 2> In this embodiment, the shared peripheral 201 includes a digital output port 2011 and a CAN controller 2012 , the first peripheral 202 includes an analog output port 2021 , and the second peripheral 203 includes a digital input port 2031 .

[0075] 18 is a diagram showing the software configuration of the electronic control unit of the third embodiment. The software shown in FIG.

[0076] <Software configuration> The first virtual machine 7 includes a first guest OS 9, a first control software application 10, a virtual driver 11, a peripheral access request recording program 19, an analog output port driver 12, and a virtual CAN driver 21. The second virtual machine 8 includes a second guest OS 13, a second control software application 15, the virtual driver 11, a digital input port driver 14, and a virtual CAN driver 21.

[0077] <First Virtual Machine 7> The operation of the software in the first virtual machine 7 will be described. When the hypervisor 6 configures the first virtual machine 7, the first virtual machine 7 starts a first guest OS 9. The first guest OS 9 starts a first control software application 10. The first control software application 10 uses a digital output port 2011 and a CAN controller 2012 which are shared peripherals 201, and an analog output port 2021 which is a first peripheral 202.

[0078] FIG. 19 is a diagram showing an outline of a process flow when the first control software application 10 of the third embodiment uses the CAN controller 2012 which is the shared peripheral 201.

[0079] <Access to CAN controller 2012 from the first virtual machine 7> In order for the first control software application 10 to access the CAN controller 2012, which is the shared peripheral 201, the virtual CAN driver 21, the hypervisor 6, and the CAN driver 22 are used. That is, the first control software application 10 calls the virtual CAN driver 21 by specifying an ID specified by the CAN message protocol and data to be transmitted in a CAN frame as arguments as a peripheral access request. The virtual CAN driver 21 executes a process (generally called VMExit) for changing the processing context of the CPU 1 from the first virtual machine 7 to the hypervisor 6. The hypervisor 6 checks the usage status of the CAN controller 2012. That is, if the second virtual machine 8 is not using the CAN controller 2012, the hypervisor 6 calls the CAN driver 22 for accessing the CAN controller 2012 by specifying the ID and data as arguments. When the second virtual machine 8 is using the CAN controller 2012, the hypervisor 6 stores the argument ID and data in a buffer prepared inside the hypervisor 6 and waits, and after the second virtual machine 8 has finished using the CAN controller 2012, the hypervisor 6 retrieves the argument ID and data from the buffer and calls the CAN driver 22 with the retrieved arguments.

[0080] The CAN driver 22 accesses the register of the CAN controller 2012, stores the ID and data in a CAN frame, transmits it to the CAN communication bus, and returns normal termination to the hypervisor 6. When the hypervisor 6 receives the normal termination return from the CAN driver 22, it executes a process (generally called VMEntry) for changing the processing context of the CPU1 from the hypervisor 6 to the first virtual machine 7. When the virtual CAN driver 21 receives the normal termination information from the hypervisor 6, it returns normal termination to the first control software application 10.

[0081] FIG. 20 is a diagram showing the CAN ledger 57 of the third embodiment.

[0082] <CAN Table 57> The CAN Table 57 is stored inside the CAN Driver 22 and includes the message ID for identifying each CAN frame, the content of the data included in the CAN frame, the information on whether to perform transmission processing or reception processing on the CAN frame, and the information on the data length in the CAN frame. In this embodiment, the CAN frames from ID0 to 2000 are used for normal control processing and are transmitted to or received from the CAN communication bus. In the CAN frame with the message ID 9900, a set of the status confirmation time, the processing target, and the register value in the peripheral state recording information 54 is stored as 8-byte data, and the transmission / reception information of the CAN frame is described as "monitoring unit transmission".

[0083] <CAN Driver 22> The CAN Driver 22 operates the registers of the CAN Controller 2012 according to the information described in the CAN Table 57. That is, for the 8-byte data of the message ID0, the registers of the CAN Controller 2012 are operated to receive the vehicle speed from the CAN communication bus, for the 8-byte data of the message ID1, the registers of the CAN Controller 2012 are operated to transmit the engine speed to the CAN communication bus, and for the 8-byte data of the message ID2, the registers of the CAN Controller 2012 are operated to transmit the throttle opening to the CAN communication bus.

[0084] Furthermore, for data of message ID 9900, the type of transmission / reception of which is set to monitor unit transmission in the CAN ledger 57, the CAN driver 22 does not operate the register of the CAN controller 2012, but writes the data in a memory area that can be referenced by the hypervisor monitoring program 17. Since the CAN driver 22 exists outside the first virtual machine 7 and the hypervisor 6, it is not affected by the restriction on the memory area referenced by the hypervisor 6. Furthermore, by using a peripheral (the digital output port 2011) used for monitoring the hypervisor 6 and a different peripheral (the CAN controller 2012), the hypervisor 6 can store the peripheral access record information 53 in a memory area that can be referenced by the hypervisor monitoring program 17 even if an abnormality occurs in the operation of the digital output port 2011.

[0085] According to this embodiment, even if access from inside the virtual machine configured by the hypervisor 6 to outside the virtual machine is prohibited and the peripheral access request recording program 19 is unable to write the peripheral access recording information 53 to a memory area that can be referenced by the hypervisor monitoring program 17, the peripheral access recording information 53 can be taken outside the first virtual machine 7 and written to a memory area that can be referenced by the hypervisor monitoring program 17. EXAMPLES

[0086] An electronic control device and method according to a fourth embodiment of the present invention will be described. The fourth embodiment differs from the second embodiment in that the electronic control device is shut down when a failure of the hypervisor 6 is detected at a frequency equal to or greater than a predetermined value. Note that the same components as those in the second embodiment are given the same reference numerals and their description will be omitted.

[0087] FIG. 21 is a diagram showing an outline of the process flow of the monitoring result storage program 20 of the fourth embodiment.

[0088] <Monitoring result storage program 20> The monitoring result storage program 20 stores the peripheral access record information 53, the peripheral state record information 54, and the peripheral desired state information 55 in a non-volatile memory area inside the memory 3 of the microcontroller 900, calculates the frequency of abnormality occurrence in the hypervisor 6, and shuts down the electronic control device 0 if the calculated frequency of abnormality occurrence is equal to or greater than a predetermined threshold value.

[0089] <Step S5> In step S 5 , the monitoring result storage program 20 stores the peripheral access record information 53 , the peripheral state record information 54 , and the peripheral desired state information 55 in a non-volatile memory area inside the memory 3 of the microcomputer 900 .

[0090] <Step S6> In step S6, the monitoring result storage program 20 calculates the time when an abnormality occurred in the hypervisor 6. Since it is difficult to specify the time when an abnormality actually occurred in the hypervisor 6 from outside the hypervisor 6, the time when the abnormality occurred in the hypervisor 6 is set to the time when the abnormality occurred, which is described in the peripheral state record information 54 and the peripheral desired state information 55 on which the hypervisor monitoring program 17 determined that an abnormality occurred in the hypervisor 6. That is, when the peripheral state record information 54 and the peripheral desired state information 55 are as shown in FIG. 14, the time when the abnormality occurred in the hypervisor 6 is calculated to be 00:32:10. The monitoring result storage program 20 stores this time in the hypervisor abnormality occurrence time information 58.

[0091] FIG. 22 is a diagram illustrating an example of hypervisor abnormality occurrence time information 58 according to the fourth embodiment.

[0092] <Hypervisor abnormality occurrence time information 58> The hypervisor abnormality occurrence time information 58 stores the time information calculated in step S6 of the monitoring result storage program 20 of the electronic control unit according to the fourth embodiment.

[0093] <Hypervisor Abnormality Occurrence Frequency Requirement 59> The hypervisor abnormality occurrence frequency requirement 59 is a condition for shutting down the electronic control unit 0. In this embodiment, it is assumed that an abnormality in the hypervisor 6 is detected twice within a time period of 10:00.

[0094] FIG. 23 is a diagram showing a schematic overview of the process in step S7 of the monitoring result storage program 20 of the fourth embodiment.

[0095] <Step S7> In step S7, the monitoring result storage program 20 calculates the frequency of abnormality occurrence in the hypervisor 6. Since the hypervisor abnormality occurrence frequency requirement 59 requires the frequency of abnormality occurrence in the hypervisor 6 within 10:00, the number of recorded hypervisor abnormality occurrence times occurring within 10:00 going back from the latest abnormality occurrence time is calculated. This will be explained with reference to FIG. 23. At time 50:25, the latest abnormality occurrence time is 47:10, and the number of times that abnormality occurred from this time back to 10:00, that is, between 37:10 and 47:10, is one according to the hypervisor abnormality occurrence time information 58, so the frequency is calculated to be one. At time 54:35, the latest abnormality occurrence time is 52:10, and the number of times that abnormality occurred from this time back to 10:00, that is, between 42:10 and 52:10, is two according to the hypervisor abnormality occurrence time information 58, so the frequency is calculated to be two.

[0096] <Step S8> In step S8, if the abnormality occurrence frequency calculated in step S7 is greater than or equal to the value specified in the hypervisor abnormality occurrence frequency requirement 59, the monitoring result storage program 20 proceeds to step S9; if not, it skips step S9 and terminates this process.

[0097] <Step S9> In step S9, the monitoring result storage program 20 outputs a reset signal from the self-reset output terminal of the microcomputer 900. This causes the power supply circuit 901 to stop supplying power to the microcomputer 900, and the electronic control device 0 is shut down. The range in which the electronic control device 0 is shut down may be a part of or the entirety of the electronic control device 0.

[0098] According to this embodiment, if an abnormality is detected in the hypervisor 6 at a low frequency, the operation of the electronic control device is continued to reduce the impact on the electronic control device and the vehicle in which the electronic control device is installed, and if an abnormality is detected in the hypervisor 6 at a high frequency, the electronic control device is shut down to reduce the impact that an abnormality occurring in the hypervisor 6 has on the safety of the electronic control device and the vehicle in which the electronic control device is installed, thereby achieving both availability and safety.

[0099] The present invention is not limited to the above-described embodiments, and includes various modified examples and equivalent configurations within the spirit of the appended claims. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the configurations described. Furthermore, a part of the configuration of one embodiment may be replaced with the configuration of another embodiment. Furthermore, the configuration of another embodiment may be added to the configuration of one embodiment. Furthermore, a part of the configuration of each embodiment may be added, deleted, or replaced with another configuration.

[0100] In addition, each of the above-mentioned configurations, functions, processing units, processing means, etc. may be realized in hardware, for example by designing some or all of them as an integrated circuit, or may be realized in software by a processor interpreting and executing a program that realizes each function.

[0101] Information such as programs, tables, and files that realize each function can be stored in a storage device such as a memory, a hard disk, or an SSD (Solid State Drive), or in a recording medium such as an IC card, an SD card, or a DVD.

[0102] In addition, the control lines and information lines shown are those considered necessary for the explanation, and do not necessarily show all the control lines and information lines necessary for implementation. In reality, it can be considered that almost all components are connected to each other. [Explanation of symbols]

[0103] 0 Electronic Control Unit 1 CPU 2 Peripherals 3. Memory 4. Bus 5. Host OS 6 Hypervisor 7 First Virtual Machine 8. Second Virtual Machine 9 First Guest OS 10 First control application software 11 Virtual Drivers 12 Analog Output Port Driver 13 Second Guest OS 14 Digital Input Port Driver 15 Second control application software 16 Digital Output Port Driver 17 Hypervisor monitoring programs 18 Register value acquisition program 19 Peripheral access request recording program 20 Monitoring result storage program 21 Virtual CAN driver 22 CAN Driver 51 Peripheral access request information 52 Peripheral access result information 53 Peripheral access record information 54 Peripheral status record information 55 Peripheral desired state information 56 Anomaly detection flag 57 CAN Ledger 58 Hypervisor abnormality occurrence time information 59 Hypervisor Abnormality Occurrence Frequency Requirements 101 First CPU Core 102 Second CPU Core 201 Shared Peripherals 202 First Peripheral 203 Second Peripheral 900 Microcontroller 901 Power supply circuit 2011 Digital Output Port 2012 CAN Controller 2021 Analog Output Port 2031 Digital Input Port

Claims

1. An electronic control device, a virtual machine that accesses the first virtual driver to perform operations; a hypervisor that invokes a first real driver of a first peripheral based on a peripheral access request received from the first virtual driver; an access recording unit that calls the first virtual driver and records a peripheral access request transmitted to the hypervisor; a state recording unit that calls the first real driver and records a state of a register of the first peripheral; A monitoring unit that monitors an operation of the hypervisor, The monitoring unit is an electronic control device that determines whether or not there is an abnormality in the hypervisor based on the records of the access recording unit and the records of the status recording unit.

2. 2. The electronic control device according to claim 1, The monitoring unit determines that the hypervisor is abnormal when the record in the access recording unit and the record in the status recording unit do not match.

3. 3. The electronic control device according to claim 2, The electronic control device according to claim 1, wherein the state recording unit repeatedly acquires the state of the register at a predetermined timing.

4. 3. The electronic control device according to claim 2, The monitoring unit is an electronic control device that determines that the hypervisor is abnormal when the access recording unit records an access request, there is a record of the real driver successfully returning the processing result to the virtual driver, and the state of the register in the status recording unit does not change.

5. 2. The electronic control device according to claim 1, an electronic control device comprising: a monitoring result storage unit that stores the record of the access recording unit and the record of the status recording unit in a non-volatile manner when the monitoring unit determines an abnormality;

6. 6. The electronic control device according to claim 5, The monitoring result storage unit is an electronic control device that stops a part or all of the electronic control device when the frequency at which the hypervisor is determined to be abnormal is equal to or greater than a predetermined threshold value.

7. 2. The electronic control device according to claim 1, a second peripheral different from the first peripheral; a second real driver for operating the second peripheral; the second peripheral outputs the record of the access record unit to an outside of the virtual machine in accordance with an instruction from the second real driver; The monitoring unit is an electronic control device that refers to the record of the access recording unit that is output to the outside of the virtual machine.

8. A method for determining an abnormality in a hypervisor that operates in an electronic control device, comprising: The electronic control device includes: a virtual machine that accesses the first virtual driver to perform operations; a hypervisor that invokes a first real driver of a first peripheral based on a peripheral access request received from the first virtual driver; an access recording unit that calls the first virtual driver and records a peripheral access request transmitted to the hypervisor; a state recording unit that calls the first real driver and records a state of a register of the first peripheral; A monitoring unit that monitors an operation of the hypervisor, The abnormality determination method includes: the state recording unit calls the first real driver to record a state of a register of the first peripheral; An abnormality determination method in which the monitoring unit determines an abnormality in the hypervisor based on the record in the access recording unit and the record in the status recording unit.

Images