Program verification device

Abstract

This technology provides a mechanism for verifying whether a program designed to monitor other programs is performing its monitoring correctly. [Solution] In S305, the first determination unit determines whether the diagnostic execution conditions for the first program were met. In S308, the second determination unit determines whether the diagnostic result for the first program was normal or abnormal. If the second determination unit determines in S308 that the diagnostic result for the first program 1a was neither normal nor abnormal, that is, if the second determination unit determines that the diagnostic result for the first program was "undiagnosed", it determines that the diagnostic function for the first program was not executed by the second program.

Description

Technical Field

[0001] This disclosure relates to a program verification device.

Background Art

[0002] The following Patent Document 1 describes a technique in which a program at the second level monitors the functions of a program at the first level that controls a control target, and a program at the third level monitors the functions of the program at the second level. By providing a program for monitoring the program, an attempt is made to improve the reliability of control.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] Here, when a program at the second level or a program at the third level is updated due to version upgrade or the like, a technique for determining whether the program is normally stored by data check or the like is known.

[0005] However, as a result of the inventors' detailed examination, it has been found that there is a problem that determining whether the stored program normally executes the monitoring function has not been conventionally performed, including the technique described in Patent Document 1.

[0006] One aspect of this disclosure provides a technique for confirming whether a program for monitoring a program normally executes monitoring.

Means for Solving the Problems

[0007] One aspect of this disclosure is a program verification device (10) that verifies whether a diagnostic function has been successfully executed for a second processing unit (62) configured to directly or indirectly monitor whether the first program is being executed normally by executing a second program (2a, 2b, 2c), which is a program different from the first program, for a first processing unit (61) configured to control a controlled object by executing a first program (1a, 1b, 1c), which is a predetermined program. The program verification device comprises a first determination unit (31) configured to determine whether a diagnostic execution condition, which is a pre-set condition for the second processing unit to execute the diagnostic function, has been met, and a second determination unit (32) configured to determine whether the diagnostic function has been successfully executed by comparing a diagnostic result, which is the result of the diagnostic function executed by the second processing unit, with diagnostic information, which is information held in advance and includes at least the type of diagnostic result output by the second processing unit.

[0008] With this configuration, the program verification device can confirm whether the diagnostic function of the second program, which monitors the first program, has been executed successfully. Therefore, it is possible to confirm whether the program for monitoring the program has performed its diagnostic function correctly. In other words, it is possible to confirm whether the program for monitoring the program has performed its monitoring correctly. [Brief explanation of the drawing]

[0009] [Figure 1] This is a diagram illustrating the general structure of the monitoring system. [Figure 2] This is a sequence diagram illustrating the overview of the monitoring system. [Figure 3] This is a block diagram of the electronic control unit. [Figure 4] This is a flowchart of the diagnostic process. [Figure 5] This is a flowchart showing the decision-making process. [Figure 6] This is a time chart for comparative examples and embodiments. [Figure 7] This is a diagram illustrating the outline of the monitoring system in Modification Example 1. [Modes for carrying out the invention]

[0010] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the drawings. [1. Embodiments] [1-1. Overview of the structure] The monitoring system 100 shown in Figure 1 comprises an electronic control unit 10 and an OTA master 20. Hereafter, the electronic control unit 10 will also be referred to as ECU10. ECU10 is an abbreviation for Electronic Control Unit.

[0011] The monitoring system 100 is a network installed in a vehicle (for example, an automobile). In this embodiment, the monitoring system 100 installed in a vehicle is given as an example, but the target of use of the monitoring system 100 is not limited to vehicles.

[0012] As shown by the dotted line frame in Figure 1, the programs executed in the monitoring system 100 are divided into a first-level program 11, a second-level program 12, and a third-level program 13.

[0013] The first-level program 11 is a program for controlling the controlled object. In this embodiment, the first-level program 11 is a program for controlling actuators mounted on the vehicle, and is a program for realizing the vehicle's original functions. In Figure 1, the first-level program 11 includes first programs 1a, 1b, and 1c.

[0014] The program 12 at the second level is a program that executes a diagnostic function for directly monitoring whether the program 11 at the first level is being executed normally. Direct monitoring means monitoring the program to be diagnosed without going through other programs. In this embodiment, the program 12 at the second level directly monitors the program 11 at the first level without going through other programs 12 at the second level. In FIG. 1, the second programs 2a and 2b are included as the program 12 at the second level.

