DE112022001480T5 - ELECTRONIC CONTROL UNIT AND ANOMALY DETERMINATION METHOD - Google Patents

Abstract

An electronic control unit includes: a virtual machine that accesses a first virtual driver to execute a process; a hypervisor that invokes a first real driver of a first peripheral device based on a peripheral access request received from the first virtual driver; an access recording unit that calls the first virtual driver to record a peripheral access request sent to the hypervisor; a state recording unit that calls the first real driver to record a state of a register of the first peripheral device; and a monitoring unit that monitors operation of the hypervisor. The monitoring unit determines an abnormality of the hypervisor based on a recording by the access recording unit and a recording by the state recording unit.

Description

Incorporation by reference

This application claims priority Japanese Patent Application No. 2021-80743 , filed May 12, 2021, the contents of which are incorporated herein by reference in their entirety.

Technical area

The present invention relates to an electronic control unit.

Technical background

The use of a hypervisor allows multiple control software applications running in different operating systems (OS) to be incorporated into a single microcomputer. As techniques of monitoring a hypervisor are techniques that are in JP 2019-144785 A (Patent Literature 1) and JP 2014-106587 A (Patent Literature 2) are known. Patent Literature 1 describes a monitoring program according to which a monitoring virtual machine is operated in virtualization software, the monitoring virtual machine is used to monitor multiple monitoring targets containing the virtualization software, results of given checks executed by the monitoring virtual machine at given intervals are obtained, the presence or absence of an anomaly in the monitoring virtual machine is determined from the detected test results and then, if the monitoring virtual machine is in an abnormal state, a given state of the plurality of monitoring targets is detected and a result of a determination the presence or absence of an anomaly in the monitoring virtual machine and the given state of the multiple monitoring targets are output.

Patent Literature 2 describes a method for controlling an input/output device, the method causing a hypervisor and a first guest operating system to share an input/output device, and according to which the input/output device has a physical function and a virtual function, the hypervisor has a physical driver that uses the physical function, the first guest operating system has a virtual driver that uses the virtual function, the hypervisor senses a state of the input/output device using the physical driver, and then , when the first guest operating system monitoring the hypervisor determines that the hypervisor is in a given state, a subphysical driver operating the input/output device is started, and the first guest operating system initiates sending/receiving data via a Data queue that is preset in a memory.

Summary of the invention

Technical problem

In an electronic control unit in which multiple control software applications running in different operating systems are integrated in a microcomputer (hardware), virtualization software called a hypervisor is used. The hypervisor provides a virtual machine as an environment for running an operating system and a control software application. The virtual machine is a device with an access authority set for its access to a central processing unit (CPU) in the microcomputer, a memory area and peripheral devices installed on the microcomputer, such as. B. a control unit area network control unit (CAN control unit) and an analog/digital converter (A/D converter). From the perspective of a guest operating system and a control software application in each virtual machine, this describes the logically corresponding fact that a CPU, memory area and peripherals exist in a different microcomputer without any set authority to access them. In general, in order to ensure the safety and reliability of an electronic control unit, the operation of the electronic control unit must be monitored to confirm that hardware and software constituting the electronic control unit are operating normally without developing an abnormality. In particular, in the case of an electronic control unit using a hypervisor, monitoring the operation of the hypervisor is necessary.

According to Patent Literature 1, the monitoring virtual machine is installed as a virtual machine, the monitoring virtual machine periodically executes a test pattern and detects an internal state (normal/abnormal) of the hypervisor and is based on a result of execution of the test pattern and a result a detection of the internal state of the hypervisor determines whether an anomaly has occurred in the electronic control unit, and then, if an anomaly has occurred, a level of influence of the anomaly can be determined. However, since monitoring of the hypervisor in Patent Literature 1 is carried out by detecting a normal or abnormal state determined by the hypervisor itself, a case in which an abnormal state of the Hypervisor caused by an anomaly that has occurred in it is not properly determined is not taken into account and therefore normal operation of the hypervisor is not guaranteed. In addition, because detecting the internal state of the hypervisor is necessary, the technique of Patent Literature 1 cannot be applied to a third-party hypervisor whose internal state is not accessible to the public.

Patent Literature 2 describes a method according to which a counter (a guard timer) is provided for the hypervisor, the counter is set to meet a request to count up or count down in a given cycle, and then when the counter completes its count in the given cycle Period is not updated, it is determined that an anomaly has occurred in the hypervisor. This allows detection of an unexpected hypervisor halt or a deadlock or livelock that has occurred in the hypervisor. To apply this method, however, it is necessary to specify requirements related to updating a count by the counter in the hypervisor. In addition, because a count update process is generally given a high priority by the guard timer, if the priority of the count update process is set greater than the processing priority of a task that has developed a deadlock or a livelock in the hypervisor, the deadlock or the livelock may not be detected become.

An object of the present invention is to monitor a hypervisor provided by a third party or the like, where the hypervisor does not expose its internal logic to the public, and based only on an anomaly that has occurred in the hypervisor the input and output of the hypervisor.

the solution of the problem

