Vehicle control system, arbitration method, and program

Abstract

In the present invention, an information provision unit (861) provides constraint information in response to a request from an application software. The constraint information is set for each usage pattern classified according to an application or purpose for using an HMI for a vehicle, and includes an HMI usable in each usage pattern and a constraint imposed with regard to the HMI in the usage pattern. An output control unit (862) determines the specific usage pattern to which the content of the HMI usage request from the application software corresponds and, when there is a conflict between HMI usage requests, arbitrates the conflicting HMI usage requests in accordance with a priority level associated with the usage patterns.

Description

Vehicle control system, arbitration method, and program CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] The present disclosure relates to a technique for arbitrating usage requests for a human-machine interface installed in a vehicle.

[0003] A vehicle is equipped with a plurality of application software programs, and each application software program utilizes a human-machine interface (hereinafter referred to as an in-vehicle HMI) installed in the vehicle to notify the user.

[0004] For example, Patent Document 1 listed below describes a technology for arbitrating HMI usage requests from multiple application software programs in accordance with a preset priority table that defines the priority relationships between services.

[0005] Japanese Patent Application Laid-Open No. 2007-145137

[0006] However, after detailed investigation by the inventors, it was found that the conventional technology using a priority table may be unable to determine the priority of HMI usage requests from application software that has been updated or newly added. This is because the existing priority table does not contain information about the updated application software. Therefore, when using a priority table, it is necessary to rewrite the priority table every time the application software is updated, which is a cumbersome and extensive task.

[0007] One aspect of the present disclosure provides a technique for easily realizing arbitration of HMI usage requests from added application software.

[0008] One aspect of the present disclosure is a vehicle control system including an information providing unit and an output control unit. The information providing unit is configured to provide constraint information in response to a request from application software. The constraint information is information set for each usage pattern classified according to the purpose or purpose of using the HMI for the vehicle, and includes HMIs that can be used in the usage pattern and constraints imposed on the HMI in the usage pattern. The output control unit is configured to control the HMI in accordance with an HMI usage request from the application software requesting use of the HMI. The output control unit is also configured to determine which usage pattern the content of the HMI usage request corresponds to, and, in the event of conflicting HMI usage requests, arbitrate the conflicting HMI usage requests in accordance with priorities associated with the usage patterns.

[0009] With this configuration, arbitration of HMI usage requests from added application software can be easily realized.

[0010] One aspect of the present disclosure is a method for arbitrating HMI usage requests, in which an on-board computer arbitrates HMI usage requests from multiple application software programs that utilize an HMI for the vehicle. In this method, the computer determines whether the content of the HMI usage request corresponds to one of usage patterns classified by the use or purpose of the HMI. Furthermore, when conflicting HMI usage requests occur, the computer arbitrates the conflicting HMI usage requests according to the priority associated with the usage pattern.

[0011] According to this method, it is possible to obtain the same effect as the above-mentioned vehicle control system.

[0012] According to one aspect of the present disclosure, there is provided a program for causing a computer to function as the information providing unit and the information output unit described above. Such a program can achieve the same effects as those of the vehicle control system described above.

[0013] 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 the contents of HMI information. FIG. 6 is an explanatory diagram showing the arrangement of a visual-use HMI, etc. FIG. 7 is an explanatory diagram illustrating the contents of constraint information. FIG. 8 is a flowchart of HMI arbitration processing. FIG. 9 is a sequence diagram showing a standard processing flow when an HMI information request and an HMI usage request are made. FIG. 10 is a sequence diagram illustrating a processing flow when a conflict between HMI usage requests occurs and a later request wins arbitration. FIG. 11 is a sequence diagram illustrating a processing flow when a conflict between HMI usage requests occurs and a later request wins arbitration or has the same priority as an earlier request. FIG. 12 is a sequence diagram illustrating a processing flow when a conflict between HMI usage requests occurs and a later request loses arbitration or has the same priority as an earlier request. FIG. 13 is a sequence diagram illustrating a processing flow when a conflict between HMI usage requests occurs and a later request loses arbitration or has the same priority as an earlier request.

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

[0015] 1 includes an electronic control unit (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).

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

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

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

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

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

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

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

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

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

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

[0026] 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 digital circuits including multiple logic circuits, analog circuits, or a combination of digital and analog circuits.

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

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

[0029] 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, or analog circuits, or a combination of digital and analog circuits.

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

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

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

[0033] The camera control unit 91 controls the exposure of the vehicle-mounted camera and acquires images captured by the vehicle-mounted camera. In this embodiment, the sixth ECU 91 includes the camera control unit 91.

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

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

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

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

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

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

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

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

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

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

[0044] [3-2. Service Providing Unit] The service providing unit 6 executes application software (hereinafter, "apps") 61 to 64 to realize various functions, such as information collection, theft prevention, and remote control, by utilizing the vehicle equipment managed by the equipment management unit 9.

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

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

[0047] 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 being aware of the vehicle equipment or performance of each individual vehicle. In other words, the apps 61 to 64 can be easily developed by third parties, i.e., app providers other than vehicle manufacturers and suppliers, 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.

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