[0015] The program 13 at the third level is a program for confirming whether the diagnostic function executed by the second programs 2a and 2b has been executed normally. In this embodiment, the function as the safety mechanism master 30 is executed by the program 13 at the third level. The safety mechanism master 30 will be described in detail later.

[0016] The program 12 at the second level and the program 13 at the third level are programs with higher reliability in design than the program 11 at the first level. For example, the program 12 at the second level and the program 13 at the third level are programs that meet the Automotive Safety Integrity Level (hereinafter referred to as ASIL). ASIL is defined by the ISO 26262 standard regarding the functional safety of vehicles running on the road and has four levels identified by A, B, C, and D. A indicates the lowest safety requirement level, and D indicates the highest safety requirement level. Less than A is represented by QM, indicating that functional safety is not applied. ASIL is the abbreviation of Automotive Safety Integrity Level. QM is the abbreviation of Quality Management.

[0017] Regarding the specific functions realized by executing the program 11 at the first level, the program 12 at the second level, and the program 13 at the third level in the electronic control unit 10, they will be described in detail later.

[0018] The OTA master 20 is an ECU for wirelessly transmitting and receiving data with a center (not shown). The center has a function as a server that provides a program to the OTA master 20 via wireless communication through a network such as the Internet. OTA is an abbreviation for Over the Air.

[0019] The OTA master 20 includes a CPU 21 and a memory 22. A program for the CPU 21 to execute a predetermined function is stored in the memory 22. The OTA master 20 has a function of controlling the software update process by the CPU 21 executing the program in the memory 22 and performing the software update of the electronic control unit 10 to be updated.

[0020] Here, initially, even if the safety requirement level for the first-level program 11 corresponded to QM, there may be a case where functional safety support becomes necessary later. Therefore, it is conceivable to newly add the second-level program 12 or change the second-level program 12 by software update. In other words, it is conceivable that the first-level program 11, the second-level program 12, and the third-level program 13 cooperate to achieve functional safety.

[0021] [1-2. Outline of processing] Taking the case where the second-level program 12 is added by software update as an example, the outline of the processing of the monitoring system 100 will be described.

[0022] First, in S1, it is assumed that the second program 2a and the second program 2b are added by software update. In S2, the second program 2a monitors whether the first program 1a is being executed normally. In other words, the second program 2a executes a diagnostic function for the first program 1a. Also, actually, it is assumed that the diagnostic function for the first program 1a by the second program 2a is completed. <00​In S3, the second program 2b monitors whether the first program 1b is executing correctly. In other words, the second program 2b performs a diagnostic function on the first program 1b. However, suppose the second program 2b fails to perform the diagnostic function on the first program 1b.

[0024] Furthermore, it is assumed that the safety requirement level of the first program 1c corresponds to QM, and therefore there is no second-level program 12 for monitoring the first program 1c. In S4, the safety mechanism master 30 obtains a diagnostic result, which is the result of the diagnostic function for the first program 1a. More specifically, the safety mechanism master 30 obtains a diagnostic result indicating that the diagnostic function for the first program 1a was executed by the second program 2a. Specifically, the safety mechanism master 30 obtains a diagnostic result of either "normal" or "abnormal".

[0025] In S5, the safety mechanism master 30 obtains a diagnostic result, which is the result of the diagnostic function for the first program 1b. More specifically, the safety mechanism master 30 obtains a diagnostic result indicating that the diagnostic function for the first program 1b was not executed by the second program 2b. Specifically, the safety mechanism master 30 obtains a diagnostic result of "not diagnosed".

[0026] In S6, the safety mechanism master 30 performs a determination process. The determination process is a process that determines whether or not the diagnostic function was executed successfully by comparing the diagnostic result with the diagnostic information. The diagnostic information is information that the safety mechanism master 30 has held in advance and includes at least the type of diagnostic result output by the diagnostic function executed by the second-level program 12.

[0027] Furthermore, the diagnostic information may also include activation information and diagnostic execution conditions. Activation information is information regarding which program the second-level program 12 will execute the diagnostic function against. In other words, activation information is information regarding which first-level program 11 the second-level program 12 corresponds to.

[0028] The diagnostic execution conditions are information about when the second-level program 12 will execute a diagnostic function on the program. In other words, the diagnostic execution conditions are pre-set conditions that determine when the second-level program 12 will execute a diagnostic function.

[0029] For example, the diagnostic results include three types: "normal," "abnormal," and "undiagnosed." "Normal" means that the Level 2 program 12 diagnosed that the controlled object was being controlled correctly by the Level 1 program 11. "Abnormal" means that the Level 2 program 12 diagnosed that the controlled object was not being controlled correctly by the Level 1 program 11. "Undiagnosed" means that the Level 2 program 12 did not perform its diagnostic function.

