On-vehicle electronic control device

Abstract

To provide an on-vehicle electronic control device enabling allocation of computing resources to execution of a black box application with unknown internal processing.SOLUTION: An on-vehicle electronic control device 1 comprises: a computing resource estimation part 12 that estimates a required computing resource amount for execution of each application; a computing resource allocation part 13 that allocates computing resources to each application by setting a quality parameter which is an indicator indicating data quality of sensor information; and a data quality adjustment part 14 that adjusts the data quality in the sensor information acquired from a sensor 102 according to the quality parameter to each application set by the computing resource allocation part 13 and inputs the sensor information in which the data quality is adjusted for execution of each application. The computing resource allocation part 13 determines the quality parameter to each application on the basis of the required computing resource amount estimated according to a temporary setting of the quality parameter to each application and a computing resource amount available across a plurality of applications.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] The present invention relates to an in-vehicle electronic control unit, and more particularly to an in-vehicle electronic control unit that executes an application that uses information detected by a sensor. [Background technology]

[0002] To ensure safety and improve comfort, some automobiles and other vehicles are equipped with driving assistance and autonomous driving functions, in which the vehicle itself performs some of the surrounding monitoring and driving behaviors that are currently performed by the driver. To achieve these driving assistance and autonomous driving functions, there are multiple in-vehicle applications that provide emergency steering assistance, lane keeping assistance, falling object detection, and other functions. These types of applications (hereafter referred to as apps) use a large amount of data (sensor information) detected by sensors mounted on the vehicle. The number of in-vehicle apps is increasing year by year in order to respond to more complex vehicle situations, which has resulted in a strain on the computing resources of in-vehicle computers.

[0003] For example, a technique described in Patent Document 1 has been proposed to address the strain on computational resources of an in-vehicle computer due to the execution of applications. The in-vehicle environment recognition device described in Patent Document 1 includes two applications (a lane recognition unit and a side vehicle detection unit) that perform lane recognition to recognize the lane in which the vehicle is traveling and side vehicle detection to detect the presence of a vehicle on the side of the vehicle. Both applications detect preset detection elements using images from an imaging unit (camera). The detection elements for lane recognition are, for example, the lateral position between the white line that divides the lane and the vehicle, and the curvature that indicates the degree of curvature of a curve. The detection elements for side vehicle detection are, for example, vehicles that exist on the left or right side of the vehicle. The in-vehicle environment recognition device includes an application control unit that issues an application implementation request to each application to perform processing according to the detection accuracy (calculation accuracy) of the detection element of each application adjusted according to the situation of the vehicle and the processing load of each application. Each application (the lane recognition unit and the side vehicle detection unit) performs processing at the detection accuracy (for example, relatively high resolution or low resolution) of the detection element according to the application implementation request (instruction) from the application control unit. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2013-105385 A Summary of the Invention [Problem to be solved by the invention]

[0005] The technology described in Patent Document 1 is premised on the ability to change (adjust) the calculation accuracy (detection accuracy of detection elements) in the internal processing of each app. For this reason, it is difficult to apply the technology described in Patent Document 1 to apps whose internal processing is unknown and cannot be changed by external instructions (hereinafter referred to as black box apps).

[0006] The present invention has been made to solve the above-mentioned problems, and its purpose is to provide an in-vehicle electronic control device that enables the allocation of computational resources to the execution of a black box app whose internal processing is unknown. [Means for solving the problem]

[0007] The present application includes a plurality of means for solving the above-mentioned problems. An example of an on-vehicle electronic control device of the present application is an on-vehicle electronic control device that executes a plurality of applications using sensor information detected by a sensor, and includes a computational resource estimation unit that estimates a required computational resource amount, which is a computational resource amount required for executing each of the plurality of applications, a computational resource allocation unit that allocates computational resources to each of the plurality of applications by setting a quality parameter as an index indicating a data quality of the sensor information, and a data quality adjustment unit that adjusts the data quality of the sensor information acquired from the sensor according to the quality parameter for each of the plurality of applications set by the computational resource allocation unit, and inputs the sensor information with the adjusted data quality for execution of each of the plurality of applications, and the computational resource allocation unit determines the quality parameter for each of the plurality of applications based on the required computational resource amount estimated according to the provisional setting of the quality parameter for each of the plurality of applications and the available computational resource amount, which is a computational resource amount that can be used by the entirety of the plurality of applications. Effect of the Invention

[0008] According to one example of the present application, sensor information whose data quality has been adjusted according to the quality parameters set for each application is input to the execution of each application, so that even for the execution of a black box application whose internal processing is unknown, it is possible to allocate computational resources according to the quality parameters set for the application. Problems, configurations and effects other than those described above will become apparent from the following description of the embodiments. [Brief description of the drawings]

[0009] [Figure 1] 1 is a schematic configuration diagram showing an on-vehicle electronic control device and its associated hardware configuration according to a first embodiment of the present invention. [Diagram 2] 1 is a block diagram showing a hardware configuration and a processing function configuration of an on-vehicle electronic control device according to a first embodiment. [Diagram 3] 3 is a flowchart showing an example of processing executed by a computational resource amount estimation unit of the on-board electronic control device according to the first embodiment shown in FIG. 2. [Figure 4] 3 is a calculation formula table for the calculation resource amount estimation unit of the in-vehicle electronic control device according to the first embodiment shown in FIG. 2 to estimate the amount of required calculation resources for each application. [Diagram 5] 3 is a flowchart showing an example of processing executed by a computational resource allocation unit of the on-vehicle electronic control device according to the first embodiment shown in FIG. 2. [Figure 6] 3 is a table showing the execution priority of each application used by a computational resource allocation unit of the in-vehicle electronic control device according to the first embodiment shown in FIG. 2. [Figure 7] 3 is a flowchart showing an example of processing executed by a data quality adjustment unit of the on-vehicle electronic control device according to the first embodiment shown in FIG. 2. [Figure 8] FIG. 4 is a block diagram showing a hardware configuration and a processing function configuration of an on-vehicle electronic control device according to a modified example of the first embodiment. [Figure 9] 9 is a flowchart showing an example of processing executed by a sensor data calculation unit and a computational resource amount estimation unit of an on-vehicle electronic control device according to a modified example of the first embodiment shown in FIG. 8. [Figure 10] FIG. 11 is a block diagram showing the hardware configuration and the processing function configuration of an on-vehicle electronic control device according to a second embodiment of the present invention. [Figure 11] 11 is a flowchart showing an example of processing executed by a computational resource amount estimation unit of the on-vehicle electronic control device according to the second embodiment shown in FIG. [Figure 12]11 is a formula table for the computational resource amount estimating unit of the in-vehicle electronic control device according to the second embodiment shown in FIG. 10 to estimate the amount of computational resources required for each application. [Figure 13] 11 is a flowchart showing an example of processing executed by a computational resource allocation unit of the on-vehicle electronic control device according to the second embodiment shown in FIG. [Figure 14] 11 is a flowchart showing an example of processing executed by a change priority calculation unit of the on-vehicle electronic control device according to the second embodiment shown in FIG. [Figure 15] 11 is a calculation formula table for the change priority calculation unit of the in-vehicle electronic control device according to the second embodiment shown in FIG. 10 to calculate the driving safety level of each application. [Figure 16] 11 is a flowchart showing an example of processing executed by a quality parameter change unit of the on-vehicle electronic control device according to the second embodiment shown in FIG. [Figure 17] 13 is a table showing an example of a transition of changes in quality parameters of each application during operation of an in-vehicle electronic control device according to a second embodiment. [Figure 18] FIG. 13 is a block diagram showing a hardware configuration and a processing function configuration of an on-vehicle electronic control device according to a modified example of the second embodiment. [Figure 19] 19 is a flowchart showing an example of processing executed by a sensor data calculation unit and a computational resource amount estimation unit of an on-vehicle electronic control unit according to a modified example of the second embodiment shown in FIG. 18. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, an embodiment of an on-vehicle electronic control device of the present invention will be described with reference to the drawings. [First embodiment] First, a vehicle equipped with an on-vehicle electronic control device according to a first embodiment of the present invention will be described with reference to Fig. 1. Fig. 1 is a schematic diagram showing the on-vehicle electronic control device according to the first embodiment and the hardware configuration related thereto.

[0011] 1, a vehicle 100 includes an on-board electronic control device 1 that controls various operations including driving of the vehicle 100, a group of sensors 102 that are mounted on the vehicle 100 and detect information necessary for driving the vehicle 100, a driving behavior planning device 103 that plans driving behavior of the vehicle 100 according to the operating conditions of the vehicle 100, and a common bus 104 that connects these devices 1, 102, and 103 to one another. The on-board electronic control device 1, the group of sensors 102, and the driving behavior planning device 103 can transmit information to one another via the common bus 104.

[0012] The in-vehicle electronic control device 1 executes a plurality of applications (hereinafter referred to as apps) that use sensor information, which is a large amount of data detected by a sensor group 102, and is configured to output processing results of the plurality of apps to a driving action planning device 103. The hardware configuration and processing functions of the in-vehicle electronic control device 1 will be described in detail later.

[0013] The sensor group 102 is composed of sensors that detect the traveling state of the vehicle 100 and sensors that detect the surrounding environment of the vehicle 100. Examples of sensors that compose the sensor group 102 include a speed sensor that detects the traveling speed of the vehicle 100, a single or multiple cameras that capture images of the front, rear, left, right, and right sides of the vehicle 100, a radar that emits radio waves to measure the distance and direction to an object, and a LIDAR (Light Detection and Ranging) that emits laser light to measure the distance and shape of an object. Of the sensor information detected by the multiple sensors that compose the sensor group 102, a configuration in which sensor information detected by one sensor is used for an app or a configuration in which sensor information detected by multiple sensors is used for an app is possible. The sensor group 102 may also be composed of only one sensor.

[0014] The driving behavior planning device 103 can be configured to plan (generate) driving behavior of the vehicle 100 based on a processing result obtained by executing an app implemented in the in-vehicle electronic control device 1, for example. In addition, the driving behavior planning device 103 grasps driving conditions such as lane changes and right turns during driving assistance.

[0015] Next, the hardware configuration and the configuration of the processing function of the on-vehicle electronic control device according to the first embodiment will be described with reference to Fig. 2. Fig. 2 is a block diagram showing the hardware configuration and the configuration of the processing function of the on-vehicle electronic control device according to the first embodiment.

