Vehicle control system

Abstract

Provided is a vehicle control system (1). The vehicle control system comprises a first acceptance determining unit (S110), a first output unit (S255), a second acceptance determining unit (S150), and a second output unit (S410). The first output unit outputs a second command based on a first command if the first acceptance determining unit determines that acceptance is possible. If the first acceptance determining unit determines that acceptance is not possible, the second acceptance determining unit uses resource information to determine whether it will be possible for the first command to be accepted within a set predetermined time. If the second acceptance determining unit determines that it will be possible for the first command to be accepted within the predetermined time, the second output unit waits until the first command can be accepted, and then outputs the second command to an operation control program.

Description

Vehicle Control System CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This international application claims priority based on Japanese Patent Application No. 2023-080017, filed with the Japan Patent Office on May 15, 2023, the entire contents of which are incorporated herein by reference.

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

[0003] Patent Document 1 describes a technology for collecting information only under circumstances specified by the server in a vehicle data collection system that collects various vehicle data from multiple vehicles via sensors mounted on the vehicles, in order to make effective use of system resources.

[0004] Patent No. 7156091

[0005] With the spread of vehicle APIs, it is expected that multiple application software (hereinafter referred to as applications or apps) will access the same vehicle in the future. A vehicle API is an interface for providing vehicle functions to applications, etc., implemented inside or outside the vehicle.

[0006] When multiple applications exist inside and outside a vehicle and each application is executed, each application accesses the vehicle at its own timing, which causes conflicts for access to the same vehicle. As a result of detailed investigation by the inventors, it was found that the conventional technology is a technology for controlling the load within a single system, and therefore it is not possible to control the load when there is conflict with other systems.

[0007] One aspect of the present disclosure is to provide a technique for suppressing conflicts among requests for access to vehicle functions from multiple applications.

[0008] One aspect of the present disclosure is a vehicle control system mounted on a vehicle and including at least one vehicle control device and an operation control device, the vehicle control system including a first acceptance / determination unit, a first output unit, a second acceptance / determination unit, and a second output unit.

[0009] The first reception determination unit is configured to, when a first command is input from an application, determine whether the first command can be received by using resource information related to the processing capacity of a resource used in the first command. The first output unit is configured, when the first reception determination unit determines that the first command can be received, to output a second command based on the first command to an operation control program installed in the operation control device, the operation control program being for controlling the control target.

[0010] The second reception determination unit is configured to determine whether the first command will be acceptable within a set predetermined time period using the resource information when the first reception determination unit determines that the first command is unacceptable. The second output unit is configured to wait until the first command is acceptable and then output the second command to the operation control program when the second reception determination unit determines that the first command will be acceptable within the predetermined time period.

[0011] With this configuration, if requests to access vehicle functions from multiple applications cannot be accepted, the requests can wait until they become available within a predetermined time, thereby controlling the vehicle resources to avoid shortages within the range that the vehicle system can tolerate.

[0012] FIG. 1 is a block diagram showing the configuration of a vehicle control system; FIG. 2 is a block diagram showing the configuration of an ECU; FIG. 3 is a block diagram showing the configuration of a center; FIG. 4 is a block diagram showing the functional configuration of a vehicle control system; FIG. 5 is an explanatory diagram illustrating an example of the contents of required resource information; FIG. 6 is a sequence diagram showing the flow of processing corresponding to request A; and FIG. 7 is a flowchart showing acceptance determination processing.

[0013] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings.

[0014] [1. Correspondence between the configuration of the embodiment and the configuration of the present disclosure] ECUs 10, 15, 20, 25, and 30 in the embodiment correspond to vehicle control devices in the present disclosure, ECUs 41 to 48 in the embodiment correspond to operation control devices in the present disclosure, and control units 91 to 99 in the embodiment correspond to operation control programs in the present disclosure.

[0015] Furthermore, the process of S110 corresponds to the function of a first reception determination unit in the present disclosure, the process of S255 in the embodiment corresponds to the function of a first output unit in the present disclosure, the process of S150 in the embodiment corresponds to the function of a second reception determination unit in the present disclosure, the process of S410 in the embodiment corresponds to the function of a second output unit in the present disclosure, the processes of S260 and S360 in the embodiment correspond to the function of a determination transmission unit in the present disclosure, and the process of S130 in the embodiment corresponds to the function of a third reception determination unit in the present disclosure.

[0016] 1 includes an electronic control unit (hereinafter, referred to as ECU) group 100 mounted on a vehicle such as an automobile, and a center 35. The ECU group 100 includes a plurality of ECUs. In this embodiment, the ECU group 100 includes 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. The ECUs belonging to the ECU group 100 are connected to each other via in-vehicle communication (i.e., wired communication or wireless communication). The center 35 is provided outside the vehicle and is connected to the ECU group 100 via out-of-vehicle communication (i.e., wireless communication).

[0017] The first ECU 10 has a relay function for in-vehicle communications and realizes coordinated control of the entire vehicle by controlling the second to fifth ECUs 15 to 30. The first ECU 10 also controls communications with the center 35, thereby realizing coordinated control of the entire system including the center 35.

[0018] The first ECU 10 and the third to fifth ECUs 20 to 30 are provided for each domain, which is divided according to the vehicle's function, and mainly control multiple ECUs (i.e., any of the sixth to thirteenth ECUs 41 to 48) that exist within that domain. The domains are, for example, the powertrain, the body, the chassis, and the cockpit.

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

[0020] The vehicle equipment may include hardware such as sensors and actuators, as well as various storage devices for storing data and software for realizing certain functions.

[0021] The first ECU 10 and the third to fifth ECUs 20-30 are connected to the sixth to thirteenth ECUs 41-48 via lower-level networks (e.g., CAN) that are individually provided. CAN is an abbreviation for Controller Area Network and is a registered trademark. The first ECU 10 and the third to fifth ECUs 20-30 have the function of centrally managing access rights to the sixth to thirteenth ECUs 41-48 and authenticating users.

[0022] In another embodiment, the vehicle control system 1 may include the 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 multiple centers 35.

[0023] [2-2. Hardware Configuration] Next, the hardware configuration 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.

