Vehicle electronic control device

Abstract

A storage unit 104 stores a first program (operating program 121), a second program (non-operating program 122) having a version number different from that of the first program, and a recovery program 113. An abnormality detection unit 106 detects an abnormality in the first program or the second program that is selectively operated. The operating program 121 updates the non-operating second program, and a program management unit 123 switches the non-operating second program to an operating program. The program management unit 123 stops the operation of the second program and switches the operation to the first program or the recovery program 113 when an abnormality of the second program in operation is detected after the lapse of a predetermined time from the switching of the operation to the second program.

Description

Vehicle electronic control device

[0001] The present invention relates to a vehicle electronic control device.

[0002] In vehicle control devices, there is known a technology capable of appropriately responding to a defect when the defect is found in updated software (see, for example, Patent Document 1).

[0003] Patent Document 1 (abstract) describes that "A vehicle control device includes a first non-volatile memory storing software for controlling a vehicle, and one or more processors that execute the software. When it is necessary to roll the software back to the old software before update, the one or more processors determine whether the old software before update is stored in a second non-volatile memory mounted on the vehicle, and when the old software is stored in the second non-volatile memory, store the old software from the second non-volatile memory to the first non-volatile memory."

[0004] Japanese Unexamined Patent Application Publication No. 2023-087366

[0005] In the technology as described in Patent Document 1, a rollback instruction is issued, for example, by a management server or a vehicle user when it is necessary to roll the software back to the old software. Therefore, even if an abnormality occurs in the updated software (program), self-recovery cannot be performed.

[0006] An object of the present invention is to provide a vehicle electronic control device capable of self-recovering even when an abnormality occurs in an updated program.

[0007] To achieve the above objective, the vehicle electronic control device of the present invention includes: a storage unit that stores a first program, a second program having a different version from the first program, and a recovery program; an abnormality detection unit that detects abnormalities in the first program or the second program which are operated alternately; and a program management unit that switches the non-operating second program, which has been updated by the operating first program, to an operating program, and if an abnormality in the operating second program is detected after a predetermined time has elapsed since switching to the second program, stops the operation of the second program and switches to the first program or the recovery program.

[0008] According to the present invention, even if an abnormality occurs in the updated program, it can self-recover. Problems, configurations, and effects other than those described above will be clarified by the following description of embodiments.

[0009] This is a block diagram showing the overall configuration of the vehicle electronic control device according to Example 1. This is a flowchart of the software recovery means according to Example 1. This is a block diagram showing the overall configuration of the vehicle electronic control device according to Example 2. This is a flowchart of the software recovery means according to Example 2. This is a flowchart of the software recovery means according to Example 1 and Example 2. This is a block diagram showing the configuration of the user interface between the vehicle electronic control device and the driver (user) according to Example 1. This is a flowchart of the software recovery means according to a modified example of Example 1. This is a block diagram showing the overall configuration of the vehicle electronic control device according to another modified example of Example 1. This is a block diagram showing the overall configuration of the vehicle electronic control device according to Example 3. This is a block diagram showing the configuration of the vehicle electronic control device and the vehicle information management station according to another modified example of Example 1.

[0010] The configuration and operation of the vehicle electronic control device according to Embodiments 1 to 3 of the present invention will be described below with reference to the drawings. In the following description, the program (software) or its area may be described as the main processing unit, but the actual main unit is the processor.

[0011] (Example 1) The vehicle electronic control unit has the configuration shown in Figure 1 (details will be described later). The configuration in Figure 1, which can store multiple application programs, is an example of a configuration used to realize software updates via wireless communication using OTA (Over The Air) technology. The storage unit has an active program that stores the latest software and a non-active program which is the previous software (the software that was running in the vehicle electronic control unit before the update) that was switched over during the last software update.

[0012] This embodiment aims to attempt to restore the system by switching the running program to the previously used software when a software malfunction occurs during the operation of an application program and it is determined that the application cannot be used continuously.

[0013] Traditional technologies often involve switching to a backup degraded program after detecting an anomaly, taking the vehicle to a dealer for repair or device replacement, or analyzing the fault information of the recovered devices and applying corrective patches to all vehicles using OTA technology. OTA technology also includes a rollback function that reverts to the pre-update software if a problem occurs during the update process. However, if a problem occurs in the software after the update is complete, software recovery through rollback is not possible.