[0016] In FIG. 2, the in-vehicle electronic control device 1 includes, as a hardware configuration, a storage device 10a including a RAM, a ROM, and the like, and a processing device 10b including a CPU, an MPU, and the like. The storage device 10a stores a plurality of applications in advance, and also stores a program and various information required for allocating the computational resources of the in-vehicle electronic control device 1 when the plurality of applications are executed. The processing device 10b appropriately reads the plurality of applications, a predetermined program, and various information from the storage device 10a, appropriately acquires sensor information from a sensor group 102, and executes processing according to the plurality of applications and the predetermined program, thereby realizing various processing functions for allocating the computational resources of the in-vehicle electronic control device 1 for the execution of the plurality of applications. The in-vehicle electronic control device 1 is configured to be able to execute, for example, three applications, a first application, a second application, and a third application, and includes a sensor information acquisition unit 11, a computational resource amount estimation unit 12, a computational resource allocation unit 13, a data quality adjustment unit 14, a first application execution unit 21, a second application execution unit 22, and a third application execution unit 23 as processing functions by software operating on the in-vehicle electronic control device 1. Each of the functional units 11, 12, 13, 14, 21, 22, and 23 of the on-vehicle electronic control device 1 executes processing within a predetermined period, for example.

[0017] The sensor information acquisition unit 11 performs a process of importing sensor information detected by the sensor group 102 into the in-vehicle electronic control unit 1 via the common bus 104. The sensor information acquisition unit 11 passes (outputs) the sensor information imported from the sensor group 102 to the computational resource estimation unit 12 and the data quality adjustment unit 14.

[0018] The computational resource amount estimation unit 12 performs a process of estimating the amount of computational resources required for each application, which is the amount of computational resources required to execute the first application, the amount of computational resources required to execute the second application, and the amount of computational resources required to execute the third application, using the sensor information received from the sensor information acquisition unit 11. A specific estimation method and a process flow of the computational resource amount estimation unit 12 will be described later in detail. The computational resource amount estimation unit 12 delivers (outputs) the amount of computational resources required for each application, which is the estimation result (processing result), to the computational resource allocation unit 13.

[0019] The computational resource allocation unit 13 performs a process of allocating computational resources of the in-vehicle electronic control device 1 to each of the first, second, and third applications by setting a quality parameter that is an index indicating the data quality of the sensor information. The computational resource allocation unit 13 is configured to set a quality parameter for each application using the amount of computational resources required for each application as an estimation result received from the computational resource amount estimation unit 12. The quality parameter in this embodiment is a processing frequency of sensor information for each application, and corresponds to the presence or absence of execution of each application. Specifically, the quality parameter represents a processing frequency of "1" when the sensor information acquired by the sensor information acquisition unit 11 is input to the execution of the application, and a processing frequency of "0" when the sensor information is not input to the execution of each application. That is, when the quality parameter is "1", it means that the application is executed using the sensor information acquired by the sensor information acquisition unit 11 as input information, and computational resources for the execution of the application are allocated. On the other hand, when the quality parameter is "0", it means that the sensor information acquired by the sensor information acquisition unit 11 is not input, so the application is not executed, and no computational resources are allocated to the application. The specific computational resource allocation method and processing flow of the computational resource allocation unit 13 will be described later in detail. The computational resource allocation unit 13 delivers (outputs) the quality parameters for each application, which are the setting results (processing results), to the data quality adjustment unit .

[0020] The data quality adjustment unit 14 adjusts the data quality of the sensor information output from the sensor information acquisition unit 11 according to the quality parameters of each application of the setting result output from the computational resource allocation unit 13, and performs processing to deliver (output) the sensor information with the adjusted data quality to the first application execution unit 21, the second application execution unit 22, and the third application execution unit 23. The quality parameters in this embodiment are expressed as a processing frequency of "1" when the sensor information acquired by the sensor information acquisition unit 11 is input to the execution of the application, and as a processing frequency of "0" when the sensor information is not input to the execution of each application. Therefore, in the case where the quality parameter for each application is the processing frequency of "1", the data quality adjustment unit 14 in this embodiment inputs the sensor information acquired by the sensor information acquisition unit 11 to each application execution unit 21, 22, and 23 as it is. On the other hand, in the case where the quality parameter for each application is the processing frequency of "0", the data quality adjustment unit 14 stops inputting the sensor information acquired by the sensor information acquisition unit 11 to each application execution unit 21, 22, and 23. Details of the processing flow of the data quality adjustment unit 14 will be described later.

[0021] The first application execution unit 21, the second application execution unit 22, and the third application execution unit 23 each perform an execution process of an application using, as input information, the sensor information whose data quality has been adjusted and which is output from the data quality adjustment unit 14. The first application execution unit 21, the second application execution unit 22, and the third application execution unit 23 each perform an execution process of an application such as a collision damage mitigation brake, a falling object detection, and a target tracking.

[0022] The collision damage mitigation brake application, for example, monitors the surrounding driving environment detected by the sensor group 102, and when there is an increased risk of collision with a vehicle or pedestrian in front or to the side detected by the sensor group 102, warns the driver with a warning sound, warning light, etc., to urge the driver to apply the brakes. Furthermore, when the driver does not apply the brakes in response to the urge to apply the brakes and it is determined that there is a high possibility of a collision, the application activates the brakes.

[0023] The falling object detection application, for example, detects the presence or absence of a fallen object in front of the vehicle by monitoring the surrounding driving environment detected by the sensor group 102. Furthermore, when a fallen object is detected, the application prompts the driver to take driving action to avoid the fallen object or executes the driving action.

[0024] The target tracking application detects a target by monitoring the surrounding driving environment detected by the sensor group 102, for example.

[0025] Next, a calculation method and a processing flow of the computation resource amount estimation unit in the on-board electronic control device according to the first embodiment will be described with reference to Fig. 3 and Fig. 4. Fig. 3 is a flowchart showing an example of processing executed by the computation resource amount estimation unit of the on-board electronic control device according to the first embodiment shown in Fig. 2. Fig. 4 is a calculation formula table for the computation resource amount estimation unit of the on-board electronic control device according to the first embodiment shown in Fig. 2 to estimate the amount of computation resources required for each app.

[0026] As described above, the computational resource amount estimation unit 12 (see FIG. 2) of the in-vehicle electronic control device 1 estimates the amount of computational resources required for each of the first application, the second application, and the third application. For example, as shown in FIG. 3, the computational resource amount required for each application is estimated by executing the following steps S10 to S50 at each predetermined control period.

[0027] First, the computational resource amount estimation unit 12 receives sensor information from the sensor information acquisition unit 11 (step S10). Next, the number of sensor data that enables estimation of the computational resource amount required for each application is extracted from the sensor information received from the sensor information acquisition unit 11 (step S20). The number of sensor data differs depending on the nature of each application. Examples of the number of sensor data include the number of sensor detection points, which is the number of detection targets detected by the sensor group 102, the data amount of sensor information detected by the sensor group 102, the number of targets detected by the sensor group 102, etc.

[0028] Next, the computational resource amount estimation unit 12 refers to a computation formula table having an estimation formula for the amount of computational resources required for each application (step S30), and estimates the amount of computational resources required for each application using the estimation formula in the computation formula table (step S40). The computation formula table is stored in advance in, for example, the storage device 10a (see FIG. 2). As shown in, for example, FIG. 4, the computation formula table is composed of a first column 121 indicating application type information and a second column 122 indicating an estimation formula for the amount of computational resources required for each application.

[0029] Estimation formula f in the second column 122 is, for example, an estimation formula for a collision damage mitigation brake application that inputs the number of sensor detection points as the number of sensor data items that enables estimation of the amount of computational resources required by each application. Estimation formula g in the second column 122 is, for example, an estimation formula for a falling object detection application that inputs the number of sensor detection points as the number of sensor data items. Estimation formula h in the second column 122 is, for example, an estimation formula for a target tracking application that inputs the number of targets detected by a sensor as the number of sensor data items.

[0030] 3, the computational resource amount estimation unit 12 outputs the amount of computational resources required for each application as an estimation result (step S50). After executing step S50, the computational resource amount estimation unit 12 ends the process of this flow.

[0031] Next, a processing flow of the computational resource allocation unit in the on-board electronic control device according to the first embodiment will be described with reference to Fig. 5 and Fig. 6. Fig. 5 is a flowchart showing an example of processing executed by the computational resource allocation unit of the on-board electronic control device according to the first embodiment shown in Fig. 2. Fig. 6 is a table showing the execution priority of each application used by the computational resource allocation unit of the on-board electronic control device according to the first embodiment shown in Fig. 2.

[0032] As described above, the computational resource allocation unit 13 (see FIG. 2) of the in-vehicle electronic control unit 1 sets quality parameters for each application, thereby allocating (distributing) the computational resources of the in-vehicle electronic control unit 1. For example, as shown in FIG. 5, the quality parameters for each application are set by executing the following steps S110 to S170 for each predetermined control period.

[0033] The computational resource allocation unit 13 first receives the amount of required computational resources for each application as an estimated result from the computational resource amount estimation unit 12 (step S110). Next, the computational resource allocation unit 13 acquires the amount of available computational resources, which is the amount of computational resources available for execution of all applications of the first application executor 21, the second application executor 22, and the third application executor 23 (step S120). The in-vehicle electronic control unit 1 can be configured to calculate the amount of available computational resources according to the operating state of the in-vehicle electronic control unit 1, or to set the amount of available computational resources in advance.

[0034] Next, the computational resource allocation unit 13 initializes and provisionally sets quality parameters for each application (step S130). In this embodiment, the initialization of the quality parameters means provisionally setting the quality parameters to maximum quality. The maximum quality of the quality parameters is the same data quality as the sensor information of the sensor group 102 acquired by the sensor information acquisition unit 11. In this embodiment, as described above, the processing frequency of the sensor information for each application corresponding to the presence or absence of execution of each application is used as the quality parameter. Specifically, the quality parameter is expressed as a processing frequency of "1" when the sensor information acquired by the sensor information acquisition unit 11 is input to the execution of the application, and as a processing frequency of "0" when the sensor information is not input to the execution of each application. Therefore, the maximum quality of the quality parameters in this embodiment corresponds to a processing frequency of "1", while the minimum quality of the quality parameters corresponds to a processing frequency of "0".

[0035] Next, the computational resource allocation unit 13 sums up the required computational resource amounts of each app according to the provisional quality parameters of each app with respect to the required computational resource amounts estimated by the computational resource amount estimation unit 12 (step S140), and determines whether or not the total sum of the required computational resource amounts of each app is within the range of the available computational resource amount acquired in step S120 (step S150). When the total value of the required computational resource amounts of each app according to the provisional quality parameters is within the range of the available computational resource amount, it is predicted that the computational resources used by the app executed using the sensor information of the data quality of the provisional quality parameters as input will be within the range of the computational resources provided by the in-vehicle electronic control unit 1.

[0036] If the total amount of required computational resources of each application exceeds the amount of available computational resources in step S150 (if NO), computational resource allocation unit 13 reduces the provisional quality parameters of the applications in the order of application execution priority indicating the order of priority of execution among the applications (step S160), and repeats steps S140 to S160 (performs loop processing) until the total amount of required computational resources of each application falls within the range of the amount of available computational resources. If the total amount of required computational resources of each application falls within the range of the amount of available computational resources in step S150 (if YES), computational resource allocation unit 13 outputs the provisional quality parameters for each application as the final quality parameters (step S170).