[0030] For example, the activation information may include information such as: the second program 2a performs a diagnostic function on the first program 1a, the second program 2b performs a diagnostic function on the first program 1b, and none of the second-level programs 12 perform a diagnostic function on the first program 1c. Specific examples of diagnostic execution conditions will be described in detail later.

[0031] The safety mechanism master 30 refers to the activation information to confirm which of the first-level programs 11 each second-level program 12 is targeting for diagnosis. The safety mechanism master 30 also refers to the diagnosis execution conditions to confirm the timing at which each second-level program 12 executes the diagnostic function. Furthermore, the safety mechanism master 30 determines whether the diagnostic function was executed successfully by comparing the output diagnostic result with the type of diagnostic result it has previously stored. More specifically, for example, if the output diagnostic result matches the type of "normal" or "abnormal," the safety mechanism master 30 determines that the diagnostic function was executed successfully. On the other hand, for example, if the output diagnostic result matches the type of "not diagnosed," the safety mechanism master 30 determines that the diagnostic function was not executed successfully. In short, if the output diagnostic result is "normal" or "abnormal," it is determined that the diagnostic function was executed successfully. On the other hand, if the output diagnostic result is "not diagnosed," it is determined that the diagnostic function was not executed successfully. It should be noted that "the diagnostic function was executed successfully" does not mean that the diagnostic result was "normal," but rather that the diagnostic function was executed to completion.

[0032] In S7, the safety mechanism master 30 requests a software update from the OTA master 20 based on the determination result of the determination process. More specifically, if there are programs that are being monitored but are not being monitored, the safety mechanism master 30 requests a software update for those programs. In this embodiment, since the diagnostic function for the first program 1b was not executed by the second program 2b, it is considered that the second program 2b is not functioning properly. Therefore, the safety mechanism master 30 requests a software update for the second program 2b.

[0033] In S8, the OTA master 20 performs a software update. More specifically, the OTA master 20 retrieves a new second program 2b from the center and controls the currently stored second program to be updated with the new second program.

[0034] [1-2. Overview of the Processing Flow] Furthermore, the processing flow of the monitoring system 100 will be explained using the sequence diagram in Figure 2. In S101, the second program 2a starts the diagnostic function.

[0035] In S102, the second program 2a obtains the execution status of the first program 1a. In S103, the second program 2a notifies the safety mechanism master 30 of the diagnostic results. Specifically, the second program 2a outputs "Normal," "Abnormal," or "Not Diagnosed."

[0036] In S104, the safety mechanism master 30 determines whether the diagnostic function was executed successfully by comparing the diagnostic result with the diagnostic information. In S105, the safety mechanism master 30 requests a software update from the OTA master 20 based on the judgment result.

[0037] In S106, the OTA master 20 notifies the user to perform a software update. For example, it displays a message on the car navigation system's display indicating that a software update is starting. When the user selects to start the software update, the OTA master 20 performs the software update.

[0038] [1-3. Structure] The configuration of the ECU10 will be described in detail using Figure 3. The ECU10 may be installed in a vehicle that uses an internal combustion engine and / or a motor as the power source for a drive system that drives the vehicle's movement. Hereinafter, the internal combustion engine will also be referred to as the engine. When the vehicle is equipped with an engine and a motor, the engine may be used to charge a battery that supplies power to the motor. The drive system may also be configured to supply power generated by a fuel cell to the motor.

[0039] The ECU 10 is configured to control, for example, a throttle device (not shown) that adjusts the amount of intake air to the vehicle's engine. The actuator drive IC 52 is configured to drive the motor of the throttle device. The ECU 10 adjusts the opening degree of the throttle valve of the throttle device, which is the object of control, by outputting a control signal to the actuator drive IC 52.

[0040] The ECU10 receives various data from sensors 51 and other sources, such as the opening degree of the throttle valve in the throttle device, the operating position of the vehicle's accelerator pedal, and the fuel injection amount.

[0041] The ECU10 includes a microcontroller 15 and a monitoring IC 16. Microcontroller 15 is an abbreviation for microcomputer. In Figure 3, one microcontroller 15 is shown, but there may be multiple microcontrollers 15.

[0042] The microcontroller 15 includes a CPU (not shown), ROM, RAM, flash memory, etc. The CPU executes a program stored in the ROM, which is a non-transitional physical recording medium. When this program is executed, the method corresponding to that program is executed.