[0014] Therefore, this embodiment is expected to enable continued use of the software by having the vehicle's electronic control unit itself detect a software malfunction even after the update is complete, determine whether the application cannot be used continuously and a rollback is required, and switch to the previous software with a proven track record. Furthermore, by transmitting malfunction information to the vehicle information management hub with the configuration shown in Figure 10, the driver (user) can receive a corrective patch via OTA technology without having to bring the vehicle to a dealer, thereby improving driver availability.

[0015] Here, in order to determine if an abnormality exists that prevents continued use of the application, we check whether the application is not functioning correctly and is repeatedly resetting, as shown in the flow chart in Figure 2.

[0016] If a problem occurring in the latest software also occurs in the previous software, the system will switch to a recovery program. This recovery program will have limited functionality, similar to previous technologies, and the driver will be notified of this limitation. The driver can then choose to either take it to a dealer or continue using it with limited functionality until a fix patch is released.

[0017] If the previous software update was for security reasons and switching to the previous software is prohibited for security reasons, the system should either switch to a recovery program or prompt the user to bring the driver to a dealer without switching. One way to prohibit software switching is to include a function in the updated latest software to delete the previous software (the non-working program), and set conditions such as switching to the recovery program if there is no data in the non-working program when a software switch is required.

[0018] The vehicle's electronic control unit is an ECU (Electric Control Unit) for the automated driving assistance system and the automated driving system. If a software malfunction occurs while the system is in use, it may perform degraded operations such as automatic roadside assistance to ensure the driver's safety before executing a recovery process by switching the software (Figure 7). Alternatively, the system may be configured so that the recovery process can be controlled by an input / output device, allowing the driver to switch the software at any time after confirming their safety (Figure 6).

[0019] In addition to the configuration in Figure 1 that stores multiple application programs, the same means as in Figure 1 can be used to detect abnormalities and perform software switching in a configuration that has a storage area for software updates in external memory (Figure 8).

[0020] In this embodiment, the vehicle's electronic control unit switches to the previous software when a malfunction occurs, enabling continued use of the vehicle without compromising system usability.

[0021] <Configuration> Figure 1 is a block diagram showing the overall configuration of the vehicle electronic control device according to Embodiment 1.

[0022] The vehicle electronic control unit 101 includes an arithmetic unit 102 equipped with a CPU (Central Processing Unit) as a processor and RAM (Random Access Memory) as memory, a communication unit 103 (communication device) having an interface for communicating with external devices using standards such as CAN / LIN / Ethernet, a storage unit 104 (storage device) for storing software programs, an external storage unit 105 (external storage device) located in a separate area from the storage unit 104, and an anomaly detection unit 106 for detecting abnormalities in the program.

[0023] The memory unit 104 has a boot program area 111 for storing the boot program that is executed first when the software starts up, and an application program area 112 for storing application programs.

[0024] The external storage unit 105 has a recovery program 113 that has the minimum operational functions necessary to limit the functionality of the application. This external storage unit 105 may also be stored inside the storage unit 104.

[0025] The application program area 112 has a structure that allows it to store two application programs: one for the running program 121 and the other for the non-running program 122. The non-running program area 122 stores the old program that was switched to non-running during the last software update process. The program management unit 123 in the boot program area 111 controls the switching of the running program and the process of rewriting the application program area 112 with the recovery program 113.

[0026] The anomaly detection unit 106 detects software anomalies based on whether there is a WDT (Watch Dog Timer) reset request from the running program 121, the presence or absence of a fault flag, etc. If an anomaly is detected, the anomaly detection unit 106 executes a software reset and notifies the boot program area 111 of the anomaly. The boot program area 111, called by the software reset, receives the anomaly notification from the anomaly detection unit 106 and the program management unit 123 switches the running program in the application program area 112. Alternatively, the boot program area 111 causes the program management unit 123 to execute a process to rewrite the application program area 112 with the recovery program 113.

[0027] Figure 2 is a flowchart of the software recovery means according to Embodiment 1.

[0028] After a malfunction occurs, the anomaly detection unit 106 detects that the WDT (Watch Dog Timer) threshold has been exceeded or that an anomaly flag has been set by the running program 121, and then executes a software reset (201).

[0029] After a software reset (201), the software starts up from the boot program area 111, detects the reset due to an abnormality notification from the abnormality detection unit 106, and increments the reset counter by 1 (202).

