In-vehicle devices, service delivery methods, and service delivery programs

Abstract

A vehicle-mounted device (4) constitutes a vehicle control system (2) together with a plurality of electronic control devices (5 to 7). The vehicle-mounted device is provided with a coordinated control unit (40). The coordinated control unit includes a usage suspension determining unit (S30) and a usage control unit (S40 to S70, S100 to S120). The usage suspension determining unit determines whether a usage suspension condition is satisfied, the usage suspension condition indicating that use of a functional interface (37) must be suspended due to factors relating to charges incurred through the use of at least one of a service application (SA1) and the functional interface. The usage control unit switches the operation of the vehicle control system on the basis of functional interface information relating to the functional interface in which the usage suspension condition has been established, vehicle status information, and user input information.

Description

Cross-reference to Related Applications

[0001] This international application claims the benefit of Japanese Patent Application No. 2023-097691, filed with the Japan Patent Office on June 14, 2023, the entire disclosure of which is incorporated herein by reference.

Technical Field

[0002] The present disclosure relates to an in-vehicle device that provides services to a vehicle, a service providing method, and a service providing program.

Background Art

[0003] Patent Document 1 describes a vehicle including a control unit that operates the vehicle based on operation information received from a management server, a management unit that manages compartments of the vehicle where a service user receives services from a service provider, and an interface unit that is set in association with service-related information provided by the service provider and the compartments.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

[0005] When a service provider provides a service to a vehicle as described in Patent Document 1, it may be necessary to obtain vehicle information regarding the vehicle from the target vehicle to which the service is provided, or to cause the target vehicle to perform a predetermined operation or process.

[0006] Thus, when a service provider uses a vehicle by obtaining vehicle information from the vehicle or causing the vehicle to perform a predetermined operation or process, it is desirable to charge the service provider for this use.

[0007] As a result of the inventor's detailed examination, it was found that if a service provider were to uniformly suspend the above-mentioned use due to factors related to billing (for example, if the usage fee exceeds the upper limit), it could impair the convenience of users who use the services provided by the service provider.

[0008] This disclosure aims to improve the convenience of users who utilize the service.

[0009] One aspect of this disclosure is an in-vehicle device that is mounted in a vehicle, connected to a plurality of electronic control units via an in-vehicle network, and constituting a vehicle control system together with the plurality of electronic control units.

[0010] The in-vehicle device of this disclosure includes a coordination control unit configured to enable coordination between a service application configured to provide services to a vehicle and a control system function block configured to control the vehicle. The control system function block includes a functional interface configured to convert access requests sent from the service application in a vehicle-independent format into a vehicle-dependent format. The coordination control unit is configured to forward access requests sent from the service application to the control system function block.

[0011] The collaborative control unit comprises a usage suspension determination unit and a usage control unit.

[0012] The service termination determination unit is configured to determine whether a pre-configured service termination condition has been met, which indicates that the use of the functional interface needs to be terminated due to factors related to charges incurred by using at least one of the service application and the functional interface.

[0013] The usage control unit is configured to switch the operation of the vehicle control system based on functional interface information relating to functional interfaces for which the usage deactivation conditions have been met, vehicle status information indicating the status of the vehicle, and user input information entered by the user using the vehicle.

[0014] The in-vehicle device of this disclosure, configured in this manner, switches the operation of the vehicle control system based on functional interface information and vehicle status information user input information. As a result, the in-vehicle device of this disclosure can prevent situations in which the use of the functional interface is uniformly stopped when it is necessary to stop using the functional interface due to factors related to billing, thereby preventing users from using the service and improving the convenience of users using the service.

[0015] Another aspect of this disclosure is a service delivery method performed by an in-vehicle device that is mounted in a vehicle, connected to a plurality of electronic control units via an in-vehicle network, and which, together with the plurality of electronic control units, constitutes a vehicle control system.

[0016] The in-vehicle device includes a coordination control unit configured to enable coordination between a service application and a control system function block. The control system function block includes a function interface. The coordination control unit is configured to forward access requests sent from the service application to the control system function block.

[0017] In the service provision method of this disclosure, the cooperation control unit determines whether a pre-configured deactivation condition has been met, which indicates that the use of a functional interface needs to be stopped due to factors related to charges incurred by using at least one of the service application and the functional interface. The cooperation control unit also switches the operation of the vehicle control system based on functional interface information relating to the functional interface for which the deactivation condition has been met, vehicle status information indicating the status of the vehicle, and user input information entered by the user using the vehicle.

[0018] The service provision method described herein is a method executed by the in-vehicle device described herein, and by executing this method, the same effects as those of the in-vehicle device described herein can be obtained.

[0019] Yet another aspect of the present disclosure is a service - providing program for causing a computer of an in - vehicle device mounted on a vehicle, connected to a plurality of electronic control units via an in - vehicle network, and constituting a vehicle control system together with the plurality of electronic control units, to function as a function interface, a cooperation control unit, a usage stop determination unit, and a usage control unit.

[0020] The computer controlled by the service - providing program of the present disclosure can form a part of the in - vehicle device of the present disclosure and can obtain the same effects as the in - vehicle device of the present disclosure.

Brief Description of the Drawings

[0021] [Figure 1] It is a block diagram showing the configuration of a service - providing system. [Figure 2] It is a block diagram showing the configuration of an ECU. [Figure 3] It is a block diagram showing the charging procedure. [Figure 4] It is a diagram showing the procedure of an API contract. [Figure 5] It is a block diagram showing the destination of a first API usage stop request. [Figure 6] It is a block diagram showing the destination of a second API usage stop request. [Figure 7] It is a flowchart showing the first half of an API usage control process. [Figure 8] It is a flowchart showing the second half of an API usage control process.

Embodiments of the Invention

[0022] Hereinafter, embodiments of the present disclosure will be described together with the drawings.

[0023] As shown in FIG. 1, the service - providing system 1 of the present embodiment includes a vehicle control system 2 and a server 3.

[0024] The vehicle control system 2 is mounted on the vehicle and has the function of communicating data with the server 3 via a wide-area wireless communication network (NW).

[0025] Server 3 has the function of communicating data with the vehicle control system 2 via a wide-area wireless communication network (NW). Server 3 has an app store that can be accessed via the wide-area wireless communication network (NW) or the internet.

[0026] A vehicle equipped with the vehicle control system 2 may have an automatic driving function in addition to a manual driving function. The vehicle may be a hybrid vehicle having an engine and an electric motor as its driving source. The vehicle is not limited to a vehicle with an automatic driving function or a hybrid vehicle; it may also be a vehicle with only a manual driving function, or a vehicle having only an engine or only an electric motor as its driving source. Hereinafter, a vehicle equipped with the vehicle control system 2 will simply be referred to as a vehicle.

