WO2022239331A1 - 電子制御装置及び異常判定方法 - Google Patents

電子制御装置及び異常判定方法 Download PDF

Info

Publication number
WO2022239331A1
WO2022239331A1 PCT/JP2022/004527 JP2022004527W WO2022239331A1 WO 2022239331 A1 WO2022239331 A1 WO 2022239331A1 JP 2022004527 W JP2022004527 W JP 2022004527W WO 2022239331 A1 WO2022239331 A1 WO 2022239331A1
Authority
WO
WIPO (PCT)
Prior art keywords
hypervisor
peripheral
electronic control
driver
recording unit
Prior art date
Application number
PCT/JP2022/004527
Other languages
English (en)
French (fr)
Inventor
将史 溝口
朋仁 蛯名
一 芹沢
健一 長田
祐 石郷岡
毅 福田
Original Assignee
日立Astemo株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日立Astemo株式会社 filed Critical 日立Astemo株式会社
Priority to US18/559,513 priority Critical patent/US20240241747A1/en
Priority to DE112022001480.6T priority patent/DE112022001480T5/de
Publication of WO2022239331A1 publication Critical patent/WO2022239331A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support

Definitions

  • the present invention relates to an electronic control device.
  • a hypervisor By using a hypervisor, multiple control software applications that run on different OSs (Operating Systems) can be installed on a single microcomputer.
  • Techniques for monitoring a hypervisor include the techniques described in JP-A-2019-144785 (Patent Document 1) and JP-A-2014-106587 (Patent Document 2).
  • Patent Document 1 a monitoring virtual machine used for monitoring a plurality of monitoring targets including virtualization software is arranged on virtualization software, and a predetermined test is executed by the monitoring virtual machine at predetermined intervals.
  • a monitoring program for outputting a determination result of the presence or absence of an abnormality in a virtual machine and predetermined states of a plurality of monitoring targets.
  • Patent Document 2 discloses a method for sharing an I/O device between a hypervisor and a first guest OS, wherein the I/O device has a physical function and a virtual function, and the hypervisor uses the physical function.
  • the first guest OS has a virtual driver that utilizes virtual functions; the hypervisor obtains the state of the I/O device via the physical driver; , the hypervisor is monitored, and when a predetermined state is reached, a sub-physical driver that operates an I/O device is activated, and the first guest OS performs transmission and reception via a queue preset on the memory.
  • a method for controlling /O devices is described.
  • Virtualization software called a hypervisor is used in an electronic control device that integrates multiple control software applications running on different OSs into a single microcomputer (hardware).
  • a hypervisor provides a virtual machine as an environment for operating an OS and control software applications.
  • a virtual machine is a CPU (Central Processing Unit) on a microcomputer, a memory area, and access rights to peripherals such as CAN (Controller Area Network) controllers and A/D (Analog/Digital) converters installed on the microcomputer. It is a unit that From the viewpoint of the guest OS and control software applications in each virtual machine, it is logically equivalent to the existence of CPUs, memory areas and peripherals to which no access authority has been granted on separate microcomputers.
  • the hardware and software that make up the electronic control device are operating normally and no abnormalities have occurred during the operation of the electronic control device. monitoring is required.
  • an electronic control device using a hypervisor it is required to monitor the operation of the hypervisor.
  • a monitoring virtual machine is installed as a virtual machine, and the monitoring virtual machine periodically executes a test pattern, acquires the internal state (normal/abnormal) of the hypervisor, and executes the test. Based on the execution result of the pattern and the acquisition result of the internal state of the hypervisor, it is possible to specify whether or not an abnormality has occurred in the electronic control unit, and if an abnormality has occurred, the extent of influence of the abnormality can be specified.
  • the monitoring of the hypervisor 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 it is not determined to be correct, and normal operation of the hypervisor is not guaranteed. In addition, since it is necessary to obtain the internal state of the hypervisor, it cannot be applied to third-party hypervisors whose internal state is not disclosed.
  • a counter (watchdog timer) is installed in the hypervisor, and a requirement is imposed to count up or count down the counter within a predetermined period, and if the counter is not updated within the predetermined period, A method for determining that an abnormality has occurred in the hypervisor is described. This makes it possible to detect unexpected shutdowns of the hypervisor, deadlocks and livelocks occurring in the hypervisor. However, in order to apply this method, it is necessary to impose requirements on the hypervisor for updating the counters. In addition, since the watchdog timer count update process is generally set to have a high priority, the priority of the counter update process inside the hypervisor is higher than the processing priority of tasks causing deadlocks or livelocks. , the deadlock and the livelock cannot be detected.
  • the purpose of the present invention is to monitor the hypervisor and detect abnormalities that occur in the hypervisor, based only on the inputs and outputs of the hypervisor whose internal logic is not disclosed, such as those manufactured by third parties.
  • the electronic control device includes a virtual machine that accesses a first virtual driver and executes processing, and a first virtual machine of the first peripheral based on a peripheral access request received from the first virtual driver.
  • a hypervisor that calls a real driver; an access recording unit that calls the first virtual driver and records a peripheral access request sent to the hypervisor; and a monitoring unit for monitoring the operation of the hypervisor. Determine the abnormality of the visor.
  • a hypervisor abnormality can be detected without accessing the hypervisor's internal state.
  • FIG. 4 is a diagram showing an overview of the processing flow when the first control software application of the first embodiment uses the first peripheral;
  • FIG. 10 is a diagram showing an overview of the processing flow when the first control software application of the first embodiment uses shared peripherals;
  • FIG. 10 is a diagram showing an example of peripheral access request information in the first embodiment;
  • FIG. 10 is a diagram showing an example of peripheral access result information according to the first embodiment;
  • FIG. 10 is a diagram showing an overview of the processing flow when the second control software application of the first embodiment uses the second peripheral;
  • FIG. 10 is a diagram showing an overview of the processing flow when the second control software application of the first embodiment uses shared peripherals;
  • FIG. 10 is a diagram showing an example of peripheral access record information in the first embodiment;
  • FIG. FIG. 4 is a diagram showing an example of peripheral state record information of the first embodiment;
  • FIG. 4 is a diagram showing an overview of the processing flow of the hypervisor monitoring program of the first embodiment;
  • FIG. 4 is a diagram showing an example of peripheral desired state information of the first embodiment;
  • FIG. FIG. 4 is a diagram schematically showing processing for generating peripheral desired state information in step S1 of the hypervisor monitoring program of the first embodiment;
  • FIG. 4 is a diagram schematically showing processing for generating peripheral desired state information in step S1 of the hypervisor monitoring program of the first embodiment; It is a figure which shows the software structure of the electronic controller of a 2nd Example.
  • FIG. 11 is a diagram showing an overview of the processing flow of the hypervisor monitoring program of the second embodiment; It is a figure which shows the hardware constitutions of the electronic controller of a 3rd Example. It is a figure which shows the software structure of the electronic controller of a 3rd Example.
  • FIG. 11 is a diagram showing a processing flow outline when the first control software application of the third embodiment uses the shared peripheral CAN controller; It is a figure which shows the CAN ledger of a 3rd Example.
  • FIG. 20 is a diagram showing an overview of the processing flow of a monitoring result storage program of the fourth embodiment
  • FIG. 21 is a diagram showing an example of hypervisor failure occurrence time information according to the fourth embodiment
  • FIG. 13 is a diagram schematically showing an outline of processing in step S7 of the monitoring result saving program of the fourth embodiment
  • This embodiment relates to an electronic control device, and more particularly to an electronic control device in which multiple control software applications are integrated on one microcomputer.
  • FIG. 1 is a diagram showing the hardware configuration of the electronic control unit of the first embodiment.
  • the electronic control device of this embodiment will be described with reference to FIG.
  • the electronic control unit 0 has a microcomputer 900 and a power supply circuit 901 .
  • a microcomputer 900 includes a CPU (Central Processing Unit) 1 that performs arithmetic processing, a peripheral device group 2 mounted on the electronic control unit 0, a memory 3 that stores software, and a CPU 1 that connects the peripheral 2 and the memory 3 to the CPU 1. It consists of a bus 4 that allows access to the peripherals 2 and the memory 3 from.
  • CPU Central Processing Unit
  • a power input terminal of the microcomputer 900 is connected to the power supply circuit 901 .
  • the microcomputer 900 is activated when receiving power supply from the power supply circuit 901 .
  • 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 .
  • the CPU 1 has two cores, a first CPU core 101 and a second CPU core 102 .
  • the number of CPU cores is two, but the number of CPU cores is not limited to this, and may be, for example, one or three or more.
  • the peripheral 2 is a device that inputs and outputs data and signals inside or outside the microcomputer 900, and includes a first control software application 10 (that is, the first CPU core 101) and a second control software application 15 (that is, the second A shared peripheral 201 accessed by both the CPU core 102 of the first control software application 10 (i.e., the first CPU core 101) and a first peripheral 202 accessed by only the first control software application 10 (i.e., the first CPU core 101) and a second peripheral 203 that is accessed only by 15 (ie, the second CPU core 103).
  • Peripheral 2 is a general name for peripheral circuits other than the CPU 1 and the memory 3 mounted on the microcomputer 900. Specifically, a CAN (Controller Area Network) controller mounted on the microcomputer 900, an analog/digital/ Includes converters, direct memory access controllers, GPIO (General Purpose Input/Output), and more.
  • a CAN Controller Area Network
  • the memory 3 includes ROM, which is a non-volatile storage element, and RAM, which is a volatile storage element.
  • the ROM stores immutable programs (eg, BIOS) and the like.
  • the RAM is a high-speed and 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.
  • shared peripheral 201 includes digital output port 2011
  • first peripheral 202 includes analog output port 2021
  • second peripheral 203 includes digital input port 2031 .
  • FIG. 2 is a diagram showing the software configuration of the electronic control unit of the first embodiment.
  • the software shown in FIG. 2 is stored in memory 3 .
  • a host OS (Operating System) 5 is mounted on the microcomputer 900 .
  • the host OS 5 activates the hypervisor 6 , the hypervisor monitoring program 17 and the register value acquisition program 18 .
  • the hypervisor 6 is booted according to a boot method defined by the hypervisor 6 .
  • the hypervisor monitoring program 17 and the register value acquisition program 18 are activated at intervals of 5 milliseconds to acquire information for monitoring. For the sake of simplification, the activation period is set to 5 milliseconds in this embodiment.
  • the hypervisor 6 may be composed of software executed on the host OS 5 or may be composed of hardware implemented in the microcomputer 900 .
  • the hypervisor 6 configures the first virtual machine 7 and the second virtual machine 8 according to a method defined by the hypervisor 6 and starts them respectively.
  • 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.
  • the first virtual machine 7 the first guest OS 9, the first control software application 10, the virtual driver 11, the peripheral access request recording program 19, and the analog output port driver 12 are executed.
  • 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 as well. That is, at least one peripheral access request recording program 19 needs to be executed on the hypervisor 6 .
  • First Virtual Machine 7 Operation of software in the first virtual machine 7 will be described.
  • the hypervisor 6 configures the first virtual machine 7
  • the first virtual machine 7 boots the first guest OS 9 .
  • a first guest OS 9 launches a first control software application 10 .
  • the first control software application 10 uses the shared peripheral 201 , the digital output port 2011 , and the first peripheral 202 , the analog output port 2021 .
  • FIG. 3 is a diagram showing an overview of the processing flow when the first control software application 10 uses the first peripheral 202.
  • FIG. 3 is a diagram showing an overview of the processing flow when the first control software application 10 uses the first peripheral 202.
  • Analog output port driver 12 is used to access analog output port 2021 , which is first peripheral 202 , from first control software application 10 . That is, when the first control software application 10 calls the analog output port driver 12 specifying 5 V as an argument as a peripheral access request, the analog output port driver 12 accesses the register of the analog output port 2021 and outputs the output voltage value. 5V is set in a predetermined register of the microcomputer 900, and normal termination is returned to the first control software application 10. FIG.
  • FIG. 4 is a diagram showing an overview of the processing flow when the first control software application 10 uses the shared peripheral 201.
  • FIG. 4 is a diagram showing an overview of the processing flow when the first control software application 10 uses the shared peripheral 201.
  • the peripheral access request recording program 19 In order to access the digital output port 2011 which is the shared peripheral 201 from the first control software application 10, 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 designates H as an argument and calls the peripheral access request recording program 19 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 designating H as an argument.
  • the virtual driver 11 executes a process (generally called VMExit) to change the processing context of the CPU 1 from the first virtual machine 7 to the hypervisor 6 .
  • the hypervisor 6 confirms the usage status of the digital output port 2011 .
  • the hypervisor 6 calls the digital output port driver 16 for accessing the digital output port 2011 with an argument of H unless 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. After the end of use, the argument H is extracted from the buffer, and the digital output port driver 16 is called with the extracted argument.
  • 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. do.
  • the hypervisor 6 receives a normal completion return from the digital output port driver 16, it executes processing (generally called VMEntry) for changing the processing context of the CPU 1 from the hypervisor 6 to the first virtual machine 7. do.
  • the virtual driver 11 receives normal termination 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 normal termination to the first control software application 10 .
  • FIG. 5 is a diagram showing an example of peripheral access request information 51 by the 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 to which access was requested by the call, and the peripheral added in the call. Contains argument information.
  • FIG. 6 is a diagram showing an example of peripheral access result information 52 for the 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 returns information to the effect that normal processing has been completed to the virtual driver 11, and information on the peripheral processed by the hypervisor 6. and the information of the processing result.
  • FIG. 7 is a diagram showing an overview of the processing flow when the second control software application 15 uses the second peripheral 203.
  • FIG. 7 is a diagram showing an overview of the processing flow when the second control software application 15 uses the second peripheral 203.
  • the digital input port driver 14 is used to access the digital input port 2031, which is the second peripheral 203, from the second control software application 15.
  • FIG. 8 is a diagram showing an overview of the processing flow when the second control software application 15 uses the shared peripheral 201.
  • FIG. 8 is a diagram showing an overview of the processing flow when the second control software application 15 uses the shared peripheral 201.
  • 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) to change the processing context of the CPU 1 from the second virtual machine 8 to the hypervisor 6 .
  • the hypervisor 6 confirms the usage status of the digital output port 2011 . That is, the hypervisor 6 calls the digital output port driver 16 to access the digital output port 2011 with an argument of H unless the first virtual machine 7 is using the digital output port 2011 .
  • the argument H is stored in a buffer prepared inside the hypervisor 6 and waits. After the end of use, the argument H is extracted from the buffer, and the digital output port driver 16 is called with the extracted argument.
  • 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. do.
  • the hypervisor 6 receives a normal completion return from the digital output port driver 16, it executes processing (generally called VMEntry) for changing the processing context of the CPU 1 from the hypervisor 6 to the first virtual machine 7. do.
  • processing generally called VMEntry
  • the virtual driver 11 receives normal termination information from the hypervisor 6 , the virtual driver 11 returns normal termination to the first control software application 10 .
  • 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 a peripheral access request, as shown in FIG. Also, as shown in FIG. 4, the peripheral access request recording program 19 writes the 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 virtual driver 11 has completed normal termination. to generate Furthermore, the peripheral access request recording program 19 is repeatedly started by the first guest OS 9 at a predetermined timing (for example, in a cycle of 100 milliseconds). Peripheral access record information 53 is generated by integrating the peripheral access result information 52 for the software application 10, and the peripheral access record information 53 is written in a memory area that can be referenced by the hypervisor monitoring program 17. FIG.
  • FIG. 9 is a diagram showing an example of the peripheral access record information 53.
  • FIG. 9 is a diagram showing an example of the 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 access is requested by the request, the information of the argument added in the request, and the peripheral access request record program 19. It includes the time when the hypervisor 6 sent the information that the processing was completed normally to the virtual driver 11 in accordance with the request, and the information of the processing result by the hypervisor 6 .
  • the register value acquisition program 18 is repeatedly started by the host OS 5 at a predetermined timing (for example, every 5 milliseconds).
  • the register value acquisition program 18 calls the digital output port driver 16 each time it is started, acquires the value of a predetermined register of the microcomputer 900 representing the state of the digital output port 2011 which is the shared peripheral 201, and stores the peripheral state recording information 54. , and writes the generated peripheral state record information 54 to a memory area that 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 as well.
  • FIG. 10 is a diagram showing an example of the peripheral state record information 54.
  • FIG. 10 is a diagram showing an example of the peripheral state record information 54.
  • the peripheral state record information 54 includes information on the peripheral to be processed by the register value acquisition program 18, the time at which the register value acquisition program 18 called the peripheral (digital output port driver 16), and the value of the register acquired by the call. include.
  • FIG. 11 is a diagram showing an overview of the processing flow of the hypervisor monitoring program 17.
  • FIG. 11 is a diagram showing an overview of the processing flow of the 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 the value that the register value should take does not match the peripheral state record information 54, the hypervisor 6 is abnormal. is determined to have occurred.
  • step S ⁇ b>1 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 .
  • step S2 the hypervisor monitoring program 17 compares the peripheral state recording information 54 and the desired peripheral state information 55 to determine whether the state of the hypervisor 6 is normal or abnormal.
  • FIG. 12 is a diagram showing an example of peripheral desired state information 55.
  • FIG. 12 is a diagram showing an example of peripheral desired state information 55.
  • the peripheral desired state information 55 includes the time when the register value acquisition program 18 calls the digital output port driver 16 and the value information of the peripheral register at the time calculated based on the peripheral access record information 53 .
  • FIG. 13 is a diagram schematically showing the peripheral desired state information generation processing in step S1 of the hypervisor monitoring program 17.
  • the first control software application 10 sent a peripheral access request with an argument of H at 10:00.
  • the value of the register is set to H at any time between 10:00 and 16:00 according to the hypervisor response time information of the peripheral access record information 53. is calculated as
  • the first control software application 10 sent a peripheral access request with an argument of L at time 25:00.
  • the value of the register is set to L at any time between 25:00 and 32:00 according to the hypervisor response time information of the peripheral access record information 53. is calculated as
  • peripheral desired state information 55 is generated as shown in FIG. That is, at time 12:10, either the initial value, which is an undefined value, is maintained, or it is H according to the peripheral access request transmitted at time 10:00, and the value of the register is H or L. You can take either. At time 17:10 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, the register value continues to be either H or L according to the peripheral access request at time 25:00, and the register value is either H or L. obtain. At time 32:10 after time 32:00, the register value is L, and at time 37:10, the register value is L.
  • FIG. 14 is a diagram schematically showing the peripheral desired state information generation processing in step S1 of the hypervisor monitoring program 17.
  • step S2 the hypervisor monitoring program 17 compares the peripheral desired state information 55 with the peripheral state recording information 54, and records the value of the peripheral register at each time calculated by the peripheral desired state information 55 in the peripheral state recording information 54. If it is different from the value of the registered register, it is determined that an abnormality has occurred in the hypervisor 6 . That is, in the case shown in FIG. 14, according to the peripheral desired state information 55, the register value should be L at time 32:10, but according to the peripheral state recording information 54, the actual register value is H. , an abnormality of the hypervisor 6 is detected.
  • the hypervisor 6 can detect the virtual machines 7 and 8 by recording changes in the register values of the microcomputer 900 operated by the hypervisor 6. It monitors from outside the hypervisor 6 whether or not the processes requested by the internal control software applications 10 and 15 are being executed correctly. Therefore, an abnormality of the hypervisor 6 can be detected based on the input and output of the hypervisor 6 without accessing the internal state of the hypervisor 6 . That is, even when the hypervisor 6 returns a normal process to the virtual machines 7 and 8, if the process is not actually performed normally, an abnormality of the hypervisor 6 can be detected.
  • the electronic control device and method of the 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 reference numerals are assigned to the same configurations as those of the first embodiment, and the description thereof will be omitted.
  • FIG. 15 is a diagram showing the software configuration of the electronic control unit of the second embodiment.
  • the software shown in FIG. 15 is stored in memory 3 .
  • a host OS 5 is installed on the microcomputer 900 .
  • the host OS 5 activates the hypervisor 6 , the hypervisor monitoring program 17 and the register value acquisition program 18 .
  • the host OS 5 repeatedly checks the value of the abnormality detection flag 56 at a predetermined timing (for example, every 5 milliseconds), and when it confirms that the abnormality detection flag 56 is True, sets the abnormality detection flag 56 to False. After rewriting, the monitoring result storage program 20 is activated.
  • the abnormality detection flag 56 is a variable that takes one of two values of True or False.
  • FIG. 16 is a diagram showing an overview of the processing flow of the hypervisor monitoring program 17.
  • step S3 the hypervisor monitoring program 17 branches the process depending on 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.
  • step S4 the hypervisor monitoring program 17 changes the value of the abnormality detection flag 56 to True, and terminates the process.
  • the monitoring result storage program 20 stores peripheral access record information 53 , peripheral state record information 54 and peripheral desired state information 55 in a non-volatile memory area inside the memory 3 of the microcomputer 900 .
  • the peripheral access record information 53, the peripheral state record information 54, and the peripheral desired state information 55 are stored as the reason why the hypervisor 6 has detected an abnormality and the abnormality in the hypervisor 6. It can be used as information for debugging to identify behavioral patterns that occur.
  • the electronic control device and method of the third embodiment of the present invention will be described.
  • the third embodiment differs from the first embodiment in that it uses another virtual driver to retrieve the peripheral access record information 53.
  • FIG. The same reference numerals are assigned to the same configurations as in the first embodiment, and the description thereof will be omitted.
  • FIG. 17 is a diagram showing the hardware configuration of the electronic control unit of the third embodiment.
  • shared peripheral 201 includes digital output port 2011 and CAN controller 2012
  • first peripheral 202 includes analog output port 2021
  • second peripheral 203 includes digital input port 2031 .
  • FIG. 18 is a diagram showing the software configuration of the electronic control unit of the third embodiment.
  • the software shown in FIG. 18 is stored in memory 3 .
  • 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.
  • a second virtual machine 8 includes a second guest OS 13 , a second control software application 15 , a virtual driver 11 , a digital input port driver 14 and a virtual CAN driver 21 .
  • First Virtual Machine 7 Operation of software in the first virtual machine 7 will be described.
  • the hypervisor 6 configures the first virtual machine 7
  • the first virtual machine 7 boots the first guest OS 9 .
  • a first guest OS 9 launches a first control software application 10 .
  • the first control software application 10 uses the shared peripheral 201 , the digital output port 2011 and the CAN controller 2012 , and the first peripheral 202 , the analog output port 2021 .
  • FIG. 19 is a diagram showing an overview of the processing flow when the first control software application 10 of the third embodiment uses the CAN controller 2012, which is the shared peripheral 201.
  • FIG. 19 is a diagram showing an overview of the processing flow when the first control software application 10 of the third embodiment uses the CAN controller 2012, which is the shared peripheral 201.
  • ⁇ Access from first virtual machine 7 to CAN controller 2012> In order to access the CAN controller 2012 which is the shared peripheral 201 from the first control software application 10, 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 as a peripheral access request, specifying an ID specified by the CAN message protocol and data to be transmitted in the CAN frame as arguments.
  • 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 confirms the usage status of the CAN controller 2012 .
  • the hypervisor 6 calls the CAN driver 22 to access the CAN controller 2012 by designating the ID and data as arguments.
  • the argument ID and data are stored in a buffer prepared inside the hypervisor 6, and the CAN controller 2012 is used by the second virtual machine 8. is completed, the argument ID and data are extracted from the buffer, and the CAN driver 22 is called with the extracted arguments.
  • 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 completion to the hypervisor 6.
  • the hypervisor 6 receives a normal end return from the CAN driver 22, the hypervisor 6 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.
  • VMEntry a process for changing the processing context of the CPU 1 from the hypervisor 6 to the first virtual machine 7.
  • FIG. When the virtual CAN driver 21 receives normal termination information from the hypervisor 6 , the normal termination is returned to the first control software application 10 .
  • FIG. 20 is a diagram showing the CAN ledger 57 of the third embodiment.
  • the CAN ledger 57 is held inside the CAN driver 22, and includes a message ID for identifying each CAN frame, the content of data included in the CAN frame, information on whether to transmit or receive the CAN frame, and information on whether to process the CAN frame. Contains data length information in the CAN frame.
  • CAN frames with IDs 0 through 2000 are used for normal control processing and are sent to or received from the CAN communication bus.
  • a set of state confirmation time, processing target, and register value in the peripheral state record information 54 is stored as 8-byte data, and information on transmission/reception of the CAN frame is described as monitoring unit transmission. .
  • the CAN driver 22 operates registers of the CAN controller 2012 according to information described in the CAN ledger 57 . That is, the 8-byte data of message ID0 is received from the CAN communication bus as the vehicle speed by manipulating the register of the CAN controller 2012, and the 8-byte data of message ID1 is manipulated by manipulating the register of the CAN controller 2012 to obtain the engine speed. The 8-byte data of the message ID2 is transmitted to the CAN communication bus as the throttle opening by manipulating the register of the CAN controller 2012 .
  • the CAN driver 22 can refer to the data of the message ID 9900 whose transmission/reception type is the monitoring unit transmission in the CAN ledger 57 without operating the register of the CAN controller 2012, and the hypervisor monitoring program 17 can refer to it. Write the data in the memory area. Since the CAN driver 22 exists outside the first virtual machine 7 and the hypervisor 6, it is not affected by the hypervisor 6's restriction on the reference area of the memory area. In addition, by using a peripheral (the digital output port 2011) used for monitoring the hypervisor 6 and another peripheral (the CAN controller 2012), the hypervisor 6 can be Also, the peripheral access record information 53 can be stored in a memory area that the hypervisor monitoring program 17 can refer to.
  • the peripheral access request recording program 19 stores the peripheral access recording information 53 in a memory in which the hypervisor monitoring program 17 can refer. Even if writing to the area is impossible, the peripheral access record information 53 can be taken out of the first virtual machine 7 and written to a memory area that can be referenced by the hypervisor monitoring program 17 .
  • the electronic control device and method of the fourth embodiment of the present invention will be described.
  • the fourth embodiment differs from the second embodiment in that the electronic control unit is shut down when failure of the hypervisor 6 is detected at a frequency equal to or greater than a predetermined value. It should be noted that the same reference numerals are given to the same configurations as those of the second embodiment, and the description thereof will be omitted.
  • FIG. 21 is a diagram showing an overview of the processing flow of the monitoring result storage program 20 of the fourth embodiment.
  • 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, and calculates the frequency of occurrence of abnormalities in the hypervisor 6. , the electronic control unit 0 is shut down when the calculated abnormality occurrence frequency is equal to or greater than a predetermined threshold.
  • step S5 the monitoring result saving program 20 saves the peripheral access record information 53, the peripheral state record information 54, and the peripheral desired state information 55 in the internal non-volatile memory area of the memory 3 of the microcomputer 900.
  • FIG. 1 the monitoring result saving program 20 saves the peripheral access record information 53, the peripheral state record information 54, and the peripheral desired state information 55 in the internal non-volatile memory area of the memory 3 of the microcomputer 900.
  • step S ⁇ b>6 the monitoring result storage program 20 calculates the time when the hypervisor 6 became abnormal. Since it is difficult to specify from outside the hypervisor 6 the time when the abnormality actually occurred in the hypervisor 6, the hypervisor monitoring program 17 determines that the abnormality has occurred in the hypervisor 6 as the time when the abnormality occurred.
  • the time described in the peripheral state recording information 54 and the peripheral desired state information 55 used as the basis is set as the time when the hypervisor 6 malfunctions. That is, when the peripheral state recording information 54 and the peripheral desired state information 55 are as shown in FIG. 14, the time at which the hypervisor 6 failed is calculated as time 00:32:10.
  • the monitoring result saving program 20 saves this time in the hypervisor failure occurrence time information 58 .
  • FIG. 22 is a diagram showing an example of the hypervisor failure occurrence time information 58 of the fourth embodiment.
  • the hypervisor abnormality occurrence time information 58 stores the information of the time calculated in step S6 of the monitoring result saving program 20 of the electronic control unit of the fourth embodiment.
  • 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 10:00.
  • FIG. 23 is a diagram schematically showing the outline of the processing in step S7 of the monitoring result saving program 20 of the fourth embodiment.
  • the monitoring result storage program 20 calculates the frequency of occurrence of abnormalities in the hypervisor 6 in step S7. Since the hypervisor failure occurrence frequency requirement 59 stipulates that the failure frequency of the hypervisor 6 occurs within 10:00 hours, the hypervisor failure occurrence times within 10:00 hours preceding the latest failure occurrence time. Calculate the number of recordings of Description will be made with reference to FIG. At time 50:25, the latest error occurrence time is 47:10, and the number of occurrences between 37:10 and 47:10 is the hypervisor error occurrence time. Since it is once according to the information 58, the frequency is calculated to be once.
  • the latest error occurrence time is 52:10, and the number of occurrences from time 10:00 going back from this time, that is, between time 42:10 and time 52:10 is the hypervisor error occurrence. Since it is two times according to the time information 58, the frequency is calculated to be two times.
  • step S8 the monitoring result storage program 20 proceeds to step S9 if the abnormality occurrence frequency calculated in step S7 is equal to or greater than the value specified by the hypervisor abnormality occurrence frequency requirements 59, otherwise skips step S9. End the leverage process.
  • step S9> the monitoring result storage program 20 outputs a reset signal from the self-reset output terminal of the microcomputer 900 .
  • the power supply circuit 901 stops supplying power to the microcomputer 900, and the electronic control unit 0 shuts down.
  • the stop range of the electronic control unit 0 may be part or all of it.
  • the operation of the electronic control device is continued to suppress the influence on the electronic control device and the vehicle in which the electronic control device is mounted. If the hypervisor 6 detects an abnormality frequently, the electronic control unit is shut down to prevent the abnormality occurring in the hypervisor 6 from affecting the safety of the electronic control unit and the vehicle in which the electronic control unit is mounted. can be reduced, and both availability and safety can be achieved.
  • the present invention is not limited to the above-described embodiments, and includes various modifications and equivalent configurations within the scope of the attached claims.
  • the above-described embodiments have been described in detail for easy understanding of the present invention, and the present invention is not necessarily limited to those having all the described configurations.
  • part of the configuration of one embodiment may be replaced with the configuration of another embodiment.
  • the configuration of another embodiment may be added to the configuration of one embodiment.
  • additions, deletions, and replacements of other configurations may be made to a part of the configuration of each embodiment.
  • each configuration, function, processing unit, processing means, etc. described above may be realized by hardware, for example, by designing a part or all of them with an integrated circuit, and the processor realizes each function. It may be realized by software by interpreting and executing a program to execute.
  • Information such as programs, tables, and files that implement each function can be stored in storage devices such as memory, hard disks, SSDs (Solid State Drives), or recording media such as IC cards, SD cards, and DVDs.
  • storage devices such as memory, hard disks, SSDs (Solid State Drives), or recording media such as IC cards, SD cards, and DVDs.
  • control lines and information lines indicate those that are considered necessary for explanation, and do not necessarily indicate all the control lines and information lines necessary for implementation. In practice, it can be considered that almost all configurations are interconnected.

