Vehicle electronic control device and method

JP2025034218APending Publication Date: 2025-03-13DENSO CORP
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
JP2023140471
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2023-08-30
Publication Date
2025-03-13

Smart Images

  • Figure 2025034218000001_ABST
    Figure 2025034218000001_ABST
Patent Text Reader

Abstract

To make it possible to detect an abnormality in processing by a control program which actually performs control, by installing a different version of a control program with improved performance on a control device mounted on a vehicle, and using the different version of the control program, for evaluating the different version of the control program.SOLUTION: There is installed, on a vehicle electronic control device 30 mounted on a vehicle, a sub-program which is a program capable of executing a function equivalent to a function of a main program and having a configuration different in part or in whole from that of the main program to improve performance. A calculation result of sub-processing according to the sub-program is compared with a calculation result of main processing according to the main program. On the basis of a result of the comparison, an abnormality in the main processing is determined.SELECTED DRAWING: Figure 1
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] The present disclosure relates to a vehicle electronic control device that is mounted on a vehicle and executes desired functions in the vehicle, and a method for determining an abnormality in main processing following a main program in the vehicle electronic control device. [Background technology]

[0002] For example, Patent Document 1 discloses a vehicle control device in which one microcomputer performs calculations equivalent to those of another microcomputer, and upon detecting an abnormality in the other microcomputer by comparing the results of the calculations, one microcomputer takes over the automatic driving control performed by the other microcomputer. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6777761 Summary of the Invention [Problem to be solved by the invention]

[0004] The performance of desired functions for vehicles, such as autonomous driving control functions, is improving year by year, and they are often installed in new vehicles and model-changed vehicles. Furthermore, in recent years, technology such as so-called OTA (Over The Air), which rewrites programs via wireless communication after the vehicle is released on the market, is becoming more widespread.

[0005] Here, in order to verify the performance improvement of the desired function, it is desirable to actually evaluate different versions of the control program with improved performance in various scenes that the vehicle encounters.

[0006] The present disclosure has been made in consideration of the above-mentioned points, and aims to provide a vehicle control device and method that implements different versions of a control program with improved performance in a control device mounted on a vehicle in order to evaluate the different versions of a control program with improved performance, and uses the different versions of the control program to detect abnormalities in processing by the control program that actually performs control. [Means for solving the problem]

[0007] In order to achieve the above object, the present disclosure provides an electronic control device for a vehicle that is mounted on a vehicle and executes a desired function in the vehicle, comprising: a main processing unit (36) that executes a main process according to a main program based on input data from at least one sensor; a sub-processing unit (44) that executes a sub-process according to a sub-program based on the same input data as the main processing unit; an abnormality determination unit (S560) that compares a calculation result by the main processing in the main processing unit with a calculation result by the sub-processing in the sub-processing unit and determines an abnormality in the main processing unit based on the comparison result, The desired function is executed by a main processing unit according to a main program, A subprogram is characterized in that it is capable of executing functions equivalent to those of a main program, but has a configuration that differs in part or entirely from that of the main program in order to improve performance.

[0008] The method disclosed herein is a method for determining an abnormality in main processing according to a main program executed by at least one processor in a vehicle electronic control device that is mounted on a vehicle and that executes a desired function in the vehicle, the method comprising: Executing a main process according to a main program based on input data from at least one sensor (S110 to S200); Executing a sub-process according to a sub-program based on the same input data as the main process (S440 to S510); and A calculation result of the main processing is compared with a calculation result of the sub-processing, and an abnormality in the main processing is determined based on the result of the comparison (S560). The desired function is executed by a main process following a main program, A subprogram is characterized in that it is capable of executing functions equivalent to those of a main program, but has a configuration that differs in part or entirely from that of the main program in order to improve performance.

[0009] According to the vehicle electronic control device and method disclosed herein, a subprogram, which is a program capable of executing functions equivalent to those of a main program and differs in part or all from the main program in order to improve performance, is implemented in a vehicle electronic control device mounted on a vehicle. Then, a calculation result of the subprocessing according to the subprogram is compared with a calculation result of the main processing according to the main program. An abnormality in the main processing is determined based on the comparison result. In this way, according to the vehicle electronic control device and method disclosed herein, it is possible to detect an abnormality in the main processing by the main program that actually performs control by utilizing the subprogram.

[0010] The reference numbers in parentheses above are merely an example of a correspondence with a specific configuration in an embodiment described below, in order to facilitate understanding of the present disclosure, and are not intended to limit the scope of the present disclosure in any way.

[0011] In addition, the technical features described in each claim in addition to the features of the present disclosure described above will become apparent from the description of the embodiments described below and the accompanying drawings. [Brief description of the drawings]

[0012] [Figure 1] 1 is a configuration diagram showing an example of a configuration of a vehicle electronic control device according to an embodiment; [Diagram 2]10 is a flowchart showing the processing executed by the main SoC, including the main processing according to the main program. [Diagram 3] 3 is a flowchart showing a process executed by the main SoC in parallel with the process shown in the flowchart of FIG. 2. [Figure 4] 13 is a flowchart showing processing executed by a sub-SoC, including sub-processing according to a sub-program. [Diagram 5] 5 is a flowchart showing the process executed by the sub-SoC following the flowchart in FIG. 4. [Figure 6] 11 is a table for explaining an abnormality determination in the main processing of the main SoC. [Figure 7] 1 is a flowchart illustrating a process performed by a data center. [Figure 8] 11 is a flowchart illustrating another process performed by the data center. [Figure 9] 10 is a flowchart showing a process executed by a vehicle electronic control device of a target vehicle for communication with a data center and for updating a main program and a subprogram. [Figure 10] 10 is a flowchart showing a part of a process executed by a vehicle electronic control device according to a second embodiment. [Figure 11] 10 is a flowchart showing a part of a process executed by a vehicle electronic control device according to a modified example of the second embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Hereinafter, preferred embodiments of the present disclosure will be described with reference to the drawings. Note that the same or similar configurations may be omitted from description by assigning the same reference number across multiple drawings. When only a portion of a configuration is described in each embodiment, the configuration of another embodiment described above may be applied to the other portion of the configuration. In addition to the combination of configurations explicitly stated in the description of each embodiment, configurations of multiple embodiments may be partially combined together even if not explicitly stated, as long as there is no particular problem with the combination.

[0014] (First embodiment) FIG. 1 is a configuration diagram showing an example of the configuration of a vehicle electronic control device 30 according to this embodiment. Note that the vehicle in which the vehicle electronic control device 30 is mounted is not limited to a general private passenger car, and may be a rental car vehicle, a manned taxi vehicle, a ride-sharing vehicle, a freight vehicle, a bus, or the like. In addition, the vehicle in which the vehicle electronic control device 30 is mounted may be a right-hand drive vehicle or a left-hand drive vehicle. Furthermore, the traffic environment in which the vehicle travels may be a traffic environment premised on left-hand traffic, or a traffic environment premised on right-hand traffic.