[0027] The vehicle control system 2 comprises one ECU 4, multiple ECUs 5, multiple ECUs 6, an external communication device 7, and an internal communication network 8. ECU stands for Electronic Control Unit.

[0028] ECU4 integrates multiple ECUs5 to achieve coordinated control throughout the entire vehicle.

[0029] Each ECU5 is located in a domain defined by the vehicle's function, and primarily controls multiple ECU6s within that domain. Each ECU5 is connected to its subordinate ECU6s via a separate underlying network (e.g., CAN). CAN stands for Controller Area Network. CAN is a registered trademark. Domains include, for example, powertrain, body, chassis, and cockpit.

[0030] ECU6 connected to ECU5, which belongs to the powertrain domain, includes, for example, an ECU6 that controls the engine, an ECU6 that controls the motor, and an ECU6 that controls the battery.

[0031] ECU6 connected to ECU5 belonging to the body domain includes, for example, an ECU6 that controls the air conditioner and an ECU6 that controls the doors.

[0032] ECU6 connected to ECU5 belonging to the chassis domain includes, for example, an ECU6 that controls the brakes and an ECU6 that controls the steering.

[0033] ECU6 connected to ECU5 belonging to the cockpit domain includes, for example, ECU6 that controls the displays of the meters and navigation device 100, and ECU6 that controls input devices operated by the vehicle occupants.

[0034] The external communication device 7 communicates data with the server 3 via a wide-area wireless communication network (NW).

[0035] The in-vehicle communication network 8 includes CAN FD and Ethernet. Ethernet is a registered trademark. CAN FD stands for CAN with Flexible Data Rate. CAN FD bus-connects ECU 4 to each ECU 5 and the external communication device 7. Ethernet connects ECU 4 to each ECU 5 and the external communication device 7 individually.

[0036] The ECU4 is an electronic control unit centered around a microcomputer equipped with a CPU4a, ROM4b, RAM4c, etc. The various functions of the microcomputer are realized by the CPU4a executing a program stored in a non-transitional physical recording medium. In this example, ROM4b corresponds to the non-transitional physical recording medium storing the program. Furthermore, the execution of this program executes the method corresponding to the program. Note that some or all of the functions performed by the CPU4a may be configured hardware-wise using one or more ICs. Also, the number of microcomputers constituting the ECU4 may be one or more.

[0037] The ECU4 also includes flash ROM4d. Flash ROM4d is a non-volatile memory whose contents can be rewritten.

[0038] ECU5, ECU6, and the external communication device 7 are all electronic control units, similar to ECU4, that are centered around a microcomputer equipped with a CPU, ROM, RAM, etc. The number of microcomputers constituting ECU5, ECU6, and the external communication device 7 may be one or more. ECU5 controls one or more ECU6s. ECU4 controls one or more ECU5s, or controls all ECU5, ECU6, and the external communication device 7 for the entire vehicle.

[0039] In the following, ECU4, ECU5, ECU6, and the external communication device 7 will be referred to as in-vehicle devices 4-7 unless otherwise specified.

[0040] Server 3 comprises a control unit 11, a communication unit 12, and a storage unit 13.

[0041] The control unit 11 is an electronic control unit centered around a microcomputer equipped with a CPU 11a, ROM 11b, RAM 11c, etc. The various functions of the microcomputer are realized by the CPU 11a executing a program stored in a non-transitional physical recording medium. In this example, ROM 11b corresponds to the non-transitional physical recording medium that stores the program. Furthermore, the execution of this program executes a method corresponding to the program. Note that some or all of the functions performed by the CPU 11a may be configured hardware-wise by one or more ICs, etc. Also, the number of microcomputers constituting the control unit 11 may be one or more.

[0042] The communication unit 12 communicates data with the vehicle control system 2 via a wide-area wireless communication network NW. The storage unit 13 is a storage device for storing various types of data.

[0043] The service provision system 1 further includes a servicer terminal device 9. The servicer terminal device 9 is a device managed by the service provider SV (hereinafter referred to as Servicer SV), which will be described later, and is, for example, a personal computer.

[0044] The servicer terminal device 9 comprises a control unit 15, a communication unit 16, a storage unit 17, a display unit 18, and an operation input unit 19.

[0045] The control unit 15 is an electronic control unit that is mainly composed of a microcomputer equipped with a CPU, ROM, RAM, etc.

[0046] The communication unit 16 communicates data with the vehicle control system 2 and the server 3 via a wide-area wireless communication network NW. The storage unit 17 is a storage device for storing various types of data. The display unit 18 includes a display device (not shown) and displays various images on the display screen of the display device. The operation input unit 19 outputs input operation information to identify input operations performed by the user via a keyboard and mouse (not shown).

[0047] The service provision system 1 further includes a mobile terminal device 10. The mobile terminal device 10 is an information processing terminal (e.g., a smartphone or tablet) carried by the vehicle driver (i.e., the user US described later). The mobile terminal device 10 has the function of communicating data with the vehicle control system 2 via a wide-area wireless communication network NW.

[0048] As shown in Figure 2, the ECU4 comprises a real-time processing unit 20 and an application processing unit 30 (hereinafter referred to as the application processing unit 30). If the ECU4 comprises multiple CPUs 4a, the real-time processing unit 20 and the application processing unit 30 may be implemented by processes executed by the same CPU, or they may be implemented by processes executed by different CPUs.

[0049] The real-time processing unit 20 works in conjunction with in-vehicle devices 5-7 connected via CAN FD to perform vehicle control and other operations that require real-time processing. The application processing unit 30 works in conjunction with in-vehicle devices 5-7 connected via Ethernet to execute various applications that require high processing power (for example, entertainment applications).

[0050] The application processing unit 30 has the function of transmitting instructions and other information based on the processing of various applications to the real-time processing unit 20. The real-time processing unit 20 has the function of transmitting information and other information collected from the ECU, etc., via CAN FD to the application processing unit 30. As a result, the real-time processing unit 20 and the application processing unit 30 cooperate with each other to realize various functions.

[0051] The software for the vehicle control system 2 is built in accordance with AUTOSAR. AUTOSAR is an architecture for autonomous driving and is an abbreviation for Automotive Open System Architecture. AUTOSAR is a registered trademark. AUTOSAR provides not only communication between software components (hereinafter referred to as SW-C) implemented to realize various applications, but also functions related to cloud connectivity and security. SW-C is software that has been modularized to realize a certain function. An application program contains one or more SW-Cs. However, the software for the vehicle control system 2 does not necessarily have to be built in accordance with AUTOSAR.