A typical example of the present invention disclosed herein is as follows. An electronic control unit includes: a virtual machine that accesses a first virtual driver to execute a process; a hypervisor that invokes a first real driver of a first peripheral device based on a peripheral access request received from the first virtual driver; an access recording unit that calls the first virtual driver to record a peripheral access request sent to the hypervisor; a state recording unit that calls the first real driver to record a state of a register of the first peripheral device; and a monitoring unit that monitors operation of the hypervisor. The monitoring unit determines an abnormality of the hypervisor based on a recording by the access recording unit and a recording by the state recording unit.

Advantageous effects of the invention

According to one aspect of the present invention, an anomaly of a hypervisor may be detected without accessing an internal state of the hypervisor. Problems, configurations and effects not described above will be clarified by the following description of embodiments.

Brief description of the drawings

• [ 1 ] 1 represents a hardware configuration of an electronic control unit according to a first embodiment.
• [ 2 ] 2 illustrates a software configuration of the electronic control unit according to the first embodiment.
• [ 3 ] 3 illustrates an overview of a process flow that is executed when a first control software application of the first embodiment uses a first peripheral device.
• [ 4 ] 4 illustrates an overview of a process flow that is executed when the first control software application of the first embodiment uses a shared peripheral device.
• [ 5 ] 5 illustrates an example of peripheral access request information according to the first embodiment.
• [ 6 ] 6 illustrates an example of peripheral access result information of the first embodiment.
• [ 7 ] 7 illustrates an overview of a process flow that is executed when a second control software application of the first embodiment uses a second peripheral device.
• [ 8th ] 8th illustrates an overview of a process flow executed when the second control software application of the first embodiment uses the shared peripheral device.
• [ 9 ] 9 illustrates an example of peripheral access record information according to the first embodiment.
• [ 10 ] 10 illustrates an example of peripheral state recording information according to the first embodiment.
• [ 11 ] 11 illustrates an overview of a process flow of a hypervisor monitoring program of the first embodiment.
• [ 12 ] 12 illustrates an example of peripheral determination state information according to the first embodiment.
• [ 13 ] 13 is a diagram schematically showing a process of generating the peripheral determination state information executed in step S1 of the hypervisor monitoring program of the first embodiment.
• [ 14 ] 14 is a diagram schematically showing the process of generating the peripheral determination state information executed in step S1 of the hypervisor monitoring program of the first embodiment.
• [ 15 ] 15 represents a software configuration of an electronic control unit according to a second embodiment.
• [ 16 ] 16 illustrates an overview of a process flow of a hypervisor monitoring program of the second embodiment.
• [ 17 ] 17 represents a hardware configuration of an electronic control unit according to a third embodiment.
• [ 18 ] 18 illustrates a software configuration of the electronic control unit according to the third embodiment.
• [ 19 ] 19 illustrates an overview of a process flow executed when the first control software application of the third embodiment uses a CAN controller which is the shared peripheral device.
• [ 20 ] 20 represents a CAN ledger of the third embodiment.
• [ 21 ] 21 illustrates an overview of a process flow of a monitoring result storage program of a fourth embodiment.
• [ 22 ] 22 illustrates an example of hypervisor anomaly occurrence time information of the fourth embodiment.
• [ 23 ] 23 is a diagram schematically showing an overview of a process executed in step S7 of the monitoring result storage program of the fourth embodiment.

Description of the embodiments

Embodiments described herein relate to an electronic control unit and particularly relate to an electronic control unit in which multiple control software applications are integrated in a microcomputer.

Examples of preferred embodiments of the present invention are described below. In the embodiments, for convenience of description, an example is explained in which two control software applications, i.e. H. a first control software application and a second control software application, are integrated in an electronic control unit. However, in a different example, a third control software application and a fourth control software application may be integrated into an electronic control unit.

First embodiment

<Configuration>

1 represents a hardware configuration of an electronic control unit according to a first embodiment.

<Electronic control unit 0>

The electronic control unit according to the first embodiment will be described below with reference to 1 described. An electronic control unit 0 includes a microcomputer 900 and a power supply circuit 901. The microcomputer 900 includes a central processing unit (CPU) 1 that executes calculation processes, a peripheral device 2 which is a peripheral device group installed on the electronic control unit 0, a memory 3, the software stores, and a bus 4 that connects the CPU 1, the peripheral device 2 and the memory 3 and allows the CPU 1 to access the peripheral device 2 and the memory 3.

A power input terminal of the microcomputer 900 is connected to a power supply circuit 901. The microcomputer 900 starts when powered by 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 supplying power to the microcomputer 900.

<CPU 1>

The CPU 1 contains two CPU cores, i.e. H. a first CPU core 101 and a second CPU core 102. It should be noted that two CPU cores are mentioned by way of example to simplify the description. For example, the CPU 1 may include one CPU core or three or more CPU cores.

<Peripheral device 2>

The peripheral device 2 is a device that inputs and outputs data/signals to or from the microcomputer 900, and includes a shared peripheral device 201 accessed by both a first control software application 10 (i.e., a first CPU core 101). as well as a second control software application 15 (i.e., a second CPU core 102), a first peripheral device 202 accessed only by the first control software application 10 (i.e., the first CPU core 101). , and a second peripheral device 203 accessed only by the second control software application 15 (i.e., the second CPU core 103). The peripheral device 2 generally refers to peripheral circuits that do not include the CPU 1 and the memory 3 installed on the microcomputer 900. The peripheral device 2 specifically includes a control unit area network (CAN) control unit, an analog-to-digital converter, a direct memory access control unit, and a general purpose input/output (GPIO) installed on the microcomputer 900.