Landscapes

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

Abstract

電子制御装置であって、第一の仮想ドライバにアクセスして、処理を実行する仮想マシンと、前記第一の仮想ドライバから受信したペリフェラルアクセス要求に基づいて第一のペリフェラルの第一の実ドライバを呼び出すハイパーバイザと、前記第一の仮想ドライバを呼び出して、前記ハイパーバイザへ送信したペリフェラルアクセス要求を記録するアクセス記録部と、前記第一の実ドライバを呼び出して、前記第一のペリフェラルのレジスタの状態を記録する状態記録部と、前記ハイパーバイザの動作を監視する監視部とを備え、前記監視部は、前記アクセス記録部の記録と前記状態記録部の記録に基づいて、前記ハイパーバイザの異常を判定する。

Description

電子制御装置及び異常判定方法 参照による取り込み
　本出願は、令和３年（２０２１年）５月１２日に出願された日本出願である特願２０２１－８０７４３の優先権を主張し、その内容を参照することにより、本出願に取り込む。
　本発明は、電子制御装置に関する。
　ハイパーバイザを用いると、異なるＯＳ（Operating System）上で動作する複数の制御ソフトウェアアプリケーションを単一のマイコンに搭載できる。ハイパーバイザを監視する技術として、特開２０１９－１４４７８５（特許文献１）、特開２０１４－１０６５８７（特許文献２）に記載の技術がある。特許文献１には、仮想化ソフトウェア上に、仮想化ソフトウェアを含む複数の監視対象の監視に用いられる監視用の仮想マシンを配置し、所定間隔において監視用の仮想マシンによって実行された所定のテストの結果を取得し、取得したテストの結果から監視用の仮想マシンの異常有無を判定し、監視用の仮想マシンが異常である場合、複数の監視対象の所定の状態を取得し、監視用の仮想マシンの異常有無の判定結果と、複数の監視対象の所定の状態とを出力する監視プログラムが記載されている。
　また、特許文献２には、ハイパバイザと第１のゲストＯＳがＩ／Ｏデバイスを共有する方法であって、Ｉ／Ｏデバイスは、物理機能と仮想機能を有し、ハイパバイザは、物理機能を利用する物理ドライバを有し、第１のゲストＯＳは、仮想機能を利用する仮想ドライバを有し、前記ハイパバイザが、物理ドライバを介してＩ／Ｏデバイスの状態を取得し、第１のゲストＯＳが、ハイパバイザを監視して所定の状態になったときには、Ｉ／Ｏデバイスを操作するサブ物理ドライバを起動し、前記第１のゲストＯＳは、メモリ上に予め設定したキューを介して送受信を行うＩ／Ｏデバイスの制御方法が記載されている。
　異なるＯＳ上で動作する複数の制御ソフトウェアアプリケーションを一つのマイコン（ハードウェア）に統合した電子制御装置においては、ハイパーバイザと呼称される仮想化ソフトウェアが用いられる。ハイパーバイザは、ＯＳ及び制御ソフトウェアアプリケーションを動作させるための環境として、仮想マシンを提供する。仮想マシンとは、マイコン上のＣＰＵ（Central Processing Unit）、メモリ領域、及びマイコン上に搭載されたＣＡＮ（Controller Area Network）コントローラやＡ／Ｄ（Ａｎａｌｏｇ／Ｄｉｇｉｔａｌ）コンバータなどのペリフェラルに対するアクセス権を設定した単位である。各仮想マシン内のゲストＯＳ及び制御ソフトウェアアプリケーションから見て、アクセス権限が付与されていないＣＰＵ、メモリ領域及びペリフェラルが別のマイコン上に存在することと論理的に等価である。一般に、電子制御装置の安全性や信頼性を確保するため、当該電子制御装置の動作中に、当該電子制御装置を構成するハードウェア及びソフトウェアが正常に動作しており、異常を発生していないことの監視が求められる。特に、ハイパーバイザを用いた電子制御装置において、ハイパーバイザの動作の監視が求められる。
　特許文献１によれば、仮想マシンとして監視用仮想マシンを設置し、該監視用仮想マシンが定期的にテストパターンを実行するとともに、ハイパーバイザの内部状態（正常・異常）を取得し、前記テストパターンの実行結果及び前記ハイパーバイザの内部状態の取得結果に基づき、電子制御装置に異常が発生しているか否か、及び異常が発生している場合に該異常による影響範囲を特定できる。しかし、特許文献１におけるハイパーバイザの監視は、ハイパーバイザ自身が判定する正常又は異常の状態を取得することにより実施されているため、ハイパーバイザに異常が発生することによってハイパーバイザによる異常状態が適切に判定されない場合が考慮されておらず、ハイパーバイザの正常動作が保証されない。また、ハイパーバイザの内部状態を取得する必要があるため、内部状態が公開されていないサードパーティ製のハイパーバイザに適用できない。
　特許文献２によれば、ハイパーバイザに対しカウンタ（ウォッチドッグタイマ）を設置し、当該カウンタを所定周期内にカウントアップ又はカウントダウンするよう要件を課し、当該カウンタが所定周期内に更新されない場合にハイパーバイザに異常が発生と判定する方法が記載されている。これにより、ハイパーバイザの予期しない停止や、ハイパーバイザに発生したデッドロックやライブロックを検出可能である。しかし、この方法を適用するためには、カウンタの更新に関する要件をハイパーバイザに課す必要がある。また、ウォッチドッグタイマのカウント更新処理は一般的に高優先度に設定されるため、ハイパーバイザ内部においてカウンタ更新処理の優先度がデッドロック又はライブロックを発生しているタスクの処理優先度より高い場合に、当該デッドロック及び当該ライブロックを検出できない。
　そこで本発明では、サードパーティ製などの、内部ロジックが公開されていないハイパーバイザの入力及び出力のみに基づいた、当該ハイパーバイザの監視、当該ハイパーバイザに発生した異常の検知を目的とする。
　本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、電子制御装置であって、第一の仮想ドライバにアクセスして、処理を実行する仮想マシンと、前記第一の仮想ドライバから受信したペリフェラルアクセス要求に基づいて第一のペリフェラルの第一の実ドライバを呼び出すハイパーバイザと、前記第一の仮想ドライバを呼び出して、前記ハイパーバイザへ送信したペリフェラルアクセス要求を記録するアクセス記録部と、前記第一の実ドライバを呼び出して、前記第一のペリフェラルのレジスタの状態を記録する状態記録部と、前記ハイパーバイザの動作を監視する監視部とを備え、前記監視部は、前記アクセス記録部の記録と前記状態記録部の記録に基づいて、前記ハイパーバイザの異常を判定する。
　本発明の一態様によれば、、ハイパーバイザの内部状態にアクセスせずに、ハイパーバイザの異常を検知できる。前述した以外の課題、構成及び効果は、以下の実施例の説明によって明らかにされる。
第一の実施例の電子制御装置のハードウェア構成を示す図である。 第一の実施例の電子制御装置のソフトウェア構成を示す図である。 第一の実施例の第一の制御ソフトウェアアプリケーションが第一のペリフェラルを使用するときの処理フローの概要を表す図である。 第一の実施例の第一の制御ソフトウェアアプリケーションが共有ペリフェラルを使用するときの処理フロー概要を示す図である。 第一の実施例のペリフェラルアクセス要求情報の例を示す図である。 第一の実施例のペリフェラルアクセス結果情報の例を示す図である。 第一の実施例の第二の制御ソフトウェアアプリケーションが第二のペリフェラルを使用するときの処理フロー概要を示す図である。 第一の実施例の第二の制御ソフトウェアアプリケーションが共有ペリフェラルを使用するときの処理フロー概要を示す図である。 第一の実施例のペリフェラルアクセス記録情報の例を示す図である。 第一の実施例のペリフェラル状態記録情報の例を示す図である。 第一の実施例のハイパーバイザ監視プログラムの処理フロー概要を示す図である。 第一の実施例のペリフェラル所望状態情報の例を示す図である。 第一の実施例のハイパーバイザ監視プログラムのステップＳ１におけるペリフェラル所望状態情報の生成処理を模式的に示す図である。 第一の実施例のハイパーバイザ監視プログラムのステップＳ１におけるペリフェラル所望状態情報の生成処理を模式的に示す図である。 第二の実施例の電子制御装置のソフトウェア構成を示す図である。 第二の実施例のハイパーバイザ監視プログラムの処理フロー概要を示す図である。 第三の実施例の電子制御装置のハードウェア構成を示す図である。 第三の実施例の電子制御装置のソフトウェア構成を示す図である。 第三の実施例の第一の制御ソフトウェアアプリケーションが共有ペリフェラルであるＣＡＮコントローラを使用するときの処理フロー概要を示す図である。 第三の実施例のＣＡＮ台帳を示す図である。 第四の実施例の監視結果保存プログラムの処理フロー概要を示す図である。 第四の実施例のハイパーバイザ異常発生時刻情報の例を示す図である。 第四の実施例の監視結果保存プログラムのステップＳ７における処理の概要を模式的に示す図である。
　本実施例は、電子制御装置に関するものであって、特に、複数の制御ソフトウェアアプリケーションを一つのマイコン上に統合した電子制御装置に関する。
　以下、本発明に好適な実施形態の例（実施例）を説明する。説明のため本実施例においては、第一の制御ソフトウェアアプリケーションと第二の制御ソフトウェアアプリケーションの二つの制御ソフトウェアアプリケーションを一つの電子制御装置に統合する例を説明するが、これに限らず、第三の制御ソフトウェアアプリケーションや第四の制御ソフトウェアアプリケーションを一つの電子制御装置に統合するものでもよい。
　＜構成＞
　図１は、第一の実施例の電子制御装置のハードウェア構成を示す図である。
　＜電子制御装置０＞
　図１を参照して、本実施例の電子制御装置について説明する。電子制御装置０は、マイコン９００と電源回路９０１を有する。マイコン９００は、演算処理を行うＣＰＵ（Central Processing Unit）１、電子制御装置０に搭載された周辺機器群であるペリフェラル２、ソフトウェアを格納するメモリ３、ＣＰＵ１とペリフェラル２とメモリ３を接続しＣＰＵ１からペリフェラル２及びメモリ３へのアクセスを可能とするバス４で構成される。
　マイコン９００の電源入力端子は、電源回路９０１と接続されている。マイコン９００は電源回路９０１から電源供給を受けると起動する。マイコン９００は、自己リセット信号出力端子を有する。マイコン９００が自己リセット信号出力端子からデジタル信号を出力することによって、電源回路９０１はマイコン９００への電源供給を停止する。
　＜ＣＰＵ１＞
　ＣＰＵ１は、第一のＣＰＵコア１０１と第二のＣＰＵコア１０２の二つのコアを有する。なお、説明のためＣＰＵコアは二つとしているが、これに限らず、例えば一つでも三つ以上でもよい。
　＜ペリフェラル２＞
　ペリフェラル２は、マイコン９００の内部又は外部にデータ及び信号を入出力するデバイスであり、第一の制御ソフトウェアアプリケーション１０（すなわち第一のＣＰＵコア１０１）及び第二の制御ソフトウェアアプリケーション１５（すなわち第二のＣＰＵコア１０２）の両方からアクセスされる共用ペリフェラル２０１と、第一の制御ソフトウェアアプリケーション１０（すなわち第一のＣＰＵコア１０１）のみからアクセスされる第一のペリフェラル２０２と、第二の制御ソフトウェアアプリケーション１５（すなわち第二のＣＰＵコア１０３）のみからアクセスされる第二のペリフェラル２０３とを含む。ペリフェラル２とは、マイコン９００に搭載されるＣＰＵ１及びメモリ３以外の周辺回路の一般的な呼称であり、具体的には、マイコン９００に搭載されたＣＡＮ（Controller Area Network）コントローラ、アナログ・デジタル・コンバータ、ダイレクト・メモリ・アクセスコントローラ、ＧＰＩＯ（General Purpose Input/Output）などを含む。
　＜メモリ３＞
　メモリ３は、不揮発性の記憶素子であるＲＯＭ及び揮発性の記憶素子であるＲＡＭを含む。ＲＯＭは、不変のプログラム（例えば、ＢＩＯＳ）などを格納する。ＲＡＭは、ＤＲＡＭ（Dynamic Random Access Memory）のような高速かつ揮発性の記憶素子であり、ＣＰＵ１が実行するプログラム及びプログラムの実行時に使用されるデータを格納する。
　簡単のため、本実施例においては、共用ペリフェラル２０１がデジタル出力ポート２０１１を含み、第一のペリフェラル２０２がアナログ出力ポート２０２１を含み、第二のペリフェラル２０３がデジタル入力ポート２０３１を含むものとする。
　図２は、第一の実施例の電子制御装置のソフトウェア構成を示す図である。図２に示すソフトウェアはメモリ３に格納される。
　＜ソフトウェア構成＞
　以下の処理は、ＣＰＵ１の第一のＣＰＵコア１０１又は第二のＣＰＵコア１０２のいずれかにおいて実行される。
　ホストＯＳ（Operating System）５は、マイコン９００上に搭載される。ホストＯＳ５は、ハイパーバイザ６とハイパーバイザ監視プログラム１７とレジスタ値取得プログラム１８を起動する。ハイパーバイザ６は、ハイパーバイザ６によって定められる起動方法に従って起動される。ハイパーバイザ監視プログラム１７とレジスタ値取得プログラム１８は５ミリ秒周期で起動し、監視のための情報を取得する。なお、簡単のため本実施例では起動周期を５ミリ秒としたが、これに限らず、他のタイミングで起動してもよい。ハイパーバイザ６は、ホストＯＳ５上で実行されるソフトウェアで構成されても、マイコン９００に実装されるハードウェアで構成されてもよい。
　ハイパーバイザ６は、ハイパーバイザ６によって定められる方法によって、第一の仮想マシン７と第二の仮想マシン８を構成し、それぞれを起動する。なお、簡単のため本実施例では仮想マシンの数を２としたが、これに限らず、１又は３以上でもよい。
　第一の仮想マシン７では、第一のゲストＯＳ９と、第一の制御ソフトウェアアプリケーション１０と、仮想ドライバ１１と、ペリフェラルアクセス要求記録プログラム１９と、アナログ出力ポートドライバ１２が実行される。第二の仮想マシン８では、第二のゲストＯＳ１３と、第二の制御ソフトウェアアプリケーション１５と、仮想ドライバ１１と、デジタル入力ポートドライバ１４が実行される。ペリフェラルアクセス要求記録プログラム１９は、第一の仮想マシン７上で実行されているが、第二の仮想マシン８上で実行されてもよい。すなわち、ペリフェラルアクセス要求記録プログラム１９は、ハイパーバイザ６上で少なくとも一つ実行されていればよい。
　＜第一の仮想マシン７＞
　第一の仮想マシン７におけるソフトウェアの動作について説明する。ハイパーバイザ６が第一の仮想マシン７を構成すると、第一の仮想マシン７は第一のゲストＯＳ９を起動する。第一のゲストＯＳ９は、第一の制御ソフトウェアアプリケーション１０を起動する。第一の制御ソフトウェアアプリケーション１０は、共用ペリフェラル２０１であるデジタル出力ポート２０１１と第一のペリフェラル２０２であるアナログ出力ポート２０２１を使用する。
　図３は、第一の制御ソフトウェアアプリケーション１０が第一のペリフェラル２０２を使用するときの処理フローの概要を表す図である。
　＜第一の仮想マシン７から第一のペリフェラル２０２へのアクセス＞
　第一の制御ソフトウェアアプリケーション１０から第一のペリフェラル２０２であるアナログ出力ポート２０２１にアクセスするためには、アナログ出力ポートドライバ１２を用いる。すなわち、第一の制御ソフトウェアアプリケーション１０がペリフェラルアクセス要求として、引数に５Ｖを指定してアナログ出力ポートドライバ１２をコールすると、アナログ出力ポートドライバ１２はアナログ出力ポート２０２１のレジスタにアクセスし、出力電圧値を５Ｖとするための値をマイコン９００の所定のレジスタにセットし、第一の制御ソフトウェアアプリケーション１０に正常終了をリターンする。
　図４は、第一の制御ソフトウェアアプリケーション１０が共用ペリフェラル２０１を使用するときの処理フロー概要を示す図である。
　＜第一の仮想マシン７から共用ペリフェラル２０１へのアクセス＞
　第一の制御ソフトウェアアプリケーション１０から共用ペリフェラル２０１であるデジタル出力ポート２０１１にアクセスするためには、ペリフェラルアクセス要求記録プログラム１９と仮想ドライバ１１とハイパーバイザ６とデジタル出力ポートドライバ１６を用いる。すなわち、第一の制御ソフトウェアアプリケーション１０は、ペリフェラルアクセス要求として、引数にＨを指定してペリフェラルアクセス要求記録プログラム１９をコールする。ペリフェラルアクセス要求記録プログラム１９は、第一の制御ソフトウェアアプリケーション１０によるペリフェラルアクセス要求情報５１を記録し、引数にＨを指定して仮想ドライバ１１をコールする。仮想ドライバ１１は、ＣＰＵ１の処理コンテクストを第一の仮想マシン７からハイパーバイザ６に変更するための処理（一般にＶＭＥｘｉｔと呼称される）を実行する。ハイパーバイザ６は、デジタル出力ポート２０１１の使用状況を確認する。すなわち、ハイパーバイザ６は、第二の仮想マシン８がデジタル出力ポート２０１１を使用中でなければ、引数をＨとしてデジタル出力ポート２０１１にアクセスするためのデジタル出力ポートドライバ１６をコールする。第二の仮想マシン８がデジタル出力ポート２０１１を使用中の場合は、ハイパーバイザ６の内部に準備されたバッファに引数Ｈを格納して待機し、第二の仮想マシン８によるデジタル出力ポート２０１１の使用終了後にバッファから引数Ｈを取り出し、取り出した引数を付してデジタル出力ポートドライバ１６をコールする。
　デジタル出力ポートドライバ１６は、デジタル出力ポート２０１１のレジスタにアクセスし、出力値をＨ（Ｈｉｇｈ，１）とするためのマイコン９００の所定のレジスタに値をセットし、ハイパーバイザ６に正常終了をリターンする。ハイパーバイザ６は、デジタル出力ポートドライバ１６から正常終了のリターンを受け取ると、ＣＰＵ１の処理コンテクストをハイパーバイザ６から第一の仮想マシン７に変更するための処理（一般にＶＭＥｎｔｒｙと呼称される）を実行する。仮想ドライバ１１は、ハイパーバイザ６から正常終了の情報を受け取ると、ペリフェラルアクセス要求記録プログラム１９をコールする。ペリフェラルアクセス要求記録プログラム１９は、第一の制御ソフトウェアアプリケーション１０に対するペリフェラルアクセス結果情報５２を記録し、第一の制御ソフトウェアアプリケーション１０に正常終了をリターンする。
　図５は、第一の制御ソフトウェアアプリケーション１０によるペリフェラルアクセス要求情報５１の例を示す図である。
　＜第一の制御ソフトウェアアプリケーション１０によるペリフェラルアクセス要求情報５１＞
　第一の制御ソフトウェアアプリケーション１０によるペリフェラルアクセス要求情報５１は、第一の制御ソフトウェアアプリケーション１０がペリフェラルアクセス要求記録プログラム１９をコールした時刻と、当該コールによってアクセスを要求したペリフェラルと、当該コールにおいて付加した引数の情報を含む。
　図６は、第一の制御ソフトウェアアプリケーション１０に対するペリフェラルアクセス結果情報５２の例を示す図である。
　＜第一の制御ソフトウェアアプリケーション１０に対するペリフェラルアクセス結果情報５２＞
　第一の制御ソフトウェアアプリケーション１０に対するペリフェラルアクセス結果情報５２は、ハイパーバイザ６が仮想ドライバ１１に対して正常処理済みである旨の情報を返信した時刻と、ハイパーバイザ６が処理を行ったペリフェラルの情報と、処理結果の情報を含む。
　＜第二の仮想マシン８＞
　第二の仮想マシン８におけるソフトウェアの動作について説明する。ハイパーバイザ６が第二の仮想マシン８を構成すると、第二の仮想マシン８は第二のゲストＯＳ１３を起動する。第二のゲストＯＳ１３は、第二の制御ソフトウェアアプリケーション１５を起動する。第二の制御ソフトウェアアプリケーション１５は、共用ペリフェラル２０１であるデジタル出力ポート２０１１と第二のペリフェラル２０３であるデジタル入力ポート２０３１を使用する。
　図７は、第二の制御ソフトウェアアプリケーション１５が第二のペリフェラル２０３を使用するときの処理フロー概要を示す図である。
　＜第二の仮想マシン８から第二のペリフェラル２０３へのアクセス＞
　第二の制御ソフトウェアアプリケーション１５から第二のペリフェラル２０３であるデジタル入力ポート２０３１にアクセスするためには、デジタル入力ポートドライバ１４を用いる。すなわち、第二の制御ソフトウェアアプリケーション１５がペリフェラルアクセス要求として、デジタル入力ポートドライバ１４をコールすると、デジタル入力ポートドライバ１４はデジタル入力ポート２０３１のレジスタにアクセスし、マイコン９００の所定のレジスタの値を読み取り、該読み取りの結果を付して第二の制御ソフトウェアアプリケーション１５にリターンする。
　図８は、第二の制御ソフトウェアアプリケーション１５が共用ペリフェラル２０１を使用するときの処理フロー概要を示す図である。
　＜第二の仮想マシン８から共用ペリフェラル２０１へのアクセス＞
　第二の制御ソフトウェアアプリケーション１５から共用ペリフェラル２０１であるデジタル出力ポート２０１１にアクセスするためには、仮想ドライバ１１とハイパーバイザ６とデジタル出力ポートドライバ１６を用いる。すなわち、第一の制御ソフトウェアアプリケーション１０は、ペリフェラルアクセス要求として、引数にＨを指定して仮想ドライバ１１をコールする。仮想ドライバ１１は、ＣＰＵ１の処理コンテクストを第二の仮想マシン８からハイパーバイザ６に変更するための処理（一般にＶＭＥｘｉｔと呼称される）を実行する。ハイパーバイザ６は、デジタル出力ポート２０１１の使用状況を確認する。すなわち、ハイパーバイザ６は、第一の仮想マシン７がデジタル出力ポート２０１１を使用中でなければ、引数をＨとしてデジタル出力ポート２０１１にアクセスするためのデジタル出力ポートドライバ１６をコールする。第一の仮想マシン７がデジタル出力ポート２０１１を使用中の場合は、ハイパーバイザ６の内部に準備されたバッファに引数Ｈを格納して待機し、第一の仮想マシン７によるデジタル出力ポート２０１１の使用終了後にバッファから引数Ｈを取り出し、取り出した引数を付してデジタル出力ポートドライバ１６をコールする。
　デジタル出力ポートドライバ１６は、デジタル出力ポート２０１１のレジスタにアクセスし、出力値をＨ（Ｈｉｇｈ，１）とするためのマイコン９００の所定のレジスタに値をセットし、ハイパーバイザ６に正常終了をリターンする。ハイパーバイザ６は、デジタル出力ポートドライバ１６から正常終了のリターンを受け取ると、ＣＰＵ１の処理コンテクストをハイパーバイザ６から第一の仮想マシン７に変更するための処理（一般にＶＭＥｎｔｒｙと呼称される）を実行する。仮想ドライバ１１は、ハイパーバイザ６から正常終了の情報を受け取ると、第一の制御ソフトウェアアプリケーション１０に正常終了をリターンする。
　＜ペリフェラルアクセス要求記録プログラム１９＞
　ペリフェラルアクセス要求記録プログラム１９は、図４に示すように、第一の制御ソフトウェアアプリケーション１０がペリフェラルアクセス要求を送出したときに、第一の制御ソフトウェアアプリケーション１０によるペリフェラルアクセス要求情報５１を生成する。また、ペリフェラルアクセス要求記録プログラム１９は、図４に示すように、仮想ドライバ１１がハイパーバイザ６から正常終了済みとの情報を受け取ったときに、第一の制御ソフトウェアアプリケーション１０に対するペリフェラルアクセス結果情報５２を生成する。さらに、ペリフェラルアクセス要求記録プログラム１９は、第一のゲストＯＳ９によって所定のタイミングで繰り返し（例えば１００ミリ秒周期で）起動され、第一の制御ソフトウェアアプリケーション１０によるペリフェラルアクセス要求情報５１と第一の制御ソフトウェアアプリケーション１０に対するペリフェラルアクセス結果情報５２を統合したペリフェラルアクセス記録情報５３を生成し、当該ペリフェラルアクセス記録情報５３をハイパーバイザ監視プログラム１７が参照可能なメモリ領域に書き込む。
　図９は、ペリフェラルアクセス記録情報５３の例を示す図である。
　＜ペリフェラルアクセス記録情報５３＞
　ペリフェラルアクセス記録情報５３は、第一の制御ソフトウェアアプリケーション１０がペリフェラルアクセス要求記録プログラム１９をコールした時刻と、当該要求によるアクセス要求先のペリフェラルと、当該要求において付加した引数の情報と、当該ペリフェラルアクセス要求に従ってハイパーバイザ６が仮想ドライバ１１に対して正常処理済みとの情報を送信した時刻と、ハイパーバイザ６による処理結果の情報を含む。
　＜レジスタ値取得プログラム１８＞
　レジスタ値取得プログラム１８は、ホストＯＳ５によって所定のタイミングで繰り返し（例えば５ミリ秒周期で）起動される。レジスタ値取得プログラム１８は、起動毎にデジタル出力ポートドライバ１６をコールして、共用ペリフェラル２０１であるデジタル出力ポート２０１１の状態を表すマイコン９００の所定のレジスタの値を取得し、ペリフェラル状態記録情報５４を生成し、生成したペリフェラル状態記録情報５４をハイパーバイザ監視プログラム１７が参照可能なメモリ領域に書き込む。レジスタ値取得プログラム１８は、ホストＯＳ５上で実行されているが、ハイパーバイザ６上で実行されてもよい。
　図１０は、ペリフェラル状態記録情報５４の例を示す図である。
　＜ペリフェラル状態記録情報５４＞
　ペリフェラル状態記録情報５４は、レジスタ値取得プログラム１８の処理対象のペリフェラルと、レジスタ値取得プログラム１８がペリフェラル（デジタル出力ポートドライバ１６）をコールした時刻と、該コールにより取得したレジスタの値の情報を含む。
　図１１は、ハイパーバイザ監視プログラム１７の処理フロー概要を示す図である。
　＜ハイパーバイザ監視プログラム１７＞
　ハイパーバイザ監視プログラム１７は、ペリフェラルアクセス記録情報５３に基づいてレジスタ値が本来取るべき値を計算し、この本来取るべき値とペリフェラル状態記録情報５４が一致していない場合に、ハイパーバイザ６に異常が発生したと判定する。
　ステップＳ１において、ハイパーバイザ監視プログラム１７は、ペリフェラルアクセス記録情報５３に含まれるすべての情報とペリフェラル状態記録情報５４に含まれる状態確認時刻情報に基づいて、ペリフェラル所望状態情報５５を生成する。
　ステップＳ２において、ハイパーバイザ監視プログラム１７は、ペリフェラル状態記録情報５４とペリフェラル所望状態情報５５を比較し、ハイパーバイザ６の状態が正常であるか異常であるかを判定する。
　図１２は、ペリフェラル所望状態情報５５の例を示す図である。
　＜ペリフェラル所望状態情報５５＞
　ペリフェラル所望状態情報５５は、レジスタ値取得プログラム１８がデジタル出力ポートドライバ１６をコールした時刻と、ペリフェラルアクセス記録情報５３に基づいて計算された時刻におけるペリフェラルレジスタの値の情報を含む。
　図１３は、ハイパーバイザ監視プログラム１７のステップＳ１におけるペリフェラル所望状態情報生成処理を模式的に示す図である。
　＜ステップＳ１＞
　本実施例では、レジスタの初期値は不定である。
　ペリフェラルアクセス記録情報５３によると、第一の制御ソフトウェアアプリケーション１０は、時刻１０：００に引数をＨとしてペリフェラルアクセス要求を送信している。第一の制御ソフトウェアアプリケーション１０がペリフェラルアクセス要求を送信してから図４に示すフローに従ってデジタル出力ポートドライバ１６のレジスタの値が実際に操作されるまでの間にはオーバヘッドが存在する。当該オーバヘッドの長さは予測できないが、ペリフェラルアクセス記録情報５３のハイパーバイザ返答時刻情報によって、時刻１０：００と時刻１６：００の間のいずれかの時刻でレジスタの値がＨにセットされていると計算される。
　同様に、ペリフェラルアクセス記録情報５３によると、第一の制御ソフトウェアアプリケーション１０は、時刻２５：００に引数をＬとしてペリフェラルアクセス要求を送信している。第一の制御ソフトウェアアプリケーション１０がペリフェラルアクセス要求を送信してから図４に示すフローに従ってデジタル出力ポートドライバ１６のレジスタの値が実際に操作されるまでの間にはオーバヘッドが存在する。当該オーバヘッドの長さは予測できないが、ペリフェラルアクセス記録情報５３のハイパーバイザ返答時刻情報によって、時刻２５：００と時刻３２：００の間のいずれかの時刻でレジスタの値がＬにセットされていると計算される。
　従って、ペリフェラル所望状態情報５５は、図１２に示す通りに生成される。すなわち、時刻１２：１０においては不定値である初期値が維持されているか、時刻１０：００に送信されたペリフェラルアクセス要求に従いＨとなっているかのいずれかであり、レジスタの値はＨ又はＬいずれも取り得る。時刻１６：００より後の時刻１７：１０においては、レジスタの値はＨ、時刻２２：１０においては引き続きレジスタの値はＨとなっている。また、時刻２７：１０においては、引き続きレジスタの値はＨとなっているか、時刻２５：００におけるペリフェラルアクセス要求に従ってＬとなっているかのいずれかであり、レジスタの値はＨ又はＬいずれも取り得る。時刻３２：００より後の時刻３２：１０においては、レジスタの値はＬ、時刻３７：１０においては引き続きレジスタの値はＬと計算される。
　図１４は、ハイパーバイザ監視プログラム１７のステップＳ１におけるペリフェラル所望状態情報生成処理を模式的に示す図である。
　＜ステップＳ２＞
　ステップＳ２において、ハイパーバイザ監視プログラム１７は、ペリフェラル所望状態情報５５とペリフェラル状態記録情報５４を比較し、ペリフェラル所望状態情報５５で計算された各時刻におけるペリフェラルレジスタの値がペリフェラル状態記録情報５４に記録されたレジスタの値と異なる場合に、ハイパーバイザ６の異常が発生したと判定する。すなわち、図１４に示す場合、時刻３２：１０において、ペリフェラル所望状態情報５５によるとレジスタの値はＬであるべきだが、ペリフェラル状態記録情報５４によると実際のレジスタの値はＨとなっているため、ハイパーバイザ６の異常が検知される。これは、第一の制御ソフトウェアアプリケーション１０が、デジタル出力ポート２０１１をＬにするようペリフェラルアクセス要求を送信し、ハイパーバイザ６は正常に処理した旨を第一の制御ソフトウェアアプリケーション１０に返答しているが、実際にはデジタル出力ポート２０１１の値がＨのまま変更されていないことを表している。
　本実施例によれば、内部ロジックが公開されていないハイパーバイザ６であっても、ハイパーバイザ６が操作するマイコン９００のレジスタの値の変化の記録によって、ハイパーバイザ６が仮想マシン７、８の内部の制御ソフトウェアアプリケーション１０、１５が要求した処理が正しく実行しているか否かをハイパーバイザ６の外部から監視する。このため、ハイパーバイザ６の内部状態にアクセスせずに、ハイパーバイザ６の入力及び出力に基づいて、ハイパーバイザ６の異常を検知できる。すなわち、ハイパーバイザ６が仮想マシン７、８に対して正常処理を返信している場合でも、実際に正常に処理が行われていなければハイパーバイザ６の異常を検出できる。
　また、レジスタの実際の値と予定値の不整合によってハイパーバイザ６の異常を判定するので、テストパターンのような余分な処理が不要となり、本来の処理への影響を抑制できる。
　本発明の第二の実施例の電子制御装置及び方法について説明する。第二の実施例は、ソフトウェア構成に監視結果保存プログラム２０が追加される点で第一の実施例と異なる。なお、第一の実施例と同じ構成には、同じ符号を付して、その説明を省略する。
　図１５は、第二の実施例の電子制御装置のソフトウェア構成を示す図である。図１５に示すソフトウェアはメモリ３に格納される。
　＜ソフトウェア構成＞
　ホストＯＳ５はマイコン９００上に搭載される。ホストＯＳ５は、ハイパーバイザ６とハイパーバイザ監視プログラム１７とレジスタ値取得プログラム１８を起動する。また、ホストＯＳ５は、異常検知フラグ５６の値を所定のタイミングで繰り返し（例えば５ミリ秒周期で）確認し、異常検知フラグ５６がＴｒｕｅであることを確認した場合、異常検知フラグ５６をＦａｌｓｅに書き換えた後、監視結果保存プログラム２０を起動する。
　＜異常検知フラグ５６＞
　異常検知フラグ５６はＴｒｕｅ、Ｆａｌｓｅの２値のいずれかをとる変数である。
　図１６は、ハイパーバイザ監視プログラム１７の処理フロー概要を示す図である。
　＜ステップＳ３＞
　ステップＳ３において、ハイパーバイザ監視プログラム１７は、ステップＳ２における判定結果が正常であるか異常であるかに従って、処理を分岐する。すなわち、ステップＳ２における判定結果が正常である場合は何もせずに終了し、ステップＳ２における判定結果が異常である場合はステップＳ４に進む。
　＜ステップＳ４＞
　ステップＳ４において、ハイパーバイザ監視プログラム１７は、異常検知フラグ５６の値をＴｒｕｅに変更し、処理を終了する。
　＜監視結果保存プログラム２０＞
　監視結果保存プログラム２０は、ペリフェラルアクセス記録情報５３とペリフェラル状態記録情報５４とペリフェラル所望状態情報５５をマイコン９００のメモリ３の内部の不揮発メモリ領域に保存する。
　本実施例によれば、不揮発メモリ領域の参照によって、ペリフェラルアクセス記録情報５３とペリフェラル状態記録情報５４とペリフェラル所望状態情報５５を、ハイパーバイザ６に異常が検知された理由及びハイパーバイザ６に異常が発生する動作パターンを特定するデバッグのための情報とし使用できる。
　本発明の第三の実施例の電子制御装置及び方法について説明する。第三の実施例は、ペリフェラルアクセス記録情報５３を取り出すために別の仮想ドライバを使用する点で第一の実施例と異なる。なお、第一の実施例と同じ構成については、同じ符号を付して、その説明を省略する。
　＜構成＞
　図１７は、第三の実施例の電子制御装置のハードウェア構成を示す図である。
　＜ペリフェラル２＞
　本実施例においては、共用ペリフェラル２０１にデジタル出力ポート２０１１及びＣＡＮコントローラ２０１２が含まれ、第一のペリフェラル２０２にアナログ出力ポート２０２１が含まれ、第二のペリフェラル２０３にデジタル入力ポート２０３１が含まれる。
　図１８は、第三の実施例の電子制御装置のソフトウェア構成を示す図である。図１８に示すソフトウェアはメモリ３に格納される。
　＜ソフトウェア構成＞
　第一の仮想マシン７は、第一のゲストＯＳ９と、第一の制御ソフトウェアアプリケーション１０と、仮想ドライバ１１と、ペリフェラルアクセス要求記録プログラム１９と、アナログ出力ポートドライバ１２と、仮想ＣＡＮドライバ２１を含む。第二の仮想マシン８は、第二のゲストＯＳ１３と、第二の制御ソフトウェアアプリケーション１５と、仮想ドライバ１１と、デジタル入力ポートドライバ１４と、仮想ＣＡＮドライバ２１を含む。
　＜第一の仮想マシン７＞
　第一の仮想マシン７におけるソフトウェアの動作について説明する。ハイパーバイザ６が第一の仮想マシン７を構成すると、第一の仮想マシン７は第一のゲストＯＳ９を起動する。第一のゲストＯＳ９は、第一の制御ソフトウェアアプリケーション１０を起動する。第一の制御ソフトウェアアプリケーション１０は、共用ペリフェラル２０１であるデジタル出力ポート２０１１とＣＡＮコントローラ２０１２と、第一のペリフェラル２０２であるアナログ出力ポート２０２１を使用する。
　図１９は、第三の実施例の第一の制御ソフトウェアアプリケーション１０が共用ペリフェラル２０１であるＣＡＮコントローラ２０１２を使用するときの処理フロー概要を示す図である。
　＜第一の仮想マシン７からＣＡＮコントローラ２０１２へのアクセス＞
　第一の制御ソフトウェアアプリケーション１０から共用ペリフェラル２０１であるＣＡＮコントローラ２０１２にアクセスするためには、仮想ＣＡＮドライバ２１とハイパーバイザ６とＣＡＮドライバ２２を用いる。すなわち、第一の制御ソフトウェアアプリケーション１０は、ペリフェラルアクセス要求として、引数にＣＡＮメッセージプロトコルで指定されるＩＤ及びＣＡＮフレームに送信するデータｄａｔａを指定して仮想ＣＡＮドライバ２１をコールする。仮想ＣＡＮドライバ２１は、ＣＰＵ１の処理コンテクストを第一の仮想マシン７からハイパーバイザ６に変更するための処理（一般にＶＭＥｘｉｔと呼称される）を実行する。ハイパーバイザ６は、ＣＡＮコントローラ２０１２の使用状況を確認する。すなわち、ハイパーバイザ６は、第二の仮想マシン８がＣＡＮコントローラ２０１２を使用中でなければ、引数にＩＤとｄａｔａを指定してＣＡＮコントローラ２０１２にアクセスするためのＣＡＮドライバ２２をコールする。第二の仮想マシン８がＣＡＮコントローラ２０１２を使用中の場合は、ハイパーバイザ６の内部に準備したバッファに引数ＩＤとｄａｔａを格納して待機し、第二の仮想マシン８によるＣＡＮコントローラ２０１２の使用が終了した後に、前記バッファから引数ＩＤとｄａｔａを取り出し、前記取り出した引数をつけてＣＡＮドライバ２２をコールする。
　ＣＡＮドライバ２２はＣＡＮコントローラ２０１２のレジスタにアクセスし、ＣＡＮ通信バスに対してＩＤとｄａｔａをＣＡＮフレームに格納して送信し、ハイパーバイザ６に対し、正常終了をリターンする。ハイパーバイザ６は、ＣＡＮドライバ２２から正常終了のリターンを受け取ると、ＣＰＵ１の処理コンテクストをハイパーバイザ６から第一の仮想マシン７に変更するための処理（一般にＶＭＥｎｔｒｙと呼称される）を実行する。仮想ＣＡＮドライバ２１は、ハイパーバイザ６から正常終了の情報を受け取ると、第一の制御ソフトウェアアプリケーション１０に対し正常終了をリターンする。
　図２０は、第三の実施例のＣＡＮ台帳５７を示す図である。
　＜ＣＡＮ台帳５７＞
　ＣＡＮ台帳５７は、ＣＡＮドライバ２２内部に保持され、各ＣＡＮフレームを識別するためのメッセージＩＤと当該ＣＡＮフレームに含まれるデータの内容と当該ＣＡＮフレームを送信処理するか受信処理するかの情報と当該ＣＡＮフレームにおけるデータ長の情報を含む。本実施例では、ＩＤ０かから２０００までのＣＡＮフレームは、通常の制御処理に使用され、ＣＡＮ通信バスに対し送信される又はＣＡＮ通信バスから受信される。メッセージＩＤ９９００のＣＡＮフレームには、ペリフェラル状態記録情報５４における状態確認時刻と処理対象とレジスタ値の組を８バイトのデータとして格納し、当該ＣＡＮフレームの送信・受信の情報は監視部送信と記載する。
　＜ＣＡＮドライバ２２＞
　ＣＡＮドライバ２２は、ＣＡＮ台帳５７に記述された情報に従って、ＣＡＮコントローラ２０１２のレジスタを操作する。すなわち、メッセージＩＤ０の８バイトデータについてはＣＡＮコントローラ２０１２のレジスタを操作して車両速度としてＣＡＮ通信バスから受信し、メッセージＩＤ１の８バイトデータについてはＣＡＮコントローラ２０１２のレジスタを操作してエンジン回転数としてＣＡＮ通信バスに送信し、メッセージＩＤ２の８バイトデータについてはＣＡＮコントローラ２０１２のレジスタを操作してスロットル開度としてＣＡＮ通信バスに送信する。
　さらに、ＣＡＮドライバ２２は、ＣＡＮ台帳５７において送信・受信の種別が監視部送信となっているメッセージＩＤ９９００のデータについては、ＣＡＮコントローラ２０１２のレジスタを操作せず、ハイパーバイザ監視プログラム１７が参照可能なメモリ領域に当該データを書き込む。ＣＡＮドライバ２２は第一の仮想マシン７及びハイパーバイザ６の外部に存在するため、ハイパーバイザ６によるメモリ領域の参照領域の制限の影響を受けない。また、ハイパーバイザ６の監視に使用するペリフェラル（デジタル出力ポート２０１１）と別のペリフェラル（ＣＡＮコントローラ２０１２）を用いることによって、ハイパーバイザ６はデジタル出力ポート２０１１の操作において異常が発生している場合においても、ペリフェラルアクセス記録情報５３をハイパーバイザ監視プログラム１７が参照可能なメモリ領域に格納できる。
　本実施例によれば、ハイパーバイザ６が構成した仮想マシン内部から仮想マシン外部へのアクセスが禁止され、ペリフェラルアクセス要求記録プログラム１９がペリフェラルアクセス記録情報５３をハイパーバイザ監視プログラム１７が参照可能なメモリ領域に書き込むことが不可能な場合でも、当該ペリフェラルアクセス記録情報５３を第一の仮想マシン７の外部に取り出し、ハイパーバイザ監視プログラム１７が参照可能なメモリ領域に書き込むことができる。
　本発明の第四の実施例の電子制御装置及び方法について説明する。第四の実施例は、ハイパーバイザ６の故障を所定の値以上の頻度で検出した場合に、電子制御装置をシャットダウンする点で第二の実施例と異なる。なお、第二の実施例と同じ構成については、同一の符号を付して、その説明を省略する。
　図２１は、第四の実施例の監視結果保存プログラム２０の処理フロー概要を示す図である。
　＜監視結果保存プログラム２０＞
　監視結果保存プログラム２０は、ペリフェラルアクセス記録情報５３とペリフェラル状態記録情報５４とペリフェラル所望状態情報５５をマイコン９００のメモリ３の内部の不揮発メモリ領域に保存し、ハイパーバイザ６の異常発生頻度を計算し、計算された異常発生頻度が所定の閾値以上の場合に電子制御装置０をシャットダウンする。
　＜ステップＳ５＞
　ステップＳ５において、監視結果保存プログラム２０は、ペリフェラルアクセス記録情報５３とペリフェラル状態記録情報５４とペリフェラル所望状態情報５５をマイコン９００のメモリ３の内部の不揮発メモリ領域に保存する。
　＜ステップＳ６＞
　ステップＳ６において、監視結果保存プログラム２０は、ハイパーバイザ６に異常が発生した時刻を計算する。ハイパーバイザ６に実際に異常が発生した時刻をハイパーバイザ６の外部からの特定は困難であるため、異常が発生した時刻として、ハイパーバイザ監視プログラム１７がハイパーバイザ６に異常が発生したと判定する根拠としたペリフェラル状態記録情報５４とペリフェラル所望状態情報５５に記載された時刻をハイパーバイザ６に異常が発生した時刻とする。すなわち、ペリフェラル状態記録情報５４とペリフェラル所望状態情報５５が図１４に示すものある場合、ハイパーバイザ６に異常が発生した時刻は、時刻００：３２：１０と計算される。監視結果保存プログラム２０は、この時刻をハイパーバイザ異常発生時刻情報５８に保存する。
　図２２は、第四の実施例のハイパーバイザ異常発生時刻情報５８の例を示す図である。
　＜ハイパーバイザ異常発生時刻情報５８＞
　ハイパーバイザ異常発生時刻情報５８は、第四の実施例の電子制御装置の監視結果保存プログラム２０のステップＳ６で計算された時刻の情報を格納する。
　＜ハイパーバイザ異常発生頻度要件５９＞
　ハイパーバイザ異常発生頻度要件５９は、電子制御装置０をシャットダウンするための条件である。本実施例では、時間１０：００以内にハイパーバイザ６の異常を２回検出とする。
　図２３は、第四の実施例の監視結果保存プログラム２０のステップＳ７における処理の概要を模式的に示す図である。
　＜ステップＳ７＞
　監視結果保存プログラム２０は、ステップＳ７において、ハイパーバイザ６に異常が発生した頻度を計算する。ハイパーバイザ異常発生頻度要件５９によって時間１０：００以内のハイパーバイザ６の異常発生頻度が条件となっているため、最新の異常発生時刻から遡って時間１０：００以内に発生したハイパーバイザ異常発生時刻の記録回数を計算する。図２３を用いて説明する。時刻５０：２５において、最新の異常発生時刻は４７：１０であり、この時刻から遡って時間１０：００、すなわち時刻３７：１０から時刻４７：１０の間に発生した回数はハイパーバイザ異常発生時刻情報５８によれば１回であるため、頻度は１回であると計算される。時刻５４：３５において、最新の異常発生時刻は５２：１０であり、この時刻から遡って時間１０：００、すなわち時刻４２：１０から時刻５２：１０の間に発生した回数は、ハイパーバイザ異常発生時刻情報５８によれば２回であるため、頻度は２回であると計算される。
　＜ステップＳ８＞
　ステップＳ８において、監視結果保存プログラム２０は、ステップＳ７で計算した異常発生頻度がハイパーバイザ異常発生頻度要件５９で規定した値以上であれば、ステップＳ９に進み、そうでなければステップＳ９をスキップしてこの処理を終了する。
　＜ステップＳ９＞
　ステップＳ９において、監視結果保存プログラム２０は、マイコン９００の自己リセット出力端子からリセット信号を出力する。これにより、電源回路９０１はマイコン９００への電源供給を停止し、電子制御装置０はシャットダウンする。電子制御装置０の停止範囲は、その一部でも全部でもよい。
　本実施例によれば、ハイパーバイザ６に異常を検知した頻度が低ければ、電子制御装置の動作を継続して、当該電子制御装置や当該電子制御装置が搭載された車両への影響を抑制し、ハイパーバイザ６に異常を検知した頻度が高ければ、電子制御装置をシャットダウンして、ハイパーバイザ６に発生した異常が当該電子制御装置や当該電子制御装置が搭載された車両の安全に与える影響を低減でき、可用性と安全性を両立できる。
　なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。
　また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。
　各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。
　また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。

