Vehicle control device and vehicle control method

Abstract

An API unit (71) includes a function API (72), which is an interface provided for each function. A state predicting unit (852) predicts the state of resources possessed by a vehicle, within a specified time range. An information generating unit (851) generates, for each function API, reference information including a time period during which the function API is available, from a prediction result obtained by the state predicting unit. An information providing unit (73) provides the reference information generated by the information generating unit for a function API specified in a request from application software.

Description

Cross-reference to Related Applications

[0001] This international application claims priority based on Japanese Patent Application No. 2023-080018 filed with the Japan Patent Office on May 15, 2023, and incorporates the entire contents of Japanese Patent Application No. 2023-080018 by reference into this international application.

Technical Field

[0002] This disclosure relates to a technology for processing requests from application software that realizes services using vehicle functions.

Background Art

[0003] Patent Document 1 describes a technology for collecting information only in a situation specified by the server side in order to effectively utilize system resources in a vehicle data collection system that collects various vehicle data obtained via sensors and the like mounted on a vehicle from a plurality of vehicles.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

[0005] In the future, with the spread of vehicle APIs, it is assumed that a plurality of systems will access the same vehicle. A vehicle API is an interface for providing vehicle functions to application software or the like implemented inside or outside the vehicle.

[0006] When multiple systems exist inside and outside a vehicle, and application software is executed in each system, each system attempts to access the vehicle at its own discretion, resulting in conflicts over access to the same vehicle. Conventional technologies control the load within a single system, and therefore have the problem of not being able to control the load when conflicts occur with other systems.

[0007] This disclosure provides a technology to suppress conflicts in access requests to vehicle functions from multiple systems.

[0008] One aspect of this disclosure is a vehicle control device installed in a vehicle. The vehicle control device comprises an equipment management unit, an API unit, a state prediction unit, an information generation unit, and an information provision unit. The equipment management unit is configured to execute control over vehicle equipment, which is equipment possessed by the vehicle, and to manage the state of the vehicle equipment. The API unit receives requests from application software and has function APIs, which are interfaces provided for each of the functions, in order to realize functions that utilize the vehicle equipment managed by the equipment management unit. The state prediction unit is configured to predict the state of the vehicle's resources within a specified time range. The information generation unit is configured to generate reference information for each function API, including the time period during which the function API can be used, based on the prediction results from the state prediction unit. The information provision unit is configured to provide the reference information generated by the information generation unit for the function API specified by the request from the application software.

[0009] According to the above vehicle control device, application software can determine the time periods during which the desired functional API is available via the information provision unit. By each application software using the functional API according to the time period it has determined, it is possible to suppress conflicts in requests for the same resource from multiple application software programs. In other words, it is possible to control requests for access to vehicle functions from multiple application software programs so as not to deplete the vehicle's resources.

[0010] One aspect of this disclosure is a vehicle control method performed by a computer installed in a vehicle. In this vehicle control method, an equipment management unit of the computer performs control over vehicle equipment, which is equipment possessed by the vehicle, and manages the state of said vehicle equipment. An API unit of the computer receives requests from application software and provides function APIs, which are interfaces provided for each function, in order to realize functions that utilize the vehicle equipment managed by the equipment management unit. A state prediction unit of the computer predicts the state of the vehicle's resources within a specified time range. An information generation unit of the computer generates reference information for each function API, including the time period during which the function API can be used, based on the prediction results from the state prediction unit. Then, an information provision unit of the computer provides the application software that made the request with the reference information generated by the information generation unit for the function API specified in the request from the application software.

[0011] This vehicle control method can achieve the same effects as the vehicle control device described above. [Brief explanation of the drawing]

[0012] [Figure 1] This is a block diagram showing the configuration of a vehicle control system. [Figure 2] This is a block diagram showing the configuration of the ECU. [Figure 3] This is a block diagram showing the configuration of the center. [Figure 4] This is a block diagram showing the functional configuration of a vehicle control system. [Figure 5] This is an explanatory diagram illustrating the contents of the necessary resource information. [Figure 6] This flowchart shows the processes performed by the reservation mediation department. [Figure 7] This sequence diagram shows the basic processing flow when a request is made via the confirmation API and the reservation API. [Figure 8] This is a sequence diagram showing the processing flow when there is a reservation conflict. [Modes for carrying out the invention]

[0013] Embodiments of this disclosure will be described below with reference to the drawings.

[0014] [1. System Configuration] The vehicle control system 1 shown in Figure 1 comprises a group of electronic control units (hereinafter referred to as ECUs) 100 mounted on a vehicle such as an automobile, and a center 35. The ECU group 100 includes multiple ECUs. In this embodiment, the ECU group 100 comprises a first ECU 10, a second ECU 15, a third ECU 20, a fourth ECU 25, a fifth ECU 30, and sixth to thirteenth ECUs 41 to 48. Each ECU belonging to the ECU group 100 is connected to each other by in-vehicle communication (i.e., wired communication or wireless communication). The center 35 is located outside the vehicle and is connected to the ECU group 100 by external communication (i.e., wireless communication).

[0015] The first ECU 10 has a relay function for in-vehicle communication and, by coordinating the second to fifth ECUs 15 to 30, enables coordinated control of the entire vehicle. Furthermore, the first ECU 10 also coordinates communication with the center 35, enabling coordinated control of the entire system, including the center 35.

[0016] The first ECU 10 and the third to fifth ECUs 20 to 30 are provided for each domain classified by the functions in the vehicle, and mainly execute the control of a plurality of ECUs (that is, any one of the sixth to thirteenth ECUs 41 to 48) existing within that domain. The domains are, for example, the power train, the body, the chassis, and the cockpit, etc.

[0017] The sixth to thirteenth ECUs 41 to 48 control vehicle equipment which is equipment mounted on the vehicle.

[0018] The vehicle equipment may include, in addition to hardware such as sensors and actuators, various storage devices for storing data, and software for realizing a certain function.

[0019] The first ECU 10 and the third to fifth ECUs 20 to 30 are connected to the subordinate sixth to thirteenth ECUs 41 to 48 via separately provided lower-layer networks (for example, CAN). CAN is the abbreviation of Controller Area Network and is a registered trademark. The first ECU 10 and the third to fifth ECUs 20 to 30 have a function of centrally managing access rights, etc. to the subordinate sixth to thirteenth ECUs 41 to 48 and performing user authentication, etc.

[0020] In another embodiment, the vehicle control system 1 may include an ECU group 100 and the center 35 may be omitted. In another embodiment, the number of ECUs belonging to the ECU group 100 may be 14 or more or 13 or less. In another embodiment, there may be a plurality of centers 35.

[0021] [2. Hardware Configuration] Next, the hardware configurations of each ECU belonging to the ECU group 100 and the center 35 will be described. Each ECU belonging to the ECU group 100 has the same hardware configuration. Therefore, here, the configuration of the first ECU 10 will be described as a representative.

[0022] As shown in Figure 2, the first ECU 10 comprises a microcomputer 11, a vehicle interface (hereinafter referred to as I / F) 12, and a communication unit 13. The microcomputer 11 comprises a CPU 11a, a ROM 11b, and a RAM 11c. Various functions of the first ECU 10 are realized by the CPU 11a executing a program stored in a non-transitional physical recording medium. In this embodiment, the ROM 11b corresponds to the non-transitional physical recording medium that stores the program. Furthermore, the execution of this program executes a method corresponding to the program.