<Memory 3>

The memory 3 includes a ROM, which is a non-volatile memory element, and a RAM, which is a volatile memory element. The ROM stores an unchangeable program (e.g. BIOS) and the like. RAM is a volatile memory element that allows high-speed access, such as: B. a dynamic random access memory (DRAM) that stores programs executed by the CPU 1 and data used to execute programs.

For simplicity, this embodiment will be described assuming that the shared peripheral device 201 includes a digital output port 2011, the first peripheral device 202 includes an analog output port 2021, and the second peripheral device 203 includes a digital input port 2031.

2 illustrates a software configuration of the electronic control unit according to the first embodiment. The software pieces included in 2 are shown are stored in memory 3.

<Software configuration>

The following process is executed in either the first CPU core 101 or the second CPU core 102 of the CPU 1.

A host operating system (host OS) 5 is installed in the microcomputer 900. The host operating system 5 activates a hypervisor 6, a hypervisor monitoring program 17 and a register value acquisition program 18. The hypervisor 6 is activated by an activation procedure defined by the hypervisor 6. The hypervisor monitor program 17 and the register value capture program 18 are activated in a 5 millisecond cycle to collect information for monitoring. For simplicity, the activation cycle in this embodiment is described as 5 milliseconds. However, a different activation cycle can also be used without a limitation of 5 milliseconds. The hypervisor 6 may be configured by software running in the host operating system 5 or by hardware installed on the microcomputer 900.

The hypervisor 6 configures a first virtual machine 7 and a second virtual machine 8 through a method defined by the hypervisor 6, and activates each of the first virtual machine 7 and the second virtual machine 8. For convenience, in this embodiment, two virtual machines are used Machines described. However, one or three or more virtual machines can be provided without being limited to two.

In the first virtual machine 7, a first guest operating system 9, the 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 operating system 13, the second control software application 15, the virtual driver 11 and a digital input port driver 14 are executed. The peripheral access request recording program 19 is executed in the first virtual machine 7, but may be executed in the second virtual machine 8. In other words, at least one peripheral access request recording program 19 executed in the hypervisor 6 is sufficient.

<First virtual machine 7>

The operation of software in the first virtual machine 7 is described. When the hypervisor 6 configures the first virtual machine 7, the first virtual machine 7 activates the first guest operating system 9. The first guest operating system 9 activates the first control software application 10. The first control software application 10 uses the digital output port 2011, which is the shared peripheral device 201, and the analog output port 2021 which is the first peripheral device 202.

3 illustrates an overview of a process flow that is executed when the first control software application 10 uses the first peripheral device 202.

<Access from the first virtual machine 7 to the first peripheral device 202>

To access the analog output port 2021, which is the first peripheral device 202, the first control software application 10 uses the analog output port driver 12. Specifically, when the first control software application 10 calls the analog output port driver 12 by setting a parameter of 5V, the call being made as a peripheral access request, the analog output port driver 12 accesses a register of the analog output port 2021 to, inputs a value for setting an output voltage of 5 V at a given location of a register of the microcomputer 900 and sends a response indicating normal termination to the first control software application 10.

4 illustrates an overview of a process flow that is executed when the first control software application 10 uses the shared peripheral device 201.

<Access from the first virtual machine 7 to the shared peripheral device 201>

To access the digital output port 2011, which is the shared peripheral device 201, the first control software application 10 uses the peripheral access request recorder 19, the virtual driver 11, the hypervisor 6 and the digital output port driver 16. Specifically, the first control software application 10 calls the peripheral access request recording program 19 by setting a parameter of H, which call is made as a peripheral access request. The peripheral access request recording program 19 records peripheral access request information 51 from the first control software application 10 and calls the virtual driver 11 by setting a parameter of H. The virtual driver 11 executes a process of changing a processing context of the CPU 1 from the first virtual machine 7 to the hypervisor 6 (this process is generally referred to as VMExit). The hypervisor 6 checks a usage status of the digital output port 2011. If it is determined that the second virtual machine 8 is not using the digital output port 2011, the hypervisor 6 calls the digital output port driver 16 to access the digital output port 2011 by setting a parameter of H up. When it is determined that the second virtual machine 8 is using the digital output port 2011, the hypervisor 6 stores the parameter H in a buffer provided in the hypervisor 6 and goes to standby, taking the parameter H out of the buffer after the second virtual machine 8 has finished using the digital output port 2011, and then calls the digital output port driver 16 by appending the extracted parameter to the call.

The digital output port driver 16 accesses a register of the digital output port 2011, inputs a value for setting an output value of H (high or 1) to a given location of the register of the microcomputer 900, and sends a response indicating normal completion , back to the hypervisor 6. Upon receipt of the response indicating normal completion from the digital output port driver 16, the hypervisor 6 performs a process of changing the processing context of the CPU 1 from the hypervisor 6 to the first virtual machine 7 (this process generally called VVMentry). When information indicating normal completion is received from the hypervisor 6, the virtual driver 11 calls the peripheral access request recorder 19. The peripheral access request recording program 19 records peripheral access result information 52 about the first control software application 10 and sends a response indicating normal completion to the first control software application 10.