[0030] If the reset counter is within the threshold X set by the designer (203: Yes), the program management unit 123 executes the application of the running program 121. If the reset counter exceeds the threshold X (203: No), the program management unit 123 switches the non-running program 122 to a running program (206), executes the application that was previously the non-running program 122, and initializes the reset counter (207).

[0031] When executing the running program 121 because the reset counter is within threshold X, if the application of the running program 121 cannot be read due to a software malfunction or a thumb check error caused by data corruption (204: No), the anomaly detection unit 106 detects this anomaly and performs another software reset (201).

[0032] The application of the running program 121 can be read, but if the software freezes or loops at "a certain point in time" (205: Yes), the anomaly detection unit 106 detects an exceedance of the WDT threshold, etc., and performs another software reset (201). "A certain point in time" refers to the timing when the function that was executed immediately before the first malfunction occurred is called, or the timing when the function that detects the anomaly flag registered at the time of the malfunction is executed once or a predetermined number of times, or the timing within a predetermined time set by the designer after the application is executed. If "a certain point in time" is exceeded without freezing or looping, the program management unit 123 sends a report (log data) of the details of the malfunction that occurred and the processes executed by the software recovery means to an external device (for example, an external device such as a server) via the communication unit 103 210. The reset counter may then be initialized, but it may not be initialized considering the possibility of the malfunction recurring in a long period of time.

[0033] After the software switch (206) and reset counter initialization (207), the process proceeds to steps 208 and 209 to switch to the recovery or correction program shown in Figure 5, or the software recovery process ends by sending a report 210 as described above.

[0034] Figure 5 is a flowchart of the software recovery means according to Embodiment 1.

[0035] In Figure 2, after switching from the non-operating program 122 to the operating program (206), in Figure 5, the application software is started (501) and it is confirmed that the application software does not freeze or loop (502). If there is an abnormality in either of these, the processes leading to program switching 201 to 205 are performed, and if the reset counter exceeds the threshold, it switches to a recovery or correction program (503). After that, the reset counter is initialized (504), and after confirming that the application software starts normally (505) and that no freeze or loop occurs (506), the program management unit 123 transmits the results and the contents of the recovery process so far as a report to the outside via the communication unit 103 210.

[0036] Figure 6 is a block diagram showing the configuration of the user interface between the vehicle electronic control device and the driver (user) according to Embodiment 1.

[0037] The vehicle electronic control unit 101 transmits its control status to the communication control unit 601 (for example, another vehicle electronic control unit) via the communication unit 103. The control status includes information on the vehicle status processed by the vehicle electronic control unit 101, as well as reports on the progress and results of the recovery process. Of this information, information that needs to be notified to the driver 603, such as the occurrence of an abnormality in the vehicle electronic control unit 101 or the start of the recovery process, is displayed on the vehicle control operation panel 602 via the communication control unit 601.

[0038] The driver 603 can operate the vehicle control operation panel 602, for example, by referring to the display 604, and can instruct the vehicle electronic control unit 101 via the communication control device 601 whether or not to perform the recovery process.

[0039] Figure 7 is a flowchart of a software recovery means according to a modified example of Embodiment 1.

[0040] After a malfunction occurs, the vehicle electronic control unit 101 performs a degraded operation (701), such as automatic road shouldering, and after the operation is completed (702: Yes), it performs a software switch (703). The software switch (703) is performed using one of the flows shown in Figures 2 and 5 or Figure 4, which will be described later. After the software switch, the application software startup status 204 and 205 is checked (704) in the same manner as in Figure 2, and then the program management unit 123 sends a report (705) via the communication unit 103 to the outside as a report, indicating whether the status was successful or not and the details of the recovery process so far.

[0041] Figure 8 is a block diagram showing the overall configuration of a vehicle electronic control device according to another modified example of Embodiment 1.

[0042] The vehicle electronic control unit 101, as shown in Figure 1, includes a calculation unit 102, a communication unit 103, a storage unit 104, an external storage unit 105, and an anomaly detection unit 106. The storage unit 104 includes a boot program area 111 and an application program area 112. The application program area 112 stores the running program 121.

[0043] The external storage unit 105 includes an update software writing area 801 for writing the new program when updating the software, a backup area 802 for writing the running program 121 as a backup when switching to the update software, and a recovery program area 803 similar to the area of ​​the recovery program 113 in Figure 1.