[0023] The vehicle interface 12 connects to other ECUs and in-vehicle devices via an in-vehicle network, etc., and acquires various information from other ECUs and in-vehicle devices. The in-vehicle network may include a Controller Area Network (CAN) and Ethernet. CAN is a registered trademark. Ethernet is a registered trademark.

[0024] The communication unit 13 communicates data with the center 35, etc., via a wide-area communication network using wireless communication. However, it is not necessary for all ECUs belonging to the ECU group 100 to have a communication unit 13; it may be provided by only one or some of the ECUs.

[0025] The methods for realizing the various functions of the first ECU 10 are not limited to software; some or all of its elements may be realized using one or more hardware components. For example, if the above functions are realized by an electronic circuit, which is hardware, that electronic circuit may be a digital circuit containing a large number of logic circuits, an analog circuit, or a combination of a digital circuit and an analog circuit.

[0026] As shown in Figure 3, the center 35 comprises a microcomputer 36, a communication unit 37, and a storage unit 38. The microcomputer 36 comprises a CPU 36a, a ROM 36b, and a RAM 36c. The various functions of the center 35 are realized by the CPU 36a executing a program stored in a non-transitional physical recording medium. In this embodiment, the ROM 36b corresponds to the non-transitional physical recording medium that stores the program. Furthermore, the execution of this program executes a method corresponding to the program.

[0027] The communication unit 37 communicates data with the ECU group 100 via a wide-area communication network. The storage unit 38 is a storage device for storing vehicle data and the like provided by the ECU group 100.

[0028] The methods for realizing the various functions of Center 35 are not limited to software; some or all of its elements may be realized using one or more hardware components. For example, if the above functions are realized by an electronic circuit, which is hardware, that electronic circuit may be a digital circuit containing a large number of logic circuits, an analog circuit, or a combination of digital and analog circuits.

[0029] [3. Functional Configuration] Returning to Figure 1, let's explain the various functions of the vehicle control system 1. The vehicle control system 1 includes the functions of the first layer equipment management unit 9, the second layer status management unit 8, the third layer vehicle service unit 7, and the fourth layer service provision unit 6. In other words, the software architecture of the vehicle control system 1 is layered into four layers. The above-mentioned functions of the vehicle control system 1 are shared among the ECUs belonging to the ECU group 100 and the center 35.

[0030] [3-1. Equipment Management Department] The equipment management unit 9 is equipped with multiple control units 91 to 99 according to various types of vehicle equipment. Vehicle equipment includes, for example, onboard cameras, onboard millimeter-wave radar, brakes, steering, displays, speakers, various lights, onboard air conditioning, and power seats.

[0031] Specifically, the equipment management unit 9 includes a camera control unit 91, a millimeter-wave control unit 92, a brake control unit 93, a steering control unit 94, a display control unit 95, a sound control unit 96, a light control unit 97, a Heating Ventilation and Air-Conditioning (HVAC) control unit 98, and a seat control unit 99. Vehicle equipment is individually controlled by the corresponding control unit from among the control units 91 to 99.

[0032] The camera control unit 91 controls the exposure of the in-vehicle camera and other parameters to acquire images captured by the in-vehicle camera. In this embodiment, the sixth ECU 91 includes the camera control unit 91.

[0033] The millimeter-wave control unit 92 controls the on-board millimeter-wave radar and acquires the detection results detected by the millimeter-wave radar. In this embodiment, the seventh ECU 92 includes the millimeter-wave control unit 92.

[0034] The brake control unit 93 controls the brakes. In this embodiment, the 8th ECU 93 includes the brake control unit 93.

[0035] The steering control unit 94 controls the steering. In this embodiment, the ninth ECU 44 includes the steering control unit 94.

[0036] The display control unit 95 controls the display devices (e.g., meters, warning lights, etc.). In this embodiment, the 10th ECU 45 includes the display control unit 95.

[0037] The sound control unit 96 controls the speaker to output sounds such as warning sounds and voices from the speaker. In this embodiment, the 11th ECU 46 is equipped with the sound control unit 96.

[0038] The light control unit 97 controls various lights mounted on the vehicle. In this embodiment, the fifth ECU 30 includes the light control unit 97.

[0039] The HAVC control unit 98 controls the in-vehicle air conditioner. In this embodiment, the 12th ECU 47 includes the HAVC control unit 98.

[0040] The seat control unit 99 controls the vehicle's electric power seat. In this embodiment, the 13th ECU 48 includes the seat control unit 99.

[0041] The equipment management unit 9 operates the vehicle equipment according to the operation instructions from the status management unit 8 and notifies the status management unit 8 of the operation results. For example, if the vehicle equipment is an actuator, the operation result may indicate whether the actuator terminated normally or abnormally. If the vehicle equipment is a sensor, the operation result may indicate data detected by the sensor. If the vehicle equipment is a storage device, the result notification may indicate data read from the storage device.

[0042] In addition to operating vehicle equipment according to operation instructions from the status management unit 8, the equipment management unit 9 may also be configured to spontaneously detect the status of vehicle equipment and notify the status management unit 8.

[0043] [3-2. Service Provision Department] The service provision unit 6 executes application software (hereinafter referred to as "apps") 61 to 64, thereby utilizing vehicle equipment managed by the equipment management unit 9 to realize various functions, such as information gathering, theft prevention, and remote operation.

[0044] In this embodiment, the first ECU 10, the second ECU 15, and the center 35 are equipped with a service provision unit 6. The ROM 11b of the first ECU 10 stores applications 61 and 62. The ROM 11b of the second ECU 15 stores application 63. The ROM 36b of the center 35 stores application 64.

[0045] Applications 61-64 are basically configured to realize their intended services by utilizing the functions of the vehicle equipment via the API unit 71, which constitutes the vehicle service unit 7.

[0046] Apps 61-64 are not dedicated programs for performing processing specific to a particular vehicle model or grade, but rather general-purpose programs for performing processing compatible with many vehicle models and grades. Therefore, apps 61-64 are written using publicly available modeled vehicle functions so that they can be created without being aware of the vehicle equipment or performance of individual vehicles. In other words, apps 61-64 can be easily developed by third-party app providers other than OEMs, and the developed products can be widely released. Accordingly, vehicle users who own vehicles equipped with the ECU group 100 can install apps released by third parties onto any of the ECU group 100 via a wide-area communication network, etc. Furthermore, vehicle users can add or modify apps 61-64 as they wish.

[0047] Furthermore, in the case of an application used to provide a service that acquires vehicle information from many vehicles and analyzes vehicle behavior and driver operation, the service provider, who is the provider of the application, may install the application on any of the ECU group 100 with the permission of the vehicle user. In addition, access rights to individual APIs belonging to the API section 71 from applications installed in the center 35 by the service provider, etc., may be restricted by the vehicle user on a per-service provider or per-application basis.

[0048] [3-3. Vehicle Service Department] The vehicle service unit 7 includes an Application Programming Interface (API) unit 71. In this embodiment, the first ECU 10 includes the API unit 71. The API unit 71 includes a plurality of vehicle APIs. The vehicle APIs are interfaces provided to applications 61 to 64 belonging to the service provision unit 6 for accessing subdivided vehicle functions.