[0043] The electronic control unit 10 comprises a torque control unit 61, a torque monitor unit 62, a first determination unit 31, a second determination unit 32, an acquisition unit 33, and an update unit 34, as functional blocks, or virtual components, realized by the CPU executing a program. The first determination unit 31, the second determination unit 32, the acquisition unit 33, and the update unit 34 are included in the safety mechanism master 30.

[0044] The torque control unit 61 executes the first program 1a. More specifically, by executing the first program 1a, the torque control unit 61 calculates the target throttle opening of the throttle valve from the accelerator pedal input. Then, the torque control unit 61 executes a control function that outputs a control signal to the actuator drive IC 52 so that the actual throttle opening becomes the target throttle opening.

[0045] The torque monitor unit 62 executes the second program 2a. More specifically, by executing the second program 2a, the torque monitor unit 62 performs the diagnostic functions shown in (1) to (3) below.

[0046] (1) The allowable torque, which is the maximum output torque of the engine, is calculated from the amount of accelerator pedal operation. (2) The estimated torque, which is an estimated value of the torque currently being generated by the engine, is calculated from the throttle opening.

[0047] (3) The calculated allowable torque is compared with the estimated torque to determine, for example, whether the estimated torque is greater than the allowable torque by a predetermined value or more. If the estimated torque is greater than a predetermined value or more than the allowable torque, the torque monitor unit 62 determines that the control function of the torque control unit 61 to the throttle valve is abnormal. In this case, the torque monitor unit 62 outputs to the second determination unit 32 that the control function of the torque control unit 61 is abnormal as a diagnostic result, which is the result of the diagnostic function that was performed. The torque monitor unit 62 also outputs a cutoff signal to the actuator drive IC 52 via the output interface 64.

[0048] On the other hand, if the estimated torque is not greater than a predetermined value than the allowable torque, the torque monitor unit 62 determines that the control function of the torque control unit 61 on the throttle valve is normal. In this case, the torque monitor unit 62 outputs to the second determination unit 32 as a diagnostic result that the control function of the torque control unit 61 is normal.

[0049] Furthermore, if the diagnostic function is not performed, the torque monitor unit 62 outputs an undiagnosed diagnostic result to the second determination unit 32, indicating that the diagnostic function was not performed. The first determination unit 31 is configured to determine whether or not the diagnostic execution conditions have been met. In this embodiment, the diagnostic execution conditions refer to the conditions under which the diagnostic function of the torque monitor unit 62 is executed. For example, the diagnostic execution conditions are met when the accelerator is pressed while the vehicle is running, when the accelerator is not pressed while the vehicle is running but a predetermined timing has arrived, or when fuel is being injected. Note that the diagnostic execution conditions differ depending on the controlled object. The diagnostic execution conditions only need to be predetermined.

[0050] The second determination unit 32 is executed when the first determination unit 31 determines that the diagnostic execution conditions have been met. The second determination unit 32 is configured to determine whether the diagnostic function was executed successfully by comparing the diagnostic result, which is the result of the diagnostic function executed by the second program 2a, with the diagnostic information, which is information related to the diagnostic function.

[0051] The acquisition unit 33 is configured to acquire a program via wireless communication. More specifically, the acquisition unit 33 is configured to acquire a program via the OTA master 20. In this embodiment, if the second determination unit 32 determines that the diagnostic function by the second program 2a is not being executed properly, the acquisition unit 33 acquires a new second program via the OTA master 20.

[0052] The update unit 34 is configured to update the program. More specifically, when a new second program is acquired by the acquisition unit 33, the update unit 34 updates the currently stored second program 2a to the new second program.

[0053] The monitoring IC 16 is an IC for monitoring the operation of the microcontroller 15. More specifically, the monitoring IC 16, together with the first determination unit 31 and the second determination unit 32, achieves third-level functional safety in the ECU 10. The monitoring IC 16 comprises a watchdog monitoring unit 66 and a microcontroller 15 monitoring unit.

[0054] The watchdog monitoring unit 66 monitors the count value of the watchdog timer 65. More specifically, if the count value of the watchdog timer 65 exceeds a predetermined value due to a malfunction in the microcontroller 15 and is not initialized, the watchdog monitoring unit 66 outputs a shutdown request to the microcontroller 15 monitoring unit. In addition, if the count value of the watchdog timer 65 exceeds a predetermined value, the watchdog monitoring unit 66 outputs a reset signal to the microcontroller 15.