5 illustrates an example of the peripheral access request information 51 from the first control software application 10.

<Peripheral access request information 51 from the first control software application 10>

The peripheral access request information 51 from the first control software application 10 includes information about a time at which the first control software application 10 called the peripheral access request recording program 19 about a peripheral device to which an access request was made by the call and via a parameter that is set by the call.

6 illustrates an example of the peripheral access result information 52 about the first control software application 10.

<Peripheral access result information 52 about a first control software application 10>

The peripheral access result information 52 about the first control software application 10 includes information about a time at which the hypervisor 6 sent a response indicating normal completion of a process back to the virtual driver 11 via a peripheral device that is a Process is subjected to by the hypervisor 6, and about process results.

<Second virtual machine 8>

The operation of software in the second virtual machine 8 is described. When the hypervisor 6 configures the second virtual machine 8, the second virtual machine 8 activates the second guest operating system 13. The second guest operating system 13 activates the second control software application 15. The second control software application 15 uses the digital output port 2011, which is the shared peripheral device 201, and the digital input port 2031 which is the second peripheral device 203.

7 illustrates an overview of a process flow that is executed when the second control software application 15 uses the second peripheral device 203.

<Access from second virtual machines 8 to the second peripheral device 203>

To access the digital input port 2031, which is the second peripheral device 203, the second control software application 15 uses the digital input port driver 14. Specifically, when the second control software application 15 calls the digital input port driver 14, the call being made as a peripheral access request, the digital input port driver 14 accesses a register of the digital input port 2031, reads a value at one given location of the register of the microcomputer 900 and sends a response accompanied by the read value back to the second control software application 15.

8th illustrates an overview of a process flow that is executed when the second control software application 15 uses the shared peripheral device 201.

<Access from the second virtual machine 8 to the shared peripheral device 201>

To access the digital output port 2011, which is the shared peripheral device 201, the second control software application 15 uses the virtual driver 11, the hypervisor 6 and the digital output port driver 16. Specifically, the first control software application 10 calls the virtual driver 11 by setting a parameter of H, the call being made as a peripheral access request. The virtual driver 11 executes a process of changing a processing context of the CPU 1 from the second virtual machine 8 to the hypervisor 6 (this process is generally referred to as VMExit). The hypervisor 6 checks a usage status of the digital output port 2011. If it is determined that the first virtual machine 7 is not using the digital output port 2011, the hypervisor 6 calls the digital output port driver 16 to access the digital output port 2011 by setting a parameter of H up. When it is determined that the first virtual machine 7 is using the digital output port 2011, the hypervisor 6 stores the parameter H in the buffer provided in the hypervisor 6 and goes into standby, taking the parameter H out of the buffer after the first virtual Machine 7 has completed using the digital output port 2011, and then calls the digital output port driver 16 by appending the extracted parameter to the call.

The digital output port driver 16 accesses a register of the digital output port 2011, inputs a value for setting an output value of H (high or 1) in a given location of the register of the microcomputer 900, and sends a response indicating normal completion indicates, back to the hypervisor 6. Upon receipt of the response indicating normal completion from the digital output port driver 16, the hypervisor 6 performs a process of changing the processing context of the CPU 1 from hypervisor 6 to the first virtual machine 7 (the process is generally referred to as VMBentry). When information indicating normal completion is received from the hypervisor 6, the virtual driver 11 sends a response indicating normal completion back to the first control software application 10.

<Peripheral access request recording program 19>

As in 4 As shown in FIG 4 As shown, when the virtual driver 11 receives information indicating normal completion from the hypervisor 6, the peripheral access request recording program 19 generates the peripheral access result information 52 via the first control software application 10. Further, the peripheral access request recording program 19 repeatedly activated by the first guest operating system 9 in a given timing (e.g., in a cycle of 100 milliseconds), generates peripheral access record information 53 into which the peripheral access request information 51 from the first control software application 10 and the peripheral access result -Information 52 is integrated via the first control software application 10, and writes the peripheral access record information 53 to a memory area to which the hypervisor monitoring program 17 can refer.

9 illustrates an example of the peripheral access record information 53.

<Peripheral access record information 53>

The peripheral access record information 53 includes information about a time at which the first control software application 10 called the peripheral access request recording program 19, about a peripheral accessed by a peripheral access request, on a parameter sent to the Peripheral access request is attached to a time at which the hypervisor 6 has sent information indicating normal completion of a process to the virtual driver 11 according to the peripheral access request, and to process results by the hypervisor 6.

<Register value acquisition program 18>

The register value acquisition program 18 is repeatedly activated by the host operating system 5 at a given timing (e.g. in a cycle of 5 milliseconds). Each time it is activated, the register value capture program 18 calls the digital output port driver 16 to capture a value at a given location of the register of the microcomputer 900, the value indicating a state of the digital output port 2011 that is the shared peripheral device 201, generates peripheral state record information 54 and writes the generated peripheral state record information 54 to a memory area to which the hypervisor monitoring program 17 can reference. The register value capture program 18 is executed in the host operating system 5, but can be executed in the hypervisor 6.

10 illustrates an example of the peripheral state record information 54.

<Peripheral state record information 54>