[0049] [3-3. Vehicle Service Unit] The vehicle service unit 7 includes an Application Programming Interface (hereinafter, 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.

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

[0051] The first instruction may include a command indicating the requested content, an instruction such as an argument, a function call, or the like.

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

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

[0054] The API unit 71 includes at least a control API 72 and an information API 73 .

[0055] The information API 73 is a vehicle API for receiving requests from applications regarding the acquisition of information managed by the state management unit 8 .

[0056] The control API 72 is a vehicle API for receiving requests from applications relating to the control of equipment managed by the equipment management unit 9 .

[0057] 1 and 4, the state management unit 8 includes a state recognition unit 81, a motor system equipment control unit 82, a human machine interface (hereinafter referred to as HMI) system equipment control unit 83, and a body system equipment control unit 84.

[0058] The units 81 to 84 belonging to the state management unit 8 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 state management unit 8 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.

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

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

[0061] The HMI equipment control unit 83 corresponds to vehicle operations related to presenting information to the user. The HMI equipment control 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 equipment control unit 83. Note that the HMI equipment control unit 83 may control, for example, vehicle equipment belonging to the haptic control unit in addition to the vehicle equipment belonging to the display control unit 95 and the sound control unit 96. The vehicle equipment belonging to the haptic control unit may include, for example, equipment that vibrates the steering wheel, equipment that vibrates the seat, equipment that retracts the seat belt, etc.

[0062] The body equipment control unit 84 controls the operation of the body systems of the vehicle in relation to the vehicle environment. For example, the body equipment 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 equipment control unit 84.

[0063] [3-5. HMI System Equipment Control Unit] The HMI system equipment control unit 83 belonging to the status management unit 8 will be described.

[0064] As shown in FIG. 4, the HMI equipment control unit 83 includes an information storage unit 85 and a processing execution unit 86 .

[0065] The information storage unit 85 stores at least HMI information 851 and constraint information 852 .

[0066] The HMI information 851 stores information about HMI equipment that is the control target of the HMI equipment control unit 83. For example, information about a display device, which is one type of HMI equipment, stores the position, size, resolution, driver viewing angle, etc. for each type of display device, as shown in FIG.

[0067] Types of display devices may include, for example, a multi-information display (hereinafter, MID), a head-up display (hereinafter, HUD), a center information display (hereinafter, CID), a display for a passenger seat (hereinafter, P seat), a display for multiple rear seats (hereinafter, R seat), etc.

[0068] The MID is a display located at position P1 shown in FIG. 6, i.e., on the instrument panel in front of the driver's seat (hereinafter referred to as "D seat"). The MID displays various information such as meters and vehicle status. The MID may be divided into multiple display areas. Each display area is located at positions P11 to P13 shown in FIG. 6. The HMI information 851 related to the MID may be configured with settings such as the position, size, resolution, and driver viewing angle for each of the multiple divided display areas.

[0069] The HUD provides various information to the driver by projecting an image onto the windshield in front of seat D at position P2 shown in FIG.

[0070] The CID is a large display located at position P3 in Fig. 6, i.e., in the center of the cockpit. The CID mainly displays navigation information, entertainment information, and the like.

[0071] In addition, the HUD and CID may have multiple display areas, similar to the MID. In this case, the HMI information 851 of the HUD and CID may be set with the position, size, resolution, driver viewing angle, etc. for each of the multiple divided display areas.

[0072] The P seat display is located at position P4 shown in FIG. 6, that is, in front of the P seat, and provides various information to the passenger in the P seat.

[0073] The R seat displays are located at positions P5 to P7 shown in FIG. 6, that is, in front of each of the multiple R seats, and provide various information to the R seat occupants.

[0074] It is not necessary to provide all the types of display devices, and some may be omitted.

[0075] In the HMI information 851, size indicates the size of the display area. Resolution indicates the display resolution. The driver's viewing angle is based on the state in which the driver's line of sight is directly ahead. When the line of sight moves little to the display area, it is indicated as "near." When the line of sight moves a lot, it is indicated as "far." When the line of sight moves somewhere between "near" and "far," it is indicated as "medium."

[0076] The restriction information 852 is information indicating the content of restrictions imposed on the HMI when using HMI-related equipment, for each usage pattern.

[0077] As shown in Figure 7, usage patterns are classified according to the purpose or purpose of using the HMI equipment. Usage patterns may include, for example, "warning," "attention call," and "notification." Usage patterns are set from a perspective common to all vehicles, regardless of the specific in-vehicle HMI installed in the vehicle.

[0078] The constraint information 852 is set for each of the visual utilization device and the auditory utilization device.

[0079] The constraint information for visual use devices may include "usable devices," "displayable area," "usable number of characters," "animation use," and "display time."

[0080] "Available devices" is information indicating display devices that can be used in a given usage pattern. For example, if the usage pattern is "warning" or "attention," an MID or HUD may be an available device. If the usage pattern is "notification," there are no restrictions on the display device, and any display device may be an available device.

[0081] The "displayable area" is information that indicates the position of the display area relative to the driver's viewing angle that can be used. For example, when the usage pattern is "warning," the displayable area is a display area where the driver's viewing angle is "near" so that the driver can check information with as little eye movement as possible. When the usage pattern is "attention," the displayable area is a display area where the driver's viewing angle is "near" to "medium," allowing for greater eye movement than for "warning." When the usage pattern is "notification," the driver does not necessarily need to check information, so there is no restriction on the driver's viewing angle, and any display area may be the displayable area.

[0082] The "number of available characters" indicates the upper limit of the number of characters that can be displayed in the display area. For example, when the usage pattern is "warning," the "number of available characters" may be set to a small number so that the driver can instantly recognize it, when the usage pattern is "notification," the "number of available characters" may be set to a large number because no particular restriction is required, and when the usage pattern is "attention," the "number of available characters" may be set to somewhere between the two.

[0083] "Animation use" indicates whether animation can be used to display the display area. For example, "animation use" may be set to "unavailable" when the usage pattern is "warning" or "attention", and may be set to "available" when the usage pattern is "notification".

[0084] The "display time" indicates the duration of the display. The "display time" may be set to a short time when the usage pattern is "warning," a long time when the usage pattern is "notification," or an intermediate time between the two when the usage pattern is "attention."

[0085] The constraint information for the hearing-utilizing device may include "available devices," "available frequency range," and "sound output time."

[0086] "Available devices" is information indicating sound devices that can be used in a target usage pattern. For example, if the usage pattern is "warning," a buzzer that can reliably attract the driver's attention may be set as the available device. If the usage pattern is "attention" or "notification," there are no restrictions on sound devices, and any sound device, including a device that outputs sound, may be set as the available device.

[0087] The "available frequency range" is information indicating the pitch of the buzzer that can be used. For example, if the usage pattern is "warning," the "available frequency range" may be set to a high-pitched sound that is easy to hear. If the usage pattern is "attention" or "notification," the "available frequency range" may be set to a lower pitch so that it can be distinguished from a "warning."

[0088] "Sound output time" is information indicating the upper limit of the sound output time in a usage pattern. For example, when the usage pattern is "warning," the output time may be set to "short" because of the urgency involved. When the usage pattern is "attention," the output time may be set to "medium" so that notifications such as voice can also be used. When the usage pattern is "notification," the output time may be set to "long" so that the necessary information is conveyed sufficiently.

[0089] The constraint information may include constraint information on "tactile devices" in addition to "visual devices" and "auditory devices."

[0090] The restriction information for the "tactile utilization device" may include "available devices." The "available devices" is information indicating vibration devices that can be used in the usage pattern of interest. For example, when the usage pattern is "warning," the "available devices" may be set to allow use of a steering wheel vibration device, a seat vibration device, a seat belt retractor, etc. When the usage pattern is "attention alert," the steering wheel vibration device and a seat vibration device may be set to allow use. When the usage pattern is "notification," the use of tactile utilization devices may be prohibited.

[0091] Here, only "available devices" is exemplified as the constraint information for the "tactile device," but the constraint information may also include "vibration duration," "vibration strength," "vibration pattern," and the like.

[0092] The "visual device," "auditory device," and "tactile device" may be used alone, or two or three of them may be used in combination.

[0093] Each usage pattern is associated with a "priority." The "priority" of a usage pattern indicates the priority of processing when HMI usage requests conflict. If the usage pattern is "warning," the priority may be "high," if the usage pattern is "attention," the priority may be "medium," and if the usage pattern is "notification," the priority may be "low."

[0094] The HMI information 851 and the restriction information 852 have different contents for each vehicle depending on the performance and arrangement of the HMI equipment of the vehicle. The HMI information 851 and the restriction information 852 stored in the information storage unit 85 may be acquired from, for example, the center 35 outside the vehicle. A part of the HMI information 851 stored in the information storage unit 85 may be acquired from the equipment management unit 9.

[0095] Returning to Figure 4, when the processing execution unit 86 receives a request (i.e., the second command) from the vehicle service unit 7, it determines whether the vehicle condition is suitable for executing the second command, and if so, instructs the equipment management unit 9 to operate the target equipment.

[0096] The processing execution unit 86 has the function of outputting an operation instruction 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.

[0097] The processing execution unit 86 includes an HMI information providing unit 861 and an HMI output control unit 862 .

[0098] The HMI information providing unit 861 executes information providing processing. The information providing processing is executed when the information API 73 accepts an HMI information acquisition request (i.e., a first command) from an application belonging to the service providing unit 6, and the HMI equipment control unit 83 receives an HMI information acquisition request (i.e., a second command) transferred from the vehicle service unit 7. In the information providing processing, the HMI information 851 and the constraint information 852 stored in the information storage unit 85 are provided to the requesting application.

[0099] The HMI output control unit 862 executes an HMI arbitration process. The HMI arbitration process is executed when the control API 72 accepts an HMI control request (i.e., a first command) from an application belonging to the service providing unit 6, and the HMI equipment control unit 83 receives an HMI control request (i.e., a second command) transferred from the vehicle service unit 7.

[0100] The HMI information acquisition request includes at least information for identifying the requesting application.

[0101] The HMI control request includes at least information specifying which HMI device to use and in what manner, in addition to information identifying the requesting application. The requesting application is required to set the usage manner described in the HMI control request so as to satisfy one of the usage patterns in the constraint information 852 shown in FIG. 7.

[0102] [4. Processing] The HMI arbitration processing executed by the HMI output control unit 862 will be described with reference to the flowchart of Fig. 8. The HMI arbitration processing is repeatedly executed when the fourth ECU 25 equipped with the HMI equipment control unit 83 is started up.

[0103] When the HMI arbitration process is started, in S110, the HMI output control unit 862 determines whether or not an HMI usage request has been received from the vehicle service unit 7 via the control API 72. If an HMI usage request has been received, the HMI output control unit 862 proceeds to S120, and if an HMI usage request has not been received, the HMI output control unit 862 terminates the process. Hereinafter, the received HMI usage request will be referred to as an acceptance request.

[0104] In S120, the HMI output control unit 862 determines whether the usage mode indicated in the acceptance request satisfies the constraint conditions of the usage pattern "warning." If the HMI output control unit 862 determines that the constraint conditions of the usage pattern "warning" are satisfied, the process proceeds to S130. If the HMI output control unit 862 determines that the constraint conditions are not satisfied, the process proceeds to S140.

[0105] In S130, the HMI output control unit 862 sets the priority of the acceptance request to "high" and proceeds to S190.

[0106] In S140, the HMI output control unit 862 determines whether the usage mode indicated in the acceptance request satisfies the constraint conditions of the usage pattern "attention." If the HMI output control unit 862 determines that the constraint conditions of the usage pattern "attention" are satisfied, the process proceeds to S150, and if it determines that the constraint conditions are not satisfied, the process proceeds to S160.

[0107] In S150, the HMI output control unit 862 sets the priority of the acceptance request to "medium" and proceeds to S190.

[0108] In S160, the HMI output control unit 862 determines whether the usage mode indicated in the acceptance request satisfies the constraints of the usage pattern "notification." If the HMI output control unit 862 determines that the constraints of the usage pattern "notification" are satisfied, the process proceeds to S170. If the HMI output control unit 862 determines that the constraints are not satisfied, the process proceeds to S180.

[0109] In S170, the HMI output control unit 862 sets the priority of the acceptance request to "low" and proceeds to S190.

[0110] In S180, the HMI output control unit 862 executes a rejection process to reject the acceptance request, and then ends the process. In the rejection process, a result notification indicating that the request has been rejected is sent back to the application that sent the acceptance request. When the application that sent the acceptance request receives the request rejection notification, it may output an HMI usage request again.

[0111] In S190, the HMI output control unit 862 determines whether there is an HMI usage request (hereinafter referred to as a competing request) that conflicts with the accepted request, and if there is a competing request, proceeds to S210; if there is no competing request, proceeds to S210.

[0112] In S200, the HMI output control unit 862 performs an output execution process to execute HMI output in accordance with the reception request, and then ends the HMI arbitration process. In the output execution process, an instruction is output to the equipment management unit 9, which manages the HMI equipment indicated in the reception request, to perform output in the usage mode indicated in the reception request. In addition, in the output execution process, if a response is received from the equipment management unit 9, a result notification indicating the response content is returned to the requesting application via the vehicle service unit 7.

[0113] In S210, the HMI output control unit 862 determines whether the accepted request has a higher priority than the competing request, and if it does, proceeds to S220, otherwise proceeds to S230.

[0114] In S220, the HMI output control unit 862 executes arbitration winning processing. In arbitration winning processing, the HMI output control based on the competing request is suspended or forcibly terminated, and then the HMI output control based on the acceptance request is executed. If the competing request is forcibly terminated, a result notification indicating that the HMI output control based on the competing request has been forcibly terminated is returned to the application that requested the competing request. If the competing request is suspended, after the HMI output control based on the acceptance request is terminated, the suspended HMI output control based on the competing request is resumed, and the HMI arbitration processing is terminated.

[0115] In S230, the HMI output control unit 862 determines whether the accepted request and the competing request have the same priority, and if they have the same priority, it proceeds to S240; if they do not have the same priority, i.e., if the accepted request has a lower priority than the competing request, it proceeds to S250.

[0116] In S240, the HMI output control unit 862 executes the same priority process and terminates the HMI arbitration process. In the same priority process, the HMI output control based on the competing request may be continued by rejecting the acceptance request. In this case, a result notification indicating that the HMI usage request has been rejected is output to the application that requested the acceptance request. Alternatively, the same priority process may put the acceptance request on hold and execute the HMI output control based on the acceptance request after the HMI output control based on the competing request has been completed. Alternatively, the same priority process may suspend the HMI output control based on the competing request, execute the HMI output control based on the acceptance request, and resume the suspended HMI output control based on the competing request after the HMI control based on the acceptance request has been completed. Alternatively, the same priority process may forcibly terminate the HMI output control based on the competing request and execute the HMI output control based on the acceptance request. In this case, a result notification indicating that the HMI output control based on the competing request has been forcibly terminated may be returned to the application that requested the competing request.

[0117] In S250, the HMI output control unit 862 executes arbitration processing and terminates the HMI arbitration processing. In the arbitration processing, the HMI output control unit 862 continues the HMI output control based on the competing request by rejecting the acceptance request. In addition, the HMI output control unit 862 outputs a result notification indicating that the HMI usage request has been rejected to the application that sent the acceptance request.

[0118] 5. Operation 5-1. Basic Operation Next, the basic operation of the vehicle control system 1 will be described with reference to the sequence diagram of FIG.

[0119] As shown in FIG. 9, in S10, the application A belonging to the service providing unit 6 uses the information API 73 of the API unit 71 of the vehicle service unit 7 to send an "HMI information request" in the form of a first command.

[0120] The API unit 71 performs a format check and an authority check on the received "HMI information request," and if both are determined to be conforming, converts the "HMI information request" from the format of the first command to the format of the second command. Then, in S11, the API unit 71 transmits the "HMI information request" converted into the format of the second command to the processing execution unit 86 of the HMI equipment control unit 83 belonging to the status management unit 8.

[0121] When the processing execution unit 86 receives the "HMI information request," in S12, it acquires the HMI information 851 and the constraint information 852 from the information storage unit 85. Furthermore, in S13, the processing execution unit 86 transmits an "HMI information notification" indicating the acquired HMI information 851 and constraint information 852 to the API unit 71.

[0122] In S14, the API unit 71 transmits the "HMI information notification" received from the process execution unit 86 to application A, which is the application that has made the "HMI information request."

[0123] Application A sets the contents of the "HMI usage request", i.e., the HMI equipment to be used and the usage mode, taking into consideration the HMI information 851 and restriction information 852 shown in the "HMI information notification". For example, the "HMI usage request" may be set to "display the characters 'xxx' for 'x seconds' in the display area set in the driver's field of view 'near' of the 'MID'".

[0124] In S15, the application A uses the control API 72 of the API unit 71 to send an "HMI usage request" in the format of a first command.

[0125] When the API unit 71 receives the "HMI usage request," it performs a format check and an authority check in S16, just as it did for the "HMI information request." If the check results in a match, it converts the "HMI usage request" from the first command format to the second command format and sends it to the processing execution unit 86.

[0126] When the process execution unit 86 receives the "HMI usage request," it executes an HMI arbitration process in S17. If it is determined as a result of the HMI arbitration process that there are no conflicting HMI usage requests, the process execution unit 86 transmits the "HMI usage request" to the equipment management unit 9 in S18.

[0127] In S19, the equipment management unit 9 executes HMI output control in accordance with the received "HMI usage request." When the equipment management unit 9 ends the HMI output control, in S20, the equipment management unit 9 notifies the processing execution unit 86 that the HMI output control has ended normally.

[0128] In S21, the process execution unit 86 transmits a "result notification" indicating the notification content from the equipment management unit 9 to the API unit 71.

[0129] In S22, the API unit 71 transmits the "result notification" received from the process execution unit 86 to application A, which is the application that has made the "HMI usage request."

[0130] 5-2. Operation 1 when HMI usage requests conflict] The operation when HMI usage requests conflict in the HMI arbitration process will be described with reference to Fig. 10. Here, it is assumed that an HMI usage request from app B occurs while HMI output control is being executed based on an HMI usage request from app A. In other words, the HMI usage request from app A is the conflicting request, and the HMI usage request from app B is the acceptance request.