[0055] When the microcontroller 15 monitoring unit receives a cutoff request from the watchdog monitoring unit 66, it outputs a cutoff signal to the actuator drive IC 52. The above describes in detail the processes executed by the first program 1a and the second program 2a. The specific processes executed by the first programs 1b, 1c, and the second program 2b are omitted here, but the first programs 1b and 1c only need to be programs for controlling the controlled object. The second program 2b is a separate program from the first program and only needs to be a program that performs a diagnostic function to monitor whether the first program is executing normally.

[0056] [1-4. Processing] [1-4-1. Diagnostic Process] The diagnostic process performed by the torque monitor unit 62 of the ECU10 will be explained using the flowchart in Figure 4. This diagnostic process is repeatedly executed while the ignition switch is ON.

[0057] First, in S201, the torque monitor unit 62 determines whether or not the diagnostic execution conditions have been met. If the torque monitor unit 62 determines in S201 that the diagnostic execution conditions were not met, it proceeds to S202 and sets a value indicating "not diagnosed" in the result. There are two possible cases when it is determined in S201 that the diagnostic execution conditions were not met. The first is a case where the predetermined diagnostic execution conditions were not objectively met. In other words, this means that the conditions for the diagnostic function to be executed have not yet been met in terms of the vehicle's state. The second is a case where the diagnostic execution conditions were objectively met, but the torque monitor unit 62 mistakenly determined that the diagnostic execution conditions were not met. In other words, this is a case where the diagnostic function was scheduled to be executed, but was not actually executed.

[0058] On the other hand, if the torque monitor unit 62 determines that the diagnostic execution conditions have been met in S201, it proceeds to S203. In S203, the torque monitor unit 62 performs the diagnostic function described above and determines whether the diagnostic result is normal or abnormal.

[0059] If the torque monitor unit 62 determines in S203 that the diagnostic result is normal, it proceeds to S204 and sets a value indicating "normal" in the result. On the other hand, if the torque monitor unit 62 determines in S203 that the diagnostic result is abnormal, it proceeds to S205 and sets a value indicating "abnormal" in the result.

[0060] Next, in S206, the torque monitor unit 62 sets the result set in S202, S204, or S205 as the diagnostic result output to the second determination unit 32. The diagnostic result set in S206 is output to the second determination unit 32.

[0061] [1-4-2. Judgment Process] The judgment process performed by the safety mechanism master 30 will be explained using the flowchart in Figure 5. This judgment process is executed repeatedly while the ignition switch is ON. This judgment process determines whether the diagnostic function is being executed correctly for the updated second program, and if the diagnostic function is not being executed correctly, it is performed to update the program again.

[0062] First, in S301, the safety mechanism master 30 retrieves pre-held activation information. The subsequent processes from S302 to S311 are executed sequentially for each of the second programs if multiple second programs exist.

[0063] In S302, the safety mechanism master 30 determines whether the second program 2a is valid. More specifically, the safety mechanism master 30 determines whether the second program 2a is linked to any of the first-level programs 11 that are subject to performing diagnostic functions. If there is a first-level program 11 that the second program 2a is subject to performing diagnostic functions, the safety mechanism master 30 determines that the second program 2a is valid.

[0064] If the safety mechanism master 30 determines in S302 that the second program 2a is not valid, it proceeds to S303 and sets the result to "normal". In other words, if there is no first-level program 11 that the second program 2a is targeting for performing its diagnostic function, there is no need to execute the second program 2a, and therefore there is no need to update the second program 2a to a new second program 2a.

[0065] On the other hand, if the safety mechanism master 30 determines in S302 that the second program 2a is valid, it proceeds to S304. In S304, the first determination unit 31 acquires the history of when the diagnostic execution conditions for the first program 1a have been met. In other words, it acquires information on whether or not the predetermined diagnostic execution conditions were objectively met at a predetermined timing. The safety mechanism master 30 has the diagnostic execution conditions for the first program 1a stored in advance, and therefore checks and records whether or not the diagnostic execution conditions have been met at a predetermined timing.

[0066] Next, in S305, the first determination unit 31 determines whether the diagnostic execution conditions for the first program 1a have been met. More specifically, the first determination unit 31 refers to the history of the fulfillment of the diagnostic execution conditions and determines whether it has been recorded that the diagnostic execution conditions have been met.

[0067] If the first determination unit 31 determines in S305 that the diagnostic execution conditions for the first program 1a were not met, it proceeds to S306 and sets the result to "normal". In other words, if the conditions for executing the second program 2a are not yet met, it is considered that there is no need to update the second program 2a to a new second program 2a.

