In-vehicle device, server device, resource control method, resource control support method, and computer program

Abstract

This in-vehicle device comprises: a communication unit that communicates with an external device; an information acquisition unit that acquires, via the communication unit, actual performance information indicating the amount of resource consumed by a non-host vehicle when the non-host vehicle traveled in a host vehicle's planned travel area, the non-host vehicle being a vehicle other than the host vehicle; an estimation unit that estimates, on the basis of the actual performance information acquired by the information acquisition unit, the amount of resource that is consumed when the host vehicle travels in the planned travel area and varies over time as the host vehicle travels; and a resource control unit that controls the resource consumption by allocating an execution period of predetermined application software to a specific period according to the estimation result from the estimation unit.

Description

[Technical Field]

[0001] The present disclosure relates to an in-vehicle device, a server device, a resource control method, a resource control support method, and a computer program. This disclosure claims priority to Japanese Patent Application No. 2022-116047 filed on July 21, 2022, and incorporates all of the contents of that Japanese application by reference. [Background technology]

[0002] Next-generation connected services, which enable high-speed, large-capacity communications, will increase the amount of data communicated between vehicles and external devices. This will lead to an increase in the range of temporal fluctuations in resource consumption (e.g., consumption of communication resources or computational resources) in on-board devices installed in vehicles.

[0003] In such a situation, services may not be able to meet the allowable delay time during periods of high load, when the amount of communication data reaches its peak. If the in-vehicle device is equipped with a high-performance processor that can handle high loads, it may be possible to prevent services from failing to meet the allowable delay time even under high loads. However, this would result in over-specification and increase the cost of the in-vehicle device.

[0004] As a technique for preventing a decrease in system responsiveness under high load, Patent Document 1 (see below) proposes a technology related to an automotive electronic control unit that dynamically allocates processor cores to process tasks and distributes the load. The automotive electronic control unit in Patent Document 1 is equipped with a multi-core processor that integrates multiple processor cores. When a task related to interrupt processing occurs in response to a change in driving conditions, the automotive electronic control unit executes a first distributed process that distributes the load of the task according to the load status of the multiple processor cores. The automotive electronic control unit further executes a second distributed process that predicts changes in driving conditions when the engine speed is below a predetermined value and distributes the load of tasks affected by the prediction result according to the load status of the multiple processor cores. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Publication No. 2019-109744 Summary of the Invention

[0006] An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device mounted on a vehicle, and includes a communication unit that communicates with an external device, an information acquisition unit that acquires, via the communication unit, historical information on resource consumption of other vehicles other than the host vehicle when the other vehicles travel through an area in which the host vehicle is scheduled to travel, an estimation unit that estimates, based on the historical information acquired by the information acquisition unit, the resource consumption that varies over time as the host vehicle travels through the area in which the host vehicle is scheduled to travel, and a resource control unit that controls resource consumption by allocating the execution period of specified application software to a specified period in accordance with the estimation result of the estimation unit.

[0007] The present disclosure can be realized not only as an in-vehicle device, a server device, a resource control method, a resource control support method, and a computer program including such characteristic configurations, but also as a storage medium recording a program for causing a computer to execute the characteristic steps executed by the in-vehicle device or the server device, or as other systems or devices including the in-vehicle device or the server device. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram illustrating the overall configuration of a system according to the first embodiment. [Figure 2] FIG. 2 is a diagram for explaining a vehicle in which the on-board device shown in FIG. 1 is installed. [Figure 3] FIG. 3 is a diagram for explaining the dynamic map. [Figure 4] FIG. 4 is a diagram for explaining resource control executed in the in-vehicle device shown in FIG. [Figure 5] FIG. 5 is a diagram for explaining resource control executed in the in-vehicle device shown in FIG. [Figure 6] FIG. 6 is a diagram for explaining a method for creating a resource consumption result map in the server device shown in FIG. [Figure 7] FIG. 7 is a diagram showing an example of the content of the resource consumption amount result map. [Figure 8] FIG. 8 is a block diagram illustrating an example of a functional configuration of the in-vehicle device illustrated in FIG. [Figure 9] FIG. 9 is a block diagram showing an example of a hardware configuration of the in-vehicle device (GW (Gateway) device) shown in FIG. [Figure 10] FIG. 10 is a block diagram illustrating an example of a hardware configuration of the server device illustrated in FIG. [Figure 11] FIG. 11 is a block diagram illustrating an example of a functional configuration of the server device illustrated in FIG. [Figure 12] FIG. 12 is a flowchart illustrating an example of a control structure of a program executed in the in-vehicle apparatus according to the first embodiment. [Figure 13] FIG. 13 is a flowchart illustrating an example of a control structure of a program executed by the server device according to the first embodiment. [Figure 14] FIG. 14 is a flowchart showing an example of a control structure of a program executed by the server device in accordance with the first modification. [Figure 15] FIG. 15 is a flowchart showing an example of a control structure of a program executed in the in-vehicle device according to the second modification. [Figure 16] FIG. 16 is a flowchart showing an example of a control structure of a program executed by the server device in accordance with the second modification. [Figure 17] FIG. 17 is a flowchart showing an example of a control structure of a program executed in the in-vehicle device according to the third modification. [Figure 18]FIG. 18 is a flowchart showing an example of a control structure of a program executed by the server device in accordance with the third modification. [Figure 19] FIG. 19 is a flowchart showing an example of a control structure of a program executed by the server device in accordance with the fourth modification. [Figure 20] FIG. 20 is a flowchart showing an example of a control structure of a program executed in an in-vehicle device according to the fourth modification. [Figure 21] FIG. 21 is a diagram illustrating the configuration of an in-vehicle device according to the second embodiment. [Figure 22] FIG. 22 is a block diagram showing an example of a functional configuration of the in-vehicle device (GW device) shown in FIG. [Figure 23] FIG. 23 is a flowchart illustrating an example of a control structure of a program executed by the in-vehicle apparatus according to the second embodiment. [Figure 24] FIG. 24 is a block diagram illustrating an example of a functional configuration of a server device according to the third embodiment. [Figure 25] FIG. 25 is a block diagram illustrating an example of a functional configuration of an in-vehicle device (GW device) according to the third embodiment. [Figure 26] FIG. 26 is a flowchart illustrating an example of a control structure of a program executed by the server device in accordance with the third embodiment. [Figure 27] FIG. 27 is a flowchart illustrating an example of a control structure of a program executed by the in-vehicle apparatus according to the third embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] [Problem to be solved by this disclosure] The technology disclosed in Patent Document 1 predicts changes in driving conditions and dynamically allocates tasks to multiple processor cores. This eliminates high load conditions caused by interrupt processing in response to changes in driving conditions. However, it is difficult to predict load increases due to communication with the outside of the vehicle from changes in driving conditions. Therefore, with the technology disclosed in Patent Document 1, there is a risk that service responsiveness will decrease when there is a high load due to communication with the outside of the vehicle.

[0010] The present disclosure has been made to solve the above-mentioned problems, and one purpose of the present disclosure is to provide an in-vehicle device, a server device, a resource control method, a resource control support method, and a computer program that are capable of suppressing a decrease in responsiveness even under high load caused by communication with outside the vehicle.

[0011] [Effects of this disclosure] According to the present disclosure, it is possible to provide an in-vehicle device, a server device, a resource control method, a resource control support method, and a computer program that are capable of suppressing a decrease in responsiveness even under high load caused by communication with the outside of the vehicle.

[0012] [Description of the embodiments of the present disclosure] Preferred embodiments of the present disclosure will be described below. At least some of the embodiments described below may be combined in any combination.

[0013] (1) An in-vehicle device according to a first aspect of the present disclosure is an in-vehicle device mounted on a vehicle, and includes: a communication unit that communicates with an external device; an information acquisition unit that acquires, via the communication unit, historical information on resource consumption of other vehicles, other than the subject vehicle, when the other vehicles travel in an area where the subject vehicle is scheduled to travel; an estimation unit that estimates, based on the historical information acquired by the information acquisition unit, the resource consumption that varies over time as the subject vehicle travels in the area where the subject vehicle is scheduled to travel; and a resource control unit that controls resource consumption by allocating the execution period of a specified application software to a specified period according to the estimation result of the estimation unit.

[0014] The information acquisition unit acquires historical information on resource consumption of other vehicles when the other vehicles, other than the host vehicle, travel through the planned travel area of the host vehicle. Based on the acquired historical information, the estimation unit estimates the resource consumption that varies over time as the host vehicle travels. That is, based on the historical information, predicts an increase in load due to communication with an external device when the host vehicle travels through the planned travel area. The resource control unit controls resource consumption by, for example, allocating the execution period of specified application software to a period that avoids high load times. This allows the in-vehicle device to suppress a decrease in responsiveness even during high load times due to communication with an external device. In addition, it is possible to suppress the occurrence of services that do not satisfy the allowable delay time without installing a high-performance processor in the in-vehicle device. As a result, it is possible to suppress a decrease in responsiveness while suppressing an increase in the cost of the in-vehicle device.