[0052] Each device belonging to the vehicle control system 2, namely ECU4, ECU5, ECU6, and the external communication device 7, is equipped with a platform. The platform provides an environment for executing SW-C written in a hardware-independent format.

[0053] The platform comprises a runtime environment (RTE) and foundational software (BSW). The RTE is the interface connecting SW-Cs to each other and to the BSW. The BSW is the layer connecting the hardware and SW-Cs, and includes the OS, drivers, middleware, etc. The functions of the BSW are divided into smaller modules, and the functions of each module are provided to the SW-Cs via APIs. API stands for Application Programming Interface.

[0054] Hereinafter, the platform provided by the real-time processing unit 20 will be referred to as the first platform 21 (hereinafter, the first PF21), and the platform provided by the application processing unit 30 will be referred to as the second platform 31 (hereinafter, the second PF31).

[0055] The real-time processing unit 20 includes a control system function block group 22 as a collection of service applications (hereinafter referred to as service apps) that operate on the first PF 21. A service app is an application that receives requests from clients, processes them, and returns the results.

[0056] The control system function block group 22 is equipped with an API that receives commands related to the vehicle's motion, and is a group of applications that integrate the commands received by the API to realize consistent vehicle control. The control system function block group 22 outputs various commands via the in-vehicle communication network 8 to the in-vehicle devices 5 to 7, which are entities that execute control based on those commands.

[0057] The first PF21 includes a conversion gateway 211. The conversion gateway 211 has the function of converting communication frames received by the real-time processing unit 20 via CAN FD into Ethernet format and providing them to the application processing unit 30. The conversion gateway 211 also has the function of converting Ethernet format communication frames provided by the application processing unit 30 into CAN FD format.

[0058] The application processing unit 30 includes a hypervisor 32 and runs software on multiple virtual machines. Note that the hypervisor 32 may be omitted.

[0059] The application processing unit 30 includes a group of service-related function blocks 33, which are a collection of service applications that operate on the second PF 31.

[0060] The service-related function block group 33 is a collection of service applications. Each service application includes one or more SW-Cs. Service applications are provided not only by the vehicle manufacturer that produced the vehicle, but also by third parties. An example of a third party providing a service application is a data utilization company that provides services by collecting data from vehicles.

[0061] The second PF31 comprises a control system function block group 35, a data system function block group 36, and an API gateway 40.

[0062] The control system function block group 35 is a collection of programs equipped with APIs for receiving requests related to vehicle control from the service system function block group 33. The control system function block group 35 is equipped with an API group 37 consisting of multiple APIs, and converts API access requests from the service system function block group 33, which are expressed in a vehicle-independent format, into API access requests expressed in a vehicle-dependent format, and provides them to the real-time processing unit 20. The above "vehicle-independent format" refers to a format common to vehicles (i.e., a format that absorbs differences between vehicle types). The above "vehicle-dependent format" refers to a format specific to a vehicle.

[0063] The control system function block group 35 has APIs that include motion system APIs for controlling the vehicle's motion and other non-motion system APIs. API access requests received by the motion system APIs are forwarded to the control system function block group 35, and from the control system function block group 35, they are forwarded via the in-vehicle communication network 8 to the in-vehicle devices 5-7 that execute the control based on the request. API access requests received by the non-motion system APIs are also forwarded via the in-vehicle communication network 8 to the in-vehicle devices 5-7 that execute the control based on the request.

[0064] The data system function block group 36 is a collection of programs equipped with APIs for handling vehicle data acquired and stored via the real-time processing unit 20. The data system function block group 36 has the function of abstracting and storing vehicle data, which is expressed in a vehicle-dependent format and supplied from the real-time processing unit 20, in a vehicle-independent format. The data system function block group 36 may also have an API that provides the function of transmitting specified vehicle data to an ECU or the like via Ethernet. In particular, if the destination is an external communication device 7, the external communication device 7 may upload the transmitted vehicle data to the cloud.

[0065] Furthermore, communication with other in-vehicle devices 5-7 via the control system function block group 35 may not be limited to CAN FD, but may use Ethernet or other communication means. Similarly, communication with other in-vehicle devices 5-7 via the data system function block group 36 may not be limited to Ethernet, but may use CAN FD or other communication means.

[0066] The API gateway 40 is configured using the functions of a virtual function bus (hereinafter referred to as VFB). The VFB is middleware that enables communication between SW-Cs and between SW-Cs and BSWs without requiring awareness of hardware and communication protocols, and is also called a software bus. Communication between SW-Cs refers to access from one SW-C to an API provided by another SW-C, and communication between SW-Cs and BSWs refers to access from one SW-C to an API provided by the control system function block group 35 and the data system function block group 36.

[0067] In other words, SW-C accesses various APIs via the API gateway 40 and uses the functions provided by the accessed APIs to realize the desired functionality.

[0068] When SW-C uses an API, it sends an API access request. The API access request includes at least the application ID of the service application containing the requesting SW-C, and the API-ID, which is information indicating the API to which the request is being made.

[0069] As shown in Figure 3, an app store 14 is installed on server 3. As indicated by arrow L1, the app store 14 has the function of registering the first service app SA1 manufactured by servicer SV based on an application made by servicer SV who accesses the app store 14 using servicer terminal device 9. The first service app SA1 registered in the app store 14 is posted on the app store 14's website.

[0070] Furthermore, as indicated by arrow L2, the app store 14 has the function of registering the APIs used by the first service app SA1 in the app store 14 based on an application from the servicer SV.

[0071] When user US accesses the App Store 14 website and purchases the first service app SA1, the first service app SA1 is installed in the ECU4 of user US's vehicle, as indicated by arrow L3.

[0072] As indicated by arrow L4, when the first service application SA1 sends an API access request to the API gateway 40, the API gateway 40 forwards the API access request to the control system function block group 35, as indicated by arrow L5. The control system function block group 35 converts the API access request into an API access request expressed in a vehicle-dependent format, as described above, and provides it to the real-time processing unit 20.

[0073] As indicated by arrow L6, the API gateway 40 sends a statistical access log to the app store 14, which includes the number of API uses, taking into account the status of successful execution of API access requests, and the amount of communication data associated with API use.

[0074] Based on the statistical access logs received from the API gateway 40, the app store 14 calculates the API usage fee incurred by the first service app SA1 using the API and bills the servicer SV for the API usage fee. As indicated by arrow L7, the servicer SV pays the billed API usage fee to the app store 14.

[0075] App Store 14 calculates the app usage fee for Service App SA1 based on its usage status and bills User US for the app usage fee. User US pays the billed app usage fee to App Store 14, as indicated by arrow L8. App Store 14 transfers the app usage fee paid by User US to Servicer SV, as indicated by arrow L9.