The peripheral state record information 54 includes information about a process target peripheral subjected to a process by the register value acquisition program 18, a time at which the register value acquisition program 18 called the peripheral device (the digital output port driver 16), and a register value determined by the call is recorded.

11 represents an overview of a process flow of the hypervisor monitoring program 17.

<Hypervisor Monitor 17>

The hypervisor monitoring program 17 calculates a value assumed to be input as a register value based on the peripheral access record information 53, and then determines when the value assumed to be input as the register value , does not match the corresponding value indicated by the peripheral state record information 54 that an abnormality has occurred in the hypervisor 6.

In step S1, the hypervisor monitoring program 17 generates peripheral determination state information 55 based on all pieces of information that the peripheral access srecording information 53, and status check time information contained in the peripheral status recording information 54.

In step S2, the hypervisor monitoring program 17 compares the peripheral state record information 54 with the peripheral determination state information 55 and determines whether the hypervisor 6 is in a normal state or an abnormal state.

12 illustrates an example of the peripheral determination state information 55.

<Peripheral determination state information 55>

The peripheral determination state information 55 includes information about a time at which the register value acquisition program 18 called the digital output terminal driver 16 and a peripheral register value at a time calculated based on the peripheral access record information 53.

13 is a diagram schematically showing a process of generating the peripheral determination state information executed in step S1 of the hypervisor monitoring program 17.

<Step S1>

In this embodiment, an initial value for the register is a non-fixed value.

According to the peripheral access record information 53, the first control software application 10 sends a peripheral access request with a specified parameter H at 10:00. Now, an overhead time is a period between the sending of the peripheral access request by the first control software application 10 and the actual processing of a register value of the digital output port driver 16 according to the flow shown in 4 shown is present. The length of the surcharge period cannot be predicted. However, with reference to a response time of a hypervisor indicated in the peripheral access record information 53, it is deduced that the register value is set to H at any time between 10:00 and 16:00.

Accordingly, according to the peripheral access record information 53, the first control software application 10 sends a peripheral access request with a set parameter L at 25:00. Now, an overhead time is a period between the sending of the peripheral access request by the first control software application 10 and the actual processing of a register value of the digital output port driver 16 according to the flow shown in FIG 4 shown is present. The length of the surcharge period cannot be predicted. However, with reference to a response time of a hypervisor indicated in the peripheral access record information 53, it is deduced that the register value is set to L at any time between 25:00 and 32:00.

Therefore, the peripheral determination state information 55 included in 12 are shown. Specifically, at 12:10, either the initial value results, that is, a non-fixed value that is maintained, or H, which is entered as the register value match to the peripheral access request sent at 10:00, meaning that both the register value H and The register value L could also result. At 17:10, a time behind 16:00, the register value is H, which also results in 22:10. However, at 27:10 this results in either the register value remaining H or the register value being switched to L in accordance with the peripheral access request sent at 25:00, meaning that both the register value is H and the register value L could result. At 32:10, a time behind 32:00, the register value is L, which also results in 37:10.

14 is a diagram schematically showing the process of generating the peripheral determination state information executed in step S1 of the hypervisor monitoring program 17.

<Step S2>

In step S2, the hypervisor monitoring program 17 compares the peripheral determination state information 55 with the peripheral state record information 54 and determines that an abnormality has occurred in the hypervisor 6 if the peripheral register value at each calculated time in the peripheral determination state information 55 differs from the corresponding register value recorded in peripheral state record information 54 is different. Specifically should, as in 14 is specified, the register value at 32:10 according to the peripheral determination state information will be 55 L, however, the actual register value at 32:10 according to the peripheral state recording information is 54 H. This indicates the fact that an abnormality has occurred in the hypervisor 6, which means detection of an anomaly. This indicates a case where the first tax soft ware application 10 has sent a peripheral access request of setting a register value of the digital output port 2011 to L and the hypervisor 6 has sent a response indicating normal completion of a process back to the first control software application 10, but in fact the register value is of the digital output connection has not changed in 2011, i.e. H remains.

According to this embodiment, even in the case of the hypervisor 6 whose internal logic is not made open to the public, it is monitored from outside the hypervisor 6 using a record of changes in the register values of the microcomputer 900 operated by the hypervisor 6 Hypervisor 6 correctly executes processes requested by control software applications 10 and 15 in virtual machines 7 and 8. Through this process, an anomaly of the hypervisor 6 can be detected based on input to and output from the hypervisor 6 without accessing an internal state of the hypervisor 6. Even in a case where the hypervisor 6 sends a response indicating completion of a normal process back to the virtual machines 7 and 8, if the process is actually not executing normally, this fact may be considered an anomaly of the hypervisor 6 be detected.

In addition, because an abnormality of the hypervisor 6 is determined based on the inconsistency between an actual value of the register and a preset value, an additional process such as B. a test sample is unnecessary, which reduces a negative impact on a main process.

Second embodiment

An electronic control unit and an abnormality detection method according to a second embodiment of the present invention will be described. The second embodiment is different from the first embodiment in that a monitoring result storage program 20 is added to a software configuration. The same components as those of the first embodiment are denoted by the same reference numerals and will be omitted from further description.

15 represents a software configuration of the electronic control unit according to the second embodiment. Pieces of software included in 15 is shown are stored in memory 3.