[0015] (2) In the above (1), the estimation unit may estimate, for each travel section, resource consumption that varies depending on the travel section in the planned travel area, including resource consumption due to the execution of application software that requires real-time processing. The resource control unit may control resource consumption by allocating an execution period for application software that does not require real-time processing to a predetermined period based on the estimation result of the estimation unit. This configuration allows the execution period for application software that does not require real-time processing to be allocated to a period when resources are available. In other words, it is possible to prevent application software that does not require real-time processing from being executed during a period when resource consumption increases due to the execution of application software that requires real-time processing. This allows the execution periods of application software to be distributed, thereby easily preventing a decrease in responsiveness during high load situations due to communication with the outside of the vehicle. Note that whether application software requires real-time processing can be determined, for example, based on whether an allowable communication delay time is equal to or less than a predetermined threshold.

[0016] (3) In the above (1) or (2), the external device may include a server device that collects resource consumption performance information from multiple other vehicles and creates a resource consumption performance map in which resource consumption performance is set for travel sections in the planned travel area based on the collected performance information, the information acquisition unit may acquire the resource consumption performance map from the server device via the communication unit as performance information, and the estimation unit may estimate the resource consumption for each travel section in the planned travel area based on the resource consumption performance map. With this configuration, it is possible to easily estimate resource consumption that varies over time as the host vehicle travels. In other words, it is possible to easily predict a load increase due to communication with an external device when the host vehicle travels in the planned travel area.

[0017] (4) In the above (1) or (2), the external device may include an on-board device mounted on another vehicle other than the host vehicle, and the information acquisition unit may acquire, via the communication unit, historical resource consumption information for the planned travel area from the on-board device of the other vehicle that has traveled through the planned travel area of the host vehicle, and the estimation unit may estimate the resource consumption for each travel section in the planned travel area based on the historical resource consumption information acquired from the on-board device of the other vehicle. This also makes it possible to easily estimate the resource consumption that fluctuates over time as the host vehicle travels. Therefore, it is possible to easily suppress a decrease in responsiveness during high loads caused by communication with an external vehicle.

[0018] (5) In any of (1) to (4) above, the resource control unit may be configured to allocate an execution period of application software that does not require real-time processing to a planned driving period for a driving section in which the ratio of the resource consumption estimated by the estimation unit to the resource usage upper limit is equal to or less than a predetermined value. This makes it possible to easily set the execution period of application software that does not require real-time processing to a period other than a high load period.

[0019] (6) In the above (5), the predetermined value may be set based on the resource consumption of application software that does not require real-time performance. This allows the execution period of the application software that does not require real-time performance to be set during a period in which resources for executing the application software that does not require real-time performance are secured.

[0020] (7) In any of (1) to (6) above, the performance information may be configured to include quantized information that is set for each travel section of the planned travel area and that is obtained by quantizing the performance values of resource consumption of other vehicles that have traveled through the planned travel area into multiple levels. That is, quantized information is set for each travel section of the planned travel area, and the performance information includes this quantized information. This reduces the amount of data in the performance information, making it easier for the information acquisition unit to acquire the performance information.

[0021] (8) In any of the above (1) to (7), the information acquisition unit may be configured to acquire the performance information before the host vehicle enters the planned travel area. For example, the information acquisition unit may be configured to acquire the performance information immediately before entering the planned travel area, or several seconds to several minutes before. This makes it possible to predict, before entering the planned travel area, an increase in load due to communication with an external device when the host vehicle travels through the planned travel area.

[0022] (9) In any of the above (1) to (8), the information acquisition unit may be configured to request the external device to transmit the performance information before the host vehicle enters the planned travel area. This allows the host vehicle to acquire the performance information before entering the planned travel area.

[0023] (10) In any of (1) to (9) above, the performance information may be added with time information indicating the date and time when the performance information was created, and the estimation unit may compare the date and time indicated by the time information with the current date and time and estimate the resource consumption amount that varies over time as the vehicle travels based on the comparison result. This allows the resource consumption amount to be estimated using performance information that was created most recently, thereby improving the accuracy of the resource consumption amount estimation.

[0024] (11) A server device according to a second aspect of the present disclosure is a server device capable of communicating with an in-vehicle device mounted on a vehicle, and includes: an information collection unit that collects historical resource consumption information from a plurality of vehicles; an historical resource consumption map creation unit that receives information about the planned travel area from the in-vehicle device and creates a historical resource consumption map in which the resource consumption historical data is set for the travel section of the planned travel area based on the historical resource consumption information collected by the information collection unit; an execution period extraction unit that extracts, based on the resource consumption historical resource consumption map, a recommended execution period that recommends the execution of application software that does not require real-time processing during the travel period of the planned travel area; and a notification unit that notifies the in-vehicle device that sent the information about the planned travel area of the recommended execution period extracted by the execution period extraction unit.

[0025] The server device collects resource consumption performance information from multiple vehicles and creates a resource consumption performance map. Based on the created resource consumption performance map, the server device extracts recommended execution periods for recommending execution of application software that does not require real-time performance, and notifies the in-vehicle device of the extracted recommended execution periods. The in-vehicle device distributes the execution periods of the application software by allocating the execution periods of the application software that does not require real-time performance to the recommended execution periods. This allows the in-vehicle device to easily suppress a decrease in responsiveness during high loads caused by communication with the outside of the vehicle. In this way, by notifying the in-vehicle device of the recommended execution periods of the application software that does not require real-time performance, the server device can enable the in-vehicle device to suppress a decrease in responsiveness during high loads caused by communication with the outside of the vehicle.

[0026] Server according to another aspect of the present disclosure Device is a server device capable of communicating with an on-board device mounted in a vehicle, and includes an information collection unit that collects actual resource consumption information from a plurality of vehicles, an actual resource consumption map creation unit that creates a resource consumption actual map in which actual resource consumption results are set for driving sections in a predetermined area based on the actual resource information collected by the information collection unit, and a distribution unit that distributes the resource consumption actual map created by the actual resource consumption map creation unit to the on-board device. By distributing the resource consumption actual map to the on-board device, the server device can support the on-board device in a vehicle equipped with the on-board device so as to suppress a decrease in responsiveness during high load times caused by communication with the outside of the vehicle.

[0027] (12) A resource control method according to a third aspect of the present disclosure is a resource control method for an in-vehicle device mounted on a vehicle, the resource control method including the steps of: acquiring, by the in-vehicle device, through a communication unit that communicates with an external device, historical information on resource consumption of another vehicle other than the subject vehicle when the other vehicle travels in a planned travel area of the subject vehicle; estimating, by the in-vehicle device, the resource consumption that varies over time as the subject vehicle travels in the planned travel area based on the historical information acquired in the acquiring step; and controlling resource consumption by the in-vehicle device by allocating, by the in-vehicle device, the execution period of predetermined application software to a predetermined period in accordance with the estimation result in the estimating step. This allows the in-vehicle device to suppress a decrease in responsiveness even under high load caused by communication with outside the vehicle.

[0028] (13) A resource control support method according to a fourth aspect of the present disclosure is a resource control support method executed by a server device capable of communicating with an on-board device mounted in a vehicle, and supporting control of resource consumption in the vehicle, the resource control support method including the steps of: the server device collecting historical resource consumption information from a plurality of vehicles; the server device receiving information about a planned travel area from the on-board device and creating a resource consumption historical map in which historical resource consumptions are set for travel sections of the planned travel area based on the historical information collected in the collecting step; the server device extracting, based on the resource consumption historical map, a recommended execution period during which application software that does not require real-time processing is executed during the travel period of the planned travel area; and the server device notifying the on-board device that transmitted the information about the planned travel area of the recommended execution period extracted in the extracting step. This helps the on-board device to suppress a decrease in responsiveness during high loads caused by communication with outside the vehicle.

[0029] (14) A computer program according to a fifth aspect of the present disclosure causes a computer mounted on a vehicle to function as: a communication unit that communicates with an external device; an information acquisition unit that acquires, via the communication unit, historical information on resource consumption of other vehicles when the other vehicles, other than the host vehicle, travel through an area where the host vehicle is scheduled to travel; an estimation unit that estimates resource consumption that varies over time as the host vehicle travels through the area where the host vehicle is scheduled to travel based on the historical information acquired by the information acquisition unit; and a resource control unit that controls resource consumption by allocating execution periods of predetermined application software to predetermined periods in accordance with the estimation results of the estimation unit. This makes it possible to suppress a decrease in responsiveness during high loads caused by communication with outside the vehicle.

[0030] (15) A computer program according to a sixth aspect of the present disclosure causes a computer to function as an information collecting unit that collects resource consumption performance information from multiple vehicles, an performance map creating unit that receives information about a planned travel area from an in-vehicle device and creates a resource consumption performance map in which resource consumption performance is set for travel sections of the planned travel area based on the performance information collected by the information collecting unit, an execution period extracting unit that extracts, based on the resource consumption performance map, a recommended execution period for recommending the execution of application software that does not require real-time processing during a travel period in the planned travel area, and a notification unit that notifies the in-vehicle device that has transmitted the information about the planned travel area of the recommended execution period extracted by the execution period extracting unit. This can help the in-vehicle device to suppress a decrease in responsiveness during high loads caused by communications with outside the vehicle.

