JP2011022934A - Electronic control unit and method for detecting failure - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an electronic control unit which can mount a monitoring microcomputer without increase cost and in-vehicle space and reducing a communication time between a microcomputer and the monitoring microcomputer, and a method for detecting an failure. <P>SOLUTION: The electronic control unit 100 for providing an in-vehicle device with an operation result includes: a CPU 11 that actually exists; virtual CPU constructing means 12 and 14 for constructing virtual CPUs from the CPU 11 that actually exists; and a first virtual CPU(A)1 and a second virtual CPU(A)2 which are virtually constructed, wherein the second virtual CPU(A)2 monitors the first virtual CPU(A)1 for providing an operation result. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to an electronic control unit that provides a calculation result to an in-vehicle device mounted on a vehicle, and more particularly to an electronic control unit and an abnormality detection method for detecting an abnormality of the electronic control unit.

  The vehicle has various electronic control units that are based on microcomputers. However, because the applications that run on the microcomputer are software, the microcomputers can run out of special situations such as resource shortages, infinite loops, and noise. May be difficult to operate normally. Therefore, a technique is considered in which the microcomputer executes an abnormality detection program to detect that the microcomputer is not operating normally (see, for example, Patent Document 1). Patent Document 1 discloses an abnormality detection method for detecting an application abnormality from application operation information (process operation status, state duration, context switch count) acquired from an operating system. However, in the method using such an abnormality detection program, it is difficult to confirm whether or not a specific task such as register operation is being executed. In addition, since the microcomputer executes the abnormality detection program separately from the application, there is a problem that the load on the microcomputer is large.

In addition, a technique for detecting that the microcomputer is not operating normally by providing a monitoring microcomputer for monitoring the microcomputer is used.
FIG. 1 is a diagram illustrating an example of a conventional microcomputer monitoring system. A monitoring microcomputer connected to the microcomputer is arranged on the electronic control unit. This monitoring microcomputer monitors the microcomputer in the same manner as a so-called watchdog timer. The microcomputer periodically sets a flag in the register of the monitoring microcomputer, and the monitoring microcomputer measures an elapsed time after the flag is set. When the elapsed time exceeds the threshold, the monitoring microcomputer detects that the microcomputer is not operating normally, and resets the microcomputer, for example.

JP 2006-277115 A

  However, when a monitoring microcomputer is provided as shown in FIG. 1, it may be difficult to reset the microcomputer at an appropriate timing. This is because the microcomputer and the monitoring microcomputer communicate with each other using relatively low-speed serial communication or the like, and it takes a certain amount of time when the monitoring microcomputer tries to reset.

  In addition, mounting the monitoring microcomputer separately from the microcomputer causes an increase in cost and in-vehicle space, and there is a problem that man-hours are required for developing software to be mounted for the monitoring microcomputer. This is because the microcomputer and the monitoring microcomputer have different designs, and it is necessary to prepare a development environment for the monitoring microcomputer separately from the microcomputer.

  In view of the above problems, the present invention provides an electronic control unit and an abnormality detection method capable of mounting a monitoring microcomputer without causing an increase in cost and in-vehicle space and reducing communication time between the microcomputer and the monitoring microcomputer. For the purpose.

  In view of the above problems, the present invention is virtually constructed in an electronic control unit that provides a calculation result to an in-vehicle device, a virtual CPU, and a virtual CPU construction means for constructing a virtual CPU from the real CPU. The first virtual CPU has a first virtual CPU and a second virtual CPU, and the second virtual CPU monitors the first virtual CPU that provides the calculation result.

  It is possible to provide an electronic control unit and an abnormality detection method capable of mounting a monitoring microcomputer without causing an increase in cost and in-vehicle space and reducing communication time between the microcomputer and the monitoring microcomputer.