[0024] As shown in FIG. 2 , the first ECU 10 includes a microcomputer 11, a vehicle interface (hereinafter, I / F) 12, and a communication unit 13. The microcomputer 11 includes a CPU 11a, a ROM 11b, and a RAM 11c. The various functions of the first ECU 10 are realized by the CPU 11a executing a program stored in a non-transitory physical recording medium. In this embodiment, the ROM 11b corresponds to the non-transitory physical recording medium storing the program. Furthermore, the execution of this program causes a method corresponding to the program to be performed.

[0025] The vehicle I / F 12 connects to other ECUs and in-vehicle devices via an in-vehicle network or the like, and acquires various information from the other ECUs and in-vehicle devices. The in-vehicle network may include CAN and Ethernet. Ethernet is a registered trademark.

[0026] The communication unit 13 performs data communication with the center 35 etc. via wireless communication over a wide area communication network. However, it is not necessary for all ECUs belonging to the ECU group 100 to have the communication unit 13, and it may be provided in only one or some of the ECUs.

[0027] The method of realizing the various functions of the first ECU 10 is not limited to software, and some or all of the functions may be realized using one or more hardware elements. For example, if the functions are realized by electronic circuits that are hardware, the electronic circuits may be realized by digital circuits including multiple logic circuits, analog circuits, or a combination of these.

[0028] As shown in Figure 3, the center 35 includes a microcomputer 36, a communication unit 37, and a storage unit 38. The microcomputer 36 includes 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-transitory physical recording medium. In this embodiment, the ROM 36b corresponds to the non-transitory physical recording medium storing the program. Furthermore, by executing this program, a method corresponding to the program is performed.

[0029] The communication unit 37 performs data communication 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.

[0030] The method of realizing the various functions of the center 35 is not limited to software, and some or all of the elements may be realized using one or more pieces of hardware. For example, if the functions are realized by electronic circuits that are hardware, the electronic circuits may be realized by digital circuits including multiple logic circuits, analog circuits, or a combination of these.

[0031] 1 , various functions of the vehicle control system 1 will be described. The vehicle control system 1 has the functions of an equipment management unit 9 in a first layer, a status management unit 8 in a second layer, a vehicle service unit 7 in a third layer, and a service provision unit 6 in a fourth layer. The software architecture of the vehicle control system 1 is hierarchical in these four layers. These functions of the vehicle control system 1 are shared by each ECU belonging to the ECU group 100 and the center 35.

[0032] The equipment management unit 9 includes a plurality of control units 91 to 99 corresponding to a plurality of types of vehicle equipment, such as an on-board camera, an on-board millimeter-wave radar, brakes, a steering wheel, a display, a speaker, various lights, an on-board air conditioner, and an electric power seat.

[0033] 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 (hereinafter referred to as HVAC) control unit 98, and a seat control unit 99. The vehicle equipment is individually controlled by the corresponding control unit among the control units 91 to 99.

[0034] The camera control unit 91 controls the exposure of an in-vehicle camera (for example, the camera 91A shown in FIG. 6 ) and acquires an image captured by the in-vehicle camera. In this embodiment, the sixth ECU 91 includes the camera control unit 91.

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

[0036] The brake control unit 93 controls the brakes. In this embodiment, the eighth ECU 93 includes the brake control unit 93.

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

[0038] The display control unit 95 controls indicators (for example, meters, warning lights, etc.) In the present embodiment, the tenth ECU 45 includes the display control unit 95.

[0039] The sound control unit 96 controls the speaker to output sounds such as warning sounds, voices, etc. In this embodiment, the eleventh ECU 46 includes the sound control unit 96.

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

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

[0042] The seat control unit 99 controls an electric power seat of the vehicle. In this embodiment, the 13th ECU 48 includes the seat control unit 99.

[0043] The equipment management unit 9 operates the vehicle equipment in accordance with the operation instruction from the status management unit 8 and notifies the status management unit 8 of the operation result. For example, if the vehicle equipment is an actuator, the operation result may indicate that the actuator has completed 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.

[0044] The equipment management unit 9 may be configured to operate the vehicle equipment in accordance with an operation instruction from the status management unit 8, as well as to autonomously detect the status of the vehicle equipment and notify the status management unit 8 of the status.

[0045] [3-2. Service Providing Unit] The service providing unit 6 executes the applications 61 to 64 to realize various functions, such as information gathering, theft prevention, and remote control, by utilizing the vehicle equipment managed by the equipment managing unit 9.

[0046] In this embodiment, the first ECU 10, the second ECU 15, and the center 35 each include a service providing unit 6. The ROM 11b of the first ECU 10 stores apps 61 and 62. The ROM 11b of the second ECU 15 stores an app 63. The ROM 36b of the center 35 stores an app 64.

[0047] The applications 61 to 64 are basically configured to realize the intended services by utilizing the functions of the vehicle equipment via the API unit 71 that constitutes the vehicle service unit 7. Note that API is an abbreviation for Application Programming Interface.

[0048] The apps 61 to 64 are not dedicated programs for executing processes suited to a specific vehicle model, a specific grade, or the like, but are general-purpose programs for executing processes suited to many vehicle models, grades, and the like. Therefore, the apps 61 to 64 are written using publicly available modeled vehicle functions so that they can be created without considering the vehicle equipment and performance of individual vehicles. In other words, the apps 61 to 64 can be easily developed by third parties, who are app providers other than OEMs, and the developed apps can be widely released. Therefore, a vehicle user who owns a vehicle equipped with the ECU group 100 can install an app released by a third party into any of the ECU group 100 via a wide-area communication network or the like. Furthermore, the vehicle user can add or modify the apps 61 to 64 as desired.

[0049] In the case of an app used to provide a service that acquires vehicle information from many vehicles and analyzes the vehicle behavior, the driver's driving operations, and the like, a service provider that provides the app may, with the permission of the vehicle user, install the app in one of the ECU group 100. Furthermore, access rights to individual APIs belonging to the API unit 71 from apps installed in the center 35 by the service provider or the like may be restricted by the vehicle user for each service provider or each app.

[0050] [3-3. Vehicle Service Unit] The vehicle service unit 7 includes an 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 the apps 61 to 64 belonging to the service providing unit 6 for accessing subdivided vehicle functions.

[0051] The vehicle API has a standardized syntax that allows requests to be written without depending on a specific vehicle model or grade. When using a function provided by the vehicle, the applications 61 to 64 send a first command using the vehicle API. The first command is a command that indicates information required when using the vehicle API.