[0031] [Details of the embodiments of the present disclosure] Specific examples of an in-vehicle device, a server device, a resource control method, a resource control support method, and a computer program according to embodiments of the present disclosure will be described below with reference to the drawings. Note that in the following embodiments, identical components are assigned the same reference numerals. Their functions and names are also identical. Therefore, detailed descriptions thereof will not be repeated.

[0032] (First embodiment) [Overall configuration] 1, a system 30 according to this embodiment includes an on-vehicle device 200 mounted on a vehicle 100, and a server device 500 that communicates with the on-vehicle device 200. The server device 500 is an external device (infrastructure device) that is installed outside the vehicle. The server device 500 may be a cloud server or an edge server. The number of vehicles (on-vehicle devices) that communicate with the server device 500 is not limited to one, and may be multiple.

[0033] This system 30 predicts a load increase in the vehicle 100 due to communication with the outside of the vehicle, and schedules the execution periods of predetermined application software (hereinafter, "application software" will be simply referred to as "apps"). The server device 500 provides the in-vehicle device 200 with a resource consumption record map, which will be described later, to support the prediction of a load increase in the in-vehicle device 200. Based on the resource consumption record map provided by the server device 500, the in-vehicle device 200 predicts a load increase due to communication with the outside of the vehicle, and allocates the execution period of the predetermined app to a period when resources are available. In this way, by distributing the execution periods of the apps, the in-vehicle device 200 suppresses a decrease in responsiveness even under high load due to communication with the outside of the vehicle.

[0034] 2, the in-vehicle device 200 can also communicate with server devices (infrastructure devices 50) other than the server device 500 constituting the present system 30. The vehicle 100 on which the in-vehicle device 200 is mounted is equipped with various sensors such as a millimeter-wave radar 110, an in-vehicle camera 112, and a LiDAR (Laser Imaging Detection and Ranging) 114 in addition to the in-vehicle device 200. The in-vehicle device 200, for example, collects sensor data from these sensors and wirelessly transmits the data to the infrastructure device 50, and receives various information including a dynamic map from the infrastructure device 50.

[0035] The infrastructure device 50 receives sensor data transmitted from on-board sensors mounted on vehicles, roadside sensors mounted on roadside devices, etc., and creates a dynamic map to be used for safe driving support, etc. The infrastructure device 50 distributes the created dynamic map to vehicles.

[0036] 3, the dynamic map 60 is created by detecting moving objects in a real space 62 using a number of sensors such as LiDAR and cameras, estimating their attributes (adult, child, vehicle, motorcycle, etc.), and using high-resolution road map data prepared in advance in a virtual space. The dynamic map 60 includes dynamic information such as information on surrounding vehicles and pedestrians, semi-dynamic information such as information on accidents and congestion, semi-static information such as information on scheduled traffic regulations or road construction, and static information such as road surface information and lane information (high-precision three-dimensional map information).

[0037] 2, the in-vehicle device 200 receives various information including a dynamic map from the infrastructure device 50, and provides various information such as safe driving assistance to the passenger based on the received information. The infrastructure device 50 may be configured to remotely monitor (remote monitoring) the vehicle 100 in which the in-vehicle device 200 is installed, or remotely control (remote control) the vehicle 100, as necessary.

[0038] By connecting to the infrastructure device 50, the in-vehicle device 200 of the vehicle 100 can provide various services such as safe driving assistance to the passengers of the vehicle 100. The provision of these services is realized in the in-vehicle device 200 by executing a service app in the in-vehicle device 200.

[0039] The services provided may depend on the location characteristics of the driving area. For example, near an intersection, the in-vehicle device 200 downloads a dynamic map to provide the driver with blind spot information about right-turning vehicles, pedestrians, etc. Also, in a place with a lot of people or traffic jams, the in-vehicle device 200 uploads sensor data collected by the vehicle to the infrastructure device 50, which creates a dynamic map.

[0040] Therefore, depending on the area in which the vehicle 100 is traveling, the execution of a service app that communicates with the infrastructure device 50 increases resource consumption in the vehicle 100 due to communication with the infrastructure device 50 outside the vehicle. In other words, resource consumption increases when the vehicle 100 enters an area where communication with the outside of the vehicle is required. In such a situation, the resource consumption in the vehicle 100 not only increases but also fluctuates over time as the vehicle 100 travels. Therefore, if the temporal fluctuation in resource consumption can be predicted when traveling in such an area, it becomes easier to deal with the high load caused by communication with the outside of the vehicle.

[0041] Referring again to FIG. 1, in this embodiment, the resource consumption amount record map described above is used to predict temporal fluctuations in resource consumption. The resource consumption amount record map is a map that indicates how much resources have actually been consumed at which locations (sections) based on the resource consumption amount records of a preceding vehicle (a vehicle other than the host vehicle) that has traveled through the planned travel area of the host vehicle. The planned travel area can be, for example, a specific area where temporal fluctuations in resource consumption occur. In this case, the server device 500 that provides the resource consumption amount record map can be configured to create a resource consumption amount record map for the specific area and provide the created resource consumption amount record map to a vehicle that is entering the specific area as its planned travel area.

[0042] The in-vehicle device 200 predicts temporal fluctuations in resource consumption by referring to the resource consumption record map. In addition, the in-vehicle device 200 estimates the resource consumption that fluctuates over time as the vehicle 100 travels, based on the traveling speed of the vehicle 100 when traveling in the planned travel area. This allows the in-vehicle device 200 to predict a period when resources are available, and the in-vehicle device 200 allocates an execution period for a predetermined application to a period when resources are available. The predetermined application is, for example, an application that is not subject to time constraints for processing execution.

[0043] [Service app example] Applications that communicate with the outside of the vehicle and are executed on the in-vehicle device 200 can be classified into real-time applications (also called "high real-time applications") that require real-time processing to be executed, and non-real-time applications that do not require real-time processing to be executed.

[0044] Real-time applications require real-time performance, and therefore have constraints on their execution timing. On the other hand, non-real-time applications do not require real-time performance, and therefore have no constraints on their execution timing. Therefore, whether an application is real-time or non-real-time can be determined by whether real-time performance is required, i.e., whether there are constraints on the execution timing. Specifically, whether an application is real-time or non-real-time can be determined by, for example, whether there is an allowable delay time for the application, or whether the allowable delay time is equal to or less than a predetermined threshold.

[0045] Real-time applications can be classified into three groups based on their resource consumption: (1) Group 1: Resource Consumption (High) This group includes, for example, real-time applications that perform remote control and remote monitoring of a vehicle, and processes for uploading sensor data from sensors mounted on the vehicle to a server device (infrastructure device) for dynamic map construction. (2) Second group: Medium resource consumption This group includes, for example, real-time applications that execute download processing (for example, every few hundred ms) of dynamic maps for sharing dynamic information (blind spot information). (3) The third group: Resource consumption (low) This group includes, for example, real-time applications that perform probe information upload processing (for example, every few minutes).

[0046] Non-real-time applications include, for example, applications that perform download processing for static map updates, upload processing of vehicle information for fault diagnosis, and the like.

[0047] [Example of resource consumption estimation] 4, the on-board device 200 of the vehicle 100 estimates the resource consumption for each travel section in the planned travel area 32 based on the resource consumption result map. In Fig. 4, the upper diagram shows the resource consumption result map, and the lower diagram shows the temporal fluctuation of the resource consumption estimated based on the resource consumption result map.

[0048] In the resource consumption performance map, the area with "resource consumption: low" can be recognized as an area where, for example, real-time applications belonging to the third group that perform processes such as uploading probe information are mainly executed, the area with "resource consumption: medium" can be recognized as an area where, for example, real-time applications belonging to the second group that perform processes such as downloading dynamic maps are mainly executed, and the area with "resource consumption: high" can be recognized as an area where, for example, real-time applications belonging to the first group that perform processes such as uploading sensor data are mainly executed.

[0049] The in-vehicle device 200 estimates the amount of resource consumption required when the real-time applications belonging to each group are executed in the vehicle, for example. The resource consumption is estimated for each target resource (target resource), for example. The target resource may be, for example, a communication band (wireless or wired), a processor, or a memory. The estimated resource consumption is assigned to the driving time period of each area on the resource consumption record map, thereby obtaining the diagram shown in the lower part of FIG. 4, which shows the temporal fluctuation of resource consumption associated with driving.

[0050] [Scheduling non-real-time apps] Referring to Fig. 5, it is possible to predict a period in which resources are available based on the resource consumption estimation result. For example, if resource consumption is quantized into multiple stages (here, as an example, three stages of "high," "medium," and "low" corresponding to the first to third groups of real-time applications), the periods in which resource consumption is "medium" and "low" may be predicted as periods in which resources are available. As described above, non-real-time applications have no constraints on execution timing, and therefore can be scheduled. Therefore, the execution periods of non-real-time applications are assigned to periods predicted to have available resources.

[0051] The prediction of the period when resources are available may be based on the ratio of estimated resource consumption to the resource usage upper limit. Specifically, the period when the ratio of estimated resource consumption to the resource usage upper limit is equal to or less than a predetermined threshold X [%] may be determined as the period when resources are available. The threshold X [%] may be set, for example, to 50%. The value of the threshold X [%] may be set based on the resource consumption of non-real-time applications. In this way, the value of the threshold X [%] is set so that there are enough resources remaining to reliably execute non-real-time applications.