<Software configuration>

The host operating system 5 is installed in the microcomputer 900. The host operating system 5 activates a hypervisor 6, a hypervisor monitoring program 17, and a register value detection program 18. The host operating system 5 repeatedly checks and writes a value of the anomaly detection flag 56 at a given timing (e.g., in a 5 millisecond cycle). then, when it is confirmed that the value of the abnormality detection flag 56 is True, changes the value of the abnormality detection flag 56 to False, and then starts the monitoring result storage program 20.

<Anomaly detection flag 56>

The anomaly detection flag 56 is a variable that takes one of two values: true and false.

16 represents an overview of a process flow of the hypervisor monitoring program 17.

<Step S3>

In step S3, the hypervisor monitoring program 17 causes the process flow to branch depending on whether a determination result in step S2 is a normal state or an abnormal state. In other words, the hypervisor monitoring program 17 ends the process flow without taking any action when the determination result in step S2 is a normal state, but proceeds to step S4 when the determination result in step S2 is an abnormal state.

<Step S4>

In step S4, the hypervisor monitoring program 17 sets a value of the anomaly detection flag 56 to True and ends the process flow.

<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 determination state information 55 in a non-volatile memory area in the memory 3 of the microcomputer 900.

According to this embodiment, with reference to the non-volatile memory area, the peripheral access record information mations 53, the peripheral state record information 54 and the peripheral determination state information 55 are used as error recovery information that identifies the reason that an abnormality is detected in the hypervisor 6 and an operation pattern that causes an abnormality of the hypervisor 6 .

Third embodiment

An electronic control unit and an abnormality detection method according to a third embodiment of the present invention will be described. The third embodiment is different 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 of the first embodiment are denoted by the same reference numerals and will be omitted from further description.

<Configuration>

17 illustrates a hardware configuration of the electronic control unit according to the third embodiment.

<Peripheral device 2>

In this embodiment, the shared peripheral device 201 includes the digital output port 2011 and a CAN controller 2012, the first peripheral device 202 includes the analog output port 2021, and the second peripheral device 203 includes the digital input port 2031.

18 represents a software configuration of the electronic control unit according to the third embodiment. Pieces of software included in 18 is shown are stored in memory 3.

<Software configuration>

The first virtual machine 7 includes the first guest operating system 9, the first control software application 10, the virtual driver 11, the peripheral access request recording program 19, the analog output port driver 12 and a virtual CAN driver 21. The second virtual machine 8 contains the second guest operating system 13, the second control software application 15, the virtual driver 11, the digital input port driver 14 and a virtual CAN driver 21.

<First virtual machine 7>

The operation of software in the first virtual machine 7 is described. When the hypervisor 6 configures the first virtual machine 7, the first virtual machine 7 activates the first guest operating system 9. The first guest operating system 9 activates the first control software application 10. The first control software application 10 uses the digital output port 2011 and the CAN control unit 2012, which forms the shared peripheral device 201, and the analog output port 2021, which is the first peripheral device 202.

19 Fig. 12 illustrates an overview of a process flow executed when the first control software application 10 of the third embodiment uses the CAN controller 2012, which is the shared peripheral device 201.

<Access from the first virtual machine 7 to the CAN control unit 2012>

To access the CAN controller 2012, which is the shared peripheral device 201, the first control software application 10 uses the virtual CAN driver 21, the hypervisor 6 and a CAN driver 22. Specifically, the first control software calls Application 10 calls the virtual CAN driver 21 by setting an identifier assigned in accordance with a CAN message protocol and data to be sent to a CAN frame as parameters, the call being made as a peripheral access request . The virtual CAN driver 21 executes a process of changing a processing context of the CPU 1 from the first virtual machine 7 to the hypervisor 6 (the process is generally referred to as VMExit). The hypervisor 6 checks a usage status of the CAN controller 2012. If it is determined that the second virtual machine 8 is not using the CAN controller 2012, the hypervisor 6 calls the CAN driver 22 to access the CAN controller 2012 by setting the Identifier and data as the parameters. When it is determined that the second virtual machine 8 is using the CAN controller 2012, the hypervisor 6 stores the identifier and data in the buffer provided in the hypervisor 6 and stands by, taking the identifier and data from the buffer , after the second virtual machine 8 completes the use of the CAN controller 2012, and then calls the CAN driver 22 by appending the extracted parameter to the call.

The CAN driver 22 accesses a register of the CAN controller 2012, stores the identifier and data in a CAN frame, and sends the CAN frame over a CAN communication bus, and then sends a response indicating normal completion, back to the hypervisor 6. Upon receipt of the response indicating normal completion from the CAN driver 22, the hypervisor 6 executes a process of changing the processing context of the CPU 1 from the hypervisor 6 to the first virtual machine 7 (which process is generally referred to as VMEntry). When information indicating normal completion is received from the hypervisor 6, the virtual CAN driver 21 sends a response indicating normal completion back to the first control software application 10.

20 represents a CAN ledger 57 of the third embodiment.

<CAN ledger 57>