[0015] 1, the vehicle electronic control device 30 includes two SoCs (System on Chip), a main SoC 36 and a sub SoC 44, which are processors that perform various arithmetic processing according to programs. However, the processor is not limited to an SoC, and may be, for example, a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), or an NPU (Neural network Processing Unit). Furthermore, the processor may be configured with an FPGA (Field-Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), or the like.

[0016] 1 shows an example in which two SoCs are provided as processors, the number of processors may be one or may be three or more. When the number of processors is one, the main processing by the main SoC 36 and the sub-processing by the sub SoC 44 may be multitasked in a time-division manner, for example.

[0017] The programs are stored in, for example, rewritable Read Only Memory (ROM) 40, 48 connected to the main SoC 36 and the sub SoC 44, respectively. However, the form of the storage medium (non-transitory tangible storage medium) that stores the programs may be changed as appropriate, such as an optical disk, a hard disk drive, or a solid-state drive. Furthermore, the storage medium is not limited to a configuration provided on a circuit board, and may be provided in the form of, for example, a memory card, inserted into a slot, and electrically connected to each of the main SoC 36 and the sub SoC 44.

[0018] The vehicle electronic control device 30 is connected to an in-vehicle network (not shown) mounted on the vehicle, and is capable of outputting control commands to various devices, equipment, actuators, etc. of the vehicle via the in-vehicle network. The various devices, equipment, and actuators connected to the in-vehicle network can communicate with each other. In addition, various sensors may be configured to be connected to the in-vehicle network.

[0019] The vehicle electronic control device 30 has at least one camera 20 and / or at least one radar sensor 22 as sensors, and can obtain information on the surrounding environment of the vehicle by using these sensors. The camera 20 is attached, for example, to the front of the vehicle, and is configured to capture an image of the front of the vehicle and output the captured front image as serial data. The camera 20 may be attached to the vehicle so as to output a side image, a rear image, etc. of the vehicle in addition to the front image. The surrounding images such as the front image, side image, and / or rear image output from the camera 20 are input to the vehicle electronic control device 30.

[0020] The radar sensor 22 may be, for example, a millimeter wave sensor attached to the front of the vehicle and including a transmitter that transmits millimeter waves toward a front range or a front lateral range of the vehicle, a receiver that receives millimeter waves reflected by the target, and a detector that detects the target (a stationary object or a moving object) based on the transmitted and received millimeter waves. The receiver has a plurality of millimeter wave receiving antennas. The detector detects the distance to the target based on the transmission and reception time of the millimeter waves. Furthermore, the detector detects the direction of the target relative to the vehicle from the phase difference of the millimeter waves received by the plurality of receiving antennas. In this way, the radar sensor 22 generates detection information (peripheral information) of the target around the vehicle, including the distance to the target (or the transmission and reception time of the millimeter waves) and the direction of the target, and outputs the generated peripheral information as serial data. The radar sensor 22 may be provided at a plurality of locations on the vehicle so as to detect targets around the vehicle, such as a lateral range, a rear lateral range, and / or a rear range, in addition to the front range and the front lateral range of the vehicle. The surrounding information output by the radar sensor 22 is input to the vehicle electronic control unit 30 .

[0021] The surrounding image from the camera 20 and the surrounding information from the radar sensor 22, which are input to the vehicle electronic control device 30, are serial-parallel converted by the deserializers 32 and 34, respectively. Then, the surrounding image data converted by the deserializer 32 and the surrounding information data converted by the deserializer 32 are input in parallel to the main SoC 36 and the sub SoC 44, respectively. That is, the same input data is input to the main SoC 36 and the sub SoC 44.

[0022] As sensors, sensors such as a surround camera, a lidar sensor, and a sonar may be mounted on the vehicle in addition to or instead of the above-described camera 20 and radar sensor 22. Furthermore, as a receiving interface from each sensor 20, 22, instead of the above-described deserializers 32, 34, a communication interface of an in-vehicle network such as Ethernet (registered trademark) or CAN (registered trademark) may be used, and detection data from each sensor 20, 22 may be transmitted to the main SoC 36 and the sub SoC 44 via the in-vehicle network.

[0023] The vehicle electronic control device 30 may be configured to receive a detection signal from a sensor (not shown) for detecting the state of the vehicle. The sensor for detecting the state of the vehicle may include, for example, a Global Navigation Satellite System (GNSS) sensor capable of acquiring position and time information, a vehicle speed sensor for detecting the traveling speed of the vehicle, and a temperature sensor and a humidity sensor for determining weather information. The vehicle electronic control device 30 may further include a receiving device capable of receiving traffic information from an external traffic management center. Based on the received traffic information, the vehicle electronic control device 30 may obtain traffic environment data related to the traffic environment around the vehicle, such as whether or not there is a traffic jam. The vehicle electronic control device 30 may also obtain weather information from an external server.

[0024] The main SoC 36 of the vehicle electronic control device 30 executes a desired function in the vehicle by, for example, executing a main process according to a main program stored in the ROM 40 using the temporary storage function of the RAM 42. In the present embodiment, for example, as the desired function, the main SoC 36 executes a collision prevention control function that detects a target (a stationary object or a dynamic object) existing in front of the vehicle based on input data from at least one sensor such as the camera 20 or the radar sensor 22, determines the possibility of a collision with the detected target, and outputs a control command to various devices, equipment, and actuators according to the determined degree of the collision possibility. In the collision prevention control function, the main SoC 36 calculates, for example, a predicted collision time until the vehicle collides with the object ahead. When the calculated predicted collision time falls below a first time threshold, the main SoC 36 determines that the collision possibility has increased, and outputs a control command to an output device (not shown) to issue a warning by voice or display. Then, when the calculated collision prediction time falls below a second time threshold that is shorter than the first time threshold, the main SoC 36 determines that the possibility of a collision has further increased, and outputs a control command to the drive device of the vehicle to reduce the drive force, to the braking device of the vehicle to apply braking force, and / or to the steering device of the vehicle to avoid the object ahead.

[0025] The sub-SoC 44 of the vehicle electronic control device 30 also uses the temporary storage function of the RAM 50 to perform sub-processing according to a sub-program stored in the ROM 48, for example. The sub-program is a program that can execute functions equivalent to those of the main program and has a configuration that is partially or entirely different from that of the main program in order to improve performance. On the other hand, the sub-program is a program whose performance is improved compared to the main program, but whose performance has not yet been verified. Therefore, like the main SoC 36, the sub-SoC 44 can detect a target (a stationary object or a moving object) existing in front of the vehicle based on input data from at least one sensor, such as the camera 20 or the radar sensor 22, by executing sub-processing according to the sub-program, and determine the possibility of a collision with the detected target. However, since the performance verification of the sub-program has not been completed, the sub-program is not configured to actually execute, for example, the above-mentioned collision prevention control function. For this reason, the sub-program is not configured to output control commands to various devices, etc., by executing the sub-program.

[0026] In addition to executing the sub-programs, the sub-SoC 44 executes a storage process for storing a data set for evaluating the performance of the sub-programs in a data storage memory 46 serving as a storage medium. A program for performing this storage process is also stored in the ROM 48. The storage process may be configured as a part of the sub-programs.

