Vehicle electronic control device and method

Abstract

To provide a vehicle control device and method which make it possible to efficiently obtain data for evaluating a new version of a control program.SOLUTION: When a deviation occurs between a calculation result of a sub-program which is a different version of a program designed to improve performance with respect to a desired function, and a calculation result of a main program which is a current version of a program for executing the desired function, a vehicle electronic control device 30 stores a data set indicating a situation at that time in a storage medium 46. The stored data set includes at least either input data or both of the calculation results. Therefore, according to the vehicle electronic control device 30, it is possible to efficiently store, in the storage medium 46, the data set which is important for evaluating the sub-program.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a vehicle electronic control unit that is installed in a vehicle and that performs a desired function in the vehicle, and a method for storing a desired data set in the vehicle electronic control unit. [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 when a comparison of the calculation results detects that an abnormality has occurred in the other microcomputer, 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 vehicle functions, such as autonomous driving control functions, is improving year by year, and they are often installed in new vehicles and remodeled vehicles. Furthermore, in recent years, technologies such as over-the-air (OTA), which allow programs to be rewritten via wireless communication after a vehicle is released to the market, are becoming more widespread.

[0005] In order to verify the performance improvement of a desired function, it is desirable to evaluate different versions of the control program with improved performance in various situations that a vehicle would actually encounter. However, if evaluation data were to be obtained for such an evaluation by running a test vehicle equipped with different versions of the control program on a public road or the like, it would require driving a very long distance, which would require a huge amount of work.

[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 can efficiently obtain evaluation data for different versions of control programs with improved performance. [Means for solving the problem]

[0007] In order to achieve the above object, the present disclosure provides a vehicle electronic control device that is mounted on a vehicle and performs a desired function in the vehicle, a main processing unit (36) that executes main processing 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; a storage unit (S530, S540, S550) that compares the calculation result of the main processing in the main processing unit with the calculation result of the sub-processing in the sub-processing unit, and, when both calculation results satisfy a predetermined deviation condition, stores in a storage medium (46) a data set that includes at least one of the input data and both calculation results and indicates the situation when both calculation results with deviation were obtained; The desired function is executed by a main processing unit according to a main program, A subprogram is characterized by being a program that can execute functions equivalent to those of a main program, but differs in part or in whole from the main program in order to improve performance.

[0008] The present disclosure also provides a method for storing a desired data set, the method being executed by at least one processor in a vehicle electronic control device that is mounted on a vehicle and that performs 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 comparing the calculation result of the main processing with the calculation result of the sub-processing, and if both calculation results satisfy a predetermined deviation condition, storing in a storage medium (46) a data set including at least either the input data or both calculation results, which indicates the situation when both calculation results with deviation were obtained (S530, S540, S550); The desired function is executed by a main process according to a main program, A subprogram is characterized by being capable of executing functions equivalent to those of a main program, and having a configuration that is partially or entirely different from that of the main program in order to improve performance.

[0009] When evaluating a subprogram, a data set that shows the deviation of the subprogram's results from the main program's results is important, because such a data set can be used to check whether the subprogram's performance improvement is as expected, or whether the subprogram's performance is inferior to that of the main program.

[0010] In this regard, according to the vehicle electronic control device and method disclosed herein, when a discrepancy occurs between the operation results of a subprogram, which is a different version of a program with improved performance for a desired function, and the operation results of 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 input data or the operation results of both programs. Therefore, according to the vehicle electronic control device and method disclosed herein, it is possible to efficiently store data sets that are important for evaluating the subprogram in a storage medium.

[0011] The reference numbers in parentheses above merely indicate an example of the correspondence with specific configurations in the embodiments 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.

[0012] Furthermore, the technical features of the present disclosure other than those described above will become apparent from the following description of the embodiments and the accompanying drawings. [Brief explanation of the drawings]

[0013] [Figure 1] 1 is a configuration diagram showing an example of the configuration of a vehicle electronic control device according to an embodiment; [Figure 2] 10 is a flowchart showing the processing executed by the main SoC, including the main processing according to the main program. [Figure 3] 3 is a flowchart showing processing executed by the main SoC in parallel with the processing shown in the flowchart of FIG. 2. [Figure 4] 10 is a flowchart showing processing executed by a sub-SoC, including sub-processing according to a sub-program. [Figure 5] 5 is a flowchart showing the processing executed by the sub-SoC, following the flowchart of FIG. 4. [Figure 6] 10 is a diagram for explaining abnormality determination in the main processing of the main SoC. [Figure 7] 10 is a flowchart illustrating a process performed by a data center. [Figure 8] 10 is a flowchart illustrating another process performed by the data center. [Figure 9] 10 is a flowchart showing the processing executed by the vehicle electronic control unit of the target vehicle for communication with the data center and updating of the main program and subprograms. [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 INVENTION

[0014] Preferred embodiments of the present disclosure will be described below with reference to the drawings. Note that identical or similar configurations may be omitted from the description by assigning the same reference numerals across multiple drawings. When only a portion of a configuration is described in each embodiment, the configuration of another previously described embodiment may be applied to the remaining portion of the configuration. Furthermore, 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.

[0015] (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 installed is not limited to a general private passenger car, but may also be a rental car vehicle, a manned taxi vehicle, a ride-sharing vehicle, a freight vehicle, a bus, etc. Furthermore, the vehicle in which the vehicle electronic control device 30 is installed 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 in which traffic is premised on left-hand traffic, or a traffic environment in which traffic is premised on right-hand traffic.

[0016] 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 processors are not limited to SoCs and may be, for example, a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), or an NPU (Neural Network Processing Unit). Furthermore, the processors may be configured using an FPGA (Field-Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), or the like.

[0017] 1 shows an example in which two SoCs are provided as processors, the number of processors may be one or three or more. When there is one processor, the main SoC 36 and the sub-SoC 44 may be mounted on the same chip. The main processing by the main SoC 36 and the sub-processing by the sub-SoC 44 may be multitasked, for example, by time sharing.

[0018] The programs are stored, for example, in rewritable read-only memories (ROMs) 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 being 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 the main SoC 36 and the sub-SoC 44, respectively.

[0019] The vehicle electronic control device 30 is connected to an in-vehicle network (not shown) installed in the vehicle, and is capable of outputting control commands to various devices, equipment, actuators, etc. in the vehicle via this 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.

[0020] The vehicle electronic control device 30 has at least one camera 20 and / or at least one radar sensor 22 as sensors, and is able to acquire information about the surrounding environment of the vehicle 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, in addition to the front image, a side image of the vehicle, a rear image of the vehicle, and the like. 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.

[0021] The radar sensor 22 may be, for example, a millimeter-wave sensor attached to the front of the host vehicle and including a transmitter that transmits millimeter waves toward a range in front of the host vehicle, a range in front of the host vehicle to the sides of the vehicle, a receiver that receives millimeter waves reflected by the target, and a detector that detects the target (a stationary or moving object) based on the transmitted and received millimeter waves. The receiver has multiple 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 orientation of the target relative to the vehicle from the phase difference of the millimeter waves received by the multiple receiving antennas. In this way, the radar sensor 22 generates detection information (periphery information) of targets around the host vehicle, including the distance to the target (or the transmission and reception time of the millimeter waves) and the orientation of the target, and outputs the generated peripheral information as serial data. Note that the radar sensor 22 may be installed at multiple locations on the host vehicle so as to detect targets around the host vehicle in the lateral range, rear-side range, and / or rear range in addition to the range in front of the host vehicle and the range in front of the host vehicle. The surrounding information output by the radar sensor 22 is input to the vehicle electronic control unit 30 .

[0022] The peripheral image from the camera 20 and the peripheral information from the radar sensor 22, which are input to the vehicle electronic control device 30, are serial-to-parallel converted by the deserializers 32 and 34, respectively. Then, the peripheral image data converted by the deserializer 32 and the peripheral 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.

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

[0024] The vehicle electronic control unit 30 may also be configured to receive detection signals from sensors (not shown) for detecting the state of the vehicle. The sensors 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 humidity sensor for determining weather information. The vehicle electronic control unit 30 may also 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 unit 30 can 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 unit 30 can also obtain weather information from an external server.

[0025] The main SoC 36 of the vehicle electronic control device 30 executes a desired function in the host vehicle by, for example, executing main processing 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 moving object) ahead of the vehicle based on input data from at least one sensor, such as the camera 20 or the radar sensor 22, determines the likelihood of a collision with the detected target, and outputs control commands to various devices, equipment, and actuators according to the determined degree of the collision likelihood. In the collision prevention control function, the main SoC 36 calculates, for example, a predicted collision time until the host vehicle collides with the forward object. If the calculated predicted collision time falls below a first time threshold, the main SoC 36 determines that the likelihood of a collision 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 collision has further increased, and outputs a control command to the drive unit of the vehicle to reduce the drive force, to the brake unit of the vehicle to apply braking force, and / or to the steering unit of the vehicle to avoid the object ahead.

[0026] The sub-SoC 44 of the vehicle electronic control device 30 also utilizes the temporary storage function of the RAM 50 to perform sub-processing according to a sub-program stored in, for example, the ROM 48. The sub-program is capable of executing functions equivalent to those of the main program but differs in part or all of its configuration from the main program for improved performance. On the other hand, the sub-program is a program with improved performance compared to the main program, but performance verification has not yet been completed. Therefore, like the main SoC 36, the sub-SoC 44 can detect a target (a stationary or moving object) ahead of the vehicle based on input data from at least one sensor, such as the camera 20 or the radar sensor 22, and determine the possibility of a collision with the detected target by executing sub-processing according to the sub-program. However, because performance verification of the sub-program has not yet been completed, the sub-program is not configured to actually execute, for example, the collision prevention control function described above. Therefore, the sub-program is not configured to output control commands to various devices or the like upon execution.

[0027] In addition to executing the sub-programs, the sub-SoC 44 also performs a storage process to store data sets 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 part of the sub-programs.

[0028] 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. If both calculation results satisfy a predetermined deviation condition, a data set including at least the input data and both calculation results, indicating the situation when the calculation result in which the deviation occurred, is stored in the data storage memory 46. In this embodiment, the sub-process according to the sub-program performs calculation processing to determine 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 in which the deviation occurred is obtained in a storage medium is called a shadow mode.

[0029] The calculation results of the main processing and the sub-processing may use, for example, the same related index related to performance when executing a desired function. In the case of the above-mentioned collision prevention control function, for example, the number of targets, target positions, and predicted collision time to the targets calculated in the main processing and the sub-processing may be used as performance-related indexes. Then, when the number of targets, target positions, and predicted collision time to the targets are compared between the main processing and the sub-processing, it can be determined that the above-mentioned predetermined deviation condition is satisfied if a deviation exceeds a predetermined criterion for any of the items. For example, with regard to the predicted collision time, it can be determined that a deviation exceeds the predetermined criterion if the time difference between the two predicted collision times exceeds a predetermined third time threshold, or if, with regard to the target position, the difference between the two target positions exceeds a predetermined distance threshold. Furthermore, a deviation exceeding the predetermined criterion may also be determined if a difference in the number of detected targets exceeds a predetermined target number threshold.

[0030] The ROM 48 of the sub-SoC 44 also stores a backup program with functions equivalent to those of the main program executed by the main SoC 36. When the sub-SoC 44 determines that an abnormality may have occurred in the main process executed by the main SoC 36 by comparing the performance-related indices of the main process with those of the sub-process, the sub-SoC 44 switches the execution target program from the sub-program to the backup program and executes backup control. Like the main program of the main SoC 36, the backup program is a verified program. The backup program may be the same as or different from the main program. In this embodiment, a state in which an abnormality has occurred in the main SoC 36 and the backup program is executed by the sub-SoC 44 is called a backup mode.

[0031] In this backup control, the sub-SoC 44 first compares performance-related indicators resulting from processing according to the switched backup program with performance-related indicators resulting from processing according to the main program executed by the main SoC 36 to further confirm whether an abnormality has occurred in the main processing executed by the main SoC 36. If this confirmation process also confirms that an abnormality has occurred in the main processing executed by the main SoC 36, the sub-SoC 44 determines that an abnormality has occurred in the main SoC 36. In this case, the sub-SoC 44 continues executing processing according to the switched backup program, thereby outputting control commands to various devices, etc., in place of the main SoC 36. For example, while the sub-SoC 44 normally outputs control commands from the main SoC 36 as is, if control commands are output from both the main SoC 36 and the sub-SoC 44, a selection output circuit can be provided to select and output the control command from the sub-SoC 44, allowing the sub-SoC 44 to output the control command. Alternatively, when the sub-SoC 44 outputs a control command according to backup control, it may instruct the main SoC 36 to stop outputting control commands. As a result, during backup control, various devices can be driven by control commands output from the sub-SoC 44.

[0032] The data center 10 shown in FIG. 1 collects evaluation data (data sets) for subprograms stored in the vehicle electronic control units 30 of each vehicle. After the subprograms are thoroughly verified by engineers developing the system and program at the data center based on the collected evaluation data, the data center 10 distributes the verified subprograms to each vehicle as a new main program. In response to receiving the new main program, each vehicle rewrites the main program in the ROM 40 of the main SoC 36 with the new main program. Furthermore, when the data center 10 prepares a different version of the subprogram with improved performance based on the collected evaluation data, the data center distributes the subprogram to each vehicle. In response to receiving the different version of the subprogram, each vehicle rewrites the subprogram in the ROM 48 of the sub SoC 44 with the received different version of the subprogram.

[0033] 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. Therefore, 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. Furthermore, when the communication device 38 receives a different version of the subprogram with improved performance, the main SoC 36 passes 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 communicate directly with the data center 10.

[0034] 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 main processes according to a main program.

[0035] 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 and whether the clock frequency that serves as the basis for the operation of the main SoC 36 is oscillating stably. 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 results of the self-check and later provides them to the sub-SoC 44, which determines whether the main SoC 36 has an abnormality.

[0036] 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 on the received peripheral image to extract targets that may be obstacles to the vehicle's travel. At this time, 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.

[0037] 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 combined and extracted as a single target. In step S160, the main SoC 36 calculates the distance of the extracted target, for example, as the average distance or the minimum distance of the combined multiple reflecting objects.

[0038] In step S170, the main SoC 36 compares the targets extracted from the peripheral image from the camera 20 with the targets extracted from the peripheral information from the radar sensor 22 based on the positions, orientations, etc. of the targets, and associates the same targets with each other. Then, in step S180, the main SoC 36 calculates, for each associated target, a predicted collision time, which is the time until the host vehicle collides with the target, using the relative speed of the target calculated in step S130 and the distance to the target calculated in step S160.

[0039] In step S190, the main SoC 36 determines whether collision prevention control is necessary based on the calculated collision prediction time. For example, if 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 an audio or visual warning. Furthermore, if the calculated collision prediction time falls below a second time threshold that is shorter than the first time threshold, the main SoC 36 outputs, as collision prevention control, control commands to the vehicle drive system to reduce driving force, the vehicle brake system to apply braking force, and / or the vehicle steering system to avoid a forward object in step S200. Note that if multiple targets are detected, the main SoC 36 may determine whether collision prevention control is necessary for, for example, the target with the shortest collision prediction time.

[0040] In step S210, the main SoC 36 determines whether to terminate the desired function based on, for example, whether the main switch of the vehicle has been turned off and the vehicle has been parked. If it is determined that the function should be terminated, the main SoC 36 terminates the processing shown in the flowchart of Fig. 2. On the other hand, if it is determined that the function should not be terminated, the main SoC 36 repeats the processing from step S100.

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

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

[0043] As will be described later, 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. The 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, the main SoC 36 returns information corresponding to the query to the sub-SoC 44 in step S310.

[0044] 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 sub-processing according to a sub-program.

[0045] In the first step S400, the sub-SoC 44 executes a self-check. The content of the self-check is the same as that 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 where 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.

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

[0047] The processing in steps S440 to S460 involves the sub-SoC 44 extracting a target from the peripheral 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 involves the sub-SoC 44 extracting a target from peripheral 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 is capable of executing functions equivalent to those of the main program, and is a program whose configuration differs in part or entirely from the main program in order to improve performance, and does not necessarily perform all the same calculations as the main program.

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

[0049] In step S520, the sub-SoC 44 queries the main SoC 36 for the target matching result and the predicted collision time as the calculation results (performance-related indices) of the main SoC 36. The sub-SoC 44 then receives the matching result and the predicted collision time as replies to the query. The received matching result and predicted collision time are temporarily stored in the RAM 50. In step S530, the sub-SoC 44 compares the matching result and predicted collision time received from the main SoC 36 with the matching result and predicted collision time calculated by the sub-SoC 44, and determines whether or not there is a discrepancy between both matching results and the predicted collision time.

[0050] For example, if there is no difference in the number of targets between the two matching results, no difference in the target positions between the two matching results that exceeds a predetermined distance threshold, and no difference in the predicted collision time for the target closest to the vehicle that exceeds a predetermined third time threshold, the sub-SoC 44 can determine that there is no discrepancy between the two 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.

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

[0052] In step S550, since the calculation results (performance-related indicators) 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 that includes at least one of the input data and both calculation results and indicates the situation when the calculation result in which the deviation occurred. 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 understand the situation when the deviation occurred based on the stored data set. Therefore, the program evaluator (a data center engineer) can confirm whether the performance improvement of the sub-program is as expected, whether the performance of the sub-program is inferior to the performance of the main program, and if so, what circumstances caused this inferiority. The data set stored in the data storage memory 46 preferably includes the amount of deviation between the performance-related indicators of both the main SoC 36 and the sub-SoC 44. This makes it easier to understand the degree of deviation.

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

[0054] In addition to including at least one of the input data and both calculation results, the dataset preferably further includes at least one of the following: a version of the main program, a version of the subprogram, traffic environment data regarding the traffic environment around the vehicle (e.g., congested, clear, etc.), driving condition data regarding the driving condition of the vehicle (speed, whether turning or going straight, etc.), weather data regarding the weather (clear, rainy, snowy, foggy, etc.), and time data regarding the time. From these accompanying data, a program evaluator can more accurately determine the versions of the main program and subprogram used when a calculation result that caused a deviation was obtained, and the situation of the vehicle when the calculation result that caused the deviation was obtained. Furthermore, by including the aforementioned accompanying data in the dataset, for example, when evaluation data for a specific situation is needed, it is possible to easily distinguish between necessary and unnecessary data and collect the necessary data.

[0055] Furthermore, the sub-SoC 44 may limit the number of data sets it stores to a predetermined number, taking into account 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 between the calculation results, the greater the importance of the data set as evaluation data for the subprogram. Note that after the limit on the number of stored data sets is reached, if a calculation result that deviates more from the stored data set is obtained, the stored data set can be overwritten with the new data set.

[0056] Furthermore, when storing data sets in the data storage memory 46, the sub-SoC 44 may store data sets in which the results of calculations by the sub-processing according to the sub-program are superior in performance in executing the desired function to the results of calculations by the main processing according to the main program, and data sets in which the results of calculations by the sub-processing are inferior in performance in executing the desired function to the results of calculations by the main processing, separately. This makes it possible to evaluate the performance of the sub-program in terms of both performance improvement and performance degradation relative to the main program based on the stored data sets. In this case, as described above, when limiting the number of data sets to be stored to a predetermined number, separate limits may be set for data sets in which the results of calculations by the sub-processing are superior in performance in executing the desired function to the results of calculations by the main processing, and data sets in which the results of calculations by the sub-processing are inferior in performance in executing the desired function to the results of calculations by the main processing.

[0057] 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 determination result of the self-check of the main SoC 36 in step S430, the result of comparing the results of 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.

[0058] Furthermore, the sub-SoC 44 can determine that an abnormality may have occurred in the main processing of the main SoC 36 if, for example, the sub-SoC 44 detects a target object while the main SoC 36 does not detect a target object as a result of comparing the collation result between the main SoC 36 and the sub-SoC 44 with the collision prediction time. Furthermore, the sub-SoC 44 can determine that an abnormality may have occurred in the main processing of the main SoC 36 if, for example, the main SoC 36 does not detect a target object for which the collision prediction time is to be calculated when the collision prediction time calculated by the sub-SoC 44 reaches a fourth time threshold. Furthermore, the sub-SoC 44 can also determine that an abnormality may have occurred in the main processing of the main SoC 36 if, for example, the collision prediction time calculated by the main SoC 36 lags behind the collision prediction time calculated by the sub-SoC 44 by more than a third time threshold.

[0059] 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 marked 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 marked when a target is not extracted. For example, in Case 1, in the main processing and the sub-processing, targets are 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 predicted collision time of targets that is sufficient to determine an abnormality in the main SoC 36, the sub SoC 44 executes the shadow mode, and if there is a difference that is sufficient to determine an abnormality in the main SoC 36, the sub SoC 44 executes the backup mode.

[0060] In cases 2 to 4, 8, and 12, there is a defect in the detection of targets by the camera 20 and / or radar sensor 22 in the sub-processing, whereas in the main processing, targets are detected correctly by the camera 20 and / or radar sensor 22 compared to the sub-processing. In these cases, the main processing by the main SoC 36 can be considered to be executed normally, and therefore the sub SoC 44 executes the shadow mode.

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

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

[0063] In case 16, it is not possible to determine whether 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.

[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 should be terminated, the sub-SoC 44 terminates the processing shown in the flowchart of FIG. 4. On the other hand, if it is determined that the function should not 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 sub-processing according to the sub-program. In step S580, the 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 the storage processing of storing a data set for evaluating the performance of the sub-program. Furthermore, the processing of steps S560 to S570 corresponds to the 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, sub-SoC 44 calculates the predicted time until collision with the target using the backup program after switching. At this time, sub-SoC 44 executes the backup program after switching, and calculates the predicted time until collision with the target after undergoing at least the calculation processes 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 also inquire of the main SoC 36 about not only the predicted collision time but also 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, if the main SoC 36 has not detected a target object for which the collision prediction time is to be calculated when the collision prediction time calculated by the sub-SoC 44 reaches the fourth time threshold, or if the collision prediction time calculated by the main SoC 36 is delayed by more than the third time threshold relative 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 in the main SoC 36 has been confirmed, and the process 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, or if the result of the self-check of the main SoC 36 is OK, the process proceeds to step S650.

[0069] In step S630, the sub-SoC 44 continues execution of 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 should be terminated, the sub-SoC 44 terminates the processing shown in the flowcharts of FIGS. 4 and 5. On the other hand, if it is determined that the function should not be terminated, the sub-SoC 44 repeats the processing from step S590. In this case, 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 processing 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 processing of steps S600 to S620 may be skipped.

[0070] Meanwhile, 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 to terminate the desired function. If it is determined to terminate the function, the sub-SoC 44 terminates the processing shown in the flowcharts of FIGS. 4 and 5. On the other hand, if it is determined not to terminate the function, the sub-SoC 44 proceeds to step S660. In step S660, after switching to the backup program, the data and calculation results stored in 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. Thereafter, the sub-SoC 44 returns to step S400 of 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, the data center 10 prepares a different version of the subprogram with improved performance based on the collected evaluation data, etc., and distributes the prepared subprogram to a target vehicle. A 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 queries the target vehicles, each of which has the subprogram to be evaluated implemented in its sub-SoC 44, for evaluation data (data set) for the subprogram. In response to this query, each target vehicle replies with an overview of the stored evaluation data, i.e., the comparison results of performance-related indicators, the magnitude of deviation (i.e., the amount of deviation), the versions of the main program and the subprogram, and / or accompanying data indicating the situation when the deviation occurred, as described below. In this way, by each target vehicle transmitting an overview of the evaluation data rather than immediately transmitting input data such as camera images, an increase in communication load can be suppressed, and the data center 10 can perform screening of the collected data, as described below. Note that the overview of the evaluation data is also included in the evaluation data.

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

[0075] In step S730, the data center 10 instructs the 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 received evaluation data in a database. Meanwhile, in step S750, the data center 10 instructs the 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. If it is determined in this determination 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 processing 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] Once the performance of the subprogram has been 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 to a database, and update information is saved.

[0079] Next, a description will be given of the flowchart of Fig. 9. Fig. 9 is a flowchart showing the processing 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 subprograms.

[0080] In the first step S900, the vehicle electronic control unit 30 determines whether 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. The vehicle electronic control unit 30 then 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 way, 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 the data center 10 to that effect.

[0083] In step S960, the vehicle electronic control unit 30 determines whether it has received an instruction to send all of the evaluation data of the subprogram from the data center 10, or whether it has received an instruction to discard the evaluation data. If it has received a transmission instruction, the vehicle electronic control unit 30 transmits all of the stored evaluation data to the data center 10 in step S970. On the other hand, if it has received an 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 that has improved performance for a desired function, and the calculation results of a main program, which is the 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 input data or the calculation results of both programs. 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 a data set in a storage medium indicating the situation when the calculation result in which the deviation occurred was obtained, in the event that a deviation occurred 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, 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, the vehicle electronic control device 30 according to this embodiment does not simply store a data set indicating the situation when the calculation result in which the discrepancy occurred was obtained, but instead queries the data center 10 about whether or not the data set needs to be stored. If 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 the storage process executed by the vehicle electronic control device 30 (sub-SoC 44) according to this embodiment. The flowchart shown in Fig. 10 adds steps S542 and S544 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 a discrepancy has occurred between the two calculation results, the sub-SoC 44 proceeds to step S542. In step S542, the sub-SoC 44 transmits information about the dataset (for example, information corresponding to an overview of the evaluation data described above) to the data center 10 and inquires of the data center 10 about whether the dataset needs to be stored. In step S544, if the sub-SoC 44 determines, based on the reply from the data center 10, that the data set needs to be stored, it proceeds to step S550. In step S550, the sub-SoC 44 stores the dataset in a storage medium. On the other hand, if the data center 10 replies that storage of the dataset is not necessary, the sub-SoC 44 proceeds to step S565 without storing the dataset.

[0090] In the above example, the vehicle electronic control unit 30 inquires of the data center 10 about whether or not a data set needs to be stored. However, the vehicle electronic control unit 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. The selection information may be related to associated data.

[0091] Fig. 11 is a flowchart including a storage process for storing only data sets that match the selection information. The flowchart shown in Fig. 11 adds steps S544 and S546 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 a discrepancy exists between the two calculation results, 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 is "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 is "NO," and the sub-SoC 44 proceeds to step S565 without storing the data set.

[0093] The above describes preferred embodiments of the present disclosure, but the present disclosure is not limited to the above-described embodiments and can be implemented in various modified forms within the scope of the gist of the present disclosure.

[0094] For example, in each of the above-described embodiments, the vehicle electronic control unit 30 has been described as executing a collision prevention control function as a desired function. However, the function executed by the vehicle electronic control unit 30 is not limited to the collision prevention control function. For example, the vehicle electronic control unit 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 applies the brakes, an adaptive cruise control function that detects a vehicle ahead and follows it while maintaining a safe distance, 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 assists the vehicle in staying within its lane, a blind spot monitoring function that detects vehicles approaching from the side or rear and notifies the driver, etc.

[0095] For example, when detecting objects such as other vehicles using a rear cross traffic alert function, blind spot monitoring function, or adaptive cruise control function, the deviation of the calculation result may be determined based on the detectable distance. For a traffic sign recognition function, the deviation of the calculation result may be determined based on the recognizable distance and recognition rate of traffic signs. For a 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 is 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 herein may be implemented by a special-purpose computer having a processor programmed to perform one or more functions embodied in a computer program. Alternatively, the control device and the method executed by the control device described herein may be implemented 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 concepts and combinations thereof, which apply not only to the vehicle electronic control unit 30 but also to a method for storing a desired data set, which is executed by at least one processor in the vehicle electronic control unit 30.

[0099] (Technical thought 1) An electronic control device for a vehicle that is mounted on a vehicle and that executes a desired function in the vehicle, a main processing unit (36) that executes main processing 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; a storage unit (S530, S540, S550) that compares the calculation result of the main processing in the main processing unit with the calculation result of the sub-processing in the sub-processing unit, and, when both calculation results satisfy a predetermined deviation condition, stores in a storage medium (46) a data set that includes at least one of the input data and both calculation results and indicates the situation when the calculation result in which a deviation occurred was obtained; the desired function is executed by the main processing unit in accordance with the main program, The subprogram is a program that can execute functions equivalent to those of the main program, and has a configuration that differs in part or entirely from that of the main program in order to improve performance.

[0100] (Technical thought 2) The vehicle electronic control device according to Technical Idea 1, wherein 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 the performance when executing the desired function.

[0101] (Technical Thought 3) An electronic control device for a vehicle as described in Technical Idea 2, wherein when a performance-related index calculated by the main processing and a performance-related index calculated by the sub-processing deviate from each other by more than a predetermined judgment criterion, it is determined that the predetermined deviation condition is satisfied.

[0102] (Technical Thought 4) The vehicle electronic control device described in any one of Technical Ideas 1 to 3, wherein the dataset includes at least one of the input data and both of the calculation results over a predetermined period before and after the calculation result in which the deviation occurred is obtained.

[0103] (Technical Thought 5) The vehicle electronic control device according to any one of Technical Ideas 1 to 4, wherein the data set includes a magnitude of deviation between both of the calculation results.

[0104] (Technical Thought 6) 6. The electronic control device for a vehicle according to any one of Technical Ideas 1 to 5, wherein the data set includes a version of the main program and a version of the subprogram.

[0105] (Technical Thought 7) The electronic control device for a vehicle described in any one of Technical Ideas 1 to 6, wherein the data set further includes at least one of traffic environment data related to the traffic environment around the vehicle, driving condition data related to the driving condition of the vehicle, weather data related to the weather, and time data related to the time.

[0106] (Technical Thought 8) The vehicle electronic control device according to any one of Technical Ideas 1 to 7, wherein the storage unit inquires of an external data center (10) about whether or not the data set needs to be stored, and when receiving an instruction from the external data center that the data set needs to be stored, stores the data set in the storage medium.

[0107] (Technical Thought 9) The electronic control device for a vehicle described in any one of Technical Ideas 1 to 7, wherein the storage unit receives selection data for selecting the data sets to be stored from an external data center (10), and stores the data sets that match the selection data in the storage medium.

[0108] (Technical Thought 10) The vehicle electronic control device according to any one of Technical Ideas 1 to 9, wherein the storage unit stores a predetermined number of the data sets in the storage medium in descending order of the degree of deviation.

[0109] (Technical Thought 11) The electronic control device for a vehicle described in any one of Technical Ideas 1 to 10, wherein the storage unit stores in the storage medium the data set when the calculation result by the sub-processing is superior to the calculation result by the main processing in terms of performance when executing the desired function, and the data set when the calculation result by the sub-processing is inferior to the calculation result by the main processing in terms of performance when executing the desired function.

[0110] (Technical Thought 12) The vehicle electronic control device according to any one of technical ideas 1 to 11, wherein the data set stored in the storage medium by the storage unit is collected by an external data center (10) to verify the performance of the subprogram.

[0111] (Technical Thought 13) The vehicle electronic control device according to Technical Idea 12, wherein the data set collected by the external data center is selected based on the magnitude of deviation between the two calculation results.

[0112] (Technical Thought 14) The electronic control device for a vehicle according to any one of technical ideas 8, 9, 12, and 13, wherein the subprogram whose performance has been verified is distributed to the vehicle by the external data center as a new main program.

[0113] (Technical Thought 15) The electronic control device for a vehicle according to any one of technical ideas 8, 9, 12, 13, and 14, wherein the subprogram is updated by a subprogram of a different version from the subprogram distributed by the external data center.

[0114] (Technical Thought 16) The vehicle electronic control device according to any one of Technical Ideas 1 to 12, wherein the main processing unit and the sub-processing unit are mounted on the same chip.

[0115] (Technical Thought 17) the main processing unit and the sub-processing unit are implemented on different chips, The vehicle electronic control device according to any one of Technical Ideas 1 to 12, wherein the input data is transmitted from the main processing unit to the sub-processing unit via a communication interface. [Explanation of symbols]

[0116] 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; a storage unit (S530, S540, S550) which 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 when both calculation results satisfy a predetermined deviation condition, causes a data set including at least one of the input data and both calculation results to be stored in a storage medium (46) indicating a situation when the calculation result in which a deviation occurred was obtained, 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. 2. The electronic control device for a vehicle according to claim 1, wherein the calculation result from the main processing and the calculation result from the sub-processing are the same type of performance-related index related to performance when the desired function is executed.

3. 3. The electronic control device for a vehicle according to claim 2, wherein when a performance-related index calculated by the main processing and a performance-related index calculated by the sub-processing deviate from each other by more than a predetermined judgment criterion, it is determined that the predetermined deviation condition is satisfied.

4. 4. The electronic control device for a vehicle according to claim 1, wherein the data set includes at least one of the input data and both of the calculation results over a predetermined period before and after a calculation result in which a deviation occurs is obtained.

5. The electronic control device for a vehicle according to claim 1 , wherein the data set includes a magnitude of deviation between the two calculation results.

6. The electronic control device for a vehicle according to claim 1 , wherein the data set includes a version of the main program and a version of the sub-program.

7. 4. The electronic control device for a vehicle according to claim 1, wherein the data set further includes at least one of traffic environment data relating to a traffic environment around the vehicle, driving condition data relating to a driving condition of the vehicle, weather data relating to weather, and time data relating to time.

8. 4. The electronic control device for a vehicle according to claim 1, wherein the storage unit inquires of an external data center about whether or not the data set needs to be stored, and when an instruction that the data set needs to be stored is received from the external data center, the storage unit stores the data set in the storage medium.

9. 4. The electronic control device for a vehicle according to claim 1, wherein the storage unit receives, from an external data center, selection data for selecting the data sets to be stored, and stores the data sets that match the selection data in the storage medium.

10. The electronic control device for a vehicle according to claim 1 , wherein the storage unit stores a predetermined number of the data sets in the storage medium in order of decreasing degree of deviation.

11. 4. The electronic control device for a vehicle according to claim 1, wherein the storage unit stores in the storage medium the data set when the calculation result by the sub-processing is superior to the calculation result by the main processing in terms of performance when executing the desired function, and the data set when the calculation result by the sub-processing is inferior to the calculation result by the main processing in terms of performance when executing the desired function.

12. 4. The electronic control device for a vehicle according to claim 1, wherein the data set stored in the storage medium by the storage unit is collected by an external data center in order to verify the performance of the subprogram.

13. The vehicle electronic control device according to claim 12 , wherein the data set collected by the external data center is selected based on the magnitude of deviation between the two calculation results.

14. The electronic control device for a vehicle according to claim 12 , wherein the sub-program whose performance has been verified is distributed to the vehicle by the external data center as a new main program.

15. The electronic control device for a vehicle according to claim 12, wherein the subprogram is updated by a subprogram of a different version from the subprogram, the subprogram being distributed by the external data center.

16. The electronic control device for a vehicle according to claim 1 , wherein the main processing unit and the sub-processing unit are mounted on a same chip.

17. The main processing unit and the sub-processing unit are implemented on different chips, The electronic control device for a vehicle according to claim 1 , wherein the input data is transmitted from the main processing unit to the sub-processing unit via a communication interface.

18. 1. A method for storing a desired data set, executed by at least one processor in a vehicle electronic control unit for performing 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; Executing a sub-process according to a sub-program based on the same input data as the main process; and comparing the calculation result by the main processing with the calculation result by the sub-processing, and if both of the calculation results satisfy a predetermined deviation condition, storing in a storage medium a data set including at least one of the input data and both of the calculation results, which indicates a situation when both of the calculation results with a deviation were obtained; the desired function is executed by the main process in accordance with the main program, 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.

Images