[0131] Although the explanation is omitted, it is assumed that the application B also acquires the HMI information 851 and the constraint information 852 by an "HMI information request" in the same manner as the application A.

[0132] As shown in FIG. 10, in S31, the application B transmits an "HMI usage request" in the format of the first command, similar to the case of S15.

[0133] When the API unit 71 receives the "HMI usage request," in S32, as in S16, it transmits the "HMI usage request" converted from the first command format to the second command format to the processing execution unit 86.

[0134] When the process execution unit 86 receives the "HMI usage request," it executes HMI arbitration processing in S33. If the result of the HMI arbitration processing is that there are conflicting HMI usage requests and arbitration has been won, the process execution unit 86 transmits a "forced termination request" to the equipment management unit 9 in S34.

[0135] When the equipment management unit 9 receives the "forced termination request," it forcibly terminates the HMI output control based on the competing request that is currently being executed, and notifies the process execution unit 86 of the forced termination in S35.

[0136] When the processing execution unit 86 receives a notification from the equipment management unit 9, in S36 it sends a "result notification" indicating the notification content to the API unit 71, and in S38 it sends an "HMI usage request" from app B, which is an acceptance request, to the equipment management unit 9.

[0137] In S37, the API unit 71 transmits the "result notification" received from the process execution unit 86 to application A, which is the application that has issued the competing request.