[0044] The backup area 802 contains the previous application program written during the last software update until the running program 121 is written to it for backup. If the anomaly detection unit 106 detects a software anomaly in the same manner as shown in Figure 1, it performs a software reset and notifies the boot program area 111 of the anomaly. The boot program area 111, called up by the software reset, receives the anomaly notification from the anomaly detection unit 106, and the program management unit 123 writes the data from the backup area 802 or the recovery program area 803 to the running program 121 and executes the application program.

[0045] FIG. 10 is a block diagram showing the configuration of a vehicle electronic control device and a vehicle information management station according to another modification of Embodiment 1.

[0046] The vehicle electronic control device 101 transmits failure data to the communication control device 601 via the communication unit 103. The failure data is the report described in the flow diagrams 2, 4, 5, and 7. The failure data is sent to the vehicle information management station 1002 via the wireless communication device 1001, and is used for failure analysis.

[0047] Modified patch data created through failure analysis is sent to the vehicle electronic control device 101 via the wireless communication device 1001 and the communication control device 601, updating the program of the vehicle electronic control device.

[0048] The main features of Embodiment 1 can also be summarized as follows.

[0049] The storage unit 104 shown in FIG. 1 stores a first program (running program 121), a second program (non-running program 122) having a different version from the first program, and a recovery program 113. The abnormality detection unit 106 detects an abnormality in the first program or the second program that is alternatively operated. The running program 121 updates the non-running second program, and the program management unit 123 switches operation from the running first program to the non-running second program. If an abnormality of the running second program is detected after a predetermined time has elapsed since switching the operation to the second program, the program management unit 123 stops the operation of the second program and switches the operation to the first program or the recovery program 113. The recovery program is, for example, a program having codes for executing vehicle drive control or software update. The abnormality is, for example, corruption of the first program or the second program (e.g., a checksum abnormality), an infinite loop or freeze of the process of the first program or the second program, or occurrence of a failure state that limits the functions of the software.

[0050] If an abnormality is detected in the running second program after a predetermined time has elapsed since switching to the updated second program, the system can self-recover even if an abnormality occurs in the updated program by rolling back or switching to the recovery program 113. As a result, the need to bring the system to a dealer is reduced, and the system's availability can be increased.

[0051] As shown in Figure 2, after detecting an abnormality in the running second program (updated and running program 122), if the second program does not operate normally even after resetting it a predetermined number of times (203: No), the program management unit 123 switches operation to the first program (deactivated program 121) or the recovery program 113 (206).

[0052] This allows the updated second program to continue running as much as possible, minimizing the need to roll back or switch to the recovery program 113. As a result, the system's availability can be increased while allowing for continued use of the latest features.

[0053] As shown in Figure 5, the program management unit 123 switches operation from the second program (updated and running program 122) to the first program (deactivated program 121), and after detecting an abnormality in the first program, if the first program does not operate normally even after resetting the first program a predetermined number of times (203: No), it switches operation to the recovery program 113 or the correction program 303 (503).

[0054] This allows the rolled-back program to continue running for as long as possible, and prevents the need to switch to the recovery program 113 or the correction program 303. As a result, system availability is increased while allowing the use of pre-update functions to continue as long as possible.

[0055] As shown in Figure 6, the vehicle electronic control unit 101 includes an output unit (vehicle control operation panel 602) that outputs information and an input unit (vehicle control operation panel 602) that receives input. Before switching operation from the second program (updated and operational program 122) to the first program (deactivated program 121) or the recovery program, the program management unit 123 outputs information via the output unit (image, sound, warning light, etc.) asking whether a switch is necessary. When the program management unit 123 receives a switch request via the input unit, it switches operation to the requested program.

[0056] This allows the system to roll back or switch to a recovery program at the user's desired timing. In this embodiment, the input and output units are integrated, such as a touch panel, but they may be separate. In this embodiment, the vehicle electronic control unit 101 is connected to the vehicle control operation panel 602 via the communication control unit 601, but the vehicle electronic control unit 101 may be directly connected to the vehicle control operation panel 602.