[0052] [Creating a resource consumption performance map] 6, server device 500 collects, from preceding vehicles, actual resource consumption values for each real-time application in a travel area (a planned travel area for the vehicle itself). Each preceding vehicle transmits travel actual information (e.g., location information, time information, and resource consumption (observation results)) when traveling through the travel area (planned travel area) to server device 500 as upload information. Server device 500 creates a resource consumption actual map based on the collected information and updates it periodically (e.g., every few minutes) or irregularly.

[0053] Fig. 7 is a diagram showing an example of the content of a resource consumption amount result map. Fig. 7 shows an example of the content of the resource consumption amount result map in a tabular format, but the format does not have to be a tabular format. Referring to Fig. 7, the table showing the content of the resource consumption amount result map includes columns for "Area (section)", "Real-time application", "Execution period (milliseconds)", "Tolerable delay (milliseconds)", "Target resource", "Resource consumption amount [numerical value]", "Resource consumption amount [determination result]", and "Remarks".

[0054] The "Area (Section)" column stores the section specified by the location information. The "Real-time Application" column stores the identification number of the real-time application executed in each area (section). The "Execution Period (milliseconds)" column stores the execution period of the real-time application. The "Allowable Delay (milliseconds)" column stores the allowable delay time of the real-time application. The "Target Resource" column stores the target resource items: "Communication Bandwidth," "Processor," and "Memory." The "Resource Consumption [Numeric Value]" column stores the actual resource consumption value for each target resource item. The "Resource Consumption [Judgment Result]" column stores quantization information obtained by quantizing the actual resource consumption value into N levels. For example, if the actual resource consumption value is quantized into three levels, one of "High," "Medium," or "Low" is stored. The "Notes" column stores additional notes as needed.

[0055] The table shown in FIG. 7 is created as performance data for a predetermined period. The time information included in the driving performance information is used to determine whether the information is for a predetermined period. A time information column may be added to the table shown in FIG. 7 so that each record has time information. Furthermore, since vehicle speed information can be calculated from time information and location information, a speed information column may be added to the table shown in FIG. 7 so that each record has speed information. The resource consumption performance map may also have time information added to indicate the date and time when the resource consumption performance map was created.

[0056] The server device 500 (see FIG. 6) may be configured to appropriately statistically process and use the contents of the table shown in FIG. 7. For example, the values stored in the "resource consumption [numerical value]" column may be obtained by statistically processing (averaging) observed values of multiple preceding vehicles, or by statistically processing (averaging) time fluctuations due to the execution period of a real-time application.

[0057] In addition, driving performance information may be collected from each vehicle, regardless of whether it is a preceding vehicle or not, and information corresponding to the information on the preceding vehicle may be extracted from the collected information to create or update a resource consumption performance map.

[0058] [Configuration of In-Vehicle Device 200] 8, the in-vehicle device 200 includes an in-vehicle GW device 210 and an exterior wireless device 300. In addition to the GW device 210, the vehicle 100 is equipped with an in-vehicle network 400, which is a communication network including various sensors and various ECUs (Electronic Control Units). Typically, a vehicle is equipped with multiple in-vehicle networks. In FIG. 8, the in-vehicle network 400 is illustrated as a representative of the multiple in-vehicle networks, and the other in-vehicle networks are not illustrated.

[0059] The GW device 210 interconnects multiple in-vehicle networks, including the in-vehicle network 400, and organizes data exchange between the in-vehicle networks. The in-vehicle network 400 includes a sensor group 410 including various sensors, and an ECU group 420 including various ECUs. If the vehicle 100 has an autonomous driving function, the ECU group 420 includes an autonomous driving ECU.

[0060] The GW device 210 further includes, as functional units, an information acquisition unit 220, a resource management unit 230, and a cooperation mediation unit 240. The information acquisition unit 220 acquires, via the exterior radio device 300, actual information on the amount of resources consumed in the planned travel area of another vehicle (preceding vehicle) that has traveled through the planned travel area of the host vehicle (vehicle 100). In other words, the information acquisition unit 220 acquires, via the exterior radio device 300, actual information on the amount of resources consumed in the planned travel area of the other vehicle (preceding vehicle) that has traveled through the planned travel area of the host vehicle (vehicle 100). R The information acquisition unit 220 acquires actual resource consumption information. In this embodiment, the information acquisition unit 220 acquires a resource consumption actual map from the server device 500 as actual information. The resource management unit 230 manages resource consumption of the host vehicle. The resource management unit 230 includes a resource consumption estimation unit 232 and a resource control unit 234. The resource consumption estimation unit 232 estimates resource consumption that varies over time as the host vehicle travels through the planned travel area, based on the resource consumption actual map acquired by the information acquisition unit 220. The resource control unit 234 allocates the execution period of a predetermined application to a predetermined period according to the estimation result of the resource consumption estimation unit 232. Specifically, as described above, the resource control unit 234 allocates the execution period of a non-real-time application to a period in which resources are predicted to be available.

[0061] The collaboration mediation unit 240 is a functional unit (application) that mediates collaboration between an end ECU and a server device (infrastructure device). The collaboration mediation unit 240, for example, acquires or updates information on a dynamic map and transfers it to an end ECU (for example, an autonomous driving ECU).

[0062] The exterior-vehicle radio device 300 includes multiple wireless interfaces (hereinafter, "interfaces" will be abbreviated as "IFs") that perform wireless communication with the exterior of the vehicle. The multiple wireless IFs include, for example, a wireless IF 310 for performing cellular communication with an external device (exterior-vehicle device) using 5G (fifth-generation mobile communication system) or LTE (Long Term Evolution), a wireless IF 320 for performing wireless communication with an external device using C-V2X (Cellular Vehicle to Everything), and other wireless IFs 330. An example of the other wireless IFs 330 is local 5G. Note that the wireless IFs included in the exterior-vehicle radio device 300 are not limited to these, and may be other types. Furthermore, the number of wireless IFs included in the exterior-vehicle radio device 300 is not limited to these.

[0063] There are various wireless interfaces that correspond to each communication method. As communication methods, cellular communication (4G (LTE) / 5G) and LPWA (Low Power Wide Area) are known for wide-area communication, while DSRC (Dedicated Short Range Communications) and C-V2X are known for short-range communication. Furthermore, there are local communication methods such as WiFi and local 5G for communication between wide and short areas. Local 5G differs from cellular 5G in that it is operated independently by companies or local governments other than telecommunications carriers.

[0064] [Resource Management in Vehicle 100] The resource management targets (target resources) include communication resources and computational resources. The communication resource management targets include the wired communication band between the in-vehicle network 400 and the GW device 210, the wireless communication band for communication between the in-vehicle device 200 and an external device (e.g., infrastructure device 50, etc.), and relay processing or end processing. The computational resource management targets include a processor and a memory. The observation area of each resource is the communication band (wired / wireless) as the communication link, and the processor and memory as the application execution area.

[0065] [Hardware configuration] 《GW device 210》 9, GW device 210 mounted on vehicle 100 includes a computer 212. Computer 212 includes a control unit 250 that controls the entire GW device 210, a storage device 260 that stores various data, an in-vehicle network communication unit 270 that communicates with an in-vehicle network, and a communication IF 280 that communicates with external wireless device 300. Control unit 250, storage device 260, in-vehicle network communication unit 270, and communication IF 280 are all connected to a bus 290, and data exchange between them is performed via bus 290.

[0066] The control unit 250 includes an arithmetic unit 252, a read-only memory (ROM) 254 that stores a boot-up program and the like for the computer 212, and a random-access memory (RAM) 256 that can be written to and read from at any time. The arithmetic unit 252 includes, as an arithmetic element (processor), a central processing unit (CPU) or a micro processing unit (MPU). The storage device 260 includes, for example, a nonvolatile memory such as a flash memory. The ROM 254 or the storage device 260 stores software (computer programs) executed by the arithmetic unit 252 and various information (data).

[0067] A computer program for causing the GW device 210 to function as each functional unit of the GW device 210 according to the present disclosure is stored in a predetermined storage medium such as a DVD (Digital Versatile Disc) or a USB (Universal Serial Bus) memory, distributed, and then transferred from the storage medium to the storage device 260. Alternatively, the computer program may be transmitted to the computer 212 from an external device via wireless communication with the outside of the vehicle and stored in the storage device 260.

[0068] The functions of the functional units of the GW device 210 are realized by software processing executed by the control unit 250 using hardware. Some or all of these functions may be realized by an integrated circuit including a microcomputer.

[0069] The in-vehicle network communication unit 270 provides an IF for communicating with the in-vehicle network. The in-vehicle network communication unit 270 communicates with the in-vehicle network in accordance with a communication protocol such as CAN (Controller Area Network). A plurality of in-vehicle network communication units 270 are provided corresponding to a plurality of in-vehicle networks. Under the control of the control unit 250, the GW device 210 (computer 212) relays data between in-vehicle networks by transmitting data (messages) received by one in-vehicle network communication unit from another in-vehicle network communication unit. The communication IF 280 provides an IF for communicating with the exterior-vehicle wireless device 300.