[0138] In step S39, the equipment management unit 9 executes HMI output control in accordance with the received "HMI usage request." When the equipment management unit 9 completes the HMI output control, in step S40, the equipment management unit 9 notifies the process execution unit 86 that the HMI output control has been successfully completed.

[0139] In S41, the process execution unit 86 transmits a "result notification" indicating the notification content from the equipment management unit 9 to the API unit 71.

[0140] In S42, the API unit 71 transmits the "result notification" received from the process execution unit 86 to application B, which is the application that has issued the acceptance request.

[0141] That is, if the acceptance request wins arbitration over the competing request, the HMI output control based on the competing request may be forcibly terminated, and the HMI output control based on the acceptance request may be executed.

[0142] 5-3. Operation 2 When HMI Usage Requests Compete Another operation when HMI usage requests compete in the HMI arbitration process will be described with reference to FIG.

[0143] As shown in Fig. 11, steps S31 to S33 are the same as those described in Fig. 10. However, in the HMI arbitration process of S33, the process execution unit 86 determines that the accepted request has won arbitration over the competing request, or that the accepted request and the competing request have the same priority. In this case, the process execution unit 86 transmits an "interruption request" to the equipment management unit 9 in S34a.

[0144] When the equipment management unit 9 receives the "interruption request," it interrupts the HMI output control based on the competing request that is currently being executed, and notifies the process execution unit 86 in S35a that the HMI output control has been interrupted.