It is a figure which shows an example of the conventional microcomputer monitoring system. It is an example of the figure which illustrates notionally the structure of an electronic control unit. It is an example of the schematic block diagram of ECU (Example 1). It is an example of the flowchart figure which shows the procedure in which ECU detects abnormality (Example 1). It is an example of the schematic block diagram of an abnormality detection system (Example 2). It is an example of the functional block diagram of ECU. It is an example of the flowchart figure which shows the procedure in which one ECU detects the abnormality of the other ECU. It is an example of the schematic block diagram of ECU which has three virtual CPUs (Example 3). FIG. 10 is an example of a flowchart illustrating a procedure for detecting abnormality by an ECU using logical product as logic (Example 3); FIG. 10 is an example of a flowchart illustrating a procedure for detecting an abnormality using an logical OR as a logic (Embodiment 4); (Example 4) which is an example of the schematic block diagram of ECU which detects abnormality by majority vote. (Example 5) which is an example of the figure which shows ECU which detects abnormality by a WDT unit. An example of a flowchart showing a procedure for detecting an abnormality of the VCPU (A) 1 by the WDT unit is shown (Example 5). (Example 6) which is an example of the schematic block diagram of ECU which switches the virtual CPU which monitors VCPU (A) 1 periodically. (Example 6) which is an example of the flowchart figure which shows the procedure which switches virtual CPU which ECU monitors periodically. (Example 6) which is an example of the flowchart figure which shows the procedure which switches the role of virtual CPU which ECU monitors periodically. (Example 7) which is an example of the schematic block diagram of ECU100 which switches the virtual CPU which monitors VCPU (A) 1 aperiodically. (Example 7) which is an example of the flowchart figure which shows the procedure which switches virtual CPU which ECU monitors aperiodically. (Example 7) which is an example of the flowchart figure which shows the procedure which switches the role of virtual CPU which ECU monitors periodically. FIG. 10 is an example of a schematic configuration diagram of an ECU that detects an abnormality by majority vote (Embodiment 8). FIG. 10 is an example of a schematic configuration diagram of an ECU that detects an abnormality by majority decision of monitoring results of three or more virtual CPUs (Embodiment 8). (Example 9) which is an example of the schematic block diagram of an abnormality detection system. (Example 10) which is an example of the schematic block diagram of an abnormality detection system. (Example 11) which is an example of the schematic block diagram of ECU equipped with the virtual CPU which further monitors the monitoring virtual CPU. (Example 11) which shows an example of the flowchart figure which shows the procedure in which ECU detects abnormality. (Example 12) which is an example of the schematic block diagram of ECU100 which detects abnormality of VCPU (A) 1 and VCPU (A) 2 by the actual monitoring microcomputer.

  Hereinafter, the best mode for carrying out the present invention will be described with reference to the drawings.

  FIG. 2 is an example of a diagram conceptually illustrating the structure of the electronic control unit of the present embodiment. An electronic control unit (hereinafter referred to as an ECU (Electronic Control Unit)) has a hierarchical structure of a hardware resource 11, an OS (Operating System) 15, and an application 16 in order from the lower layer.

  The hardware resource 11 is, for example, a CPU, I / O, RAM, ROM, ASIC (Application Specific Integrated Circuit), switch element, CAN communication unit (COM1), etc. The CPU may be a multi-core type or a single-core type. .

  In this embodiment, the hardware resource has the virtual CPU monitor 12. The virtual CPU monitor 12 provides virtual hardware resources 11 to a plurality of OSs 15 to arbitrate use requests from the OSs 15 so that the hardware resources 11 do not compete with each other. The OS 15 operates by recognizing the virtual hardware resource 11 as physical hardware.

  As such a virtual CPU mounting method, a hardware multithread type execution environment is known. The hardware multithread means a structure in which a plurality of instruction buffers and register files are provided, and instructions are executed by switching the connection between these and an ALU (Arithmetic Logic Unit). Therefore, even if referred to as a “virtual” CPU, the operation result is provided by a physically existing circuit.

  The general OS 15 requests the hardware resource (especially the CPU) 11 to execute its code in the highest privilege mode, and the application 16 requests to execute the code in the low privilege mode. The virtual CPU monitor 12 is executed on the hardware resource 11 in a privilege mode that is higher than the highest privilege mode in which the OS 15 is normally executed. When the virtual CPU monitor 12 is executed in such a special privilege mode, the virtual CPU monitor 12 sends information indicating that the OS 15 is executed in the highest privilege mode to the OS 15. Thus, it appears to the OS 15 that the OS 15 is being executed in the highest privilege mode.

  By doing so, the virtual CPU monitor 12 receives a privileged instruction for directly controlling the hardware resource 11 requested to be executed by the OS 15, so that a conflict between the OSs can be avoided. Therefore, the OS 15 seems to monopolize the hardware resource 11, which is equivalent to the fact that each OS 15 has a virtual CPU (hereinafter referred to as a virtual CPU 13). The virtual CPU 13 is expressed as VCPU (Virtual CPU) in the following embodiments.

  As described above, since the plurality of virtual CPUs 13 can share the hardware resource 11, a plurality of OSs 15 can be executed simultaneously. Although there are only two OSs 15 in the figure, three or more OSs 15 can be executed with the same structure as in FIG.

  The virtual CPU monitor 12 is executed by the hardware resource 11 by switching the OS 15 as appropriate. This is because when the hardware resource 11 is limited (for example, when there is only one CPU), only one OS 15 is operating at a certain moment.

  For example, when the OS 15 to be executed is switched from one OS (A) 1 to the other OS (A) 2 every time or in response to a request from the OS 15, the virtual CPU monitor 12 displays all register values ( Save the program counter, instruction register, general-purpose register, etc. (switch the register file to be used). The data structure to be stored is the virtual CPU control structure 14, which has storage areas for register values when the OS 15 is executed and register values when the virtual CPU monitor 12 is executed. When switching the OS 15, the virtual CPU monitor 12 saves the register value of one OS (A) 1 to the virtual CPU control structure 14 and transfers the contents of the virtual CPU control structure 14 of the other OS (A) 2 to the register. Perform a series of processing to return.

  Since this register saving / restoring process is performed in hardware, it is completed in one to several clocks. Therefore, conventionally, for example, switching from one virtual CPU (A) 1 to the other virtual CPU (A) 2 is completed in a very short time compared to the case where the OS 15 performs context switching. For this reason, a plurality of (virtual) CPUs or OSs 15 appear to operate simultaneously from the outside.

  The OS 15 may be a general-purpose OS such as OSEK (Open system together with interfaces for automotive electronics), μITRON, LINUX, or may be an OS designed uniquely. Various applications 16 run on the OS 15. In this embodiment, in order to detect that the application 16 is not operating normally, at least one application 16 becomes the monitoring program (A) 2. The monitored application (A) 1 is, for example, a program for engine control, brake control, transmission control, travel motor control, and navigation. In the following description, the program for performing the actual processing is simply referred to as application (A) 1, and the program for detecting that it is not operating normally is referred to as monitoring program (A) 2. Further, detecting that the device is not operating normally is simply referred to as “detecting an abnormality”.

  FIG. 3A shows an example of a schematic configuration diagram of the ECU 100. The ECU 100 has a microcomputer mounted on a substrate as an entity, and the microcomputer includes a CPU (A) and a COM1. The CPU (A) and COM1 have the hardware resource 11 as an entity. The hardware resources 11 such as RAM and I / O are omitted. The COM 1 is a communication unit that is connected to the in-vehicle LAN 17 such as CAN (Controller Area Network), FlexRay, or LIN (Local Interconnect Network) and communicates with other ECUs 100.

  VCPU (A) 1 and VCPU (A) 2 described on the CPU (A) are virtual CPUs 13. That is, VCPU (A) 1 and VCPU (A) 2 are virtual CPUs that appear to exist from, for example, the OS 15, the application (A) 1, or the monitoring program (A) 2. In FIG. 3A, it is assumed that the application (A) 1 is executed on the VCPU (A) 1 and the monitoring program (A) 2 is executed on the VCPU (A) 2.

  The monitoring program (A) 2 is used when the application (A) 1 running on the VCPU (A) 1 is not operating normally due to some reason such as resource shortage, infinite loop, deadlock, etc. A reset request is output to VCPU (A) 1. The reset request refers to, for example, activating the hardware reset terminal of the VCPU (A) 1. That is, only the VCPU (A) 1 can be reset in hardware. Whether the VCPU (A) 1 is operating normally is determined by the VCPU (A) 2 depending on whether the VCPU (A) 1 is accessing the VCPU (A) 2 register (VCPU (A) 2_checkreg21) at regular intervals. . When VCPU (A) 1 is not accessing VCPU (A) 2_checkreg21 at a constant cycle, VCPU (A) 2 resets VCPU (A) 1.

  FIG. 3B shows an example of a functional block diagram of the ECU 100. The functional block diagram of FIG. 3B is realized by the VCPU (A) 1 executing the application (A) 1 and the VCPU (A) 2 executing the monitoring program (A) 2.

  The actual processing unit 61A is a block for executing the original processing of the application (A) 1. The writing unit 62A writes the predetermined value “FFh” (h: hexadecimal) in the VCPU (A) 2_checkreg21 of the VCPU (A) 2. If the writing is not performed within a certain period, an abnormality is detected. Therefore, the writing unit 62A is repeatedly called at a certain period and executed by being called from the actual processing unit 61A. The called writing unit 62A writes the predetermined value “FFh” in the VCPU (A) 2_checkreg 21 and returns the process to the actual processing unit 61A. Therefore, if the actual processing unit 61A is operating normally, the writing unit 62A can write the predetermined value “FFh” in the VCPU (A) 2_checkreg21. On the other hand, when the actual processing unit 61A is not operating normally, the writing unit 62A is not called, so that the predetermined value “FFh” cannot be written to the VCPU (A) 2_checkreg21 within a certain period.

  The register value detection unit 64A detects the value of VCPU (A) 2_checkreg21 immediately after the writing unit 62A writes the predetermined value “FFh” in the VCPU (A) 2_checkreg21, and determines whether “FFh” is written. judge. Immediately after the writing by the writing unit 62A, the register value detecting unit 64A detects the value of VCPU (A) 2_checkreg21, so that the register value detecting unit 64A is synchronized with the writing unit 62A. Then, the register value detection unit 64A detects the value of the VCPU (A) 2_checkreg21 at the same constant cycle as the write with a slight delay from the write timing.

  When “FFh” is written in the VCPU (A) 2_checkreg21, the register value detection unit 64A requests the register value initialization unit 66A to initialize the VCPU (A) 2_checkreg21. The register value initialization unit 66A writes “00h” in the VCPU (A) 2_checkreg21.

  When the register value detection unit 64A detects that “00h” is written in the VCPU (A) 2_checkreg 21, the register value detection unit 64A requests the reset unit 65A to reset the VCPU (A) 1. The reset unit 65A resets the VCPU (A) 1. As a method of applying the reset, the reset may be performed by hardware as described above, or a reset by software (only VCPU (A) 1 is reset by writing a value in the software reset register) may be used.

  FIG. 4 is an example of a flowchart illustrating a procedure in which the ECU 100 according to the present embodiment detects an abnormality. The procedure of FIG. 4 is repeatedly started at regular intervals when, for example, the ignition is turned on or the main system is turned on in the case of an electric vehicle or a hybrid vehicle. The start timing is common to the following embodiments.

  First, the writing unit 62A of the VCPU (A) 1 writes “FFh” to the VCPU (A) 2_checkreg 21 of the VCPU (A) 2 at regular intervals (S10).

  The register value detection unit 64A of the VCPU (A) 2 determines whether “FFh” is written in the VCPU (A) 2_checkreg 21 (S20).

  When “FFh” is written in VCPU (A) 2_checkreg21 (Yes in S20), VCPU (A) 1 is accessing VCPU (A) 2_checkreg21 at regular intervals, so VCPU (A) The register value initialization unit 66A of 2 writes “00h” in the VCPU (A) 2_checkreg 21 (S30). Thereafter, the VCPU (A) 2 stands by for a certain period (S40).

  When “FFh” is not written in VCPU (A) 2_checkreg21 (N0 in S20), VCPU (A) 1 does not access VCPU (A) 2_checkreg21 at regular intervals, so VCPU (A) The second reset unit 65A resets the VCPU (A) 1 (S50). As a result, the VCPU (A) 1 is restarted. Thereafter, the process of FIG. 4 is repeated (S60). Note that VCPU (A) 2 does not reset VCPU (A) 1 during restart even after a fixed period has elapsed. This prevents repeated resets.

  As described above, the ECU 100 according to the present embodiment can monitor whether or not the application (A) 1 is normally executed without using a physical monitoring microcomputer. Since VCPU (A) 1 and VCPU (A) 2 have the same hardware resource 11, even if they are a plurality of CPUs in terms of function, there is no increase in in-vehicle space. The virtual CPU 13 may be used only on the monitoring side. However, since the VCPU (A) 1 and VCPU (A) 2 have the same hardware resource 11, the monitoring side and the monitoring CPU are both selected. By using the virtual CPU 13 as well, it is not necessary to mount a physical CPU to be monitored, and the in-vehicle space can be used more efficiently.

  In addition, since VCPU (A) 1 and VCPU (A) 2 share the same hardware resource 11, the communication speed between VCPU (A) 2 and VCPU (A) 1 becomes high. Therefore, the VCPU (A) 2 can reset the VCPU (A) 1 in a short time after the abnormality is detected.

  FIG. 5 shows an example of a schematic configuration diagram of the abnormality detection system 200 of the present embodiment. In FIG. 5, the same parts as those in FIG. In FIG. 5, ECU 100A and ECU 100B are connected via LAN1. Among these, the configuration of the ECU 100A is the same as that in FIG.

  The ECU 100B has the microcomputer 2 mounted on the board as a substance, and the microcomputer 2 has a CPU (B) and a COM2. VCPU (B) 1 and VCPU (B) 2 on CPU (B) are virtual CPUs 13. Therefore, VCPU (B) 1 and VCPU (B) 2 are virtual CPUs that appear to exist from, for example, the OS 15, the application (A) 1, or the monitoring program (A) 2. 5A and 5B, it is assumed that the application (A) 1 is executed on the VCPU (B) 1 and the monitoring program (A) 2 is executed on the VCPU (B) 2.

In this configuration, in this embodiment, the ECU 100B detects an abnormality in the ECU 100A, and the ECU 100A detects an abnormality in the ECU 100B.
FIG. 6 shows an example of a functional block diagram of the ECU 100. In FIG. 6, the same parts as those in FIG. 3B are denoted by the same reference numerals, and the description thereof is omitted.

  The writing unit 62A of the VCPU (A) 1 writes the predetermined value “FFh” into the VCPU (B) 2_checkreg 22 of the VCPU (B) 2. The implementation of the writing unit 62A is the same as that of the first embodiment, but the writing unit 62A writes via the LAN 1, so the writing unit 62A transmits a frame storing information for writing from the COM 1 to the ECU 100. If the actual processing unit 61A is operating normally, the writing unit 62A can write the predetermined value “FFh” in the VCPU (B) 2_checkreg 22 at regular intervals. When the actual processing unit 61A is not operating normally, the writing unit 62A cannot write the predetermined value “FFh” into the VCPU (B) 2_checkreg22 within a certain period.

  The register value detection unit 64B of the VCPU (B) 2 detects the value of the VCPU (B) 2_checkreg22 immediately after the writing unit 62A writes the predetermined value “FFh” to the VCPU (B) 2_checkreg22, and writes “FFh”. It is determined whether or not. The register value detection unit 64B determines the write timing with the write unit 62A in order to detect the value of VCPU (B) 2_checkreg22 immediately after the write. Then, the register value detection unit 64B assumes a delay time due to the communication time via the LAN 1, and detects the value of the VCPU (B) 2_checkreg22 at a constant cycle with a slight delay from the determined timing.

  When “FFh” is written in VCPU (B) 2_checkreg22, the register value detection unit 64B requests the register value initialization unit 66B to initialize the VCPU (B) 2_checkreg22. The register value initialization unit 66B writes “00h” in the VCPU (B) 2_checkreg22.

  When the register value detection unit 64B detects that “00h” is written in the VCPU (B) 2_checkreg 22, the register value detection unit 64B requests the reset unit 65B to reset the VCPU (A) 1. The reset unit 65B resets the VCPU (A) 1. The reset method may be a hardware reset, but since it is via the LAN 1, it is preferable to use a software reset.

  Further, the writing unit 62B of the VCPU (B) 1 writes a predetermined value “FFh” into the VCPU (A) 2_checkreg 21 of the VCPU (A) 2 at regular intervals. If the actual processing unit 61B is operating normally, the writing unit 62B can write the predetermined value “FFh” in the VCPU (A) 2_checkreg21. When the actual processing unit 61B is not operating normally, the writing unit 62B cannot write the predetermined value “FFh” to the VCPU (A) 2_checkreg21 within a certain period.

  The register value detection unit 64A detects the value of the VCPU (A) 2_checkreg21 immediately after the writing unit 62B writes the predetermined value “FFh” in the VCPU (A) 2_checkreg21 to determine whether “FFh” is written. judge. The method of determining the timing of “immediately after writing” is the same as that of the register value detection unit 64B of the VCPU (B) 2.

  When “FFh” is written in the VCPU (A) 2_checkreg21, the register value detection unit 64A requests the register value initialization unit 66A to initialize the VCPU (A) 2_checkreg21. The register value initialization unit 66A writes “00h” in the VCPU (A) 2_checkreg21. When the register value detection unit 64A detects that “00h” is written in the VCPU (A) 2_checkreg 21, the register value detection unit 64A requests the reset unit 65A to reset the VCPU (B) 1. The reset unit 65A resets VCPU (B) 1. The reset method may be a hardware reset, but since it is via the LAN 1, it is preferable to use a software reset.

  Thus, even if the application (A) 1 and the monitoring program (A) 2 increase, the configuration of the application (A) 1 and the monitoring program (A) 2 is the same only by changing the location and number of the virtual CPU 13. can do.

  FIG. 7A is an example of a flowchart illustrating a procedure in which the ECU 100B detects an abnormality in the ECU 100A. First, the writing unit 62A of the VCPU (A) 1 writes “FFh” to the VCPU (B) 2_checkreg22 of the VCPU (B) 2 at regular intervals (S10). The register value detection unit 64B of VCPU (B) 2 detects the value of VCPU (B) 2_checkreg22 at regular intervals, and determines whether “FFh” is written (S20).

  When “FFh” is written in VCPU (B) 2_checkreg22 (Yes in S20), the register value initialization unit 66B of VCPU (B) 2 writes “00h” in VCPU (B) 2_checkreg22 (S30). Thereafter, the VCPU (B) 2 is on standby for a certain period (S40). Thereafter, VCPU (B) 2 returns to the original state (return).

  When “FFh” is not written in VCPU (B) 2_checkreg22 (No in S20), the reset unit 65B of VCPU (B) 2 resets VCPU (A) 1 (S50). Since VCPU (A) 1 restarts, VCPU (A) 1 returns to its original state (return). Thereafter, the process of FIG. 7A is repeated (S60).

  FIG. 7B is an example of a flowchart illustrating a procedure when the ECU 100A detects an abnormality in the ECU 10B. Similarly, the writing unit 62B of the VCPU (B) 1 writes “FFh” to the VCPU (A) 2_checkreg 21 of the VCPU (A) 2 at regular intervals (S10). The register value detector 64A of the VCPU (A) 2 detects the value of the VCPU (A) 2_checkreg21 at regular intervals, and determines whether “FFh” is written (S20).

  When “FFh” is written in the VCPU (A) 2_checkreg 21 (Yes in S20), the register value initialization unit 66A of the VCPU (A) 2 writes “00h” in the VCPU (A) 2_checkreg 21 (S30). Thereafter, the VCPU (A) 2 stands by for a certain period (S40). Thereafter, the VCPU (A) 2 returns to the original state (return).

  When “FFh” is not written in the VCPU (A) 2_checkreg 21 (No in S20), the reset unit 65A of the VCPU (A) 2 resets the VCPU (B) 1 (S50). Since VCPU (B) 1 restarts, VCPU (B) 1 returns to its original state (return). Thereafter, the process of FIG. 7B is repeated (S60).

  According to the present embodiment, in addition to the effects of the first embodiment, an abnormality can be detected between the two ECUs 100A and 100A connected via the LAN1. Even if an abnormality occurs in one ECU 100A due to noise and an abnormality occurs not only in the application (A) 1, but also in the monitoring program (A) 2, the abnormality in the application (A) 1 is caused by the monitoring program (A) 2 of the other ECU 100B. Therefore, reliability can be improved.

  In the present embodiment, an ECU 100 that detects an abnormality of one virtual CPU 13 by two virtual CPUs 13 will be described.

FIG. 8A and FIG. 8B show an example of a schematic configuration diagram of the ECU 100 having three virtual CPUs 13. In FIG. 8, VCPU (A) 1 executes application (A) 1, and VCPU (A) 2 and VCPU (A) 3 execute monitoring program (A) 2. Then, the ECU 100 detects an abnormality with one of the following logics.
(1) Logical product (2) Logical sum

〔Logical AND〕
FIG. 8A is a diagram showing the ECU 100 that detects an abnormality by logical product. VCPU (A) 2 is connected to the AND circuit 23, and VCPU (A) 3 is also connected to the AND circuit 23. The AND circuit 23 and VCPU (A) 1 are connected.

  First, the VCPU (A) 1 writes “FFh” in the VCPU (A) 2_checkreg 21 of the VCPU (A) 2 at regular intervals. Further, the VCPU (A) 1 writes “FFh” in the VCPU (A) 3_checkreg 24 of the VCPU (A) 3 at regular intervals.

  VCPU (A) 2 detects the value of VCPU (A) 2_checkreg21 at regular intervals, and determines whether “FFh” is written. When “FFh” is not written, the VCPU (A) 2 inputs a reset request (A) 2 to the AND circuit 23. Similarly, VCPU (A) 3 detects the value of VCPU (A) 3_checkreg 24 at regular intervals to determine whether “FFh” is written. When “FFh” is not written, the VCPU (A) 3 inputs a reset request (A) 3 to the AND circuit 23.

  The AND circuit 23 outputs a reset request to the VCPU (A) 1 when both the reset request (A) 2 and the reset request (A) 3 are input. Therefore, the ECU 100A in FIG. 8A can make the logical product the abnormality detection logic.

  The AND circuit 23 is included in the hardware resource 11. Further, the AND circuit 23 may be implemented in software by the VCPU (A) 2 or VCPU (A) 3. In this case, the monitoring program (A) 2 of the VCPU (A) 2 or VCPU (A) 3 monitors two flags, for example, and outputs a reset request to the VCPU (A) 1 when both are turned on.

  FIG. 9 is an example of a flowchart illustrating a procedure in which the ECU 100A detects an abnormality using a logical product as a logic.

  First, the VCPU (A) 1 writes “FFh” to the VCPU (A) 2_checkreg 21 of the VCPU (A) 2 at regular intervals (S10A). Immediately after VCPU (A) 1 writes “FFh” to VCPU (A) 2_checkreg 21 of VCPU (A) 2, it is determined whether or not “FFh” is written to VCPU (A) 2_checkreg21. (S20A).

  When “FFh” is written in the VCPU (A) 2_checkreg 21 (Yes in S20A), the VCPU (A) 2 writes “00h” in the VCPU (A) 2_checkreg21 (S30A). When “FFh” is not written in the VCPU (A) 2_checkreg 21 (No in S20A), the VCPU (A) 2 outputs a reset request (A) 2 to the AND circuit 23 (S40A).

  Further, the VCPU (A) 1 writes “FFh” to the VCPU (A) 3_checkreg 24 of the VCPU (A) 3 at regular intervals (S10B). The timing at which VCPU (A) 1 writes “FFh” in VCPU (A) 2_checkre 21 and VCPU (A) 3_checkreg 24 is preferably the same, but is adjusted so as not to deviate at least a certain period. If the value of VCPU (A) 2_checkreg21 is not “FFh”, VCPU (A) 2 issues a reset request (A) 2 at regular intervals, and VCPU (A) 3 indicates that the value of VCPU (A) 3_checkreg24 is “FFh” If there is not, the reset request (A) 3 is output every fixed period, so that the abnormality can be detected within the fixed period even if the logical product is adopted in the logic.

  Immediately after VCPU (A) 1 writes “FFh” to VCPU (A) 3_checkreg 24 of VCPU (A) 3, VCPU (A) 3 determines whether “FFh” is written to VCPU (A) 3_checkreg24 (S20B).

  When “FFh” is written in the VCPU (A) 3_checkreg 24 (Yes in S20B), the VCPU (A) 3 writes “00h” in the VCPU (A) 3_checkreg 24 (S30B). When “FFh” is not written in the VCPU (A) 3_checkreg 24 (No in S20B), the VCPU (A) 3 outputs a reset request (A) 3 to the AND circuit 23 (S40B).

  As a result, when the AND circuit 23 is turned on (Yes in S50), the AND circuit outputs a reset request to the VCPU (A) 1, and the VCPU (A) 1 is restarted (S60). If the AND circuit 23 is not turned on (No in S50), no reset request is output to the VCPU (A) 1. In this case, VCPU (A) 1, VCPU (A) 2, and VCPU (A) 3 are on standby for a certain period (S70). When VCPU (A) 1 is restarted (S60), VCPU (A) 1 returns to the original state (return). Further, after waiting for a certain period (S70), VCPU (A) 1, VCPU (A) 2, and VCPU (A) 3 return to their original states (return).

  In this way, by using the logical product as the abnormality detection logic, it is possible to reset the VCPU (A) 1 only when there is a high possibility that an abnormality has occurred. For example, it is suitable for logic that resets the ECU 100A that executes control in which sudden restart is not preferable. That is, since the ECU 100A is restarted only when there is an obvious abnormality, the availability of the ECU 100 can be improved.

[Logical sum]
FIG. 8B is a diagram showing the ECU 100 that detects an abnormality by a logical sum. In FIG. 8B, the same parts as those in FIG. VCPU (A) 2 is connected to the OR circuit 25, and VCPU (A) 3 is also connected to the OR circuit 25. The OR circuit 25 and VCPU (A) 1 are connected.

  First, the VCPU (A) 1 writes “FFh” in the VCPU (A) 2_checkreg 21 of the VCPU (A) 2 at regular intervals. Further, the VCPU (A) 1 writes “FFh” in the VCPU (A) 3_checkreg 24 of the VCPU (A) 3 at regular intervals.

  The OR circuit 25 outputs a reset request to the VCPU (A) 1 when either or both of the reset request (A) 2 and the reset request (A) 3 are input. Therefore, the ECU 100A in FIG. 8B can set the logical sum to the abnormality detection logic.

  The OR circuit 25 is included in the hardware resource 11. In addition, the OR circuit 25 may be implemented in software by the VCPU (A) 2 or VCPU (A) 3. In this case, the monitoring program (A) 2 of the VCPU (A) 2 or VCPU (A) 3 monitors, for example, two flags and outputs a reset request to the VCPU (A) 1 when one or both of them are turned on. .

  FIG. 10 is an example of a flowchart illustrating a procedure in which the ECU 100 detects an abnormality using a logical sum as logic. In FIG. 10, the description of the same steps as in FIG. 9 is omitted. The processes from step S10A, S10B to S40A, S40B are the same as those in FIG.

  If the OR circuit 25 is turned on as a result of the processing up to S40 (Yes in S50), a reset request is output to the VCPU (A) 1, and the VCPU (A) 1 is restarted (S60). While VCPU (A) 1 is restarting, VCPU (A) 2 does not output reset request (A) 2, but VCPU (A) 3 outputs reset request (A) 3 There is nothing.

  If the OR circuit 25 is not turned on (No in S50), no reset request is output to the VCPU (A) 1. In this case, VCPU (A) 1, VCPU (A) 2, and VCPU (A) 3 are on standby for a certain period (S70). When VCPU (A) 1 is restarted (S60), VCPU (A) 1 returns to the original state (return). Further, after waiting for a certain period (S70), VCPU (A) 1, VCPU (A) 2, and VCPU (A) 3 return to their original states (return).

  Thus, by adopting the logical sum as the abnormality detection logic, for example, the VCPU (A) 1 of the ECU 100 that executes control that may be suddenly restarted can be reset early. That is, when there is a possibility of abnormality, the ECU 100 is restarted, so that the reliability of the ECU 100 can be improved.

  In the third embodiment, an abnormality is detected by the logical product or logical sum of the outputs of the two VCPU (A) 2 and VCPU (A) 3, but three or more virtual CPUs (VCPU (A) 2, VCPU (A) 3 ,..., VCPU (A) n) 13 is applied with logical product or logical sum logic to detect VCPU (A) 1 abnormality, and VCPU (A) 1 if any of the above is detected. May be reset. In this case, it is only necessary to connect the AND circuit 23 or the OR circuit 25 to each virtual CPU 13.

  Further, the ECU 100 determines the majority of outputs of VCPU (A) 2 to VCPU (A) n when a large number of virtual CPUs 13 are related to VCPU (A) 1 as in VCPU (A) 2 to VCPU (A) n. Therefore, an abnormality can be detected.

  FIG. 11 is an example of a diagram illustrating the ECU 100 that detects an abnormality by majority vote. In FIG. 11, the same parts as those in FIG. VCPU (A) 2, VCPU (A) 3,..., VCPU (A) n are connected to the majority circuit 27.

  The majority circuit 27 counts the number of reset requests (A) 2, reset requests A (3),... Reset requests (A) n (hereinafter referred to as the number of reset requests) input within a certain period. When the number of reset requests is equal to or greater than a predetermined value (for example, half of the number of VCPU (A) 2 etc.), the majority circuit 27 outputs a reset request to VCPU (A) 1. The predetermined value is stored in the majority circuit 27 in advance. The majority circuit 27 counts the number of reset requests input within a certain period and outputs a comparison result with a predetermined value. If the result is less than the predetermined value, the process of clearing the counted number of reset requests is repeated. By doing so, the majority circuit 27 can determine whether to reset the VCPU (A) 1 by majority vote at regular intervals. Note that the majority circuit 27 is also included in the hardware resource 11. The majority circuit 27 may be implemented by software.

  Note that the flowchart is omitted in FIG. 9 or FIG. 10 because the process of step S50 is only “Has the majority vote been established?”.

  According to the ECU 100 of the present embodiment, the abnormality is detected by the majority vote based on the outputs of the n VCPUs (A), so it is possible to accurately determine whether there is an abnormality. In addition, by changing the predetermined value, it is possible to adjust the VCPU (A) 1 so that it is easy to reset and improve the reliability, or it is difficult to reset and the availability is improved.

  The abnormality detection method described so far has an affinity with the watchdog timer (WDT). Therefore, in this embodiment, the ECU 100 that realizes WDT by configuring the WDT unit 18 to reset the VCPU (A) 1 will be described.

  FIG. 12 is an example of a diagram illustrating the ECU 100 that detects an abnormality by the WDT unit 18. The WDT unit 18 of FIG. 12 includes a reset circuit (not shown) that outputs a WDT_reg 28 and a reset request to the VCPU (A) 1. The WDT unit 18 stores a timer value corresponding to the fixed period described in the previous embodiments. The WDT unit 18 continues to measure time, but when “FFh” is written in the WDT_reg 28, the measured time is once set to zero and the time measurement is resumed. If the measured time exceeds the timer value before “FFh” is written to WDT_reg 28, WDT unit 18 outputs a reset signal to VCPU (A) 1.

  In FIG. 12, the WDT unit 18 is arranged in the VCPU (A) 2. Since the WDT unit 18 is independent hardware such as an IC, the entity is included in the hardware resource 11. In general ECU 100, WDT unit 18 is often not mounted in a microcomputer, but is mounted on an integrated IC in which a plurality of ICs are integrated.

  FIG. 13 shows an example of a flowchart showing a procedure for detecting an abnormality of the VCPU (A) 1 by the WDT unit 18.

  The VCPU (A) 1 writes “FFh” in the WDT_reg 28 of the WDT unit 18 at regular intervals (S10). The WDT unit 18 determines whether “FFh” is written in (S20).

  When “FFh” is written in the WDT_reg 28 (Yes in S20), the WDT unit 18 returns the time measured so far to zero (S30).

  Next, the WDT unit 18 determines whether or not the measurement time is equal to or greater than a timer value (constant period) (S40). If the measurement time is equal to or greater than the timer value (Yes in S40), the WDT unit 18 resets the VCPU (A) 1 (S50). As a result, the VCPU (A) 1 is restarted (S60). When VCPU (A) 1 is restarted (S60), VCPU (A) 1 returns to the original state (return).

  If the measurement time is not equal to or greater than the timer value (No in S40), VCPU (B) 2 repeats the processing from step S20 (return).

  According to the present embodiment, the widely used WDT unit 18 can be realized by the virtual CPU 13.

  In the present embodiment, an ECU 100 that switches the virtual CPU 13 that periodically monitors the VCPU (A) 1 will be described. Generally, fixing the same processing to the same CPU is not preferable for monitoring because a load is concentrated on a specific circuit. Therefore, the load is prevented from being concentrated by switching the virtual CPU 13 to be monitored.

  FIG. 14A shows an example of a schematic configuration diagram of the ECU 100 that switches the virtual CPU 13 that monitors the VCPU (A) 1. In FIG. 14 (a), the same parts as those in FIG. 8 (b) are denoted by the same reference numerals and description thereof is omitted. The ECU 100 has a VCPU (A) 2 and a VCPU (A) 3 for monitoring, but only one of them is active and the other is inactive. Active means that the virtual CPU 13 is executing a series of processes of monitoring the VCPU (A) 2_checkreg 21, writing “00h”, and outputting a reset request.

  There are several methods for switching between VCPU (A) 2 and VCPU (A) 3. For example, a timer interrupt is used. The timer generates timer interrupts to VCPU (A) 1, VCPU (A) 2, and VCPU (A) 3 for each switching time. When VCPU (A) 2 is active, VCPU (A) 1 that detected the timer interrupt switches the write destination of “FFh” from VCPU (A) 2 to VCPU (A) 3. The VCPU (A) 2 that has detected the timer interrupt interrupts the execution of the monitoring program (A) 2. Further, the VCPU (A) 3 that has detected the timer interrupt starts execution of the monitoring program (A) 2. That is, by switching the monitoring program (A) 2 of the VCPU (A) 2 and the monitoring program (A) 2 of the VCPU (A) 3 to, for example, a standby state and an execution state in task scheduling, the VCPU (A) 2 Only one of VCPU (A) 3 can be active. Such switching can generally be realized by using the scheduler function of the virtual CPU monitor 12.

  FIG. 15 shows an example of a flowchart showing a procedure for switching the virtual CPU 13 monitored by the ECU 100. Until the timer interrupt occurs, VCPU (A) 1 executes application (A) 1, and VCPU (A) 2 executes monitoring program (A) 2.

  When the timer generates a timer interrupt (S10), VCPU (A) 1 switches the write destination of “FFh” from VCPU (A) 2 to VCPU (A) 3 (S20). Thereafter, the VCPU (A) 1 repeats this process, and switches the write destination of “FFh” from the VCPU (A) 3 to the VCPU (A) 2 (return → S20).

  When the timer generates a timer interrupt (S10), the VCPU (A) 2 interrupts the execution of the monitoring program (A) 2 (S30). Thereafter, the VCPU (A) 2 resumes the execution of the monitoring program (A) 2 (Return → S30).

  Further, the VCPU (A) 3 resumes the execution of the monitoring program (A) 2 (S40). Thereafter, the VCPU (A) 3 resumes the execution of the monitoring program (A) 2 (Return → S40).

  By doing so, it is possible to switch the virtual CPU that periodically monitors the VCPU (A) 1 and distribute the load.

  FIG. 14B shows an example of a schematic configuration diagram of the ECU 100. The ECU 100 in FIG. 14B monitors VCPU (A) 1 while switching the roles of VCPU (A) 2 and VCPU (A) 3.

  For example, in the left diagram of FIG. 14B, VCPU (A) 1 writes “FFh” in VCPU (A) 2_checkreg 21 of VCPU (A) 2 and VCPU (A) 3_checkreg 24 of VCPU (A) 3. The VCPU (A) 2 reads the value of the VCPU (A) 2_checkreg21 and determines whether “FFh” is written. The VCPU (A) 3 also reads the value of the VCPU (A) 3_checkreg 24 and determines whether “FFh” is written.

  As in the first embodiment, when “FFh” is not written in the VCPU (A) 2_checkreg 21, the VCPU (A) 2 resets the VCPU (A) 1. On the other hand, when “FFh” is not written in the VCPU (A) 3_checkreg 24, the VCPU (A) 3 requests the VCPU (A) 2 to perform processing associated with the occurrence of an event (hereinafter simply referred to as an event request). . This event request is a request for resetting the VCPU (A) 1. Therefore, the VCPU (A) 2 that has received the event request resets the VCPU (A) 1. That is, VCPU (A) 2 and VCPU (A) 3 are monitoring VCPU (A) 1 in multiple.

  The ECU 100 in FIG. 14 (b) switches the division of roles every time. The right figure of FIG.14 (b) has shown an example of ECU100 after switching the role. That is, the VCPU (A) 1 writes “FFh” in the VCPU (A) 2_checkreg 21 of the VCPU (A) 2 and the VCPU (A) 3_checkreg 24 of the VCPU (A) 3. The VCPU (A) 3 reads the value of the VCPU (A) 3_checkreg 24 and determines whether “FFh” is written. When “FFh” is not written in the VCPU (A) 3_checkreg 24, the VCPU (A) 3 resets the VCPU (A) 1. Also, the VCPU (A) 2 reads the value of the VCPU (A) 2_checkreg21 and determines whether “FFh” is written. If “FFh” is not written in the VCPU (A) 2_checkreg 21, the VCPU (A) 2 requests an event from the VCPU (A) 3. Receiving the event request, VCPU (A) 3 resets VCPU (A) 1. The event request is a kind of interrupt, for example.

  Such switching of roles can also be realized by using a timer interrupt, for example. There is no change in the processing of VCPU (A) 1 that detected the timer interrupt. On the other hand, the VCPU (A) 2 that has detected the timer interrupt performs the process when “FFh” is not written in the VCPU (A) 2_checkreg 21 from the process of resetting the VCPU (A) 1 to the VCPU (A) 2 A) Switch to the process that outputs to 3.

  The VCPU (A) 3 that has detected the timer interrupt performs processing when “FFh” is not written in the VCPU (A) 3_checkreg 24, and from processing that outputs an event request to the VCPU (A) 2, VCPU (A) 3 ) Switch to the process of resetting 1. Such switching of roles can be realized, for example, when the scheduler switches processing (tasks) of the monitoring program (A) 2 executed by the VCPU (A) 2 and VCPU (A) 3 by timer interruption.

  FIG. 16 shows an example of a flowchart showing a procedure for periodically switching the role of the virtual CPU 13 monitored by the ECU 100. In FIG. 16, the description of the same steps as those in FIG. 15 is omitted.

  When the timer generates a timer interrupt (S10), VCPU (A) 2 performs the process when “FFh” is not written in VCPU (A) 2_checkreg21, from the process of resetting VCPU (A) 1, to the event request. Is switched to the process of outputting to the VCPU (A) 3 (S30). Thereafter, VCPU (A) 1 notifies the interruption from the timer to VCPU (A) 3 and VCPU (A) 2 (return). The VCPU (A) 2 switches from the process of outputting the event request to the VCPU (A) 3 to the process of resetting the VCPU (A) 1 each time notification is made from the VCPU (A) 1 (Return → S30).