[0070] Server device 500 10 , server device 500 includes a computer 510. Computer 510 includes a control unit 520, a storage device 530, and a network IF 540. Control unit 520 includes a CPU 522, a graphics processing unit (GPU) 524, a ROM 526, and a RAM 528. Control unit 520, storage device 530, and network IF 540 are all connected to a bus 550, and data exchange between them is performed via bus 550.

[0071] The storage device 530 includes a non-volatile storage device such as a flash memory or a hard disk drive. The storage device 530 stores various information and computer programs to be executed by the CPU 522. The network IF 540 provides a connection to the network 70, which enables communication with other terminals.

[0072] The server device 500 acquires driving performance information (e.g., position information, time information, and resource consumption (observation results)) from each preceding vehicle via the network 70 for creating a resource consumption performance map. The server device 500 processes the acquired driving performance information to create a resource consumption performance map. The server device 500 distributes the created resource consumption performance map to the vehicles via the network 70.

[0073] A computer program for causing server device 500 to function as each functional unit of server device 500 according to the present embodiment is stored in a predetermined storage medium such as a DVD or a USB memory and distributed, and is then transferred from the storage medium to storage device 530. Alternatively, the computer program may be transmitted to computer 510 from an external device via network 70 and stored in storage device 530.

[0074] [Functional configuration of server device 500] Referring to FIG. 11, the control unit 520 of the server device 500 includes, as functional units, a communication control unit 560, an information collection unit 562, an actual result map creation unit 564, and a distribution unit 566. The storage device 530 includes a driving actual result information storage unit 532 and an actual result map storage unit 534. The communication control unit 560 controls the network IF 540 (see FIG. 10) for communicating with an external device. The information collection unit 562 collects driving actual result information from a plurality of preceding vehicles and stores it in the driving actual result information storage unit 532. The actual result map creation unit 564 reads and processes the driving actual result information stored in the driving actual result information storage unit 532 to create a resource consumption actual result map. The actual result map creation unit 564 stores the created resource consumption actual result map in the actual result map storage unit 534. The actual result map creation unit 564 also has a function of updating the resource consumption actual result map based on newly collected driving actual information. The distribution unit 566 reads out the resource consumption amount result map from the result map storage unit 534 at a predetermined timing and distributes it to the vehicle.

[0075] These functions are realized by software processing executed by the control unit 250 using hardware. Some or all of these functions may be realized by an integrated circuit including a microcomputer.

[0076] [Software configuration] 《In-vehicle equipment 200》 12, a control structure of a computer program executed by in-vehicle device 200 to suppress degradation in responsiveness even under high load caused by communication with the outside of the vehicle will be described. This program starts, for example, when wireless communication with the outside of the vehicle is started.

[0077] This program includes step S1000 of waiting until a resource consumption record map is received from server device 500, and step S1010, which is executed when the resource consumption record map is received from server device 500 in step S1000, and which repeats step S1012 described below for each observation area of the target resource until processing for all target resources is completed. Step S1010 includes step S1012 of estimating resource consumption of real-time applications in the planned travel area based on the received resource consumption record map.

[0078] This program further includes step S1020, which is executed after step S1010, for scheduling the execution period of the non-real-time application based on the resource consumption estimation result; step S1030, which is executed after step S1020, for executing the non-real-time application during the execution period set by the scheduling process of step S1020; and step S1040, which is executed after step S1030, for determining whether a system shutdown instruction has been issued and branching the control flow depending on the determination result. If it is determined in step S1040 that a system shutdown instruction has been issued, control returns to step S1000. If it is determined in step S1040 that a system shutdown instruction has been issued, this program ends.

[0079] Server device 500 13, a control structure of a computer program executed by server device 500 to create and distribute a resource consumption result map to a vehicle will be described. This program is started by an operation by an administrator who manages server device 500, for example.

[0080] This program includes step S2000, which collects driving performance information (e.g., location information, time information, and resource consumption (observation results)) from each vehicle (preceding vehicle) for creating a resource consumption performance map; step S2010, which is executed after step S2000, which creates or updates the resource consumption performance map based on the collected information; and step S2020, which is executed after step S2010, which distributes the created or updated resource consumption performance map to vehicle 100 (on-board device 200) and returns control to step S2000.

[0081] [Operation] The system 30 according to this embodiment operates as follows: In the following, a case will be described in which a specific area in which the amount of resource consumption fluctuates over time is set as the planned travel area.

[0082] 1, server device 500 collects actual resource consumption values for each real-time application in a travel area (specific area) from each preceding vehicle that has traveled in the specific area. Specifically, each preceding vehicle transmits travel history information (e.g., location information, time information, and resource consumption amount (observation result)) when traveling in the travel area to server device 500 as upload information. Server device 500 collects travel history information including actual resource consumption values by receiving the upload information from each preceding vehicle (step S2000 in FIG. 13).

[0083] The server device 500 creates a resource consumption amount record map based on the collected driving performance information (step S2010), and distributes the created resource consumption amount record map to the vehicle 100 (on-vehicle device 200) (step S2020).

[0084] When the on-board device 200 of the vehicle 100 receives the resource consumption amount actual map (YES in step S1000 of FIG. 12), it estimates the resource consumption amount that varies over time as the vehicle travels through the planned travel area based on the received resource consumption amount actual map (step S1010 of FIG. 12).

[0085] With reference to Fig. 4, specifically, the in-vehicle device 200 estimates resource consumption of real-time applications in the planned travel area based on the received resource consumption record map. The in-vehicle device 200 schedules the execution periods of non-real-time applications based on the resource consumption estimation results (step S1020 in Fig. 12). With reference to Fig. 5, a period with available resources is extracted based on the resource consumption estimation results. The in-vehicle device 200 allocates the execution periods of non-real-time applications to the periods with available resources. The in-vehicle device 200 executes processing by the non-real-time applications during the execution periods of the non-real-time applications (step S1030 in Fig. 12).

[0086] As is clear from the above description, the in-vehicle device 200 and the server device 500 according to this embodiment have the following advantages.

[0087] The in-vehicle device 200 acquires historical information (a resource consumption historical map in this embodiment) on resource consumption amounts in a planned travel area by other vehicles (preceding vehicles) that have traveled through the planned travel area of the host vehicle. Based on the acquired resource consumption historical map, the in-vehicle device 200 estimates resource consumption amounts that vary over time as the host vehicle travels. That is, based on the resource consumption historical map, the in-vehicle device 200 predicts a load increase due to communication with an external device when the host vehicle travels through the planned travel area. The in-vehicle device 200 further controls resource consumption by allocating the execution period of a predetermined application (non-real-time application) to a period that avoids, for example, a high-load period. This allows the in-vehicle device 200 to suppress a decrease in responsiveness even during a high-load period due to communication with an external device. In addition, it is possible to suppress the occurrence of services that do not satisfy the allowable delay time without installing a high-performance processor in the in-vehicle device. As a result, it is possible to suppress a decrease in responsiveness while suppressing an increase in the cost of the in-vehicle device.

[0088] The in-vehicle device 200 estimates, for each travel section in the planned travel area, resource consumption, including resource consumption due to the execution of real-time applications, which varies depending on the travel section, and allocates the execution period of non-real-time applications to a predetermined period according to the estimation result. This allows the execution period of non-real-time applications to be allocated to periods when resources are available. In other words, it is possible to prevent non-real-time applications from being executed during periods when resource consumption increases due to the execution of real-time applications. This allows the execution periods of applications to be distributed, making it easy to prevent a decrease in responsiveness during times of high load caused by communication with the outside of the vehicle.

[0089] The server device 500 collects actual resource consumption values (driving actual information) from multiple preceding vehicles, and creates a resource consumption actual map in which actual resource consumptions are set for driving sections in the planned driving area based on the collected driving actual information. By using the resource consumption actual map provided by the server device 500, the in-vehicle device 200 can easily estimate the resource consumption that varies over time as the vehicle drives.

[0090] When scheduling the execution period of a non-real-time application, the execution period of the non-real-time application can be assigned to a planned driving period for a driving section where the ratio of estimated resource consumption to the resource usage upper limit is equal to or less than a predetermined threshold X [%]. In this case, the execution period of the non-real-time application can be easily set to a period other than a high load period. The value of the threshold X [%] may be set based on the resource consumption of the non-real-time application. This allows the execution period of the non-real-time application to be set to a period in which resources for executing the non-real-time application are secured.

[0091] The resource consumption amount record map is set for each travel section of the planned travel area, and includes quantized information (e.g., "high," "medium," and "low") obtained by quantizing the actual values of resource consumption in the planned travel area by the preceding vehicle that traveled through the planned travel area into multiple levels (three levels in this embodiment). This reduces the amount of data in the resource consumption amount record map, making it easier for the in-vehicle device 200 to acquire the resource consumption amount record map.

[0092] (First Modification) In a system according to a first modification, a server device that distributes a resource consumption history map monitors the current location of a destination vehicle and distributes the resource consumption history map to the vehicle before the vehicle enters a planned travel area. The server device acquires location information of the vehicle (on-board device) by communicating with the vehicle. The server device determines, based on the acquired location information, whether the destination vehicle has not yet entered the planned travel area.