[0027] In the storage process executed by the sub-SoC 44, the calculation result calculated by the main process according to the main program is compared with the calculation result calculated by the sub process according to the sub program. When both calculation results satisfy a predetermined deviation condition, a data set including at least one of the input data and both calculation results, which indicates the situation when the calculation result with deviation was obtained, is stored in the data storage memory 46. In this embodiment, the sub process according to the sub program performs a calculation process for determining the possibility of collision with the detected target, and when the calculation result by the sub program deviates from the calculation result by the main program, the control to store the data set indicating the situation when the calculation result with deviation was obtained in the storage medium is called a shadow mode.

[0028] The calculation results by the main processing and the calculation results by the sub-processing may use, for example, the same related index related to the performance when executing the desired function. In the case of the above-mentioned collision prevention control function, for example, the number of targets, the position of the target, and the collision prediction time to the target calculated in the main processing and the sub-processing may be used as the performance related index. Then, as a result of comparing the number of targets, the position of the target, and the collision prediction time to the target in the main processing and the sub-processing, if a deviation occurs in any of the items beyond a predetermined judgment criterion, it can be determined that the above-mentioned predetermined deviation condition is satisfied. For example, with regard to the collision prediction time, if the time difference between both collision prediction times exceeds a predetermined third time threshold, or with regard to the target position, if the difference between the positions of both targets exceeds a predetermined distance threshold, it can be determined that a deviation occurs beyond the predetermined judgment criterion. Furthermore, if a difference occurs in the number of detected targets that is equal to or greater than a predetermined target number threshold, it may also be determined that a deviation occurs beyond the predetermined judgment criterion.

[0029] The ROM 48 of the sub-SoC 44 further stores a backup program that has the same function as the main program executed by the main SoC 36 and executes a backup process (alternative process). When the sub-SoC 44 determines that there is a possibility of an abnormality occurring in the main process executed by the main SoC 36 by comparing the performance-related index of the main process with the performance-related index of the sub process, the sub-SoC 44 switches the program to be executed from the sub program to the backup program and executes backup control. The backup program is a verified program like the main program of the main SoC 36. The backup program may be the same as the main program or may be different. In this embodiment, a state in which some abnormality occurs in the main SoC 36 and the backup program is executed by the sub-SoC 44 is called a backup mode.

[0030] In this backup control, first, the sub SoC 44 compares the performance-related index of the backup process according to the switched backup program with the performance-related index of the main process according to the main program executed in the main SoC 36 to further confirm whether an abnormality has occurred in the main process executed in the main SoC 36. If this confirmation process also confirms that an abnormality has occurred in the main process executed in the main SoC 36, the sub SoC 44 determines that an abnormality has been confirmed in the main SoC 36. In this case, the sub SoC 44 outputs control commands to various devices, etc., instead of the main SoC 36, by continuing to execute the backup process according to the switched backup program. For example, normally, the control command from the main SoC 36 is output as is, but when a control command is output from both the main SoC 36 and the sub SoC 44, a selection output circuit that selects and outputs the control command from the sub SoC 44 can be provided to output the control command from the sub SoC 44. Alternatively, when the sub SoC 44 outputs a control command by backup control, it may instruct the main SoC 36 to stop outputting the control command. As a result, during backup control, various devices and the like can be driven by control commands output from the sub-SoC 44.

[0031] The data center 10 shown in FIG. 1 collects evaluation data (data set) of the subprogram stored in the vehicle electronic control device 30 of each vehicle. In addition, when the subprogram is sufficiently verified by an engineer who develops the present system and program at the data center side based on the collected evaluation data, the data center 10 distributes the verified subprogram as a new main program to each vehicle. In response to receiving the new main program, the main program in the ROM 40 of the main SoC 36 is rewritten with the new main program in each vehicle. In addition, when a different version of the subprogram with improved performance is prepared based on the collected evaluation data, the data center 10 distributes the subprogram to each vehicle. In response to receiving the different version of the subprogram in each vehicle, the subprogram in the ROM 48 of the sub SoC 44 is rewritten with the received different version of the subprogram.

[0032] The vehicle electronic control device 30 has a communication device 38 for communicating with the data center 10. In the example shown in FIG. 1, the communication device 38 is connected to the main SoC 36. For this reason, for example, when transmitting evaluation data of a subprogram to the data center 10, the main SoC 36 acquires the evaluation data from the sub SoC 44 and transmits it to the data center 10. In addition, when the communication device 38 receives a different version of the subprogram with improved performance, the main SoC 36 transfers the received subprogram to the sub SoC 44. Note that the communication device 38 may also be provided in the sub SoC 44, so that the sub SoC 44 can directly communicate with the data center 10.

[0033] Next, various processes executed in the main SoC 36 and the sub-SoC 44 will be described with reference to the flowcharts of Figures 2-5 and 7-9. Figure 2 is a flowchart showing the processes executed by the main SoC 36, including the main process according to the main program.

[0034] In the first step S100, the main SoC 36 executes a self-check. In the self-check, the main SoC 36 checks, for example, whether the supplied operating voltage is within a predetermined voltage range, whether the clock frequency that is the basis for the operation of the main SoC 36 is oscillating stably, and so on. If an abnormality is detected in this self-check, the main SoC 36 is likely to operate abnormally. Therefore, the main SoC 36 saves the result of the self-check and later provides the self-check result to the sub-SoC 44, which judges whether the main SoC 36 has an abnormality.

[0035] In step S110, the main SoC 36 receives a peripheral image from the camera 20. In step S120, the main SoC 36 performs image analysis processing on the received peripheral image to extract targets that may be obstacles to the traveling of the host vehicle. In this case, if the peripheral image includes multiple targets, the main SoC 36 extracts each of the multiple targets. Then, in step S130, the main SoC 36 calculates the relative speed of the targets based on changes in the positions and sizes of the targets in the peripheral image.

[0036] In step S140, the main SoC 36 receives surrounding information from the radar sensor 22. In step S150, the main SoC 36 extracts a target based on the received surrounding information. For example, if the horizontal, vertical, and depth distances of multiple reflecting objects are within a predetermined distance range, the multiple reflecting objects are integrated and extracted as a single target. In step S160, the main SoC 36 calculates the distance of the extracted target as, for example, the average distance or the minimum distance of the integrated multiple reflecting objects.

[0037] In step S170, the main SoC 36 compares the target extracted from the peripheral image from the camera 20 with the target extracted from the peripheral information from the radar sensor 22 based on the position and direction of the target, and associates the same targets with each other. Then, in step S180, the main SoC 36 calculates a collision prediction time, which is the time until the host vehicle collides with the target, for each associated target, using the relative speed of the target calculated in step S130 and the distance of the target calculated in step S160. Note that the main SoC 36 can calculate the distance to each target and the relative speed of each target from the peripheral image from the camera 20 by using the stereo camera. The main SoC 36 can also calculate the relative speed from the change in the distance of the target calculated from the peripheral information from the radar sensor 22 to calculate the collision prediction time. This also applies to the sub SoC 44 described later.