[0076] Furthermore, as indicated by arrow L10, when the first service application SA1 sends an API access request to the API gateway 40, the API gateway 40 may forward the API access request to the second service application SA2, which provides a different service from the first service application SA1.

[0077] Next, we will explain the procedure for Servicer SV to enter into an API usage agreement.

[0078] As shown in process P1 of Figure 4, the servicer SV accesses the app store 14 and applies for registration of the service app to be listed and the API to be used.

[0079] As shown in process P2, the app store 14 examines whether the service application submitted by the servicer SV can access the control system function block group 35.

[0080] If the submitted service application has access to the control system function block group 35, the app store 14 presents the servicer SV with a billing method for the API usage, as shown in process P3.

[0081] As shown in Table TB1, the app store 14 stores API policy information, including the API-ID, reliability, and billing method, for each submitted API in the storage unit 13.

[0082] In table TB1, APIs with API-ID API1 have a reliability rating of "High" and are billed on a "per-call" basis, while APIs with API-ID API2 have a reliability rating of "Low" and are billed on a "monthly" basis.

[0083] APIs with a reliability setting of "High" will accept API access requests from highly reliable service applications and reject API access requests from less reliable service applications.

[0084] APIs with a reliability setting of "low" will accept API access requests even from unreliable service applications.

[0085] "Call-based billing" is a billing model where charges are added according to the number of API access requests. "Monthly billing" is a billing model where a fixed fee is charged every month, regardless of the number of API access requests.

[0086] As shown in process P4, Servicer SV notifies App Store 14 that it agrees to the proposed usage API billing model. As a result, App Store 14 publishes the service app applied for by Servicer SV on App Store 14's website, as shown in process P5.

[0087] The app store 14 stores information about the service apps to be posted on the website (hereinafter referred to as "posted app information") and information about the APIs authorized for the service apps to be posted on the website (hereinafter referred to as "API authorization information") in the storage unit 13.

[0088] As shown in Table TB2, the listed application information includes, for each listed service application, the application ID, the function name of the service application, the billing method of the service application, and the servicer ID. The application ID is information used to identify the service application. The servicer ID is information used to identify the provider of the service application.

[0089] In Table TB2, the service app with App ID APP1 has the function name "Comfortable Air Conditioning," the billing method is "Usage Time," and the servicer ID is "Dev1." The service app with App ID APP2 has the function name "Road Service," the billing method is "Monthly," and the servicer ID is "Dev1."

[0090] The "Usage Time" billing method charges a fee based on the amount of time the service app is used. The "Monthly" billing method charges a fixed fee each month, regardless of the amount of time the service app is used.

[0091] As shown in Table TB3, API authorization information includes the API-ID and application ID for each authorized API.

[0092] Table TB3 shows that APIs with API-ID API1 are called by service applications with application ID APP1, and APIs with API-ID API2 are called by service applications with application ID APP2.

[0093] Next, we will explain the circumstances under which API usage may be suspended due to billing-related factors.

[0094] As shown in Figure 5, the API gateway 40 determines whether the API usage contract has expired. If it determines that the API usage contract has expired, the API gateway 40 sends a first API usage suspension request to the control system function block group 35, the first service application SA1, and the second service application SA2, as indicated by arrows L11, L12, and L13, indicating that the use of the expired API will be stopped. The first API usage suspension request is accompanied by an API-ID that identifies the API for which the suspension is to be requested.

[0095] As shown in Figure 6, the app store 14 determines whether user US is in arrears on the usage fees for the first service app SA1, and whether servicer SV is in arrears on the usage fees for the API. If it determines that user US is in arrears on the usage fees for the first service app SA1, or if it determines that servicer SV is in arrears on the usage fees for the API, the app store 14 sends a second API usage suspension request to the first service app SA1, indicating that the use of the API will be suspended due to the arrears, as shown by arrow L21. The second API usage suspension request is accompanied by an API-ID that identifies the API for which the suspension is to be requested.

[0096] When the first service application SA1 receives a request to deactivate the second API, it sends the request to the API gateway 40, as indicated by arrow L22.

[0097] When the API gateway 40 receives a request to deactivate the second API, it sends the request to the control system function block group 35 and the second service application SA2, as indicated by arrows L23 and L24.

[0098] Furthermore, the API gateway 40 determines whether the usage fee for the first service application SA1 by user US has exceeded the billing limit set by user US. In addition, the API gateway 40 determines whether the API usage fee for the first service application SA1 has exceeded the billing limit set by servicer SV.

[0099] If the API gateway 40 determines that the usage fee for the first service application SA1 has exceeded the billing limit, or if it determines that the usage fee for the API has exceeded the billing limit, the API gateway 40 sends a third API usage suspension request to the control system function block group 35, the first service application SA1, and the second service application SA2, indicating that the use of the API will be stopped because the billing limit has been exceeded. The third API usage suspension request is accompanied by an API-ID that identifies the API for which the suspension is to be requested.

[0100] The API gateway 40 also determines whether there are insufficient resources to execute the processing corresponding to the API. If it determines that there are insufficient resources to execute the processing corresponding to the API, the API gateway 40 sends a fourth API usage suspension request to the control system function block group 35, the first service application SA1, and the second service application SA2, indicating that the use of the API for which resources are insufficient should be stopped. The fourth API usage suspension request is accompanied by an API-ID that identifies the API for which the suspension is to be requested.

[0101] Next, the procedure for the API usage control process executed by the API gateway 40 will be explained. The API usage control process is a process that is repeatedly executed while the ECU 4 is operating.

[0102] When the API usage control process is executed, the API gateway 40 (hereinafter referred to as APIGW40) determines in S10 whether or not there is a prediction of an API usage outage, as shown in Figure 7.

[0103] Specifically, APIGW40 determines that an API outage is predicted when it receives API outage prediction information from the app store 14. The API outage prediction information includes a list of service apps that will become unusable due to the API outage, the reason for the API outage, the timing of the API outage (for example, "API will be stopped in X minutes"), points to note regarding the API outage, and whether additional charges will be incurred.

[0104] Furthermore, APIGW40 determines that an API outage is likely if the API usage contract expires, the service application usage fee exceeds the billing limit, the API usage fee exceeds the billing limit, or there are insufficient resources to execute the processing corresponding to the API. After determining that an API outage is likely, APIGW40 sends the above-mentioned API outage requests 1, 3, and 4 after a predetermined waiting period has elapsed.