[0052] The first command may include a command indicating the request content, a command such as an argument, a function call, etc. The first command may also include priority information indicating which command should be given priority for processing. The priority may be set, for example, depending on whether the manufacturer of the application requesting the first command is an OEM or a third party other than the OEM. OEM stands for Original Equipment Manufacturer. Specifically, an OEM may be given a higher priority than a third party. Among OEMs, a vehicle manufacturer may be given a higher priority than a parts / application manufacturer. The priority may also be set according to the type of control.

[0053] The syntax of the vehicle API, i.e., the format of the first command, is written using publicly available modeled vehicle functions so that the first command can be created without considering the vehicle equipment and performance of each vehicle, similar to the apps 61 to 64. In other words, the first command describes the function to be realized abstractly without specifying the vehicle equipment or using expressions that depend on the performance of the vehicle equipment. For example, the first command describes the content to turn on the car finder, but does not specify specific matters that depend on each vehicle, such as how to control which vehicle equipment, such as specifying which lights to turn on out of multiple lights installed in the vehicle.

[0054] Upon receiving the first command, the API unit 71 determines whether the first command can be accepted 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 can be accepted, it converts the first command into a second command written in a format suitable for the model and grade of the target vehicle, and transmits the second command to the status management unit 8. In other words, the API unit 71 has a function of converting the first command written in a standard format handled by the service providing unit 6 into a second command written in a format specific to the vehicle handled by the status management unit 8 and the equipment management unit 9. The second command is assigned an app ID that identifies the app that sent the first command (hereinafter, the requester app). The API unit 71 also has a function of transferring a result notification, which is a response from the status management unit 8 to the requester app, to the requester app.

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

[0056] The function API 72 is a vehicle API that is used when requesting control of vehicle equipment.

[0057] The confirmation API 73 is a vehicle API used to confirm the available time periods, etc., for the specified function API 72.

[0058] The reservation API 74 is a vehicle API used when reserving the use of the specified function API 72 by specifying start conditions, end conditions, etc.

[0059] 3-4. State Management Unit As shown in FIG. 4, the state management unit 8 includes a process execution unit 80 and a reservation management unit 85.

[0060] The processing execution unit 80 processes requests from the service providing unit 6 via the function API 72 .

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

[0062] [3-4-1. Processing Execution Unit] The processing execution unit 80 includes a state recognition unit 81, a motor system equipment control unit 82, a human machine interface (hereinafter referred to as HMI) system state recognition unit 83, and a body system control unit 84.

[0063] The units 81 to 84 belonging to the process execution unit 80 are classified not by implementation means (for example, control units 91 to 99) that are likely to depend on variations in the vehicle, but by vehicle operations that are likely to be requested by the service providing unit 6. In this embodiment, the units 81 to 84 belonging to the process execution unit 80 are provided in either the first ECU 10 or the third to fifth ECUs 30 that manage the respective domains of the vehicle, as shown in FIG.

[0064] The state recognition unit 81 is responsible for recognizing the situation of the vehicle itself and its surroundings, such as the positions of the vehicle 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.

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

[0066] The HMI system status recognition unit 83 corresponds to vehicle operations related to the presentation of information to the user. The HMI system status 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 status recognition unit 83.

[0067] The body system control unit 84 controls the vehicle's body system operations related to the vehicle environment. For example, the body system control unit 84 controls vehicle equipment belonging to a light control unit 97, an HVAC control unit 98, and a seat control unit 99. In this embodiment, the fifth ECU 30 includes the body system control unit 84.

[0068] When the process execution unit 80 receives a request (i.e., the second command) from the vehicle service unit 7, it determines whether the state of the vehicle is suitable for executing the second command, and if so, instructs the equipment management unit 9 to operate the target equipment. The vehicle state suitable for executing the second command may include the target equipment being capable of realizing the function required by the second command, the execution of the second command not being prohibited in a scene estimated from the vehicle state, etc.

[0069] The processing execution unit 80 has a function of outputting an operation instruction for the target equipment to the equipment management unit 9 and providing the operation result 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 individual operation results as they are, or may be used after integrating multiple operation results and converting them into highly abstract data.

[0070] For example, the processing execution unit 80 may receive a request from the vehicle service unit 7 to collect information to understand the vehicle status, and may obtain data from a plurality of vehicle equipment as operation results from the equipment management unit 9. If data such as "vehicle speed 0 km / h," "shift position P," and "driver absent from the vehicle" are obtained as operation results, the processing execution unit 80 may convert the data into data indicating that "the vehicle is parked," and may transmit the converted data to the vehicle service unit 7 as a result notification.

[0071] Reservation Management Unit] The reservation management unit 85 is provided in, for example, the third ECU 20. However, the reservation management unit 85 may be provided in an ECU other than the third ECU 20. As shown in FIG. 4 , the reservation management unit 85 includes a reservation arbitration unit 851, a state prediction unit 852, and an information storage unit 853.

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

[0073] The resource information is information that associates an API-ID that identifies a function API 72 with a resource required to execute a process associated with that function API 72. The resource information includes the processing capacity of an operation control device (e.g., various ECUs) in response to a request from the applications 61 to 64. Note that there may be multiple resources, and even in the case of multiple resources, they will be referred to as resources in the same way. The resource may be the processing capacity of resources (e.g., devices, equipment) installed in the vehicle. Examples of resources include a CPU, storage, memory, battery, communication equipment, sensors, actuators, etc. The resource information may include the past, present, and future usage status of these resources.

[0074] The resource information required to execute the process is stored as different data for each vehicle. That is, the resource information includes characteristic information that differs depending on the vehicle model or individual vehicle. Specifically, as shown in FIG. 5 , the resource information for vehicle X and the resource information for vehicle Y as characteristic information may be set to different values.

[0075] The resource information is stored for each vehicle in, for example, the information storage unit 853. The past, present, and future (future) usage status of each resource is stored in the information storage unit 853 as characteristic information or as a table separate from the characteristic information. The past, present, and future usage status of each resource can be read and rewritten by the reservation arbitration unit 851, etc.

[0076] In addition, resource information required to execute the process includes information such as "ECUs, actuators, and sensors to be used," "current usage rate," "processing content," "resource usage rate required for processing," "execution time required for processing," "waiting time prediction," and "maximum processing time."