[0037] The sum of the required computational resources of each application in step S140 is a calculation of the amount of computational resources required for simultaneous execution of each application. In the quality parameters of this embodiment, the maximum quality is the processing frequency "1", and the quality when the maximum quality is lowered becomes the minimum quality processing frequency "0". At the first processing of step S140, the quality parameter of each application is initialized to the highest quality 1 processing frequency "1". Therefore, the total value of the required computational resources of each application at the first processing of step S140 is the total value obtained by adding up the required computational resources of each application as a result of estimation by computational resource amount estimation unit 12.

[0038] If the total amount of required computational resources for each application exceeds the amount of available computational resources in step S150 (if NO), it is predicted that the computational resources of the in-vehicle electronic control device 1 will be insufficient if each application is executed simultaneously. Therefore, the computational resource allocation unit 13 reduces the provisionally set quality parameters of the application, starting with the application with the lowest execution priority (step S160). Specifically, the priority table for application execution is referenced, and the provisionally set quality parameter for the application with the lowest execution priority is reduced.

[0039] The application execution priority table, as shown in Fig. 6 for example, is composed of a first column 131 indicating application type information and a second column 132 indicating execution priority information of each application. In the application execution priority table shown in Fig. 6, the application for collision damage mitigation braking is set to "1", which is the highest execution priority among the three applications, from the viewpoint of improving safe driving. The application for falling object detection is set to "3", which is the lowest execution priority among the three applications. The application for target tracking is set to "2", which is the middle execution priority among the three applications.

[0040] 5, the computational resource allocation unit 13 first lowers the quality parameter of the falling object detection application, which has the lowest execution priority among the three applications. That is, the computational resource allocation unit 13 changes the quality parameter for the falling object detection application from the maximum quality processing frequency "1" to the lowest quality processing frequency "0."

[0041] The computational resource allocation unit 13 recalculates the amount of computational resources required by the falling object detection app with the lowest execution priority, whose quality parameter has been lowered, according to the lowered quality parameter, and again sums up the amount of computational resources required by each app (step S140 in the first loop process). The result of the recalculation of the amount of computational resources required by the falling object detection app becomes "0" according to the change in the processing frequency of the lowest quality of the quality parameter of the app to "0". Therefore, the total amount of computational resources required by each app according to the provisionally set quality parameter is reduced by the amount of computational resources required by the falling object detection app as estimated by the computational resource amount estimation unit 12.

[0042] In step S150, if the total amount of required computational resources as a result of recalculation according to the reduced quality parameters is still within the range of the amount of available computational resources (Yes), the quality parameters for the falling object detection app are set as the minimum quality "0", and the quality parameters for the other apps are set as the initialized maximum quality "1" as the final quality parameters. This means that the computational resources of the in-vehicle electronic control device 1 have been allocated to apps other than the falling object detection app (the collision damage mitigation braking and target tracking apps).

[0043] On the other hand, in step S150, if the total amount of required computational resources as a result of recalculation according to the reduced quality parameter exceeds the available computational resource amount (No), the quality parameter of the target tracking app with the next lowest execution priority is reduced, and the amount of required computational resources of the target tracking app with the reduced quality parameter is recalculated according to the reduced quality parameter, and the amount of required computational resources of each app is added up again (step S140 by the second loop process). Since the quality parameter of the target tracking app is also changed to the lowest quality processing frequency "0", the recalculation result of the amount of required computational resources of the target tracking app becomes "0" according to the change of the quality parameter of the app to the lowest quality "0". Therefore, the total amount of required computational resources of each app according to the provisional quality parameter is further reduced by the amount of required computational resources of the target tracking app estimated by the computational resource amount estimation unit 12. In other words, the total amount of required computational resources of each app according to the provisional quality parameter is only the amount of required computational resources of the collision damage mitigation brake app with the highest execution priority. This means that the computational resources of the in-vehicle electronic control unit 1 are allocated only to the collision mitigation brake application.

[0044] Through these processes, the computational resource allocation unit 13 sets the quality parameters for each application by changing the provisional settings to the final settings. The computational resource allocation unit 13 delivers (outputs) the set quality parameters for each application to the data quality adjustment unit 14. After executing step S170, the computational resource allocation unit 13 ends the processing of this flow.

[0045] Next, a processing flow of the data quality adjustment unit in the on-vehicle electronic control device according to the first embodiment will be described with reference to Fig. 7. Fig. 7 is a flowchart showing an example of processing executed by the data quality adjustment unit of the on-vehicle electronic control device according to the first embodiment shown in Fig. 2.

[0046] As described above, the data quality adjustment unit 14 (see FIG. 2) of the in-vehicle electronic control unit 1 adjusts the data quality of the sensor information from the sensor information acquisition unit 11 according to the quality parameters of each application, which are the setting results of the computational resource allocation unit 13. For example, as shown in FIG. 7, the following steps S210 to S240 are executed at every predetermined control period, thereby inputting the sensor information, the data quality of which has been adjusted according to the quality parameters set for each application, to each of the application execution units 21, 22, and 23.

[0047] The data quality adjuster 14 first receives sensor information from the sensor information acquirer 11 (step S210), and receives quality parameters of each application from the computational resource allocation unit 13 (step S220). The order of the processes of steps S210 and S220 does not matter.

[0048] Next, the data quality adjustment unit 14 adjusts the data quality of the sensor information to be input to each application execution unit 21, 22, 23 in accordance with the quality parameters set for each application (step S230). In this embodiment, the quality parameters are expressed as a processing frequency of "1" when the sensor information acquired by the sensor information acquisition unit 11 is input to the execution of an application, and as a processing frequency of "0" when the sensor information is not input to the execution of each application. Therefore, the data quality is adjusted for the sensor information to be input to each application according to the maximum quality of "1" or the minimum quality of "0" set for each application.

[0049] Next, the data quality adjustment unit 14 outputs the sensor information, the data quality of which has been adjusted according to the quality parameter of each application, to each application (the first application execution unit 21, the second application execution unit 22, and the third application execution unit 23) (step S240). Specifically, when the quality parameter is the highest quality "1", the sensor information acquired by the sensor information acquisition unit 11 is input directly to the execution of the application. On the other hand, when the quality parameter is the lowest quality "0", the input of the sensor information acquired by the sensor information acquisition unit 11 to the application is stopped. After executing step S240, the computational resource allocation unit 13 ends the processing of this flow.

[0050] In this embodiment, the first application executing unit 21, the second application executing unit 22, and the third application executing unit 23 receive sensor information whose data quality has been adjusted according to a quality parameter set for each application. That is, each of the application executing units 21, 22, and 23 performs processing using the sensor information whose data quality has been adjusted by the data quality adjusting unit 14 as input information. In this case, even if each of the application executing units 21, 22, and 23 executes a black box application whose internal processing cannot be changed by an external instruction, it is possible to increase or decrease the computational resources used by each of the application executing units 21, 22, and 23 by adjusting the data quality of the sensor information input to each of the application executing units 21, 22, and 23 without changing the internal processing of each of the application executing units 21, 22, and 23. For example, by lowering the data quality of the sensor information input to each of the application executing units 21, 22, and 23, it is possible to reduce the computational resources used by each of the application executing units 21, 22, and 23.

[0051] The quality parameter in this embodiment is the frequency of processing sensor information for each application, which corresponds to whether or not each application is being executed. Specifically, the quality parameter is expressed as a processing frequency of "1" when the sensor information acquired by the sensor information acquisition unit 11 is input to the execution of the application, and as a processing frequency of "0" when the sensor information is not input to the execution of the application. In this case, by setting the quality parameter for an application to a processing frequency of "0", the computational resources used by the application can be allocated to "0".

[0052] As described above, the in-vehicle electronic control device 1 according to the first embodiment is an in-vehicle electronic control device that executes multiple applications that use sensor information detected by sensors constituting a sensor group 102, and includes a computational resource estimation unit 12 that estimates a required amount of computational resources, which is the amount of computational resources required to execute each of a first application, a second application, and a third application (multiple applications), a computational resource allocation unit 13 that allocates computational resources to each of the three applications (multiple applications), i.e., the first application, the second application, and the third application, by setting a quality parameter as an index indicating the data quality of the sensor information, and a data quality adjustment unit 14 that adjusts the data quality of the sensor information acquired from the sensors of the sensor group 102 in accordance with the quality parameters for each of the three applications (multiple applications) set by the computational resource allocation unit 13, and inputs the sensor information with the adjusted data quality for the execution of each of the three applications (multiple applications). The computational resource allocation unit 13 determines quality parameters for each of the three apps (multiple applications) based on the amount of required computational resources estimated in accordance with the provisional settings of quality parameters for each of the three apps (multiple applications) and the amount of available computational resources, which is the amount of computational resources that can be used by the three apps (multiple applications) as a whole.

[0053] According to this configuration, sensor information whose data quality has been adjusted according to the quality parameters set for each application is input for the execution of each application, so that even for the execution of a black box application whose internal processing is unknown, computational resources can be allocated according to the quality parameters set for that application.

[0054] In addition, the computational resource allocation unit 13 of the in-vehicle electronic control device 1 in this embodiment determines quality parameters for each of the three apps (multiple applications) so that the total amount of required computational resources obtained by adding up the amount of required computational resources estimated according to the provisionally set quality parameters for each of the three apps (multiple applications) falls within the range of the amount of available computational resources.

[0055] According to this configuration, the quality parameters for each app are set so that the total amount of required computational resources estimated based on the quality parameters falls within the range of the amount of available computational resources, thereby avoiding a shortage of computational resources in the in-vehicle electronic control device 1 when executing three apps (multiple applications).

[0056] In addition, when the total amount of required computational resources exceeds the amount of available computational resources, the computational resource allocation unit 13 of the in-vehicle electronic control device 1 in this embodiment repeatedly lowers one of the quality parameters tentatively set for each of the three apps (multiple applications), and determines the provisional quality parameter when the total amount of required computational resources falls within the range of the amount of available computational resources as the quality parameter for each of the three apps (multiple applications).

[0057] According to this configuration, the quality parameters of each app are set so that the total amount of required computational resources falls within the range of the amount of available computational resources by lowering one of the provisionally set quality parameters of each app, thereby making it possible to appropriately allocate (distribute) the computational resources of the in-vehicle electronic control unit 1 to each app by the quality parameter set for each app.

