Vehicle-mounted device, service providing method, and service providing program
The in-vehicle device addresses the issue of billing-related service disruptions by managing usage suspension within the vehicle control system, ensuring that service usage is stopped only when necessary, thus enhancing user convenience.
Patent Information
- Application Number
- PCT/JP2024/020896
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-06-14
- Filing Date
- 2024-06-07
- Publication Date
- 2024-12-19
AI Technical Summary
The convenience of users who utilize services provided by service providers is impaired when billing-related issues, such as exceeding usage fees, lead to uniform stopping of service usage, disrupting the service experience.
An in-vehicle device connected to multiple electronic control units via an in-vehicle network, which forms a vehicle control system, includes a cooperation control unit that determines and manages usage suspension conditions, converting access requests and controlling vehicle operations based on functional interface information, vehicle status, and user input to uniformly stop service usage when necessary due to billing factors.
This solution enhances user convenience by preventing service disruptions due to billing-related issues, ensuring that service usage is uniformly stopped only when necessary, thereby improving the overall user experience.
Smart Images

Figure JP2024020896_19122024_PF_FP_ABST
Abstract
Description
In-vehicle device, service providing method, and service providing program 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.
[0002] The present disclosure relates to an in-vehicle device that provides a service to a vehicle, a service providing method, and a service providing program.
[0003] Patent document 1 describes a vehicle that includes a control unit that operates the vehicle based on operation information received from a management server, a management unit that manages the compartments in the vehicle where service users receive services from service providers, and an interface unit that is set in correspondence with the service-related information and compartments provided by the service provider.
[0004] Japanese Patent Application Laid-Open No. 2020-98610
[0005] As described in Patent Document 1, when a service provider provides a service to a vehicle, it may be necessary to obtain vehicle information about the vehicle from the target vehicle to which the service is being provided, or to have the target vehicle perform a specified operation or process.
[0006] In this way, when a service provider uses a vehicle by obtaining vehicle information from the vehicle or causing the vehicle to perform a specified operation or process, it is desirable to charge the service provider for this use.
[0007] As a result of detailed consideration by the inventors, it was found that if the above-mentioned use by the service provider needs to be stopped due to billing factors (for example, the usage fee exceeds the upper limit), if the above-mentioned use is stopped uniformly, the convenience of users who use the services provided by the service provider may be impaired.
[0008] The present disclosure improves convenience for users who use services.
[0009] One aspect of the present disclosure is an in-vehicle device that is mounted on a vehicle, connected to a plurality of electronic control devices via an in-vehicle network, and that configures a vehicle control system together with the plurality of electronic control devices.
[0010] The in-vehicle device of the present disclosure includes a cooperation control unit configured to realize cooperation between a service application configured to provide a service to a vehicle and a control system functional block configured to control the vehicle. The control system functional block includes a functional interface configured to convert an access request expressed in a vehicle-independent format and transmitted from the service application into a vehicle-dependent format. The cooperation control unit is configured to transfer the access request transmitted from the service application to the control system functional block.
[0011] The cooperation control unit includes a usage suspension determination unit and a usage control unit.
[0012] The usage suspension determination unit is configured to determine whether a preset usage suspension condition indicating that usage of the functional interface needs to be suspended due to factors related to charges incurred by using at least one of the service application and the functional interface has been established.
[0013] The usage control unit is configured to switch the operation of the vehicle control system based on functional interface information regarding the functional interface for which the usage suspension condition is met, vehicle status information indicating the status of the vehicle, and user input information input by the user using the vehicle.
[0014] The in-vehicle device of the present disclosure configured as above switches the operation of the vehicle control system based on the functional interface information and the user-input vehicle status information. As a result, when it is necessary to stop the use of the functional interfaces due to billing reasons, the in-vehicle device of the present disclosure can prevent the occurrence of a situation in which the use of the functional interfaces is uniformly stopped, preventing the user from using the service, thereby improving convenience for the user who uses the service.
[0015] Another aspect of the present disclosure is a service providing method executed by an in-vehicle device that is mounted on a vehicle, connected to a plurality of electronic control devices via an in-vehicle network, and that configures a vehicle control system together with the plurality of electronic control devices.
[0016] The in-vehicle device includes a cooperation control unit configured to realize cooperation between a service application and a control system functional block. The control system functional block includes a function interface. The cooperation control unit is configured to transfer an access request transmitted from the service application to the control system functional block.
[0017] In the service providing method of the present disclosure, the cooperation control unit determines whether a predetermined use suspension condition indicating that use of the functional interface needs to be suspended due to a factor related to charges incurred by using at least one of the service application and the functional interface is satisfied, and switches the operation of the vehicle control system based on functional interface information related to the functional interface for which the use suspension condition is satisfied, vehicle status information indicating the status of the vehicle, and user input information input by a user using the vehicle.
[0018] The service providing method of the present disclosure is a method executed by the in-vehicle device of the present disclosure, and by executing this method, it is possible to obtain the same effects as the in-vehicle device of the present disclosure.
[0019] Yet another aspect of the present disclosure is a service provision program that causes a computer of an on-board device that is mounted on a vehicle, connected to multiple electronic control devices via an on-board network, and that, together with the multiple electronic control devices, forms a vehicle control system to function as a functional interface, a coordination control unit, a usage suspension determination unit, and a usage control unit.
[0020] A computer controlled by the service providing program of the present disclosure can constitute 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.
[0021] 1 is a block diagram showing the configuration of a service providing system; FIG. 2 is a block diagram showing the configuration of an ECU; FIG. 3 is a block diagram showing a billing procedure; FIG. 4 is a diagram showing an API contract procedure; FIG. 5 is a block diagram showing a destination of a first API usage suspension request; FIG. 6 is a block diagram showing a destination of a second API usage suspension request; FIG. 7 is a flowchart showing the first half of an API usage control process; FIG. 8 is a flowchart showing the second half of an API usage control process;
[0022] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings.
[0023] As shown in FIG. 1, the service providing system 1 of this embodiment includes a vehicle control system 2 and a server 3.
[0024] The vehicle control system 2 is mounted on a vehicle and has a function of performing data communication with a server 3 via a wide area wireless communication network NW.
[0025] The server 3 has a function of performing data communication with the vehicle control system 2 via the wide area wireless communication network NW. The server 3 is provided with 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 a driving source. The vehicle is not limited to a vehicle having an automatic driving function or a hybrid vehicle, but may be a vehicle equipped with only a manual driving function, or a vehicle having only an engine or only an electric motor as a driving source. Hereinafter, a vehicle equipped with the vehicle control system 2 will be simply referred to as a vehicle.
[0027] The vehicle control system 2 includes one ECU 4, a plurality of ECUs 5, a plurality of ECUs 6, an external communication device 7, and an internal communication network 8. ECU is an abbreviation for Electronic Control Unit.
[0028] The ECU 4 controls a plurality of ECUs 5 to realize coordinated control of the entire vehicle.
[0029] An ECU 5 is provided for each domain, which is divided according to the vehicle's functions, and mainly controls the multiple ECUs 6 present within that domain. Each ECU 5 is connected to its subordinate ECUs 6 via a lower-level network (e.g., CAN) that is individually provided for each ECU 5. CAN stands for Controller Area Network. CAN is a registered trademark. Examples of domains include the powertrain, body, chassis, and cockpit.
[0030] The ECUs 6 connected to the ECU 5 belonging to the powertrain domain include, for example, an ECU 6 that controls the engine, an ECU 6 that controls the motor, and an ECU 6 that controls the battery.
[0031] The ECUs 6 connected to the ECU 5 belonging to the body domain include, for example, an ECU 6 that controls an air conditioner, an ECU 6 that controls doors, and the like.
[0032] The ECUs 6 connected to the ECU 5 belonging to the chassis domain include, for example, an ECU 6 that controls the brakes, an ECU 6 that controls the steering, and the like.
[0033] The ECUs 6 connected to the ECU 5 belonging to the cockpit domain include, for example, an ECU 6 that controls the meters and the display of the navigation device 100, and an ECU 6 that controls input devices operated by the vehicle occupants.
[0034] The external vehicle communication device 7 performs data communication with the server 3 via the 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. The CAN FD connects the ECU 4 to each ECU 5 and the external-vehicle communication device 7 via a bus. The Ethernet individually connects the ECU 4 to each ECU 5 and the external-vehicle communication device 7.
[0036] The ECU 4 is an electronic control device mainly composed of a microcomputer including a CPU 4a, a ROM 4b, a RAM 4c, etc. Various functions of the microcomputer are realized by the CPU 4a executing a program stored in a non-transitory tangible recording medium. In this example, the ROM 4b corresponds to the non-transitory tangible recording medium storing the program. Furthermore, the execution of this program executes a method corresponding to the program. Note that some or all of the functions executed by the CPU 4a may be configured as hardware using one or more ICs, etc. Furthermore, the number of microcomputers constituting the ECU 4 may be one or more.
[0037] The ECU 4 further includes a flash ROM 4d, which is a non-volatile memory whose stored contents are rewritable.
[0038] Like the ECU 4, the ECUs 5, 6, and exterior communication device 7 are all electronic control devices mainly configured with a microcomputer including a CPU, ROM, RAM, etc. The number of microcomputers configuring the ECUs 5, 6, and exterior communication device 7 may be one or more. The ECU 5 controls one or more ECUs 6. The ECU 4 controls one or more ECUs 5, 6, or controls the ECUs 5, 6 and exterior communication device 7 of the entire vehicle.
[0039] In the following description, the ECU 4, ECU 5, ECU 6 and the external communication device 7 will be referred to as the in-vehicle devices 4 to 7 unless otherwise specified.
[0040] The server 3 includes a control unit 11 , a communication unit 12 , and a storage unit 13 .
[0041] The control unit 11 is an electronic control device mainly composed of a microcomputer including a CPU 11a, a ROM 11b, a RAM 11c, etc. Various functions of the microcomputer are realized by the CPU 11a executing a program stored in a non-transitory tangible recording medium. In this example, the ROM 11b corresponds to the non-transitory tangible recording medium storing the program. Furthermore, the execution of this program results in the execution of a method corresponding to the program. Note that some or all of the functions executed by the CPU 11a may be configured as hardware using one or more ICs, etc. Furthermore, the number of microcomputers constituting the control unit 11 may be one or more.
[0042] The communication unit 12 performs data communication with the vehicle control system 2 via the wide area wireless communication network NW. The storage unit 13 is a storage device for storing various data.
[0043] The service providing system 1 further includes a servicer terminal device 9. The servicer terminal device 9 is a device managed by a service provider SV (hereinafter referred to as servicer SV) described later, and is, for example, a personal computer.
[0044] The servicer terminal device 9 includes 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 device mainly composed of a microcomputer including a CPU, a ROM, a RAM, and the like.
[0046] The communication unit 16 communicates data with the vehicle control system 2 and the server 3 via the wide area wireless communication network NW. The memory unit 17 is a storage device for storing various data. The display unit 18 is equipped with 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 for identifying input operations performed by the user via a keyboard and mouse (not shown).
[0047] The service providing system 1 further includes a mobile terminal device 10. The mobile terminal device 10 is an information processing terminal (e.g., a smartphone or a tablet) carried by a vehicle driver (i.e., a user US, described later). The mobile terminal device 10 has a function of performing data communication with the vehicle control system 2 via a wide-area wireless communication network NW.
[0048] 2, the ECU 4 includes a real-time processing unit 20 and an application processing unit 30 (hereinafter referred to as the application processing unit 30). When the ECU 4 includes multiple CPUs 4a, the real-time processing unit 20 and the application processing unit 30 may be realized by processes executed by the same CPU, or may be realized by processes executed by different CPUs.
[0049] The real-time processing unit 20 cooperates with the in-vehicle devices 5 to 7 connected via the CAN FD to execute vehicle control and other tasks that require real-time performance. The application processing unit 30 cooperates with the in-vehicle devices 5 to 7 connected via Ethernet to execute various applications (e.g., entertainment applications) that require high processing power.
[0050] The application processing unit 30 has a function of transmitting instructions based on the processing of various applications to the real-time processing unit 20. The real-time processing unit 20 has a function of transmitting information collected from the ECU or the like via the 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 of 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 not only provides communication between software components (hereinafter referred to as SW-C) implemented to realize various applications, but also functions related to cloud connection and security. SW-C is modularized software to realize a certain function. An application program includes one or more SW-Cs. Note that the software of the vehicle control system 2 does not necessarily have to be built in accordance with AUTOSAR.
[0052] Each of the devices belonging to the vehicle control system 2, i.e., the ECU 4, ECU 5, ECU 6, and the external-vehicle communication device 7, has a platform. The platform provides an environment for executing SW-C written in a hardware-independent format.
[0053] The platform comprises a runtime environment (hereinafter referred to as RTE) and platform software (hereinafter referred to as BSW). RTE is an interface that connects SW-Cs with each other and between SW-Cs and BSW. BSW is a layer that connects hardware and SW-Cs, and includes the OS, drivers, middleware, etc. The functions of BSW are divided into small modules, and the functions of each module are provided to SW-Cs via APIs. API stands for Application Programming Interface.
[0054] Hereinafter, the platform provided in the real-time processing unit 20 will be referred to as a first platform 21 (hereinafter referred to as a first PF 21), and the platform provided in the application processing unit 30 will be referred to as a second platform 31 (hereinafter referred to as a second PF 31).
[0055] The real-time processing unit 20 includes a control system functional block group 22 as a collection of service applications (hereinafter, referred to as service apps) that run on the first PF 21. A service app is an application that receives a request from a client, processes it, and returns the result.
[0056] The control system functional block group 22 is a group of applications that have an API that receives commands related to vehicle movement and that integrates the commands received by the API to achieve consistent vehicle control. The control system functional block group 22 outputs various commands via the in-vehicle communication network 8 to the in-vehicle devices 5 to 7 that execute the control based on the commands.
[0057] The first PF 21 includes a conversion gateway 211. The conversion gateway 211 has a function of converting a communication frame received by the real-time processing unit 20 via CAN FD into an Ethernet format and providing the frame to the application processing unit 30. The conversion gateway 211 also has a function of converting a communication frame in Ethernet format provided from the application processing unit 30 into a CAN FD format.
[0058] The application processing unit 30 includes a hypervisor 32 and executes software on a plurality of virtual machines. Note that the hypervisor 32 may be omitted.
[0059] The application processing unit 30 includes a service function block group 33 as a group of service applications that run on the second PF 31 .
[0060] The service function block group 33 is a collection of service applications. Each service application includes one or more SW-Cs. Service applications may be provided not only by the vehicle manufacturer that produced the vehicle, but also by third parties. Examples of third parties that provide service applications include data utilization companies that provide services by collecting data from vehicles.
[0061] The second PF 31 includes a control system function block group 35 , a data system function block group 36 , and an API gateway 40 .
[0062] The control system functional block group 35 is a set of programs equipped with an API for receiving requests related to vehicle control from the service system functional block group 33. The control system functional block group 35 includes an API group 37 made up of multiple APIs, and converts API access requests from the service system functional 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-mentioned "vehicle-independent format" is a format common to vehicles (i.e., a format that absorbs differences between vehicle models). The above-mentioned "vehicle-dependent format" is a format specific to the vehicle.
[0063] The APIs included in the control system functional block group 35 include motion system APIs that control the motion of the vehicle and other non-motion system APIs. An API access request accepted by a motion system API is transferred to the control system functional block group 35, and then transferred from the control system functional block group 35 to the in-vehicle devices 5 to 7 that execute control based on the request via the in-vehicle communication network 8. An API access request accepted by a non-motion system API is transferred via the in-vehicle communication network 8 to the in-vehicle devices 5 to 7 that execute control based on the request.
[0064] The data-related functional block group 36 is a set of programs equipped with an API for handling vehicle data acquired and stored via the real-time processing unit 20. The data-related functional block group 36 has a function of abstracting vehicle data expressed in a vehicle-dependent format and supplied from the real-time processing unit 20 into a vehicle-independent format and storing the abstracted data. The data-related functional block group 36 may have an API that provides a function for transmitting specified vehicle data to an ECU or the like via Ethernet. In particular, when the destination is the exterior communication device 7, the exterior communication device 7 may upload the transmitted vehicle data to the cloud.
[0065] Note that communication with the other on-board devices 5 to 7 via the control system function block group 35 is not limited to CAN FD, but may use Ethernet or other communication means. Also, communication with the other on-board devices 5 to 7 via the data system function block group 36 is not 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). VFB is middleware, also called a software bus, that enables communication between SW-Cs and between SW-Cs and BSWs without regard to hardware, communication protocols, etc. Communication between SW-Cs refers to access from an SW-C to an API provided by another SW-C, and communication between SW-Cs and BSW refers to access from an SW-C to an API provided by the control system function block group 35 and the data system function block group 36.
[0067] That is, the SW-C accesses various APIs via the API gateway 40 and uses the functions provided by the accessed APIs to achieve the desired functions.
[0068] When using an API, the SW-C sends an API access request. The API access request includes at least the application ID of the service application including the SW-C that is the request source, and an API-ID that is information indicating the API that is the request destination.
[0069] 3 , the server 3 is provided with an app store 14. As indicated by arrow L1, the app store 14 has a function of registering a first service app SA1 created by the servicer SV in the app store 14 based on an application from the servicer SV that accesses the app store 14 using the servicer terminal device 9. The first service app SA1 registered in the app store 14 is published on the website of the app store 14.
[0070] Furthermore, as indicated by an arrow L2, the application store 14 has a function of registering the API used by the first service application SA1 in the application store 14 based on a request from the servicer SV.
[0071] When the user US accesses the website of the app store 14 and purchases the first service app SA1, the first service app SA1 is installed in the ECU 4 mounted in the vehicle of the user US, as shown by the arrow L3.
[0072] As indicated by arrow L4, when the first service application SA1 transmits an API access request to the API gateway 40, the API gateway 40 transfers the API access request to the control system functional block group 35 as indicated by arrow L5. As described above, the control system functional block group 35 converts the API access request into an API access request expressed in a vehicle-dependent format and provides the API access request to the real-time processing unit 20.
[0073] As indicated by arrow L6, the API gateway 40 transmits to the app store 14 a statistical access log including the number of API usages taking into account the execution success status of API access requests and the amount of communication data associated with the API usage.
[0074] The app store 14 calculates the API usage fee incurred when the first service app SA1 uses the API based on the statistical access log received from the API gateway 40, and bills the servicer SV for the API usage fee. The servicer SV pays the billed API usage fee to the app store 14, as indicated by arrow L7.
[0075] The app store 14 calculates an app usage fee for the first service app SA1 based on the usage status of the first service app SA1 and bills the user US for the app usage fee. The user US pays the billed app usage fee to the app store 14, as shown by arrow L8. The app store 14 transfers the app usage fee paid by the user US to the servicer SV, as shown by arrow L9.
[0076] As shown by arrow L10, when the first service app SA1 sends an API access request to the API gateway 40, the API gateway 40 may forward the API access request to a second service app SA2 that provides a service different from that of the first service app SA1.
[0077] Next, the procedure when the servicer SV makes an API usage contract will be described.
[0078] As shown in process P1 of FIG. 4, the servicer SV accesses the app store 14 and applies for registration of the service app to be posted and the API to be used.
[0079] As shown in process P2, the application store 14 examines whether the service application requested by the servicer SV is accessible to the control system functional block group 35 or not.
[0080] If the requested service application can access the control function block group 35, the application store 14 presents the usage API billing form to the servicer SV as shown in process P3.
[0081] As shown in table TB1, the application store 14 stores API policy information in the storage unit 13, which includes the API-ID, reliability, and billing form for each requested API.
[0082] In table TB1, the reliability of the API with API-ID API1 is "high" and the billing type is "pay per call," while the reliability of the API with API-ID API2 is "low" and the billing type is "monthly."
[0083] An API whose reliability is set to "high" accepts API access requests from service apps whose reliability is high, and rejects API access requests from service apps whose reliability is low.
[0084] An API whose reliability is set to "low" accepts an API access request even from a service application with low reliability.
[0085] "Pay-per-call" is a billing format in which a fee is charged according to the number of API access requests. "Monthly" is a billing format in which a fixed fee is charged monthly, regardless of the number of API access requests.
[0086] As shown in process P4, the servicer SV notifies the app store 14 that it agrees to the contract for the proposed usage API billing format. As a result, as shown in process P5, the app store 14 lists the service app applied for by the servicer SV on its website.
[0087] The app store 14 stores information about the service app posted on the website (hereinafter referred to as posted app information) and information about the API authorized for the service app posted on the website (hereinafter referred to as API authorization information) in the storage unit 13.
[0088] As shown in Table TB2, the listed app information includes, for each listed service app, an app ID, a function name of the service app, a billing method for the service app, and a servicer ID. The app ID is information for identifying the service app. The servicer ID is information for identifying the provider of the service app.
[0089] In table TB2, the function name of the service app with the app ID APP1 is "Comfortable Air Conditioning," the billing type is "Usage Time," and the servicer ID is "Dev1." The function name of the service app with the app ID APP2 is "Road Service," the billing type is "Monthly," and the servicer ID is "Dev1."
[0090] The "usage time" billing format is a billing format in which a fee is charged according to the usage time of the service app. The "monthly" billing format is a billing format in which a fixed fee that is not dependent on the usage time of the service app is charged monthly.
[0091] As shown in table TB3, the API authorization information includes an API-ID and an application ID for each API that is authorized for use.
[0092] Table TB3 shows that an API with an API-ID of API1 is called by a service application with an application ID of APP1, and an API with an API-ID of API2 is called by a service application with an application ID of APP2.
[0093] Next, a manner in which API usage is suspended due to a factor related to billing will be described.
[0094] 5, the API gateway 40 determines whether the contract for API usage has expired. If it determines that the contract for API usage has expired, the API gateway 40 transmits a first API usage stop request, as indicated by arrows L11, L12, and L13, to the control system functional block group 35, the first service application SA1, and the second service application SA2, indicating that usage of the API whose contract has expired is to be stopped. An API-ID identifying the API whose usage is being requested to be stopped is added to the first API usage stop request.
[0095] 6 , the app store 14 determines whether the user US is in arrears with the usage fee for the first service app SA1 and whether the servicer SV is in arrears with the usage fee for the API. If the app store 14 determines that the user US is in arrears with the usage fee for the first service app SA1 or if the servicer SV determines that the API usage fee is in arrears, the app store 14 transmits a second API usage suspension request to the first service app SA1, as indicated by arrow L21, indicating that usage of the API will be suspended due to the arrears. The second API usage suspension request includes an API-ID that identifies the API for which suspension is requested.
[0096] Upon receiving the second API usage stop request, the first service application SA1 transmits the second API usage stop request to the API gateway 40, as indicated by arrow L22.
[0097] When the API gateway 40 receives the second API usage stop request, it transmits the second API usage stop request to the control system functional block group 35 and the second service application SA2, as indicated by arrows L23 and L24.
[0098] The API gateway 40 also determines whether the usage fee for the first service app SA1 by the user US exceeds the upper charge limit set by the user US. Furthermore, the API gateway 40 determines whether the usage fee for the API by the first service app SA1 exceeds the upper charge limit set by the servicer SV.
[0099] If it is determined that the usage fee for the first service app SA1 has exceeded the upper charge limit, or if it is determined that the usage fee for the API has exceeded the upper charge limit, the API gateway 40 transmits a third API usage suspension request indicating that usage of the API will be suspended because the upper charge limit has been exceeded to the control system functional block group 35, the first service app SA1, and the second service app SA2. The third API usage suspension request includes an API-ID that identifies the API for which suspension is 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 transmits a fourth API usage stop request indicating that the usage of the API for which there are insufficient resources should be stopped to the control system functional block group 35, the first service application SA1, and the second service application SA2. The fourth API usage stop request is accompanied by an API-ID that identifies the API for which the usage stop is requested.
[0101] Next, a description will be given of the procedure of the API usage control process executed by the API gateway 40. The API usage control process is a process that is repeatedly executed while the ECU 4 is in operation.
[0102] When the API usage control process is executed, the API gateway 40 (hereinafter, APIGW 40) determines whether or not there is a prediction of an API usage suspension in S10, as shown in FIG.
[0103] Specifically, the APIGW 40 determines that an API usage suspension is predicted when API usage suspension prediction information is received from the app store 14. The API usage suspension prediction information includes a list of service apps that will become unusable due to the API usage suspension, the reason for the API usage suspension, the timing of the API usage suspension (e.g., "API will be suspended in X minutes"), points to note due to the API usage suspension, and the status of additional charges.
[0104] Furthermore, APIGW40 determines that an API usage suspension is predicted when the contract for API usage expires, when the usage fee for a service app exceeds the upper charge limit, when the usage fee for an API exceeds the upper charge limit, or when there is a shortage of resources to execute processing corresponding to the API. APIGW40 transmits the above-mentioned first, third, and fourth API usage suspension requests after a preset waiting time has elapsed since determining that an API usage suspension is predicted.
[0105] If there is no prediction of API usage suspension, the APIGW 40 waits until there is a prediction of API usage suspension by repeating the process of S10. If there is a prediction of API usage suspension, the APIGW 40 notifies the user US and the servicer SV in S20 that the service apps will be suspended. In addition to suspending the service apps, the APIGW 40 notifies the user US and the servicer SV of a list of service apps that will become unusable due to the suspension of API usage, the reason for suspending API usage, the timing of suspending API usage, points to note due to the suspension of API usage, and the status of additional charges.
[0106] Specifically, when there is an occupant in the vehicle, the APIGW 40 notifies the user US that the service app will be stopped, for example, by displaying a message on the display screen of the navigation device 100. The APIGW 40 determines whether there is an occupant in the vehicle by detecting whether there is an occupant seated in each of the multiple seats installed in the vehicle cabin based on the detection results of multiple seating sensors installed in the seats of the multiple seats in the vehicle cabin.
[0107] When there is no occupant in the vehicle, the APIGW 40 notifies the mobile terminal device 10 of the user US that the service app will be stopped. Note that the telephone number or email address of the mobile terminal device 10 of the user US is registered in advance in the ECU 4.
[0108] The APIGW 40 notifies the servicer terminal device 9 of the servicer SV that the service application will be stopped.
[0109] In S30, the APIGW 40 determines whether it is time to stop API usage. Specifically, the APIGW 40 determines that it is time to stop API usage when the second API usage stop request described above is received from the app store 14. The APIGW 40 also determines that it is time to stop API usage when it is time to send the first, third, and fourth API usage stop requests described above.
[0110] If it is not time to stop API usage, the APIGW 40 repeats the process of S30 to wait until it is time to stop API usage. When it is time to stop API usage, the APIGW 40 determines in S40 whether or not it may be better to not permit API usage suspension for the API for which suspension is requested (hereinafter, the API to be stopped). Specifically, the APIGW 40 determines whether or not it may be better to not permit API usage suspension for the API to be stopped by referring to a disallowance setting table in which API disallowance information indicating the possibility of disallowance for each of a plurality of APIs is preset. The disallowance setting table is stored in the flash ROM 4d.
[0111] Examples of APIs for which it may be better not to allow API usage suspension include information gathering APIs, APIs for improving the interior space of a vehicle, and entertainment APIs.
[0112] Examples of APIs for which it may be better not to allow API usage suspension include APIs directly related to driving operations, automated driving system APIs, and advanced driving assistance system APIs.
[0113] Here, if there is no case where it is better not to permit API usage suspension for the API to be stopped, the APIGW 40 proceeds to S120. On the other hand, if there is a case where it is better not to permit API usage suspension, the APIGW 40 determines in S50 whether the vehicle is traveling. Specifically, the APIGW 40 determines that the vehicle is traveling when the traveling speed of the vehicle is equal to or greater than a preset traveling determination speed (e.g., 3 km / h).
[0114] If the vehicle is traveling, the APIGW 40 proceeds to S70. On the other hand, if the vehicle is not traveling, the APIGW 40 determines in S60 whether the vehicle is stopped. Specifically, the APIGW 40 determines that the vehicle is stopped if the traveling speed of the vehicle is less than a preset stopping determination speed (e.g., 3 km / h) and the shift position is in drive or neutral.
[0115] If the vehicle is stopped, the APIGW 40 proceeds to S90. On the other hand, if the vehicle is not stopped, the APIGW 40 determines that the vehicle is parked, and proceeds to S110.
[0116] When the process proceeds to S70, as shown in FIG. 8, the APIGW 40 prohibits the suspension of API usage for the API to be stopped. This results in an additional charge due to continued API usage. The additional charge due to continued API usage is calculated separately from the normal charge. The charge amount may be borne by either the user US or the servicer SV. For example, any excess amount due to the user US's responsibility may be borne by the user, while any excess amount that is unavoidable due to safety considerations may be borne by the servicer.
[0117] In S80, the APIGW 40 notifies the user US and the servicer SV that API usage suspension for the API to be stopped is prohibited, and ends the API usage control process. Specifically, when there is an occupant in the vehicle, the APIGW 40 notifies the user US that API usage suspension for the API to be stopped is prohibited, for example, by displaying this on the display screen of the navigation device 100. When there is no occupant in the vehicle, the APIGW 40 notifies the mobile terminal device 10 of the user US that API usage suspension for the API to be stopped is prohibited. The APIGW 40 notifies the servicer terminal device 9 of the servicer SV that API usage suspension for the API to be stopped is prohibited.
[0118] When the process proceeds to S90, the APIGW 40 notifies the user US and the servicer SV that the service application will be stopped, in the same manner as in S20.
[0119] In S100, the APIGW 40 determines whether the user US has permitted API usage suspension based on an input operation by the user US via the input device mounted on the vehicle. Specifically, if the user input information output by the input device in response to the user US's input operation via the input device indicates permission to suspend API usage, the APIGW 40 determines that the user US has permitted API usage suspension. Furthermore, if the user input information indicates a denial of API usage suspension, the APIGW 40 determines that the user US has not permitted API usage suspension. Furthermore, if the input device does not output user input information even after a preset waiting time has elapsed, the APIGW 40 determines that the user US has not permitted API usage suspension.
[0120] If the user US does not permit the API usage to be stopped, the APIGW 40 terminates the API usage control process. As a result, an additional charge for continuing the API usage will be incurred. The additional charge for continuing the API usage will be calculated separately from the normal charge.
[0121] When the process proceeds to S110, the APIGW 40 determines whether or not a vehicle user is in the vehicle. Specifically, the APIGW 40 determines that a vehicle user is in the vehicle when there is one or more seats occupied by an occupant based on the detection results of the multiple seating sensors.
[0122] If the vehicle user is in the vehicle, the APIGW 40 proceeds to S90. On the other hand, if the vehicle user is not in the vehicle, the APIGW 40 stops the API use of the API to be stopped in S120.
[0123] In S130, the APIGW 40 notifies the user US and the servicer SV that the service application will be stopped, in the same manner as in S20, and ends the API usage control process.
[0124] The ECU 4 configured as above is mounted on a vehicle and connected to a plurality of on-board devices 5 to 7 via an in-vehicle communication network 8 , and together with the plurality of on-board devices 5 to 7 constitutes a vehicle control system 2 .
[0125] The ECU 4 includes an API gateway 40. The API gateway 40 is configured to realize cooperation between a first service app SA1 configured to provide a service to the vehicle and a control system functional block group 35 configured to control the vehicle. The control system functional block group 35 includes an API group 37. The API group 37 is configured to convert an API access request expressed in a vehicle-independent format and transmitted from the first service app SA1 into a vehicle-dependent format. The API gateway 40 is configured to transfer the API access request transmitted from the first service app SA1 to the control system functional block group 35.
[0126] The API gateway 40 is configured to determine whether a predetermined usage suspension condition has been met, which indicates that usage of the API group 37 needs to be suspended due to factors related to charges incurred by using at least one of the first service application SA1 and the API group 37.
[0127] The API gateway 40 is configured to switch the operation of the vehicle control system 2 based on the API denial information of the API for which the usage suspension condition is met, vehicle status information indicating the vehicle status, and user input information entered by the user US who uses the vehicle. Note that although the control system function block group 35 and the data system function block group 36 are equipped with APIs, switching the operation of the vehicle control system 2 based on the API denial information or the like applies to the control system function block group 35, but not to the data system function block group 36.
[0128] The ECU 4 switches the operation of the vehicle control system 2 based on the API denial information, the vehicle state information, and the user input information. This prevents the ECU 4 from uniformly suspending API usage when it is necessary to suspend API usage due to billing-related factors, thereby preventing the user US from being able to use the service. This improves the convenience of the user US who uses the service.
[0129] The vehicle state information includes driving state information indicating the driving state of the vehicle and occupant presence information indicating the presence or absence of an occupant in the vehicle. The API gateway 40 is configured to switch the operation of the vehicle control system 2 by determining whether to prohibit or permit suspension of API use based on the API non-permission information, the vehicle state information, and the user input information. This allows the ECU 4 to determine whether to prohibit or permit suspension of API use based on at least whether the vehicle is driving and whether an occupant is present in the vehicle.
[0130] The API gateway 40 is configured to determine, based on the API disapproval information, that an API is one for which suspension of use may not be permitted, and to prohibit suspension of use of the API when it determines, based on the driving state information, that the vehicle is driving. This allows the ECU 4 to prevent a situation in which a necessary service becomes unavailable while the vehicle is driving, thereby further improving convenience for the user US who uses the service.
[0131] The API gateway 40 is configured to permit API suspension when it determines, based on the API disapproval information, that an API is one for which suspension may not be permitted, determines, based on the driving state information, that the vehicle is stopped, and determines, based on the user input information, that the user US has permitted API suspension. This allows the ECU 4 to suspend API usage when the user US has permitted API suspension while the vehicle is stopped. In other words, when the user US determines that API usage is unnecessary, API usage is suspended. Therefore, even when API usage is suspended, the ECU 4 can prevent the user US from being unable to use a service that is necessary for the user US, thereby further improving the convenience of the user US who uses the service.
[0132] The API gateway 40 is configured to permit suspension of use of a functional interface when it determines, based on the API disapproval information, that an API is one for which suspension may not be permitted, based on the driving state information, determines that the vehicle is parked, based on the occupant presence / absence information, determines that an occupant is present in the vehicle, and based on the user input information, determines that the user US has permitted suspension of use of the API. This allows the ECU 4 to suspend use of the API when the user US permits suspension of use of the API while the vehicle is parked. In other words, when the user US determines that use of the API is not necessary, use of the API is suspended. Therefore, even when API use is suspended, the ECU 4 can prevent the user US from being unable to use a service that is necessary for the user US, thereby further improving convenience for the user US who uses the service.
[0133] The API gateway 40 is configured to permit suspension of use of a functional interface when it determines, based on the API disapproval information, that an API is one for which suspension may not be permitted, determines, based on the driving state information, that the vehicle is parked, and determines, based on the occupant presence information, that no occupants are present in the vehicle. This allows the ECU 4 to suspend use of the API when no occupants are present in the vehicle while the vehicle is parked. In other words, when a user US using a service is not present in the vehicle, API use is suspended. Therefore, even when API use is suspended, the ECU 4 can prevent a situation in which the user US is unable to use a service necessary for the user US, thereby further improving the convenience of the user US using the service.
[0134] The API gateway 40 is configured to permit suspension of an API if it determines, based on the API disapproval information, that there is a possibility that suspension of the API is not appropriate. That is, APIs whose suspension will not cause any problems for the user US are uniformly suspended due to billing-related factors. In this way, the ECU 4 suspends the use of APIs whose suspension will not cause any problems for the user US. Therefore, even if the API usage is suspended, it is possible to prevent the user US from being unable to use a necessary service, thereby further improving the convenience of the user US who uses the service.
[0135] The API gateway 40 is also configured to determine whether a preset usage suspension prediction condition indicating that usage of the API may be suspended is satisfied. If the API gateway 40 determines that the usage suspension prediction condition is satisfied, the API gateway 40 is configured to notify the user US that usage of the first service app SA1 that uses this API will be suspended. This allows the ECU 4 to make the user US aware that usage of the first service app SA1 may become unavailable.
[0136] Furthermore, the API gateway 40 is configured to notify the user US using the navigation device 100 installed in the vehicle when an occupant is present in the vehicle, and to notify the user US using the mobile terminal device 10 pre-registered for the user US when no occupant is present in the vehicle. This makes it possible to prevent the ECU 4 from being unable to notify the user US that use of the first service app SA1 will be stopped.
[0137] In the embodiment described above, the ECU 4 corresponds to an in-vehicle device, the ECUs 5 and 6 and the external communication device 7 correspond to a plurality of electronic control devices, and the in-vehicle communication network 8 corresponds to an in-vehicle network.
[0138] The first service application SA1 corresponds to a service application, the control function block group 35 corresponds to a control 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 determination unit, the determination condition of S30 corresponds to a usage suspension condition, S40 to S70 and S100 to S120 correspond to processing as a usage control unit, and API denial information corresponds to functional interface information.
[0140] Furthermore, S10 corresponds to processing as a prediction judgment unit, the judgment conditions of S10 correspond to the suspension of use 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 modifications.
[0142] [Modification 1] In the above embodiment, a form was shown in which it was determined whether or not it would be better not to permit API usage suspension based on API denial information indicating the presence or absence of denial possibility. However, it may also be determined whether or not it would be better not to permit API usage suspension based on the level of denial possibility (e.g., 0, 1, 2, 3, ...) instead of the presence or absence of denial possibility.
[0143] [Modification 2] In the above embodiment, the API usage is prohibited when the vehicle is traveling. However, API usage may be allowed to continue by prohibiting API usage, and API usage may be stopped when it is safe to stop it. Furthermore, if the vehicle has an autonomous driving function, the vehicle may automatically transition to evacuation driving and stop API usage.
[0144] [Modification 3] In the above embodiment, as shown in Fig. 7, the process of S110 is executed. However, the process of S110 may not be executed. That is, if the vehicle is not stopped in S60, the APIGW 40 may proceed to S120. This allows the ECU 4 to stop using the API as soon as possible.
[0145] [Variation 4] In the above embodiment, a form was shown in which it was determined whether the vehicle was moving, stopped, or parked based on the vehicle's traveling speed and the shift position, but the traveling state of the vehicle may also be determined using information from the navigation device 100.
[0146] [Modification 5] In the above embodiment, the use of APIs is suspended due to factors related to billing. However, the suspension of API use may be collectively controlled for all APIs used by safety-related service applications.
[0147] [Modification 6] In the above embodiment, the use of the API is stopped due to a factor related to billing, but the use of the API may be stopped by prohibiting the start of a service application or by forcibly terminating the service application.
[0148] The ECU 4 and the methods described herein may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to execute one or more functions embodied in a computer program. Alternatively, the ECU 4 and the methods described herein may be implemented by a special-purpose computer configured by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the ECU 4 and the methods described herein may be implemented by one or more special-purpose 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 methods for implementing the functions of each unit included in the ECU 4 do not necessarily need to include software; all of the functions may be implemented using one or more hardware components.
[0149] In the above embodiments, multiple functions of one component 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. Furthermore, part of the configuration of the above embodiments may be omitted. Furthermore, 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.
[0150] In addition to the ECU 4 described above, the present disclosure can also be realized in various forms, such as a system including the ECU 4 as a component, a program for causing a computer to function as the ECU 4, a non-transient physical recording medium such as a semiconductor memory on which this program is recorded, and a service provision method. [Technical Ideas Disclosed in the Present Specification] [Item 1] An on-board device (4) that is mounted on a vehicle and connected to a plurality of electronic control devices (5 to 7) via an on-board network (8) and that constitutes a vehicle control system (2) together with the plurality of electronic control devices, the on-board device (4) comprising: a cooperation control unit (40) configured to realize cooperation between a service application (SA1) configured to provide a service to the vehicle and a control system functional block (35) configured to control the vehicle, the control system functional block comprising: a functional interface (37) configured to convert an access request expressed in a vehicle-independent format and transmitted from the service application into a vehicle-dependent format, the cooperation control unit being configured to transfer the access request transmitted from the service application to the control system functional block, the cooperation control unit comprising: a use suspension determination unit (S30) configured to determine whether a preset use suspension condition indicating that use of the functional interface needs to be suspended due to a factor related to charges incurred by using at least one of the service application and the functional interface has been established; and a usage control unit (S40 to S70, S100 to S120) configured to switch the operation of the vehicle control system based on functional interface information regarding the functional interface for which the usage suspension condition is met, vehicle status information indicating the status of the vehicle, and user input information input by a user using the vehicle.
[0151] [Item 2] The in-vehicle device according to Item 1, wherein the vehicle state information includes driving state information indicating a driving state of the vehicle and occupant presence information indicating whether or not an occupant is present in the vehicle, and the usage control unit is configured to switch the operation of the vehicle control system by determining whether to prohibit or permit suspension of usage of the function interface based on the function interface information, the vehicle state information, and the user input information.
[0152] [Item 3] The in-vehicle device according to Item 2, wherein the usage control unit is configured to prohibit the suspension of use of the functional interface when it determines, based on the functional interface information, that the functional interface is one for which it may be better not to allow the suspension of use, and when it determines, based on the driving state information, that the vehicle is driving.
[0153] [Item 4] The in-vehicle device according to item 2 or 3, wherein the usage control unit is configured to permit the suspension of use of the functional interface when it determines, based on the functional interface information, that the functional interface is one for which it may be better not to permit the suspension of use, determines, based on the driving state information, that the vehicle is stopped, and determines, based on the user input information, that the user has permitted the suspension of use of the functional interface.
[0154] [Item 5] The in-vehicle device according to any one of Items 2 to 4, wherein the usage control unit is configured to permit the suspension of use of the functional interface when it determines, based on the functional interface information, that the functional interface is one for which it may be better not to permit the suspension of use, determines, based on the driving state information, that the vehicle is parked, determines, based on the occupant presence / absence information, that an occupant is present in the vehicle, and determines, based on the user input information, that the user has permitted the suspension of use of the functional interface.
[0155] [Item 6] The in-vehicle device according to any one of Items 2 to 5, wherein the usage control unit is configured to permit the suspension of use of the functional interface when it determines, based on the functional interface information, that the functional interface is one for which it may be better not to permit the suspension of use, based on the driving state information, that the vehicle is parked, and based on the occupant presence / absence information, that no occupant is present in the vehicle.
[0156] [Item 7] The in-vehicle device according to any one of Items 2 to 6, wherein the usage control unit is configured to permit the suspension of use of the functional interface when it is determined, based on the functional interface information, that the functional interface is one for which it is unlikely that the suspension of use should be prohibited.
[0157] [Item 8] The in-vehicle device according to any one of items 2 to 7, wherein the cooperation control unit further includes: a prediction determination unit (S10) configured to determine whether a pre-set use suspension prediction condition indicating that use of the functional interface may be suspended has been established; and a notification unit (S20) configured to notify the user that use of the service application that uses the functional interface will be suspended when the prediction determination unit determines that the use suspension prediction condition has been established.
[0158] [Item 9] The in-vehicle device according to Item 8, wherein the notification unit is configured to notify the user using a first notification device (100) installed in the vehicle when the occupant is present in the vehicle, and to notify the user using a second notification device (10) registered in advance for the user when the occupant is not present in the vehicle.
[0159] [Item 10] A service providing method executed by an on-board device (4) that is mounted on a vehicle, connected to a plurality of electronic control devices (5-7) via an on-board network (8), and that configures a vehicle control system (2) together with the plurality of electronic control devices, wherein the on-board device comprises a cooperation control unit (40) configured to realize cooperation between a service application (SA1) configured to provide a service to the vehicle and a control system functional block (35) configured to control the vehicle, the control system functional block comprising: a functional interface (37) configured to convert an access request expressed in a vehicle-independent format and transmitted from the service application into a vehicle-dependent format, the cooperation control unit being configured to transfer the access request transmitted from the service application to the control system functional block, and the cooperation control unit determining whether a preset use suspension condition indicating that use of the functional interface needs to be suspended due to a factor related to charges incurred by using at least one of the service application and the functional interface has been established, A service provision method in which the collaboration control unit switches the operation of the vehicle control system based on functional interface information regarding the functional interface for which the usage suspension condition is met, vehicle status information indicating the status of the vehicle, and user input information entered by a user using the vehicle.
[0160] [Item 11] A computer of an on-board device (4) that is mounted on a vehicle and connected to a plurality of electronic control devices (5-7) via an on-board network (8), and that constitutes a vehicle control system (2) together with the plurality of electronic control devices, comprises: a functional interface (37) configured to convert an access request transmitted from a service application (SA1) configured to provide a service to the vehicle and expressed in a vehicle-independent format into a vehicle-dependent format; a cooperation control unit (40) configured to realize cooperation between the service application and a control system function block (35) that is equipped with the functional interface and configured to control the vehicle, and that is configured to transfer the access request transmitted from the service application to the control system function block; a use suspension determination unit (S30) configured to determine whether a preset use suspension condition indicating that use of the function interface needs to be suspended due to a factor related to charges incurred by using at least one of the service application and the functional interface has been established; A service provision program for causing the vehicle control system to function as a usage control unit (S40 to S70, S100 to S120) configured to switch the operation of the vehicle control system based on functional interface information regarding the functional interface for which the usage suspension condition is met, vehicle status information indicating the status of the vehicle, and user input information input by a user using the vehicle.
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 electronic control devices, comprising: a linkage control unit (40) configured to realize linkage between a service application (SA1) configured to provide a service to the vehicle and a control system functional block (35) configured to control the vehicle, the control system functional block comprising: a functional interface (37) configured to convert an access request expressed in a vehicle-independent format and transmitted from the service application into a vehicle-dependent format, the linkage control unit being configured to transfer the access request transmitted from the service application to the control system functional block, the linkage control unit comprising: a usage suspension determination unit (S30) configured to determine whether a preset usage suspension condition indicating that usage of the functional interface needs to be suspended due to a factor related to charges incurred by using at least one of the service application and the functional interface has been established; and a usage control unit (S40 to S70, S100 to S120) configured to switch the operation of the vehicle control system based on functional interface information regarding the functional interface for which the usage suspension condition is satisfied, vehicle state information indicating the state of the vehicle, and user input information input by a user using the vehicle.
2. An in-vehicle device as described in claim 1, wherein the vehicle status information includes driving status information indicating the driving status of the vehicle and occupant presence information indicating whether the vehicle has an occupant, and the usage control unit is configured to switch the operation of the vehicle control system by determining whether to prohibit or permit suspension of usage of the function interface based on the function interface information, the vehicle status information, and the user input information.
3. An in-vehicle device as described in claim 2, wherein the usage control unit is configured to prohibit the suspension of usage of the functional interface when it determines, based on the functional interface information, that the functional interface is one for which it may be better not to allow the suspension of usage, and when it determines, based on the driving state information, that the vehicle is driving.
4. An in-vehicle device as described in claim 2 or claim 3, wherein the usage control unit is configured to permit the suspension of usage of the functional interface when it determines, based on the functional interface information, that the functional interface is one for which it may be better not to permit the suspension of usage, determines, based on the driving condition information, that the vehicle is stopped, and determines, based on the user input information, that the user has permitted the suspension of usage of the functional interface.
5. An in-vehicle device as described in claim 2 or claim 3, wherein the usage control unit is configured to permit the suspension of usage of the functional interface when it determines, based on the functional interface information, that the functional interface is one for which it may be better not to permit the suspension of usage, determines, based on the driving state information, that the vehicle is parked, determines, based on the occupant presence / absence information, that an occupant is present in the vehicle, and determines, based on the user input information, that the user has permitted the suspension of usage of the functional interface.
6. An in-vehicle device as described in claim 2 or claim 3, wherein the usage control unit is configured to permit the suspension of usage of the functional interface when it determines, based on the functional interface information, that the functional interface is one for which it may be better not to permit the suspension of usage, based on the driving state information, that the vehicle is parked, and based on the occupant presence / absence information, that there is no occupant in the vehicle.
7. An in-vehicle device as described in claim 2 or claim 3, wherein the usage control unit is configured to permit the suspension of usage of the functional interface when it determines, based on the functional interface information, that the functional interface is one for which it is unlikely that the suspension of usage should be permitted.
8. An in-vehicle device as described in claim 2 or claim 3, wherein the cooperation control unit further comprises: a prediction determination unit (S10) configured to determine whether a preset usage suspension prediction condition indicating that usage of the functional interface may be suspended has been established; and a notification unit (S20) configured to notify the user that usage of the service application that uses the functional interface will be suspended when the prediction determination unit determines that the usage suspension prediction condition has been established.
9. An in-vehicle device as described in claim 8, wherein the notification unit is configured to notify the user using a first notification device (100) installed in the vehicle when an occupant is present in the vehicle, and to notify the user using a second notification device (10) pre-registered for the user when no occupant is present in the vehicle.
10. A service providing method executed by 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 electronic control devices, wherein the on-board device comprises a linkage control unit (40) configured to realize linkage between a service application (SA1) configured to provide a service to the vehicle and a control system functional block (35) configured to control the vehicle, the control system functional block comprises a functional interface (37) configured to convert an access request expressed in a vehicle-independent format and transmitted from the service application into a vehicle-dependent format, the linkage control unit is configured to transfer the access request transmitted from the service application to the control system functional block, and the linkage control unit determines whether a preset usage suspension condition indicating that usage of the functional interface needs to be suspended due to a factor related to charges incurred by using at least one of the service application and the functional interface has been established, A service providing method in which the coordination control unit switches the operation of the vehicle control system based on functional interface information regarding the functional interface for which the usage suspension condition is met, vehicle status information indicating the status of the vehicle, and user input information entered by a user using the vehicle.
11. A computer of an on-board device (4) mounted on a vehicle and connected to a plurality of electronic control devices (5-7) via an on-board network (8), constituting a vehicle control system (2) together with the plurality of electronic control devices, comprising: a functional interface (37) configured to convert an access request transmitted from a service application (SA1) configured to provide a service to the vehicle and expressed in a vehicle-independent format into a vehicle-dependent format; a cooperation control unit (40) configured to realize cooperation between the service application and a control system functional block (35) equipped with the functional interface and configured to control the vehicle, and configured to transfer the access request transmitted from the service application to the control system functional block; a usage suspension determination unit (S30) configured to determine whether a preset usage suspension condition indicating that usage of the functional interface needs to be suspended due to a factor related to charges incurred by using at least one of the service application and the functional interface has been established; A service provision program for causing the vehicle control system to function as a usage control unit (S40 to S70, S100 to S120) configured to switch the operation of the vehicle control system based on functional interface information related to the functional interface for which the usage suspension condition is satisfied, vehicle state information indicating the state of the vehicle, and user input information input by a user using the vehicle.
Citation Information
Patent Citations
Key function management system
JP2016132918A
Electric vehicle, and power transmission system for transmitting power to electric vehicle
JP2019037031A
Vehicle control device, vehicle control program, and vehicle control system
WO2022260010A1