Further, the VCPU (A) 3 resets the VCPU (A) 1 from the process in which “FFh” is not written in the VCPU (A) 3 _checkreg 24 and from the process of outputting the event request to the VCPU (A) 2. Switch to processing (S40). The VCPU (A) 2 switches from the process of resetting the VCPU (A) 1 to the process of outputting an event request to the VCPU (A) 2 each time a notification is sent from the VCPU (A) 1 (Return → S40).
By doing so, it is possible to periodically switch multiple monitoring procedures and distribute the load.

  According to the ECU 100 of the present embodiment, the load can be distributed by periodically switching the virtual CPU 13 or the role that monitors the VCPU (A) 1. Further, since the VCPU (A) 1 is monitored in multiple, reliability is improved.

  In the present embodiment, an ECU 100 that performs the same switching as in the sixth embodiment aperiodically will be described.

  FIG. 17A shows an example of a schematic configuration diagram of the ECU 100 that switches the virtual CPU that monitors the VCPU (A) 1 aperiodically. In FIG. 17A, the same parts as those in FIG. 14A are denoted by the same reference numerals, and the description thereof is omitted. Although there is no difference in configuration, in FIG. 17A, a trigger for switching the active virtual CPU 13 is different from that in FIG. That is, in the sixth embodiment, the active virtual CPU 13 is switched periodically (for example, by timer interruption), but in this embodiment, the active virtual CPU 13 is switched by some event.

  There are various events, for example, hardware interrupt, occurrence of exception, detection of hook (a specific event specified by software is detected), and the like.

  The virtual CPU 13, OS 15, or application 16 that has detected such an event causes VCPU (A) 1, VCPU (A) 2, and VCPU (A) 3 to generate interrupts. Processing after the event has occurred is the same as that in the sixth embodiment.

  FIG. 18 shows an example of a flowchart showing a procedure for aperiodically switching the virtual CPU 13 monitored by the ECU 100. Until the event occurs, the VCPU (A) 1 executes the application (A) 1, and the VCPU (A) 2 and the VCPU (A) 3 execute the monitoring program (A) 2.

  The hardware resource 11, the application (A) 1 or the OS 15 detects the occurrence of an event, and generates an interrupt for each of the VCPU (A) 1, VCPU (A) 2 and VCPU (A) 3 (S10). As a result, the VCPU (A) 1 switches the write destination of “FFh” from VCPU (A) 2 to VCPU (A) 3 (S20). Thereafter, the VCPU (A) 1 repeats this process, and switches the write destination of “FFh” from VCPU (A) 3 to VCPU (A) 2 (Return → S20).

  The VCPU (A) 2 interrupts the execution of the monitoring program (A) 2 (S30). Thereafter, the VCPU (A) 2 resumes the execution of the monitoring program (A) 2 (Return → S30).

  Further, the VCPU (A) 3 resumes the execution of the monitoring program (A) 2 (S40). Thereafter, the VCPU (A) 3 resumes the execution of the monitoring program (A) 2 (Return → S40). By doing this, it is possible to switch the virtual CPU that monitors the VCPU (A) 1 aperiodically and distribute the load.

  FIG. 17B shows an example of a schematic configuration diagram of the ECU 100 that switches the role of the virtual CPU to be monitored aperiodically. In FIG. 17 (b), the same parts as those in FIG. 14 (b) are denoted by the same reference numerals, and the description thereof is omitted. The ECU 100 in FIG. 17B switches the roles of the VCPU (A) 2 and VCPU (A) 3 by the occurrence of an event in the same manner as the ECU 100 in FIG. Processing after the occurrence of an event is the same as in the sixth embodiment.

  FIG. 19 shows an example of a flowchart showing a procedure for aperiodically switching the role of the virtual CPU 13 monitored by the ECU 100.

  The hardware resource 11, the application (A) 1 or the OS 15 detects the occurrence of an event, and generates an interrupt for each of the VCPU (A) 1, VCPU (A) 2 and VCPU (A) 3 (S10).

  VCPU (A) 2 switches the process when “FFh” is not written in VCPU (A) 2_checkreg21 from the process of resetting VCPU (A) 1 to the process of outputting an event request to VCPU (A) 3 (S30). Thereafter, VCPU (A) 1 notifies the interruption from the timer to VCPU (A) 3 and VCPU (A) 2 (return). The VCPU (A) 2 switches from the process of outputting the event request to the VCPU (A) 3 to the process of resetting the VCPU (A) 1 each time notification is made from the VCPU (A) 1 (Return → S30).

  Further, the VCPU (A) 3 resets the VCPU (A) 1 from the process in which “FFh” is not written in the VCPU (A) 3_checkreg24, and from the process of outputting the event request to the VCPU (A) 2. Switch to processing (S40). The VCPU (A) 2 switches from the process of resetting the VCPU (A) 1 to the process of outputting an event request to the VCPU (A) 2 each time a notification is sent from the VCPU (A) 1 (Return → S40).

  By doing so, it is possible to switch the multiple monitoring procedures aperiodically and distribute the load.

  According to the ECU 100 of this embodiment, the load can be distributed by switching the virtual CPU 13 that monitors the VCPU (A) 1 or the role every time an event occurs. Further, since the VCPU (A) 1 is monitored in multiple, reliability is improved. Note that the virtual CPU 13 that monitors the VCPU (A) 1 may be switched periodically or aperiodically, or multiple monitoring procedures may be switched by combining the sixth embodiment and the present embodiment.

  As in the sixth or seventh embodiment, the configuration for switching the virtual CPUs 13 can be applied to three or more virtual CPUs 13.

  FIG. 20A is an example of a schematic configuration diagram of the ECU 100 that detects an abnormality by majority vote. In FIG. 20 (a), the same parts as those in FIG. Of the VCPU (A) 2, VCPU (A) 3,..., VCPU (A) n shown in the figure, one or more virtual CPUs 13 are always active, but one or more virtual CPUs 13 are not always active. For example, in the figure, an active virtual CPU 13 other than VCPU (A) n is used.

  The ECU 100 repeats the virtual CPU 13 that is active periodically or aperiodically. For example, when the switching time elapses, as shown in FIG. 20B, the ECU 100 activates VCPU (A) n and deactivates VCPU (A) 2. In this way, the VCPU (A) 1 can be monitored by a fixed number of virtual CPUs 13 while the load is distributed.

  Whether each of the virtual CPUs 13 becomes active or inactive periodically or not is determined by each virtual CPU 13 as follows, for example. Each virtual CPU 13 counts the number of interrupts due to the occurrence of a timer interrupt or event, and each virtual CPU 13 determines whether to be active or inactive according to the number of times. For example, when the number is divided by the number n of virtual CPUs 13 and the remainder is 0, VCPU (A) 1 is 1; You can decide whether to become active or inactive.

  Further, it is possible to determine whether or not to reset the VCPU (A) 1 by majority decision without using the majority decision circuit 27 of FIG.

  FIG. 21A is an example of a schematic configuration diagram of the ECU 100 that detects an abnormality by majority decision of the monitoring results of three or more virtual CPUs 13. In the ECU 100 of FIG. 21A, the VCPU (A) 1 writes “FFh” to the VCPU (A) 2, VCPU (A) 3,..., VCPU (A) n at regular intervals. The VCPU (A) 2 determines whether “FFh” is written in the VCPU (A) 2_checkreg 21, and stores the event request if not written. On the other hand, the VCPU (A) 3 determines whether “FFh” is written in the VCPU (A) 3_checkreg 24, and if not, outputs an event request to the VCPU (A) 2. The VCPU (A) n determines whether “FFh” is written in the VCPU (A) n_checkreg 26, and outputs an event request to the VCPU (A) 2 if not written.

  Then, the VCPU (A) 2 counts the number of reset requests input within a certain period. If the number of reset requests is greater than or equal to a predetermined value, the VCPU (A) 2 outputs a reset request to the VCPU (A) 1. That is, the VCPU (A) 2 executes majority decision processing as the master VCPU. In this manner, each virtual CPU 13 multiplexly monitors the VCPU (A) 1, and the majority CPU can determine whether the VCPU (A) 2 serving as the master VCPU is to be reset. The processing of the virtual CPU 13 which has become the master VCPU is described in the monitoring program (A) 2.

  Then, the ECU 100 can switch the VCPU (A) 2 of the master VCPU to another virtual CPU 13. The switching method can be determined in advance as in the switching method of the ECU 100 described in FIG. Each virtual CPU 13 determines whether or not to become a master based on the remainder obtained by dividing the number of interrupts due to the occurrence of timer interrupts or events by the number n of virtual CPUs 13.

  FIG. 21B is a diagram showing an example of the ECU 100 in which the master VCPU is switched from VCPU (A) 2 to VCPU (A) 3. As shown in the figure, the master VCPU is changed from VCPU (A) 2 to VCPU (A) 3. By doing this, it is possible to disperse the fact that the same processing load is concentrated in which a large number of specific virtual CPUs 13 are determined or the VCPU (A) 1 is reset. Further, since each CPU 13 monitors the VCPU (A) 1 in a multiplexed manner, the reliability of the ECU 100 can be improved.

  As described above, the ECU 100 of the present embodiment can further improve the reliability of the ECU 100 in addition to the effects of the sixth embodiment or the seventh embodiment.

  In the second embodiment, the abnormality detection system 200 in which the ECU 100A connected to the LAN 1 monitors the ECU 100B and the ECU 100B monitors the ECU 100A has been described.

  In this embodiment, an abnormality detection system 200 will be described in which the ECU 100A monitors the ECU 100B and the ECU 100B monitors the ECU 100A via the hierarchically formed LAN1 and LAN2.

  FIG. 22 shows an example of a schematic configuration diagram of the abnormality detection system 200 of the present embodiment. In FIG. 22, the same parts as those in FIG. In FIG. 22, the ECU 100A is connected to the LAN 1 and the ECU 100B is connected to the LAN 2. LAN 1 and LAN 2 are connected via a G / W (Gateway) device 19.

  When the LAN1 and LAN2 protocols are different, the G / W device 19 converts communication data formatted according to the protocol of one LAN1 (LAN2) into communication data formatted according to the protocol of the other LAN2 (LAN1) To do. There are various in-vehicle LANs 17 such as CAN, FlexRay, and LIN, for example, but these are not always compatible in format. The G / W device 19 enables the ECU 100A of the LAN 1 with a different protocol to monitor the ECU 100B of the LAN 2 (or vice versa).

  Even in the same protocol, the communication speed may differ between the two. Also in this case, the G / W device 19 absorbs the difference in speed and enables the LAN 1 ECU 100A to monitor the LAN 2 ECU 100B (or vice versa). Specifically, a buffer is provided in the G / W device 19 to temporarily store communication data transmitted from the LAN 1 and then transmit it to the other LAN 2 to absorb the difference in communication speed.

  In addition to the case where LAN1 and LAN2 are connected hierarchically as shown in FIG. 22, a star type in which a plurality of ECUs 100A and 100B are connected around the G / W device 19 and a plurality of ECUs 100A and 100B are connected to the same LAN. Even in the star type, the ECU 100A can monitor the ECU 100B (or vice versa). The LAN 1 may be multiplexed with a plurality of cables.

  As a special example, in FlexRay, the time information at which the communication data is transmitted is included in the communication data. Thereby, for example, when the ECU 100A writes “FFh” in the VCPU (B) 2_checkreg 22 of the ECU 100B, the time information can be written together. Therefore, by referring to this time information, ECU 100B can detect the time that has elapsed since ECU 100A last written “FFh” in VCPU (B) 2_checkreg22. If the ECU 100B resets the VCPU (A) 1 with reference to time information as well as “FFh”, the VCPU (A) 1 can be reset at a more accurate timing. The reliability and availability of the ECU 100A can be improved.

  According to the ECU 100 of the present embodiment, the ECU 100A can detect an abnormality of the ECU 100B and the ECU 100B can detect an abnormality of the ECU 100A via a hierarchically constructed network.

  As in the ninth embodiment, one ECU 100A can monitor the other ECU 100B via the in-vehicle LAN 17 in which LANs 1 and 2 of various protocols and communication speeds are mixed, so that the abnormality detection using the virtual CPU 13 is effective particularly in the vehicle. Improves.

  FIG. 23 shows an example of a schematic configuration diagram of the abnormality detection system 200 of the present embodiment. In vehicles, ECUs 100A and 100B having different failure tolerance requirement levels are often connected to LAN1 and LAN2. For example, the power train ECU 100 is connected to the same LAN 1, the brake ECU 100 is connected to the same LAN 1, the body ECU 100 is connected to the same LAN 2, and the multimedia ECU 100 is the same 1 Connected to two LANs 2. The LANs 1 and 2 are connected via the G / W device 19.

  The multimedia-type ECU 100 is less likely to affect driving even if it fails, but if the power-train-type ECU 100 fails, it may not be able to run in the worst case. The ECU 100 is designed according to the required high tolerance for failure. That is, the multimedia-type ECU 100 has a low failure tolerance requirement level, and the power train-type ECU 100 has a high failure tolerance requirement level.

  In the conventional monitoring microcomputer having a physical CPU, the configuration could not be flexibly changed. Therefore, when detecting an abnormality in the ECU, the monitoring microcomputer had to be arranged for each LAN.

  However, even if the ECU 100 having the virtual CPU 13 of this embodiment is arranged in any LAN 1, 2, a reference (for example, logical product, logical sum, majority decision, fixed period, etc.) by which the plurality of virtual CPUs 13 detect abnormality is appropriately set. can do. Further, as described above, the ECU 100 can communicate via the in-vehicle LAN 17 in which LANs having various protocols and communication speeds are mixed.

  For this reason, one monitoring ECU 100 can detect an abnormality of the ECU 100 at a different failure tolerance requirement level. In addition, since the abnormality detection system 200 according to the present embodiment can monitor the ECUs 100A and 100B having different failure tolerance request levels via various in-vehicle LANs 17, the ECUs 100A and 100B having different failure tolerance requirement levels can be monitored within the same LAN. There is no need to monitor. As a result, it is possible to flexibly determine the LAN 1 or LAN 2 in which the ECU 100 that detects abnormality is arranged.

  In this embodiment, an ECU 100 equipped with a virtual CPU 13 that further monitors the monitoring virtual CPU 13 will be described.

  FIG. 24 shows an example of a schematic configuration diagram of the ECU 100 equipped with the virtual CPU 13 that further monitors the monitoring virtual CPU 13. The VCPU (A) 2 is monitoring the VCPU (A) 1 as in the previous embodiments. On the other hand, the VCPU (A) 3 monitors the VCPU (A) 2 and the VCPU (A) 1.

  The VCPU (A) 1 writes a predetermined value “FFh” in the VCPU (B) 2_checkreg 22 of the VCPU (B) 2 at regular intervals. Similarly to the first embodiment, the VCPU (A) 2 monitors whether “FFh” is described in the VCPU (B) 2_checkreg22.