The CAN ledger 57 held in the CAN driver 22 contains information about a message identifier for identifying each CAN frame, about data contents representing the contents of data contained in the CAN frame, about whether the CAN frame is sent or whether the CAN frame is received, and about a data length in the CAN frame. In this embodiment, CAN frames with identifiers in the range 0 to 2000 are used for conventional control processes and are sent to or received from the CAN communication bus. In a CAN frame with a message identifier 9900, a set of a status check time, a process destination and a register value specified in the peripheral status record information 54 is stored as 8 byte data and information about whether the CAN frame that is sent or the CAN frame that is received is entered as “Transmission to Monitoring Unit”.

<CAN driver 22>

The CAN driver 22 operates a register of the CAN controller 2012 according to information entered into the CAN ledger 57. Specifically, the CAN driver 22 receives by operating the register of the CAN controller 2012 8 byte data of a CAN frame with a message identifier 0 from the CAN communication bus as a vehicle speed, sends by operating the register of the CAN controller 2012 8 byte data of a CAN frame with a message identifier 1 to the CAN communication bus as engine speed and sends 8 byte data of a CAN frame with a message identifier 2 to the CAN communication bus as throttle opening degree by operating the register of the CAN control unit 2012.

With regard to data of a CAN frame with a message identifier 9900, the information about whether to be sent or received is entered into the CAN ledger 57 as "transmission to the monitoring unit", the CAN driver 22 does not operate the register of the CAN control unit 2012, but writes the data to a memory area that the hypervisor monitoring program 17 can refer to. Since it exists outside the first virtual machine 7 and the hypervisor 6, the CAN driver 22 does not receive the reference of a limit to a reference space in the memory area arranged by the hypervisor 6. In addition, using a peripheral device (a digital output port 2011) used for monitoring the hypervisor 6 and another peripheral device (the CAN controller 2012) enables the hypervisor 6 to store the peripheral access record information 53 in the memory area to which the hypervisor monitoring program 17 can refer if an anomaly occurs during the operation of the digital output port 2011.

According to this embodiment, even in a case where access from inside the virtual machine configured by the hypervisor 6 to the outside of the virtual machine is prohibited, and hence the peripheral access request recording program 19 cannot record the peripheral access recording information 53 to the memory area , to which the hypervisor monitor program 17 can refer, the peripheral access record information 53 is taken from the first virtual machine 7 and written to the memory area to which the hypervisor monitor program 17 can refer.

Fourth embodiment

An electronic control unit and an abnormality detection method according to a fourth embodiment of the present invention will be described. The fourth embodiment is different from the second embodiment in that the electronic control unit is turned off when a failure of the hypervisor 6 is detected at a frequency equal to or greater than a given value. The same components as those of the second embodiment are denoted by the same reference numerals and will be omitted from further description.

21 illustrates an overview of a process flow of a monitoring result storage program 20 of the fourth embodiment.

<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 determination state information 55 in a non-volatile memory area in the memory 3 of the microcomputer 900, calculates the occurrence frequency of anomalies in the hypervisor 6, and then switches when the calculated occurrence frequency of anomalies is equal to or greater than a given threshold value, the electronic control unit 0.

<Step S5>

In step S5, the monitoring result storage program 20 stores the peripheral access record information 53, the peripheral state record information 54 and the peripheral determination state information 55 in the non-volatile memory area in the memory 3 of the microcomputer 900.

<Step S6>

In step S6, the monitoring result storage program 20 calculates a time at which an abnormality occurred in the hypervisor 6. Because it is difficult to determine the time at which the abnormality actually occurred in the hypervisor 6 from outside the hypervisor 6, a time indicated in the peripheral state record information 54 and the peripheral determination state information 55, the time by taking the hypervisor monitoring program 17 as a basis for determining the occurrence of an anomaly in the hypervisor 6, the time at which the anomaly occurred in the hypervisor 6 is determined. Specifically, as in the peripheral state recording information 54 and the peripheral determination state information 55 shown in 14 The time at which the anomaly occurred in the hypervisor 6 is calculated as 00:32:10. The monitoring result storage program 20 stores the calculated time, that is, 00:32:10 in hypervisor anomaly occurrence time information 58.

22 illustrates an example of the hypervisor anomaly occurrence time information 58 of the fourth embodiment.

<Hypervisor anomaly occurrence time information 58>

The hypervisor abnormality occurrence time information 58 stores information about a time calculated in step S6 of the monitoring result storage program 20 of the electronic control unit of the fourth embodiment.

<Hypervisor anomaly occurrence frequency condition 59>

A hypervisor abnormality occurrence frequency condition 59 is a condition for shutting down the electronic control unit 0. In this embodiment, this condition sets an abnormality of the hypervisor 6 detected twice in a period of 10:00 as a shutdown condition.

23 is a diagram schematically showing an overview of a process executed in step S7 of the monitoring result storage program 20 of the fourth embodiment.

<Step S7>

In step S7, the monitoring result storage program 20 calculates the occurrence frequency of anomalies in the hypervisor 6. Since the hypervisor anomaly occurrence frequency condition 59 sets the occurrence frequency of anomalies in the hypervisor 6 in the period 10:00 as a shutdown condition, records of a hypervisor anomaly occurrence time in the period 10:00, that extends backwards from the most recent anomaly occurrence time. This process is described with reference to 23 described. At point 50:25, the most recent anomaly occurrence time is 47:10 and is the occurrence number of anomalies in the 10:00 period extending backwards from 47:10, that is, in the period between 37:10 and 47:10, according to the hypervisor anomaly occurrence time Information 58 1 and therefore the frequency in the time period is determined as 1. At point 54:35, the most recent anomaly occurrence time is 52:10 and is the occurrence number of anomalies in the 10:00 period extending backwards from 52:10, that is, in the period between 42:10 and 52:10 according to the hypervisor anomaly occurrence time information 58 2 and therefore the frequency in the time period is determined as 2.