[0093] The planned travel area of the vehicle is set in the server device as the above-mentioned specific area. The server device determines whether the vehicle has not yet entered the specific area set as the planned travel area, and distributes a resource consumption record map to the vehicle based on the determination result. "Before entering the planned travel area" can be, for example, immediately before entering the planned travel area, a few seconds before, or a few minutes before entering the planned travel area. The time until entering the planned travel area can be calculated from location information, vehicle speed, etc.

[0094] As a result, the in-vehicle device installed in the vehicle receives the resource consumption record map from the server device before entering the planned travel area. Other configurations of the in-vehicle device and the server device are the same as those in the first embodiment.

[0095] [Software configuration] In the server device according to the first modification, a program shown in Fig. 14 is executed instead of the program shown in Fig. 13. The program in Fig. 14 further includes step S2012 in addition to the program in Fig. 13. The processing in steps S2000, S2010, and S2020 in Fig. 14 is the same as the processing in each step shown in Fig. 14. The differences will be described below.

[0096] 14, this program is executed after step S2010 and includes step S2012 for determining whether the vehicle (on-board device) providing the resource consumption result map has entered a specific area (planned travel area) and branching the control flow depending on the determination result. If it is determined in step S2012 that the vehicle has not yet entered, control returns to step S2000. If it is determined in step S2012 that the vehicle has not yet entered, control proceeds to step S2020.

[0097] With this configuration, the in-vehicle device can more reliably obtain the resource consumption record map from the server device before entering the planned travel area, thereby predicting, before entering the planned travel area, an increase in load due to communication with the outside of the vehicle when the vehicle travels through the planned travel area.

[0098] Other effects of the first modified example are the same as those of the first embodiment.

[0099] (Second Modification) In the system according to the second modification, an in-vehicle device requests a server device to transmit a resource consumption record map. In response to the transmission request from the in-vehicle device, the server device distributes the resource consumption record map to the in-vehicle device that transmitted the transmission request. The in-vehicle device transmits the transmission request to the server device at any timing before entering the planned travel area, for example. This allows the in-vehicle device to receive the resource consumption record map from the server device before the vehicle enters the planned travel area. Other configurations of the in-vehicle device and the server device are the same as those of the first embodiment.

[0100] [Software configuration] 《In-vehicle device》 In the in-vehicle device according to the second modification, a program shown in Fig. 15 is executed instead of the program shown in Fig. 12. The program in Fig. 15 further includes step S1100 in addition to the program in Fig. 12. The processing in steps S1000 to S1040 in Fig. 15 is the same as the processing in each step shown in Fig. 12. The differences will be described below.

[0101] 15, this program includes step S1100 of requesting a server device that distributes resource consumption history maps to transmit the resource consumption history map. In step S1100, for example, at a predetermined timing before the host vehicle enters the planned travel area, a transmission request for transmitting the resource consumption history map is transmitted from the in-vehicle device to the server device. When the processing of step S1100 ends, control proceeds to step S1000. If it is determined in step S1040 that there is "no" instruction to shut down the system, control returns to step S1100.

[0102] Server device In a server device according to the second modification, a program shown in Fig. 16 is executed instead of the program shown in Fig. 13. The program in Fig. 16 includes steps S2014 and S2022 instead of step S2020 in the program in Fig. 13. The processing in steps S2000 and S2010 in Fig. 16 is the same as the processing in each step shown in Fig. 13. The differences will be described below.

[0103] Referring to FIG. 16, this program includes step S2014, which is executed after step S2010, to determine whether or not a transmission request has been received from an in-vehicle device and branch the control flow depending on the determination result, and step S2022, which is executed if it is determined in step S2014 that a transmission request has been received, to deliver (transmit) a resource consumption actual map to the in-vehicle device (vehicle) that sent the transmission request.

[0104] If it is determined in step S2014 that a transmission request has not been received, or if the processing of step S2022 ends, control returns to step S2000.

[0105] In this way, the in-vehicle device can request the server device to send a resource consumption history map before the vehicle enters the planned driving area, thereby obtaining the resource consumption history map from the server device before the vehicle enters the planned driving area.

[0106] Other effects of the second modified example are the same as those of the first embodiment.

[0107] (Third Modification) In a system according to the third modification, an in-vehicle device notifies a server device of a planned driving area of the vehicle. The planned driving area may be set based on a destination set (input) by a passenger of the vehicle in a navigation system or the like. In this case, a route to the set (input) destination is determined, and the planned driving area is derived based on the determined route. Furthermore, if a destination is not input, the planned driving area may be set based on, for example, a past driving history or the current driving behavior of the vehicle. Upon receiving a notification from the in-vehicle device, the server device selects or creates a resource consumption record map corresponding to the transmitted planned driving area and distributes it to the in-vehicle device that transmitted the notification. The timing at which the in-vehicle device notifies the server device of the planned driving area of the vehicle is not particularly limited. For example, the timing at which the planned driving area of the vehicle is notified may be any timing before the vehicle enters the planned driving area, as in the second modification. Other configurations of the in-vehicle device and the server device are the same as those of the first embodiment.

[0108] [Software configuration] 《In-vehicle device》 In an in-vehicle device according to the third modification, a program shown in Fig. 17 is executed instead of the program shown in Fig. 12. The program in Fig. 17 further includes step S1110 in the program in Fig. 12. The processing in steps S1000 to S1040 in Fig. 17 is the same as the processing in each step shown in Fig. 12. The differences will be described below.

[0109] 17, this program includes step S1110 of notifying a server device that distributes a resource consumption actual map of an area where the vehicle is scheduled to travel. When the processing of step S1110 ends, control proceeds to step S1000. If it is determined in step S1040 that there is "no" instruction to terminate the system, control returns to step S1110.

[0110] Server device In the server device according to the third modification, the programs shown in Figures 18 and 19 are executed instead of the program shown in Figure 13. The program shown in Figure 18 is executed in parallel with the program shown in Figure 19.

[0111] 18, this program includes step S2000 of collecting driving performance information (e.g., position information, time information, and resource consumption (observation results)) from each vehicle (preceding vehicle) for creating a resource consumption performance map, and step S2010, which is executed after step S2000, of creating or updating the resource consumption performance map based on the collected information. When the processing of step S2010 ends, control returns to step S2000.

[0112] 19, this program includes step S2100 of waiting until a notification of a planned travel area is received from the vehicle, step S2110 which is executed if it is determined in step S2100 that the notification of the planned travel area has been received, and which selects a resource consumption record map corresponding to the notified planned travel area from the created resource consumption record maps or creates a resource consumption record map corresponding to the notified planned travel area, and step S2120 which is executed after step S2110 and which transmits (distributes) the resource consumption record map corresponding to the notified planned travel area to the vehicle (the vehicle that sent the notification). When the processing of step S2120 ends, control returns to step S2100.

[0113] In the system according to the third modification, the in-vehicle device notifies the server device of the planned travel area of the vehicle and obtains from the server device a resource consumption history map corresponding to the planned travel area, thereby enabling the in-vehicle device to predict temporal fluctuations in resource consumption associated with the travel of the vehicle for various planned travel areas.

[0114] Other effects of the third modified example are the same as those of the first embodiment.

[0115] (Fourth Modification) In the system according to the fourth modification, the time elapsed since the resource consumption amount result map was created is calculated, and the in-vehicle device executes the resource consumption estimation process using the resource consumption amount result map according to the elapsed time. That is, if the resource consumption amount result map acquired by the in-vehicle device is old, the resource consumption estimation process using the resource consumption amount result map is not executed, but if the resource consumption amount result map is relatively new, the resource consumption estimation process is executed.

[0116] The resource consumption result map is accompanied by time information indicating the date and time when the resource consumption result map was generated. The in-vehicle device compares the date and time indicated by the time information with the current date and time, and estimates the resource consumption that fluctuates over time as the vehicle travels, based on the comparison result. For example, if the comparison shows that a time longer than a predetermined time (e.g., a time in the range of 2 to 6 hours) has passed since the resource consumption result map was generated, the in-vehicle device does not perform the estimation process using the resource consumption result map. This allows the resource consumption to be estimated using result information that was created more recently, thereby improving the accuracy of the resource consumption estimation.

[0117] [Software configuration] 《In-vehicle device》 In an in-vehicle device according to the fourth modification, a program shown in Fig. 20 is executed instead of the program shown in Fig. 12. The program in Fig. 20 further includes step S1120 and step S1130 in the program in Fig. 12. The processing in steps S1000 to S1040 in Fig. 20 is the same as the processing in each step shown in Fig. 12. The differences will be described below.

[0118] 20, this program includes the following steps: step S1120, which is executed when it is determined in step S1000 that a resource consumption result map has been received from the server device, and which compares the creation date and time of the received resource consumption result map with the current date and time; and step S1130, which is executed after step S1120, and which determines whether the time elapsed since the resource consumption result map was created is within a predetermined time (for example, a time in the range of 2 to 6 hours) and branches the control flow depending on the determination result. If it is determined in step S1130 that the time elapsed since the resource consumption result map was created is not within the predetermined time (i.e., a time longer than the predetermined time has passed), control returns to step S1000. If it is determined in step S1130 that the time elapsed since the resource consumption result map was created is within the predetermined time, control proceeds to step S1010.