[0077] The "ECUs, actuators, and sensors to be used," "processing content," "resource usage rate required for processing," and "execution time required for processing" are predetermined static targets or values. However, the "execution time required for processing" may be a value calculated each time.

[0078] "ECUs, actuators, and sensors used" indicates the ECUs that execute the processing, the actuators and sensors that are the processing targets, etc. (hereinafter also referred to as "used equipment"). "Current usage rate" indicates the usage rate for each piece of used equipment. In other words, the usage rate is the resource usage rate, or the proportion at which the resource is being used. The usage rate mainly indicates the usage rate of the ECUs installed in each control unit 91 to 99, and may also include the status of the ECUs for the entire vehicle.

[0079] "Processing content" indicates the processing that can be performed for each piece of equipment being used. "Resource utilization rate required for processing" indicates the utilization rate of the resources required for each processing that can be performed. "Execution time required for processing" indicates the time required from the start to the end of each processing that can be performed. "Waiting time prediction" indicates, for each processing that can be performed, when in the future the processing is likely to start, specifically, how many milliseconds it is likely to take for the processing to be performed. In other words, future resource information is included. "Processing upper limit time" indicates, for each processing that can be performed, the upper limit of the time that the processing should be completed. The processing upper limit time is a time specified for each request. "Current utilization rate" is obtained, for example, periodically and updated each time.

[0080] The reservation information is information relating to a reservation for use of the function API 72. The reservation information is set in accordance with a request from the service providing unit 6 using the reservation API 74. The reservation information includes the function API 72 that identifies the function API 72 that is the target of the reservation, an application ID that identifies the application that made the reservation, the start time and end time of the reservation, etc.

[0081] The state prediction unit 852 responds to an inquiry from the reservation arbitration unit 851 by returning a predicted result of the usage state of the vehicle equipment (i.e., resources). The period to be predicted may be a specified time range (e.g., 24 hours) from the current time point when the request is received, or may be a time range specified by an instruction from the reservation arbitration unit 851. The resource information to be predicted includes the aforementioned "standby time prediction," and may further include "power state," "future usage rate prediction," "remaining battery capacity," "free data capacity," "equipment availability," "communication availability," etc.

[0082] The "power supply state" may include information indicating whether the IG is in the ON, ACC, or OFF state, as well as information indicating the connection status of the charging plug. The "future usage rate prediction" may include the CPU usage rate. The "standby time prediction" is obtained by the state prediction unit 852 receiving an inquiry from the reservation arbitration unit 851 and referring to the information storage unit 853, and calculating, for example, based on the sum of the execution times required for one or more other processes that must wait. The "future usage rate prediction" is, for example, information expressing the usage rate of the CPU installed in each control unit 91 to 99 as a percentage. The "future usage rate prediction" may also include information on the usage rate of the CPU installed in each ECU other than each control unit 91 to 99. The "remaining battery capacity" is information expressing the remaining capacity of the vehicle battery as a percentage. The "free data capacity" is information indicating the free memory capacity available for processing. The "equipment availability" is information indicating the results of a determination of whether the equipment is available, including whether the equipment is malfunctioning and whether the equipment is operating. The equipment for which "equipment availability" is indicated may include special image processing that requires a high processing load. "Communication availability" is information that indicates the communication status with an external server. For example, the occupancy rate of the communication channel used for communication with the external server may be indicated for each application.

[0083] The status prediction unit 852 repeatedly acquires the status of the in-vehicle equipment from the equipment management unit 9 and accumulates the results of the aggregation using a predetermined method. For example, the aggregation method uses the on / off timing of the vehicle's ignition switch as a starting point and aggregates the elapsed time from the starting point as an index. Furthermore, the aggregated values ​​may be aggregated individually for each day of the week, each season, or each driver, for example.

[0084] When receiving an inquiry from the reservation arbitration unit 851, the state prediction unit 852 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 consideration the aggregated value of past usage status and the reservation information stored in the information storage unit 853. Furthermore, the prediction of the usage status of each resource may utilize information such as whether each application has access authority to each API, the driving route set by the navigation device, the distance to the destination, and the estimated arrival time. Furthermore, the prediction of the usage status of each resource may utilize information such as a drop-off prediction extracted from an image captured by a camera capturing the interior of the vehicle, and information on the driver's schedule obtained by linking with the calendar of a mobile terminal. Furthermore, the prediction of the usage status of each resource may utilize past prediction results, whether the air conditioner is being used, etc.

[0085] Here, a method for predicting the utilization status of a source in the status prediction unit 852 will be described.

[0086] For "power supply status," if the current power supply status is IG-ON or the charging plug is connected, the probability that the current power supply status is IG-ON is set to 100%, and the predicted value S1 is gradually reduced as time passes.

[0087] There are two methods for decreasing the predicted value S1: one is to decrease it simply in inverse proportion to the passage of time, as shown in equation (1), and the other is to decrease it in accordance with a preset first table value f1(t), as shown in equation (2), where t is time, and f1(t) is a value between 0 and 1, and is set so that the value changes with the passage of time.

[0088] 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, for example, by calculating the average time from when the IG is turned on to when the IG is turned off from past history, and monotonically decreasing the value of the first table value f1(t) until it becomes approximately zero over the calculated average time.

[0089] Furthermore, when the current power supply state is IG-ON and the driving route is set by the navigation device, the first table value f1(t) may be set to a small value up to the estimated arrival time in the route guidance of the navigation device, and to a large value after the estimated arrival time.

[0090] Furthermore, when the current power supply state is that the charging plug is connected, the first table value f1(t) may be set to a small value until the scheduled charging completion time according to the charging plan, and to a large value after the scheduled charging completion time.

[0091] The predicted value S2 of the "future usage rate prediction" may be calculated according to equation (3) using a second table value f2(t) that represents the CPU usage rate predicted from the application usage record or application usage plan. The second table value f2(t) takes a value between 0 and 1.

[0092] S2 [%] = 100 × f2(t) (3) When setting the second table value f2(t) based on the application usage history, the application usage history is tallied on a time axis representing the elapsed time from the time when the IG was turned on, and the probability that each application will be used at each time is calculated. The second table value f2(t) is set based on this probability and the CPU usage rate when each application is used. The second table value f2(t) may be set individually for each application.