[0058] In addition, in the in-vehicle electronic control device 1 according to the present embodiment, an execution priority indicating an order of priority for execution among the three apps (multiple applications) is set in advance. When the total amount of required computational resources exceeds the amount of available computational resources, the computational resource allocation unit 13 of the in-vehicle electronic control device 1 reduces the provisionally set quality parameters in order from the application with the lowest execution priority until the total amount of required computational resources falls within the range of the amount of available computational resources.

[0059] According to this configuration, the quality parameters of each app are set by lowering the quality parameters starting from the app with the lowest execution priority, thereby making it possible to avoid a shortage of computational resources in the in-vehicle electronic control device 1 for the execution of three apps (multiple applications) while minimizing the adverse effects on the execution of each app caused by lowering the quality parameters.

[0060] Furthermore, in the in-vehicle electronic control device 1 according to this embodiment, the quality parameter is set to the highest quality as the data quality in the sensor information obtained from the sensors of the sensor group 102, and the computational resource allocation unit is configured to decrease the provisionally set quality parameter from the highest quality when the total amount of required computational resources exceeds the amount of available computational resources.

[0061] According to this configuration, it becomes possible to set the quality parameters of each app to the higher quality side, thereby allowing the allocation (distribution) of computational resources for the execution of each app to be increased, so that the available computational resources of the in-vehicle electronic control unit 1 can be utilized as much as possible for the execution of the three apps (multiple applications).

[0062] [Modification of the first embodiment] Next, an on-vehicle electronic control device according to a modified example of the first embodiment will be described with reference to Figs. 8 and 9. Fig. 8 is a block diagram showing the hardware configuration and processing function configuration of an on-vehicle electronic control device according to a modified example of the first embodiment. Fig. 9 is a flowchart showing an example of processing executed by a sensor data calculation unit and a computational resource amount estimation unit of the on-vehicle electronic control device according to the modified example of the first embodiment shown in Fig. 8. In Figs. 8 and 9, the same reference numerals as those shown in Figs. 1 to 7 denote similar parts, and detailed description thereof will be omitted.

[0063] The in-vehicle electronic control device 1A according to the modified example of the first embodiment shown in FIG. 8 is different from the in-vehicle electronic control device 1 according to the first embodiment in the following points. In the in-vehicle electronic control device 1 according to the first embodiment, the functional units 11, 12, 13, 14, 21, 22, and 23 (software blocks) are all implemented in one ECU (Electronic Control Unit) (see FIG. 2). In contrast, in the in-vehicle electronic control device 1A according to this modified example, the functional units 11A, 12A, 13, 14A, 21, 22, and 23 (software blocks) are separately implemented in either the zone ECUs 3 and 4 or the integrated ECU 5. Accordingly, the processing method of the functional units 11A, 12A, and 14A of the in-vehicle electronic control device 1A is changed, and a functional unit 16 is added. The other configurations of the modified example of the first embodiment are similar to those of the first embodiment.

[0064] Specifically, the in-vehicle electronic control device 1A according to this modification includes zone ECUs 3 and 4 and an integrated ECU 5. The zone ECUs 3 and 4 collect information for each area of ​​the vehicle 100, such as the front, rear, left, and right sides. The zone ECU 3 targets a certain area of ​​the vehicle 100, while the zone ECU 4 targets an area different from the zone ECU 3. The integrated ECU 5 integrates each function and uses the information collected by the zone ECUs 3 and 4. As with the in-vehicle electronic control device 1 according to the first embodiment, the zone ECUs 3 and 4 are provided with, as hardware configurations, a storage device (not shown) made of RAM, ROM, etc., and a processing device (not shown) made of CPU, MPU, etc., as well as with the in-vehicle electronic control device 1 according to the first embodiment. The integrated ECU 5 is also provided with, as hardware configurations, a storage device (not shown) made of RAM, ROM, etc., and a processing device (not shown) made of CPU, MPU, etc., as well as with the in-vehicle electronic control device 1 according to the first embodiment.

[0065] The zone ECUs 3 and 4 each have a sensor data calculation unit 16 in addition to a sensor information acquisition unit 11A and a data quality adjustment unit 14A similar to the functional units 11 and 14 of the in-vehicle electronic control unit 1 according to the first embodiment. On the other hand, the integrated ECU 5 has a computational resource estimation unit 12A, a computational resource allocation unit 13, a first application executor 21, a second application executor 22, and a third application executor 23 similar to the functional units 12, 13, 21, 22, and 23 of the in-vehicle electronic control unit 1 according to the first embodiment. The computational resource estimation unit 12A, the computational resource allocation unit 13, the first application executor 21, the second application executor 22, and the third application executor 23 require information from both the zone ECU 3 and the zone ECU 4, and therefore need to be implemented in the integrated ECU 5. In addition, since the computational resource allocation unit 13, the first application execution unit 21, the second application execution unit 22, and the third application execution unit 23 of the in-vehicle electronic control unit 1A in this modified example have the same configuration as those of the in-vehicle electronic control unit 1 in the first embodiment, their description will be omitted.

[0066] The sensor information acquisition unit 11A of the zone ECUs 3, 4 acquires sensor information related to the target areas of the zone ECUs 3, 4 from a target sensor in the sensor group 102. The data quality adjustment unit 14A of the zone ECUs 3, 4 adjusts the data quality of the sensor information related to the target areas of the zone ECUs 3, 4 acquired by the sensor information acquisition unit 11A in accordance with quality parameters set for each application. The data quality adjustment unit 14A outputs the sensor information with the adjusted data quality to the first application executor 21, the second application executor 22, and the third application executor 23 of the integrated ECU 5.

[0067] In this modification, the data quality adjustment unit 14A is implemented in the zone ECUs 3 and 4 instead of in the integrated ECU 5, thereby making it possible to reduce the amount of data communication between the zone ECUs 3 and 4 and the integrated ECU 5. If the data quality adjustment unit were implemented in the integrated ECU 5, the sensor information acquired by the sensor information acquisition unit 11A of the zone ECUs 3 and 4 would need to be output as is to the integrated ECU 5 (data quality adjustment unit). In contrast, by implementing the data quality adjustment unit 14A in the zone ECUs 3 and 4, the sensor information whose data quality has been adjusted is output to the integrated ECU 5. For this reason, when the data quality of the sensor information is reduced, the amount of sensor information output from the zone ECUs 3 and 4 to the integrated ECU 5 is reduced.

[0068] The sensor data calculation unit 16 of the zone ECUs 3 and 4 is responsible for receiving sensor information (step S10) and extracting the number of pieces of sensor data from the sensor information (step S20) among the series of processes (steps S10 to S50) shown in Fig. 3 in the computational resource estimation unit 12 of the in-vehicle electronic control unit 1 according to the first embodiment. On the other hand, the computational resource estimation unit 12A of the integrated ECU 5 is responsible for processing other than the processes performed by the sensor data calculation unit 16 of the zone ECUs 3 and 4 among the series of processes (steps S10 to S50) shown in Fig. 3 in the computational resource estimation unit 12 according to the first embodiment, and estimates the amount of computational resources required by each application. In other words, a combination of the sensor data calculation unit 16 of the zone ECUs 3 and 4 and the computational resource estimation unit 12A of the integrated ECU 5 corresponds to the computational resource estimation unit 12 of the in-vehicle electronic control unit 1 according to the first embodiment.

[0069] The processing procedure of the sensor data calculation units 16 of the zone ECUs 3 and 4 and the computational resource estimation unit 12A of the integrated ECU 5 is, for example, as follows. As shown in Fig. 9, first, the sensor data calculation units 16 of the zone ECUs 3 and 4 receive sensor information related to the target areas of the zone ECUs 3 and 4 from the sensor information acquisition units 11A of the zone ECUs 3 and 4 (step S10A), and extract the number of sensor data items that enable estimation of the computational resource amount required for each application from the received sensor information (step S20A). The sensor data calculation units 16 of the zone ECUs 3 and 4 output the extracted number of sensor data items to the integrated ECU 5 (computational resource estimation unit 12A) (step S22).

[0070] Next, the computational resource estimation unit 12A of the integrated ECU 5 acquires the number of pieces of sensor data output by the sensor data calculation units 16 of the zone ECUs 3 and 4 (step S24). Next, like the computational resource estimation unit 12 of the in-vehicle electronic control unit 1 according to the first embodiment, the computational resource estimation unit 12A refers to the calculation formula table shown in FIG. 4 (step S30) and estimates the amount of computational resources required for each application using the number of pieces of sensor data based on the estimation formula in the calculation formula table (step S40). The estimated amount of computational resources required for each application is output to the computational resource allocation unit 13 of the integrated ECU 5 (step S50).

[0071] In this modification, the sensor data calculation unit 16 of the zone ECUs 3 and 4 is responsible for the extraction process (step S20) of the number of sensor data from the sensor information in the computational resource estimation unit 12 of the in-vehicle electronic control unit 1 according to the first embodiment. This makes it possible to output only information (the number of sensor data) used to estimate the amount of computational resources required for each application without outputting the sensor information acquired by the sensor information acquisition unit 11A of the zone ECUs 3 and 4 to the integrated ECU 5 as it is. If the computational resource estimation unit 12A of the integrated ECU 5 has the same processing function as the computational resource estimation unit 12 of the in-vehicle electronic control unit 1 according to the first embodiment, it is necessary to output the sensor information acquired by the sensor information acquisition unit 11A of the zone ECUs 3 and 4 as it is to the integrated ECU 5. In contrast, in this modification, only the number of sensor data from the sensor information is output from the sensor information acquisition unit 11A of the zone ECUs 3 and 4 to the computational resource estimation unit 12A of the integrated ECU 5, so that the amount of data communication between the zone ECUs 3 and 4 and the integrated ECU 5 can be reduced.

[0072] According to the modification of the first embodiment described above, as in the first embodiment, sensor information whose data quality has been adjusted according to the quality parameters set for each application is input for the execution of each application, so that even for the execution of a black box application whose internal processing is unknown, it is possible to allocate computational resources according to the quality parameters set for the application.

[0073] Moreover, the on-vehicle electronic control device 1A according to this modification includes zone ECUs 3 and 4 as first electronic control devices mounted on the vehicle 100, and an integrated ECU 5 as a second electronic control device. The zone ECUs 3 and 4 (first electronic control devices) include a data quality adjustment unit 14A and a sensor information acquisition unit 11A that acquires sensor information from sensors of the sensor group 102 and transfers the sensor information to the data quality adjustment unit 14A, and are configured to output the sensor information whose data quality has been adjusted by the data quality adjustment unit 14A to the integrated ECU 5 (second electronic control device). The integrated ECU 5 (second electronic control device) includes a computational resource estimation unit 12A, a computational resource allocation unit 13, and multiple application execution units 21, 22, and 23 that receive the sensor information output from the zone ECUs 3 and 4 (first electronic control devices) and execute three apps (multiple applications), respectively. According to this configuration, by implementing the data quality adjustment unit 14A in the zone ECUs 3 and 4 (first electronic control units) rather than in the integrated ECU 5 (second electronic control unit), the sensor information acquired by the sensor information acquisition unit 11A of the zone ECUs 3 and 4 (first electronic control units) is output to the integrated ECU 5 after adjusting the data quality, so that the amount of data communication between the zone ECUs 3 and 4 and the integrated ECU 5 can be reduced compared to the case where the sensor information acquired by the sensor information acquisition unit 11A is output directly to the integrated ECU 5 (second electronic control unit).