[0057] As shown in Figure 7, if the program management unit detects an abnormality in the running second program (updated program 122) after a predetermined time has elapsed since switching to the second program, it executes a vehicle degradation operation. After the degradation operation is completed, it stops the operation of the second program and switches to the first program (deactivated program 121) or the recovery program. The degradation operation is, for example, an automatic roadside maneuver that autonomously moves the vehicle to the roadside and stops it, or an operation that assists the user in manually moving the vehicle to the roadside and stopping it.

[0058] This allows for a rollback or a switch to recovery program 113 after ensuring safety.

[0059] As shown in Figure 8, the storage unit includes a first storage unit (storage unit 104) that stores a first program (running program 121), and a second storage unit (external storage unit 105) provided in an external area different from the first storage unit and that stores a second program (program 121 that was deactivated and backed up during the last update).

[0060] This reduces the possibility of corruption in both the memory area of ​​the first program and the memory area of ​​the second program.

[0061] As shown in Figure 10, the vehicle electronic control unit 101 includes a communication unit 103 that communicates with an external device (for example, the server of the vehicle information management bureau 1002). If the program management unit detects an abnormality in the second program (updated program 122) after a predetermined time has elapsed since switching to the second program, it transmits the input / output data and log data at the time the abnormality in the second program was detected to the external device via the communication unit 103.

[0062] By analyzing input / output data and log data sent to an external device, it is possible to create and distribute program correction patches.

[0063] (Example 2) In the software recovery described in Example 1, the system only switches to the previous software or recovery program, and the functions of the latest software cannot be used until a correction patch is applied. To address this problem, the system has a configuration (Figure 3) and process (Figure 4) in which, after switching to the previous software or recovery program, the program is self-repaired by AI (Artificial Intelligence) based on the latest software that had a problem, thereby enabling recovery to the latest software without waiting for a correction patch.

[0064] The AI ​​has a virtual machine area and, based on the type of malfunction that occurred, identifies the parts of the software that need fixing and the means of fixing them, and then updates the software to the latest version. After the fix, it performs a malfunction reproducibility check by replaying prepared test patterns and data from when the malfunction occurred in the vehicle electronic control unit and its peripheral devices reproduced in the virtual machine. If it is confirmed that the malfunction has been resolved, it writes the corrected program to the application program of the vehicle electronic control unit.

[0065] <Configuration> Figure 3 is a block diagram showing the overall configuration of the vehicle electronic control device according to Embodiment 2.

[0066] In addition to the configurations 102 to 123, the vehicle electronic control unit 101 has a virtual machine area 301 generated by the software within the vehicle electronic control unit 101. The virtual machine area 301 includes a virtual computing area 302 that reproduces the computing performance of the CPU / RAM of the arithmetic unit 102, a correction program 303 which is the same software version as the running program 121, malfunction reproduction data 304 which is input / output data inside and outside the vehicle electronic control unit before and after the abnormality detection unit detects an abnormality such as a malfunction, and control value correction data 305 which can change constants and coefficients related to program control and fault detection.

[0067] The virtual machine area 301 overwrites the data of the correction program 303 with the control value correction data 305 related to the malfunction that occurred, and verifies whether the malfunction can be reproduced using the malfunction reproduction data 304.

[0068] If the verification results show that the bug cannot be reproduced and the program correction is completed, the program management unit 123 writes the correction program 303 to the non-operating program 122 and switches to the operating program.

[0069] Figure 4 is a flowchart of the software recovery means according to Example 2.

[0070] The vehicle electronic control unit 101 shown in Figure 3 switches to the recovery program 113 using software switching means 201 to 207, similar to the flow shown in Figure 2, when a malfunction occurs (401).

[0071] Subsequently, the virtual machine area 301 starts the correction process (402) using the correction program 303, the defect reproduction data 304, and the control value correction data 305. The virtual machine (virtual machine area 301) monitors the correction status (403) and switches the running program to the correction program (404) when the correction is complete.

[0072] After switching to the corrected program, the program management unit 123 checks the application software startup status 204 and 205 as in Figure 2 (405), and then transmits a report (406) via the communication unit 103 to the outside as a report indicating whether the status was successful or not and the details of the recovery process so far.

[0073] The main features of Example 2 can also be summarized as follows:

[0074] The virtual machine (virtual machine area 301) shown in Figure 3 creates a correction program 303, which is a program obtained by modifying the second program (the running non-running program 122) based on input / output data when an abnormality is detected in the running second program (the running non-running program 122), and rewrites the second program with the correction program 303 in response to a request from the program management unit 123.