[0038] In step S190, the main SoC 36 determines whether or not collision prevention control is necessary based on the calculated collision prediction time. For example, when the calculated collision prediction time falls below a first time threshold, the main SoC 36 determines that collision prevention control is necessary, and in step S200, outputs a control command to an output device (not shown) to issue a warning by voice or display. Furthermore, when the calculated collision prediction time falls below a second time threshold that is shorter than the first time threshold, the main SoC 36 outputs a control command to the drive device of the vehicle to reduce the drive force, to the brake device of the vehicle to apply a braking force, and / or to the steering device of the vehicle to avoid a forward object, as collision prevention control, in step S200. Note that when multiple targets are detected, the main SoC 36 may determine whether or not collision prevention control is necessary, for example, for the target with the shortest collision prediction time.

[0039] In step S210, the main SoC 36 determines whether or not to end the desired function based on, for example, whether or not the main switch of the vehicle is turned off and the vehicle is parked. If it is determined that the function is to be ended, the main SoC 36 ends the process shown in the flowchart of Fig. 2. On the other hand, if it is determined that the function is not to be ended, the main SoC 36 repeats the process from step S100.

[0040] In the above-mentioned flowchart of FIG. 2, at least the processes of steps S110 to S200 correspond to the main process according to the main program.

[0041] Next, a description will be given of the flowchart of Fig. 3. Fig. 3 is a flowchart showing a process executed by the main SoC 36 in parallel with the process shown in the flowchart of Fig. 2.

[0042] As described below, the sub SoC 44 queries the main SoC 36 for various information in order to store evaluation data for evaluating sub-programs and to determine whether there is an abnormality in the main processing by the main SoC 36. Types of queries from the sub SoC 44 will be described in detail later. In step S300, the main SoC 36 determines whether or not a query has been received from the sub SoC 44. If it is determined that a query has been received, in step S310, the main SoC 36 replies to the sub SoC 44 with information corresponding to the query.

[0043] Next, a description will be given of the flowcharts of Figures 4 and 5. Figures 4 and 5 are flowcharts showing the processing executed by the sub-SoC 44, including the sub-processing according to the sub-program.

[0044] In the first step S400, the sub-SoC 44 executes a self-check. The contents of the self-check are the same as those of the self-check by the main SoC 36. In step S410, the sub-SoC 44 determines whether the self-check result of step S400 is OK and whether the sub-SoC 44 is in a state in which it can function normally. If the self-check result is OK, the sub-SoC 44 proceeds to step S420. On the other hand, if the self-check result is not OK, the sub-SoC 44 returns to step S400.

[0045] In step S420, the sub SoC 44 inquires of the main SoC 36 about the result of the self-check. The sub SoC 44 then receives the self-check result in response to the inquiry. The received self-check result is temporarily stored in the RAM 50. In step S430, the sub SoC 44 determines whether the self-check result of the main SoC 36 is OK. If the self-check result of the main SoC 36 is OK, the sub SoC 44 proceeds to steps S440 and S470. On the other hand, if the self-check result of the main SoC 36 is not OK, the sub SoC 44 proceeds to step S560.

[0046] The processing in steps S440 to S460 is performed by the sub SoC 44 extracting a target from the surrounding image from the camera 20 and calculating the relative speed of the target, and is basically the same as the processing in steps S110 to S130 by the main SoC 36 described above. Also, the processing in steps S470 to S490 is performed by the sub SoC 44 extracting a target from the surrounding information from the radar sensor 22 and calculating the distance to the target, and is basically the same as the processing in steps S140 to S160 by the main SoC 36 described above. However, the sub program can execute functions equivalent to those of the main program, and is a program whose configuration is partially or entirely different from that of the main program in order to improve performance, and does not necessarily perform all the same calculations as the main program.

[0047] In step S500, the sub-SoC 44 compares targets extracted from the surrounding image from the camera 20 with targets extracted from the surrounding information from the radar sensor 22, and associates the same targets with each other. Then, in step S510, the sub-SoC 44 calculates a collision prediction time, which is the time until the host vehicle collides with the target, for each of the associated targets, using the relative speed of the target calculated in step S460 and the distance of the target calculated in step S490. The comparison result and the collision prediction time by the sub-SoC 44 are temporarily stored in the RAM 50.

[0048] In step S520, the sub-SoC 44 inquires of the main SoC 36 about the matching result and the collision prediction time as the calculation result (performance-related index) of the main SoC 36. The sub-SoC 44 then receives the matching result and the collision prediction time as a reply to the inquiry. The received matching result and collision prediction time are temporarily stored in the RAM 50. In step S530, the sub-SoC 44 compares the matching result and the collision prediction time received from the main SoC 36 with the matching result and the collision prediction time calculated by the sub-SoC 44, and determines whether or not there is a discrepancy between both the matching results and the collision prediction time.

[0049] For example, if there is no difference in the number of targets in both matching results, there is no difference in the positions of the targets in both matching results that is greater than or equal to a predetermined distance threshold, and there is no difference in the predicted collision time for the target closest to the vehicle that is greater than or equal to a predetermined third time threshold, the sub-SoC 44 can determine that there is no discrepancy between both matching results and the predicted collision time. In this case, the determination result in step S540 is "NO," and the sub-SoC 44 proceeds to step S565.

[0050] On the other hand, if the number of targets in both matching results differs, the positions of targets in both matching results differ by a predetermined distance threshold or more, or the collision prediction time for the target closest to the vehicle differs by a predetermined third time threshold or more, it can be determined that a discrepancy has occurred between both matching results and the collision prediction time. In this case, the determination result in step S540 is "YES," and the sub-SoC 44 proceeds to step S550.

[0051] In step S550, since the calculation results (performance-related indexes) of both the main SoC 36 and the sub SoC 44 satisfy the predetermined deviation condition, the sub SoC 44 stores in the data storage memory 46 a data set including at least one of the input data and both calculation results, which indicates the situation when the calculation result in which the deviation occurred was obtained. The input data and both calculation results are temporarily stored in the RAM 50. The sub SoC 44 reads the corresponding data from the RAM 50 and stores it in the data storage memory 46. This allows the program evaluator to grasp the situation when the deviation occurred based on the stored data set. Therefore, the program evaluator (the engineer on the data center side) can confirm whether the performance improvement of the sub program is as expected, or whether the performance of the sub program is inferior to the performance of the main program, and if it is inferior, under what circumstances it occurred. It is preferable that the data set stored in the data storage memory 46 includes the amount of deviation of the performance-related indexes of both the main SoC 36 and the sub SoC 44. This makes it easier to grasp the degree of deviation.

[0052] Here, it is preferable that the data set includes at least the input data and both of the calculation results over a predetermined period before and after the calculation result in which the deviation occurred. This makes it possible to more accurately grasp from the data set how the deviation occurred in the calculation result. In this case, at least the input data and both of the calculation results are repeatedly stored in the RAM 50. Then, when it is determined that the calculation result has deviated, the input data and / or both of the calculation results for a predetermined period before and after the deviation are read from the RAM 50 and stored in the data storage memory 46.