Further, the VCPU (A) 1 writes a predetermined value “F0h” in the VCPU (A) 3_checkreg 24 of the VCPU (A) 3 at regular intervals. The VCPU (A) 2 writes a predetermined value “Fh” into the VCPU (A) 3_checkreg 24 of the VCPU (A) 3 at regular intervals (“Fh” instead of “0Fh”). That is, only the lower 1 byte of the VCPU (A) 3_checkreg 24 is set to “1”. As a result of such writing, the VCPU (A) 3_checkreg 24 takes the following state.
・ When both VCPU (A) 1 and VCPU (A) 2 are operating normally
VCPU (A) 3_checkreg = "FFh"
・ When only VCPU (A) 1 is operating normally
VCPU (A) 3_checkreg = "F0h"
・ When only VCPU (A) 2 is operating normally
VCPU (A) 3_checkreg = "0Fh"
The VCPU (A) 3 determines whether any of the predetermined values “FFh”, “F0h”, and “0Fh” is written in the VCPU (A) 3_checkreg 24. If “FFh” is written, the VCPU (A) 3_checkreg24 A) A predetermined value “00h” is written in 3_checkreg24.
The VCPU (A) 3 then outputs a reset request to the reset determination circuit 30 as follows.
(1) When VCPU (A) 3_checkreg24 is “0Fh”
Since VCPU (A) 1 may be abnormal, VCPU (A) 3 outputs a reset request (3 → 1) to VCPU (A) 1 to reset determination circuit 30. Therefore, VCPU (A) 3 can detect a failure of VCPU (A) 1 separately from VCPU (A) 2.
(2) When VCPU (A) 3_checkreg24 is “F0h”
Since VCPU (A) 2 may be abnormal, VCPU (A) 3 outputs a reset request (3 → 2) to VCPU (A) 2 to reset determination circuit 30. That is, it is possible to detect an abnormality in the VCPU (A) 2 by detecting an abnormality in the VCPU (A) 2.
(3) When VCPU (B) 2_checkreg22 is “00h”
Since VCPU (A) 1 may be abnormal, VCPU (B) 2 outputs a reset request (2 → 1) to VCPU (A) 1 to reset determination circuit 30.

  That is, the VCPU (A) 3 can detect any abnormality of the VCPU (A) 1 and VCPU (A) 2. The reset determination circuit 30 determines VCPU (A) 1 and VCPU (A) 2 to be reset from these reset requests. If the VCPU (A) 1 can distinguish between the reset request (3 → 1) and the reset request (3 → 2), it is reset depending on whether the reset request (3 → 1) or the reset request (3 → 2) is received. It is possible to change the target. However, in this embodiment, the reset request (3 → 1) and the reset request (3 → 2) are simply handled as a reset request from the VCPU (A) 3.