[0049] The vehicle API has a standardized syntax that allows requests to be described without being dependent on a specific vehicle model or trim level. When applications 61-64 utilize the functions provided by the vehicle, they send a first command using the vehicle API. The first command is a command that specifies the information required when using the vehicle API.

[0050] The first directive may include commands, arguments, function calls, etc., that indicate the request. The first directive may also include priority information indicating which directives should be processed with priority. Priority may be set, for example, depending on whether the manufacturer of the application requesting the first directive is an OEM or a third party other than an OEM. OEM stands for Original Equipment Manufacturer. Specifically, OEMs may be given higher priority than third parties. Furthermore, among OEMs, vehicle manufacturers may be given higher priority than parts / application manufacturers. Priority may also be set according to the type of control.

[0051] The syntax of the vehicle API, i.e., the format of the first command, is written using publicly available modeled vehicle functions so that it can be created without being aware of the vehicle equipment and performance of individual vehicles, similar to apps 61-64. In other words, the first command abstractly describes the function to be implemented without specifying vehicle equipment or using expressions that depend on the performance of vehicle equipment. For example, the first command may state to turn on the car finder, but it does not specify which vehicle equipment to control and how, or specify which of the multiple lights implemented in the vehicle should be turned on, which are specific details that depend on the individual vehicle.

[0052] When the API unit 71 receives a first command, it determines whether or not the first command is acceptable from a formal standpoint, such as the format of the first command and the access rights held by the requester of the first command. If the API unit 71 determines that the first command is acceptable, it converts it into a second command written in a format suitable for the vehicle type and grade of the target vehicle and sends it to the status management unit 8. In other words, the API unit 71 has the function of converting a first command written in a standard format handled by the service provision unit 6 into a second command written in a vehicle-specific format handled by the status management unit 8 and the equipment management unit 9. The second command is also assigned an application ID that identifies the application that sent the first command (hereinafter referred to as the requesting application). Furthermore, the API unit 71 has the function of forwarding the result notification, which is the response from the status management unit 8 to the second command, to the requesting application.

[0053] The API unit 71 includes a function API 72, a confirmation API 73, and a reservation API 74.

[0054] Functional API 72 is a vehicle API used when requesting control over vehicle equipment.

[0055] The verification API 73 is a vehicle API used to check the available time periods and other details for a specified function API 72.

[0056] The reservation API 74 is a vehicle API used to reserve the use of a specified function API 72, specifying start and end conditions, etc.

[0057] [3-4. Status Management Section] As shown in Figure 4, the status management unit 8 comprises a processing execution unit 80 and a reservation management unit 85.

[0058] The processing execution unit 80 processes requests from the service provision unit 6 via the functional API 72.

[0059] The reservation management unit 85 processes requests from the service provision unit 6 via the confirmation API 73 and the reservation API 74.

[0060] [3-4-1. Processing Execution Unit] The processing execution unit 80 includes a state recognition unit 81, a motion system equipment control unit 82, a Human Machine Interface (HMI) system state recognition unit 83, and a body system control unit 84.

[0061] The parts 81 to 84 belonging to the processing execution unit 80 are classified not by implementation means (e.g., control units 91 to 99) which are prone to vehicle variations, but by vehicle operation which is easily required by the service provision unit 6. In this embodiment, as shown in Figure 1, the parts 81 to 84 belonging to the processing execution unit 80 are each provided in one of the first ECU 10 and the third to fifth ECUs 30 which manage each domain of the vehicle.

[0062] The state recognition unit 81 is responsible for recognizing the vehicle itself and the surrounding environment, such as the position of vehicles and pedestrians. The state recognition unit 81 controls, for example, vehicle equipment belonging to the camera control unit 91 and the millimeter-wave control unit 92. In this embodiment, the third ECU 20 includes the state recognition unit 81.

[0063] The motion system equipment control unit 82 corresponds to the vehicle's driving system operations, such as turning, driving, and stopping. The motion system equipment control unit 82 controls, for example, vehicle equipment belonging to the brake control unit 93 and the steering control unit 94. In this embodiment, the first ECU 10 includes the motion system equipment control unit 82.

[0064] The HMI system state recognition unit 83 corresponds to the vehicle's operations related to the presentation of information to the user. The HMI system state recognition unit 83 controls, for example, vehicle equipment belonging to the display control unit 95 and the sound control unit 96. In this embodiment, the fourth ECU 25 includes the HMI system state recognition unit 83.

[0065] The body system control unit 84 corresponds to the operation of the vehicle's body system in relation to the vehicle environment. The body system control unit 84 controls, for example, vehicle equipment belonging to the light control unit 97, HVAC control unit 98, and seat control unit 99. In this embodiment, the fifth ECU 30 includes the body system control unit 84.

[0066] When the processing execution unit 80 receives a request (i.e., a second command) from the vehicle service unit 7, it determines whether the vehicle's condition is suitable for the execution of the second command, and if so, it instructs the equipment management unit 9 to operate the target equipment. The vehicle condition suitable for the execution of the second command may include the fact that the target equipment is capable of performing the functions required by the second command, and that the execution of the second command is not prohibited in a scenario estimated from the vehicle's condition.

[0067] The processing execution unit 80 has the function of outputting operation instructions for the target equipment to the equipment management unit 9 and providing the operation results returned from the equipment management unit 9 to the vehicle service unit 7 as a result notification for the second command. The result notification may use the individual operation results as they are, or it may use multiple operation results integrated and converted into higher-level abstract data.

[0068] For example, the processing execution unit 80 may receive a request from the vehicle service unit 7 to collect information to understand the vehicle's status, and the equipment management unit 9 may provide data from multiple vehicle equipment as an operational result. If the operational result provides data such as "vehicle speed 0 km / h," "shift position P," and "driver not inside the vehicle," the processing execution unit 80 may convert this data to indicate that "the vehicle is parked," and send the converted data to the vehicle service unit 7 as a result notification.

[0069] [3-4-2. Reservation Management Department] The reservation management unit 85 is provided in the first ECU 10. However, the reservation management unit 85 may be provided in an ECU other than the first ECU 10. As shown in Figure 4, the reservation management unit 85 includes a reservation arbitration unit 851, a state prediction unit 852, and an information storage unit 853.

[0070] The information storage unit 853 stores necessary resource information and reservation information.

[0071] The required resource information is information that associates the API-ID, which identifies the functional API 72, with the resources necessary to execute the process associated with that functional API 72. Specifically, as shown in Figure 5, the resources necessary to execute the process include information such as "equipment used," "processing content," "CPU processing load," "required data amount," "power consumption," "communication volume," and "execution time."

[0072] "Equipment Used" indicates the ECU that executes the processing, the actuators and sensors that are the target of the processing, etc. "Processing Details" indicates the necessary processing for each piece of equipment used. "CPU Processing Load" indicates the processing load on the ECU indicated in "Equipment Used". "Required Data Capacity" indicates the available memory capacity required for processing on the ECU indicated in "Equipment Used". "Power Consumption" indicates the power consumption for each piece of equipment indicated in "Equipment Used". "Communication Volume" indicates the communication volume required for data upload and data download when communication with an external server is required. "Execution Time" indicates the average processing time for each process indicated in "Processing Details".