[0119] In addition, if a time longer than a predetermined time has passed since the resource consumption actual map was generated, the in-vehicle device may be configured to discard the resource consumption actual map and request the server device to send a new resource consumption actual map.

[0120] (Second embodiment) 21, in-vehicle device 200A according to this embodiment acquires driving history information (e.g., position information, time information, and resource consumption (observation results)) from a preceding vehicle, and estimates resource consumption that varies over time as the vehicle travels based on the acquired driving history information, which is different from the first embodiment in that it estimates resource consumption based on a resource consumption history map acquired from a server device. The other configurations are the same as those of the first embodiment.

[0121] The in-vehicle device 200A of the vehicle 100A communicates with a plurality of preceding vehicles (e.g., two or three) that have already traveled through the planned travel area via vehicle-to-vehicle communication, and acquires travel history information from these preceding vehicles. The in-vehicle device 200A processes the acquired travel history information to determine which real-time applications have been executed for each travel section in the planned travel area. Based on the determination result, the in-vehicle device 200A estimates the resource consumption of the real-time applications in the planned travel area, in the same manner as in the first embodiment. The in-vehicle device 200A further schedules the execution periods of non-real-time applications based on the resource consumption estimation result.

[0122] 22, the in-vehicle device 200A according to this embodiment includes a GW device 210A instead of the GW device 210 (see FIG. 8). The GW device 210A includes an information acquisition unit 222 and a resource management unit 230A instead of the information acquisition unit 220 and the resource management unit 230 (see FIG. 8), respectively. The information acquisition unit 222 acquires, via the exterior-vehicle radio device 300 (see FIG. 8), “travel performance information,” which is performance information on resource consumption in the planned travel area of the host vehicle, from a preceding vehicle that has traveled through the planned travel area of the host vehicle. The resource management unit 230A includes a resource consumption amount estimation unit 232A instead of the resource consumption amount estimation unit 232 (see FIG. 8). The resource consumption amount estimation unit 232A estimates resource consumption for each travel section in the planned travel area based on the travel performance information acquired from the preceding vehicle.

[0123] [Software configuration] In-vehicle device 200A according to the present embodiment, a program shown in Fig. 23 is executed instead of the program shown in Fig. 12. The program in Fig. 23 includes steps S1200 and S1210 instead of steps S1000 and S1010 in the program in Fig. 12. The processing in steps S1020 to S1040 in Fig. 23 is the same as the processing in each step shown in Fig. 12. The differences will be described below.

[0124] 23, this program includes step S1200 of waiting until driving performance information is received from multiple preceding vehicles, and step S1210, which is executed when it is determined in step S1200 that driving performance information has been received from multiple preceding vehicles, and which repeats step S1212, described below, for each observation area of the target resource until processing for all target resources is completed. Step S1210 includes step S1212 of estimating resource consumption of the real-time application in the planned driving area based on the received driving performance information. When processing in step S1210 is completed, control proceeds to step S1020.

[0125] In this embodiment, to estimate resource consumption, driving history information acquired from a preceding vehicle is used instead of a resource consumption history map acquired from a server device. This also allows the in-vehicle device 200A to easily estimate resource consumption that varies over time as the vehicle travels. Therefore, it is possible to easily suppress a decrease in responsiveness under high load caused by communication with the outside of the vehicle.

[0126] Other effects are the same as those of the first embodiment.

[0127] (Third embodiment) The system according to this embodiment differs from the first embodiment in that the server device extracts a period in which resources are available in the vehicle and notifies the vehicle of the extracted period as a recommended execution period for recommending the execution of a non-real-time application. That is, in this embodiment, the server device executes the process up to extracting a period to allocate an execution period for a non-real-time application.

[0128] 24, server device 500A according to the present embodiment includes a control unit 520A instead of control unit 520 (see FIG. 11). Control unit 520A includes, as functional units, an execution period extraction unit 568 and a notification unit 570 instead of distribution unit 566 (see FIG. 11). Server device 500A receives information on the planned travel area and the resource management target transmitted from the in-vehicle device. Actual result map creation unit 564 creates a resource consumption actual result map corresponding to the planned travel area and stores it in the actual result map storage unit 534. Execution period extraction unit 568 extracts a recommended execution period, during which execution of a non-real-time application is recommended, based on the resource consumption actual result map during the travel period of the planned travel area. Specifically, execution period extraction unit 568 estimates resource consumption of a real-time application in the planned travel area based on the information on the resource management target and the resource consumption actual result map. The execution period extraction unit 568 further extracts, based on the resource consumption estimation result, a period during which resources are available to the extent that the non-real-time application can be executed as a recommended execution period. The notification unit 570 notifies the in-vehicle device that transmitted the information on the planned driving area, etc., of the recommended execution period of the non-real-time application extracted by the execution period extraction unit 568.

[0129] 25, the in-vehicle device 200B according to this embodiment includes a GW device 210B instead of the GW device 210 (see FIG. 8). The GW device 210B does not include the information acquisition unit 220 (see FIG. 8), and includes a resource management unit 230B instead of the resource management unit 230 (see FIG. 8). The resource management unit 230B includes a recommended execution period receiving unit 236 and a resource control unit 238. The recommended execution period receiving unit 236 receives a recommended execution period notified from the server device 500A (see FIG. 24). The resource control unit 238 assigns the execution period of the non-real-time application to the recommended execution period.

[0130] The hardware configurations of the server device 500A and the in-vehicle device 200B are the same as those in the first embodiment.

[0131] [Software configuration] Server device 500A In server device 500A according to the present embodiment, programs shown in Figures 18 and 26 are executed instead of the program shown in Figure 13. The program shown in Figure 26 is executed in parallel with the program shown in Figure 18. Description of the program shown in Figure 18 will be omitted.

[0132] 26, this program includes step S2200 of waiting until information on the planned travel area and the resource management targets is received from in-vehicle device 200B, step S2210, which is executed if it is determined in step S2200 that the information on the planned travel area and the resource management targets has been received, and which selects a resource consumption record map corresponding to the received planned travel area from among the record maps stored in record map storage unit 534 or creates a resource consumption record map corresponding to the planned travel area, and step S2220, which is executed after step S2210 and which repeats step S2222, described below, based on the information on the resource management targets until processing for all target resources is completed for each observation area of the target resources. Step S2220 includes step S2222 of estimating resource consumption of real-time applications in the planned travel area for each observation area of the target resources based on the resource consumption record map.

[0133] This program further includes step S2230, which is executed after step S2220, for extracting, as a recommended execution period, a period during which the non-real-time application to be executed on the in-vehicle device 200B can be executed based on the resource consumption estimation result, and step S2240, which is executed after step S2230, for notifying the in-vehicle device 200B, which has transmitted the information on the planned traveling area, of the extracted recommended execution period, and returning control to step S2200.

[0134] 《In-vehicle device 200B》 In on-vehicle device 200B according to this embodiment, a program shown in FIG. 27 is executed instead of the program shown in FIG.

[0135] 27, this program includes step S1300 for notifying server device 500A (see FIG. 24) of the planned travel area of the host vehicle and information related to the resource management target, step S1310, which is executed after step S1300 and waits until a recommended execution period transmitted from server device 500A is received, step S1320, which is executed if it is determined in step S1310 that the recommended execution period has been received and schedules the execution period of a non-real-time application based on the received recommended execution period, step S1330, which is executed after step S1320 and executes the non-real-time application in the execution period set in the scheduling process of step S1320, and step S1340, which is executed after step S1330 and determines whether a system shutdown instruction has been issued and branches the control flow depending on the determination result. If it is determined in step S1340 that a system shutdown instruction has "not been issued," control returns to step S1300. If it is determined in step S1340 that a system shutdown instruction has been issued, the program ends.

[0136] In step S1300, the timing of notifying the server device 500A of the information related to the planned travel area and the resource management target is not particularly limited. As an example, the timing of notifying the server device 500A of this information can be any timing before the host vehicle enters the planned travel area.

[0137] As in the first embodiment, the server device 500A collects driving performance information from multiple preceding vehicles and creates a resource consumption performance map. Based on the created resource consumption performance map, the server device 500A extracts recommended execution periods for recommending execution of non-real-time applications and notifies the in-vehicle device 200B of the extracted recommended execution periods. The in-vehicle device 200B distributes the execution periods of the applications by allocating the execution periods of the non-real-time applications to the recommended execution periods. This allows the in-vehicle device 200B to easily suppress degradation in responsiveness during high loads caused by communication with the outside of the vehicle. In this way, by notifying the in-vehicle device 200B of the recommended execution periods of the non-real-time applications, the server device 500A can assist the in-vehicle device 200B in suppressing degradation in responsiveness during high loads caused by communication with the outside of the vehicle.

[0138] (Variation) In the above embodiment, an example has been shown in which the GW device has the function of the resource management unit, but the present disclosure is not limited to such an embodiment. The function of the resource management unit may be provided in a device other than the GW device.

[0139] In the above embodiment, an example has been described in which the in-vehicle device includes a gateway device and an exterior wireless device, but the present disclosure is not limited to such an embodiment. The in-vehicle device may be, for example, an ECU other than the gateway device and the exterior wireless device. That is, the ECU may have the functionality of the resource management unit. Furthermore, a dedicated ECU having the functionality of the resource management unit may be installed in the vehicle as an in-vehicle device. Furthermore, a resource management unit may be installed in multiple in-vehicle devices.