Claims (8)

  1. 　電子制御装置であって、
    　第一の仮想ドライバにアクセスして、処理を実行する仮想マシンと、
    　前記第一の仮想ドライバから受信したペリフェラルアクセス要求に基づいて第一のペリフェラルの第一の実ドライバを呼び出すハイパーバイザと、
    　前記第一の仮想ドライバを呼び出して、前記ハイパーバイザへ送信したペリフェラルアクセス要求を記録するアクセス記録部と、
    　前記第一の実ドライバを呼び出して、前記第一のペリフェラルのレジスタの状態を記録する状態記録部と、
    　前記ハイパーバイザの動作を監視する監視部とを備え、
    　前記監視部は、前記アクセス記録部の記録と前記状態記録部の記録に基づいて、前記ハイパーバイザの異常を判定する電子制御装置。
  2. 　請求項１に記載の電子制御装置であって、
    　前記監視部は、前記アクセス記録部の記録と前記状態記録部の記録が整合しない場合、前記ハイパーバイザが異常であると判定する電子制御装置。
  3. 　請求項２に記載の電子制御装置であって、
    　前記状態記録部は、所定のタイミングで繰り返し前記レジスタの状態を取得することを特徴とする電子制御装置。
  4. 　請求項２に記載の電子制御装置であって、
    　前記監視部は、前記アクセス記録部にアクセス要求の記録があり、前記実ドライバの処理結果を前記仮想ドライバへ正常に返答した記録があり、かつ前記状態記録部のレジスタの状態が変化ない場合に、前記ハイパーバイザが異常であると判定する電子制御装置。
  5. 　請求項１に記載の電子制御装置であって、
    　前記監視部が異常を判定した場合、前記アクセス記録部の記録及び前記状態記録部の記録を不揮発に保存する監視結果保存部を備える電子制御装置。
  6. 　請求項５に記載の電子制御装置であって、
    　前記監視結果保存部は、前記ハイパーバイザが異常であると判定された頻度が所定の閾値以上である場合、前記電子制御装置の一部又は全部を停止する電子制御装置。
  7. 　請求項１に記載の電子制御装置であって、
    　前記第一のペリフェラルと異なる第二のペリフェラルと、
    　前記第二のペリフェラルを操作するための第二の実ドライバを備え、
    　前記第二のペリフェラルは、前記第二の実ドライバの指示に従って、前記アクセス記録部の記録を前記仮想マシンの外部に出力し、
    　前記監視部は、前記仮想マシンの外部に出力された前記アクセス記録部の記録を参照する電子制御装置。
  8. 　電子制御装置で動作するハイパーバイザの異常判定方法であって、
    　前記電子制御装置は、
    　第一の仮想ドライバにアクセスして、処理を実行する仮想マシンと、
    　前記第一の仮想ドライバから受信したペリフェラルアクセス要求に基づいて第一のペリフェラルの第一の実ドライバを呼び出すハイパーバイザと、
    　前記第一の仮想ドライバを呼び出して、前記ハイパーバイザへ送信したペリフェラルアクセス要求を記録するアクセス記録部と、
    　前記第一の実ドライバを呼び出して、前記第一のペリフェラルのレジスタの状態を記録する状態記録部と、
    　前記ハイパーバイザの動作を監視する監視部とを有し、
    　前記異常判定方法は、
    　前記状態記録部が、前記第一の実ドライバを呼び出して、前記第一のペリフェラルのレジスタの状態を記録し、
    　前記監視部が、前記アクセス記録部の記録と前記状態記録部の記録に基づいて、前記ハイパーバイザの異常を判定する異常判定方法。