[0073] Reservation information is information related to the reservation of using the function API 72. The reservation information is set according to a request from the service provision unit 6 using the reservation API 74. The reservation information includes the function API 72 that identifies the function API 72 to be reserved, the application ID that identifies the application making the reservation, the start time and end time of the reservation, etc.

[0074] The status prediction unit 852 responds to inquiries from the reservation arbitration unit 851 by providing a prediction result of the utilization status of the vehicle equipment (i.e., resources). The period covered by the prediction may be a specified time range from the current time when the request was received (e.g., 24 hours), or it may be a time range specified by instructions from the reservation arbitration unit 851.

[0075] The resources to be predicted may include "power status," "CPU usage," "battery level," "available data capacity," "equipment availability," and "communication availability," etc.

[0076] "Power Status" may include information indicating whether the IG is ON, ACC, or OFF, as well as information indicating the connection status of the charging plug. "CPU Usage" is information expressed as a percentage of the CPU usage rate of the first ECU 10, which performs processing as the vehicle service unit 7 and processing as the reservation management unit 85 of the status management unit 8. "CPU Usage" may also include information on the CPU usage rate of each ECU other than the first ECU 10. "Battery Level" is information expressed as a percentage of the remaining capacity of the vehicle battery. "Free Data Capacity" is information representing the free memory capacity available for processing. "Equipment Availability" is information representing the result of determining whether the equipment is available, including whether the equipment is malfunctioning and whether the equipment is operating. Equipment for which "Equipment Availability" is indicated may include special image processing with high processing load. "Communication Availability" is information representing the communication status with an external server, etc. For example, the occupancy rate of the communication channel used for communication with an external server may be shown for each application.

[0077] The status prediction unit 852 repeatedly acquires the status of the in-vehicle equipment from the equipment management unit 9 and stores the results aggregated in a predetermined manner. The aggregation method is, for example, to use the on / off timing of the vehicle's IG switch as the starting point and aggregate using the elapsed time from the starting point as an index. The aggregated values ​​may also be aggregated individually, for example, by day of the week, by season, by driver, by route, or by destination. Routes may include, for example, commuting routes and other routes other than commuting routes.

[0078] When the status prediction unit 852 receives an inquiry from the reservation arbitration unit 851, it predicts the usage status of each resource and returns the prediction result to the reservation arbitration unit 851. The prediction of the usage status of each resource takes into account aggregated values ​​of past usage status and reservation information stored in the information storage unit 853. Furthermore, the prediction of the usage status of each resource may also utilize information such as whether each application has access rights to each API, the driving route set by the navigation device, and the estimated time of arrival. In addition, the prediction of the usage status of each resource may also utilize information such as disembarkation predictions extracted from images of cameras that capture the interior of the vehicle, and information about the driver's schedule obtained by linking with the calendar of a mobile terminal.

[0079] Here, we will explain how the state prediction unit 852 predicts the usage status of the source.

[0080] "Power Status" is calculated by assuming a 100% probability that the current power status is IG-ON or the charging plug is connected, and gradually decreasing the predicted value S1 as time progresses.

[0081] There are two ways to decrease the predicted value S1: (1) simply by decreasing it inversely proportional to the passage of time, and (2) by decreasing it according to a predetermined first table value f1(t). t is time, and f1(t) takes a value between 0 and 1, and is set to change as time progresses.

[0082] S1[%]=100 / t (1) S1[%] = 100 × f1(t) (2) The first table value f1(t) may be set from past history. In this case, the first table value f1(t) may be set such that, for example, the average time from when the IG-ON is turned on until the IG-ON is turned off is calculated from past history, and the value of the first table value f1(t) decreases monotonically until it becomes approximately zero based on the calculated average time.

[0083] Furthermore, if the current power state is IG-ON and a driving route has been set by the navigation system, the first table value f1(t) may be set as follows: That is, the first table value f1(t) may be set to be a small value until the estimated arrival time in the navigation system's route guidance, and to be a large value thereafter.

[0084] Furthermore, if the current power status is that the charging plug is connected, the first table value f1(t) may be set to be a small value until the scheduled charging completion time, and a large value thereafter, according to the charging plan.

[0085] The predicted value S2 for "CPU usage" may be calculated according to equation (3) using the second table value f2(t), which represents the CPU usage predicted from the application's actual usage or application usage plan. The second table value f2(t) takes values ​​between 0 and 1.

[0086] S2[%] = 100 × f2(t) (3) When setting the second table value f2(t) based on app usage data, app usage data is aggregated on a time axis representing the elapsed time starting from the moment the IG-ON was activated, and the probability of each app being used at each time point is calculated. The second table value f2(t) is then set based on this probability and the CPU usage rate when each app was used. The second table value f2(t) may be set individually for each app.

[0087] Alternatively, the second table value f2(t) may be set using the app usage plan instead of the app usage history.

[0088] The predicted value S3 for "battery level" may be calculated according to equation (4) using the current battery level Qc[%] as the base, and a third table value f3(t) which is set based on the app's usage history or planned usage and the power consumption required by each app.

[0089] S3[%]=Qc-100×f3(t) (4) The third table value f3(t) is set such that, for example, the attenuation increases as the probability of the app being used at each time point increases, and as the power consumption of the app being used increases. Furthermore, if a driving route is set by a navigation system, the third table value f3(t) may also be set considering the app usage predicted from the driving route.

[0090] The predicted value S4 for "data capacity" may be calculated according to equation (5) using the fourth table value f4(t), which is set based on the application's actual usage or usage plan and the data capacity each application requires when executing a process, with Dm being the maximum available data capacity.

[0091] S4[%]=Dm×f4(t) (5) The fourth table value f4(t) is calculated from the results of aggregating app usage data on a time axis representing the elapsed time starting from the moment the IG-ON was activated. It is set based on the probability of each app being used at each time point and the data capacity required when each app is executed. App usage plans may be used instead of app usage data.

[0092] The predicted values ​​S5 and S6 for "equipment availability" may be calculated using the fifth table values ​​f5(t) and sixth table values ​​f6(t), which are set from the usage history or usage plan of equipment that may be accessed by multiple applications (e.g., cameras, special image processing, etc.). Predicted value S5 is the probability that the equipment is available and not in use, and may be calculated according to equation (6). Predicted value S6 is the probability that the equipment is in use and not available, and may be calculated according to equation (7).

[0093] S5[%] = 100 × f5(t) (6) S6[%] = 100 × f6(t) (7) The predicted value S7 for "communication availability" may be calculated using equation (8), where C[%] is the current communication status, or it may be calculated using equation (9), where f7(t), the seventh table value representing the communication status estimated from the vehicle's travel plan, is used. The current communication status C may be, for example, the ratio of the measured actual communication speed to the maximum communication speed. The seventh table value f7(t) takes a value between 0 and 1.

[0094] S7[%]=C / t (8) S7[%]=100×f7(t) (9) When a driving route is set by the navigation system, the value of Table 7 f7(t) may be reduced depending on the surrounding environment of the driving route. For example, at the scheduled times of passing through tunnels or clusters of buildings, the communication condition may deteriorate, so the value of Table 7 f7(t) may be reduced.

[0095] The first to seventh table values ​​f1(t) to f7(t) may be prepared individually for each season, time of day, and driver.

