Vehicle-mounted electronic control device

Abstract

This vehicle-mounted electronic control device comprises: a computational resource amount estimating unit that estimates a necessary computational resource amount for executing each application; a computational resource allocating unit that allocates computational resources to each application by setting a quality parameter as an index representing the data quality of sensor information; and a data quality adjusting unit that adjusts the data quality of the sensor information acquired from a sensor in accordance with the quality parameter for each application set by the computational resource allocating unit, and inputs the sensor information having the adjusted data quality for the execution of each application. The computational resource allocating unit determines the quality parameter for each application on the basis of the necessary computational resource amount estimated in accordance with a provisional setting of the quality parameter for each application and the amount of computational resources available to all of a plurality of applications.

Description

In-vehicle electronic control unit

[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.

[0002] To ensure safety and improve comfort, automobiles and other vehicles are being equipped with driving assistance and autonomous driving functions, which allow the vehicle itself to perform some of the surrounding monitoring and driving behaviors that are currently performed by the driver. To achieve these functions, there are multiple in-vehicle applications that provide emergency steering assistance, lane keeping assistance, and fallen object detection. These types of applications (hereinafter 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 increasingly complex vehicle situations, resulting in a strain on the computing resources of in-vehicle computers.

[0003] To address the strain on computational resources of an onboard computer due to application execution, for example, a technology described in Patent Document 1 has been proposed. The onboard 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, which recognizes the lane in which the vehicle is traveling, and side vehicle detection, which detects the presence of vehicles on the sides of the vehicle. Both applications detect pre-defined detection elements using images from an imaging unit (camera). Detection elements for lane recognition include, for example, the lateral position of the vehicle relative to the white lines that define the lane and the curvature indicating the degree of curvature of a curve. Detection elements for side vehicle detection include, for example, vehicles present on the left or right side of the vehicle. The onboard environment recognition device includes an application control unit that issues application execution requests to each application to perform processing according to the detection accuracy (calculation accuracy) of each application's detection element, which is adjusted depending on the vehicle's situation 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 (e.g., relatively high or low resolution) of the detection elements in accordance with the application execution request (instruction) from the application control unit.

[0004] JP 2013-105385 A

[0005] The technology described in Patent Literature 1 is based on the premise that the calculation accuracy (detection accuracy of detection elements) can be changed (adjusted) in the internal processing of each app. For this reason, the technology described in Patent Literature 1 is difficult to apply 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 problems, and its purpose is to provide an in-vehicle electronic control device that enables the allocation of computing resources to the execution of a black box application whose internal processing is unknown.

[0007] The present application includes a plurality of means for solving the above-described problems. An example of an on-board electronic control device of the present application is an on-board electronic control device that executes a plurality of applications using sensor information detected by a sensor, the on-board electronic control device including: a computational resource estimator that estimates a required amount of computational resources that is an amount of computational resources 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 of 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 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 adjusted data quality for execution of each of the plurality of applications, wherein the computational resource allocation unit determines the quality parameter for each of the plurality of applications based on the required amount of computational resources estimated in accordance with the provisional setting of the quality parameter for each of the plurality of applications and an available amount of computational resources that is an amount of computational resources that can be used by all of the plurality of applications.

[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 clear from the description of the embodiment below.

[0009] 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. FIG. 2 is a block diagram showing the hardware configuration and processing function configuration of the on-vehicle electronic control device according to the first embodiment. FIG. 3 is a flowchart showing an example of processing executed by a computational resource amount estimating unit of the on-vehicle electronic control device according to the first embodiment shown in FIG. 2. FIG. 4 is a calculation formula table for the computational resource amount estimating unit of the on-vehicle electronic control device according to the first embodiment shown in FIG. 2 to estimate the amount of computational resources required for each app. FIG. 4 is a flowchart showing an example of processing executed by a computational resource allocating unit of the on-vehicle electronic control device according to the first embodiment shown in FIG. 2. FIG. 5 is a table showing the execution priority of each app used by the computational resource allocating unit of the on-vehicle electronic control device according to the first embodiment shown in FIG. 2. FIG. 6 is a flowchart showing an example of processing executed by a data quality adjusting unit of the on-vehicle electronic control device according to the first embodiment shown in FIG. 2. FIG. 7 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. 8 is a flowchart showing an example of processing executed by a sensor data calculation unit and a computational resource amount estimating unit of the on-vehicle electronic control device according to the modified example of the first embodiment shown in FIG. 10 is a flowchart showing an example of processing executed by a computational resource amount estimation unit of the in-vehicle electronic control device according to the second embodiment shown in FIG. 10. It is a calculation formula table used by the computational resource amount estimation 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 app. It is a flowchart showing an example of processing executed by a computational resource allocation unit of the in-vehicle electronic control device according to the second embodiment shown in FIG. 10. It is a flowchart showing an example of processing executed by a change priority calculation unit of the in-vehicle electronic control device according to the second embodiment shown in FIG. 10. It is a calculation formula table used by 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 app. It is a flowchart showing an example of processing executed by a quality parameter change unit of the in-vehicle electronic control device according to the second embodiment shown in FIG. It is a table showing an example of progress of changes in the quality parameters of each app during operation of the in-vehicle electronic control device according to the second embodiment.18 is a block diagram showing a hardware configuration and a configuration of processing functions of an on-board electronic control device according to a modification of the second embodiment. It 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-board electronic control device according to the modification of the second embodiment shown in FIG.

[0010] Hereinafter, embodiments 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 and its related hardware configuration according to the first embodiment.

[0011] 1, a vehicle 100 includes an on-board electronic control unit 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 interconnects these devices 1, 102, and 103. The on-board electronic control unit 1, the group of sensors 102, and the driving behavior planning device 103 can communicate information with each other via the common bus 104.

[0012] The on-board electronic control unit 1 executes a plurality of applications (hereinafter referred to as apps) that use sensor information, which is a large amount of data detected by the sensor group 102, and is configured to output processing results of the plurality of apps to the driving action planning device 103. The hardware configuration and processing functions of the on-board electronic control unit 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 make up the sensor group 102 include a speed sensor that detects the traveling speed of the vehicle 100, one or more cameras that capture images of the front, rear, left, and right sides of the vehicle 100, radar that emits radio waves to measure the distance and direction to an object, and 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 make up the sensor group 102, a configuration is possible in which sensor information detected by one sensor is used by an app, or a configuration in which sensor information detected by multiple sensors is used by an app. Furthermore, the sensor group 102 may 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 processing results obtained by executing an app implemented in the on-board electronic control device 1, for example. The driving behavior planning device 103 also grasps driving conditions such as lane changes and right turns during driving assistance.

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

[0016] 2 , the in-vehicle electronic control unit 1 includes, as its hardware configuration, a storage device 10a including RAM, ROM, etc., and a processing device 10b including a CPU, MPU, etc. The storage device 10a pre-stores a plurality of applications, as well as programs and various information necessary for allocating the computational resources of the in-vehicle electronic control unit 1 when the plurality of applications are executed. The processing device 10b appropriately reads the plurality of applications, predetermined programs, and various information from the storage device 10a, appropriately acquires sensor information from a sensor group 102, and executes processing in accordance with the plurality of applications and predetermined programs, thereby realizing various processing functions for allocating the computational resources of the in-vehicle electronic control unit 1 for the execution of the plurality of applications. The in-vehicle electronic control unit 1 is configured to be able to execute, for example, three applications: a first application, a second application, and a third application. The in-vehicle electronic control unit 1 includes, as processing functions implemented by software running on the in-vehicle electronic control unit 1, 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. Each of the functional units 11, 12, 13, 14, 21, 22, and 23 of the on-vehicle electronic control unit 1 executes processing within a predetermined cycle, for example.

[0017] The sensor information acquisition unit 11 performs processing to input 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 input from the sensor group 102 to the computational resource amount estimation unit 12 and the data quality adjustment unit 14.

[0018] The computational resource amount estimation unit 12 performs processing to estimate the amount of computational resources required for each app, which is the amount of computational resources required to execute the first app, the amount of computational resources required to execute the second app, and the amount of computational resources required to execute the third app, using the sensor information received from the sensor information acquisition unit 11. Specific details of the estimation method and processing flow of the computational resource amount estimation unit 12 will be described later. The computational resource amount estimation unit 12 passes (outputs) the amount of computational resources required for each app, which is the estimation result (processing result), to the computational resource allocation unit 13.

[0019] The computational resource allocation unit 13 allocates computational resources of the in-vehicle electronic control unit 1 to each of the first, second, and third applications by setting a quality parameter, which 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, which is the estimated result received from the computational resource amount estimation unit 12. In this embodiment, the quality parameter is the frequency of processing sensor information for each application, and corresponds to whether or not each application is executed. Specifically, the quality parameter represents a processing frequency of "1" when sensor information acquired by the sensor information acquisition unit 11 is input for application execution, and a processing frequency of "0" when sensor information is not input for application execution. In other words, a quality parameter of "1" 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 executing the application are allocated. On the other hand, a quality parameter of "0" means that the sensor information acquired by the sensor information acquisition unit 11 is not input, and therefore the application is not executed, and no computational resources are allocated to the application. The details of the specific computational resource allocation method and processing flow of the computational resource allocation unit 13 will be described later. The computational resource allocation unit 13 passes (outputs) the quality parameters for each application, which are the setting results (processing results), to the data quality adjustment unit 14.

[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 resulting from the setting output from the computational resource allocation unit 13, and delivers (outputs) 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. In this embodiment, the quality parameters are represented 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 a processing frequency of "0" when the sensor information is not input to the execution of each application. Therefore, in this embodiment, when the quality parameter for each application is a processing frequency of "1," the data quality adjustment unit 14 inputs the sensor information acquired by the sensor information acquisition unit 11 directly to each application execution unit 21, 22, and 23. On the other hand, when the quality parameter for each application is a 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 execute a corresponding 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 execute, for example, applications for collision damage mitigation braking, falling object detection, and target tracking.

[0022] The collision damage mitigation brake application 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 ahead or to the side detected by the sensor group 102, it warns the driver with a warning sound or warning light, etc., to urge the driver to apply the brakes. Furthermore, when the driver does not apply the brakes in response to the urging and it is determined that there is a high possibility of a collision, the application activates the brakes.

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

[0024] The target tracking application detects a target by, for example, monitoring the surrounding driving environment detected by the sensor group 102. Furthermore, the detected target is tracked using sensor information from the sensor group 102.

[0025] Next, a calculation method and processing flow of the computational resource amount estimation unit in the on-board electronic control unit according to the first embodiment will be described with reference to Figures 3 and 4. Figure 3 is a flowchart showing an example of processing executed by the computational resource amount estimation unit of the on-board electronic control unit according to the first embodiment shown in Figure 2. Figure 4 is a calculation formula table used by the computational resource amount estimation unit of the on-board electronic control unit according to the first embodiment shown in Figure 2 to estimate the amount of computational 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 unit 1 estimates the amount of computational resources required for each of the first, second, and third applications. For example, as shown in FIG. 3, the computational resource amount estimation unit 12 estimates the amount of computational resources required for each application 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 items 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 items varies depending on the characteristics of each application. Examples of the number of sensor data items include the number of sensor detection points, which is the number of detection targets detected by the sensor group 102, the amount of sensor information data detected by the sensor group 102, and the number of targets detected by the sensor group 102.

[0028] Next, the computational resource amount estimator 12 refers to a calculation 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 calculation formula table (step S40). The calculation formula table is pre-stored in, for example, the storage device 10a (see FIG. 2). As shown in FIG. 4, for example, the calculation 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 braking app 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 for each app. Estimation formula g in the second column 122 is, for example, an estimation formula for a falling object detection app 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 app 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 estimated amount of computational resources required for each application (step S50). After executing step S50, the computational resource amount estimation unit 12 ends the processing of this flow.

[0031] Next, the processing flow of the computational resource allocation unit in the on-board electronic control unit 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 unit 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 unit according to the first embodiment shown in Fig. 2.

[0032] As described above, the computational resource allocation unit 13 (see FIG. 2) of the on-board electronic control unit 1 sets quality parameters for each application to allocate (distribute) the computational resources of the on-board 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 computational resources required for each app as an estimated result from the computational resource amount estimation unit 12 (step S110). Next, it acquires the amount of available computational resources, which is the amount of computational resources available for execution of all apps by the first application execution unit 21, the second application execution unit 22, and the third application execution unit 23 (step S120). The on-board electronic control unit 1 can be configured to calculate the amount of available computational resources according to the operating state of the on-board 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 quality parameters are represented by the processing frequency of sensor information for each application corresponding to whether or not each application is executed. Specifically, the quality parameters are represented by 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 the application. Therefore, in this embodiment, the maximum quality of the quality parameters 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 amounts of computational resources required for each app according to the provisionally set quality parameters of each app with respect to the amount of computational resources estimated by the computational resource amount estimation unit 12 (step S140), and determines whether the total amount of computational resources required for each app is within the range of the amount of available computational resources acquired in step S120 (step S150). When the total amount of computational resources required for each app according to the provisionally set quality parameters is within the range of the amount of available computational resources, it is predicted that the computational resources used by the app executed using the sensor information on the data quality of the provisionally set quality parameters as input will fall within the range of computational resources provided by the in-vehicle electronic control unit 1.

[0036] If the total amount of required computational resources for each application exceeds the available amount of computational resources (NO in step S150), the computational resource allocation unit 13 reduces the provisional quality parameters of the applications in descending order of execution priority (step S160), and repeats steps S140 to S160 (performing a loop process) until the total amount of required computational resources for each application falls within the range of the available amount of computational resources. If the total amount of required computational resources for each application falls within the range of the available amount of computational resources (YES in step S150), the 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 amounts of computational resources required for 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 a processing frequency of "1," and the quality obtained when the maximum quality is lowered becomes the minimum quality processing frequency of "0." At the initial processing of step S140, the quality parameters of each application are initialized to the processing frequency of "1" for the highest quality. Therefore, the total amount of computational resources required for each application at the initial processing of step S140 is the sum of the amounts of computational resources required for each application estimated by the 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 (NO in step S150), it is predicted that the computational resources of the in-vehicle electronic control unit 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 applications, starting with the application with the lowest execution priority (step S160). Specifically, the computational resource allocation unit 13 refers to the application execution priority table and reduces the provisionally set quality parameter for the application with the lowest execution priority.

[0039] The application execution priority table, as shown in Fig. 6, is composed of a first column 131 indicating application type information and a second column 132 indicating execution priority information for each application. In the application execution priority table shown in Fig. 6, the application for collision damage mitigation braking is set to the highest execution priority of "1" among the three applications from the perspective of improving safe driving. The application for falling object detection is set to the lowest execution priority of "3" among the three applications. The application for target tracking is set to the middle execution priority of "2" 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 for the falling object detection app with the lowest execution priority, whose quality parameter has been lowered, in accordance with the lowered quality parameter, and again sums up the amount of computational resources required for each app (step S140 in the first loop processing). The result of the recalculation of the amount of computational resources required for the falling object detection app becomes "0" in accordance with the change in the processing frequency of the lowest quality of the app's quality parameter to "0." Therefore, the total amount of computational resources required for each app in accordance with the provisionally set quality parameter is reduced by the amount of computational resources required for the falling object detection app 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 (if Yes), the quality parameters for the falling object detection app are set as the minimum quality of "0," and the quality parameters for the other apps are set as the initialized maximum quality of "1," as the final quality parameters. This means that the computational resources of the in-vehicle electronic control unit 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, if the total amount of required computational resources recalculated according to the reduced quality parameters still exceeds the available amount of computational resources (No in step S150), the quality parameters of the target tracking app with the next lowest execution priority are reduced, and the amount of required computational resources of the target tracking app with the reduced quality parameters is recalculated according to the reduced quality parameters, and the amount of required computational resources of each app is again added up (step S140 by the second loop processing). Because the quality parameters of the target tracking app are also changed to the lowest quality processing frequency of "0," the recalculated amount of required computational resources of the target tracking app becomes "0" in accordance with the change of the app's quality parameter to the lowest quality of "0." Therefore, the total amount of required computational resources of each app according to the provisional quality parameters is further reduced by the amount of required computational resources of the target tracking app estimated by the computational resource amount estimation unit 12. That is, the total amount of required computational resources of each app according to the provisional quality parameters is the amount of required computational resources of only the collision damage mitigation braking 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 damage mitigation brake application.

[0044] Through these processes, the computational resource allocation unit 13 sets the quality parameters for each application from provisional settings to final settings, and 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, the processing flow of the data quality adjustment unit in the on-vehicle electronic control unit 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 unit according to the first embodiment shown in Fig. 2.

[0046] As described above, the data quality adjustment unit 14 (see FIG. 2 ) of the on-board electronic control unit 1 adjusts the data quality of the sensor information from the sensor information acquisition unit 11 in accordance with 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 , by executing the following steps S210 to S240 at each predetermined control cycle, the sensor information whose data quality has been adjusted in accordance with the quality parameters set for each application is input 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 then receives quality parameters of each application from the computational resource allocation unit 13 (step S220). The order of the processes in 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 represented 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 a processing frequency of "0" when the sensor information is not input to the execution of each application. Therefore, the data quality of the sensor information to be input to each application is adjusted using the highest quality of "1" or the lowest 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, if 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, if 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, first application execution unit 21, second application execution unit 22, and third application execution unit 23 receive sensor information whose data quality has been adjusted according to quality parameters set for each application. That is, each of application execution units 21, 22, and 23 performs processing using the sensor information whose data quality has been adjusted by data quality adjustment unit 14 as input information. In this case, even if each of application execution units 21, 22, and 23 executes a black-box application whose internal processing cannot be changed by external instructions, it is possible to increase or decrease the computational resources used by each of application execution units 21, 22, and 23 by adjusting the data quality of the sensor information input to each of application execution units 21, 22, and 23 without changing the internal processing of each of application execution units 21, 22, and 23. For example, by lowering the data quality of the sensor information input to each of application execution units 21, 22, and 23, it is possible to reduce the computational resources used by each of application execution units 21, 22, and 23.

[0051] The quality parameter in this embodiment is a processing frequency of sensor information for each application, corresponding 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 a plurality of applications that use sensor information detected by sensors that constitute the sensor group 102, and includes: a computational resource amount estimation unit 12 that estimates a required computational resource amount, which is the amount of computational resources required to execute each of the first application, the second application, and the third application (a plurality of applications); a computational resource allocation unit 13 that allocates computational resources to each of the three applications (a plurality of 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 parameter for each of the three applications (a plurality of 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 (a plurality of 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 according to 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 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 computing resources according to the quality parameters set for the 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 according to the quality parameters falls within the range of available computational resources, thereby avoiding a shortage of computational resources in the in-vehicle electronic control unit 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 unit 1 in this embodiment repeatedly lowers one of the quality parameters of the provisional settings for each of the three apps (multiple applications), and determines the provisional setting quality parameter when the total amount of required computational resources falls within the range of the 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 available computational resources by lowering one of the quality parameters of each provisionally set app, thereby making it possible to appropriately allocate (distribute) the computational resources of the in-vehicle electronic control unit 1 to each app by using the quality parameters set for each app.

[0058] Furthermore, in the in-vehicle electronic control unit 1 according to the present embodiment, execution priorities indicating the order of execution priority among the three apps (plurality of applications) are 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 unit 1 reduces the provisionally set quality parameters of the applications in order from 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 unit 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 data quality of the sensor information obtained from the sensors of the sensor group 102 is set to be the highest quality for the quality parameter, and the computational resource allocation unit is configured to decrease the provisionally set quality parameter from the highest quality when the total value of the required computational resources exceeds the available computational resources.

[0061] With this configuration, it is possible to set the quality parameters of each app to the high quality side, thereby increasing the allocation (distribution) of computational resources for the execution of each app, and therefore making the most of the available computational resources of the in-vehicle electronic control unit 1 for the execution of three apps (multiple applications).

[0062] [Modification of the First Embodiment] Next, an on-vehicle electronic control device according to a modification of the first embodiment will be described with reference to Figures 8 and 9. Figure 8 is a block diagram showing the hardware configuration and processing function configuration of the on-vehicle electronic control device according to the modification of the first embodiment. Figure 9 is a flowchart showing an example of processing executed by the sensor data calculation unit and the computational resource amount estimation unit of the on-vehicle electronic control device according to the modification of the first embodiment shown in Figure 8. Note that in Figures 8 and 9, parts with the same reference numerals as those shown in Figures 1 to 7 are 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 differs from the in-vehicle electronic control device 1 according to the first embodiment in the following respects. 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 a single 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 has been changed, and a functional unit 16 has been added. The remaining configuration of the modified example of the first embodiment is similar to that 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 region of the vehicle 100, such as the front, rear, left, and right sides. The zone ECU 3 targets a certain region of the vehicle 100, while the zone ECU 4 targets a different region from the zone ECU 3. The integrated ECU 5 integrates the various functions and utilizes the information collected by the zone ECUs 3 and 4. Similar to the in-vehicle electronic control device 1 according to the first embodiment, the zone ECUs 3 and 4 include, as hardware components, a storage device (not shown) including RAM, ROM, etc., and a processing device (not shown) including a CPU, MPU, etc. Similar to the in-vehicle electronic control device 1 according to the first embodiment, the integrated ECU 5 also includes, as hardware components, a storage device (not shown) including RAM, ROM, etc., and a processing device (not shown) including a CPU, MPU, etc.

[0065] The zone ECUs 3 and 4 each include 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, as well as a sensor data calculation unit 16. On the other hand, the integrated ECU 5 includes a computational resource amount estimation unit 12A, a computational resource allocation unit 13, a first application execution unit 21, a second application execution unit 22, and a third application execution unit 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 amount estimation unit 12A, 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 require information from both the zone ECU 3 and the zone ECU 4, and therefore need to be implemented in the integrated ECU 5. Note that 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 of this modified example have the same configuration as those of the in-vehicle electronic control unit 1 of the first embodiment, and therefore their description will be omitted.

[0066] The sensor information acquisition unit 11A of each of the zone ECUs 3 and 4 acquires sensor information relating to the target area of ​​each of the zone ECUs 3 and 4 from a target sensor in the sensor group 102. The data quality adjustment unit 14A of each of the zone ECUs 3 and 4 adjusts the data quality of the sensor information relating to the target area of ​​each of the zone ECUs 3 and 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 adjusted data quality to the first application execution unit 21, the second application execution unit 22, and the third application execution unit 23 of the integrated ECU 5.

[0067] In this modified example, the data quality adjustment unit 14A is implemented in the zone ECUs 3 and 4 instead of in the integrated ECU 5, thereby reducing 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 directly 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. Therefore, if 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 units 16 of the zone ECUs 3 and 4 are responsible for receiving sensor information (step S10) and extracting the number of sensor data items from the sensor information (step S20) among the series of processes (steps S10 to S50) shown in FIG. 3 performed by the computational resource amount estimation unit 12 of the in-vehicle electronic control unit 1 according to the first embodiment. Meanwhile, the computational resource amount estimation unit 12A of the integrated ECU 5 performs processes other than those performed by the sensor data calculation units 16 of the zone ECUs 3 and 4 among the series of processes (steps S10 to S50) performed by the computational resource amount estimation unit 12 according to the first embodiment shown in FIG. 3 , and estimates the amount of computational resources required for each app. In other words, the combination of the sensor data calculation units 16 of the zone ECUs 3 and 4 and the computational resource amount estimation unit 12A of the integrated ECU 5 corresponds to the computational resource amount estimation unit 12 of the in-vehicle electronic control unit 1 according to the first embodiment.

[0069] 9 , the sensor data calculation units 16 of the zone ECUs 3 and 4 and the computational resource amount estimation unit 12A of the integrated ECU 5 perform the following processing steps: 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, from the received sensor information, the number of pieces of sensor data that enable estimation of the computational resource amounts required for each app (step S20A). The sensor data calculation units 16 of the zone ECUs 3 and 4 then output the extracted number of pieces of sensor data to the integrated ECU 5 (computational resource amount estimation unit 12A) (step S22).

[0070] Next, the computational resource amount 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, similar to the computational resource amount estimation unit 12 of the in-vehicle electronic control unit 1 according to the first embodiment, the computational resource amount 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 app 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 app 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 process of extracting the number of sensor data items from the sensor information in the computational resource amount estimation unit 12 of the on-board electronic control unit 1 according to the first embodiment (step S20). This makes it possible to output only information (the number of sensor data items) used to estimate the amount of computational resources required for each app, without outputting the sensor information acquired by the sensor information acquisition unit 11A of the zone ECUs 3 and 4 directly to the integrated ECU 5. If the computational resource amount estimation unit 12A of the integrated ECU 5 had the same processing function as the computational resource amount estimation unit 12 of the on-board electronic control unit 1 according to the first embodiment, the sensor information acquired by the sensor information acquisition unit 11A of the zone ECUs 3 and 4 would need to be output directly to the integrated ECU 5. In contrast, in this modification, only the number of sensor data items from the sensor information is output from the sensor information acquisition unit 11A of the zone ECUs 3 and 4 to the computational resource amount estimation unit 12A of the integrated ECU 5, thereby reducing the amount of data communication between the zone ECUs 3 and 4 and the integrated ECU 5.

[0072] According to the above-described modification of the first embodiment, similarly to the first embodiment, 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.

[0073] The on-board 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 amount 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, thereby reducing the amount of data communication between the zone ECUs 3 and 4 and the integrated ECU 5 compared to when 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 shown in Figures 1 to 9 indicate 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 processing function configuration of the on-vehicle electronic control device according to the second embodiment.

[0075] The main differences 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 provisionally set quality parameters of each app by lowering the quality parameter 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 provisionally set quality parameters of each app so as to change (downgrade) them continuously or in multiple stages. A specific method for changing the quality parameters will be described later. Furthermore, the in-vehicle electronic control device 1 according to the first embodiment predetermines the priority of the provisionally set quality parameters between apps as the execution priority of the apps (see FIG. 6 ). In contrast, the in-vehicle electronic control device 1B according to the second embodiment is configured to calculate a change priority, which is an index for determining which of the provisionally set quality parameters for each app should be changed, and change the provisionally set quality parameters for each app based on the change priority obtained by the calculation. The change priority of the quality parameters is calculated using vehicle driving information, which is information related to the vehicle's driving conditions.

[0076] Specifically, the in-vehicle electronic control unit 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 unit 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 unit 1B are different from those of the functional units 12 and 13 according to the first embodiment. Furthermore, the in-vehicle electronic control unit 1B includes a change priority calculation unit 17 and a quality parameter change unit 18 as new functional units. The other hardware and functional configurations of the in-vehicle electronic control unit 1B according to 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 provisionally set quality parameters or the provisionally set quality parameters from the quality parameter modification 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 depending on the provisionally set quality parameters of each app. Details of the processing flow of the computational resource amount estimation unit 12B will be described later. The computational resource amount estimation unit 12B passes (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 allocates (distributes) the computational resources of the in-vehicle electronic control unit 1 to the execution of each application by determining quality parameters for each application using the amount of computational resources required for each application estimated by the computational resource amount estimation unit 12B. However, if a predetermined condition is satisfied, the computational resource allocation unit 13B outputs the quality parameters of each application as the allocation of computational resources for each application to the data quality adjustment unit 14, while if the predetermined condition is not satisfied, the computational resource allocation unit 13B outputs the provisionally set quality parameters of each application to the change priority calculation unit 17. 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 process flow of the change priority calculation unit 17 will be described in detail 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 with the highest change priority among the change priorities of the quality parameters of each application from the change priority calculation unit 17. 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 a computational resource amount estimation unit in an 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 used by 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 Figure 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), as in the first embodiment (see Figure 3), and extracts the number of sensor data items for each app from the sensor information (step S20).

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

[0084] The quality parameters in this embodiment are data quality parameters 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. Examples of quality parameters in this embodiment include the processing frequency of sensor information (frequency of output to each application), the resolution of image information or point sequence information in the sensor information, and the detection range of the sensor information. Initializing the quality parameters in step S26B sets the quality parameters to the highest quality. The highest 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 determining 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 currently being executed.

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

[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 a 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 a 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 a quality parameter. Here, the number of sensor data is extracted from the sensor information in step S20. The quality parameter is the highest quality parameter initialized in step S26B or a provisional quality parameter received from the quality parameter change unit 18.

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

[0088] Next, a processing flow of the computational resource allocation unit in the on-board electronic control unit 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-board electronic control unit according to the second embodiment shown in Fig. 10.

[0089] 13 , as in the first embodiment (see FIG. 5 ), the computational resource allocation unit 13B receives the estimated amount of required computational resources for each app from the 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 by the first application execution unit 21, the second application execution unit 22, and the third application execution unit 23 (step S120). Next, the computational resource allocation unit 13B adds up the amount of required computational resources for each app to which the provisionally set quality parameters of each app have already been reflected (step S140), and determines whether 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 app 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 app that are 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 to the execution of each app by setting the quality parameters of each app to be final.

[0091] If it is determined in step S150 that the total amount of required computational resources for 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 on the number of times the quality parameters can be 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 to the provisionally set 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). Step S160B involves repeating (looping) steps S140 to S160 of the process flow shown in FIG. 5 executed by the computational resource allocation unit 13 of the first embodiment. That is, the quality parameters are set in descending order, starting with the application with the lowest execution priority, from "1" (highest quality) to "0" (lowest quality), until the total amount of computational resources required for each application according to the provisionally set quality parameters falls within the range of available computational resources. That is, the quality parameters are changed from "1" (highest quality), which indicates execution of the application, to "0" (lowest quality), which indicates suspension of application execution. The computational resource allocation unit 13B sets the quality parameters of each application set in step S160B as final quality parameters and outputs them to the data quality adjustment unit 14 (step S170B).

[0093] If 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 provisionally set quality parameters of each application at the time of the processing to the change priority calculation unit (step S180). This starts the process of changing the provisionally set quality parameters of each application. After executing step S180 or step S170B, the computational resource allocation unit 13B ends the process of this flow.

[0094] Next, a processing flow of the change priority calculation unit in the on-board electronic control unit 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 unit according to the second embodiment shown in Fig. 10. Fig. 15 is a calculation formula table used by the change priority calculation unit of the on-board electronic control unit 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 each app's provisionally set quality parameter using the driving safety level of each app and the provisionally set quality parameters of each app from the computational resource allocation unit 13B. The driving safety level of the vehicle 100 is an index expressed by at least one of the probability of occurrence of a predetermined event (e.g., an event that reduces safety) when each app is executed and the impact on the predetermined event. The driving safety level can be defined, for example, as a function with vehicle driving information and quality parameters as variables. Examples of vehicle driving information include the vehicle speed obtainable from a speed sensor (not shown) in the sensor group 102, driving conditions obtainable from the driving action planning device 103, and driver input operations.

[0096] 14, the change priority calculation unit 17 first receives the provisionally set quality parameters of each app 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 each app's quality parameter on the driving safety level of each app, and a series of processes from steps S350 to S360 for calculating an index indicating the influence of each app's quality parameter on the computational resources required for each app, are executed in parallel. Note that a configuration is also possible 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.

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

[0098] As shown in FIG. 15 , the formula table includes a first column 171 indicating application type information and a second column 172 indicating a calculation formula for the driving safety level of each application. The calculation formula s in the second column 172 is a calculation formula for the driving safety level for a collision mitigation braking application, and is a function that takes, for example, vehicle speed as vehicle driving information and processing frequency as a quality parameter as input. The estimation formula t in the second column 172 is a calculation formula for the driving safety level for a falling object detection application, and is a function that takes, for example, vehicle speed as vehicle driving information and resolution as a quality parameter as input. The estimation formula u in the second column 172 is a calculation formula for the driving safety level for a target tracking application, and is a function that takes, for example, vehicle speed as vehicle driving information, the number of targets detected by the sensor as the number of sensor data, and processing frequency as a quality parameter as input. In the collision mitigation braking application and target tracking application, the amount of change in driving safety level 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 application, the amount of change in the driving safety level in response to a change (downgrade) in the resolution as a quality parameter is calculated.

[0099] The change priority calculation unit 17, in parallel processing, references a formula table having an estimation formula for the amount of computational resources required for each app (step S350), and calculates the amount of change in the amount of computational resources required 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 referenced in step S350 is the required computational resource amount calculation formula table shown in FIG. 12. For the collision damage mitigation braking and target tracking apps, the amount of change in the amount of computational resources required in response to a change (downgrade) in the processing frequency as a quality parameter is calculated. On the other hand, for the falling object detection app, the amount of change in the amount of computational resources required 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 app (step S370). Specifically, using the amount of change in the driving safety level in response to the change in the quality parameters of each app, which is the calculation result of step S340, and the amount of change in the amount of required computational resources in response to the change in the quality parameters of each app, which is the calculation result of step S360, the change priority calculation unit 17 calculates the amount of change in the driving safety level per unit amount of required computational resources in response to the change in the quality parameters of each app. In other words, the change priority of the quality parameters of each app is calculated as the ratio of the calculation result of step S340 to the calculation result of S360.

[0101] The process of changing the provisional quality parameters is performed to optimize the sensor information data quality in a direction that does not reduce the quality. Therefore, it is preferable to prioritize changing quality parameters that result in a small reduction in driving safety and a large reduction in the amount of required computational resources. Therefore, the smaller the change in driving safety per unit amount of required computational resources due to a change in the quality parameter, the higher the priority of the quality parameter change. Therefore, the change in driving safety of each app per unit amount of required computational resources due to a change (downgrade) in the quality parameter can be used as the priority of the quality parameter change.

[0102] The change priority calculation unit 17 outputs the provisionally set change priority of the 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 of 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 each application from the change priority calculation unit 17. The smaller the change priority output by the change priority calculation unit 17, the higher the change priority of the quality parameter.

[0105] 16 , the quality parameter modification unit 18 receives the change priority of the provisionally set quality parameters of each app from the change priority calculation unit 17 (step S410). Next, the provisionally set quality parameter with the highest change priority among the change priorities of the quality parameters of each app is modified (step S420). That is, the quality parameter corresponding to the smallest value among the output values ​​of the change priority calculation unit 17 is modified. The provisionally set quality parameter that results in the smallest change in the driving safety level per unit amount of required computational resources in response to a change in the quality parameter is modified. Next, the quality parameter modification unit 18 outputs the provisionally set quality parameters of each app, including the modified quality parameter, to the computational resource amount estimation unit (step S430). After executing step S430, the quality parameter modification unit 18 terminates 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 progress of changes in the quality parameters of each application during operation of the in-vehicle electronic control device according to the second embodiment.

[0107] In the in-vehicle electronic control unit 1B according to the present 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 in the change process for the quality parameters, a second column indicating the progress of changes in the quality parameters for the collision damage mitigation braking application as the first application, and a third column indicating the progress of changes in the quality parameters for the falling object detection application as the second application. The values ​​of the quality parameters, change priority, and required computational resource amount for 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 indicates that the quality parameters are initialized to "0" in step S26B of the processing flow shown in Fig. 11, and is incremented by "+1" each time a provisional quality parameter is received in step S28B of the processing flow. The table shown in Fig. 17 indicates that the processing in step S28B is executed twice. In other words, the provisional quality parameter change processing is executed twice.

[0109] The quality parameter for the first application in the second column is the frequency of processing sensor information, i.e., the number of times processing is performed 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 amount of computational resources required for the first application according to this quality parameter is 140, based on the calculation result of step S40B in the processing flow shown in FIG. 11. Furthermore, the change priority of the quality parameter for the first application according to this quality parameter is 0.2, based on the calculation result of step S370 in the processing flow shown in FIG. 14. However, this assumes that step S150 in the processing 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, measured in degrees. The initialized quality parameter for the second application is data quality with a resolution of 2 degrees, which is the highest quality. The estimated amount of computational resources required for the second application based on this quality parameter is 110, based on the calculation result of step S40B in the process flow shown in FIG. 12. Furthermore, the change priority of the quality parameter of the second application based on this quality parameter is 0.8, based on the calculation result of step S370 in the process flow shown in FIG. 14. However, this assumes that step S150 in 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 (i.e., the change priority is higher) 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 terms of the number of processes per second from 5 to 2. As a result of changing the quality parameter of the first application, the estimated amount of required computational resources for the first application changes from 140 to 80, as calculated 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, as calculated 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 (i.e., the change priority is higher) than the change priority value of the first application in the second column (1.5). The resolution of the quality parameters of the second application is reduced from 2 degrees to 5 degrees. As a result of changing the quality parameters of the second application, the estimated amount of required computational resources for the second application changes from 110 to 60, as calculated 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, as calculated 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 for the first application (80) and the estimated amount of computational resources required for the second application (60) in the second column falls within the range of available computational resources of the in-vehicle electronic control unit 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, it is possible to allocate computational resources according to the quality parameters set for the app.

[0115] Moreover, the on-board 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 (plurality of applications), using vehicle driving information that is information about 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 (plurality of applications) based on the change priority that is the 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 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 (plurality of applications) exceeds the amount of available computational resources.

[0116] According to this configuration, when the combination of the change priority calculation unit 17 and the quality parameter change unit 18 exceeds the total amount of required 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 avoid a shortage of computational resources in the on-board electronic control unit 1 for the execution of three apps (multiple applications), while allocating (distributing) the computational resources of the on-board electronic control unit 1 to the execution of each app according to the driving conditions of the vehicle 100.

[0117] In addition, the change priority calculation unit 17 of the in-vehicle electronic control unit 1B in this embodiment is configured to calculate the change priority for each of the three apps (multiple applications) based on the 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 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 is possible to change the quality parameter taking into account the driving safety level of each application, thereby making it possible to allocate (distribute) the computational resources of the in-vehicle electronic control unit 1 by changing the quality parameter while suppressing a decrease in the driving safety level of each application.

[0119] In addition, the change priority calculation unit 17 of the in-vehicle electronic control unit 1B in this embodiment is configured to calculate the amount of change in driving safety for 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 for 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 per unit amount of required computational resources when the quality parameters of each application are changed as a provisional setting as the change priority of the quality parameters of each application, it is possible to preferentially change the quality parameters that result in a small decrease in driving safety and a large decrease in the amount of required computational resources. This enables appropriate allocation (distribution) of the computational resources of the in-vehicle electronic control unit 1 to the execution of each application while maintaining high driving safety.

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

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

[0123] [Modification of Second Embodiment] Next, an on-vehicle electronic control device according to a modification of the second embodiment will be described with reference to Figures 18 and 19. Figure 18 is a block diagram showing the hardware configuration and processing function configuration of an on-vehicle electronic control device according to a modification of the second embodiment. Figure 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 modification of the second embodiment shown in Figure 18. Note that in Figures 18 and 19, parts with the same reference numerals as those shown in Figures 1 to 17 are similar parts, and detailed description 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, and 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, and 14C of the in-vehicle electronic control device 1C has been changed, and a functional unit 16 has been added. The rest of the configuration of the in-vehicle electronic control device 1C according to the modified example of the second embodiment is similar to the configuration of the second embodiment.

[0125] Specifically, the in-vehicle electronic control unit 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 the various functions and uses the information collected by the zone ECUs 3 and 4. As with the in-vehicle electronic control unit 1B according to the second embodiment, the zone ECUs 3 and 4 and the integrated ECU 5C each include, as hardware components, a storage device (not shown) including a RAM, a ROM, etc., and a processing device (not shown) including a CPU, an MPU, etc.

[0126] The zone ECUs 3 and 4 each include 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, as well as a sensor data calculation unit 16. Meanwhile, the integrated ECU 5C includes a computational resource amount estimation unit 12C, a computational resource allocation unit 13B, 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 those of 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 amount 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, change priority calculation unit 17, quality parameter change unit 18, first application execution unit 21, second application execution unit 22, and 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 units 11C of the zone ECUs 3 and 4 acquire sensor information related to the target areas of the zone ECUs 3 and 4. The data quality adjustment units 14C of the zone ECUs 3 and 4 adjust 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 units 11C in accordance with quality parameters set for each application. The data quality adjustment units 14C output the sensor information with adjusted data quality to the first application execution unit 21, the second application execution unit 22, and the third application execution unit 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 the integrated ECU 5C, thereby reducing 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 reduced.

[0129] The sensor data calculation units 16 of the zone ECUs 3 and 4 are responsible for receiving sensor information (step S10) and extracting the number of sensor data items 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 amount estimation unit 12B of the on-board electronic control unit 1B according to the second embodiment. On the other hand, the computational resource amount estimation unit 12C of the integrated ECU 5C performs processes other than those performed by the sensor data calculation units 16 of the zone ECUs 3 and 4 among the series of processes shown in FIG. 11 in the computational resource amount estimation unit 12B of the on-board electronic control unit 1B according to the second embodiment. In other words, the combination of the sensor data calculation units 16 of the zone ECUs 3 and 4 and the computational resource amount estimation unit 12C of the integrated ECU 5C corresponds to the computational resource amount estimation unit 12B of the on-board electronic control unit 1B according to the second embodiment.

[0130] 19 , the sensor data calculation units 16 of the zone ECUs 3 and 4 and the computational resource amount estimation unit 12C of the integrated ECU 5C perform the following processing steps: 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 then output the extracted number of pieces of sensor data to the integrated ECU 5C (computational resource amount estimation unit 12C) (step S21C).

[0131] Next, the computational resource amount estimation unit 12C of the integrated ECU 5C acquires the number of pieces of sensor data output by the sensor data calculation units 16 of the zone ECUs 3 and 4 (step S22C). Next, similar to the computational resource amount estimation unit 12B of the in-vehicle electronic control unit 1B according to the second embodiment, the computational resource amount estimation unit 12C determines whether the quality parameters have not yet been set (step S24B). If the computational resource amount estimation unit 12C determines that the quality parameters of each app have not yet been set (Yes), it initializes and provisionally sets the quality parameters of each app (step S26B). On the other hand, if the computational resource amount estimation unit 12C determines that the quality parameters of each app have already been set (No), it receives from the quality parameter change unit 18 the provisionally set quality parameters of each app, including the quality parameters changed by the quality parameter change unit 18 (step S28B). Furthermore, the computational resource amount estimation unit 12C references the calculation formula table shown in FIG. 12 (step S30B) and estimates the amount of computational resources required for each app using the number of pieces of sensor data and the quality parameters for the estimation formula in the calculation formula table (step S40B). The estimated amount of computational resources required for each application 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 sensor data items from the sensor information in the computational resource amount estimation unit 12B of the on-board electronic control unit 1B according to the second embodiment (step S20). This makes it possible to output only information (the number of sensor data items) used to estimate the amount of computational resources required for each app, without outputting the sensor information acquired by the sensor information acquisition unit 11C of the zone ECUs 3 and 4 directly to the integrated ECU 5C. In this modification, only the number of sensor data items from the sensor information is output from the sensor information acquisition unit 11C of the zone ECUs 3 and 4 to the computational resource amount estimation unit 12C of the integrated ECU 5C, thereby reducing the amount of data communication between the zone ECUs 3 and 4 and the integrated ECU 5.

[0133] According to the above-described modification of the second embodiment, similarly to the second embodiment, 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. Therefore, 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] The on-board 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 a sensor group 102 and transfers the sensor information to the data quality adjustment unit 14C. The sensor information, the data quality of which has been adjusted by the data quality adjustment unit 14C, is output to the integrated ECU 5C (second electronic control device). The integrated ECU 5C (second electronic control device) includes a computational resource amount 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 apps (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, thereby reducing the amount of data communication between the zone ECUs 3 and 4 and the integrated ECU 5C compared to when 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-described first and second embodiments and their modifications, but includes various modifications. The above-described embodiments have been described in detail to clearly explain the present invention, and are not necessarily limited to those including all of the described configurations. For example, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, or it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is also possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

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

[0137] Furthermore, in the above-described first and second embodiments and their modifications, the computational resource allocation units 13 and 13B of the in-vehicle electronic control devices 1, 1A, 1B, and 1C are configured to gradually decrease the provisional quality parameters from the highest quality when the total amount of required computational resources estimated based on the provisional quality parameters for each app exceeds the available computational resources. However, the computational resource allocation units can also be configured to gradually decrease the provisional quality parameters from a state lower than the highest quality when the total amount of required computational resources estimated based on the provisional quality parameters for each app exceeds the available computational resources. For example, the computational resource allocation unit is configured to gradually decrease the provisional quality parameters from a data quality of 90%, which represents a low-quality state relative to the highest data quality. In this configuration, the upper limit of the quality parameters set for each app is lower than the highest quality, thereby reducing the computational resources allocated to each app based on the quality parameters. This allows the in-vehicle electronic control device to secure spare computational resources available for emergency control in advance.

[0138] REFERENCE SIGNS LIST 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 amount 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, comprising: a computational resource amount estimation unit that estimates a required computational resource amount, which is the amount of computational resources necessary to execute 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 showing the 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 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 for the execution of each of the plurality of applications, wherein the computational resource allocation unit determines the quality parameter for each of the plurality of applications based on the required computational resource amount estimated in accordance with a provisional setting of the quality parameter for each of the plurality of applications and an available computational resource amount, which is the amount of computational resources that can be used by all of the plurality of applications.

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

3. An in-vehicle electronic control device as described in claim 1, wherein the computational resource allocation unit determines the quality parameters for each of the plurality of applications so that the total amount of required computational resources obtained by adding up the amounts of required computational resources estimated according to the provisionally set quality parameters for each of the plurality of applications falls within the range of the amount of available computational resources.

4. An in-vehicle electronic control device as described in claim 3, wherein the computational resource allocation unit, when the total value of the required amounts of computational resources exceeds the available amount of computational resources, repeatedly reduces one of the tentative quality parameters for each of the multiple applications, and determines the tentative quality parameter when the total value of the required amounts of computational resources falls within the range of the available amount of computational resources as the quality parameter for each of the multiple applications.

5. An in-vehicle electronic control device as described in claim 4, wherein an execution priority indicating an order of priority for execution among the plurality of applications is set in advance, and when the total value of the required amount of computational resources exceeds the available amount of computational resources, the computational resource allocation unit lowers the provisionally set quality parameters in order from the application with the lowest execution priority until the total value of the required amount of computational resources falls within the range of the available amount of computational resources.

6. An in-vehicle electronic control device as described in claim 4, wherein the quality parameter is set to the highest quality of data in the sensor information when obtained from the sensor, and the computational resource allocation unit decreases the provisionally set quality parameter from the highest quality when the total value of the required computational resources exceeds the available computational resources.

7. An in-vehicle electronic control device as described in claim 4, wherein the quality parameter is set to the highest quality of data in the sensor information when obtained from the sensor, and the computational resource allocation unit lowers the provisionally set quality parameter from a state of lower quality than the highest quality when the total value of the required computational resources exceeds the available computational resources.

8. An in-vehicle electronic control device as described in claim 1, further comprising: 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 the vehicle's driving conditions; and 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, which is the calculation result of the change priority calculation unit, wherein the change priority calculation unit and the quality parameter change unit are configured to perform the process when the total value of the required amount of computational resources obtained by adding up the required amount of computational resources estimated in accordance with the provisionally set quality parameters for each of the plurality of applications exceeds the available amount of computational resources.

9. An in-vehicle electronic control device as described in claim 8, wherein 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 the probability of occurrence of a specified event due to execution of each of the plurality of applications and the degree of influence on the specified event, and which has the vehicle driving information and the quality parameter as variables.

10. An in-vehicle electronic control device as described in claim 9, wherein the change priority calculation unit calculates, using the vehicle driving information, an amount of change in the driving safety level of each of the multiple applications when the provisionally set quality parameters for each of the multiple applications are changed, calculates an amount of change in the required amount of computational resources for each of the multiple applications when the provisionally set quality parameters for each of the multiple applications are changed, and calculates, as the change priority for each of the multiple applications, an amount of change in the driving safety level per unit amount of the required amount of computational resources when the provisionally set quality parameters for each of the multiple applications are changed, based on the amount of change in the calculated driving safety level and the amount of change in the calculated required amount of computational resources.

11. An on-vehicle electronic control device as described in claim 1, comprising a first electronic control device and a second electronic control device mounted on a vehicle, wherein the first electronic control device comprises the data quality adjustment unit and a sensor information acquisition unit that acquires the sensor information from the sensor and passes the sensor information to the data quality adjustment unit, and is configured to output the sensor information whose data quality has been adjusted by the data quality adjustment unit to the second electronic control device, and the second electronic control device comprises the computational resource amount estimation unit and 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 each of the plurality of applications.

12. An on-vehicle electronic control device as described in claim 8, comprising a first electronic control device and a second electronic control device mounted on the vehicle, wherein the first electronic control device comprises the data quality adjustment unit and a sensor information acquisition unit that acquires the sensor information from the sensor and passes the sensor information to the data quality adjustment unit, and is configured to output the sensor information whose data quality has been adjusted by the data quality adjustment unit to the second electronic control device, and the second electronic control device comprises the computational resource amount estimation unit, the computational resource allocation unit, the change priority calculation unit, the quality parameter change unit, and a plurality of app execution units that receive the sensor information output from the first electronic control device and execute the plurality of applications, respectively.

Images