[0075] This allows the system to self-repair malfunctions. As a result, the need to bring the system to a dealer is reduced, and system availability is increased. Furthermore, the latest features can be continuously utilized. Note that the virtual machine may create the correction program 303 not only by correcting only the control parameters of the second program, but also by recoding the second program.

[0076] A virtual machine may create a fix program if it has been switched to operation by a recovery program.

[0077] This minimizes the period during which functionality is limited by the recovery program and allows for early self-repair of bugs in the updated program. As a result, system availability is enhanced while continuing to utilize the latest features.

[0078] (Example 3) The program management unit shown in Figure 1 may be provided outside the vehicle electronic control unit as shown in Figure 9. This makes it possible to switch to the previous software, recovery program, or a correction program, which has a virtual machine area as shown in Figure 3, if there is an abnormality in the boot program area, including the boot program.

[0079] <Configuration> Figure 9 is a block diagram showing the overall configuration of the vehicle electronic control device according to Embodiment 3.

[0080] The vehicle electronic control unit 101, as shown in Figure 1, includes a calculation unit 102, a communication unit 103, a storage unit 104, an external storage unit 105, and an anomaly detection unit 106. The storage unit 104 includes a boot program area 111 and an application program area 112. The application program area 112 stores the running program 121 and the non-running program 122. The external storage unit 105 stores the recovery program 113.

[0081] Furthermore, there is an external device 901 equipped with a program management unit 911 located outside the vehicle electronic control unit 101, which has the same function as the program management unit 123 of the boot program area 111 of the vehicle electronic control unit 101 in Figure 1.

[0082] If the anomaly detection unit 106 detects a software anomaly, as in Figure 1, it notifies the program management unit 911 of the anomaly and switches the startup information of the application program. Subsequently, the anomaly detection unit 106 performs a software reset and notifies the boot program area 111 of the anomaly. The boot program area 111, which was called up by the software reset, receives the anomaly notification from the anomaly detection unit 106, reads the startup information of the application program from the program management unit 911, and switches the operating program in the application program area 112.

[0083] Alternatively, when a software anomaly is detected, the anomaly detection unit 106 notifies the program management unit 911 of the anomaly, and the program management unit 911 writes the recovery program 113 for the external storage unit 105 to the non-operating program 122. Subsequently, the program management unit 911 switches the startup information of the application program, the boot program area 111, which has been reset by the anomaly detection unit 106, reads the startup information from the program management unit 911, and switches the operating program in the application program area 112.

[0084] The main features of Example 3 can also be summarized as follows:

[0085] As shown in Figure 9, the vehicle electronic control unit 101 includes an external device 901 on which a program management unit 123 is provided, and a communication unit 103 that communicates with the external device 901. For example, the first program is a boot program, and the second program is a boot program with a different version from the first program.

[0086] This allows the system to self-recover even if an error occurs in the updated boot program. As a result, the need to bring the system to a dealer is reduced, and system availability is increased.

[0087] The present invention is not limited to the embodiments described above, and includes various modifications. For example, the embodiments described above are described in detail to make the present invention easier to understand, and are not necessarily limited to those having all the configurations described. Furthermore, it is possible to replace parts of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add configurations from other embodiments to the configuration of one embodiment. In addition, it is possible to add, delete, or replace parts of the configuration of each embodiment with other configurations.

[0088] Furthermore, some or all of the above configurations and functions may be implemented in hardware, for example, by designing them as integrated circuits. Alternatively, the above configurations and functions may be implemented in software by having the processor interpret and execute programs that implement each function. Information such as programs, tables, and files that implement each function can be stored in memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.

[0089] The embodiments of the present invention may also be as follows.

[0090] (1) A vehicle electronic control device comprising: a storage unit for storing an application program including at least a first program and a second program, and a recovery program; a program management unit for switching programs and managing their states; an abnormality detection unit that runs in a different area from the application program and monitors for abnormalities in the application program; and a calculation unit that executes the application program or the recovery program, wherein the first program, when in operation, updates the second program, when inactive, the program management unit switches from the first program to the second program, and if the abnormality detection unit detects an abnormality in the second program after a predetermined time has elapsed since switching to the second program, it executes a switching process to stop the second program and switch back to the first program or the recovery program.