[0053] In addition to including at least one of the input data and both calculation results, the data set preferably further includes at least one of the following: a version of the main program, a version of the subprogram, traffic environment data related to the traffic environment around the vehicle (e.g., congested, empty, etc.), running state data related to the running state of the vehicle (speed, whether turning, going straight, etc.), weather data related to the weather (clear, rainy, snowy, foggy, etc.), and time data related to the time. From these associated data, the program evaluator can more accurately grasp the versions of the main program and the subprogram used when the calculation result in which the deviation occurred was obtained, and the situation of the vehicle when the calculation result in which the deviation occurred was obtained. Furthermore, since the data set includes the above-mentioned associated data, for example, when evaluation data in a specific situation is required, it is possible to easily distinguish between necessary data and unnecessary data and collect the necessary data.

[0054] Furthermore, the sub-SoC 44 may limit the number of data sets to be stored to a predetermined number, taking into consideration the storage capacity of the data storage memory 46. In this case, it is preferable that the sub-SoC 44 selects data sets in descending order of the degree of deviation between the calculation results of the main SoC 36 and the sub-SoC 44, and stores the selected data sets. This is because the greater the degree of deviation of the calculation results, the higher the importance of the data set as evaluation data for the subprogram. After the number of stored data sets reaches the limit, if a calculation result with a greater degree of deviation than the stored data set is obtained, the stored data set may be overwritten with the data set at that time.

[0055] In addition, when storing the data set in the data storage memory 46, the sub-SoC 44 may store in the data storage memory 46 a data set in which the calculation result by the sub-process according to the sub-program is superior in performance in executing the desired function to the calculation result by the main process according to the main program, and a data set in which the calculation result by the sub-process is inferior in performance in executing the desired function to the calculation result by the main process. This makes it possible to evaluate the performance of the sub-program in terms of both performance improvement and performance deterioration with respect to the main program based on the stored data set. In this case, as described above, when limiting the number of data sets to be stored to a predetermined number, separate limitations may be set for the data set in which the calculation result by the sub-process is superior in performance in executing the desired function to the calculation result by the main process, and the data set in which the calculation result by the sub-process is inferior in performance in executing the desired function to the calculation result by the main process.

[0056] 4, the sub-SoC 44 determines whether or not there is a possibility that an abnormality has occurred in the main processing of the main SoC 36, based on the result of the self-check of the main SoC 36 in step S430, the result of comparing the main SoC 36 and the sub-SoC 44 with the collision prediction time in step S530, etc. For example, if it is determined in step S430 that the self-check result of the main SoC 36 is not OK, the sub-SoC 44 can determine that there is a possibility that an abnormality has occurred in the main processing of the main SoC 36.

[0057] Furthermore, as a result of comparing the collation result between the main SoC 36 and the sub SoC 44 with the collision prediction time, for example, if the sub SoC 44 detects a target while the main SoC 36 does not detect a target, the sub SoC 44 can determine that there is a possibility that an abnormality has occurred in the main processing of the main SoC 36. Furthermore, for example, if the main SoC 36 does not detect a target for calculating the collision prediction time when the collision prediction time calculated by the sub SoC 44 reaches a fourth time threshold, the sub SoC 44 can determine that there is a possibility that an abnormality has occurred in the main processing of the main SoC 36. Furthermore, for example, if the collision prediction time calculated by the main SoC 36 is delayed by more than a third time threshold with respect to the collision prediction time calculated by the sub SoC 44, the sub SoC 44 can also determine that there is a possibility that an abnormality has occurred in the main processing of the main SoC 36.

[0058] The above-mentioned abnormality determination in the main processing of the main SoC 36 will be described from another perspective with reference to the table in Fig. 6. In the table in Fig. 6, a circle is attached when a target is extracted from the peripheral image from the camera 20 and when a target is extracted from the peripheral information from the radar sensor 22, and a cross is attached when a target is not extracted. For example, in case 1, in the main processing and the sub-processing, a target is extracted from the peripheral image from the camera 20 and the peripheral information from the radar sensor 22, respectively. In this case, if there is no difference in the number, position, and collision prediction time of the targets to a degree that would determine an abnormality in the main SoC 36, the sub SoC 44 executes the shadow mode, and if there is a difference to a degree that would determine an abnormality in the main SoC 36, the sub SoC 44 executes the backup mode.

[0059] In cases 2 to 4, 8, and 12, there is a defect in the detection of a target by the camera 20 and / or the radar sensor 22 in the sub-processing, whereas in the main processing, the target is detected normally by the camera 20 and / or the radar sensor 22 compared to the sub-processing. In this case, the main processing by the main SoC 36 can be regarded as being executed normally, and therefore the sub SoC 44 executes the shadow mode.

[0060] On the other hand, in the cases 5, 9, 13, 14, and 15, the detection of the target by the camera 20 and / or the radar sensor 22 in the sub-processing is normal, while in the main processing, there is a defect in the detection of the target by the camera 20 and / or the radar sensor 22 compared to the sub-processing. In this case, since there is a possibility that an abnormality has occurred in the main processing by the main SoC 36, the sub SoC 44 executes the backup mode.

[0061] In cases 6, 7, 10, and 11, in both the sub-processing and the main processing, there is a defect in the detection of targets by the camera 20 or the radar sensor 22. Therefore, in this case, as described above, based on the number of targets, their positions, and the predicted collision time, it is determined whether or not there is a possibility that an abnormality has occurred in the main processing by the main SoC 36, and depending on the result of the determination, either the shadow mode or the backup mode is executed.

[0062] In case 16, it is not possible to determine whether or not there is a possibility that an abnormality has occurred in the main processing by the main SoC 36. Therefore, the sub SoC 44 executes the shadow mode.

[0063] Thus, in this embodiment, when the calculation result (performance-related index) by the main processing is inferior to the calculation result (performance-related index) by the sub-processing in executing a desired function by exceeding the abnormality determination criterion as described above, the sub-SoC 44 determines that there is a possibility that an abnormality in the main processing (or an abnormality in the main SoC 36) has occurred. Therefore, according to the vehicle electronic control device and method of this embodiment, it is possible to detect an abnormality in the main processing by the main program that actually performs control by utilizing the sub-program.

[0064] If the sub-SoC 44 determines in step S560 that there is a possibility that an abnormality has occurred in the main processing of the main SoC 36, the process proceeds to step S570 in the flowchart of Fig. 5. On the other hand, if the sub-SoC 44 determines that there is no possibility that an abnormality has occurred in the main processing of the main SoC 36, the process proceeds to step S565. In step S565, the sub-SoC 44 determines whether or not to terminate the desired function (i.e., the collision prevention control function). If it is determined that the function is to be terminated, the sub-SoC 44 terminates the process shown in the flowchart of Fig. 4. On the other hand, if it is determined that the function is not to be terminated, the sub-SoC 44 returns to step S400.

[0065] In step S570, data and calculation results stored in RAM 50 are discarded during the sub-processing according to the sub-program. In step S580, sub-SoC 44 switches the program to be executed from the sub-program (or the abnormality determination processing of the main program) to the backup program. In the flowchart of FIG. 4 described above, at least the processing of steps S440 to S510 corresponds to the sub-processing according to the sub-program. Furthermore, the processing of steps S530 to S550 corresponds to a storage processing for storing a data set for evaluating the performance of the sub-program. Furthermore, the processing of steps S560 and S570 corresponds to an abnormality determination processing of the main program. The storage processing and abnormality determination processing may be configured as part of the sub-program.