[0068] On the other hand, if the first determination unit 31 determines in S305 that the diagnostic execution conditions for the first program 1a have been met, it proceeds to S307. In S307, the second determination unit 32 obtains the diagnostic result for the first program 1a.

[0069] Next, in S308, the second determination unit 32 determines whether the diagnosis result for the first program 1a was normal or abnormal. If the second determination unit 32 determines in S308 that the diagnostic result for the first program 1a was either normal or abnormal, it sets the result to "abnormal". In other words, if the second determination unit 32 determines that the diagnostic result for the first program 1a was "not diagnosed", it sets the result to "abnormal". This means that the diagnostic function for the first program 1a was not executed despite the diagnostic execution conditions being objectively met.

[0070] On the other hand, if the second determination unit 32 determines in S308 that the diagnostic result for the first program 1a was normal or abnormal, it sets the result to "normal". This means that the diagnostic execution conditions were objectively met and the diagnostic function for the first program 1a was actually executed.

[0071] Next, in S311, the second determination unit 32 sets the result set in S303, S306, S309, or S310 for the diagnostic execution determination of the second program 2a. Next, the safety mechanism master 30 performs the same process for the other second programs.

[0072] Next, in S312, the safety mechanism master 30 determines whether or not a software update is necessary. More specifically, the safety mechanism master 30 determines that a software update is necessary for the second program if the diagnostic execution result was "abnormal". In other words, if the diagnostic result for the first program was "not diagnosed", the safety mechanism master 30 determines that an update is necessary for the second program. This means that there is an inconsistency between the first and second programs, and it is thought that the second program did not execute properly. Therefore, it is considered necessary to update to a new second program that is consistent with the first program.

[0073] On the other hand, the safety mechanism master 30 determines that software updates are unnecessary for the second program, for which the diagnostic execution result was "normal." In other words, since the second program executed successfully, it is considered safe to continue using the currently stored second program.

[0074] The safety mechanism master 30 terminates this determination process if it determines in S312 that no software updates are required for any of the second programs. In other words, the safety mechanism master 30 terminates this determination process if it determines that no software updates are required for any of the second programs registered in the activation information. To put it another way, if none of the second programs output "not diagnosed" as a diagnostic result, the safety mechanism master 30 determines that no software updates are required.

[0075] On the other hand, if the safety mechanism master 30 determines in S312 that a software update is necessary, it proceeds to S313. In other words, if the safety mechanism master 30 determines that a software update is necessary for any of the second programs registered in the activation information, it proceeds to S313. To put it another way, if any of the second programs output "not diagnosed" as a diagnostic result, the safety mechanism master 30 determines that a software update is necessary for that second program.

[0076] In S313, the acquisition unit 33 requests a software update. More specifically, the acquisition unit 33 requests a software update from the OTA master 20. Specifically, the acquisition unit 33 requests a software update for the second program that output "Not diagnosed" as a diagnostic result. After that, the safety mechanism master 30 terminates this judgment process.

[0077] Furthermore, if a new second program is acquired by the acquisition unit 33 via the OTA master 20, the update unit 34 updates the currently stored second program with the new second program.

[0078] [1-5. Effects] According to the embodiments described in detail above, the following effects can be obtained. (1a) The first determination unit 31 determines whether the diagnostic execution conditions have been met. If the first determination unit 31 determines that the diagnostic execution conditions have been met, the second determination unit 32 determines whether the diagnostic function has been executed successfully by comparing the diagnostic result with the diagnostic information. With this configuration, it is possible to confirm whether the second-level program 12 for monitoring the first-level program 11 has successfully executed the monitoring function.

[0079] (1b) The first program is a first-level program 11 for controlling a control target mounted on the vehicle. The second program is a second-level program 12 that directly monitors whether the first program is executing normally. With this configuration, the safety mechanism master 30 can confirm whether the second-level program 12 is performing its monitoring function normally. Thus, the first-level program 11, the second-level program 12, and the safety mechanism master 30 work together to achieve functional safety.

[0080] (1c) The diagnostic information includes the type of diagnostic result from the second program, information on which first program the second program will execute the diagnostic function on (i.e., activation information), and information on when the second program will execute the diagnostic function on the first program (i.e., diagnostic execution conditions). With this configuration, the safety mechanism master 30 can determine whether the diagnostic function was executed successfully for each second program, even if there are multiple second programs. Therefore, with one safety mechanism master 30, it is possible to perform determination processing for multiple second programs.