[0074] [Second embodiment] Next, an on-vehicle electronic control device according to a second embodiment of the present invention will be described with reference to Figures 10 to 16. In Figures 10 to 16, the same reference numerals as those in Figures 1 to 9 denote similar parts, and detailed description thereof will be omitted. First, the configuration of the processing function of the on-vehicle electronic control device according to the second embodiment will be described with reference to Figure 10. Figure 10 is a block diagram showing the hardware configuration and the processing function configuration of the on-vehicle electronic control device according to the second embodiment.

[0075] The main points of difference between the in-vehicle electronic control device 1B according to the second embodiment shown in FIG. 10 and the in-vehicle electronic control device 1 according to the first embodiment are as follows. The in-vehicle electronic control device 1 according to the first embodiment changes the quality parameters of each provisionally set application by lowering the quality parameters from the highest quality "1" to the lowest quality "0". In contrast, the in-vehicle electronic control device 1B according to the second embodiment processes the change (downgrade) of the quality parameters of each provisionally set application continuously or in multiple stages. A specific method of changing the quality parameters will be described later. In addition, in the in-vehicle electronic control device 1 according to the first embodiment, the priority of the change (downgrade) of the provisionally set quality parameters between applications is previously determined as the execution priority of the application (see FIG. 6). In contrast, the in-vehicle electronic control device 1B according to the second embodiment is configured to calculate a change priority that is an index for determining which quality parameter of the provisionally set quality parameters for each application is to be changed, and change the provisionally set quality parameters for each application based on the change priority of the calculation result. The change priority of the quality parameters is calculated using vehicle driving information that is information on the driving situation of the vehicle.

[0076] Specifically, the in-vehicle electronic control device 1B includes a sensor information acquisition unit 11, a computational resource amount estimation unit 12B, a computational resource allocation unit 13B, a data quality adjustment unit 14, a first application execution unit 21, a second application execution unit 22, and a third application execution unit 23 as functional units (software blocks) similar to those of the in-vehicle electronic control device 1 according to the first embodiment. The processing contents of the computational resource amount estimation unit 12B and the computational resource allocation unit 13B of the in-vehicle electronic control device 1B are different from those of the functional units 12 and 13 of the first embodiment. Furthermore, the in-vehicle electronic control device 1B includes a change priority calculation unit 17 and a quality parameter change unit 18 as new functional units. The other hardware configurations and functional configurations of the in-vehicle electronic control device 1B of the second embodiment are similar to those of the first embodiment.

[0077] The computational resource amount estimation unit 12B performs processing to estimate the amount of computational resources required for each app, using the initialized provisional quality parameters or the provisional quality parameters from the quality parameter change unit 18 in addition to the sensor information from the sensor information acquisition unit 11. That is, the estimated amount of computational resources required for each app changes according to the provisional quality parameters of each app. The details of the processing flow of the computational resource amount estimation unit 12B will be described later. The computational resource amount estimation unit 12B delivers (outputs) the estimated result (processing result) of the amount of computational resources required for each app to the computational resource allocation unit 13B.

[0078] The computational resource allocation unit 13B determines a quality parameter for each app using the amount of computational resources required for each app estimated by the computational resource amount estimation unit 12B, thereby allocating (distributing) the computational resources of the in-vehicle electronic control unit 1 for the execution of each app. However, when a predetermined condition is satisfied, the computational resource allocation unit 13B outputs the quality parameter of each app as the allocation of computational resources to each app to the data quality adjustment unit 14, whereas when the predetermined condition is not satisfied, the computational resource allocation unit 13B outputs the provisionally set quality parameter of each app to the change priority calculation unit 17. The details of the processing flow of the computational resource allocation unit 13B will be described later.

[0079] The change priority calculation unit 17 performs a process of calculating a change priority for the provisionally set quality parameters of each application using the vehicle driving information and the provisionally set quality parameters of each application from the computational resource allocation unit 13B. The details of the process flow of the change priority calculation unit 17 will be described later. The change priority calculation unit 17 passes (outputs) the change priority of the provisionally set quality parameters of each application, which is the calculation result (processing result), to the quality parameter change unit 18.

[0080] The quality parameter change unit 18 performs processing to change the provisionally set quality parameters of the application having the highest change priority among the change priorities of the quality parameters of the applications from the change priority calculation unit 17. The details of the processing flow of the quality parameter change unit 18 will be described later. The quality parameter change unit 18 passes (outputs) the changed provisionally set quality parameters to the computational resource amount estimation unit 12B.

[0081] Next, a processing flow of the computational resource amount estimation unit in the on-board electronic control device according to the second embodiment will be described with reference to Fig. 11 and Fig. 12. Fig. 11 is a flowchart showing an example of processing executed by the computational resource amount estimation unit of the on-board electronic control device according to the second embodiment shown in Fig. 10. Fig. 12 is a calculation formula table for the computational resource amount estimation unit of the on-board electronic control device according to the second embodiment shown in Fig. 10 to estimate the amount of computational resources required for each app.

[0082] In FIG. 11, the computational resource amount estimation unit 12B of the in-vehicle electronic control unit 1B receives sensor information from the sensor information acquisition unit 11 (step S10) and extracts the number of sensor data items for each application from the sensor information (step S20), similar to the first embodiment (see FIG. 3).

[0083] Next, unlike the first embodiment, the computational resource amount estimation unit 12B determines whether or not the quality parameters are not set (step S24B). If it is determined in step S24B that the quality parameters of each application are not set (Yes), the computational resource amount estimation unit 12B initializes and provisionally sets the quality parameters of each application (step S26B). On the other hand, if it is determined that the quality parameters of each application have been set (No), the computational resource amount estimation unit 12B receives the provisional quality parameters of each application, including the quality parameters changed by the quality parameter change unit 18, from the quality parameter change unit 18 (step S28B).

[0084] The quality parameters in this embodiment are data quality that can be changed continuously or in multiple stages, and are changed continuously or in multiple stages to adjust the processing load (computational resources used) of each application. The quality parameters in this embodiment include the processing frequency of the sensor information (frequency of output to each application), the resolution of the image information or point sequence information in the sensor information, the detection range of the sensor information, etc. The initialization of the quality parameters in step S26B is to set the quality parameters to the highest quality. The highest quality of the data quality of the sensor information means the same data quality as the sensor information acquired by the sensor information acquisition unit 11 from the sensor group 102. Note that the determination that the quality parameters have been set in step S24B (No determination) means that a loop process for changing the provisionally set quality parameters is being executed.

[0085] Next, the computational resource amount estimation unit 12B refers to a computational formula table having an estimation formula for the computational resource amount required for each application (step S30B), and estimates the computational resource amount required for each application using the number of sensor data received in step S20 and the quality parameters of each application provisionally set in step S26B or step S28B based on the estimation formula in the computational formula table (step S40B). The computational formula table is composed of a first column 121 indicating application type information and a second column 122B indicating an estimation formula for the computational resource amount required for each application, as shown in FIG. 12, for example.

[0086] The estimation formula fb in the second column 122B is an estimation formula for a collision damage mitigation brake application, and is, for example, a function that takes as input the number of sensor detection points as the number of sensor data and the processing frequency as the quality parameter. The estimation formula gb in the second column 122B is an estimation formula for a falling object detection application, and is, for example, a function that takes as input the number of sensor detection points as the number of sensor data and the resolution as the quality parameter. The estimation formula hb in the second column 122B is an estimation formula for a target tracking application, and is, for example, a function that takes as input the number of targets detected by the sensor as the number of sensor data and the processing frequency as the quality parameter. Here, the number of sensor data is extracted from the sensor information in step S20. The quality parameter is the highest quality quality parameter initialized in step S26B or a provisionally set quality parameter received from the quality parameter change unit 18.

[0087] Furthermore, the computational resource amount estimation unit 12B outputs the amount of computational resources required for each application as an estimation result (step S50), similarly to the first embodiment. After executing step S50, the computational resource amount estimation unit 12B ends the process of this flow (one control cycle).

[0088] Next, a processing flow of the computational resource allocation unit in the on-vehicle electronic control device according to the second embodiment will be described with reference to Fig. 13. Fig. 13 is a flowchart showing an example of processing executed by the computational resource allocation unit of the on-vehicle electronic control device according to the second embodiment shown in Fig. 10.

[0089] 13, similarly to the first embodiment (see FIG. 5), computational resource allocation unit 13B receives the estimated amount of required computational resources for each app from computational resource amount estimation unit 12B (step S110), and acquires the amount of available computational resources, which is the amount of computational resources available for execution of all apps of first application executor 21, second application executor 22, and third application executor 23 (step S120). Next, computational resource allocation unit 13B adds up the amount of required computational resources for each app in which the provisionally set quality parameters of each app have already been reflected (step S140), and determines whether or not the total amount of required computational resources for each app is within the range of the amount of available computational resources (step S150).

[0090] If the total amount of required computational resources for each application is within the range of the amount of available computational resources in step S150 (Yes), the computational resource allocation unit 13B sets the quality parameters of each application provisionally set at that time as final quality parameters and outputs them to the data quality adjustment unit 14 (step S170B). That is, the computational resource allocation unit 13B allocates (distributes) the computational resources of the in-vehicle electronic control unit 1B for the execution of each application by setting the quality parameters of each application to be final.

[0091] If it is determined in step S150 that the total amount of required computational resources of each application exceeds the amount of available computational resources (No), the computational resource allocation unit 13B determines whether the number of times the provisional quality parameters have been changed has reached an upper limit (step S152). The upper limit of the number of times the quality parameters have been changed is determined by constraints such as the processing cycle of each application.

[0092] If it is determined in step S152 that the number of changes of the provisional quality parameters has reached the upper limit (Yes), the computational resource allocation unit 13B sets the quality parameters of each application by referring to the application execution priority table shown in FIG. 6 (step S160B). In step S160B, the computational resource allocation unit 13 of the first embodiment repeats steps S140 to S160 (loop processing) in the process flow of FIG. 5. That is, the quality parameters are set so as to decrease from the highest quality "1" to the lowest quality "0" in order from the application with the lowest execution priority until the total value of the required computational resource amount of each application according to the provisional quality parameters falls within the range of the available computational resource amount. That is, the quality parameters are changed from the highest quality "1" meaning the execution of the application to the lowest quality "0" meaning the stop of the execution of the application. The computational resource allocation unit 13B sets the quality parameters of each application set in step S160B as the final quality parameters and outputs them to the data quality adjustment unit 14 (step S170B).