[0066] In step S590, the sub-SoC 44 calculates the predicted collision time until the collision with the target by the backup program after switching. Note that at this time, the sub-SoC 44 executes the backup program after switching to calculate the predicted collision time until the collision with the target after at least the calculation processing of steps S110 to S170 described above.

[0067] In step S600, the sub SoC 44 inquires of the main SoC 36 about the predicted collision time. The sub SoC 44 then receives the predicted collision time in response to the inquiry. In step S610, the sub SoC 44 compares the predicted collision time received from the main SoC 36 with the predicted collision time calculated by the sub SoC 44 to determine whether or not there is an abnormality in the main SoC 36. Note that in step S600, the sub SoC 44 may inquire of the main SoC 36 not only about the predicted collision time but also about the comparison result, and in step S610, determine whether or not there is an abnormality in the main SoC 36 based on the comparison result between the comparison result and the predicted collision time.

[0068] As a result of the comparison process in step S610, for example, when the collision prediction time calculated by the sub SoC 44 reaches the fourth time threshold, if the main SoC 36 does not detect a target object for calculating the collision prediction time, or if the collision prediction time calculated by the main SoC 36 is delayed by more than the third time threshold with respect to the collision prediction time calculated by the sub SoC 44, the sub SoC 44 determines that an abnormality has occurred in the main processing of the main SoC 36. Furthermore, if the result of the self-check of the main SoC 36 is NG, the sub SoC 44 also determines that an abnormality has occurred in the main processing of the main SoC 36. If such a determination is made, in step S620, the sub SoC 44 determines that an abnormality has been confirmed in the main SoC 36, and proceeds to step S630. On the other hand, if the sub SoC 44 determines in step S610 that no abnormality has occurred in the main processing of the main SoC 36, and if the result of the self-check of the main SoC 36 is OK, the sub SoC 44 proceeds to step S650.

[0069] In step S630, the sub SoC 44 continues to execute the switched backup program, thereby outputting a control command from the sub SoC 44 as necessary. Then, in step S640, the sub SoC 44 determines whether or not to terminate the desired function (i.e., the collision prevention control function). If it is determined that the function is to be terminated, the sub SoC 44 terminates the process shown in the flowcharts of FIG. 4 and FIG. 5. On the other hand, if it is determined that the function is not to be terminated, the sub SoC 44 repeats the process from step S590. At this time, once the sub SoC 44 determines that an abnormality in the main SoC 36 has been confirmed, the sub SoC 44 may be configured to output a control command in step S630 regardless of the process results of steps S600 to S620. Alternatively, once the sub SoC 44 determines that an abnormality in the main SoC 36 has been confirmed, the process of steps S600 to S620 may be skipped.

[0070] In step S650, which is executed when it is determined in step S620 that the main SoC 36 is normal, the sub-SoC 44 also determines whether or not to terminate the desired function. If it is determined that the function is to be terminated, the sub-SoC 44 terminates the process shown in the flowcharts of FIG. 4 and FIG. 5. On the other hand, if it is determined that the function is not to be terminated, the sub-SoC 44 proceeds to step S660. In step S660, after switching to the backup program, the data and calculation results stored in the RAM 50 are discarded. Next, in step S670, the sub-SoC 44 switches the program to be executed from the backup program to the sub-program. After that, the sub-SoC 44 returns to step S400 in the flowchart of FIG. 4.

[0071] Next, a description will be given of the flowchart in Fig. 7. Fig. 7 is a flowchart showing the processing executed by the data center 10.

[0072] In the first step S700, when the data center 10 prepares a different version of the subprogram with improved performance based on collected evaluation data, etc., the data center 10 distributes the prepared subprogram to a target vehicle. The target vehicle is a vehicle that uses the corresponding subprogram. The data center 10, for example, assigns a vehicle ID to each vehicle and manages the type of program used in each vehicle in a database.

[0073] In step S710, the data center 10 inquires of the target vehicles having the subprogram to be evaluated implemented in the sub-SoC 44 about the evaluation data (data set) of the subprogram. In response to this inquiry, each target vehicle replies with an overview of the stored evaluation data, i.e., the comparison result of the performance-related indexes, the magnitude of deviation (i.e., the amount of deviation), the versions of the main program and the subprogram, and / or associated data indicating the situation when the deviation occurred, as described below. In this way, each target vehicle does not immediately transmit input data such as a camera image, but transmits an overview of the evaluation data, thereby suppressing an increase in the communication load, and the data center 10 can perform screening of the collected data, as described below. The overview of the evaluation data is also included in the evaluation data.

[0074] In step S720, the data center 10 judges whether or not the evaluation data is necessary based on the summary of the evaluation data returned from each target vehicle. For example, if sufficient evaluation data in a similar situation has already been collected, the data center 10 judges the corresponding evaluation data as "unnecessary". Conversely, if sufficient evaluation data in a similar situation has not been collected, the data center 10 judges the corresponding evaluation data as "necessary". The data center 10 may also judge whether or not the evaluation data is necessary based on the magnitude of deviation of the performance-related index. For example, the data center 10 may judge evaluation data with a deviation of a predetermined magnitude or more as "necessary" and evaluation data with a deviation of less than the predetermined magnitude as "unnecessary". Alternatively, the data center 10 may judge evaluation data with a deviation of equal to or greater than the minimum deviation among the evaluation data already collected as "necessary" and judge evaluation data with a deviation of less than the minimum deviation as "unnecessary". If the evaluation data is determined to be "necessary", the data center 10 proceeds to step S730. On the other hand, if the evaluation data is determined to be "unnecessary", the data center 10 proceeds to step S750.

[0075] In step S730, the data center 10 instructs target vehicles for which it has determined that evaluation data is "necessary" to transmit all evaluation data, including input data such as camera images. Then, in step S740, it receives all evaluation data from each target vehicle, and stores all of the received evaluation data in a database. Meanwhile, in step S750, the data center 10 instructs target vehicles for which it has determined that evaluation data is "unnecessary" to discard the evaluation data.

[0076] Then, in step S760, the data center 10 determines whether the required amount of evaluation data has been collected or whether evaluation data has been collected from all of the target vehicles. In this determination, if it is determined that the required amount of evaluation data has been collected or that evaluation data has been collected from all of the target vehicles, the data center 10 ends the process shown in the flowchart of Fig. 7. On the other hand, if it is determined that the required amount of evaluation data has not yet been collected or that evaluation data has not yet been collected from all of the target vehicles, the data center 10 returns to step S710.

[0077] Next, a description will be given of the flowchart of Fig. 8. Fig. 8 is a flowchart showing another process executed by the data center 10.

[0078] When the performance of the subprogram is verified based on sufficient evaluation data, the subprogram is distributed to each target vehicle as an updated main program for updating the existing main program. In the first step S800 of Fig. 8, the data center 10 distributes the updated main program to the target vehicle. Then, in step S810, the version of the distributed main program is written in a database, for example, to store the update information.