PCT/JP2022/004527 2021-05-12 2022-02-04 電子制御装置及び異常判定方法 WO2022239331A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US18/559,513 US20240241747A1 (en) 2021-05-12 2022-02-04 Electronic controller and abnormality determination method
DE112022001480.6T DE112022001480T5 (de) 2021-05-12 2022-02-04 Elektronische steuereinheit und anomaliebestimmungsverfahren

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-080743 2021-05-12
JP2021080743A JP2022174784A (ja) 2021-05-12 2021-05-12 電子制御装置及び異常判定方法

Publications (1)

Publication Number Publication Date
WO2022239331A1 true WO2022239331A1 (ja) 2022-11-17

Family

ID=84029069

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/004527 WO2022239331A1 (ja) 2021-05-12 2022-02-04 電子制御装置及び異常判定方法

Country Status (4)

Country Link
US (1) US20240241747A1 (ja)
JP (1) JP2022174784A (ja)
DE (1) DE112022001480T5 (ja)
WO (1) WO2022239331A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006268687A (ja) * 2005-03-25 2006-10-05 Mitsubishi Electric Corp コンピュータウィルス監視プログラム及びこれを用いたコンピュータ端末装置
JP2010122736A (ja) * 2008-11-17 2010-06-03 Ricoh Co Ltd シリアル通信装置とそれを備えた画像形成装置
JP2014178975A (ja) * 2013-03-15 2014-09-25 Nec Corp コンピュータ装置と方法とプログラム
JP2019144785A (ja) * 2018-02-20 2019-08-29 富士通株式会社 監視プログラム、監視装置及び監視方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5874879B2 (ja) 2012-11-26 2016-03-02 株式会社日立製作所 Ｉ／ｏデバイスの制御方法及び仮想計算機システム
JP6983855B2 (ja) 2019-11-19 2021-12-17 鹿島道路株式会社 再生アスファルト混合物の製造システム及び方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006268687A (ja) * 2005-03-25 2006-10-05 Mitsubishi Electric Corp コンピュータウィルス監視プログラム及びこれを用いたコンピュータ端末装置
JP2010122736A (ja) * 2008-11-17 2010-06-03 Ricoh Co Ltd シリアル通信装置とそれを備えた画像形成装置
JP2014178975A (ja) * 2013-03-15 2014-09-25 Nec Corp コンピュータ装置と方法とプログラム
JP2019144785A (ja) * 2018-02-20 2019-08-29 富士通株式会社 監視プログラム、監視装置及び監視方法