[0093] When it is determined in step S152 that the number of changes to the quality parameters has not reached the upper limit (No), the computational resource allocation unit 13B outputs the quality parameters of each application that are provisionally set at the time of the processing to the change priority calculation unit (step S180). This starts the change processing for the provisionally set quality parameters of each application. After executing step S180 or step S170B, the computational resource allocation unit 13B ends the processing of this flow.

[0094] Next, a processing flow of the change priority calculation unit in the on-board electronic control device according to the second embodiment will be described with reference to Fig. 14 and Fig. 15. Fig. 14 is a flowchart showing an example of processing executed by the change priority calculation unit of the on-board electronic control device according to the second embodiment shown in Fig. 10. Fig. 15 is a calculation formula table for the change priority calculation unit of the on-board electronic control device according to the second embodiment shown in Fig. 10 to calculate the driving safety level of each app.

[0095] As described above, the change priority calculation unit 17 calculates a change priority for the provisionally set quality parameters of each application using the driving safety level of each application and the provisionally set quality parameters of each application from the computational resource allocation unit 13B. The driving safety level of the vehicle 100 is an index represented by at least one of the probability of occurrence of a predetermined event (e.g., an event that reduces safety) during execution of each application and the degree of influence on the predetermined event. For example, the driving safety level can be defined as a function with vehicle driving information and quality parameters as variables. Examples of the vehicle driving information include the vehicle speed obtainable from a speed sensor (not shown) of the sensor group 102, the driving situation obtainable from the driving action planning device 103, and the driver's operation input.

[0096] 14, the change priority calculation unit 17 first receives the provisional quality parameters of each application from the computational resource allocation unit 13B (step S310). Next, for example, a series of processes from steps S320 to S340 for calculating an index indicating the influence of the quality parameters of each application on the driving safety level of each application and a series of processes from steps S350 to S360 for calculating an index indicating the influence of the quality parameters of each application on the computational resources required by each application are executed in parallel. Note that a configuration in which the series of processes from steps S320 to S340 and the series of processes from steps S350 to S360 are executed in series is also possible.

[0097] The change priority calculation unit 17 acquires driving information of the vehicle 100 (step S320). Next, a calculation formula table having a calculation formula for the driving safety level of each application is referenced (step S330), and based on the calculation formula table, the vehicle driving information is used as input information to calculate the amount of change in the driving safety level of each application in response to a change (downgrade) in the provisionally set quality parameter of each application (step S340). The calculation formula table is, for example, stored in advance in the storage device 10a (see FIG. 10).

[0098] The calculation formula table is composed of a first column 171 indicating application type information and a second column 172 indicating a calculation formula of the driving safety level of each application, as shown in FIG. 15, for example. The calculation formula s in the second column 172 is a calculation formula of the driving safety level for the collision damage mitigation brake application, and is, for example, a function that inputs the own vehicle speed as the vehicle driving information and the processing frequency as the quality parameter. The estimation formula t in the second column 172 is a calculation formula of the driving safety level for the falling object detection application, and is, for example, a function that inputs the own vehicle speed as the vehicle driving information and the resolution as the quality parameter. The estimation formula u in the second column 172 is a calculation formula of the driving safety level for the target tracking application, and is, for example, a function that inputs the own vehicle speed as the vehicle driving information, the number of targets detected by the sensor as the number of sensor data, and the processing frequency as the quality parameter. In the collision damage mitigation brake and target tracking applications, the change amount of the driving safety level with respect to the change (downgrade) in the processing frequency as the quality parameter is calculated. On the other hand, in the falling object detection application, the amount of change in driving safety level with respect to a change (downgrade) in the resolution as a quality parameter is calculated.

[0099] The change priority calculation unit 17, in parallel processing, refers to a formula table having an estimation formula for the amount of required computational resources for each app (step S350), and calculates the amount of change in the amount of required computational resources for each app in response to a change (downgrade) in the quality parameter of each provisionally set app based on the formula table (step S360). The formula table referred to in step S350 is the required computational resource amount calculation formula table shown in FIG. 12. In the collision damage mitigation braking and target tracking apps, the amount of change in the amount of required computational resources in response to a change (downgrade) in the processing frequency as a quality parameter is calculated. On the other hand, in the falling object detection app, the amount of change in the amount of required computational resources in response to a change (downgrade) in the resolution as a quality parameter is calculated.

[0100] After the series of processes in steps S320 to S340 and the series of processes in steps S350 to S360 are completed, the change priority calculation unit 17 calculates the change priority of the quality parameters of each application (step S370). Specifically, the change amount of the driving safety level per unit amount of the required computational resource for the change in the quality parameters of each application is calculated using the change amount of the driving safety level for the change in the quality parameters of each application, which is the calculation result in step S340, and the change amount of the required computational resource for the change in the quality parameters of each application, which is the calculation result in step S360. That is, the change priority of the quality parameters of each application is calculated as a ratio of the calculation result in step S340 to the calculation result in S360.

[0101] The process of changing the provisional quality parameters is performed to optimize the data quality of the sensor information in a direction that reduces the quality of the sensor information. Therefore, it is preferable to preferentially change the quality parameters that reduce the driving safety level less and reduce the required computational resources more. From this, it can be said that the smaller the change in the driving safety level per unit amount of the required computational resources due to the change in the quality parameters, the higher the priority of the quality parameter change. Therefore, it is possible to use the change in the driving safety level of each app per unit amount of the required computational resources due to the change (downgrade) of the quality parameters as the priority of the quality parameter change.

[0102] The change priority calculation unit 17 outputs the change priority of the provisionally set quality parameters of each application, which is the calculation result of step S370, to the quality parameter change unit 18 (step S380). After executing step S380, the change priority calculation unit 17 ends the processing of this flow.

[0103] Next, a processing flow of the quality parameter change unit in the on-vehicle electronic control device according to the second embodiment will be described with reference to Fig. 16. Fig. 16 is a flowchart showing an example of processing executed by the quality parameter change unit in the on-vehicle electronic control device according to the second embodiment shown in Fig. 10.

[0104] As described above, the quality parameter change unit 18 changes the quality parameter with the highest change priority among the change priorities of the quality parameters of the applications from the change priority calculation unit 17. The change priority output by the change priority calculation unit 17 indicates that the smaller the value, the higher the change priority of the quality parameter.

[0105] In FIG. 16, the quality parameter change unit 18 receives the change priority of the provisional quality parameters of each application from the change priority calculation unit 17 (step S410). Next, the provisional quality parameter with the highest change priority among the change priorities of the quality parameters of each application is changed (step S420). That is, the quality parameter corresponding to the smallest value among the output values ​​of the change priority calculation unit 17 is changed. The provisional quality parameter with the smallest change amount of the driving safety level per unit amount of the required computational resources with respect to the change in the quality parameter is changed. Next, the quality parameter change unit 18 outputs the provisional quality parameters of each application including the changed quality parameter to the computational resource amount estimation unit (step S430). After executing step S430, the quality parameter change unit 18 ends the processing of this flow.

[0106] Next, the operation of the in-vehicle electronic control device according to the second embodiment will be described with reference to Fig. 17. Fig. 17 is a table showing an example of the transition of changes in the quality parameters of each application during the operation of the in-vehicle electronic control device according to the second embodiment.

[0107] In the in-vehicle electronic control device 1B according to this embodiment, the provisionally set quality parameters of each application are changed, for example, as shown in the table in Fig. 17, and the finally set quality parameters are output to the data quality adjustment unit 14. The table in Fig. 17 has a first column on the left side indicating the number of loops of the change process for the quality parameters, a second column indicating the change progress of the quality parameters related to the collision damage mitigation brake application as the first application, and a third column indicating the change progress of the quality parameters related to the falling object detection application as the second application. The values ​​of the quality parameters, change priority, and required computational resource amount of each application in the second and third columns are the calculation results for the number of loops in the first column.

[0108] The loop count shown in the first column is the initialization of the quality parameters in step S26B of the process flow shown in Fig. 11 as "0", and is incremented by "+1" each time a provisional quality parameter is received in step S28B of the process flow. The table shown in Fig. 17 indicates that the process of step S28B is executed twice. That is, the process of changing the provisional quality parameter is executed twice.

[0109] The quality parameter for the first application in the second column is the frequency of processing the sensor information, that is, the number of processes per second. The initialized quality parameter for the first application is a data quality in which the sensor information is processed five times per second as the highest quality. The estimated value of the required computational resource amount for the first application according to this quality parameter is 140 from the calculation result of step S40B of the process flow shown in FIG. 11. Moreover, the change priority of the quality parameter of the first application according to this quality parameter is 0.2 from the calculation result of step S370 of the process flow shown in FIG. 14. However, this is premised on the case where step S150 of the process flow shown in FIG. 13 is No.

[0110] The quality parameter of the second application in the third column is the resolution of the sensor information, and the unit is angle. The initialized quality parameter for the second application is data quality with a resolution of 2 degrees as the highest quality. The estimated value of the required computational resource amount of the second application according to this quality parameter is 110 from the calculation result of step S40B of the process flow shown in FIG. 12. In addition, the change priority of the quality parameter of the second application according to this quality parameter is 0.8 from the calculation result of step S370 of the process flow shown in FIG. 14. However, this is premised on the case where step S150 of the process flow shown in FIG. 13 is No.

[0111] When the loop count in the first column is "1", the quality parameter of the first application in the second column is changed, while the quality parameter of the second application in the third column is maintained. This is because when the loop count is "0", the change priority value of the first application in the second column (0.2) is smaller (higher change priority) than the change priority value of the second application in the third column (0.8). The quality parameter of the first application is reduced in the number of processes per second from 5 to 2. As a result of the change in the quality parameter of the first application, the estimated value of the required computational resource amount of the first application at this time changes from 140 to 80 from the calculation result in step S40B of the process flow shown in FIG. 11, and the change priority of the quality parameter of the first application changes from 0.2 to 1.5 from the calculation result in step S370 of the process flow shown in FIG. 14.

[0112] When the loop count in the first column is "2", the quality parameters of the first application in the second column are maintained, while the quality parameters of the second application in the third column are changed. This is because when the loop count is "1", the change priority value of the second application in the third column (0.8) is smaller (higher change priority) than the change priority value of the first application in the second column (1.5). The quality parameters of the second application are reduced in resolution from 2 degrees to 5 degrees. As a result of the change in the quality parameters of the second application, the estimated value of the required computational resource amount of the second application at this time changes from 110 to 60 based on the calculation result in step S40B of the process flow shown in FIG. 11, and the change priority of the quality parameters of the second application changes from 0.8 to 2.0 based on the calculation result in step S370 of the process flow shown in FIG. 14.