[0096] The reservation arbitration unit 851 executes reservation arbitration processing, which processes requests from the service provision unit 6 via the confirmation API 73 or reservation API 74 of the API unit 71.

[0097] [4. Processing] The reservation arbitration process performed by the reservation arbitration unit 851 will be explained with reference to the flowchart in Figure 6. The reservation arbitration process is initiated by receiving a second command from the vehicle service unit 7.

[0098] When the reservation arbitration process is initiated, in S110, the reservation arbitration unit 851 determines whether the received second command is a "resource confirmation" request. A "resource confirmation" request is a request input via the confirmation API 73. A "resource confirmation" request includes an application ID that identifies the requesting application and an API_ID, which is identification information that identifies the function API 72 (hereinafter referred to as the API to be confirmed) to be used. A "resource confirmation" request may also include information that specifies the time period to be predicted.

[0099] If the reservation arbitration unit 851 determines that the received second command is a "resource confirmation" request, it proceeds to S120; otherwise, it proceeds to S150.

[0100] In S120, the reservation arbitration unit 851 refers to the necessary resource information stored in the information storage unit 853 and obtains information regarding the resources required to execute the API to be checked (hereinafter referred to as "necessary resources").

[0101] In the subsequent S130, the reservation arbitration unit 851 queries the status prediction unit 852 to obtain a resource utilization forecast. The resource utilization forecast shows, for example, the fluctuations in resource utilization forecasts within a specified time range for each resource. If a time range is specified in the "resource confirmation" request, it follows that specification; if no time range is specified, it shows the utilization forecast from the present time to a certain period of time later (for example, 24 hours).

[0102] In the subsequent S140, the reservation arbitration unit 851 generates a "Resource Prediction Response" notification based on the information regarding the required resources obtained in S120 and the resource utilization forecast obtained in S130, and sends it to the requesting application via the API unit 71 to terminate the process. The "Resource Prediction Response" notification includes the API_ID, which is identification information for identifying the API to be checked, and the start and end times of the time period during which the API to be checked can be used (hereinafter referred to as the "Available Time Period"). The Available Time Period is a time period extracted on the condition that the amount of available resources estimated from the resource utilization forecast has a margin of at least a predetermined lower limit relative to the amount of resources required by the API to be checked. Multiple Available Time Periods may exist. The "Resource Prediction Response" notification may also include the probability that the API to be checked can actually be used during the Available Time Period (hereinafter referred to as the "Availability Probability") and the resource utilization forecast obtained in S130. The information attached to the "Resource Prediction Response" notification, including the available time slots, the probability of availability, and the resource utilization forecast, constitutes the reference information in this disclosure.

[0103] In S150, the reservation arbitration unit 851 determines whether the received second command is an "API usage reservation" request. An "API usage reservation" request is a request entered via the reservation API 74. An "API usage reservation" request includes an application ID that identifies the requesting application, an API-ID that identifies the function API 72 to be reserved (hereinafter referred to as the reserved API), and usage information that indicates the usage conditions for the reserved API. The usage information includes at least usage time information that specifies the usage time period for the reserved API. The usage time information includes start conditions for starting the use of the reserved API and end conditions for ending its use. The start and end conditions may be specific times, or they may be the occurrence of some event, such as IG-ON detection and arrival at the destination. The end condition may be the elapsed time since the start of use. The usage information may optionally include information that specifies the resources to be used (hereinafter referred to as specified resources). The specified resources may include, for example, the upper limit of time allowed for communication with an external server such as the center 35.

[0104] If the reservation arbitration unit 851 determines that the second instruction is an "API usage reservation" request, it proceeds to S160; otherwise, it terminates the process.

[0105] In S160, the reservation arbitration unit 851 obtains information regarding the resources required for the API to be reserved, in the same manner as in S120. At this time, if the start and end conditions of the usage time information are not specified in terms of time, the unit performs a process to convert them into a start time estimated from the start condition and an end time estimated from the end condition.

[0106] In the subsequent S170, the reservation arbitration unit 851 obtains a resource utilization forecast using the same method as in the previous S130.

[0107] In the subsequent S180, the reservation arbitration unit 851 determines whether the resources necessary for executing the reserved API can be prepared during the usage time period indicated by the usage time information, that is, whether the resources are sufficient. Specifically, if the amount of available resources identified from the resource usage forecast obtained in S170 is greater than the amount of resources required for the reserved API obtained in S160, it is determined that the resources are sufficient. In other words, the ability to execute the reserved API is determined by whether or not the resources are sufficient.

[0108] If the reservation arbitration unit 851 determines that there are sufficient resources to execute the reservation API during the usage time period, it proceeds to S190; otherwise, it proceeds to S200.

[0109] In S190, the reservation arbitration unit 851 sends a "reservation successful" notification via the API unit 71 to the application that requested the reservation, indicating that the reservation made by the "API usage reservation" request (hereinafter referred to as the "reserved reservation") has been successful. Furthermore, the reservation arbitration unit 851 stores the reservation information indicating the details of the successful reservation in the information storage unit 853 and terminates processing. The "reservation successful" notification includes the API-ID of the API to be reserved, the reservation start time, and the reservation end time. The reservation information stored in the information storage unit 853 is reflected in the resource usage status prediction by the status prediction unit 852.

[0110] In S200, the reservation arbitration unit 851 determines whether there are any conflicting reservations among the reservation information stored in the information storage unit 853 that have a lower priority than the accepted reservation. A conflicting reservation is another confirmed reservation whose usage time overlaps with the accepted reservation. Priority may be assigned to the requesting application, to the reservation target API, depending on the application manufacturer, or depending on whether the application is installed in the vehicle or on an external server. Priority may be assigned to reservations with shorter reservation times. Priority may also be differentiated based on whether or not there is a charge and the charge grade.

[0111] The reservation mediation unit 851 proceeds to S210 if there is a competing reservation with a lower priority than the accepted reservation, and proceeds to S240 if there is no competing reservation with a lower priority.

[0112] In S210, the reservation mediation unit 851 sends a "reservation confirmed" notification to the app that requested the reservation via the API unit 71, and also sends a "reservation cancelled" notification to the app that requested the competing reservation (hereinafter referred to as the competing app) via the API unit 71. The "reservation cancelled" notification shows the details of the cancelled reservation. The "reservation cancelled" notification may also show the reason why the reservation was cancelled. Furthermore, the reservation mediation unit 851 stores the reservation information showing the confirmed reservation details in the information storage unit 853, and deletes the reservation information regarding the competing reservation from the information storage unit 853.

[0113] In the subsequent S220, the reservation arbitration unit 851 determines whether a conflicting reservation can be executed under certain conditions when an accepted reservation has been confirmed. If it is conditionally executable, the process moves to S230; if it is conditionally impossible to execute, the process terminates. Conditional execution may include cases where execution is possible by changing the time zone, and cases where execution is possible by limiting the amount of resources used per unit time, thereby allowing an increase in the processing time. Resource usage may include CPU usage and communication volume with the center 35, etc.

[0114] In S230, the reservation arbitration unit 851 sends a "reservation change proposal" notification to the competing application via the API unit 71. The "reservation change proposal" notification includes the API-ID of the reservation target API, the application ID of the requesting application, and the proposed reservation change. The proposed content includes the time period during which changes are possible, and the start and end times that will be changed by restricting resources.