[0105] If there is no prediction of an API outage, APIGW40 will repeat the process in S10 until an API outage is predicted. When an API outage is predicted, APIGW40 will notify the user US and servicer SV in S20 that the service application will be stopped. In addition to stopping the service application, APIGW40 will notify the user US and servicer SV of a list of service applications that will become unusable due to the API outage, the reason for stopping the API, the timing of the API outage, points to note regarding the API outage, and the status of any additional charges.

[0106] Specifically, if there are occupants in the vehicle, APIGW40 notifies the user US to stop the service application, for example, by displaying it on the display screen of the navigation device 100. APIGW40 determines whether or not there are occupants in the vehicle by detecting whether or not an occupant is seated in each of the multiple seats installed in the vehicle interior, based on the detection results of multiple seat occupancy sensors installed on each of the seats in the vehicle interior.

[0107] APIGW40 notifies the user US's mobile device 10 to stop the service application if there are no occupants in the vehicle. The user US's phone number or email address is pre-registered in ECU4.

[0108] APIGW40 notifies the servicer terminal device 9 of servicer SV that the service application will be stopped.

[0109] APIGW40 determines at S30 whether it is time to stop using the API. Specifically, APIGW40 determines that it is time to stop using the API when it receives the above-mentioned second API usage stop request from the app store 14. APIGW40 also determines that it is time to stop using the API when it sends the above-mentioned first, third, and fourth API usage stop requests.

[0110] If it is not yet time to stop using the API, APIGW40 will repeat the process in S30 until it is time to stop using the API. When it is time to stop using the API, APIGW40 will determine in S40 whether it is advisable not to allow the API to be stopped (hereinafter referred to as the API to be stopped). Specifically, APIGW40 will determine whether it is advisable not to allow the API to be stopped by referring to a pre-configured disallowance setting table that shows whether or not there is a possibility of disallowance for each of multiple APIs. The disallowance setting table is stored in flash ROM4d.

[0111] Examples of APIs where it is not advisable not to allow API usage suspension include information gathering APIs, APIs that improve the in-car environment, and entertainment APIs.

[0112] Examples of APIs for which it may be better not to allow API suspension include APIs directly related to driving operations, autonomous driving system APIs, and advanced driver assistance system APIs.

[0113] If there are no cases where it is better not to allow the API to be stopped, APIGW40 proceeds to S120. On the other hand, if there are cases where it is better not to allow the API to be stopped, APIGW40 determines in S50 whether or not the vehicle is in motion. Specifically, APIGW40 determines that the vehicle is in motion if the vehicle's speed is above a predetermined speed (for example, 3 km / h).

[0114] If the vehicle is in motion, APIGW40 proceeds to S70. On the other hand, if the vehicle is not in motion, APIGW40 determines in S60 whether the vehicle is stopped or not. Specifically, APIGW40 determines that the vehicle is stopped if the vehicle's speed is below a preset stopping speed (for example, 3 km / h) and the shift position is in drive or neutral.

[0115] If the vehicle is stationary, APIGW40 proceeds to S90. On the other hand, if the vehicle is not stationary, APIGW40 determines that the vehicle is parked and proceeds to S110.

[0116] When migrating to S70, as shown in Figure 8, APIGW40 will prohibit the deactivation of APIs that are subject to suspension. As a result, additional charges will be incurred for continued use of the APIs. These additional charges for continued use of the APIs will be calculated separately from the regular charges. The burden of these charges may fall on either the user (US) or the servicer (SV). For example, excess usage due to the user's responsibility may be borne by the user, while excess usage that is unavoidable due to security considerations may be borne by the servicer.

[0117] APIGW40, in S80, notifies user US and servicer SV that API usage deactivation for the target APIs is prohibited, and terminates the API usage control process. Specifically, if there are occupants in the vehicle, APIGW40 notifies user US that API usage deactivation for the target APIs is prohibited, for example, by displaying it on the display screen of the navigation device 100. If there are no occupants in the vehicle, APIGW40 notifies user US's mobile terminal device 10 that API usage deactivation for the target APIs is prohibited. APIGW40 also notifies servicer SV's servicer terminal device 9 that API usage deactivation for the target APIs is prohibited.

[0118] When migrating to S90, APIGW40 will notify users (US) and servicers (SV) that the service application will be stopped, similar to how it was done with S20.

[0119] In S100, APIGW40 determines whether user US has authorized API deactivation based on input operations by user US via the input device installed in the vehicle. Specifically, if the user input information output by the input device, resulting from user US's input operations via the input device, indicates authorization for API deactivation, APIGW40 determines that user US has authorized API deactivation. If the user input information indicates denial of API deactivation, APIGW40 determines that user US has not authorized API deactivation. Furthermore, if the input device does not output user input information after a predetermined waiting period has elapsed, APIGW40 determines that user US has not authorized API deactivation.

[0120] If user US has not authorized the termination of API usage, APIGW40 will terminate the API usage control process. This will result in additional charges for continued API usage. These additional charges for continued API usage will be calculated separately from regular charges.

[0121] When transitioning to S110, APIGW40 determines whether or not there are passengers in the vehicle. Specifically, based on the detection results of multiple seat sensors, APIGW40 determines that there are passengers in the vehicle if there is at least one seat occupied by an occupant.

[0122] If there are passengers on board the vehicle, APIGW40 proceeds to S90. On the other hand, if there are no passengers on board, APIGW40 stops using the APIs targeted for suspension at S120.

[0123] APIGW40, in S130, notifies the user US and servicer SV that the service application will be stopped, similar to S20, and terminates the API usage control process.

[0124] The ECU 4 configured in this way is mounted in the vehicle and connected to multiple in-vehicle devices 5-7 via an in-vehicle communication network 8, and together with the multiple in-vehicle devices 5-7, it constitutes the vehicle control system 2.

[0125] The ECU4 includes an API gateway 40. The API gateway 40 is configured to facilitate communication between a first service application SA1 configured to provide services to the vehicle and a control system function block group 35 configured to control the vehicle. The control system function block group 35 includes an API group 37. The API group 37 is configured to convert API access requests, which are expressed in a vehicle-independent format and sent from the first service application SA1, into a vehicle-dependent format. The API gateway 40 is configured to forward API access requests sent from the first service application SA1 to the control system function block group 35.

[0126] The API gateway 40 is configured to determine whether a pre-configured termination condition has been met, which indicates that the use of API group 37 needs to be stopped due to factors related to billing incurred by using at least one of the first service application SA1 and API group 37.

[0127] The API gateway 40 is configured to switch the operation of the vehicle control system 2 based on API disallowance information for APIs whose usage conditions have been met, vehicle status information indicating the status of the vehicle, and user input information entered by the user US who uses the vehicle. Although the control system function block group 35 and the data system function block group 36 are equipped with APIs, the switching of the operation of the vehicle control system 2 based on API disallowance information etc. is applied to the control system function block group 35 and not to the data system function block group 36.