When the reset request (3 → 1) or the reset request (3 → 2) is received, the reset determination circuit 30 resets VCPU (B) 1 and VCPU (B) 2.
When receiving a reset request (2 → 1), the reset determination circuit 30 resets VCPU (A) 1 and VCPU (B) 2.
When the reset request (3 → 1) and the reset request (2 → 1), or the reset request (3 → 2) and the reset request (2 → 1) are received within a certain period, the reset determination circuit 30 receives the VCPU ( A) Reset 3 The reason why the VCPU (A) 3 is reset is that the priority of reset is VCPU (A) 3> VCPU (A) 2.

  As described above, when any one of the reset requests (2 → 1), (3 → 1), and (3 → 2) is input to the reset determination circuit 30, the VCPU (A) 1, VCPU ( The entire ECU can be reset while maintaining B) 2 and VCPU (A) 3. The reset determination circuit 30 arbitrates reset requests (2 → 1), (3 → 1), and (3 → 2), and from VCPU (A) 1, VCPU (B) 2, or VCPU (A) 3 You can decide what to reset.

FIG. 25 shows an example of a flowchart showing a procedure in which the ECU 100 detects an abnormality.
The VCPU (A) 2 writes a predetermined value “FFh” in the VCPU (B) 2_checkreg 22 at regular intervals (S10). Further, the VCPU (A) 2 writes a predetermined value “F0h” in the VCPU (A) 3_checkreg 24 at regular intervals (S20).

  Further, the VCPU (A) 2 writes a predetermined value “Fh” in the VCPU (A) 3_checkreg 24 at regular intervals (S30). Then, the VCPU (A) 2 determines whether “FFh” is written in the VCPU (B) 2_checkreg 22 (S40). When “FFh” is not written in the VCPU (B) 2_checkreg 22 (No in S40), the VCPU (A) 2 transmits a reset request (2 → 1) to the reset circuit (S50). When “FFh” is written in the VCPU (B) 2_checkreg 22 (Yes in S40), the VCPU (A) 2 writes “00h” in the VCPU (B) 2_checkreg 22 (S60).

  The VCPU (A) 3 determines whether “FFh” is written in the VCPU (B) 3_checkreg (S70). When “FFh” is written in VCPU (B) 3_checkreg (Yes in S70), VCPU (A) 3 writes “00h” in VCPU (B) 3_checkreg (S80).

  If “0Fh” is written in VCPU (B) 3_checkreg instead of “FFh”, the VCPU (A) 3 transmits a reset request (3 → 1) to the reset determination circuit 30 (S90). If “F0h” is written in VCPU (B) 3_checkreg instead of “FFh”, VCPU (A) 3 transmits a reset request (3 → 2) to the reset determination circuit 30 (S100).

  Then, the reset determination circuit 30 determines the virtual CPU 13 to be reset in response to the reset request (S110).

  According to the ECU 100 of this embodiment, the abnormality of VCPU (A) 1 can be detected by VCPU (A) 2 and VCPU (A) 3, and further the abnormality of VCPU (A) 2 can be detected by VCPU (A) 3. Therefore, the abnormality of the VCPU (A) 1 can be detected in a multiplexed manner, and the reliability of the ECU 100 can be improved.

  In the eleventh embodiment, the VCPU (A) 3 which is the virtual CPU 13 detects an abnormality in the VCPU (A) 1 and VCPU (A) 2. However, in this embodiment, the VCPU (A) 1 is detected by the actual monitoring microcomputer 40. The ECU 100 that detects an abnormality of the VCPU (A) 2 will be described.

  FIG. 26 shows an example of a schematic configuration diagram of the ECU 100 that detects abnormality of the VCPU (A) 1 and VCPU (A) 2 by the actual monitoring microcomputer 40. In FIG. 26, the same parts as those in FIG. In FIG. 26, a monitoring microcomputer 40 that physically exists instead of the VCPU (A) 3 is provided.

  VCPU (A) 2 is monitoring VCPU (A) 1. The monitoring microcomputer 40 monitors VCPU (A) 2 and VCPU (A) 1.

  The VCPU (A) 1 writes a predetermined value “FFh” in the VCPU (B) 2_checkreg 22 of the VCPU (B) 2 at regular intervals. Similarly to the first embodiment, the VCPU (A) 2 monitors whether “FFh” is described in the VCPU (B) 2_checkreg22.

  Further, the VCPU (A) 1 writes a predetermined value “F0h” in the CPU (B) _checkreg 41 of the monitoring microcomputer 40 at regular intervals. The VCPU (A) 2 writes a predetermined value “Fh” into the CPU (B) _checkreg 41 of the monitoring microcomputer 40 at regular intervals (“Fh” instead of “0Fh”). Further, the monitoring microcomputer 40 determines whether or not the predetermined value “FFh” is written in the CPU (B) _checkreg 41, and if it is written, the predetermined value “00h” is written in the CPU (B) _checkreg 41.

  Accordingly, the monitoring microcomputer 40 can detect an abnormality in the VCPU (A) 2 and VCPU (A) 1 in the same manner as the VCPU (A) 3 in the eleventh embodiment.

  According to the ECU 100 of the present embodiment, in addition to the effects of the eleventh embodiment, by configuring the VCPU (A) 3 with the monitoring microcomputer 40, even if some trouble occurs in the microcomputer itself and an abnormality occurs in the virtual CPU 13, the VCPU (A) The abnormality 1 can be reliably detected.

  As described above, the ECU 100 according to the present embodiment can detect an abnormality in the ECU 100 without causing an increase in cost or in-vehicle space. The VCPU (A) 2 can reset the VCPU (A) 1 in a short time after the abnormality is detected. By switching the virtual CPU 13 that monitors the VCPU (A) 1, the processing load can be distributed. Since ECU 100A can detect abnormality of ECU 100B via in-vehicle LAN 17, the arrangement of ECU 100A or ECU 100B can be designed flexibly. Further, by constructing a plurality of virtual CPUs 13 for monitoring, it is possible to monitor VCPU (A) 1 in a multiple manner. In addition, since the virtual CPU 13 that monitors the monitoring virtual CPU 13 can be arranged, the reliability can be improved.