[0079] Next, a description will be given of the flowchart of Fig. 9. Fig. 9 is a flowchart showing the process executed by the vehicle electronic control unit 30 of the target vehicle for communication with the data center 10 and for updating the main program and the subprogram.

[0080] In the first step S900, the vehicle electronic control unit 30 determines whether or not an updated main program has been distributed from the data center 10. If an updated main program has been distributed, the vehicle electronic control unit 30 receives the updated main program in step S910. Then, the vehicle electronic control unit 30 overwrites the existing main program in the main program writing ROM 40 with the received updated main program. In this manner, the vehicle electronic control unit 30 rewrites the main program writing ROM 40.

[0081] In step S920, the vehicle electronic control unit 30 determines whether a different version of the subprogram with improved performance has been distributed from the data center 10 based on the collected evaluation data, etc. If a different version of the subprogram with improved performance has been distributed, the vehicle electronic control unit 30 receives the different version of the subprogram in step S930. Then, the vehicle electronic control unit 30 overwrites the existing subprogram in the subprogram writing ROM 48 with the received different version of the subprogram. In this manner, the vehicle electronic control unit 30 rewrites the subprogram writing ROM 48.

[0082] In step S940, the vehicle electronic control unit 30 determines whether or not an inquiry about the evaluation data of the subprogram has been received from the data center 10. If it is determined that an inquiry about the evaluation data has been received, the vehicle electronic control unit 30 transmits an overview of the stored evaluation data (data stored in the data storage memory 46) in step S950. However, if no evaluation data is stored, the vehicle electronic control unit 30 replies to that effect to the data center 10.

[0083] In step S960, the vehicle electronic control unit 30 determines whether it has received an instruction to transmit evaluation data of the subprogram from the data center 10, or an instruction to discard the evaluation data. If it has received the instruction to transmit, the vehicle electronic control unit 30 transmits the stored evaluation data to the data center 10 in step S970. On the other hand, if it has received the instruction to discard the evaluation data, the vehicle electronic control unit 30 discards the stored evaluation data in step S980.

[0084] As described above, according to the vehicle electronic control device 30 of this embodiment, when a discrepancy occurs between the calculation results of a subprogram, which is a different version of a program with improved performance for a desired function, and a main program, which is a current version of a program that executes the desired function, a data set indicating the situation at that time is stored in a storage medium. The stored data set includes at least either the input data or the results of both calculations. Therefore, according to the vehicle electronic control device 30 of this embodiment, it is possible to efficiently store data sets that are important for evaluating the subprogram in a storage medium and efficiently collect data at the data center 10.

[0085] Second embodiment Next, a vehicle electronic control device 30 according to a second embodiment of the present disclosure will be described. The vehicle electronic control device 30 according to this embodiment may be configured similarly to the vehicle electronic control device 30 according to the first embodiment. Therefore, a description of the configuration will be omitted.

[0086] The vehicle electronic control device 30 according to the first embodiment described above stores in a storage medium a data set indicating the situation when a discrepancy occurs between the calculation result of the main processing according to the main program and the calculation result of the sub-processing according to the sub-program.

[0087] In contrast, in the vehicle electronic control device 30 according to this embodiment, when a discrepancy occurs between the calculation result of the main process according to the main program and the calculation result of the sub process according to the sub program, the vehicle electronic control device 30 does not store a data set indicating the situation when the calculation result in which the discrepancy occurred was obtained, but instead inquires of the data center 10 about the necessity of storing the data set. Then, when the data center 10 responds that the data set needs to be stored, the vehicle electronic control device 30 stores the corresponding data set in a storage medium. This makes it possible to avoid storing unnecessary data sets and efficiently use the storage capacity of the storage medium.

[0088] Fig. 10 is a flowchart showing a storage process executed by the vehicle electronic control device 30 (sub-SoC 44) according to this embodiment. The flowchart shown in Fig. 10 includes steps S542 and S544 in addition to the flowchart in Fig. 4. The other steps are the same in the flowchart in Fig. 4 and the flowchart in Fig. 10.

[0089] If it is determined in step S540 that there is a discrepancy between the results of both calculations, the sub-SoC 44 proceeds to step S542. In step S542, the sub-SoC 44 transmits information about the data set (e.g., information equivalent to an overview of the evaluation data described above) to the data center 10, and inquires of the data center 10 about whether the data set needs to be stored. In step S544, if the sub-SoC 44 determines that the data set needs to be stored based on the reply from the data center 10, it proceeds to step S550. In step S550, the sub-SoC 44 stores the data set in a storage medium. On the other hand, if the data center 10 responds that storage of the data set is not required, the sub-SoC 44 proceeds to step S565 without storing the data set.

[0090] In the above-described example, the vehicle electronic control device 30 inquires of the data center 10 about the necessity of storing a data set. However, the vehicle electronic control device 30 may acquire selection information for selecting data sets to be stored from the data center 10 in advance, and store only data sets that match the selection information in the storage medium.

[0091] Fig. 11 is a flowchart including a storage process for storing only the data sets that match the selection information. The flowchart shown in Fig. 11 includes steps S544 and S546 in addition to the flowchart in Fig. 4. The other steps are the same in the flowchart in Fig. 4 and the flowchart in Fig. 11.

[0092] If it is determined in step S540 that there is a discrepancy between the results of both calculations, the sub-SoC 44 proceeds to step S544. In step S544, the sub-SoC 44 determines whether the data set matches the selection information acquired in advance. If the data set matches the selection information, the determination result in step S546 becomes "YES", and in step S550, the sub-SoC 44 stores the data set in a storage medium. On the other hand, if the data center does not match the selection information, the determination result in step S546 becomes "NO", and the sub-SoC 44 proceeds to step S565 without storing the data set.

[0093] Although the above describes preferred embodiments of the present disclosure, the present disclosure is not limited to the above-described embodiments and can be modified in various ways without departing from the spirit and scope of the present disclosure.

[0094] For example, in each of the above-described embodiments, the vehicle electronic control device 30 has been described as executing a collision prevention control function as a desired function. However, the function executed by the vehicle electronic control device 30 is not limited to the collision prevention control function. For example, the vehicle electronic control device 30 may execute, as desired functions, a rear cross traffic alert function that detects a moving object approaching from a blind spot when the vehicle is backing up and issues a warning or automatically activates the brakes, an adaptive cruise control function that detects a vehicle ahead and follows the vehicle while maintaining a distance therebetween, a traffic sign recognition function that recognizes various traffic signs on the road and notifies the driver, a lane departure prevention function that detects white lines on the road and supports driving within the lane, a blind spot monitoring function that detects a vehicle approaching from the side or rear and notifies the driver, and the like.

[0095] For example, when detecting objects such as other vehicles in a rear cross traffic alert function, blind spot monitoring function, adaptive cruise control function, etc., the deviation of the calculation result may be determined based on the detectable distance. In addition, for a traffic sign recognition function, the deviation of the calculation result may be determined based on the recognizable distance and recognition rate of a traffic sign. In the lane departure prevention function, the deviation of the calculation result may be determined based on the recognition rate of white lines and the vehicle position within the white lines (the closer to the center, the higher the performance).