[0128] Such an ECU4 switches the operation of the vehicle control system 2 based on API disallowance information, vehicle status information, and user input information. This allows the ECU4 to prevent a situation where API use is uniformly stopped when it is necessary to stop using the API due to billing factors, thereby preventing users US from using the service and improving the convenience for users US who use the service.

[0129] Vehicle status information includes driving status information indicating the vehicle's driving status and occupant presence / absence information indicating the presence or absence of occupants in the vehicle. The API gateway 40 is configured to switch the operation of the vehicle control system 2 by deciding whether to prohibit or permit the deactivation of the API based on the API disallowance information, the vehicle status information, and the user input information. As a result, the ECU 4 can decide whether to prohibit or permit the deactivation of the API based on at least whether the vehicle is driving and whether or not there are occupants inside the vehicle.

[0130] The API gateway 40 is configured to prohibit the deactivation of an API if it determines, based on API disallowance information, that it may be better not to allow the deactivation of that API, and also if it determines, based on driving status information, that the vehicle is in motion. This prevents the ECU 4 from being unable to use necessary services while the vehicle is in motion, thereby further improving the convenience for users US who use the services.

[0131] The API gateway 40 is configured to authorize the deactivation of an API if, based on API disallowance information, it determines that it may be better not to authorize the deactivation of an API, and based on driving status information, it determines that the vehicle is stopped, and based on user input information, it determines that the user US has authorized the deactivation of the API. As a result, the ECU 4 can deactivate the API when the vehicle is stopped and the user US authorizes its deactivation. In other words, the API is deactivated when the user US determines that they do not need to use the API. Therefore, even if the API is deactivated, the ECU 4 can prevent situations where the user US is unable to use services they need, further improving the convenience for the user US who uses the services.

[0132] The API gateway 40 is configured to allow the deactivation of a functional interface if it determines, based on API disallowance information, that it may be better not to allow the deactivation of an API, based on driving status information, that the vehicle is parked, based on occupant presence information, that there are occupants in the vehicle, and based on user input information, that the user US has permitted the deactivation of the API. As a result, the ECU 4 can deactivate the API when the vehicle is parked and the user US has permitted its deactivation. In other words, the API is deactivated when the user US determines that it does not need to use the API. Therefore, even if the API is deactivated, the ECU 4 can prevent situations where the user US is unable to use services they need, and further improve the convenience of the user US using the services.

[0133] The API gateway 40 is configured to authorize the deactivation of a functional interface if it determines, based on API disallowance information, that it may be better not to authorize the deactivation of an API, and based on driving status information, it determines that the vehicle is parked, and based on occupant presence information, it determines that there are no occupants in the vehicle. As a result, the ECU 4 can deactivate the API when the vehicle is parked and there are no occupants in the vehicle. In other words, the API is deactivated when there are no users US who use the service in the vehicle. Therefore, even if the ECU 4 deactivates the API, it can prevent situations where users US are unable to use services they need, further improving the convenience for users US who use the service.

[0134] The API gateway 40 is configured to allow the deactivation of an API if it determines, based on API disallowance information, that there is no possibility that it would be better not to allow the deactivation of that API. In other words, APIs that can be deactivated without causing problems for the user US are uniformly deactivated based on billing factors. In this way, the ECU 4 deactivates APIs that can be deactivated without causing problems for the user US, thus preventing situations where users US are unable to use necessary services even if an API is deactivated, and further improving the convenience for users US who use the services.

[0135] Furthermore, the API gateway 40 is configured to determine whether a pre-configured condition for predicting the discontinuation of API use has been met, which indicates that the API may be discontinued. If the API gateway 40 determines that the condition for predicting the discontinuation of API use has been met, it is configured to notify the user US that the use of the first service application SA1, which uses this API, will be discontinued. This allows the ECU 4 to make the user US aware that they may not be able to use the first service application SA1.

[0136] Furthermore, the API gateway 40 is configured to notify the user US using the navigation device 100 installed in the vehicle if there are occupants in the vehicle, and to notify the user US using a pre-registered mobile terminal device 10 if there are no occupants in the vehicle. This prevents the ECU 4 from being unable to make the user US aware that the first service application SA1 has been stopped.

[0137] In the embodiments described above, ECU4 corresponds to an in-vehicle device, ECU5, ECU6 and the external communication device 7 correspond to multiple electronic control devices, and the in-vehicle communication network 8 corresponds to an in-vehicle network.

[0138] Furthermore, the first service application SA1 corresponds to a service application, the control system function block group 35 corresponds to a control system function block, the API gateway 40 corresponds to a cooperation control unit, and the API group 37 corresponds to a function interface.

[0139] Furthermore, S30 corresponds to processing as a usage suspension decision unit, the decision conditions of S30 correspond to usage suspension conditions, S40~S70 and S100~S120 correspond to processing as a usage control unit, and the API disallowance information corresponds to function interface information.

[0140] Furthermore, S10 corresponds to processing as a prediction and judgment unit, the judgment conditions of S10 correspond to the usage suspension prediction conditions, S20 corresponds to processing as a notification unit, the navigation device 100 corresponds to the first notification device, and the mobile terminal device 10 corresponds to the second notification device.

[0141] Although one embodiment of the present disclosure has been described above, the present disclosure is not limited to the above embodiment and can be implemented in various modified forms.

[0142] [Example 1] In the above embodiment, a method was shown to determine whether it is better not to allow API suspension based on API denial information indicating whether or not denial is possible. However, instead of determining whether or not denial is possible, the determination may also be made based on the level of denial possibility (e.g., 0, 1, 2, 3, ...).

[0143] [Differentiation 2] The above embodiment shows a configuration in which API usage is prohibited while the vehicle is in motion. However, API usage may be allowed to continue by prohibiting API usage suspension, and API usage may be stopped at a time when it can be safely terminated. Furthermore, if the vehicle has an autonomous driving function, API usage may be stopped by automatically switching to evasive driving mode.

[0144] [Difference 3] In the above embodiment, as shown in Figure 7, the process of S110 is performed. However, the process of S110 may be omitted. That is, if the vehicle is not stopped in S60, APIGW40 may proceed to S120. This allows ECU4 to stop using the API as soon as possible.

[0145] [Differentiation Example 4] In the above embodiment, a method was shown in which the vehicle's status (moving, stopped, or parked) was determined based on the vehicle's speed and shift position. However, the vehicle's driving status may also be determined using information from the navigation device 100.

[0146] [Difference 5] The above embodiment shows a method of suspending API usage due to billing-related factors. However, the suspension of API usage may also be controlled collectively for all APIs used by security-related service applications.