[0145] When the process execution unit 86 receives the notification from the equipment management unit 9, it transmits the "HMI use request" from the application B, which is the acceptance request, to the equipment management unit 9 in S38.

[0146] In step S39, the equipment management unit 9 executes HMI output control in accordance with the received "HMI usage request." After that, when the HMI output control ends, the equipment management unit 9 notifies the processing execution unit 86 in step S40 that the HMI output control has ended normally.

[0147] When the process execution unit 86 receives the notification from the equipment management unit 9, in S41 it transmits a "result notification" indicating the content of the notification from the equipment management unit 9 to the API unit 71. Furthermore, in S43 the process execution unit 86 transmits a "request to resume" to the equipment management unit 9 regarding the HMI output control based on the previously interrupted competing request.

[0148] In S42, the API unit 71 transmits the "result notification" received from the process execution unit 86 to application B, which is the application that has issued the acceptance request.

[0149] When the equipment management unit 9 receives a "restart request" from the process execution unit 86, it restarts the HMI output control based on the competing request in S19b. After that, when the HMI output control ends, the equipment management unit 9 notifies the process execution unit 86 in S20 that the HMI output control has ended normally.

[0150] In S21, the process execution unit 86 transmits a "result notification" indicating the notification content from the equipment management unit 9 to the API unit 71.