[0091] The anomaly detection unit detects anomalies in the running program, and the boot program responds by switching the program to run and starting the application program, enabling the software to self-recover. By self-recovering even when malfunctions occur, the need to bring the system to a dealer is reduced, and the system's availability is increased.

[0092] (2) The vehicle electronic control device described in (1), wherein the program management unit switches to the first program or the recovery program if an abnormality occurs in the second program, or if the second program does not operate normally even after being reset a predetermined number of times.

[0093] During startup of the boot program area, the reset counter can be increased by reading information from the anomaly detection unit regarding whether a reset occurred due to an anomaly. When this counter reaches a certain number of cycles, the boot program area performs a rollback. Since reverting to the previous software state means a regression in functionality, the system's availability is enhanced by avoiding rollbacks as much as possible.

[0094] (3) The vehicle electronic control device described in (2), comprising a virtual machine that reproduces the configuration of the vehicle, wherein the virtual machine creates a correction program that modifies the second program based on data inside and outside the vehicle when an abnormality occurs in the second program, and rewrites the second program with the correction program at the request of the program management unit.

[0095] The virtual machine uses its self-learning function to reconstruct the bug while modifying the control parameters of the patch program, verifying the reproducibility of the bug. By writing the patch program, which no longer reproduces the bug, to the application program, the software can self-repair bugs. Self-repair even when bugs occur reduces the need to bring the system to a dealer and increases system availability.

[0096] (4)(3) The vehicle electronic control device described above, characterized in that the correction program is created when the recovery program is being executed.

[0097] The program management department switches to the recovery program, performs software corrections using a virtual machine, and then switches back to the correction program after the corrections are complete. By performing self-repair in the background while the recovery software is running, the period during which functions are unavailable is minimized, and system availability is enhanced.

[0098] (5)(3) The vehicle electronic control device described in (3), wherein the calculation unit executes the startup process of the first program after detecting the abnormality, and if the first program does not start even after executing the startup process a predetermined number of times, it executes the startup process of the recovery program or the correction program.

[0099] After switching to the previous program, check if the reset is repeated a certain number of times using the same mechanism as in (2). If recovery is not possible even with the previous program, switch to the recovery program or correction program to increase the success rate of self-recovery and improve system availability.

[0100] (6) A vehicle electronic control device according to any one of (1) to (5), comprising an input / output unit that displays information to the driver and receives input from the driver, wherein when the program management unit switches from the second program to the first program or a recovery program, it displays to the driver whether a program switch is necessary on the input / output unit, and when a switching request is received, it executes the program switch.

[0101] By providing a vehicle control panel that handles input / output processing with the user via a communication control device, the user can control the recovery process. The system's availability is enhanced by allowing the user to determine the timing of the recovery process based on their usage.

[0102] (7) A vehicle electronic control device according to any one of (1) to (6), characterized in that when the abnormality detection unit detects an abnormality, it performs a degraded operation of the vehicle, and after the degraded operation is completed, it performs the switching control.

[0103] The program management department monitors the status of the degraded operation and executes the switchover control only after confirming the completion of the degraded operation. By avoiding accidents during operation before performing recovery procedures, user safety is enhanced.

[0104] (8) The vehicle electronic control device described in (1), wherein the storage unit includes a first storage unit for storing the first program and a second storage unit provided in an external area different from the first storage unit for storing the second program.

[0105] By providing an area for writing update programs to external memory and an area for backing up the current software version, software updates and rollbacks are achieved. Furthermore, by including a recovery program in external memory, the processes described in (1) can be performed. This provides flexibility in configuration and enhances the feasibility of the system.

[0106] (9) A vehicle electronic control device according to any one of (1) to (8), characterized in that the program management unit is provided as an external device, and the external device transmits a program switching instruction via the communication unit and performs the switching.

[0107] By placing the program management unit, which was previously located in the boot program area, in an external device, the entire program of the vehicle's electronic control unit, including the boot program, can be recovered. This increases the flexibility of the configuration and improves the feasibility of the system. The boot program can also be recovered, increasing the system's availability.

[0108] (10) A vehicle electronic control device according to any one of (1) to (9), comprising a communication unit that transmits and receives information with an external device, and characterized in that it transmits log data when the switching process is executed and log data when a malfunction occurs to the external device.

[0109] Through communication control devices and wireless communication devices, the vehicle's electronic control unit and the vehicle information management unit can send and receive malfunction data and correction software. If previous processing was only a temporary solution, developers can create and distribute correction software, reducing the need to bring the vehicle to a dealer and improving system availability.