[0147] [Modification 6] The above embodiment shows a method of stopping API usage due to billing-related factors. However, API usage may also be controlled by preventing the service application from starting or by forcibly terminating it.

[0148] The ECU4 and its method described herein may be implemented by a dedicated computer provided by configuring a processor and memory programmed to perform one or more functions embodied by a computer program. Alternatively, the ECU4 and its method described herein may be implemented by a dedicated computer provided by configuring a processor by one or more dedicated hardware logic circuits. Alternatively, the ECU4 and its method described herein may be implemented by one or more dedicated computers configured by a combination of a processor and memory programmed to perform one or more functions and a processor configured by one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by the computer on a computer-readable non-transitional tangible recording medium. The method for implementing the functions of each part included in the ECU4 does not necessarily have to include software, and all of its functions may be implemented using one or more hardware components.

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

[0150] In addition to the ECU4 described above, this disclosure can also be realized in various forms, such as a system that uses the ECU4 as a component, a program for making the computer function as the ECU4, a non-transitional physical recording medium such as semiconductor memory that stores this program, and a service provision method. [Technical concepts disclosed in this specification] [Item 1] An on-board device (4) mounted on a vehicle, connected to a plurality of electronic control devices (5-7) via an on-board network (8), and constituting a vehicle control system (2) together with the plurality of said electronic control devices, The system includes a service application (SA1) configured to provide services to the vehicle and a control system function block (35) configured to control the vehicle, and a cooperation control unit (40) configured to enable cooperation between the two. The aforementioned control system function block is: The system includes a functional interface (37) configured to convert access requests, expressed in a vehicle-independent format and transmitted from the service application, into a vehicle-dependent format. The aforementioned cooperation control unit is configured to forward the access request transmitted from the service application to the control system function block. The aforementioned control unit, A service termination determination unit (S30) is configured to determine whether a pre-set termination condition has been met that indicates that it is necessary to terminate the use of the functional interface due to factors related to charges arising from the use of at least one of the service application and the functional interface, A usage control unit (S40~S70, S100~S120) is configured to switch the operation of the vehicle control system based on the function interface information relating to the function interface for which the usage suspension conditions have been met, vehicle status information indicating the status of the vehicle, and user input information entered by the user using the vehicle. An in-vehicle device equipped with the following features.

[0151] [Item 2] The in-vehicle device described in item 1, The vehicle status information includes driving status information indicating the driving status of the vehicle and occupant presence / absence information indicating the presence or absence of occupants in the vehicle. The in-vehicle device is configured to switch the operation of the vehicle control system by determining whether to prohibit or permit the deactivation of the function interface based on the function interface information, the vehicle status information, and the user input information.

[0152] [Item 3] The in-vehicle device described in item 2, An in-vehicle device configured such that, based on the function interface information, the control unit determines that it may be better not to permit the deactivation of the function interface, and, based on the driving status information, determines that the vehicle is in motion, it prohibits the deactivation of the function interface.

[0153] [Item 4] An in-vehicle device as described in item 2 or item 3, An in-vehicle device configured such that the usage control unit determines, based on the function interface information, that it may be better not to permit the deactivation of the function interface, and determines, based on the driving status information, that the vehicle is stopped, and determines, based on the user input information, that the user has permitted the deactivation of the function interface, in which case it permits the deactivation of the function interface.

[0154] [Item 5] An in-vehicle device described in any one of items 2 to 4, An in-vehicle device configured to permit the deactivation of a function interface when the control unit determines, based on the function interface information, that it may be better not to permit the deactivation of the function interface, and based on the driving status information, that the vehicle is parked, and based on the presence or absence of occupants information, that there are occupants in the vehicle, and based on the user input information, that the user has permitted the deactivation of the function interface.

[0155] [Item 6] An in-vehicle device described in any one of items 2 to 5, An in-vehicle device configured such that the usage control unit determines, based on the function interface information, that it may be better not to permit the deactivation of the function interface, and determines, based on the driving status information, that the vehicle is parked, and based on the presence or absence of occupants information, that there are no occupants in the vehicle, in which case it permits the deactivation of the function interface.

[0156] [Item 7] An in-vehicle device described in any one of items 2 to 6, An in-vehicle device configured such that the usage control unit determines, based on the function interface information, that there is no possibility that the function interface should not be permitted to be deactivated, and permits the deactivation of the function interface.

[0157] [Item 8] An in-vehicle device described in any one of items 2 to 7, The aforementioned control unit further, A prediction determination unit (S10) is configured to determine whether or not a pre-set usage suspension prediction condition has been met, which indicates that the use of the aforementioned functional interface may be suspended. A notification unit (S20) is configured to notify the user that the use of the service application using the functional interface will be stopped when the prediction determination unit determines that the aforementioned conditions for predicting the discontinuation of use have been met. An in-vehicle device equipped with the following features.

[0158] [Item 9] The in-vehicle device described in item 8, The notification unit is an in-vehicle device configured to notify the user using a first notification device (100) installed in the vehicle if the occupant is present in the vehicle, and to notify the user using a second notification device (10) that has been pre-registered with the user if the occupant is not present in the vehicle.

[0159] [Item 10] A service provision method performed by an in-vehicle device (4) that is mounted on a vehicle, connected to a plurality of electronic control devices (5-7) via an in-vehicle network (8), and which together with the plurality of electronic control devices constitutes a vehicle control system (2), The in-vehicle device includes a service application (SA1) configured to provide services to the vehicle and a control system function block (35) configured to control the vehicle, and a cooperation control unit (40) configured to enable cooperation between the two. The aforementioned control system function block is: The system includes a functional interface (37) configured to convert access requests, expressed in a vehicle-independent format and transmitted from the service application, into a vehicle-dependent format. The aforementioned cooperation control unit is configured to forward the access request transmitted from the service application to the control system function block. The cooperation control unit determines whether a pre-configured suspension condition has been met, which indicates that it is necessary to suspend the use of the functional interface due to factors related to charges incurred by using at least one of the service application and the functional interface. A service provision method in which the linked control unit switches the operation of the vehicle control system based on functional interface information relating to the functional interface for which the usage suspension condition has been met, vehicle status information indicating the status of the vehicle, and user input information entered by a user of the vehicle.