11 Hardware resources 13 Virtual CPU
15 OS
16 (A) 1 Application 16 (A) 2 Monitoring program 17 In-vehicle LAN
18 WDT unit 19 G / W device 23 AND circuit 25 OR circuit 27 Majority circuit 30 Reset determination circuit 40 Monitoring microcomputer 100 ECU (electronic control unit)
200 Anomaly detection system

Claims (13)

In the electronic control unit that provides the calculation results to the in-vehicle device,
A real CPU,
A virtual CPU construction means for constructing a virtual CPU from an existing CPU;
A first virtual CPU and a second virtual CPU constructed virtually;
The second virtual CPU monitors the first virtual CPU that provides the calculation result.
An electronic control unit characterized by that. The second virtual CPU monitors the first virtual CPU via an in-vehicle network.
The electronic control unit according to claim 1. The second virtual CPU monitors the first virtual CPU via a first in-vehicle network and a second in-vehicle network connected via a gateway;
The electronic control unit according to claim 1. The first virtual CPU has writing means for periodically writing a predetermined value to a register of the second virtual CPU,
The second virtual CPU is configured to determine whether or not the predetermined value is stored in the register;
Resetting means for resetting the first virtual CPU when the predetermined value is not stored in the register;
The electronic control unit according to any one of claims 1 to 3, wherein A plurality of the second virtual CPUs constructed;
Logical operation means for receiving monitoring results output from the plurality of second virtual CPUs,
Resetting the first virtual CPU according to a result of a logical operation by the logical operation means;
The electronic control unit according to claim 1, wherein: The second virtual CPU is a watchdog timer;
The electronic control unit according to any one of claims 1 to 5, wherein When the two second virtual CPUs 1 and the second virtual CPU 2 are constructed,
Switching the second virtual CPU that monitors the first virtual CPU from the second virtual CPU 1 to the second virtual CPU 2;
The electronic control unit according to claim 1, wherein the electronic control unit is an electronic control unit. Every time a timer interrupt or an interrupt accompanying the occurrence of a predetermined event occurs,
The second virtual CPU 1 interrupts monitoring of the first virtual CPU, and the second virtual CPU 2 resumes monitoring of the first virtual CPU;
The electronic control unit according to claim 7. Of the two second virtual CPUs constructed, one outputs the monitoring result of the first virtual CPU to the other second virtual CPU,
When the other second virtual CPU monitors the first virtual CPU based on the monitoring result of the first virtual CPU or the monitoring result by the one second virtual CPU,
Every time a timer interrupt or an interrupt accompanying the occurrence of a predetermined event occurs,
Switching roles of one second virtual CPU and the other second virtual CPU;
The electronic control unit according to claim 7. The logical operation means is
Resetting the first virtual CPU according to a comparison result obtained by comparing a predetermined value with the number of negative or positive monitoring results output by the plurality of second virtual CPUs;
The electronic control unit according to claim 5. A third virtual CPU that monitors the first virtual CPU and the second virtual CPU;
Monitoring determination means for inputting the monitoring result of the second virtual CPU and the monitoring result of the third virtual CPU;
The monitoring determination unit resets the first virtual CPU when one of the monitoring result of the second virtual CPU and the monitoring result of the third virtual CPU is input.
The electronic control unit according to claim 1. The third virtual CPU is
It is not a virtually constructed CPU but a real CPU.
The electronic control unit according to claim 11. In the abnormality detection method of the electronic control unit that provides the calculation result to the in-vehicle device,
A step in which the virtual CPU construction means constructs a virtual first virtual CPU and a second virtual CPU from the existing CPU;
The second virtual CPU monitoring the first virtual CPU providing the calculation result;
The abnormality detection method characterized by having.

Images