[0110] (Other) The trigger for OTA is when update data is received from an external source, as shown in Figure 10, and this is determined by the currently running application (=running program). The program management unit in the boot program area is read when the ECU starts up (or after a soft reset), and its role is to select which program to call. Since the program management unit is a boot program, it is not running when update data is received from an external source. The program management unit can be described as "the unit that selects and manages the startup of programs."

[0111] 101...Vehicle electronic control unit 102...Calculation unit 103...Communication unit 104...Storage unit 105...External storage unit 106...Anomaly detection unit 111...Boot program area 112...Application program area 113...Recovery program 121...Running program 122...Non-running program 123...Program management unit 301...Virtual machine area 302...Virtual calculation area 303...Correction program 304...Defect reproduction data 305...Control value correction data 601...Communication control unit 602...Vehicle control operation panel 603...Driver 604...Display 801...Update software writing area 802...Backup area 803...Recovery program area 901...External device 911...Program management unit 1001...Wireless communication device 1002...Vehicle information management unit

Claims

1. A vehicle electronic control device comprising: a storage unit that stores a first program, a second program having a different version from the first program, and a recovery program; an abnormality detection unit that detects abnormalities in the first program or the second program which are operated alternately; and a program management unit that switches the non-operating second program, which has been updated by the operating first program, to an operating program, and if an abnormality in the operating second program is detected after a predetermined time has elapsed since switching to the second program, stops the operation of the second program and switches to the first program or the recovery program.

2. A vehicle electronic control device according to claim 1, wherein the program management unit, after detecting an abnormality in the operating second program, switches operation to the first program or the recovery program if the second program does not operate normally even after resetting the second program a predetermined number of times.

3. A vehicle electronic control device according to claim 2, characterized in that it includes a virtual machine that creates a correction program which is obtained by modifying the second program based on input / output data when an abnormality of the second program in operation is detected, and rewrites the second program with the correction program in response to a request from the program management unit.

4. A vehicle electronic control device according to claim 3, wherein the virtual machine creates the correction program when the operation is switched to the recovery program.

5. A vehicle electronic control device according to claim 3, wherein the program management unit switches operation to the recovery program or the correction program if, after an abnormality in the first program is detected after switching operation from the second program to the first program, the first program does not operate normally even after resetting the first program a predetermined number of times.

6. A vehicle electronic control device according to claim 1, comprising: an output unit for outputting information; and an input unit for receiving input, wherein the program management unit outputs information via the output unit to inquire whether a switch is necessary before switching operation from the second program to the first program or the recovery program, and when a switch request is received via the input unit, the vehicle electronic control device switches operation to the requested program.

7. A vehicle electronic control device according to claim 1, wherein the program management unit, when an abnormality is detected in the operating second program after a predetermined time has elapsed since switching to the operation of the second program, performs a vehicle degradation operation, stops the operation of the second program after the completion of the degradation operation, and switches to the operation of the first program or the recovery program.

8. A vehicle electronic control device according to claim 1, wherein the storage unit includes a first storage unit for storing the first program, and a second storage unit provided in an external area different from the first storage unit for storing the second program.

9. A vehicle electronic control device according to claim 1, comprising: an external device on which the program management unit is provided; and a communication unit that communicates with the external device, wherein the first program is a boot program, and the second program is a boot program of a different version from the first program.

10. A vehicle electronic control device according to claim 1, comprising a communication unit for communicating with an external device, wherein the program management unit, when an abnormality in the operating second program is detected after a predetermined time has elapsed since switching to the operation of the second program, transmits input / output data and log data at the time the abnormality in the second program was detected to the external device via the communication unit.

11. A vehicle electronic control device according to claim 1, characterized in that the recovery program is a program having code for executing vehicle drive control or software update.

12. A vehicle electronic control device according to claim 7, characterized in that the degraded operation is an automatic roadside maneuver that autonomously moves the vehicle to the roadside and stops it, or an operation that assists the user in manually moving the vehicle to the roadside and stopping it.

13. A vehicle electronic control device according to claim 1, characterized in that the abnormality is the corruption of the first program or the second program, or the process of the first program or the second program becomes stuck in an infinite loop or freezes, or a fault condition occurs that limits the functionality of the software.

Images