[0093] The second table value f2(t) may be set using an application usage plan instead of the application usage record.

[0094] The predicted value S3 of the "battery remaining capacity" may be calculated according to equation (4) using the current battery remaining capacity Qc [%] as a reference, and using a third table value f3(t) that is set based on the application usage record or application usage plan and the power consumption required by each application.

[0095] S3 [%] = Qc - 100 × f3(t) (4) The third table value f3(t) is set so that the attenuation amount increases as the probability that an app will be used at each time point increases or as the power consumption of the used app increases. Furthermore, when a driving route is set by a navigation device, the third table value f3(t) may be set taking into consideration the usage status of apps predicted from the driving route, etc.

[0096] The predicted value S4 of "data capacity" may be calculated according to equation (5) using a fourth table value f4(t) that is set based on the application usage history or usage plan and the data capacity required by each application when executing processing, with the maximum value of available data capacity being Dm.

[0097] S4[%]=Dm×f4(t) (5) The fourth table value f4(t) is set based on the probability of each app being used at each time, which is calculated from the results of aggregating app usage records on a time axis representing the elapsed time from the time when the IG is turned on, and the data capacity required to run each app. An app usage plan may be used instead of the app usage records.

[0098] The predicted values ​​S5 and S6 of "equipment usability" may be calculated using a fifth table value f5(t) and a sixth table value f6(t) that are set based on the usage history or usage plan of equipment that may be accessed by multiple apps (e.g., a camera, special image processing, etc.). The predicted value S5 is the probability that the equipment is not in use but is available, and may be calculated according to formula (6). The predicted value S6 is the probability that the equipment is in use and is unavailable, and may be calculated according to formula (7).

[0099] S5[%] = 100 × f5(t) (6) S6[%] = 100 × f6(t) (7) The predicted value S7 of "communication availability" may be calculated using equation (8) with the current communication state as C[%], or may be calculated using equation (9) with a seventh table value f7(t) representing the communication state estimated from the vehicle's driving plan. The current communication state 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.

[0100] S7[%] = C / t (8) S7[%] = 100 × f7(t) (9) When the driving route is set by the navigation device, the seventh table value f7(t) may be set to a smaller value depending on the surrounding environment of the driving route. For example, the seventh table value f7(t) may be set to a smaller value at the scheduled time of passing through a tunnel or a group of buildings because the communication conditions will deteriorate.

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

[0102] The reservation arbitration unit 851 executes an acceptance determination process for processing a request from the service providing unit 6 via the confirmation API 73 or reservation API 74 of the API unit 71 .

[0103] [4. Processing] [4-1. Sequence Diagram] Next, basic processing executed in the vehicle control system 1 will be described with reference to the sequence diagram of Fig. 6. Fig. 6 describes, as a specific example of operation, an example in which app A and app B send request A to API unit 71 and cause camera control unit 91 to execute process a using camera 91A.

[0104] First, in S210, the service providing unit 6 sends request A (i.e., the first command in this disclosure) to the vehicle service unit 7 (API unit 71). Then, in S220, the vehicle service unit 7 performs a request acceptance determination by the vehicle service unit 7. The request acceptance determination by the vehicle service unit 7 is a process of determining whether each of the control units 91 to 99 can accept the first command.

[0105] In S220, the vehicle service unit 7 determines whether the first command can be accepted based on at least one of the vehicle equipment, the vehicle state, and the syntax of the command included in the first command. Note that the vehicle equipment and the vehicle state indicate the equipment and state of the vehicle in which the vehicle control system 1 is installed.

[0106] In S220, the vehicle service unit 7 determines whether or not the operation request from the service providing unit 6 can be accepted based on, for example, the following six items.

[0107] <1> Syntax: Whether there is an error in the API syntax in the program. <2> Equipment information: Whether the vehicle is equipped with the controlled object you want to operate. <3> Operational capability level: Whether the equipment you want to operate is currently able to accept an operation request. <4> Authentication / authorization: Whether the service provider 6 that made the request is authenticated and has access to the vehicle service unit 7. <5> Abnormality in the vehicle service unit 7: Whether an abnormality (e.g., data or communication abnormality, abnormal operation outside of normal specifications, etc.) has occurred in the vehicle service unit 7. <6> Cache status: Whether a period of time has passed since the status management unit 8 determined that the command could not be accepted and that the command could be accepted. In <3>, "equipment is able to accept" refers to the range of the operation request and the number of requests that can be made within a certain period of time being within a certain range. However, the number of requests that can be made within a certain period of time being within a certain range refers to the number of requests received within a certain period of time, etc. In <3>, operation requests that do not match the vehicle status are rejected. For example, a request to open a door while traveling at 100 km / h is rejected.

[0108] In <5>, depending on the combination of the vehicle API 71 and the content of the denial of acceptance, it is changed whether the denial of acceptance is cached for each request source or cached regardless of the request source.

[0109] Note that a determination item may be set for each vehicle API 71 in the vehicle service unit 7. In other words, there may be items for which determination is not performed. Here, information on equipment equipped in the vehicle, the authentication status and access rights of the service providing unit 6, the current vehicle status related to the equipment, and abnormality information on the vehicle and both service units are stored in the RAM 11c. Information referenced by the vehicle service unit 7 when determining whether to accept the request, such as cache status information, is also stored in the RAM 11c.

[0110] In S230, the vehicle service unit 7 transmits the determination result as to whether or not the first command can be accepted to the service providing unit 6. Subsequently, in S240, the vehicle service unit 7 transmits a processing a request to the status management unit 8. The processing a request is a request to perform processing a. The processing a request is transmitted only when the first command can be accepted.

[0111] When the state management unit 8 receives a request for processing a from the vehicle service unit 7, the state management unit 8 performs a request acceptance determination in S250. The request acceptance determination by the state management unit 8 includes a conflict determination in S250A and a resource determination in S250B. In the conflict determination, the state management unit 8 determines whether the first command can be accepted in consideration of conflicts between other commands and the first command. The other commands are commands that are different from the first command and the second command and are transmitted from an application different from the application that transmitted the first command. The state management unit 8 may determine whether the first command can be accepted in consideration of conflicts with requests received by other APIs (e.g., other vehicle APIs) different from the API that received the request (e.g., vehicle API 71).