[0160] [Item 11] The computer of the on-board device (4), which is mounted in the vehicle, connected to multiple electronic control units (5-7) via an on-board network (8), and which together with the multiple electronic control units constitutes a vehicle control system (2), A functional interface (37) configured to convert access requests sent from a service application (SA1) configured to provide services to the vehicle, which are expressed in a vehicle-independent format, into a vehicle-dependent format. A cooperation control unit (40) is configured to enable cooperation between the service application and a control system function block (35) configured to control the vehicle by having the function interface, and is configured to forward the access request transmitted from the service application to the control system function block. A usage suspension determination unit (S30) is configured to determine whether a pre-set usage suspension condition has been met, which indicates that it is necessary to suspend the use of the functional interface due to factors related to charges arising from the use of at least one of the service application and the functional interface, A usage control unit (S40~S70, S100~S120) is configured to switch the operation of the vehicle control system based on the function interface information relating to the function interface for which the usage suspension conditions have been met, vehicle status information indicating the status of the vehicle, and user input information entered by the user using the vehicle. A service provision program designed to function as such.

Claims

1. An on-board device (4) mounted on a vehicle, connected to a plurality of electronic control devices (5-7) via an on-board network (8), and constituting a vehicle control system (2) together with the plurality of said electronic control devices, The system includes a service application (SA1) configured to provide services to the vehicle and a control system function block (35) configured to control the vehicle, and a cooperation control unit (40) configured to enable cooperation between the two. The aforementioned control system function block is: The system includes a functional interface (37) configured to convert access requests, which are expressed in a vehicle-independent format and transmitted from the service application, into a vehicle-dependent format. The aforementioned cooperation control unit is configured to forward the access request transmitted from the service application to the control system function block. The aforementioned control unit, A service termination determination unit (S30) is configured to determine whether a pre-set termination condition has been met that indicates that it is necessary to terminate the use of the functional interface due to factors related to charges incurred by using at least one of the service application and the functional interface, A usage control unit (S40-S70, S100-S120) is configured to switch the operation of the vehicle control system based on the function interface information relating to the function interface for which the usage suspension conditions have been met, vehicle status information indicating the status of the vehicle, and user input information entered by the user using the vehicle. An in-vehicle device equipped with the following features.

2. The in-vehicle device according to claim 1, The vehicle status information includes driving status information indicating the driving status of the vehicle and occupant presence / absence information indicating the presence or absence of occupants in the vehicle. The in-vehicle device is configured to switch the operation of the vehicle control system by determining whether to prohibit or permit the deactivation of the function interface based on the function interface information, the vehicle status information, and the user input information.

3. The in-vehicle device according to claim 2, An in-vehicle device configured such that, based on the function interface information, the control unit determines that it may be better not to permit the deactivation of the function interface, and, based on the driving status information, determines that the vehicle is in motion, it prohibits the deactivation of the function interface.

4. An in-vehicle device according to claim 2 or claim 3, An in-vehicle device configured such that the usage control unit determines, based on the function interface information, that it may be better not to permit the deactivation of the function interface, and determines, based on the driving status information, that the vehicle is stopped, and determines, based on the user input information, that the user has permitted the deactivation of the function interface, in which case it permits the deactivation of the function interface.

5. An in-vehicle device according to claim 2 or claim 3, An in-vehicle device configured to permit the deactivation of a function interface when the control unit determines, based on the function interface information, that it may be better not to permit the deactivation of the function interface, and based on the driving status information, that the vehicle is parked, and based on the presence or absence of occupants information, that there are occupants in the vehicle, and based on the user input information, that the user has permitted the deactivation of the function interface.

6. An in-vehicle device according to claim 2 or claim 3, An in-vehicle device configured such that the usage control unit determines, based on the function interface information, that it may be better not to permit the deactivation of the function interface, and determines, based on the driving status information, that the vehicle is parked, and based on the presence or absence of occupants information, that there are no occupants in the vehicle, in which case it permits the deactivation of the function interface.

7. An in-vehicle device according to claim 2 or claim 3, An in-vehicle device configured such that the usage control unit determines, based on the function interface information, that there is no possibility that the function interface should not be permitted to be deactivated, and permits the deactivation of the function interface.

8. An in-vehicle device according to claim 2 or claim 3, The aforementioned control unit further, A prediction determination unit (S10) is configured to determine whether or not a pre-set usage suspension prediction condition has been met, which indicates that the use of the aforementioned functional interface may be suspended. A notification unit (S20) is configured to notify the user that the use of the service application using the functional interface will be stopped when the prediction determination unit determines that the aforementioned conditions for predicting the suspension of use have been met. An in-vehicle device equipped with the following features.

9. The in-vehicle device according to claim 8, The notification unit is an in-vehicle device configured to notify the user using a first notification device (100) installed in the vehicle if the occupant is present in the vehicle, and to notify the user using a second notification device (10) that has been pre-registered with the user if the occupant is not present in the vehicle.

10. A service provision method that is installed in a vehicle, connected to a plurality of electronic control devices (5-7) via an in-vehicle network (8), and executed by an in-vehicle device (4) that, together with the plurality of electronic control devices, constitutes a vehicle control system (2), The in-vehicle device includes a service application (SA1) configured to provide services to the vehicle and a control system function block (35) configured to control the vehicle, and a cooperation control unit (40) configured to enable cooperation between the two. The aforementioned control system function block is: The system includes a functional interface (37) configured to convert access requests, which are expressed in a vehicle-independent format and transmitted from the service application, into a vehicle-dependent format. The aforementioned cooperation control unit is configured to forward the access request transmitted from the service application to the control system function block. The cooperation control unit determines whether a pre-configured suspension condition has been met, which indicates that it is necessary to suspend the use of the functional interface due to factors related to charges incurred by using at least one of the service application and the functional interface. A service provision method in which the linked control unit switches the operation of the vehicle control system based on functional interface information relating to the functional interface for which the usage suspension condition has been met, vehicle status information indicating the status of the vehicle, and user input information entered by a user of the vehicle.

11. The computer of the on-board device (4), which is mounted in the vehicle, connected to a plurality of electronic control devices (5-7) via an on-board network (8), and which together with the plurality of said electronic control devices constitutes a vehicle control system (2), A functional interface (37) configured to convert access requests sent from a service application (SA1) configured to provide services to the vehicle, which are expressed in a vehicle-independent format, into a vehicle-dependent format. A cooperation control unit (40) is configured to enable cooperation between the service application and a control system function block (35) configured to control the vehicle with the function interface, and is configured to forward the access request transmitted from the service application to the control system function block. A usage suspension determination unit (S30) is configured to determine whether a pre-set usage suspension condition has been met, which indicates that it is necessary to suspend the use of the functional interface due to factors related to charges incurred by using at least one of the service application and the functional interface, A usage control unit (S40-S70, S100-S120) is configured to switch the operation of the vehicle control system based on the function interface information relating to the function interface for which the usage suspension conditions have been met, vehicle status information indicating the status of the vehicle, and user input information entered by the user using the vehicle. A service provision program designed to function as such.

Images