Also Published As

Publication number Publication date
US20240241747A1 (en) 2024-07-18
JP2022174784A (ja) 2022-11-25
DE112022001480T5 (de) 2024-01-11

Similar Documents

Publication Publication Date Title
US9690603B2 (en) Central processing unit, information processing apparatus, and intra-virtual-core register value acquisition method
US4412281A (en) Distributed signal processing system
JP6530723B2 (ja) コンピュータシステム内における複数のハイパーバイザーの共同運用を容易にするためのシステムおよび方法
US20070226740A1 (en) Method and apparatus for global breakpoint for parallel debugging on multiprocessor systems
EP3835988A1 (en) Communication method and apparatus, computer-readable storage medium, and chip
US8250354B2 (en) Method and apparatus for making a processor sideband interface adhere to secure mode restrictions
JP2001014220A (ja) ソフトウェア制御される電子装置のパーティション分割および監視方法
US20040098639A1 (en) Debugging kernel-loadable modules and suspending and replacing functions in non-microkernel operating systems
JPS5968004A (ja) 車載用コンピユ−タのフエイルセ−フ方法
US8230446B2 (en) Providing a computing system with real-time capabilities
US7831816B2 (en) Non-destructive sideband reading of processor state information
JP2015067107A (ja) 車両用制御装置
WO2022239331A1 (ja) 電子制御装置及び異常判定方法
US10783242B2 (en) Method and semiconductor circuit for protecting an operating system of a security system of a vehicle
CN115576734B (zh) 一种多核异构日志存储方法和***
KR20100006742A (ko) 컴퓨터 시스템 및 그 제어 방법
US20140229764A1 (en) Management of a computer
EP2645258B1 (en) Multiprocessor system, apparatus and methods
US7631178B2 (en) Independent main partition reset
Brewerton et al. Hardware based paravirtualization: simplifying the co-hosting of legacy code for mixed criticality applications
CN117272412B (zh) 中断控制寄存器保护方法、装置、计算机设备及存储介质
US20030145175A1 (en) Multiprocessor system having respective control programs of a plurality of processors stored contiguously in a memory
JP5703505B2 (ja) バスパーティション構造を備えるコンピュータ
JP2017204286A (ja) 車両用制御装置
CN118377637A (zh) 减少冗余缓存一致性操作的方法、装置、设备和存储介质

Legal Events

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

Ref document number: 22807038

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18559513

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 112022001480

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22807038

Country of ref document: EP

Kind code of ref document: A1