[0112] In other words, the above-mentioned operation request acceptance determination refers to the vehicle state, etc., and determines whether or not the operation request can be accepted regardless of other commands, but the conflict determination in this process determines whether or not the operation request can be accepted taking into account conflicts with other commands, etc.

[0113] The state management unit 8 determines whether or not an operation request can be accepted based on, for example, the following five items.

[0114] <1> Request priority arbitration: whether the first command has a higher priority than requests based on other applications or user operations; <2> Requester cancellation request: whether the requester has requested a request cancellation and the request is being processed; <3> User cancellation request: whether a user has requested an operation interruption; <4> Request processing overload: whether the controlled object is receiving more requests than it can process; <5> Abnormality in status management unit 8 / equipment management unit 9: whether an abnormality (e.g., data or communication abnormality, operation outside normal regulations) has occurred in the status management unit 8 or the equipment management unit 9. Note that in <1>, the priority is specified by the application, and the operation based on the priority is determined on the receiving side. However, the receiving side may process the priority specified by the application ignoring the priority.

[0115] For example, if the state management unit 8 receives a request to turn on the air conditioner and a request to turn on the lights, and the voltage would fall below the power threshold if both requests were accepted, the state management unit 8 determines that the request is unacceptable. Furthermore, if the state management unit 8 receives a request for acceleration and a request for steering, and the vehicle drive control amount that satisfies both requests would result in road departure, the state management unit 8 determines that the request is unacceptable. Here, priority information for the request, information regarding requester cancellation, information regarding user cancellation, and thresholds that can be processed by the controlled object (e.g., number of requests, control amount, processing load, etc.) are stored in the RAM 11c or another memory. Information referenced by the state management unit 8 when determining whether to accept the request, such as abnormality information from the state management unit 8 and the equipment management unit 9, is also stored in the RAM 11c or another memory. If the request is determined to be unacceptable based on the conflict determination, a notification that the request is unacceptable is transmitted at S260 shown in FIG. 6 .

[0116] After the conflict determination in S250A, the state management unit 8 performs a resource determination in S250B. The conflict determination and resource determination may be selectively performed depending on the process to be executed. The resource determination may be performed only when the conflict determination determines that the process a is executable. When the state management unit 8 determines that the process a is executable in the resource determination, it generates and transmits a second command that embodies the abstracted first command as an operation instruction.

[0117] The resource determination is a process executed by the reservation arbitration unit 851 of the status management unit 8, and is shown as the acceptance determination process in Fig. 7. The acceptance determination process will be described with reference to the flowchart in Fig. 7. The acceptance determination process is started upon receiving a second command from the vehicle service unit 7.

[0118] When the acceptance determination process is started, in S110, the reservation arbitration unit 851 determines whether or not the current resources are sufficient to execute the command received in S240 (hereinafter also referred to as the "present request"). For example, it determines whether or not the processing capacity of the operation control device (e.g., the control units 91 to 99) is sufficient for the request from the application.

[0119] At this time, the reservation arbitration unit 851 references the required resource information stored in the information storage unit 853 to obtain information about the resources required to execute the API to be confirmed (hereinafter referred to as required resources). The required resources here are the "current utilization rate" and the "resource utilization rate required for processing," and if the sum of these does not exceed 100%, it is determined that the current resources are sufficient. Also, if the sum of these exceeds 100%, it is determined that the current resources are insufficient.

[0120] If the reservation arbitration unit 851 determines that the current resources are sufficient, it proceeds to S120, and if it determines that the current resources are insufficient, it proceeds to S130.

[0121] In S120, the reservation arbitration unit 851 sends a notification that the request is "immediately executable" as a reception result to the request source application of this request via the API unit 71 (see, for example, S260 in FIG. 6). In this case, the reservation arbitration unit 851 requests the equipment management unit 9 to immediately execute the process, as in S255 in FIG. 6. After the process of S120, this process ends.

[0122] In S130, the reservation arbitration unit 851 determines whether the processing for this request is scheduled to be executed within the processing upper limit time based on a request from another application. In other words, the reservation arbitration unit 851 is configured to determine whether a first command of the same type (e.g., meaning that the second command is the same) has been received from a second application while waiting for a first command to be accepted. The second application is an application different from the first application when the application that sent the first command is the first application. In other words, when this request and a request from another application overlap, the reservation arbitration unit 851 determines whether these requests can be integrated and executed as a single process in order to save resources and improve efficiency.

[0123] The information that the processing is waiting to be executed and the maximum processing time are stored in the information storage unit 853, and when making this judgment, the reservation arbitration unit 851 reads out the information that the processing is waiting to be executed and the maximum processing time from the information storage unit 853.

[0124] If the processing for this request is scheduled to be executed within the upper processing limit time based on a request from another application, the reservation arbitration unit 851 proceeds to S140. At this time, the reservation arbitration unit 851 calculates the time from the current time until the processing based on the request from the other application starts, and sets this time as the standby time (X ms). On the other hand, if the processing for this request is not scheduled to be executed within the upper processing limit time based on a request from the other application, the reservation arbitration unit 851 proceeds to S150.

[0125] In S140, the reservation arbitration unit 851 sends a notification to the requesting application of this request via the API unit 71 as an acceptance result, indicating that "execution is possible after X ms" (see, for example, S260 in FIG. 6). In other words, information indicating the time until the first command can be accepted is sent to the requesting application of this request. The wait time calculated by the reservation arbitration unit 851 is used as the content of the information indicating the time. In this case, as in S410 in FIG. 6, after waiting for X ms, a request is made to the equipment management unit 9 to execute the process. After the process of S140, this process ends.

[0126] In S150, the reservation arbitration unit 851 determines whether or not there is a surplus of resources within the processing upper limit time, making it possible to execute the processing. For example, an example of a surplus of resources is when another process ends and the process corresponding to the request can be executed. In addition, there may be a surplus of resources due to a change in the environment, such as an improvement in radio wave conditions.

[0127] Furthermore, in S150, for each process executed based on a request, if the sum of the "execution time required for the process" and the "estimated waiting time" is equal to or less than the "upper limit processing time," the process is determined to be executable. For example, for request A for vehicle X shown in FIG. 5, the sum of the "execution time required for the process" and the "estimated waiting time" for process e1 is 15 ms, and the "upper limit processing time" is 30 ms, so the process is determined to be executable. On the other hand, for process a, the sum of the "execution time required for the process" and the "estimated waiting time" is 35 ms, and the "upper limit processing time" is 10 ms, so the process is determined to be unexecutable.