<Step S8>

In step S8, if the anomaly occurrence frequency determined in step S7 is equal to or greater than a threshold frequency defined by the hypervisor anomaly occurrence frequency condition 59, the monitoring result storage program 20 proceeds to step S9. Otherwise, the monitoring result storage program 20 skips a step S9 and ends the process flow.

<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. As a result, the power supply circuit 901 stops supplying power to the microcomputer 900, which turns off the electronic control unit 0. The electronic control unit 0 is partially switched off or completely switched off.

According to this embodiment, when the detection frequency of abnormalities in the hypervisor 6 is low, the electronic control unit is kept in operation to prevent influences on the electronic control unit and a vehicle in which the electronic control unit is accommodated. On the other hand, when the detection frequency of abnormalities in the hypervisor 6 is high, the electronic control unit is shut down to influence the anomalies that have occurred in the hypervisor 6 on the safety of the electronic control unit and the vehicle in which the electronic control unit is incorporated , exercise, reduce. Therefore, both usability and security can be ensured.

The present invention is not limited to the embodiments described above and includes various modifications and configurations corresponding to the embodiments included within the scope of the appended claims. For example, the embodiments described above have been described in detail to facilitate understanding of the present invention, and the present invention is not necessarily limited to an embodiment containing all of the components described above. Certain components of a particular embodiment may be replaced by components of a further embodiment. A component of another embodiment may be added to a component of a particular embodiment. Some components of each embodiment may be removed or added to or replaced with components of another embodiment.

Some or all of the components, functions, processing units, process means and the like described above may be in the form of hardware by packaging them in an integrated circuit or in the form of software by causing a processor to interpret and execute programs that implement respective functions. be provided.

Information about programs, tables, files and the like for implementing various functions can be stored in a storage device such as. B. a memory, a hard drive and a solid state drive (SSD) or in a recording medium such as. B. an IC card, an SD card and a DVD.

A group of control lines and data lines deemed necessary for description are illustrated, and not necessarily all control lines and data lines needed for configuration are illustrated. One can assume that almost all components are actually connected.

QUOTES INCLUDED IN THE DESCRIPTION

This list of documents listed by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• JP 202180743 [0001]
• JP 2019144785 A [0003]
• JP 2014106587 A [0003]

Claims (8)

Electronic control unit, which includes: a virtual machine accessing a first virtual driver to execute a process; a hypervisor that invokes a first real driver of a first peripheral device based on a peripheral access request received from the first virtual driver; an access recording unit that calls the first virtual driver to record a peripheral access request sent to the hypervisor; a state recording unit that calls the first real driver to record a state of a register of the first peripheral device; and a monitoring unit that monitors operation of the hypervisor, wherein the monitoring unit determines an anomaly of the hypervisor based on a recording by the access recording unit and a recording by the state recording unit. Electronic control unit Claim 1 , wherein when a recording by the access recording unit and a recording by the state recording unit do not match, the monitoring unit determines that the hypervisor is in an abnormal state. Electronic control unit Claim 2 , wherein the state recording unit repeatedly records a state of the register in a given period of time. Electronic control unit Claim 2 , wherein the monitoring unit determines that the hypervisor is in an abnormal state when there is a record of an access request in the access recording unit, a record of a process result of the real driver that has been sent back to the virtual driver as a response indicating normal completion is, is present, and a state of a register of the state recording unit does not change. Electronic control unit Claim 1 , which includes a monitoring result storage unit that, when the monitoring unit determines an anomaly, stores a record by the access recording unit and a record by the state recording unit in a non-volatile memory. Electronic control unit Claim 5 , wherein when a frequency of determining that the hypervisor is in an abnormal state is equal to or greater than a given threshold, the monitoring result storage unit partially or completely brings the electronic control unit to a stop. Electronic control unit Claim 1 , comprising: a second peripheral device different from the first peripheral device; and a second real driver for operating the second peripheral device, the second peripheral device following a command from the second real driver outputting a recording by the access recording unit to outside the virtual machine and the monitoring unit relating to the recording by the access recording unit, the recording being sent to outside of the virtual machine. Anomaly determination method for a hypervisor operating in an electronic control unit, the electronic control unit including: a virtual machine accessing a first virtual driver to execute a process; the hypervisor invoking a first real driver of a first peripheral device based on a peripheral access request received from the first virtual driver; an access recording unit that calls the first virtual driver to record a peripheral access request sent to the hypervisor; a state recording unit that calls the first real driver to record a state of a register of the first peripheral device; and a monitoring unit that monitors operation of the hypervisor, and the anomaly determination method includes: causing the state recording unit to invoke the first real driver and record a state of a register of the first peripheral device; and Cause the monitoring unit to determine an anomaly of the hypervisor based on a recording by the access recording unit and a recording by the state recording unit.

Images