[0096] In each of the above-described embodiments, input data such as the surrounding image from the camera 20 and the surrounding information from the radar sensor 22 are input in parallel from each of the deserializers 32, 34 to the main SoC 36 and the sub SoC 44. However, the input data may be configured to be input once to the main SoC 36 and then transmitted from the main SoC 36 to the sub SoC 44 via a communication interface.

[0097] The control device and the method executed by the control device described in the present disclosure may be realized by a special-purpose computer having a processor programmed to execute one or more functions embodied in a computer program. Alternatively, the control device and the method executed by the control device described in the present disclosure may be realized by one or more special-purpose computers configured by a combination of a processor executing a computer program and one or more hardware logic circuits.

[0098] Finally, this specification discloses the following technical ideas and combinations thereof. The combinations of the following technical ideas apply not only to the vehicle electronic control device 30 but also to a method for determining an abnormality in main processing according to a main program, which is executed by at least one processor in the vehicle electronic control device 30.

[0099] (Technical thought 1) A vehicle electronic control device that is mounted on a vehicle and executes a desired function in the vehicle, a main processing unit (36) that executes a main process according to a main program based on input data from at least one sensor; a sub-processing unit (44) that executes a sub-process according to a sub-program based on the same input data as the main processing unit; an abnormality determination unit (S560) that compares a calculation result by the main processing in the main processing unit with a calculation result by the sub-processing in the sub-processing unit and determines an abnormality in the main processing unit based on the comparison result, the desired function is executed by the main processing unit through the main processing following the main program, The subprogram is capable of executing functions equivalent to those of the main program, and is a program having a configuration that differs in part or in whole from that of the main program in order to improve performance.

[0100] (Technical thought 2) the calculation result by the main processing and the calculation result by the sub-processing are the same type of performance-related index related to performance when executing the desired function, The abnormality determination unit determines an abnormality in the main processing unit when a performance-related index generated by the main processing is inferior to a performance-related index generated by the sub-processing by exceeding an abnormality determination criterion in executing the desired function.

[0101] (Technical Thought 3) the sub-processing unit has a verified program for executing an alternative process to the main process, The electronic control device for a vehicle described in Technical Idea 1 or 2, wherein the sub-processing unit switches the execution target program from the sub-program to a verified program for executing the alternative processing in response to the abnormality determination unit determining an abnormality in the main processing unit.

[0102] (Technical Thought 4) The electronic control device for a vehicle described in Technical Idea 3, wherein the sub-processing unit switches to a verified program for executing the alternative processing, and then compares the calculation results of the alternative processing with the calculation results of the main processing in the main processing unit, and determines an abnormality in the main processing unit based on the comparison result.

[0103] (Technical Thought 5) The electronic control device for a vehicle according to Technical Idea 3 or 4, wherein the sub-processing unit executes the desired function by the alternative processing according to the switched verified program in place of the main processing of the main processing unit.

[0104] (Technical Thought 6) The apparatus further includes an abnormality detection unit for detecting an abnormality in the sub-processing unit, The electronic control device for a vehicle according to any one of Technical Ideas 3 to 5, wherein when the abnormality detection means detects an abnormality in the sub-processing unit, the sub-processing unit does not switch the program to be executed.

[0105] (Technical Thought 7) the sub-processing unit has a data storage unit that temporarily stores data during execution of the sub-processing according to the sub-program; The electronic control device for a vehicle described in any one of Technical Ideas 3 to 6, wherein the sub-processing unit discards the data stored in the data storage unit in response to switching the execution target program from the sub-program to a verified program for executing the alternative processing. [Explanation of symbols]

[0106] 10: data center, 20: camera, 22: radar sensor, 30: vehicle electronic control device 32: Deserializer, 34: Deserializer, 38: Communication device, 40: ROM, 42: RAM, 46: Data storage memory, 48: ROM, 50: RAM

Claims

1. A vehicle electronic control device that is mounted on a vehicle and executes a desired function in the vehicle, a main processing unit (36) that executes a main process according to a main program based on input data from at least one sensor; a sub-processing unit (44) that executes a sub-processing according to a sub-program based on the same input data as the main processing unit; an abnormality determination unit (S560) that compares a calculation result by the main processing in the main processing unit with a calculation result by the sub-processing in the sub-processing unit and determines an abnormality in the main processing unit based on the comparison result, the desired function is executed by the main processing unit according to the main program, The subprogram is capable of executing functions equivalent to those of the main program, and is a program having a configuration that differs in part or in whole from that of the main program in order to improve performance.

2. the calculation result by the main processing and the calculation result by the sub-processing are the same type of performance-related index related to performance when executing the desired function, 2. The electronic control device for a vehicle according to claim 1, wherein the abnormality determination unit determines an abnormality in the main processing unit when a performance-related index resulting from the main processing is inferior to a performance-related index resulting from the sub-processing by exceeding an abnormality determination criterion in terms of executing the desired function.

3. the sub-processing unit has a verified program for executing an alternative process to the main process, 3. The electronic control device for a vehicle according to claim 1, wherein the sub-processing unit switches the execution target program from the sub-program to a verified program for executing the alternative processing in response to the abnormality determination unit determining an abnormality in the main processing unit.

4. 4. The electronic control device for a vehicle according to claim 3, wherein the sub-processing unit, after switching to a verified program for executing the alternative processing, compares a calculation result of the alternative processing with a calculation result of the main processing in the main processing unit, and determines an abnormality in the main processing unit based on the comparison result.

5. The electronic control device for a vehicle according to claim 3 , wherein the sub-processing unit executes the desired function by the alternative processing according to the switched verified program in place of the main processing of the main processing unit.

6. The apparatus further includes an abnormality detection means (S400) for detecting an abnormality in the sub-processing unit, 4. The electronic control device for a vehicle according to claim 3, wherein when the abnormality detection means detects an abnormality in the sub-processing unit, the sub-processing unit does not switch the program to be executed.

7. the sub-processing unit has a data storage unit that temporarily stores data during execution of the sub-processing according to the sub-program; 4. The electronic control device for a vehicle according to claim 3, wherein the sub-processing unit discards the data stored in the data storage unit in response to switching the execution target program from the sub-program to a verified program for executing the alternative process.

8. A method for determining an abnormality in main processing according to a main program, the method being executed by at least one processor in a vehicle electronic control device that is mounted on a vehicle and that executes a desired function in the vehicle, comprising: Executing a main process according to a main program based on input data from at least one sensor (S110 to S200); Executing a sub-process according to a sub-program based on the same input data as the main process (S440 to S510); and comparing a calculation result from the main processing with a calculation result from the sub-processing, and determining whether or not there is an abnormality in the main processing based on the result of the comparison (S560); the desired function is executed by the main process in accordance with the main program, A method in which the subprogram is capable of executing functions equivalent to those of the main program, and is a program whose configuration differs in part or in whole from that of the main program in order to improve performance.

Citation Information

Patent Citations

  • Vehicle control device

    JP6777761B2