[0140] In the above embodiment, an example of scheduling the execution period of a non-real-time application is shown, but the present disclosure is not limited to such an embodiment. If the execution period of a non-real-time application has already been set, the execution period of the non-real-time application can be reset (rescheduled) based on the result of estimating resource consumption.

[0141] In the above embodiment, an example has been shown in which the server device creates a resource consumption record map of a planned travel area of the vehicle or a specific area, but the present disclosure is not limited to such an embodiment. For example, the server device may create a resource consumption record map of an area managed by the actual device, extract a required area from the created wide-area resource consumption record map, and distribute the extracted area to the vehicle.

[0142] Each process (each function) in the above-described embodiments may be implemented by a processing circuit including one or more processors. The processing circuit may be configured by an integrated circuit or the like that combines one or more memories, various analog circuits, and various digital circuits in addition to the one or more processors. The one or more memories store programs (instructions) that cause the one or more processors to execute the respective processes. The one or more processors may execute the respective processes according to the programs read from the one or more memories, or according to logic circuits pre-designed to execute the respective processes. The processor may be a CPU, GPU, DSP (Digital Signal Processor), FPGA (Field Programmable Gate Array), ASIC (Application Specific Integrated Circuit), or any other processor suitable for computer control. The plurality of physically separated processors may cooperate with each other to execute the respective processes. For example, the processors installed in each of the physically separated computers may cooperate with each other via a network such as a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet to execute the respective processes.

[0143] Embodiments obtained by appropriately combining the techniques disclosed above are also included within the technical scope of the present disclosure.

[0144] The embodiments disclosed herein are merely examples, and the present disclosure is not limited to the above-described embodiments. The scope of the present disclosure is defined by the claims in the scope of the claims, taking into consideration the description of the detailed description of the invention, and includes all modifications within the meaning and scope equivalent to the wording described therein. [Explanation of symbols]

[0145] 30 systems 32 Planned driving area 50 Infrastructure Equipment 60 Dynamic Maps 62 Real Space 70 Network 100, 100A vehicles 110 Millimeter wave radar 112 In-vehicle camera 114 LiDAR 200, 200A, 200B in-vehicle equipment 210, 210A, 210B GW equipment 212, 510 Computer 220, 222 Information acquisition section 230, 230A, 230B Resource Management Department 232, 232A Resource consumption estimation unit 234, 238 Resource control section 236 Execution recommendation period receiving unit 240 Cooperative Mediation Department 250, 520, 520A control unit 252 Arithmetic section 254, 526 ROM 256,528 RAM 260, 530 storage device 270 In-vehicle network communication unit 280 Communication Interface 290, 500 buses 300 External radio equipment 310, 320, 330 wireless IF 400 In-Vehicle Network 410 Sensor Group 420 ECU group 500, 500A server equipment 522 CPU 524 GPU 532 Driving performance information storage unit 534 Track record map memory section 540 Network Interface 560 Communication Control Unit 562 Information Gathering Department 564 Track Record Mapping Department 566 Distribution Department 568 Execution Period Extraction Unit 570 Notification Department

Claims

1. An in-vehicle device mounted on a vehicle, a communication unit for communicating with an external device; an information acquisition unit that acquires, via the communication unit, actual information on resource consumption of another vehicle other than the host vehicle when the other vehicle travels in a planned travel area of the host vehicle; an estimation unit that estimates a resource consumption amount that varies over time as the host vehicle travels through the planned travel area based on the performance information acquired by the information acquisition unit; and a resource control unit that controls resource consumption by allocating an execution period of predetermined application software to a predetermined period in accordance with an estimation result of the estimation unit.

2. the estimation unit estimates, for each travel section, a resource consumption amount that varies depending on a travel section in the planned travel area, the resource consumption amount including a resource consumption amount due to execution of application software that requires real-time processing; 2. The in-vehicle device according to claim 1, wherein the resource control unit controls resource consumption by allocating an execution period of application software that does not require real-time processing to the predetermined period in accordance with the estimation result of the estimation unit.

3. the external device includes a server device that collects actual resource consumption information from a plurality of other vehicles and creates a resource consumption actual map in which actual resource consumptions are set for travel sections in the planned travel area based on the collected actual resource consumption information; the information acquisition unit acquires the resource consumption amount result map as the result information from the server device via the communication unit; The in-vehicle device according to claim 1 , wherein the estimation unit estimates the resource consumption amount for each travel section in the planned travel area based on the resource consumption amount record map.

4. the external device includes an in-vehicle device mounted on another vehicle other than the host vehicle, the information acquisition unit acquires, via the communication unit, actual information on resource consumption amounts in the planned travel area from an in-vehicle device of the other vehicle that has traveled through the planned travel area of the host vehicle; 3. The in-vehicle device according to claim 1, wherein the estimation unit estimates the resource consumption of each travel section in the planned travel area based on actual information of the resource consumption obtained from the in-vehicle device of the other vehicle.

5. 3. The in-vehicle device according to claim 1, wherein the resource control unit allocates an execution period of application software that does not require real-time processing to a planned driving period for a driving section in which the ratio of the resource consumption estimated by the estimation unit to the resource usage upper limit is equal to or less than a predetermined value.

6. The in-vehicle device according to claim 5 , wherein the predetermined value is set based on the resource consumption amount of the application software that does not require real-time performance.

7. 3. The in-vehicle device according to claim 1, wherein the performance information is set for each driving section of the planned driving area and includes quantized information in which the performance values of the resource consumption of the other vehicles that have driven through the planned driving area are quantized into multiple stages.

8. The in-vehicle device according to claim 1 , wherein the information acquisition unit acquires the performance information before the host vehicle enters the planned travel area.

9. The in-vehicle device according to claim 1 , wherein the information acquisition unit requests the external device to transmit the performance information before the host vehicle enters the planned travel area.

10. The performance information is added with time information indicating the date and time when the performance information was generated, 3. The in-vehicle device according to claim 1, wherein the estimation unit compares a date and time indicated by the time information with a current date and time, and estimates the resource consumption amount that varies over time as the vehicle travels based on a comparison result.

11. A server device capable of communicating with an in-vehicle device mounted in a vehicle, an information collection unit that collects performance information of resource consumption from a plurality of vehicles; an actual result map creation unit that receives information about a planned travel area from the in-vehicle device and creates a resource consumption actual result map in which actual resource consumption results are set for travel sections in the planned travel area based on the actual result information collected by the information collection unit; an execution period extraction unit that extracts, based on the resource consumption amount result map, a recommended execution period during which application software that does not require real-time processing is to be executed during a driving period in the planned driving area; a notification unit that notifies the in-vehicle device that transmitted the information about the planned travel area of the recommended execution period extracted by the execution period extraction unit.

12. A resource control method in an in-vehicle device mounted on a vehicle, comprising: a step in which the in-vehicle device acquires, via a communication unit that communicates with an external device, actual information on resource consumption amounts of other vehicles, which are vehicles other than the subject vehicle, when the other vehicles travel in a planned travel area of the subject vehicle; a step in which the in-vehicle device estimates a resource consumption amount that varies over time as the vehicle travels through the planned travel area based on the performance information acquired in the acquiring step; and controlling resource consumption by the in-vehicle device by allocating an execution period of predetermined application software to a predetermined period according to the estimation result in the estimating step.

13. A resource control support method executed in a server device capable of communicating with an on-board device mounted in a vehicle, the method supporting control of resource consumption in the vehicle, comprising: A step in which a server device collects actual resource consumption information from a plurality of vehicles; a step in which a server device receives information about the planned travel area from the in-vehicle device, and creates a resource consumption amount record map in which resource consumption records are set for travel sections of the planned travel area based on the record information collected in the collecting step; a step in which the server device extracts, based on the resource consumption amount actual map, a recommended execution period during which application software that does not require real-time processing is to be executed during a driving period in the planned driving area; a step of notifying the recommended execution period extracted in the extracting step by a server device to the vehicle-mounted device that transmitted the information on the planned travel area.

14. The computer installed in the vehicle a communication unit for communicating with an external device; an information acquisition unit that acquires, via the communication unit, actual information on resource consumption of another vehicle other than the host vehicle when the other vehicle travels in a planned travel area of the host vehicle; an estimation unit that estimates a resource consumption amount that varies over time as the host vehicle travels through the planned travel area based on the performance information acquired by the information acquisition unit; and A computer program that functions as a resource control unit that controls resource consumption by allocating an execution period of predetermined application software to a predetermined period in accordance with an estimation result of the estimation unit.

15. Computer, an information collection unit that collects performance information of resource consumption from a plurality of vehicles; an actual result map creation unit that receives information about a planned travel area from an in-vehicle device, and creates a resource consumption actual result map in which actual resource consumption results are set for travel sections in the planned travel area based on the actual result information collected by the information collection unit; an execution period extraction unit that extracts, based on the resource consumption amount result map, a recommended execution period during which application software that does not require real-time processing is to be executed during a driving period in the planned driving area; and a notification unit that notifies the in-vehicle device that transmitted the information about the planned travel area of the recommended execution period extracted by the execution period extraction unit;

Images