[0128] The reservation arbitration unit 851 makes a positive judgment when, for example, all of the processing that should be performed for the request (e.g., request A) can be performed, and makes a negative judgment when some of the processing that should be performed for the request cannot be performed.

[0129] At this time, the reservation arbitration unit 851 queries the status prediction unit 852 and obtains a "wait time prediction." If there is a surplus of resources within the processing limit time and processing for this request can be executed, the reservation arbitration unit 851 proceeds to S140. At this time, the reservation arbitration unit 851 calculates the time from the current time until there is a surplus of resources and processing for this request can be started, and sets this time as the wait time (X ms). On the other hand, if there is no surplus of resources within the processing limit time and processing for this request cannot be executed, the reservation arbitration unit 851 proceeds to S160.

[0130] In S160, the reservation arbitration unit 851 determines whether the processing for this request can be executed within the upper processing limit time by delaying the start of the other process currently on hold. Note that the condition for delaying the start of the other process on hold is that the other process on hold is executed within the upper processing limit time.

[0131] If the reservation arbitration unit 851 determines that the processing for this request can be executed within the processing upper limit time by delaying the start of another process that is currently on hold, it proceeds to S140. At this time, the reservation arbitration unit 851 calculates the time from the current time until there is a surplus of resources and the processing for this request is started, and sets this time as the waiting time (X ms). Note that for other processes whose start times have been changed, the changed start times are notified. If the reservation arbitration unit 851 determines that the processing for this request cannot be executed within the processing upper limit time even if the start of another process that is currently on hold is delayed, it proceeds to S170.

[0132] In S170, the reservation arbitration unit 851 sends a notification that the request is "unacceptable" as the acceptance result to the request source application of this request via the API unit 71 (see, for example, S260 in FIG. 6). After the processing of S170, this processing ends.

[0133] 6 shows an example in which request A is sent from application B. That is, in S310, request A is sent from a different application to execute the same process a. In S310 to S360, the same processes as in S210 to S260 above are performed.

[0134] However, request A from application B is integrated with request A from application A that is waiting for process a, and the two are executed as one process a. In this case, the waiting time in reservation arbitration unit 851 for request A from application A is X ms, whereas the waiting time in reservation arbitration unit 851 for request A from application B is Y ms, which is shorter than X ms.

[0135] As described above, the reservation arbitration unit 851 outputs the second command based on the first command to each of the control units 91 to 99 of the equipment management unit 9 in S255 or S410.

[0136] Each control unit 91-99 is equipped with an operation control program for operating the controlled object, and upon receiving an operation instruction, each control unit 91-99 of the equipment management unit 9 executes the operation control program. Upon receiving a request, each control unit 91-99 transmits an operation instruction to the controlled object. In the example of FIG. 6 , the camera control unit 91 of the equipment management unit 9 receives a request for process a and transmits a sensor information transmission instruction to the camera 91A in S420. Upon receiving the sensor information transmission instruction, the camera 91A returns sensor information, such as an image captured by the camera 91A, to the camera control unit 91. Then, in S440, the camera control unit 91 executes process a using the sensor information. Once process a is executed, the execution result is transmitted to the requesting app. In this example, because request A has been received from both app A and app B, the execution result is transmitted to both app A and app B in S450 and S460.

[0137] 5. Effects According to the embodiment described above in detail, the following effects are achieved.

[0138] (5a) In one aspect of the present disclosure, the first reception determination unit (S110) is configured to, when a first command is input from an application, determine whether the first command can be received using resource information. If the first reception determination unit determines that the first command can be received, the first output unit (S255) is configured to output a second command based on the first command to an operation control program (91 to 99) installed in the operation control device and configured to control a control target.

[0139] The second reception determination unit (S150) is configured to determine whether the first command can be received by completing another process within a set predetermined time when the first reception determination unit determines that the first command cannot be received. The second output unit (S410) is configured to wait until the first command can be received and then output the second command to the operation control program when the second reception determination unit determines that the first command can be received within the predetermined time.

[0140] With this configuration, if a request to access a vehicle function from multiple applications cannot be accepted, the request can wait until it becomes available within a predetermined time, thereby controlling the vehicle resources to avoid shortages within the range that the system can tolerate.

[0141] (5b) An aspect of the present disclosure further includes a determination sending unit (S260, S360) configured to send the determination results of the first reception determination unit and the second reception determination unit to the application. The determination sending unit (S260, S360) is configured to send, when the second reception determination unit determines that the first command will be acceptable, information indicating the time until the first command will be acceptable to the application.

[0142] With this configuration, the application can be made aware of the time remaining until the first command can be accepted.

[0143] (5c) In one aspect of the present disclosure, the first acceptance determination unit and the second acceptance determination unit are configured to determine whether the first command can be accepted based on whether the operation of the operation control device corresponding to the first command conflicts with an operation based on another process, in addition to making a determination using resource information.

[0144] With this configuration, it is possible to determine whether or not the first command can be accepted, taking into consideration conflicts with other processes.

[0145] (5d) An aspect of the present disclosure further includes a third reception determination unit (S130). The third reception determination unit (S130) is configured to determine whether a first command of the same type has been received from a second application while the second output unit is waiting to receive the first command. The second application is an application different from the first application that transmitted the first command.

[0146] The second output unit is configured to output one second command based on the first command from the first application and the first command from the second application when the third reception determination unit determines that the same type of first command has been received.

[0147] According to this configuration, a plurality of first commands of the same type can be integrated to output one second command, thereby preventing duplicate second commands from being output.

[0148] (5e) One aspect of the present disclosure further includes a state prediction unit 852 configured to predict future resources by calculation. The first reception determination unit is configured to use, as resource information, the current resources stored in the memory and the future resources predicted by the state prediction unit 852.

[0149] With this configuration, it is possible to determine whether or not the first command can be accepted using current resources and future resources.

[0150] (5f) In one aspect of the present disclosure, the resource information includes characteristic information that varies depending on the vehicle type or individual vehicle.

[0151] With this configuration, it is possible to determine whether or not the first command can be accepted using the vehicle type or an individual vehicle.

[0152] 6. Other Embodiments Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments and can be implemented in various modifications.