[0151] In S22, the API unit 71 transmits the "result notification" received from the process execution unit 86 to application A, which is the application that has made the "HMI usage request."

[0152] In other words, if the acceptance request wins arbitration over the competing request, or if the acceptance request and the competing request have the same priority, the HMI output control based on the competing request is suspended and the HMI output control based on the acceptance request is executed. After the HMI output control based on the acceptance request is executed, the suspended HMI output control based on the competing request may be resumed.

[0153] 5-4. Operation 3 When HMI Usage Requests Compete Another operation when HMI usage requests compete in the HMI arbitration process will be described with reference to FIG.

[0154] As shown in Fig. 12, steps S31 to S33 are the same as those described in Fig. 10. However, in the HMI arbitration process of S33, the process execution unit 86 determines that the acceptance request and the competing request have the same priority, or that the acceptance request has lost the arbitration to the competing request. In this case, the process execution unit 86 waits in S33a until it receives a notification from the equipment management unit 9 indicating that the HMI output control based on the competing request has ended normally.

[0155] When the HMI output control based on the competing request is completed, the equipment management unit 9 notifies the process execution unit 86 in S20 that the HMI output control has been completed normally.

[0156] When the process execution unit 86 receives the notification from the equipment management unit 9, in S21 it transmits a "result notification" indicating the content of the notification from the equipment management unit 9 to the API unit 71. In addition, the process execution unit 86 releases the waiting state for the reception request, and in S38 transmits the reception request (i.e., "HMI usage request") to the equipment management unit 9.

[0157] In S22, the API unit 71 transmits the "result notification" received from the process execution unit 86 to application A, which is the application that has made the "HMI usage request."

[0158] In step S39, the equipment management unit 9 executes HMI output control in accordance with the received "HMI usage request." After that, when the HMI output control ends, the equipment management unit 9 notifies the processing execution unit 86 in step S40 that the HMI output control has ended normally.

[0159] When the process execution unit 86 receives the notification from the equipment management unit 9, it transmits a "result notification" indicating the content of the notification from the equipment management unit 9 to the API unit 71 in S41.

[0160] In S42, the API unit 71 transmits the "result notification" received from the process execution unit 86 to application B, which is the application that has issued the acceptance request.

[0161] In other words, if the acceptance request and the competing request have the same priority, or if the acceptance request loses arbitration to the competing request, the HMI output control based on the acceptance request may be executed after waiting for the HMI output control based on the competing request to end.

[0162] 5-5. Operation 4 when HMI Usage Requests Compete With reference to FIG. 13, another operation when HMI usage requests compete with each other in the HMI arbitration process will be described.

[0163] As shown in Fig. 13, steps S31 to S33 are the same as those described in Fig. 10. However, in the HMI arbitration process of S33, the process execution unit 86 determines that the admission request and the competing request have the same priority, or that the admission request has lost the arbitration to the competing request. In this case, the process execution unit 86 rejects the admission request, and in S44 sends a "result notification" indicating that the request has been rejected to the API unit 71.