[0081] Furthermore, determining whether or not the diagnostic execution conditions have been met produces the following effects. Specifically, as shown in the comparative example in Figure 6, for example, the OTA master 20 could intentionally inject data that results in an abnormal diagnostic outcome for the first program. In other words, if the diagnostic outcome for the first program is indeed abnormal, it can be determined that the diagnostic function of the second program was executed successfully. On the other hand, if the diagnostic outcome for the first program is normal, it can be determined that the diagnostic function of the second program was not executed successfully.

[0082] However, if the diagnostic execution conditions have not yet been met when the OTA master 20 injects data resulting in an abnormal diagnostic result for the first program, the diagnostic function will not be executed regardless of whether the second program can perform the diagnostic function normally or not. In other words, depending on the timing of when the OTA master 20 injects data resulting in an abnormal diagnostic result for the first program, it is not possible to determine whether the second program can perform the diagnostic function normally or not. Specifically, for example, if abnormal data is injected between T1 and T2 (i.e., while the CPU state is reprogramming), the diagnostic function will not be executed because the diagnostic execution conditions have not yet been met. Unless abnormal data is injected between T3 and T4 (i.e., while the CPU state is running), it is not possible to determine whether the second program can perform the diagnostic function normally or not. However, it is unlikely that data would be intentionally injected while the CPU state is running, for example, while the vehicle is in motion. Therefore, in the comparative example, the timing of updating to a new second program is not fixed.

[0083] However, according to the embodiment described above, the safety mechanism master 30 performs a judgment process when the diagnostic execution conditions are met (for example, between T3 and T4). In other words, the judgment process can be performed while the vehicle is in motion. Therefore, when the ECU 10 goes to sleep (T5), reprogramming can be started (T6) to update to a new second program.

[0084] In the above embodiment, the determination process is shown as being repeatedly executed while the ignition switch is ON, but the timing of the execution of the determination process is not limited to this. For example, the determination process may be executed each time the CPU state changes.

[0085] (1d) The second determination unit 32 determines that the diagnostic function was not executed correctly if the diagnostic result is "undiagnosed". With this configuration, if the diagnostic result is neither "normal" nor "abnormal", it is determined that the diagnostic function was not executed correctly. In other words, by using a new status, "undiagnosed", it is possible to clearly indicate when the diagnostic function was not executed correctly.

[0086] (1e) If the acquisition unit 33 determines that the diagnostic function is not being executed properly by the second determination unit 32, it acquires a new second program. If the acquisition unit 33 acquires a new second program, the update unit 34 updates the currently stored second program to the new second program. With this configuration, if the diagnostic function using the currently stored second program is not being executed properly by the ECU 10, it can immediately update to the new second program. Therefore, the diagnostic function using the new second program is executed immediately, thus ensuring functional safety.

[0087] [1-6. Correspondence] In the above embodiment, the functional blocks executed by the first programs 1a, 1b, and 1c correspond to the first processing unit, and the functional blocks executed by the second programs 2a and 2b correspond to the second processing unit. Specifically, the torque control unit 61 corresponds to an example of the first processing unit, and the torque monitor unit 62 corresponds to an example of the second processing unit. Furthermore, the electronic control device 10 corresponds to a program verification device.

[0088] [2. Other Embodiments] While embodiments of this disclosure have been described above, it goes without saying that this disclosure is not limited to the embodiments described above and can take various forms.

[0089] (2a) In the above embodiment, a program for controlling a control object mounted on a vehicle is defined as a first-level program 11, and a program that directly monitors whether the first program is executing normally is defined as a second-level program 12. The example given is one in which the first program is the first-level program 11 and the second program is the second-level program 12. However, the definition of the second program is not limited to this. For example, if a program that indirectly monitors whether the first program is executing normally is defined as a third-level program 13, then the second program may be the third-level program 13. Indirect monitoring means monitoring the first program through another program. For example, the third-level program 13 may monitor the first program by monitoring whether the second-level program 12 is monitoring the first program normally.

[0090] Furthermore, the safety mechanism master 30 does not have to be configured to be executed by the third-level program 13. For example, as shown in the monitoring system 200 in Modification 1 of Figure 7, the safety mechanism master 30 may be located in the UCM as defined in the architecture provided by AUTOSAR. UCM stands for Update and Configuration Management. With such a configuration, the safety mechanism master 30 can also verify whether the diagnostic function of the third-level program 13 has been executed successfully.

[0091] More specifically, in S2-1, the second program 2c monitors whether the second program 2a is executing normally. In other words, the second program 2c performs a diagnostic function on the second program 2a. The safety mechanism master 30 can also obtain the diagnostic results for the second program 2b to confirm whether the second program 2c is executing normally.