[0115] Furthermore, a competing app may, based on the content of the received "Reservation Change Proposal" notification, resend an "API Usage Reservation" request accepting the proposal.

[0116] In S240, the reservation arbitration unit 851 determines whether the accepted reservation can be executed under certain conditions. If it can be executed under certain conditions, the process moves to S250. If it cannot be executed even under certain conditions, the process moves to S260. The determination of whether it can be executed under certain conditions is the same as described in S220.

[0117] In S250, the reservation mediation unit 851 sends a "reservation change proposal" notification to the requesting application of the reservation, and then terminates the process.

[0118] In S260, the reservation mediation unit 851 sends a "reservation unsuccessful" notification to the requesting application for the reservation and terminates the process. The "reservation unsuccessful" notification includes the API-ID of the reservation target API and the application ID of the requesting application. The "reservation unsuccessful" notification may also include information indicating the reason for the unsuccessful reservation.

[0119] Here, we provide an example of a proposed reservation change in a case where, under the conditions specified in the "API usage reservation" request from the requesting application, executing the reserved API may result in insufficient CPU usage, communication volume, or data capacity, potentially preventing execution as requested.

[0120] If the conditions specified in the "API usage reservation" request are, for example, to execute instructions to take, process, and upload an image once every second for a continuous period of 5 minutes, we propose changing the shooting interval to a longer duration (for example, once every 2 seconds). In this case, the length of the time period during which the reserved API will be used may also be changed in conjunction with the change in the shooting interval.

[0121] Furthermore, if the conditions specified in the "API usage reservation" request include, for example, a 5-minute data download via wireless communication (i.e., OTA), we propose changing the allowable download time to be extended (for example, to 1 hour).

[0122] [3. Operation] [3-1.Basic operation] Next, the basic operation of the vehicle control system 1 will be explained with reference to the sequence diagram in Figure 7.

[0123] As shown in Figure 7, in S10, application A, which belongs to the service provision unit 6, uses the verification API 73 to send a "resource confirmation" request in the form of the first command to the API unit 71 of the vehicle service unit 7.

[0124] The API unit 71 performs a format check and an authorization check on the received "resource confirmation" request. If both are deemed compliant, it converts the "resource confirmation" request from the format of the first command to the format of the second command. Then, in S11, the API unit 71 sends the "resource confirmation" request, which has been converted to the format of the second command, to the reservation arbitration unit 851 of the status management unit 8.

[0125] When the reservation arbitration unit 851 receives the "resource confirmation" request, which has been converted into a second command, in S12 it obtains the necessary resources for the API to be confirmed, which is identified from the API_ID indicated in the "resource confirmation" request, from the information storage unit 853. Furthermore, in S13, the reservation arbitration unit 851 sends an "inquiry" to the state prediction unit 852.

[0126] When the status prediction unit 852 receives an "inquiry" from the reservation mediation unit 851, it predicts the resource usage status in S14 and sends a "response" indicating the prediction result back to the reservation mediation unit 851 in S15.

[0127] When the reservation arbitration unit 851 receives a "response" to the "inquiry" from the status prediction unit 852, in S16 it extracts the available time period, which is information to be provided to the requesting application, based on the prediction result shown in the "response" and the required resources obtained in S12. Furthermore, in S17, the reservation arbitration unit 851 sends a "resource prediction response" notification to the API unit 71, which shows the information extracted in S16.

[0128] In S18, the API unit 71 sends the "Resource Prediction Response" notification received from the reservation mediation unit 851 to application A, which is the application that requested the "Resource Confirmation" request.

[0129] In S20, application A uses the reservation API 74 to send an "API usage reservation" request to the API unit 71 in the form of the first command. The content of the "API usage reservation" request may be set considering the information shown in the "Resource prediction response" notification, or it may be set independently of the "Resource prediction response" notification.

[0130] When the API unit 71 receives an "API usage reservation" request, it performs a format check and an authorization check in S21, similar to the case of a "resource confirmation" request. If the check is successful, it converts the "API usage reservation" request from the format of the first instruction to the format of the second instruction and sends it to the reservation arbitration unit 851.

[0131] When the reservation arbitration unit 851 receives an "API usage reservation" request, in S22 it obtains the necessary resources for the reservation target API, identified from the API_ID indicated in the "API usage reservation" request, from the information storage unit 853. Furthermore, in S23, the reservation arbitration unit 851 sends an "inquiry" to the state prediction unit 852.

[0132] When the status prediction unit 852 receives an "inquiry" from the reservation mediation unit 851, it predicts the resource usage status in S24 and sends a "response" indicating the prediction result back to the reservation mediation unit 851 in S25.

[0133] When the reservation mediation unit 851 receives a "response" to the "inquiry" from the status prediction unit 852, it determines in S26 whether the reservation is possible. The decision on whether the reservation is possible is based on the prediction result shown in the "response," the start and end conditions shown in the "API usage reservation" request, and the necessary resources obtained in S22.

[0134] If, after determining whether a reservation is possible, the reservation arbitration unit 851 determines that the reserved API can be executed under the start and end conditions specified in the "API usage reservation" request, it sends a "reservation successful" notification to the API unit 71. The reservation arbitration unit 851 then stores the reservation information representing the successful reservation details in the information storage unit 853.

[0135] In S29, the API unit 71 sends the "Reservation Confirmed" notification received from the reservation mediation unit 851 to application A, which is the application that made the "API Usage Reservation" request.

[0136] [3-2. Behavior during reservation conflicts] Referring to Figure 8, the behavior when there are conflicting reservations will be explained. Here, we assume that while App A has an existing reservation, App B sends an "API reservation" request to the API section 71 that uses the same resources as App A's reservation.

[0137] First, let's explain the cases in which a reservation can be made via app B, regardless of whether a reservation has been made via app A.

[0138] As shown in Figure 8, application B sends an "API usage reservation" request in S30. The processing in S32 to S38, which is carried out by the API unit 71, reservation arbitration unit 851, and state prediction unit 852, is the same as the processing in S21 to S28 described earlier.

[0139] However, in S36, even if a competing application A is running simultaneously, it is determined that a reservation is possible because there is sufficient resources available. Also, in S38, the reservation arbitration unit 851 stores reservation information representing the details of the reservation established by the "API usage reservation" request from application B in the information storage unit 853.

[0140] In S39, the API unit 71 sends the "Reservation Confirmed" notification received from the reservation mediation unit 851 to application B, which is the application that made the "API Usage Reservation" request.

[0141] Next, we will explain the case where a reservation made through app A has higher priority than a reservation made through app B.

[0142] Since the processing in S30 to S35 is the same as described above, we will omit the explanation and only explain the processing from S35 onwards.

[0143] When the reservation arbitration unit 851 receives a "response" to the "inquiry" from the status prediction unit 852, it determines in S40 whether the reservation can be made. The determination of whether the reservation can be made is based on the prediction result shown in the "response," the start and end conditions shown in the "API usage reservation" request, and the necessary resources obtained in S32. In this case, it is determined that the reservation cannot be executed under the conditions shown in the "API usage reservation" request from app B, and the reservation arbitration unit 851 sends either a "reservation unsuccessful" notification or a "reservation change proposal" notification to the API unit 71 in S41. The "reservation change proposal" notification is sent when the reservation can be executed by changing the reservation details, and the "reservation unsuccessful" notification is sent when the reservation cannot be executed even if the reservation details are changed.