[0164] In S45, the API unit 71 transmits the "result notification" received from the process execution unit 86 to application B, which is the application that has issued the acceptance request.

[0165] When the HMI output control based on the competing request is completed, the equipment management unit 9 notifies the process execution unit 86 in S20 that the HMI output control has been completed normally.

[0166] When the process execution unit 86 receives the notification from the equipment management unit 9, it transmits a "result notification" indicating the content of the notification from the equipment management unit 9 to the API unit 71 in S21.

[0167] In S22, the API unit 71 transmits the "result notification" received from the process execution unit 86 to application A, which is the request source application of the competing request.

[0168] In other words, if the admission request has the same priority as a competing request, or if the admission request loses in arbitration to the competing request, the admission request may be rejected. When application B, which is the request source application, receives a notification in the "result notification" that the request has been rejected, it may resubmit the rejected "HMI usage request."

[0169] [6. Correspondence of Terms] The HMI information providing unit 861 in this embodiment corresponds to the information providing unit in the present disclosure, and the HMI output control unit 862 corresponds to the output control unit in the present disclosure. Among the constraint information in this embodiment, the "available devices" and "displayable area" correspond to information associated with the driver's noticeability of the HMI output in the present disclosure, and information specifying the vehicle occupant to whom the information is to be provided. Among the constraint information in this embodiment, the "number of available characters" corresponds to the amount of information that can be provided in the present disclosure, and the "display time" and "sound output time" correspond to the available time of the present disclosure.

[0170] 7. Effects According to the first embodiment described above in detail, the following effects are achieved.

[0171] (7a) The HMI equipment control unit 83 determines which usage pattern the usage mode indicated in the HMI usage request corresponds to, and arbitrates conflicting HMI usage requests using the priority associated with the usage pattern. Therefore, the HMI equipment control unit 83 can arbitrate HMI usage requests without grasping the content of notifications from the HMI or using a priority table that associates the content of HMI notifications with priorities. As a result, compared to conventional techniques that use a priority table, the effort of rewriting the priority table every time an app is added can be eliminated.

[0172] (7b) In response to an HMI information request from an app, the HMI equipment control unit 83 provides HMI information indicating the type and location of the in-vehicle HMI and constraint information indicating constraints on the use of the in-vehicle HMI. Therefore, the app can generate an appropriate HMI usage request according to the in-vehicle HMI of the vehicle based on the acquired HMI information and constraint information. In other words, the same app can be applied to a wide variety of vehicles equipped with different in-vehicle HMIs.

[0173] 8. 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.

[0174] (8a) In the above embodiment, the priority between HMI usage requests is determined according to the usage pattern. If the requests have the same priority, no further priority determination is performed. Alternatively, the priority between HMI usage requests using the same usage pattern may be determined using application-specific information. Application-specific information is information that can be used without knowing the application details or the notification content via the in-vehicle HMI, such as information about the manufacturer of the application that requested the HMI usage request and the amount charged for the application's use of vehicle resources (e.g., vehicle API). In this case, the priority may be set, for example, depending on whether the manufacturer of the requesting application is the vehicle manufacturer, a supplier, or a third party. A third party is a manufacturer other than the vehicle manufacturer and suppliers, such as an application manufacturer. Specifically, the vehicle manufacturer may be given a higher priority than the supplier and third parties. Furthermore, the priority may be set as follows: vehicle manufacturer > supplier > third party.

[0175] (8b) The constraint information provided by the HMI information provider 861 in response to an HMI information request may include dynamic information that changes depending on the vehicle status or the occurrence of conflicting HMI usage requests. Examples of vehicle status include whether the vehicle is parked, stopped, or in motion. Among the constraint information, the "number of available characters," "animation usage," "display time," and "available devices" may be dynamic information. Specifically, when the vehicle is parked, for safety reasons, the "number of available characters" may be increased to display an area close to the field of view, or "animation usage" may be permitted. Furthermore, in situations where there are many conflicting HMI usage requests, the "display time" may be shortened, the "number of available characters" may be reduced, or the "available devices" may be limited to auditory or tactile devices to reduce the user's load. Furthermore, a constraint may be added that allows non-urgent notifications, such as weather information, to be output later.

[0176] (8c) In the above embodiment, the HMI that is the target of the HMI usage request is not limited to the in-vehicle HMI installed in the vehicle, but may also include portable devices such as smartphones and tablets carried by the vehicle owner or passengers.

[0177] (8d) Each ECU and center 35 belonging to the ECU group 100 and the method thereof described herein may be implemented by a dedicated computer provided by configuring a processor and memory programmed to execute one or more functions embodied in a computer program. Alternatively, each ECU and center 35 belonging to the ECU group 100 and the method thereof described herein may be implemented by a dedicated computer provided by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, each ECU and center 35 belonging to the ECU group 100 and the method thereof described herein may be implemented by one or more dedicated computers configured by combining a processor and memory programmed to execute one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible recording medium. The method for implementing the functions of each unit included in each ECU and center 35 belonging to the ECU group 100 does not necessarily need to include software; all of the functions may be implemented using one or more hardware.

[0178] (8e) 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.