[0092] (2b) In the above embodiment, an example was given of a configuration in which the safety mechanism master 30 provided in the ECU 10 performs the determination process. Specifically, an example was given in which the torque control unit 61 (i.e., the first processing unit) and the torque monitor unit 62 (i.e., the second processing unit) and the safety mechanism master 30 are provided in one ECU 10. However, the first processing unit, the second processing unit and the safety mechanism master 30 may be provided in separate ECUs. In other words, the safety mechanism master 30 may be configured as a separate unit as a program verification device.

[0093] (2c) Each device described in this disclosure (i.e., ECU 10, OTA master 20) and each method using the device may be implemented by a dedicated computer provided by configuring a processor and memory programmed to perform one or more functions embodied by a computer program. Alternatively, each device described in this disclosure and each method using the device may be implemented by a dedicated computer provided by configuring a processor by one or more dedicated hardware logic circuits. Alternatively, each device described in this disclosure and each method using the device may be implemented by one or more dedicated computers configured by a combination of a processor and memory programmed to perform one or more functions and a processor configured by one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by the computer on a computer-readable non-transitional tangible recording medium. The methods for implementing the functions of each part included in each device do not necessarily need to include software, and all of its functions may be implemented using one or more hardware components.

[0094] (2d) The functions of one component in the above embodiment may be distributed among multiple components, or the functions of multiple components may be integrated into one component. Also, some of the configurations of the above embodiment may be omitted. Also, at least some of the configurations of the above embodiment may be added to, replaced with, or otherwise adapted to the configurations of other above embodiments.

[0095] (2e) The present disclosure can be implemented in various forms, including, in addition to the electronic control device described above, a system comprising the electronic control device, a program for causing a computer to function as the electronic control device, a medium on which the program is recorded, and a method for determination processing. [Explanation of Symbols]

[0096] 1a, 1b, 1... First program, 2a, 2b, 2c... Second program, 10... Electronic control unit, 31... First determination unit, 32... Second determination unit, 61... Torque control unit, 62... Torque monitor unit.

Claims

1. A program verification device (10) confirms whether the diagnostic function has been successfully executed for a second processing unit (62) configured to directly or indirectly monitor whether the first program is being executed normally by executing a second program (2a, 2b, 2c), which is a different program from the first program, on a first processing unit (61) configured to control a controlled object by executing a first program (1a, 1b, 1c), which is a predetermined program. A first determination unit (31) is configured to determine whether a predetermined condition, which is a diagnostic execution condition for the second processing unit to execute the diagnostic function, has been met, If the first determination unit determines that the diagnostic execution conditions have been met, a second determination unit (32) is configured to determine whether the diagnostic function was executed successfully by comparing the diagnostic result, which is the result of the diagnostic function executed by the second processing unit, with the diagnostic information, which is information held in advance and includes at least the type of diagnostic result output by the second processing unit, which is information relating to the diagnostic function. A program verification device equipped with the following features.

2. A program verification device according to claim 1, The program for controlling the control target mounted on the vehicle is defined as the first-level program (11). A program that directly monitors whether the first program is executing normally is designated as a second-level program (12). The first program is a first-level program, The second program is a program verification device, which is a second-level program.

3. A program verification device according to claim 1 or claim 2, The program verification device further includes information on which program the second processing unit will execute the diagnostic function on, and information on the timing at which the second processing unit will execute the diagnostic function on the program.

4. A program verification device according to claim 1 or claim 2, The types of diagnostic results output by the second processing unit include undiagnosed diagnostic results indicating that the diagnostic function was not performed. The second determination unit is a program verification device that determines that the diagnostic function was not executed properly if the diagnostic result output by the second processing unit is "undiagnosed".

5. A program verification device according to claim 1 or claim 2, The second processing unit is provided in the program verification device, The program verification device is An acquisition unit (33) configured to acquire a program via wireless communication, An update unit (34) configured to update the program, Furthermore, If the acquisition unit determines that the diagnostic function is not being executed properly, it acquires a new second program via wireless communication. The update unit is a program verification device that, when the acquisition unit acquires the new second program, updates the currently stored second program with the new second program.

6. A program verification device according to claim 1, The program for controlling the control target mounted on the vehicle is defined as the first-level program. A program that directly monitors whether the first program is executing correctly is designated as a second-level program. A third-level program (13) is defined as a program that indirectly monitors whether the first program is executing normally by monitoring whether the second-level program is normally monitoring the first program, The first program is a first-level program, The second program is a program verification device, which is the third-level program.

Images