[0144] In S42, the API unit 71 sends the "Reservation Failed" notification or "Reservation Change Proposal" notification received from the reservation mediation unit 851 to application B, which is the application that made the "API Use Reservation" request.

[0145] Next, we will explain the case where a reservation made through app A has a lower priority than a reservation made through app B.

[0146] Since the processing in S30 to S35 is the same as described above, we will omit the explanation and only explain the processing from S35 onwards.

[0147] When the reservation arbitration unit 851 receives a "response" to the "inquiry" from the status prediction unit 852, it determines in S50 whether the reservation can be made. The determination of whether the reservation can be made is based on the prediction result shown in the "response," the start and end conditions shown in the "API usage reservation" request, and the necessary resources obtained in S32. In this case, it is determined that the reservation can be made under the conditions shown in the "API usage reservation" request from app B. Then, in S51, the reservation arbitration unit 851 sends a "reservation successful" notification to app B to the API unit 71, and in S52, it sends a "reservation cancellation" notification to app A to the API unit 71. If the usage reservation by app A can be made by changing the conditions, in addition to the "reservation cancellation" notification, a "reservation change proposal" notification showing the changes is also sent. Alternatively, instead of sending a "reservation change proposal" notification, information about the changes shown in the "reservation change proposal" notification may be added to the "reservation cancellation" notification.

[0148] In S53, the reservation mediation unit 851 deletes the reservation information for application A from the information storage unit 853 and saves the reservation information for application B to the information storage unit 853.

[0149] In S54, the API unit 71 sends the "Reservation Confirmed" notification received from the reservation mediation unit 851 to app B, which is the requesting app for the "API Use Reservation" request. In S55, the API unit 71 also sends the "Reservation Cancellation" notification and the "Reservation Change Proposal" notification to app A, which is a competing app.

[0150] [5. Correspondence of Terms] In this embodiment, the reservation arbitration unit 851 that executes the processes S120 to S140 corresponds to the information generation unit of this disclosure, the confirmation API 73 corresponds to the information provision unit of this disclosure, and the center 35 corresponds to the external device of this disclosure. In this embodiment, the reservation arbitration unit 851 that executes the process S160 corresponds to the required amount acquisition unit, the reservation arbitration unit 851 that executes the processes S170 to S260 corresponds to the reservation feasibility determination unit, and the reservation arbitration unit 851 that executes the processes S220 and S250 corresponds to the change proposal unit.

[0151] [6. Effects] The embodiments described in detail above produce the following effects.

[0152] (1) The vehicle control system 1 includes a verification API 73 that each application 61 to 64 belonging to the service provision unit 6 uses to check the time period during which a specified API is available. Therefore, each application 61 to 64 can select a time period that does not conflict with other applications and execute control using the desired API. In other words, in use cases where multiple applications 61 to 64 (i.e., multiple systems existing inside and outside the vehicle) each arbitrarily access resources, it is possible to suppress the occurrence of conflicts in access requests. Furthermore, it is possible to suppress situations in which resources become insufficient due to conflicts in access requests.

[0153] (2) The "Resource Prediction Response" notification sent in response to a "Resource Confirmation" request using the confirmation API 73 probabilistically shows the predicted usage status of each resource. Therefore, the application can make flexible decisions regarding the timing of API execution based on the notified prediction results.

[0154] (3) The vehicle control system 1 includes a reservation API 74 that each application 61 to 64 belonging to the service provision unit 6 uses to reserve the resources necessary to execute a specified API. Therefore, even if there are multiple applications that operate independently of each other, each application can execute its processing as scheduled because resources for the reserved time period are secured.

[0155] (4) Reservations made using the reservation API 74 are reflected when predicting resource usage, thereby improving the accuracy of resource usage predictions.

[0156] (5) When processing an "API usage reservation" request, if there are conflicting usage reservations and executing all of them would result in insufficient resources, the higher priority request will be accepted, and a reservation change proposal will be made for the lower priority request. The reservation change proposal may include changing the usage time slot or limiting resources. Therefore, not only can the higher priority request be reliably executed, but the execution schedule for the lower priority request can also be easily and quickly changed according to the reservation change proposal.

[0157] [7. Other Embodiments] Although embodiments of the present disclosure have been described above, the present disclosure is not limited to the embodiments described above and can be implemented in various modified forms.

[0158] (a) In the above embodiment, the conversion from the first command to the second command was shown as an example of being performed by the vehicle service unit 7, but it may also be performed by the status management unit 8, for example.

[0159] (b) In the above embodiment, examples of nonconformity reasons include "format nonconformity," "authorization nonconformity," "equipment nonconformity," and "scene nonconformity," but other examples such as "priority nonconformity" and "communication timeout" may also be included. If the nonconformity reason is "priority nonconformity," the suggestion information may indicate the priority level that is determined to be compliant.

[0160] (c) In the above embodiment, reference information to be added to the "Resource Prediction Response" notification is generated each time in accordance with the "Resource Confirmation" request. For example, in the above embodiment, reference information may be prepared in advance by generating it periodically, and this prepared reference information may be added to the "Resource Prediction Response" notification.

[0161] (d) In the above embodiment, each application 61 to 64 is configured to obtain reference information via the verification API 73, but the reference information may also be provided by storing the reference information in a shared memory accessible from each application 61 to 64. Alternatively, instead of using the verification API 73 belonging to the API unit 71, the reference information may be provided using APIs provided by the applications 61 to 64.

[0162] (e) In the above embodiment, the first ECU 10, the second ECU 15, and the center 35 are equipped with a service provision unit 6, the first ECU 10 is equipped with a vehicle service unit 7, the first ECU 10 and the third ECU 20 to fifth ECU 30 are equipped with a status management unit 8, and the fifth ECU 30 to thirteenth ECU 48 are equipped with an equipment management unit 9. The number of ECUs belonging to the ECU group 100, and the way in which the functions of the service provision unit 6, vehicle service unit 7, status management unit 8, and equipment management unit 9 are assigned to each ECU are not limited to those illustrated in the embodiment and are arbitrary.

[0163] (f) Multiple functions of one component in the above embodiment may be realized by multiple components, or one function of one component may be realized by multiple components. Also, multiple functions of multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Furthermore, some of the configurations of the above embodiment may be omitted. Furthermore, at least some of the configurations of the above embodiment may be added to or replaced with the configurations of other above embodiments.

[0164] (g) In addition to the vehicle control device described above, the disclosure can also be implemented in various forms, such as a program for making a computer function as a vehicle control device, a non-transitional physical recording medium such as a semiconductor memory on which this program is recorded, and a vehicle control method.

[0165] [8. The technical concept disclosed herein] [Item 1] A vehicle control device installed in a vehicle, The equipment management unit (9) is configured to perform control over the vehicle equipment, which is equipment that the vehicle has, and to manage the status of the vehicle equipment. In order to receive requests from application software and realize functions using the vehicle equipment managed by the equipment management unit, the API unit (71) has a function API (72) which is an interface provided for each of the functions, A state prediction unit (852) configured to predict the state of the resources of the vehicle within a specified time range, An information generation unit (851:S120~S140) is configured to generate reference information for each of the function APIs, including the time period during which the function API can be used, based on the prediction results from the state prediction unit, An information providing unit (73) is configured to provide the reference information generated by the information generation unit with respect to the functional API specified by the request from the application software, A vehicle control device equipped with the following features.