[0179] (8f) In addition to the vehicle control system described above, the present disclosure can also be realized in various forms, such as a system that includes the vehicle control system as a component, a program for causing a computer to function as the vehicle control system, a non-transient physical recording medium such as a semiconductor memory on which this program is recorded, and a method for arbitrating HMI usage requests.

[0180] [Technical Ideas Disclosed in the Specification] [Item 1] A vehicle control system comprising: an information providing unit (861) configured to provide, in response to a request from application software, information set for each usage pattern classified according to the use or purpose of using an HMI for a vehicle, constraint information including the HMI that can be used in the usage pattern and constraints imposed on the HMI in the usage pattern; and an output control unit (862) configured to control the HMI in accordance with an HMI usage request from the application software requesting use of the HMI, wherein the output control unit is configured to determine which of the usage patterns the content of the HMI usage request corresponds to, and, in the event of conflicting HMI usage requests, arbitrate the conflicting HMI usage requests in accordance with the priority associated with the usage pattern.

[0181] [Item 2] The vehicle control system according to item 1, further comprising an information storage unit (85) that stores the restriction information, and the information providing unit is configured to provide the restriction information stored in the information storage unit.

[0182] [Item 3] The vehicle control system according to item 1 or 2, wherein the output control unit is configured to reject the HMI usage request when the content of the HMI usage request does not correspond to any of the usage patterns.

[0183] [Item 4] The vehicle control system according to any one of items 1 to 3, wherein the constraint information provided by the information providing unit includes dynamic information that changes depending on the status of the vehicle equipped with the vehicle control system or a conflict occurring status of the HMI usage request.

[0184] [Item 5] A vehicle control system according to any one of items 1 to 4, wherein the constraint information provided by the information providing unit includes at least one of information indicating the available in-vehicle HMI, information associated with the driver's noticeability of the output, the amount of information that can be provided, the time period for which the information can be provided, and information specifying the occupants of the vehicle to whom the information is to be provided.

[0185] [Item 6] A vehicle control system according to any one of items 1 to 5, wherein, when the usage patterns of the conflicting HMI usage requests are the same, the output control unit is configured to arbitrate the output in accordance with application-specific information related to the application software that has requested the HMI usage requests, and the application-specific information includes at least one of information related to a manufacturer of the application software and a charge for the use of vehicle resources by the application software.

Claims

1. A vehicle control system comprising: an information providing unit (861) configured to provide, in response to a request from application software, information set for each usage pattern classified according to the use or purpose of using an HMI for a vehicle, the HMI being available in the usage pattern, and constraint information including constraints imposed on the HMI in the usage pattern; and an output control unit (862) configured to control the HMI in accordance with an HMI usage request from the application software requesting use of the HMI, wherein the output control unit is configured to determine which of the usage patterns the content of the HMI usage request corresponds to, and, in the event of conflict between the HMI usage requests, to arbitrate the conflicting HMI usage requests in accordance with the priority assigned to the usage pattern.

2. A vehicle control system as described in claim 1, further comprising an information storage unit (85) that stores the constraint information, and the information providing unit is configured to provide the constraint information stored in the information storage unit.

3. A vehicle control system as described in claim 1, wherein the output control unit is configured to reject the HMI usage request if the content of the HMI usage request does not correspond to any of the usage patterns.

4. A vehicle control system as described in claim 1, wherein the constraint information provided by the information providing unit includes dynamic information that changes depending on the status of the vehicle in which the vehicle control system is installed or the occurrence of conflicts in the HMI usage requests.

5. A vehicle control system as described in claim 1, wherein the constraint information provided by the information providing unit includes at least one of information indicating the available in-vehicle HMI, information associated with the driver's susceptibility to notice the output, the amount of information that can be provided, the time period during which the information can be provided, and information specifying the occupants of the vehicle to whom the information is to be provided.

6. A vehicle control system as described in claim 1, wherein the output control unit is configured to arbitrate the output in accordance with app-specific information related to the application software that has made the HMI usage request when the usage patterns of the conflicting HMI usage requests are the same, and the app-specific information includes at least one of information related to the manufacturer of the application software and an amount charged for the use of vehicle resources by the application software.

7. An arbitration method in which a computer installed in a vehicle arbitrates HMI usage requests from multiple application software that utilize an HMI for the vehicle, the arbitration method determining whether the content of the HMI usage request corresponds to one of usage patterns classified according to the application or purpose of using the HMI (S120-S180), and in the event of conflict between the HMI usage requests, arbitrating the conflicting HMI usage requests in accordance with the priority associated with the usage pattern (S190-S250).

8. A program that causes a computer to function as: an information providing unit (861) configured to provide, in response to a request from application software, information set for each usage pattern classified according to the use or purpose of using an HMI for a vehicle, the HMI being available in the usage pattern, and constraint information including constraints imposed on the HMI in the usage pattern; and an output control unit (862) configured to control the HMI in accordance with an HMI usage request from the application software requesting use of the HMI, wherein the output control unit determines which of the usage patterns the content of the HMI usage request corresponds to, and, in the event of conflict between the HMI usage requests, arbitrates the conflicting HMI usage requests in accordance with the priority assigned to the usage pattern.

Images