[0113] When the number of loops in the first column is "2", the sum of the estimated amount of computational resources required by the first application (80) and the estimated amount of computational resources required by the second application (60) in the second column falls within the range of the amount of computational resources available in the in-vehicle electronic control device 1. This determines the quality parameters of each application to be output to the data quality adjustment unit, and the loop process for changing the quality parameters ends.

[0114] According to the in-vehicle electronic control device 1B of the second embodiment described above, as in the first embodiment, sensor information whose data quality has been adjusted according to the quality parameters set for each app is input for the execution of each app, so that even for the execution of a black box app whose internal processing is unknown, computational resources can be allocated according to the quality parameters set for the app.

[0115] Moreover, the in-vehicle electronic control device 1B according to the present embodiment further includes a change priority calculation unit 17 that performs a process of calculating a change priority, which is an index for determining which quality parameter of the provisionally set quality parameters for each of the three apps (multiple applications), using vehicle driving information, which is information on the driving conditions of the vehicle 100, and a quality parameter change unit 18 that performs a process of changing the provisionally set quality parameters for each of the three apps (multiple applications), based on the change priority, which is a calculation result of the change priority calculation unit 17. The change priority calculation unit 17 and the quality parameter change unit 18 are configured to perform the process when the total value of the required computational resource amount obtained by adding up the required computational resource amount estimated according to the provisionally set quality parameters for each of the three apps (multiple applications) exceeds the available computational resource amount.

[0116] According to this configuration, when the combination of the change priority calculation unit 17 and the quality parameter change unit 18 exceeds the available amount of computational resources, the quality parameters of each app are changed based on the change priority of the quality parameters of each app calculated using vehicle driving information. This makes it possible to allocate (distribute) the computational resources of the in-vehicle electronic control unit 1 to the execution of each app in accordance with the driving conditions of the vehicle 100 while avoiding a shortage of computational resources in the in-vehicle electronic control unit 1 for the execution of three apps (multiple applications).

[0117] In addition, the change priority calculation unit 17 of the in-vehicle electronic control device 1B in this embodiment is configured to calculate a change priority for each of the three apps (multiple applications) based on a driving safety level, which is an index represented by at least one of the probability of occurrence of a specified event due to the execution of each of the three apps (multiple applications) and the degree of impact on the specified event, and which has vehicle driving information and quality parameters as variables.

[0118] According to this configuration, by calculating the change priority for the quality parameter of each application using the driving safety level of each application, it becomes possible to change the quality parameter taking into consideration the driving safety level of each application. This makes it possible to allocate (distribute) the computational resources of the in-vehicle electronic control unit 1 by changing the quality parameter while suppressing the deterioration of the driving safety level of each application.

[0119] In addition, the change priority calculation unit 17 of the in-vehicle electronic control device 1B in this embodiment is configured to calculate the amount of change in driving safety of each app when the provisionally set quality parameters for each app are changed using vehicle driving information, calculate the amount of change in the required computational resources of each app when the provisionally set quality parameters for each app are changed, and calculate the amount of change in driving safety per unit amount of required computational resources when the provisionally set quality parameters for each app are changed as the change priority for each app based on the calculated amount of change in driving safety and the calculated amount of change in the required computational resources.

[0120] According to this configuration, by calculating the amount of change in driving safety level per unit amount of required computational resources when the quality parameters of each application provisionally set are changed as the change priority of the quality parameters of each application, it becomes possible to change the quality parameters with priority to those with the least decrease in driving safety level and the greatest decrease in the amount of required computational resources. This makes it possible to appropriately allocate (distribute) the computational resources of the in-vehicle electronic control device 1 to the execution of each application while maintaining high driving safety.

[0121] In the present embodiment, the quality parameters include at least one of the processing frequency, resolution, and detection range of the sensor information.

[0122] According to this configuration, the quality parameters can be changed continuously or in multiple stages, and by continuously or in multiple stages changing the quality parameters of each application, it is possible to finely adjust the computational resources (processing load) used by each application.

[0123] [Modification of the second embodiment] Next, an on-vehicle electronic control device according to a modified example of the second embodiment will be described with reference to Figs. 18 and 19. Fig. 18 is a block diagram showing the hardware configuration and processing function configuration of an on-vehicle electronic control device according to a modified example of the second embodiment. Fig. 19 is a flowchart showing an example of processing executed by a sensor data calculation unit and a computational resource amount estimation unit of the on-vehicle electronic control device according to the modified example of the second embodiment shown in Fig. 18. In Figs. 18 and 19, the same reference numerals as those shown in Figs. 1 to 17 denote similar parts, and detailed descriptions thereof will be omitted.

[0124] The in-vehicle electronic control device 1C according to the modified example of the second embodiment shown in Fig. 18 differs from the in-vehicle electronic control device 1B according to the second embodiment in that the functional units 11C, 12C, 13B, 14C, 17, 18, 21, 22, 23 (software blocks) of the in-vehicle electronic control device 1C are separately implemented in either the zone ECUs 3 and 4 or the integrated ECU 5C. Accordingly, the processing method of the functional units 11C, 12C, 14C of the in-vehicle electronic control device 1C is changed, and a functional unit 16 is added. The other configurations of the in-vehicle electronic control device 1C according to the modified example of the second embodiment are similar to those of the first embodiment.

[0125] Specifically, the in-vehicle electronic control device 1C according to this modification includes zone ECUs 3 and 4 and an integrated ECU 5C. The zone ECUs 3 and 4 collect information for each area of ​​the vehicle 100, such as the front, rear, left side, and right side. The integrated ECU 5C integrates each function and uses the information collected by the zone ECUs 3 and 4. As with the in-vehicle electronic control device 1B according to the second embodiment, the zone ECUs 3 and 4 and the integrated ECU 5C each include, as a hardware configuration, a storage device (not shown) made up of a RAM, a ROM, etc., and a processing device (not shown) made up of a CPU, an MPU, etc.

[0126] The zone ECUs 3 and 4 have a sensor data calculation unit 16 in addition to a sensor information acquisition unit 11C and a data quality adjustment unit 14C having functions similar to those of the functional units 11 and 14 of the in-vehicle electronic control unit 1B according to the second embodiment. On the other hand, the integrated ECU 5C has a computational resource estimation unit 12C, a computational resource allocation unit 13C, a change priority calculation unit 17, a quality parameter change unit 18, a first application execution unit 21, a second application execution unit 22, and a third application execution unit 23, which are similar to the functional units 12B, 13B, 17, 18, 21, 22, and 23 of the in-vehicle electronic control unit 1B according to the second embodiment. The computational resource estimation unit 12C, the computational resource allocation unit 13B, the change priority calculation unit 17, the quality parameter change unit 18, the first application execution unit 21, the second application execution unit 22, and the third application execution unit 23 require information from both the zone ECU 3 and the zone ECU 4, and therefore need to be implemented in the integrated ECU 5C. In addition, the computational resource allocation unit 13B, the change priority calculation unit 17, the quality parameter change unit 18, the first application execution unit 21, the second application execution unit 22, and the third application execution unit 23 of the in-vehicle electronic control unit 1C of this modified example have the same configuration as those of the in-vehicle electronic control unit 1B of the second embodiment, so their description will be omitted.

[0127] The sensor information acquisition unit 11C of the zone ECUs 3 and 4 acquires sensor information related to the target areas of the zone ECUs 3 and 4. The data quality adjustment unit 14C of the zone ECUs 3 and 4 adjusts the data quality of the sensor information related to the target areas of the zone ECUs 3 and 4 acquired by the sensor information acquisition unit 11C in accordance with quality parameters set for each application. The data quality adjustment unit 14C outputs the sensor information with the adjusted data quality to the first application executor 21, the second application executor 22, and the third application executor 23 of the integrated ECU 5C.

[0128] In this modification, the data quality adjustment unit 14C is implemented in the zone ECUs 3 and 4 instead of in the integrated ECU 5C, thereby making it possible to reduce the amount of data communication between the zone ECUs 3 and 4 and the integrated ECU 5C. Since the sensor information whose data quality has been adjusted by the data quality adjustment unit 14C is output to the integrated ECU 5C, the amount of sensor information output to the integrated ECU 5C decreases when the data quality of the sensor information is degraded.

[0129] The sensor data calculation unit 16 of the zone ECUs 3 and 4 is responsible for receiving sensor information (step S10) and extracting the number of sensor data from the sensor information (step S20) among the series of processes (steps S10, S20, S24B, S26B, S28B, S30B, S40B, and S50) shown in FIG. 11 in the computational resource estimation unit 12B of the in-vehicle electronic control unit 1B according to the second embodiment. On the other hand, the computational resource estimation unit 12C of the integrated ECU 5C performs processes other than the processes performed by the sensor data calculation unit 16 of the zone ECUs 3 and 4 among the series of processes shown in FIG. 11 in the computational resource estimation unit 12B of the in-vehicle electronic control unit 1B according to the second embodiment. That is, a combination of the sensor data calculation unit 16 of the zone ECUs 3 and 4 and the computational resource estimation unit 12C of the integrated ECU 5C corresponds to the computational resource estimation unit 12B of the in-vehicle electronic control unit 1B according to the second embodiment.

[0130] The processing procedure of the sensor data calculation units 16 of the zone ECUs 3 and 4 and the computational resource estimation unit 12C of the integrated ECU 5C is, for example, as follows. As shown in Fig. 19, first, the sensor data calculation units 16 of the zone ECUs 3 and 4 receive sensor information related to the target areas of the zone ECUs 3 and 4 from the sensor information acquisition units 11C of the zone ECUs 3 and 4 (step S10C), and extract the number of pieces of sensor data from the received sensor information (step S20C). The sensor data calculation units 16 of the zone ECUs 3 and 4 output the extracted number of pieces of sensor data to the integrated ECU 5C (computational resource estimation unit 12C) (step S21C).

[0131] Next, the computational resource estimation unit 12C of the integrated ECU 5C acquires the number of pieces of sensor data output by the sensor data calculation unit 16 of the zone ECUs 3 and 4 (step S22C). Next, like the computational resource estimation unit 12B of the in-vehicle electronic control device 1B according to the second embodiment, the computational resource estimation unit 12C determines whether the quality parameters are not yet set (step S24B), and when it is determined that the quality parameters of each application are not yet set (Yes), it initializes and provisionally sets the quality parameters of each application (step S26B). On the other hand, when it is determined that the quality parameters of each application are already set (No), it receives the provisional quality parameters of each application including the quality parameters changed by the quality parameter change unit 18 from the quality parameter change unit 18 (step S28B). Furthermore, it refers to the calculation formula table shown in FIG. 12 (step S30B), and estimates the required computational resource amount of each application using the number of pieces of sensor data and the quality parameters for the estimation formula in the calculation formula table (step S40B). The amount of required computational resources for each application as a result of the estimation is output to the computational resource allocation unit 13B of the integrated ECU 5C (step S50).