[0166] [Item 2] The vehicle control device described in item 1, The resources to be predicted by the state prediction unit include at least one of the following: the vehicle's power status, the CPU usage rate for processing related to the function API, the remaining capacity of the battery installed in the vehicle, the availability of the vehicle equipment to be controlled, and the ability to communicate with an external device located outside the vehicle. Vehicle control system.

[0167] [Item 3] A vehicle control device as described in item 1 or item 2, The aforementioned reference information is expressed as the probability that the availability of the aforementioned API will change over time. Vehicle control system.

[0168] [Item 4] A vehicle control device described in any one of items 1 to 3, The API unit further includes a reservation API (74) that accepts reservations for the use of the function API, The aforementioned reservation includes identification information that identifies the reservation target API, which is the functional API to be reserved, and usage information that indicates the usage conditions for the reservation target API. Based on the aforementioned identification information, a required quantity acquisition unit (851:S160) is configured to acquire the required amount of the resources necessary for executing the aforementioned reservation, A reservation feasibility determination unit (851:S170~S260) is configured to determine whether the reservation can be executed under the usage conditions indicated in the usage information, based on the prediction results from the state prediction unit and the acquisition results from the required quantity acquisition unit, and to notify the requester of the reservation of the determination result, A vehicle control system further equipped with the following features.

[0169] Vehicle control system.

[0170] [Item 5] A vehicle control device as described in item 4, The aforementioned usage conditions include at least one of the following: specifying the time period during which the reserved API will be used, and specifying the maximum time required for processing using the reserved API. Vehicle control system.

[0171] [Item 6] A vehicle control device as described in item 4 or item 5, The aforementioned reservation includes information indicating the priority of the reservation. The reservation feasibility determination unit is configured to determine that a reservation can be made if a low-priority conflict reservation exists and the reservation can be made by canceling the low-priority conflict reservation. The aforementioned reservation is the reservation received by the reservation API. The aforementioned low-priority competing reservation is a confirmed reservation that uses the same resources as the aforementioned acceptance reservation and has a lower priority than the aforementioned acceptance reservation. Vehicle control system.

[0172] [Item 7] A vehicle control device described in any one of items 4 to 6, The state prediction unit is configured to reflect the acquisition results from the required quantity acquisition unit in the prediction results for the usage reservation for which the reservation has been confirmed. Vehicle control system.

[0173] [Item 8] A vehicle control device described in any one of items 4 through 7, The system further includes a change proposal unit (851:S220,S250) configured to notify the requester of the reservation of a reservation change proposal indicating the feasible usage conditions if the reservation is deemed unexecutable by the reservation feasibility determination unit, and if it is possible to execute the reservation by changing the usage conditions. Vehicle control system.

[0174] [Item 9] A vehicle control device described in any one of items 1 through 8, The information provision unit is configured to provide the reference information to the application software via a verification API provided in the API unit. Vehicle control system.

Claims

1. A vehicle control device installed in a vehicle, The equipment management unit (9) is configured to perform control over the vehicle equipment, which is equipment that the vehicle has, and to manage the status of the vehicle equipment. The API unit (71) has a function API (72), which is an interface provided for each of the functions, in order to receive requests from application software and realize functions using the vehicle equipment managed by the equipment management unit, A state prediction unit (852) configured to predict the state of the vehicle's resources within a specified time range, An information generation unit (851: S120 to S140) is configured to generate reference information for each of the function APIs, including the time period during which the function API can be used, based on the prediction results from the state prediction unit, An information providing unit (73) is configured to provide the reference information generated by the information generation unit with respect to the function API specified by the request from the application software, A vehicle control device equipped with the following features.

2. A vehicle control device according to claim 1, The resources to be predicted by the state prediction unit include at least one of the following: the vehicle's power status, the CPU usage rate for processing related to the function API, the remaining capacity of the battery installed in the vehicle, the availability of the vehicle equipment to be controlled, and the ability to communicate with an external device located outside the vehicle. Vehicle control system.

3. A vehicle control device according to claim 1, The aforementioned reference information is expressed as the probability that the availability of the API function will change over time. Vehicle control system.

4. A vehicle control device according to claim 1, The API unit further includes a reservation API (74) that accepts reservations for the use of the function API, The aforementioned reservation includes identification information that identifies the reservation target API, which is the functional API to be reserved, and usage information that indicates the usage conditions for the reservation target API. Based on the aforementioned identification information, a required quantity acquisition unit (851: S160) is configured to acquire the required amount of the resources necessary for executing the aforementioned reservation, A reservation feasibility determination unit (851: S170 to S260) is configured to determine whether the reservation can be executed under the usage conditions indicated in the usage information, based on the prediction results from the state prediction unit and the acquisition results from the required quantity acquisition unit, and to notify the requester of the reservation of the determination result. A vehicle control system further equipped with the following features. Vehicle control system.

5. A vehicle control device according to claim 4, The aforementioned usage conditions include at least one of the following: specifying the time period during which the reserved API will be used, and specifying the maximum time required for processing using the reserved API. Vehicle control system.

6. A vehicle control device according to claim 4, The aforementioned reservation includes information indicating the priority of the reservation. The reservation feasibility determination unit is configured to determine that a reservation can be made if a low-priority conflict reservation exists and the reservation can be made by canceling the low-priority conflict reservation. The aforementioned reservation is the reservation received by the reservation API. The aforementioned low-priority competing reservation is a confirmed reservation that uses the same resources as the aforementioned acceptance reservation and has a lower priority than the aforementioned acceptance reservation. Vehicle control system.

7. A vehicle control device according to claim 4, The state prediction unit is configured to reflect the acquisition results from the required quantity acquisition unit in the prediction results for the usage reservation for which the reservation has been confirmed. Vehicle control system.

8. A vehicle control device according to claim 4, The system further includes a change proposal unit (851: S220, S250) configured to notify the requester of the reservation of a reservation change proposal indicating the feasible usage conditions if the reservation is deemed unexecutable by the reservation feasibility determination unit, and if it is possible to execute the reservation by changing the usage conditions. Vehicle control system.

9. A vehicle control device according to claim 1, The information provision unit is configured to provide the reference information to the application software via a verification API provided in the API unit. Vehicle control system.

10. A vehicle control method performed by a computer installed in the vehicle, The equipment management unit of the aforementioned computer performs control over the vehicle equipment, which is the equipment of the vehicle, and manages the status of the vehicle equipment. The API unit of the computer receives requests from application software and provides function APIs, which are interfaces provided for each of the functions, in order to realize functions that utilize the vehicle equipment managed by the equipment management unit. The state prediction unit of the aforementioned computer predicts the state of the vehicle's resources within a specified time range. The information generation unit of the computer generates reference information for each of the function APIs, including the time period during which the function API is available, based on the prediction results from the state prediction unit. The information provision unit of the computer provides the reference information generated by the information generation unit with respect to the function API specified by the application software in response to a request. Vehicle control method.