[0153] (6a) In the above embodiment, the vehicle service unit 7 converts the first command into the second command. However, the state management unit 8 may convert the first command into the second command.

[0154] (6b) In the above embodiment, a waiting time prediction is generated each time a request is made. However, a waiting time prediction may be prepared in advance by periodically generating the waiting time prediction, and this prepared waiting time prediction may be used to determine whether processing can be executed.

[0155] (6c) In the above embodiment, the first ECU 10, the second ECU 15, and the center 35 each include a service providing unit 6, the first ECU 10 includes a vehicle service unit 7, the first ECU 10 and the third to fifth ECUs 20 to 30 each include a status management unit 8, and the fifth to thirteenth ECUs 30 to 48 each include an equipment management unit 9. The number of ECUs belonging to the ECU group 100 and the allocation of the functions of the service providing unit 6, the vehicle service unit 7, the status management unit 8, and the equipment management unit 9 to each ECU are not limited to those exemplified in the embodiment, and may be arbitrary.

[0156] (6d) Multiple functions possessed by one component in the above embodiments may be realized by multiple components, or one function possessed by one component may be realized by multiple components. Also, multiple functions possessed by multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Also, part of the configuration of the above embodiments may be omitted. Also, at least part of the configuration of the above embodiments may be added to or substituted for the configuration of another of the above embodiments.

[0157] (6e) In addition to the vehicle control device described above, the present disclosure can also be realized in various forms, such as a program for causing a computer to function as a vehicle control device, a non-transient physical recording medium such as a semiconductor memory on which this program is recorded, and a vehicle control method.

[0158] [7. Technical Ideas Disclosed in the Present Specification] [Item 1] A vehicle control system (1) mounted on a vehicle and including at least one vehicle control device (10, 15, 20, 25, 30) and an actuation control device (41-48), comprising: a first reception determination unit (S110) configured to, when a first command is input from an application, determine whether or not the first command can be received, using resource information related to the processing capacity of a resource used in the first command; a first output unit (S255) configured to, when the first reception determination unit determines that the first command can be received, output a second command based on the first command to an actuation control program (91-99) mounted on the actuation control device, the second output unit being an actuation control program for controlling a control target; and a second reception determination unit (S150) configured to, when the first reception determination unit determines that the first command cannot be received, determine whether or not the first command can be received within a set predetermined time, using the resource information; a second output unit (S410) configured to wait until the first command can be accepted and then output the second command to the operation control program when the second acceptance determination unit determines that the first command can be accepted within the predetermined time.

[0159] [Item 2] The vehicle control system according to item 1, further comprising a determination sending unit (S260, S360) configured to send the determination results of the first reception determination unit and the second reception determination unit to the application, wherein the determination sending unit is configured to send information to the application indicating the time until the first command can be accepted when the second reception determination unit determines that the first command can be accepted.

[0160] [Item 3] The vehicle control system according to item 1 or 2, wherein the first reception determination unit and the second reception determination unit are configured to determine whether or not the first command can be received depending on whether or not operation of an operation control device corresponding to the first command conflicts with operation based on another process, in addition to making a determination using the resource information.

[0161] [Item 4] The vehicle control system according to any one of items 1 to 3, further comprising a third reception determination unit (S130) configured to determine whether or not the second output unit has received a first command of the same type from a second application different from a first application that is an application that transmitted the first command, when the second output unit is on standby until it is able to receive the first command, and the second output unit is configured to output a single second command based on the first command from the first application and the first command from the second application to the operation control program when the third reception determination unit determines that the second output unit has received the first command of the same type.

[0162] [Item 5] A vehicle control system according to any one of items 1 to 4, further comprising a state prediction unit (852) configured to predict future resources by calculation, wherein the second reception determination unit is configured to use, as the resource information, the current resource usage status stored in a memory and the future resources predicted by the state prediction unit.

[0163] [Item 6] The vehicle control system according to any one of items 1 to 5, wherein the resource information includes characteristic information that varies depending on the vehicle type or an individual vehicle.

Claims

1. A vehicle control system (1) mounted on a vehicle and including at least one vehicle control device (10, 15, 20, 25, 30) and an operation control device (41 to 48), a first reception determination unit (S110) configured to, when a first command is input from an application, determine whether or not the first command can be received by using resource information related to the processing capacity of a resource used in the first command; a first output unit (S255) configured to output a second command based on the first command to an operation control program (91 to 99) for controlling a control target, the operation control program being installed in the operation control device when the first reception determination unit determines that the first command can be received; a second reception determination unit (S150) configured to, when the first reception determination unit determines that the first command cannot be received, determine whether the first command can be received within a set predetermined upper processing limit time using the resource information; and a second output unit (S410) configured to wait until the first command can be accepted and then output the second command to the operation control program when the second acceptance determination unit determines that the first command can be accepted within the upper processing time limit; A vehicle control system comprising:

2. 2. The vehicle control system according to claim 1, a determination sending unit (S260, S360) configured to send determination results by the first reception determination unit and the second reception determination unit to the application, The determination transmission unit transmits, to the application, information indicating a time until the first command can be accepted when the second acceptance determination unit determines that the first command can be accepted. A vehicle control system configured as follows.

3. 3. The vehicle control system according to claim 1, The first reception determination unit and the second reception determination unit determine whether the first command can be received based on whether operation of the operation control device corresponding to the first command conflicts with operation based on another process, in addition to the determination using the resource information. A vehicle control system configured as follows.

4. 3. The vehicle control system according to claim 1, a third reception determination unit (S130) configured to determine whether or not the second output unit has received a first command of the same type from a second application different from a first application that is an application that has transmitted the first command, while the second output unit is waiting until the second output unit is ready to receive the first command; Furthermore, When the third reception / determination unit determines that the same type of first command has been received, the second output unit outputs one second command based on the first command from the first application and the first command from the second application to the operation control program. A vehicle control system configured as follows.

5. 3. The vehicle control system according to claim 1, A state prediction unit (852) configured to predict future resource usage conditions through calculations, The second reception determination unit uses, as the resource information, current resource information stored in a memory and the future resource information predicted by the state prediction unit. A vehicle control system configured as follows.

6. 3. The vehicle control system according to claim 1, The resource information includes characteristic information that varies depending on the vehicle model or individual vehicle. A vehicle control system configured as follows.