[0132] In this modification, the sensor data calculation unit 16 of the zone ECUs 3 and 4 is responsible for the process of extracting the number of pieces of sensor data from the sensor information in the computational resource estimation unit 12B of the in-vehicle electronic control unit 1B according to the second embodiment (step S20). This makes it possible to output only information (the number of pieces of sensor data) used to estimate the amount of computational resources required for each application without outputting the sensor information acquired by the sensor information acquisition unit 11C of the zone ECUs 3 and 4 to the integrated ECU 5C as it is. In this modification, since only the number of pieces of sensor data from the sensor information is output from the sensor information acquisition unit 11C of the zone ECUs 3 and 4 to the computational resource estimation unit 12C of the integrated ECU 5C, the amount of data communication between the zone ECUs 3 and 4 and the integrated ECU 5 can be reduced.

[0133] According to the modified example of the second embodiment described above, as in the second embodiment, sensor information whose data quality has been adjusted according to the quality parameters set for each application is input for the execution of each application, so that even for the execution of a black box application whose internal processing is unknown, it is possible to allocate computational resources according to the quality parameters set for the application.

[0134] Moreover, the on-vehicle electronic control device 1C according to this modification includes zone ECUs 3 and 4 as first electronic control devices mounted on the vehicle 100, and an integrated ECU 5C as a second electronic control device. The zone ECUs 3 and 4 (first electronic control devices) include a data quality adjustment unit 14C and a sensor information acquisition unit 11C that acquires sensor information from sensors of the sensor group 102 and transfers the sensor information to the data quality adjustment unit 14A, and are configured to output the sensor information whose data quality has been adjusted by the data quality adjustment unit 14C to the integrated ECU 5C (second electronic control device). The integrated ECU 5C (second electronic control device) includes a computational resource estimation unit 12C, a computational resource allocation unit 13B, a change priority calculation unit 17, a quality parameter change unit 18, and multiple application execution units 21, 22, and 23 that receive the sensor information output from the zone ECUs 3 and 4 (first electronic control devices) and execute three applications (multiple applications), respectively. According to this configuration, by implementing the data quality adjustment unit 14C in the zone ECUs 3 and 4 (first electronic control units) rather than in the integrated ECU 5C (second electronic control unit), the sensor information acquired by the sensor information acquisition unit 11A of the zone ECUs 3 and 4 (first electronic control units) is output to the integrated ECU 5C after adjusting the data quality, so that the amount of data communication between the zone ECUs 3 and 4 and the integrated ECU 5C can be reduced compared to the case where the sensor information acquired by the sensor information acquisition unit 11C is output directly to the integrated ECU 5C (second electronic control unit).

[0135] [Other embodiments] The present invention is not limited to the above-mentioned first and second embodiments and their modifications, but includes various modifications. The above-mentioned embodiments have been described in detail to easily explain the present invention, and are not necessarily limited to those having all the configurations described. For example, it is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. It is also possible to add, delete, or replace a part of the configuration of each embodiment with another configuration.

[0136] For example, in the above-described first and second embodiments and their modified examples, the vehicle-mounted electronic control devices 1, 1A, 1B, and 1C each execute a plurality of (e.g., three) applications. However, the present invention can also be applied to a configuration in which the vehicle-mounted electronic control device executes one application.

[0137] In the above-mentioned first to second embodiments and their modified examples, the computational resource allocation unit 13, 13B of the in-vehicle electronic control device 1, 1A, 1B, 1C is configured to reduce the provisional quality parameter from the highest quality when the total amount of required computational resources estimated according to the provisional quality parameters for each application exceeds the available computational resource amount. However, the computational resource allocation unit can also be configured to reduce the provisional quality parameter from a state of lower quality than the highest quality when the total amount of required computational resources estimated according to the provisional quality parameters for each application exceeds the available computational resource amount. The computational resource allocation unit is configured to reduce the provisional quality parameter from, for example, 90% data quality as a state of low quality relative to the highest data quality. In this configuration, the upper limit of the quality parameter set for each application is a state of lower quality than the highest quality, so that the computational resources of each application allocated according to the quality parameter are reduced. This makes it possible for the in-vehicle electronic control device to secure in advance a surplus of computational resources available for emergency control. [Explanation of symbols]

[0138] 1, 1A, 1B, 1C... In-vehicle electronic control device, 3, 4... Zone ECU (first electronic control device), 5, 5C... Integrated ECU (second electronic control device), 12, 12A, 12B, 12C... Computational resource estimation unit, 11, 11A, 11C... Sensor information acquisition unit, 13, 13B... Computational resource allocation unit, 14, 14A, 14B, 14C... Data quality adjustment unit, 17... Change priority calculation unit, 18... Quality parameter change unit, 21... First application execution unit (application execution unit), 22... Second application execution unit (application execution unit), 23... Third application execution unit (application execution unit), 102... Sensor group (sensor)

Claims

1. An in-vehicle electronic control device that executes a plurality of applications using sensor information detected by a sensor, a computational resource estimation unit that estimates a required computational resource amount that is a computational resource amount necessary for executing each of the plurality of applications; a computational resource allocation unit that allocates computational resources to each of the plurality of applications by setting a quality parameter as an index indicating a data quality of the sensor information; a data quality adjustment unit that adjusts data quality of the sensor information acquired from the sensor in accordance with the quality parameter for each of the plurality of applications set by the computational resource allocation unit, and inputs the sensor information with the adjusted data quality to the execution of each of the plurality of applications; The computational resource allocation unit determines the quality parameter for each of the plurality of applications based on the required computational resource amount estimated according to the provisional setting of the quality parameter for each of the plurality of applications and an available computational resource amount that is an amount of computational resource that can be used by all of the plurality of applications. In-vehicle electronic control device.

2. 2. The in-vehicle electronic control device according to claim 1, The quality parameters include at least one of a processing frequency, a resolution, and a detection range of the sensor information. In-vehicle electronic control device.

3. 2. The in-vehicle electronic control device according to claim 1, The computational resource allocation unit determines the quality parameters for each of the plurality of applications such that a total value of the required computational resources obtained by adding up the required computational resource amounts estimated according to the provisionally set quality parameters for each of the plurality of applications falls within a range of the available computational resource amounts. In-vehicle electronic control device.

4. 4. The on-vehicle electronic control device according to claim 3, The computational resource allocation unit, when the total amount of required computational resources exceeds the amount of available computational resources, repeatedly lowering any one of the provisionally set quality parameters for each of the plurality of applications; The provisional quality parameters when the total amount of required computational resources falls within the range of the amount of available computational resources are determined as the quality parameters for each of the plurality of applications. In-vehicle electronic control device.

5. 5. The vehicle-mounted electronic control device according to claim 4, An execution priority indicating an order of priority for execution among the plurality of applications is set in advance; When the total value of the required amounts of computational resources exceeds the available amount of computational resources, the computational resource allocation unit reduces the provisionally set quality parameters in order from the application with the lowest execution priority until the total value of the required amounts of computational resources falls within the range of the available amount of computational resources. In-vehicle electronic control device.

6. 5. The vehicle-mounted electronic control device according to claim 4, The quality parameter is determined such that the data quality of the sensor information when acquired from the sensor is the highest quality; When the total value of the required amount of computational resources exceeds the available amount of computational resources, the computational resource allocation unit decreases the provisionally set quality parameter from the highest quality. In-vehicle electronic control device.

7. 5. The vehicle-mounted electronic control device according to claim 4, The quality parameter is determined such that the data quality of the sensor information when acquired from the sensor is the highest quality; When the total value of the required amount of computational resources exceeds the available amount of computational resources, the computational resource allocation unit decreases the provisionally set quality parameter from a state of quality lower than the highest quality. In-vehicle electronic control device.

8. 2. The on-vehicle electronic control device according to claim 1, a change priority calculation unit that performs a process of calculating a change priority, which is an index for determining which quality parameter of the provisionally set quality parameters for each of the plurality of applications is to be changed, using vehicle driving information, which is information regarding a driving state of a vehicle; a quality parameter change unit that performs a process of changing the provisionally set quality parameters for each of the plurality of applications based on the change priority that is a result of the calculation by the change priority calculation unit, The change priority calculation unit and the quality parameter change unit are configured to perform the process when a total value of the required computational resource amounts obtained by adding up the required computational resource amounts estimated according to the provisionally set quality parameters for each of the plurality of applications exceeds the available computational resource amount. In-vehicle electronic control device.

9. 9. The vehicle-mounted electronic control device according to claim 8, The change priority calculation unit calculates the change priority for each of the plurality of applications based on a driving safety level, which is an index represented by at least one of a probability of occurrence of a predetermined event due to execution of each of the plurality of applications and a degree of influence on the predetermined event, and which has the vehicle driving information and the quality parameter as variables. In-vehicle electronic control device.

10. 10. The vehicle-mounted electronic control device according to claim 9, The change priority calculation unit calculating, using the vehicle driving information, an amount of change in the driving safety level of each of the plurality of applications when the provisionally set quality parameter for each of the plurality of applications is changed; calculating a change in the required computational resource amount for each of the plurality of applications when the provisional quality parameter for each of the plurality of applications is changed; Calculating, as the change priority for each of the plurality of applications, an amount of change in the driving safety level per unit amount of the required computational resources when the provisionally set quality parameter for each of the plurality of applications is changed, based on the amount of change in the driving safety level of the calculation result and the amount of change in the required computational resources of the calculation result. In-vehicle electronic control device.

11. 2. The in-vehicle electronic control device according to claim 1, A first electronic control unit and a second electronic control unit mounted on a vehicle, The first electronic control unit includes: a sensor information acquisition unit that acquires the sensor information from the sensor and transfers the sensor information to the data quality adjustment unit, The sensor information, the data quality of which has been adjusted by the data quality adjustment unit, is output to the second electronic control device, The second electronic control device includes the computational resource estimation unit, the computational resource allocation unit, and a plurality of application execution units that receive the sensor information output from the first electronic control device and execute the plurality of applications, respectively. In-vehicle electronic control device.

12. 9. The vehicle-mounted electronic control device according to claim 8, A first electronic control unit and a second electronic control unit mounted on the vehicle, The first electronic control unit includes: a sensor information acquisition unit that acquires the sensor information from the sensor and transfers the sensor information to the data quality adjustment unit, The sensor information, the data quality of which has been adjusted by the data quality adjustment unit, is output to the second electronic control device, The second electronic control device includes the computational resource estimation unit, the computational resource allocation unit, the change priority calculation unit, the quality parameter change unit, and a plurality of application execution units that receive the sensor information output from the first electronic control device and execute the plurality of applications, respectively. In-vehicle electronic control device.

Images