Service provision system, server, in-vehicle device, service provision program, and service provision method

Abstract

The invention relates to a service providing system, a server, an in-vehicle device, a service providing program, and a service providing method. A vehicle control system (2) is provided with a cooperative control unit (40). The cooperation control unit implements cooperation between a service system function block (33) and function blocks (35, 36). The functional block is provided with functional interfaces (37, 38). The functional interface translates an access request sent from a service system functional block into a vehicle-dependent form. The cooperation control unit creates an access log on the basis of the execution status of the access request. The access log includes at least one of the number of times of use of the interface using the functional interface and the amount of communication data. The server calculates an interface utilization fee using the access log.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] The present international application claims the priority based on Japanese Patent Application No. 2022-123987 filed with the Japan Patent Office on August 3, 2022, the entire contents of which are hereby incorporated by reference into the present international application. Technical Field

[0003] The present disclosure relates to a service providing system, a server, a vehicle-mounted device, a service providing program, and a service providing method that provide services to a vehicle. Background Art

[0004] Patent document 1 describes a vehicle that includes a control unit that operates the vehicle based on operating information received from a management server, a management unit that manages the compartment of the vehicle in which a service user receives service from a service provider, and an interface unit that is set up to correspond to service-related information provided by the service provider and the compartment.

[0005] Patent Document 1: Japanese Patent Application Publication No. 2020-98610

[0006] As described in Patent Document 1, when a service provider provides a service to a vehicle, it may be necessary to obtain vehicle information related to the vehicle from a target vehicle to which the service is provided, or to cause the target vehicle to perform a predetermined action or process.

[0007] As a result of detailed research by the inventors, the following problem has been discovered: in such a case where a service provider utilizes a vehicle by acquiring vehicle information from the vehicle or causing the vehicle to perform a predetermined action or process, there may be a case where it is desirable to charge the service provider for such utilization. Summary of the invention

[0008] The present disclosure provides a technology that enables charging of a service provider who provides services to a vehicle.

[0009] One aspect of the present disclosure is a service providing system including a vehicle control system and a server. The vehicle control system includes a plurality of electronic control devices mounted on a vehicle and connected to an in-vehicle network. The server is configured to be able to perform data communication with the vehicle control system.

[0010] The vehicle control system includes a cooperation control unit configured to realize cooperation between a service system function block configured to provide a service to the vehicle and a function block configured to execute a predetermined process in the vehicle.

[0011] The function block includes a function interface configured to convert an access request expressed in a vehicle-independent format and transmitted from the service system function block into a vehicle-dependent format.

[0012] The cooperation control unit includes a request forwarding unit and an access log generating unit.

[0013] The request transfer unit is configured to transfer the access request transmitted from the service system functional block to the functional block.

[0014] The access log generation unit is configured to generate an access log including at least one of the number of interface utilization times and the amount of communication data generated by the service system function block utilizing the function interface based on the execution status of the access request by the plurality of electronic control devices. The number of interface utilization times is the number of times the service system function block utilizes the function interface.

[0015] The server is configured to calculate an interface usage fee generated by the service system function block using the function interface, using the access log created by the cooperation control unit.

[0016] The service providing system of the present disclosure configured in this way can calculate the interface usage fee using at least one of the number of interface usages and the communication data volume included in the access log. Therefore, the service providing system of the present disclosure can charge the service provider who provides the service to the vehicle.

[0017] Another aspect of the present disclosure is a server including a communication unit and a charge calculation unit.

[0018] The communication unit is configured to be able to perform data communication with the vehicle control system. When receiving the access log from the vehicle control system, the charge calculation unit is configured to calculate the interface use fee using the access log.

[0019] The server of the present disclosure configured in this way is a server included in the service providing system of the present disclosure, and can obtain the same effects as those of the service providing system of the present disclosure.

[0020] Still another aspect of the present disclosure is an in-vehicle device that is mounted on a vehicle and connected to a plurality of electronic control devices via an in-vehicle network, and includes a function interface, an access log creating unit, and a log sending unit.

[0021] The access log generating unit is configured to generate an access log including at least one of the number of interface usages and the amount of communication data based on the execution status of the access requests by the plurality of electronic control devices. The log transmitting unit is configured to transmit the access log to a server installed outside the vehicle-mounted device.

[0022] The vehicle-mounted device of the present disclosure configured in this way is a device included in the service providing system of the present disclosure, and can obtain the same effects as those of the service providing system of the present disclosure.

[0023] Another embodiment of the present disclosure is a service providing method performed by a service providing system having a vehicle control system and a server. The vehicle control system has a collaboration control unit configured to achieve collaboration between a service system function block and a function block, and the function block has a functional interface. Moreover, in the service providing method of the present disclosure, the collaboration control unit forwards an access request sent from the service system function block to the function block. In addition, the collaboration control unit creates an access log including at least one of the number of times an interface is used and the amount of communication data based on the execution status of the access request by multiple electronic control devices. Then, the server uses the access log created by the collaboration control unit to calculate the interface utilization fee generated by the service system function block utilizing the functional interface.

[0024] The service providing method of the present disclosure is a method executed by the service providing system of the present disclosure. By executing this method, the same effect as that of the service providing system of the present disclosure can be obtained.

[0025] Still another aspect of the present disclosure is a service providing program for causing a computer to function as a communication unit and a charge calculation unit.

[0026] A computer controlled by the service providing program of the present disclosure can constitute a part of the server of the present disclosure, and can obtain the same effects as the server of the present disclosure.

[0027] Another method disclosed herein is a service providing method executed by a server of a service providing system having a vehicle control system and a server, wherein the vehicle control system has a functional interface, and the server is configured to be able to communicate data with the vehicle control system. In the service providing method disclosed herein, the server communicates data with the vehicle control system. Furthermore, when the server receives an access log from the vehicle control system, the server uses the access log to calculate an interface usage fee generated by a service system functional block utilizing the functional interface, and the access log is prepared based on the execution status of multiple electronic control devices on access requests to include at least one of the number of times the interface is used and the amount of communication data.

[0028] The service providing method disclosed in the present invention is a method executed by the server disclosed in the present invention. By executing this method, the same effect as that of the server disclosed in the present invention can be obtained.

[0029] Still another aspect of the present disclosure is a service providing program for causing a computer of an onboard device mounted on a vehicle and connected to a plurality of electronic control devices via an onboard network to function as a function interface, an access log creating unit, and a log sending unit.

[0030] The computer controlled by the service providing program of the present disclosure can constitute a part of the vehicle-mounted device of the present disclosure, and can obtain the same effects as the vehicle-mounted device of the present disclosure.

[0031] Another embodiment of the present disclosure is a service providing method performed by an on-board device mounted on a vehicle and connected to a plurality of electronic control devices via an on-board network. The on-board device has a functional interface. In the service providing method of the present disclosure, the on-board device creates an access log including at least one of the number of times the interface is used and the amount of communication data based on the execution status of the access request by the plurality of electronic control devices. In addition, the on-board device sends the access log to a server provided outside the on-board device.

[0032] The service providing method of the present disclosure is a method executed by the vehicle-mounted device of the present disclosure. By executing this method, the same effect as that of the vehicle-mounted device of the present disclosure can be obtained. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 It is a block diagram showing the structure of the service providing system.

[0034] Figure 2 It is a block diagram showing the structure of the ECU.

[0035] Figure 3 It is a block diagram showing the charging steps.

[0036] Figure 4 It is a diagram that represents the steps of the API contract.

[0037] Figure 5 This is a flowchart showing the log creation process according to the first embodiment.

[0038] Figure 6 It is a diagram showing the structure of the statistical access log according to the first embodiment.

[0039] Figure 7 It is a sequence diagram showing the steps of settlement.

[0040] Figure 8 It is a diagram showing the structure of a statistical access log according to the second embodiment.

[0041] Fig. 9 It is a diagram showing the structure of the actuator operation type table.

[0042] Fig.10 This is a diagram showing the structure of a sensor action type table.

[0043] Fig.11 This is a flowchart showing the log creation process according to the second embodiment.

[0044] Fig.12 is a flow chart showing resource record processing.

[0045] Fig.13 This is a flowchart showing the additional record processing. DETAILED DESCRIPTION

[0046] [First embodiment]

[0047] Hereinafter, a first embodiment of the present disclosure will be described with reference to the drawings.

[0048] like Figure 1 As shown, the service providing system 1 of the present embodiment includes a vehicle control system 2 and a server 3 .

[0049] The vehicle control system 2 is mounted on the vehicle, and has a function of performing data communication with the server 3 via the wide area wireless communication network NW.

[0050] 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 application store that can be accessed via the wide area wireless communication network NW or the Internet.

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

[0052] The vehicle control system 2 includes one ECU 4, a plurality of ECUs 5, a plurality of ECUs 6, an external vehicle communication device 7, and an internal vehicle communication network 8. ECU is an abbreviation of Electronic Control Unit.

[0053] The ECU 4 realizes coordinated control of the entire vehicle by taking charge of the plurality of ECUs 5 .

[0054] ECU5 is set up in each domain divided by the functions in the vehicle, and mainly performs control of multiple ECU6 existing in the domain. Each ECU5 is connected to the subordinate ECU6 via a lower layer network (for example, CAN) that is independently set up. CAN is the abbreviation of Controller Area Network. CAN is a registered trademark. Domains are, for example, powertrain, body, chassis, and cockpit.

[0055] The ECU 6 connected to the ECU 5 belonging to the domain of the powertrain system includes, for example, an ECU 6 for controlling an engine, an ECU 6 for controlling a motor, and an ECU 6 for controlling a battery.

[0056] The ECU 6 connected to the ECU 5 belonging to the domain of the vehicle body includes, for example, an ECU 6 for controlling an air conditioner and an ECU 6 for controlling vehicle doors.

[0057] The ECU 6 connected to the ECU 5 belonging to the chassis domain includes, for example, an ECU 6 for controlling brakes and an ECU 6 for controlling steering.

[0058] The ECU 6 connected to the ECU 5 belonging to the cockpit domain includes, for example, an ECU 6 that controls the display of an instrument and a navigation system, and an ECU 6 that controls an input device operated by a vehicle occupant.

[0059] The vehicle external communication device 7 performs data communication with the server 3 via the wide area wireless communication network NW.

[0060] The in-vehicle communication network 8 includes CAN FD and Ethernet. Ethernet is a registered trademark. CAN FD is an abbreviation of CAN with Flexible Data Rate. CAN FD connects the ECU 4 with each ECU 5 and the external communication device 7 by bus. Ethernet connects the ECU 4 with each ECU 5 and the external communication device 7 independently.

[0061] ECU4 is an electronic control device centered on a microcomputer including CPU4a, ROM4b, and RAM4c. Various functions of the microcomputer are realized by CPU4a executing a program stored in a non-transitional physical recording medium. In this example, ROM4b is equivalent to a non-transitional physical recording medium storing the program. In addition, by executing the program, a method corresponding to the program is executed. In addition, a part or all of the functions executed by CPU4a may be constituted in hardware by one or more ICs. In addition, the number of microcomputers constituting ECU4 may be one or more.

[0062] ECU5, ECU6 and the vehicle external communication device 7 are all electronic control devices that are composed of a microcomputer having a CPU, ROM, RAM, etc., similarly to ECU4. In addition, the number of microcomputers that constitute ECU5, ECU6 and the vehicle external communication device 7 can be one or more. ECU5 includes more than one ECU6. ECU4 includes more than one ECU5, or includes the ECU5, 6 and the vehicle external communication device 7 of the entire vehicle.

[0063] Hereinafter, when the ECU 4 , ECU 5 , ECU 6 and the vehicle external communication device 7 are not particularly distinguished, they are referred to as vehicle-mounted devices 4 to 7 .

[0064] The server 3 includes a control unit 11 , a communication unit 12 , and a storage unit 13 .

[0065] The control unit 11 is an electronic control device centered on a microcomputer having a CPU 11a, a ROM 11b, and a RAM 11c. 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, the ROM 11b is equivalent to a non-transitional physical recording medium storing the program. In addition, by executing the program, a method corresponding to the program is executed. In addition, a part or all of the functions executed by the CPU 11a may be constituted in hardware by one or more ICs. In addition, the number of microcomputers constituting the control unit 11 may be one or more.

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

[0067] like Figure 2 As shown, the ECU 4 includes a real-time processing unit 20 and an application processing unit 30 (hereinafter, the application processing unit 30). When the ECU 4 includes a plurality of CPUs 4a, the real-time processing unit 20 and the application processing unit 30 may be implemented by processing executed by the same CPU or by processing executed by different CPUs.

[0068] The real-time processing unit 20 cooperates with the vehicle-mounted devices 5 to 7 connected via CAN FD to execute vehicle control requiring real-time performance, etc. The application processing unit 30 cooperates with the vehicle-mounted devices 5 to 7 connected via Ethernet to execute various application programs (e.g., entertainment applications, etc.) that require high processing capabilities.

[0069] The application processing unit 30 has a function of transmitting instructions for processing based on various application programs to the real-time processing unit 20. The real-time processing unit 20 has a function of transmitting information collected from the ECU and the like via CAN FD to the application processing unit 30. Thus, the real-time processing unit 20 and the application processing unit 30 cooperate with each other to realize various functions.

[0070] The software of the vehicle control system 2 is constructed in accordance with AUTOSAR. AUTOSAR is an architecture for autonomous driving and is the abbreviation of Automotive Open System Architecture. AUTOSAR is a registered trademark. AUTOSAR not only provides communication between software components (hereinafter, SW-C) installed to realize various applications, but also provides functions related to connection with the cloud and security. SW-C is componentized software to realize a certain function. An application contains more than one SW-C. In addition, the software of the vehicle control system 2 does not have to be constructed in accordance with AUTOSAR.

[0071] Each device belonging to the vehicle control system 2, that is, the ECU 4, ECU 5, ECU 6 and the vehicle external communication device 7, is provided with a platform. The platform provides an environment for executing SW-C described in a format that does not depend on hardware.

[0072] The platform has an operating environment (hereinafter, RTE) and basic software (hereinafter, BSW). RTE is an interface that connects SW-Cs to each other and between SW-C and BSW. BSW is a layer that connects hardware to SW-C, including OS, drivers, middleware, etc. The functions of BSW are divided into small modules, and the functions of each module are provided to SW-C via API. API is the abbreviation of Application Programming Interface.

[0073] Hereinafter, the platform included in the real-time processing unit 20 is referred to as a first platform 21 (hereinafter, first PF21 ), and the platform included in the application processing unit 30 is referred to as a second platform 31 (hereinafter, second PF31 ).

[0074] 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 applications) running on the first PF 21. The service application is an application that receives a request from a client, performs processing, and returns a result.

[0075] The control system functional block group 22 has an API for receiving commands related to vehicle motion, and is an application group for integrating the commands received by the API and implementing matching vehicle control. The control system functional block group 22 outputs various commands to the vehicle-mounted devices 5 to 7 that are entities that execute control based on the commands via the in-vehicle communication network 8.

[0076] 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 it to the application processing unit 30. In addition, the conversion gateway 211 has a function of converting a communication frame in the Ethernet format provided from the application processing unit 30 into a CAN FD format.

[0077] The application processing unit 30 includes a hypervisor 32 and executes software on a plurality of virtual machines. The hypervisor 32 may be omitted.

[0078] The application processing unit 30 includes a service system function block group 33 as a collection of service applications that operate on the second PF 31 .

[0079] The service system functional block group 33 is a collection of service applications. Each service application has one or more SW-Cs. Service applications are provided not only by vehicle manufacturers that manufacture vehicles but also by third parties. As third parties that provide service applications, for example, data users who provide services by collecting data from vehicles can be cited.

[0080] The second PF 31 includes a control system function block group 35 , a data system function block group 36 , and an API gateway 40 .

[0081] The control system function block group 35 is a collection of programs having an API for receiving requests related to vehicle control from the service system function block group 33. The control system function block group 35 has an API group 37 composed of a plurality of APIs, which converts an API access request from the service system function block group 33 in a form that is not dependent on the vehicle into an API access request in a form that is dependent on the vehicle, and provides it to the real-time processing unit 20. The above-mentioned "form that is not dependent on the vehicle" refers to a form common to vehicles (i.e., a form that absorbs different vehicle models). The above-mentioned "form that is dependent on the vehicle" refers to a form that is inherent to the vehicle.

[0082] The APIs included in the control system function block group 35 include a motion system API for controlling the motion of the vehicle and other non-motion system APIs. The API access request received by the motion system API is forwarded to the control system function block group 35, and is forwarded from the control system function block group 35 to the vehicle-mounted devices 5 to 7 that execute control based on the request via the in-vehicle communication network 8. The API access request received by the non-motion system API is forwarded to the vehicle-mounted devices 5 to 7 that execute control based on the request via the in-vehicle communication network 8.

[0083] The data system function block group 36 is a collection of programs having an API for processing vehicle data acquired and accumulated via the real-time processing unit 20. The data system function block group 36 has a function of abstracting the vehicle data, which is expressed in a vehicle-dependent form and supplied from the real-time processing unit 20, into a vehicle-independent form and accumulating it. The data system function block group 36 may also have an API that provides a function of sending specified vehicle data to an ECU or the like via Ethernet. In particular, when the destination is the off-vehicle communication device 7, the off-vehicle communication device 7 may also upload the sent vehicle data to the cloud. The data system function block group 36, like the control system function block group 35, has an API group 38 consisting of a plurality of APIs.

[0084] In addition, the communication with other onboard devices 5 to 7 via the control system functional block group 35 is not limited to CAN FD, and Ethernet or other communication methods may be used. In addition, the communication with other onboard devices 5 to 7 via the data system functional block group 36 is not limited to Ethernet, and CAN FD or other communication methods may be used.

[0085] The API gateway 40 is constructed using the function of the virtual function bus (hereinafter, VFB). VFB is an intermediate program that can realize communication between SW-Cs and communication between SW-Cs and BSWs without considering hardware and communication protocols, and is also called a software bus. Communication between SW-Cs refers to access to APIs provided by SW-Cs to other SW-Cs, and communication between SW-Cs and BSWs refers to access to APIs provided by SW-Cs to the control system function block group 35 and the data system function block group 36.

[0086] That is, the SW-C accesses various APIs via the API gateway 40 and implements desired functions using functions provided by the accessed APIs.

[0087] When using an API, the SW-C transmits an API access request. The API access request includes at least an application ID of a service application including the SW-C that is the source of the request and an API-ID that is information indicating an API that is the destination of the request.

[0088] like Figure 3 As shown, an application store 15 is provided in the server 3. As shown by arrow L1, the application store 15 has a function of registering a service application SA manufactured by a service provider SV (hereinafter, service provider SV) in the application store 15 based on an application of a service provider SV (hereinafter, service provider SV) who accesses the application store 15 using a communication device such as a personal computer. The service application SA registered in the application store 15 is published on the website of the application store 15.

[0089] In addition, as indicated by arrow L2 , the application store 15 has a function of registering the API used by the service application SA in the application store 15 based on the application of the service provider SV.

[0090] When the user US who accesses the website of the application store 15 purchases the service application SA, as indicated by an arrow L3 , the service application SA is installed in the ECU 4 mounted on the vehicle of the user US.

[0091] As shown by arrow L4, when the service application SA sends an API access request to the API gateway 40, as shown by arrow L5, the API gateway 40 forwards the API access request to the control system function block group 35. As described above, the control system function block group 35 converts the API access request into an API access request expressed in a form dependent on the vehicle, and provides it to the real-time processing unit 20. In addition, as shown by arrow L6, the API gateway 40 forwards the API access request to the data system function block group 36. The data system function block group 36 converts the API access request into an API access request expressed in a form dependent on the vehicle, and sends it to the ECU, etc. via Ethernet.

[0092] As indicated by arrow L7 , the API gateway 40 transmits a statistical access log including the number of API utilizations taking into account the execution status of the API access request and the amount of communication data accompanying the API utilization to the application store 15 .

[0093] The application store 15 calculates the API usage fee generated by the service application SA using the API based on the statistical access log received from the API gateway 40, and charges the API usage fee to the service provider SV. As shown by arrow L8, the service provider SV pays the collected API usage fee to the application store 15.

[0094] The application store 15 calculates the application usage fee of the service application SA based on the usage status of the service application SA, and charges the application usage fee to the user US. As shown by arrow L9, the user US pays the collected application usage fee to the application store 15. As shown by arrow L10, the application store 15 remits the application usage fee paid by the user US to the service provider SV.

[0095] Next, the procedure for the service provider SV to enter into an API usage contract is described.

[0096] like Figure 4 As shown in process P1, the service provider SV accesses the application store 15 and applies for registration of the service application to be released and the API to be used.

[0097] As shown in process P2 , the application store 15 checks whether the service application requested by the service provider SV can access the control system function block group 35 .

[0098] When the requested service application can access the control system function block group 35, as shown in process P3, the application store 15 prompts the service provider SV to charge for using the API.

[0099] As shown in the table TB1 , the application store 15 stores API policy information including API ID, reliability, and charging method in the storage unit 13 for each API applied for.

[0100] In table TB1, the reliability of the API with API ID API1 is "high", and the charging method is "by number of calls", and the reliability of the API with API ID API2 is "low", and the charging method is "monthly amount".

[0101] An API whose reliability is set to "high" accepts API access requests from service applications with higher reliability, and rejects API access requests from service applications with lower reliability.

[0102] For an API whose reliability is set to "low", even service applications with low reliability will accept API access requests.

[0103] "Per call" is a charging method that increases the fee based on the number of API access requests. "Monthly" is a charging method that charges a fixed fee every month regardless of the number of API access requests.

[0104] As shown in process P4, the service provider SV notifies the application store 15 of the content of agreeing to the contract under the API charging method presented. Then, as shown in process P5, the application store 15 publishes the service application applied for by the service provider SV on the website of the application store 15.

[0105] The application store 15 stores information of service applications distributed on the website (hereinafter, distributed application information) and information of APIs authorized for the service applications distributed on the website (hereinafter, API authorization information) in the storage unit 13 .

[0106] As shown in Table TB2, the published application information includes the application ID, the function name of the service application, the charging method of the service application, and the service provider ID for each published service application. The application ID is information for identifying the service application. The service provider ID is information for identifying the provider of the service application.

[0107] In table TB2, the function name of the service application with application ID APP1 is "Comfort Air Conditioning", the charging method is "Usage Time", and the service provider ID is "Dev1". The function name of the service application with application ID APP2 is "Road Service", the charging method is "Monthly", and the service provider ID is "Dev1".

[0108] The "usage time" charging method is a charging method that increases the fee according to the usage time of the service application. The "monthly amount" charging method is a charging method that charges a fixed fee every month regardless of the usage time of the service application.

[0109] As shown in Table TB3, the API authorization information includes an API ID and an application ID for each API that is authorized to be used.

[0110] Table TB3 shows that the API with API ID API1 is called by the service application with application ID APP1 , and the API with API ID API2 is called by the service application with application ID APP2 .

[0111] Next, the procedure of the log generation process executed by the API gateway 40 will be described. The log generation process is a process that is repeatedly executed during the operation of the ECU 4.

[0112] When executing the log generation process, such as Figure 5 As shown, first in S10, the API gateway 40 (hereinafter, APIGW40) determines whether an API access request is received. Here, if the API access request is not received, the APIGW40 moves to S80. On the other hand, if an API access request is received, in S20, the APIGW40 determines whether the received API access request can be executed. For example, the APIGW40 determines whether the ECU4 can perform data communication with the ECU6 that executes the processing indicated by the API access request. The APIGW40 determines that the API access request can be executed if data communication is possible, and determines that the API access request cannot be executed if data communication is not possible.

[0113] Here, if the API access request cannot be executed, the APIGW 40 moves to S70. On the other hand, if the API access request can be executed, in S30, the APIGW 40 determines whether it is necessary to forward the received API access request to the API that is the request destination. For example, if the APIGW 40 has already executed the processing indicated by the API access request, it determines that it is not necessary to forward the API access request to the API that is the request destination.

[0114] Here, when it is not necessary to forward the API access request, the APIGW 40 moves to S70 . On the other hand, when it is necessary to forward the API access request, in S40 , the APIGW 40 forwards the received API access request to the API serving as the request destination.

[0115] Then, in S50, APIGW 40 determines whether the execution result of the transferred API access request is received from the API to which the API access request was transferred. Here, if the execution result is not received, the processing of S50 is repeated to wait until the execution result is received.

[0116] Then, when receiving the execution result of the API access request, in S60 , the APIGW 40 transfers the execution result received from the API to the service application that is the request source of the API access request, and the process proceeds to S70 .

[0117] When the process moves to S70 , the APIGW 40 creates a statistical access log.

[0118] The statistical access log is determined by the application providing the API, the API, and the request source of the API access request. That is, when the number of applications providing the API is set to A, the number of APIs is set to B, and the number of request sources of the API access request is set to C, the number of statistical access logs is A×B×C.

[0119] like Figure 6 As shown, the statistical access log includes the API providing application ID, API-ID, calling source application ID, API call-out times, API execution completion times, API execution not required times, API execution exception times, API communication data volume, execution completion times during no-power parking, execution completion times during powered parking, execution completion times during stopped driving, and execution completion times during driving.

[0120] API provider application ID is the identifier of the application that provides the API. API-ID is the identifier of the API. Call source application ID is the identifier of the application that uses the API.

[0121] The number of API call-outs is the number of times a service application identified by the call source application ID makes API access requests.

[0122] The API execution completion count is the number of times a process corresponding to an API access request is executed and completed.

[0123] The API unnecessary execution count is the number of times the execution of the processing becomes unnecessary because the processing corresponding to the API access request has already been executed.

[0124] The number of API execution exceptions is the number of times that a process corresponding to an API access request was not executed due to an exception.

[0125] The API communication data volume is a cumulative value of the amount of data acquired through processing corresponding to the API access request.

[0126] The number of execution completions during power-off parking is the number of times a process corresponding to an API access request is executed and completed during power-off parking.

[0127] The number of execution completions during power supply stop is the number of times a process corresponding to an API access request is executed and completed during power supply stop.

[0128] The number of execution completions during a stop is the number of times a process corresponding to an API access request is executed and completed during a stop.

[0129] The number of execution completions during driving is the number of times a process corresponding to an API access request is executed and completed during driving.

[0130] Furthermore, the classification of the number of completed executions into "parked without power supply", "parked with power supply", "stopped driving", and "driving" is an example, and the number of completed executions in other vehicle states may be added.

[0131] Next, a first specific example of statistical access log creation will be described.

[0132] Assuming that the doors of a vehicle parked without power are unlocked, the service application sends an API access request indicating that the doors are locked to APIGW40. When receiving the API access request, APIGW40 confirms the state of the vehicle's doors. Since the vehicle's doors are unlocked, APIGW40 determines that the API access request needs to be forwarded, and forwards the received API access request to the API of the request destination. As a result, ECU4 sends an instruction indicating that the doors are locked to ECU6 that controls the doors. When ECU6 that controls the doors receives an instruction indicating that the doors are locked, it locks the vehicle's doors. When the locking of the vehicle's doors is completed, ECU6 that controls the doors sends an execution result indicating that the vehicle's doors have become locked to ECU4. When APIGW40 receives the above-mentioned execution result from the API of the request destination, it forwards the above-mentioned execution result to the service application of the request source. Furthermore, the APIGW 40 increments (ie, adds 1) the API call count and the API execution completion count in the statistical access log specified by the API providing application ID, API-ID, and the call source application ID, and increments the execution completion count in the power-off parking state.

[0133] Next, a second specific example of statistical access log creation will be described.

[0134] Assuming that the doors of the vehicle in the power-on parking state are locked, the service application sends an API access request indicating that the doors are locked to APIGW40. When receiving the API access request, APIGW40 confirms the state of the vehicle's doors. Since the vehicle's doors are locked, APIGW40 determines that the forwarding of the API access request is not necessary, and sends a notification indicating that the door locking instruction has been completed normally to the service application of the request source. Furthermore, APIGW40 increments the number of API call-outs and the number of API unnecessary executions in the statistical access log.

[0135] Next, a third specific example of statistical access log creation will be described.

[0136] Assuming that the doors of a vehicle parked without power are unlocked, the first service application sends an API access request indicating that the doors are locked to APIGW40, and the second service application sends an API access request indicating that the doors are unlocked to APIGW40. APIGW40 performs arbitration between the first service application and the second service application. Since the second service application has a higher priority than the first service application, APIGW40 sends a notification to the first service application indicating that the instruction to lock the doors has not been executed due to arbitration failure, and increments the number of API call-outs and the number of API execution exceptions in the statistical access log of the first service application. In addition, since the doors of the vehicle are unlocked, APIGW40 determines that it is not necessary to forward the API access request of the second service application, and sends a notification to the second service application indicating that the instruction to unlock the doors has ended normally. Furthermore, APIGW40 increments the number of API call-outs and the number of API execution exceptions in the statistical access log of the second service application.

[0137] Next, a fourth specific example of statistical access log creation will be described.

[0138] Assume that the service application sends an API access request for obtaining vehicle speed information to the APIGW 40 when the communication between the ECU 4 and the vehicle-mounted devices 5 to 7 is interrupted. Since the communication is abnormal, the APIGW 40 sends a notification indicating that the vehicle speed information cannot be obtained due to the communication abnormality to the service application of the request source. Furthermore, the APIGW 40 increments the number of API call-outs and the number of API execution abnormalities in the statistical access log determined by the API providing application ID, API-ID, and the calling source application ID.

[0139] Next, a fifth specific example of statistical access log creation will be described.

[0140] Assume that the service application sends an API access request for obtaining the vehicle speed information that is updated every 300ms to APIGW40. Since more than 300ms have passed since the last API access request for obtaining the vehicle speed information, APIGW40 determines that the API access request needs to be forwarded, and forwards the received API access request to the API of the request destination. As a result, ECU4 sends the instruction for obtaining the vehicle speed information to ECU6 that controls the engine. When ECU6 that controls the engine obtains the vehicle speed information, it sends the execution result indicating the obtained vehicle speed information to ECU4. When APIGW40 receives the above-mentioned execution result from the API of the request destination, it forwards the above-mentioned execution result to the service application of the request source. Furthermore, APIGW40 increments the number of API calls and the number of API execution completions in the statistical access log determined by the API providing application ID, API-ID, and the calling source application ID.

[0141] Furthermore, it is assumed that the service application sends an API access request for obtaining vehicle speed information to APIGW 40 100ms after the last API access request for obtaining vehicle speed information. Since less than 300ms have passed since the last API access request, APIGW 40 determines that the forwarding of the API access request is unnecessary, and sends the vehicle speed information of the same value as the last time to the service application of the request source, and increments the number of API call-outs and the number of API unnecessary executions in the statistical access log.

[0142] Next, a sixth specific example of statistical access log creation will be described.

[0143] Assume that the service application sends an API access request indicating the acquisition of surrounding map data to APIGW40. APIGW40 determines that the forwarding of the API access request is required, and forwards the received API access request to the API of the request destination. As a result, ECU4 sends an instruction indicating the acquisition of surrounding map data to ECU6 that controls the navigation device. When ECU6 that controls the navigation device acquires the surrounding map data, it sends the execution result indicating the acquired surrounding map data to ECU4. When APIGW40 receives the above-mentioned execution result from the API of the request destination, it forwards the above-mentioned execution result to the service application of the request source. Furthermore, APIGW40 increments the number of API calls and the number of API execution completions in the statistical access log determined by the API providing application ID, API-ID, and the calling source application ID, and adds the value corresponding to the data volume of the surrounding map data to the API communication data volume.

[0144] like Figure 5As shown, when the process of S70 is completed, in S80, the APIGW 40 determines whether the upload timing has arrived. The upload timing is set to arrive every 24 hours, for example.

[0145] Here, if the upload timing has not arrived, the APIGW 40 ends the log creation process. On the other hand, if the upload timing has arrived, in S90 , the APIGW 40 uploads all statistical access logs to the server 3 and ends the log creation process.

[0146] Next, the steps of user settlement and service provider settlement are explained.

[0147] like Figure 7 As shown by arrow L11, user US uses service application SA, and as shown by arrow L12, service application SA uses API. Whenever service application SA uses API, as shown by process P11, APIGW 40 updates the statistical access log.

[0148] The application store 15 calculates the application usage fee generated by the user US using the service application SA, for example, every month, as shown in process P12, and charges the calculated application usage fee to the user US, as shown in process P13.

[0149] As shown in process P14, when the user US pays the application usage fee to the application store 15, the application store 15 settles the application usage fee as shown in process P15. Thereafter, the application store 15 remits the application usage fee to the service provider SV as shown in process P16, and notifies the user US of the settlement completion as shown in process P17.

[0150] When the APIGW 40 uploads the statistical access log as shown in process P21 , the application store 15 calculates the API usage fee generated by the service application SA using the API based on the statistical access log as shown in process P22 .

[0151] The application store 15 sets the execution completion charging coefficient C1, the execution-not-needed charging coefficient C2, the execution abnormality charging coefficient C3, the communication data charging coefficient C4, the execution completion charging coefficient C5 during parking without power supply, the execution completion charging coefficient C6 during parking with power supply, the execution completion charging coefficient C7 during stopped driving, and the execution completion charging coefficient C8 during driving according to each statistical access log determined by the application ID, API-ID, and the calling source application ID provided by the API.

[0152] The execution completion charging coefficient C1 is the charging amount when the number of API execution completions is 1.

[0153] The non-execution charging coefficient C2 is the charge amount when the number of API non-executions is 1.

[0154] The execution abnormality charging coefficient C3 is the charging amount when the number of API execution abnormalities is 1.

[0155] The communication data charging coefficient C4 is the amount charged per unit of communication data volume.

[0156] The execution completion charging coefficient C5 in the case where the execution completion number in the case where the power-off parking is 1 is a charging amount.

[0157] The execution completion charging coefficient C6 during the power supply stop is a charging amount when the execution completion count during the power supply stop is one.

[0158] The stop-travel execution completion charging coefficient C7 is a charging amount when the stop-travel execution completion count is one.

[0159] The execution completion charging coefficient C8 during driving is the charging amount when the number of execution completions during driving is one.

[0160] That is, the application store 15 calculates the API usage fee for one statistical access log by multiplying the number of times or the amount of data by a corresponding coefficient. Furthermore, the application store 15 calculates the API usage fee for the service application SA by accumulating the API usage fees of all statistical access logs.

[0161] Furthermore, when there are a plurality of APIs that operate the same actuator and the arbitration priorities of the plurality of APIs are different, the charging coefficient of the API with a higher priority is larger than the charging coefficient of the API with a lower priority.

[0162] In addition, the execution completion charging coefficient C5 in the case of non-power parking is larger than the execution completion charging coefficient C6 in the case of power supply parking. That is, the charging amount in the case of non-power parking with limited power supply is higher than that in the case of power supply parking with power supply.

[0163] In addition, the execution completion charging coefficient C7 during stopped driving is larger than the execution completion charging coefficient C8 during driving. That is, the charging amount during stopped driving with power supply limited is higher than that during driving with power generation.

[0164] Furthermore, when there are multiple APIs for acquiring the same information and the responsiveness of these multiple APIs is different, the charging coefficient of the API with higher responsiveness is larger than the charging coefficient of the API with lower responsiveness.

[0165] In addition, the charging factor varies depending on the quality of the data obtained. For example, for data that requires professional knowledge, such as narrow road scene determination, the charging factor is higher, and for simple data such as vehicle speed information, the charging factor is lower. In addition, whether the equipment can be used (for example, notification of capability update) is free at the time of initial installation, but change notification is charged. In addition, the charging factor of APIs that obtain multiple data at the same time, such as data with timestamps, is higher.

[0166] When the calculation of the API usage fee of the service application SA is completed, as shown in process P23, the application store 15 charges the calculated API usage fee to the service provider SV.

[0167] When the service provider SV pays the API usage fee to the application store 15 as shown in process P24, the application store 15 settles the API usage fee as shown in process P25. Thereafter, as shown in process P26, the application store 15 notifies the service provider SV of the settlement completion.

[0168] The service providing system 1 configured in this manner includes a vehicle control system 2 and a server 3 .

[0169] The vehicle control system 2 is mounted on the vehicle. The vehicle control system 2 includes vehicle-mounted devices 4 to 7 connected to an in-vehicle communication network 8. The server 3 is configured to be able to perform data communication with the vehicle control system 2.

[0170] The vehicle control system 2 includes an API gateway 40. The API gateway 40 is configured to realize cooperation between a service system function block group 33 configured to provide services to the vehicle and a control system function block group 35 configured to control the vehicle.

[0171] The control system function 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 service system function block group 33 into a vehicle-dependent format.

[0172] The API gateway 40 is configured to transfer the API access request transmitted from the service system functional block group 33 to the control system functional block group 35 .

[0173] The API gateway 40 is configured to generate a statistical access log based on the execution status of the API access request by the vehicle-mounted devices 4 to 7. The statistical access log includes the number of API call-outs, the number of API execution completions, the number of API unnecessary executions, the number of API execution exceptions, the amount of API communication data, the number of execution completions during parking without power, the number of execution completions during parking with power, the number of execution completions during stopped driving, and the number of execution completions during driving.

[0174] The server 3 is configured to calculate the API usage fee generated by the service system function block group 33 using the API group 37 , using the statistical access log created by the API gateway 40 .

[0175] Such a service providing system 1 can calculate the API usage fee using the number of times and the communication data volume included in the statistical access log. Therefore, the service providing system 1 can charge the service provider SV that provides the service to the vehicle.

[0176] The server 3 includes a communication unit 12 and an application store 15 .

[0177] The communication unit 12 is configured to be able to perform data communication with the vehicle control system 2. The application store 15 is configured to calculate the API usage fee using the statistical access log when receiving the statistical access log from the vehicle control system 2. Such a server 3 is a server provided by the service providing system 1, and can obtain the same effect as the service providing system 1.

[0178] The ECU 4 is mounted on the vehicle and is connected to the vehicle-mounted devices 5 to 7 via the in-vehicle communication network 8 . The ECU 4 includes an API group 37 and an APIGW 40 .

[0179] The API gateway 40 is configured to generate a statistical access log based on the execution status of the API access request by the vehicle-mounted devices 4 to 7. The API gateway 40 is configured to send the statistical access log to the server 3 provided outside the ECU 4. Such an ECU 4 is a device provided by the service providing system 1, and can obtain the same effect as the service providing system 1.

[0180] In the above-described embodiment, the in-vehicle communication network 8 is equivalent to the vehicle network, the vehicle-mounted devices 4 to 7 are equivalent to multiple electronic control devices, the service system function block group 33 is equivalent to the service system function block, the control system function block group 35 is equivalent to the function block, and the API gateway 40 is equivalent to the collaborative control unit.

[0181] In addition, the API group 37 corresponds to the functional interface, S40 corresponds to the processing as a request forwarding unit, the API access request corresponds to the access request, S70 corresponds to the processing as an access log generating unit, and the statistical access log corresponds to the access log.

[0182] In addition, the number of API call-outs, the number of API execution completions, the number of API executions that do not require execution, the number of API execution exceptions, the number of execution completions during no-power parking, the number of execution completions during power-on parking, the number of execution completions during stopped driving, and the number of execution completions during driving are equivalent to the number of interface utilization times.

[0183] In addition, the API communication data volume is equivalent to the communication data volume, and the API usage fee is equivalent to the interface usage fee.

[0184] In addition, the number of API execution completions is equal to the number of execution completions, the number of API executions that are not required is equal to the number of executions that are not required, and the number of API execution exceptions is equal to the number of execution exceptions.

[0185] The number of times the execution is completed in a non-powered parking state, the number of times the execution is completed in a powered parking state, the number of times the execution is completed in a stopped driving state, and the number of times the execution is completed in a driving state correspond to the number of times the execution is completed in each of a plurality of vehicle states.

[0186] The API communication data volume corresponds to the cumulative value of the data volume acquired by the service system function block, the application store 15 corresponds to the charge calculation unit, and S90 corresponds to the processing as the log sending unit.

[0187] [Second embodiment]

[0188] The second embodiment of the present disclosure and the attached Figure 1 In the second embodiment, the parts different from the first embodiment are described. The same reference numerals are used for the common structures.

[0189] The service providing system 1 of the second embodiment is different from the first embodiment in that the statistical access log and log creation process are changed.

[0190] like Figure 8 As shown, the statistical access logs of the second embodiment are composed of a plurality of first statistical access logs AL1, a plurality of second statistical access logs AL2, a plurality of third statistical access logs AL3, a plurality of fourth statistical access logs AL4, and a plurality of fifth statistical access logs AL5.

[0191] The first statistical access log AL1 is determined by the application providing the API, the API, and the request source of the API access request.

[0192] In addition to the above-mentioned API providing application ID, API-ID, calling source application ID, API call times, API execution completion times, API execution unnecessary times, API execution exception times, API communication data volume, execution completion times during no-power parking, execution completion times during powered parking, execution completion times during stopped driving, and execution completion times during driving, the first statistical access log AL1 also includes the total calculation amount, total power amount, total communication volume, the number of ECUs that performed actions, the number of batteries that performed actions, the number of communication line paths that performed actions, and the number of external vehicle systems that performed actions.

[0193] The total amount of computation is the total amount of computation required to provide the API function.

[0194] The total amount of power is the total amount of power required to provide the functions of the API.

[0195] The total communication volume is the total amount of communication volume required to provide the API function.

[0196] The number of ECUs that have performed an operation is the number of ECUs that have performed an operation in cooperation to provide the API function.

[0197] The number of operated batteries is the number of batteries used to provide the API function.

[0198] The number of communication line paths in operation is the number of communication line paths used to provide the API function.

[0199] The number of external vehicle systems that have performed operations is the number of external vehicle systems that have performed operations in cooperation in order to provide the API function.

[0200] The first statistical access log AL1 is determined by the application providing the API, the API, and the request source of the API access request. That is, when the number of applications providing the API is set to A, the number of APIs is set to B, and the number of request sources of the API access request is set to C, the number of the first statistical access log AL1 is A×B×C.

[0201] The second statistical access log AL2 includes the API providing application ID, API-ID, the calling source application ID, the actuator / sensor ID, the actuator / sensor action times, and the actuator / sensor working time.

[0202] The actuator / sensor ID is an identifier of an actuator or a sensor.

[0203] The number of actuator / sensor actuations is the number of times the actuator or sensor is actuated for API call.

[0204] The actuator / sensor operating time is the time that the actuator or sensor operates in response to the API call.

[0205] The second statistical access log AL2 is determined by the application providing the API, the API, the request source of the API access request, and the actuator or sensor. That is, when the number of applications providing the API is set to A, the number of APIs is set to B, the number of request sources of the API access request is set to C, and the number of actuators or sensors is set to D, the number of the second statistical access log AL2 is A×B×C×D.

[0206] The third statistical access log AL3 includes the API providing application ID, API-ID, the calling source application ID, the ECU / system ID, the calculation amount, and the calculation amount weighted by the margin.

[0207] The ECU / system ID is an identifier of an ECU or a system.

[0208] The amount of computation is the amount of computation required to provide the functionality of the API.

[0209] The margin-weighted calculation amount is a value calculated by weighting the calculation amount required to provide the API function according to the margin of the calculation resource of each ECU or each system that is operating.

[0210] The third statistical access log AL3 is determined by the application providing the API, the API, the request source of the API access request, and the ECU or system. That is, when the number of applications providing the API is set to A, the number of APIs is set to B, the number of request sources of the API access request is set to C, and the number of ECUs or systems is set to E, the number of the third statistical access log AL3 is A×B×C×E.

[0211] The fourth statistical access log AL4 includes the API providing application ID, API-ID, the calling source application ID, the battery type ID, the power amount, and the power amount weighted by the margin.

[0212] The battery type ID is an identifier of the battery type.

[0213] The power amount is the amount of power required to provide the API function.

[0214] The margin-weighted electric power is a value calculated by weighting the electric power required to provide the API function according to the margin of the battery power.

[0215] The fourth statistical access log AL4 is determined by the application providing the API, the API, the request source of the API access request, and the battery type. That is, when the number of applications providing the API is set to A, the number of APIs is set to B, the number of request sources of the API access request is set to C, and the number of battery types is set to F, the number of the fourth statistical access log AL4 is A×B×C×F.

[0216] The fifth statistical access log AL5 includes the API providing application ID, API-ID, the calling source application ID, the communication line path ID, the communication volume, and the communication volume weighted by the margin.

[0217] The communication line path ID is an identifier of the communication line path.

[0218] The amount of communication is the amount of communication required to provide the functionality of the API.

[0219] The margin-weighted communication volume is a value calculated by weighting the communication volume required to provide the API function according to the margin of the communication band.

[0220] The fifth statistical access log AL5 is determined by the application providing the API, the API, the request source of the API access request, and the communication line path. That is, when the number of applications providing the API is set to A, the number of APIs is set to B, the number of request sources of the API access request is set to C, and the number of communication line paths is set to G, the number of the fifth statistical access log AL5 is A×B×C×G.

[0221] Next, a specific example of recording the amount of calculation required to operate an actuator in a process corresponding to an API access request to an API (hereinafter referred to as an operating system API) included in the control system function block group 35 will be described.

[0222] Assume that the windows of the vehicle are in a fully open state, and the windows of the vehicle are in a fully closed state by an API access request instructing to fully close the windows.

[0223] In a vehicle equipped with a window opening and closing actuator having a pinching detection function, the amount of calculation required for window opening and closing control is greater than that of a vehicle equipped with a window opening and closing actuator not having a pinching detection function. That is, the amount of calculation required to perform opening and closing control so that the vehicle window changes from a fully open state to a fully closed state varies depending on the type of the window opening and closing actuator.

[0224] Therefore, in a vehicle equipped with a window opening and closing actuator having a pinching detection function, the basic amount of calculation required to execute opening and closing control so that the vehicle window changes from a fully open state to a fully closed state (hereinafter, the basic amount of calculation) is set to, for example, "10". In addition, in a vehicle equipped with a window opening and closing actuator not having a pinching detection function, the basic amount of calculation required to execute opening and closing control so that the vehicle window changes from a fully open state to a fully closed state is set to, for example, "5".

[0225] Assuming that the vehicle window is in a fully open state or a half-open state (for example, 50% open state), the vehicle window becomes fully closed by an API access request instructing full closing of the window.

[0226] When a window of a vehicle is fully opened, the amount of calculation required for opening and closing control of the window is greater than when the window of the vehicle is half opened.

[0227] Therefore, the calculation amount recorded in the statistical access log when the vehicle window is moved from the fully open state to the fully closed state (hereinafter, the recorded calculation amount) is, for example, the basic calculation amount of the window opening and closing actuator. In addition, the recorded calculation amount when the vehicle window is moved from the half-open state to the fully closed state with the window opened 50% is, for example, the value obtained by multiplying the basic calculation amount of the window opening and closing actuator by 0.5.

[0228] That is, the APIGW 40 adds the calculated recorded calculation amount to the “total calculation amount” in the first statistical access log AL1 corresponding to the executed process, and adds it to the “calculation amount” in the third statistical access log AL3 corresponding to the executed process.

[0229] Next, a specific example of recording the types and numbers of actuators that have been operated in a process corresponding to an API access request to an operating system API will be described.

[0230] Assume that four windows or one window of the vehicle are in a fully open state, and all the windows of the vehicle are in a fully closed state by an API access request instructing to fully close the windows.

[0231] When four windows are fully opened, the number of actuators operated recorded in the statistical access log is four, and when one window is fully opened, the number of actuators operated recorded in the statistical access log is one.

[0232] In addition, the number of operations of the window opening and closing actuators having the pinching detection function and the number of operations of the window opening and closing actuators not having the pinching detection function are recorded in the statistical access log.

[0233] That is, the APIGW 40 records the types and numbers of the actuators that have been operated in the “number of operated ECUs” in the first statistical access log AL1 corresponding to the executed process.

[0234] Next, a specific example of recording the types and numbers of ECUs or systems that cooperate to operate an actuator in a process corresponding to an API access request to an operating system API will be described.

[0235] Assuming that the service application is configured in the cloud, the service application sends an API access request indicating an arbitrary window operation to the API gateway 40. In this case, the cooperative action of the cloud system, the external communication device 7, the ECU 4, and the ECU 5 belonging to the vehicle body domain is recorded in the statistical access log.

[0236] In addition, assuming that the service application is configured in ECU 4, the service application sends an API access request instructing an arbitrary window operation to API gateway 40. In this case, the cooperative action of ECU 4 and ECU 5 belonging to the vehicle body domain is recorded in the statistical access log.

[0237] Furthermore, assuming that a service application is disposed in ECU 5 belonging to the vehicle body domain, the service application sends an API access request instructing an arbitrary window operation to API gateway 40. In this case, the fact that ECU 5 belonging to the vehicle body domain has operated is recorded in the statistical access log.

[0238] That is, the APIGW 40 records the types and numbers of ECUs or systems that cooperate to operate the actuators in the “number of operated ECUs” and “number of operated external systems” in the first statistical access log AL1 corresponding to the executed process.

[0239] Next, a specific example of recording the amount of electric power consumed to operate an actuator in a process corresponding to an API access request to an operating system API will be described.

[0240] Each time the execution of the processing corresponding to the API access request is completed normally, the power consumption of the system, ECU or actuator that performed the action related to the processing is recorded in the statistical access log. In the case where it is difficult to directly measure the power consumption, the power consumption is calculated based on a power table that pre-sets the power amount of each action for each of multiple systems, multiple ECUs or multiple actuators. In addition, the unit price of electricity varies depending on the drive system of the car. For example, the unit price of electricity is lower for a vehicle that has only an electric motor as a driving source than for a vehicle that has only an engine as a driving source.

[0241] That is, the APIGW 40 adds the calculated power consumption amount to the “total power amount” in the first statistical access log AL1 corresponding to the executed process, and adds it to the “power amount” in the fourth statistical access log AL4 corresponding to the executed process.

[0242] Next, a specific example of recording the communication volume required to operate the actuator in the process corresponding to the API access request to the operating system API will be described.

[0243] Each time the execution of a process corresponding to an API access request is completed normally, the communication volume of the system, ECU, or actuator that performed the action related to the process is recorded in the statistical access log. In the case where it is difficult to measure the communication volume directly, the communication volume is calculated based on a communication volume table that pre-sets the communication volume of each action for each of multiple systems, multiple ECUs, or multiple actuators. In addition, the communication volume is recorded for each type of communication line. As types of communication lines, for example, satellite lines, mobile phone lines, off-vehicle Wi-Fi communication, in-vehicle Ethernet communication, in-vehicle CAN communication, in-vehicle Wi-Fi communication, etc. can be cited. In addition, for example, the price weight varies for each line, such as the communication fee for satellite lines with higher communication costs and the communication fee for in-vehicle CAN communication is higher, while the communication fee for off-vehicle Wi-Fi communication is lower. Wi-Fi is a registered trademark.

[0244] That is, the APIGW 40 adds the calculated communication volume to the “total communication volume” in the first statistical access log AL1 corresponding to the executed process, and adds it to the “communication volume” in the fifth statistical access log AL5 corresponding to the executed process.

[0245] In addition, APIGW40 calculates the amount of resources weighted by the margin (hereinafter, the weighted resource amount) based on the amount of resources required to operate the actuator (i.e., the amount of calculation, the amount of electricity, and the amount of communication) and the margin of the current system, and records the calculated weighted resource amount in the statistical access log. The weighted resource amount is calculated so that the smaller the margin, the greater the weight. Regarding the weighted calculation amount, for example, the CPU margin set to be negatively correlated with the utilization rate of CPU4a is used for calculation. Regarding the weighted electricity amount, for example, the power margin set to be positively correlated with the charging rate of the vehicle battery is used for calculation. Regarding the weighted communication volume, for example, the communication margin set to be negatively correlated with the communication volume per unit time is used for calculation.

[0246] That is, when the APIGW 40 calculates the calculation amount, it adds the calculation amount weighted by the margin to the "calculation amount weighted by the margin" in the third statistical access log AL3 corresponding to the executed process. In addition, when the APIGW 40 calculates the power amount, it adds the power amount weighted by the margin to the "power amount weighted by the margin" in the fourth statistical access log AL4 corresponding to the executed process. In addition, when the APIGW 40 calculates the communication volume, it adds the communication volume weighted by the margin to the "communication volume weighted by the margin" in the fifth statistical access log AL5 corresponding to the executed process.

[0247] Next, a specific example of the calculation amount required for processing before passing detection data representing the detection results of sensors to a service application in a process corresponding to an API access request to an API (hereinafter referred to as a read system API) provided in the data system function block group 36 is described.

[0248] Assume that, by an API access request instructing execution of a process of detecting an obstacle around the vehicle, a detection result of an obstacle around the vehicle is transmitted to the service application.

[0249] When there are no obstacles around the vehicle, a small amount of calculation is recorded in the statistical access log. When there are many obstacles around the vehicle, a large amount of calculation is recorded in the statistical access log.

[0250] That is, the APIGW 40 adds the calculated calculation amount to the “total calculation amount” in the first statistical access log AL1 corresponding to the executed process, and adds it to the “calculation amount” in the third statistical access log AL3 corresponding to the executed process.

[0251] Next, a specific example of recording the type, number, and operation time of sensors used in the process corresponding to the API access request to the reading system API will be described.

[0252] Assume that, by an API access request instructing execution of a process of detecting an obstacle around the vehicle, a detection result of an obstacle around the vehicle is transmitted to the service application.

[0253] When surrounding obstacles are detected only by the front camera, it is recorded in the statistical access log that the front camera was used, one sensor was used, and the operating time.

[0254] When surrounding obstacles are detected by the front camera and the millimeter-wave radar, the use of the front camera and the millimeter-wave radar, the use of two sensors, and the operating time are recorded in the statistical access log.

[0255] When surrounding obstacles are detected by the front camera, millimeter-wave radar, and Lidar, the use of the front camera, millimeter-wave radar, and Lidar, the number of sensors used, and the operating time are recorded in the statistical access log.

[0256] When surrounding obstacles are detected by the front camera, millimeter-wave radar, Lidar and omnidirectional camera, the use of the front camera, millimeter-wave radar, Lidar and omnidirectional camera, the number of sensors used, and the working time are recorded in the statistical access log.

[0257] When surrounding obstacles are detected by the front camera, millimeter-wave radar, Lidar, omnidirectional camera and sonar, the use of the front camera, millimeter-wave radar, Lidar, omnidirectional camera and sonar, the number of sensors used, and the working time are recorded in the statistical access log.

[0258] That is, APIGW40 records the type and number of sensors used in the "number of ECUs that performed actions" in the first statistical access log AL1 corresponding to the executed process. In addition, APIGW40 adds the operating time of the used sensors to the "actuator / sensor operating time" in the second statistical access log AL2 corresponding to the executed process.

[0259] Next, a specific example of recording the types and numbers of ECUs or systems that cooperate in order to operate a sensor and process data in a process corresponding to an API access request for reading a system API will be described.

[0260] Assuming that the service application is configured in the cloud, the service application sends an API access request instructing the execution of the process of detecting obstacles around the vehicle to the API gateway 40. In this case, the cooperative action of the cloud system, the external communication device 7, the ECU 4, and the ECU 5 belonging to the domain of the vehicle body is recorded in the statistical access log.

[0261] In addition, assuming that the service application is configured in ECU 4, the service application sends an API access request instructing the execution of the process of detecting obstacles around the vehicle to API gateway 40. In this case, the cooperation action of ECU 4 and ECU 5 belonging to the vehicle body domain is recorded in the statistical access log.

[0262] In addition, assuming that a service application is provided in ECU 5 belonging to the vehicle body domain, the service application sends an API access request instructing execution of a process for detecting obstacles around the vehicle to API gateway 40. In this case, the statistical access log records that ECU 5 belonging to the vehicle body domain has performed an action.

[0263] That is, the APIGW 40 records the types and numbers of ECUs or systems that cooperate to process data in the “number of operated ECUs” and “number of operated external systems” in the first statistical access log AL1 corresponding to the executed process.

[0264] Next, a specific example of recording the amount of power consumed to operate a sensor and process data in a process corresponding to an API access request to a reading system API will be described.

[0265] Each time the execution of the processing corresponding to the API access request is completed normally, the power consumption of the system, ECU or sensor that performed the action related to the processing is recorded in the statistical access log. In the case where it is difficult to directly measure the power consumption, the power consumption is calculated based on the power table that pre-sets the power amount of each action for each of multiple systems, multiple ECUs or multiple sensors.

[0266] That is, the APIGW 40 adds the calculated power consumption amount to the “total power amount” in the first statistical access log AL1 corresponding to the executed process, and adds it to the “power amount” in the fourth statistical access log AL4 corresponding to the executed process.

[0267] Next, a specific example of recording the communication volume required for operating the sensor and processing the data in the process corresponding to the API access request to the reading system API will be described.

[0268] Each time the execution of the processing corresponding to the API access request is completed normally, the communication volume of the system, ECU or sensor that performed the action related to the processing is recorded in the statistical access log. In the case where it is difficult to directly measure the communication volume, the communication volume is calculated based on the communication volume table that pre-sets the communication volume of each action for each of multiple systems, multiple ECUs or multiple sensors. In addition, the communication volume is recorded for each type of communication line.

[0269] That is, the APIGW 40 adds the calculated communication volume to the “total communication volume” in the first statistical access log AL1 corresponding to the executed process, and adds it to the “communication volume” in the fifth statistical access log AL5 corresponding to the executed process.

[0270] In addition, the APIGW 40 calculates the weighted resource amount based on the amount of resources required to operate the sensor (ie, the amount of calculation, the amount of power, and the amount of communication) and the current system margin, and records the calculated weighted resource amount in the statistical access log.

[0271] That is, when the APIGW 40 calculates the calculation amount, it adds the calculation amount weighted by the margin to the "calculation amount weighted by the margin" in the third statistical access log AL3 corresponding to the executed process. In addition, when the APIGW 40 calculates the power amount, it adds the power amount weighted by the margin to the "power amount weighted by the margin" in the fourth statistical access log AL4 corresponding to the executed process. In addition, when the APIGW 40 calculates the communication volume, it adds the communication volume weighted by the margin to the "communication volume weighted by the margin" in the fifth statistical access log AL5 corresponding to the executed process.

[0272] like Fig. 9 As shown, the actuator operation type table TB11 is stored in the ROM 4 b of the ECU 4 .

[0273] The actuator operation type table TB11 associates at least one of a first operation type, a second operation type, a third operation type, a fourth operation type, a fifth operation type, and a sixth operation type with each of a plurality of actuators mounted on a vehicle.

[0274] The first action type means that the action is completed in a short time or the value is returned instantly.

[0275] The second action type indicates that an action is performed for a certain period of time.

[0276] The third action type indicates that the action is always performed.

[0277] The fourth action type indicates intermittent action or periodic action.

[0278] The fifth action type indicates that the amount of input and output data is variable.

[0279] The sixth action type indicates returning the result of the calculation process.

[0280] For example, the actuator of a siren is associated with the second motion type and the fourth motion type.

[0281] The door locking actuator is associated with the first action type.

[0282] The actuator for opening and closing the door is associated with the second action type.

[0283] The lighting actuator is associated with the second action type and the fourth action type.

[0284] The actuator of the air conditioner is associated with the third operation type. However, when the air conditioner is stopped, the actuator of the air conditioner is associated with the first operation type.

[0285] The audio actuator is associated with the fifth action type.

[0286] like Fig.10 As shown, the sensor operation type table TB12 is stored in the ROM 4 b of the ECU 4 .

[0287] The sensor operation type table TB12 associates at least one of a first operation type, a second operation type, a third operation type, a fourth operation type, a fifth operation type, and a sixth operation type with each of a plurality of sensors mounted on the vehicle.

[0288] For example, the tilt sensor is associated with the first motion type and the fourth motion type.

[0289] Sonar is associated with the second action type and the sixth action type.

[0290] The camera is associated with the first action type and the second action type.

[0291] The key operation sensor is associated with the first action type.

[0292] Next, the procedure of the log creation process according to the second embodiment will be described.

[0293] like Fig.11 As shown, the log creation process of the second embodiment is different from the first embodiment in that the processes of S72, S74, and S76 are added.

[0294] That is, when the processing of S70 is completed, in S72, APIGW40 determines whether the execution of the processing corresponding to the API access request is completed normally. Here, if the execution of the processing corresponding to the API access request is not completed normally, APIGW40 moves to S80. On the other hand, if the execution of the processing corresponding to the API access request is completed normally, in S74, APIGW40 performs the resource recording processing described later.

[0295] In S76 , the APIGW 40 executes an additional record process described later, and the process proceeds to S80 .

[0296] Next, the steps of the resource registration process executed in S74 will be described. The resource registration process is executed for each of the actuators and sensors used in executing the process corresponding to the API access request.

[0297] When performing resource record processing, such as Fig.12 As shown, in S110, APIGW 40 determines whether the actuator or sensor used in the execution of the process corresponding to the API access request has performed an action corresponding to the first action type. That is, APIGW 40 determines whether the actuator or sensor used completes the action in a short time or returns a value instantly.

[0298] Furthermore, when there is only one operation type associated with the actuator or sensor, the APIGW 40 determines whether the actuator or sensor in use has performed an operation corresponding to the first operation type based on the actuator operation type table TB11 or the sensor operation type table TB12 .

[0299] In addition, when there are multiple action types corresponding to the actuator or sensor, APIGW40 determines whether the actuator or sensor used has performed an action corresponding to the first action type based on the execution result of the processing corresponding to the API access request and the actuator action type table TB11 or the sensor action type table TB12.

[0300] Here, if the actuator or sensor used performs an action corresponding to the first action type, the APIGW 40 moves to S160. On the other hand, if the actuator or sensor used does not perform an action corresponding to the first action type, in S120, the APIGW 40 determines whether the actuator or sensor used in the execution of the process corresponding to the API access request performs an action corresponding to the fourth action type. That is, the APIGW 40 determines whether the actuator or sensor used performs an intermittent action or a periodic action.

[0301] Here, if the actuator or sensor used performs an action corresponding to the fourth action type, the APIGW 40 moves to S170. On the other hand, if the actuator or sensor used does not perform an action corresponding to the fourth action type, in S130, the APIGW 40 determines whether the actuator or sensor used in the execution of the process corresponding to the API access request performs an action corresponding to the second action type or the fifth action type.

[0302] Here, when the actuator or sensor used performs an action corresponding to the second action type or the fifth action type, in S140, APIGW 40 determines whether the actuator or sensor used performs an action corresponding to the fifth action type. That is, APIGW 40 determines whether the input and output data volume is variable.

[0303] Here, if the actuator or sensor in use does not perform an operation corresponding to the fifth operation type, the APIGW 40 proceeds to S170 . On the other hand, if the actuator or sensor in use performs an operation corresponding to the fifth operation type, the APIGW 40 proceeds to S180 .

[0304] In addition, in S130, when the actuator or sensor used does not perform an action corresponding to the second action type or the fifth action type, in S150, the APIGW 40 determines whether the actuator or sensor used performs an action corresponding to the third action type. That is, the APIGW 40 determines whether the actuator or sensor continues to operate after the processing corresponding to the API access request is completed.

[0305] Here, if the actuator or sensor in use does not perform an operation corresponding to the third operation type, the APIGW 40 proceeds to S170 . On the other hand, if the actuator or sensor in use performs an operation corresponding to the third operation type, the APIGW 40 proceeds to S190 .

[0306] When the process moves to S160, APIGW40 calculates the amount of resources required for one action and adds it to the statistical access log. In addition, in S160, APIGW40 calculates the weighted amount of resources and adds it to the statistical access log. The amount of resources is the amount of calculation, the amount of electricity, and the amount of communication. When the process of S160 is completed, APIGW40 moves to S200.

[0307] When the process moves to S170, the APIGW 40 adds the value obtained by multiplying the resource amount required per unit data amount by the data amount to the statistical access log. In addition, in S170, the APIGW 40 calculates the weighted resource amount and adds it to the statistical access log. When the process of S170 is completed, the APIGW 40 moves to S200.

[0308] When the process moves to S180, APIGW 40 adds the value obtained by multiplying the amount of resources required per unit time by the action time and the action time ratio to the statistical access log. In addition, in S180, APIGW 40 calculates the weighted amount of resources and adds it to the statistical access log. When the process of S180 is completed, APIGW 40 moves to S200.

[0309] When the process moves to S190, the APIGW 40 adds the value obtained by multiplying the amount of resources required per unit time by the estimated operation time to the statistical access log. In addition, in S190, the APIGW 40 calculates the weighted amount of resources and adds it to the statistical access log. When the process of S190 is completed, the APIGW 40 moves to S200.

[0310] When the process moves to S200 , the APIGW 40 determines whether the actuator or sensor in use has performed an operation corresponding to the sixth operation type. In other words, the APIGW 40 determines whether a calculation process is required in the actuator or sensor in use.

[0311] Here, if the actuator or sensor used does not perform an action corresponding to the sixth action type, APIGW40 ends the resource record processing. On the other hand, if the actuator or sensor used performs an action corresponding to the sixth action type, in S210, APIGW40 adds the value obtained by multiplying the resource amount required per unit of computation amount by the computation amount to the statistical access log. In addition, in S210, APIGW40 calculates the weighted resource amount and adds it to the statistical access log. When the processing of S210 ends, APIGW40 ends the resource record processing.

[0312] Next, the procedure of the additional recording process executed in S76 will be described. The additional recording process is executed for each of the actuators and sensors used in the execution of the process corresponding to the API access request.

[0313] When performing additional record processing, such as Fig.13 As shown, in S310 , the APIGW 40 records the type and number of actuators that have been operated in the process corresponding to the API access request.

[0314] In S320 , the APIGW 40 records the types and numbers of ECUs or systems that cooperate in order to operate the actuators in the process corresponding to the API access request.

[0315] In S330 , the APIGW 40 records the type, number, and operation time of the sensors used in the process corresponding to the API access request.

[0316] In S340 , the APIGW 40 records the types and numbers of ECUs or systems that cooperate in order to operate the sensor and process the data in the process corresponding to the API access request, and ends the additional recording process.

[0317] The application store 15 of the server 3 calculates the API usage fee by multiplying the first, second, third, fourth, and fifth statistical access logs AL1, AL2, AL3, AL4, and AL5 obtained from the APIGW 40 by the corresponding coefficient for each item (i.e., the number of times, the amount of data, the amount of resources, the quantity, and the time). In addition, the coefficient varies for each item and also for each API.

[0318] The service providing system 1 configured in this manner includes a vehicle control system 2 and a server 3 .

[0319] The vehicle control system 2 is mounted on the vehicle. The vehicle control system 2 includes vehicle-mounted devices 4 to 7 connected to an in-vehicle communication network 8. The server 3 is configured to be able to perform data communication with the vehicle control system 2.

[0320] The vehicle control system 2 includes an API gateway 40. The API gateway 40 is configured to realize the collaboration between the service system function block group 33, the control system function block group 35, and the data system function block group 36. The service system function block group 33 is configured to provide services to the vehicle, and the control system function block group 35 and the data system function block group 36 are configured to execute predetermined processing in the vehicle.

[0321] The control system function block group 35 includes an API group 37. The data system function block group 36 includes an API group 38. The API groups 37 and 38 are configured to convert an API access request expressed in a vehicle-independent format and transmitted from the service system function block group 33 into a vehicle-dependent format.

[0322] The API gateway 40 is configured to transfer the API access request transmitted from the service system function block group 33 to the control system function block group 35 and the data system function block group 36 .

[0323] The API gateway 40 is configured to create a first statistical access log AL1 based on the execution status of the API access request by the vehicle-mounted devices 4 to 7 .

[0324] The server 3 is configured to calculate the API usage fee generated by the service system function block group 33 using the API group 37 and 38 using the first statistical access log AL1 created by the API gateway 40 .

[0325] Such a service providing system 1 can calculate the API usage fee using the number of times and the communication data volume included in the first statistical access log AL1. Therefore, the service providing system 1 can charge the service provider SV that provides the service to the vehicle.

[0326] In addition, the API gateway 40 is configured to produce first, second, third, fourth, and fifth statistical access logs AL1, AL2, AL3, AL4, and AL5 for recording resource consumption information, which is related to resources consumed in processing corresponding to API access requests for API groups 37 and 38 possessed by the control system function block group 35 and the data system function block group 36.

[0327] The resource consumption information includes the amount of calculation required to operate the actuator and the amount of calculation required for processing until the detection data indicating the detection result of the sensor is transmitted to the service system function block group 33 .

[0328] The resource consumption information includes the type and number of actuators that have been operated, and the type, number, and operating time of sensors that have been used.

[0329] The resource consumption information includes the types and numbers of a plurality of ECUs or systems that cooperate to operate the actuators, and the types and numbers of a plurality of ECUs or systems that cooperate to operate the sensors and process the data.

[0330] The resource consumption information includes the amount of electric power consumed to operate the actuator and the amount of electric power consumed to operate the sensor and process data.

[0331] The resource consumption information includes the communication volume required to operate the actuator and the communication volume required to operate the sensor and process the data.

[0332] The server 3 is configured to calculate the API usage fee using the first to fifth statistical access logs AL1 to AL5 created by the API gateway 40 .

[0333] Such a service providing system 1 can calculate the API usage fee corresponding to the consumed resources. Therefore, the service providing system 1 can prevent the situation where the API usage fee is the same even though the consumed resources are different, and can reduce the sense of unfairness in the charges of the service provider SV.

[0334] The server 3 is configured to change the weight of the resource consumption information according to the API and calculate the API usage fee. Such a service providing system 1 can charge appropriately according to the API.

[0335] The server 3 is configured to calculate the API usage fee by changing the weight of the resource consumption information according to the resource margin at the time of resource consumption. Such a service providing system 1 can give the service provider SV an incentive to use the API when the resource margin is large, thereby preventing the resource margin from decreasing.

[0336] In the above-described embodiment, S74 and S76 correspond to the processing as the resource recording unit, and the first to fifth statistical access logs AL1 to AL5 correspond to the resource access logs.

[0337] As mentioned above, although one embodiment of the present disclosure has been described, the present disclosure is not limited to the above-mentioned embodiment, and can be implemented with various modifications.

[0338] [Modification 1]

[0339] In the above embodiment, the method of recording the amount of calculation, power, and communication weighted by the margin is shown, but the amount of consumed resources and the margin of the resources at the time of consumption may be associated and recorded.

[0340] The ECU4 and its method described in the present disclosure may also be implemented by a special-purpose computer, which is provided by a processor and a memory programmed to execute one or more functions embodied by a computer program. Alternatively, the ECU4 and its method described in the present disclosure may also be implemented by a special-purpose computer, which is provided by a processor composed of one or more special-purpose hardware logic circuits. Alternatively, the ECU4 and its techniques and methods described in the present disclosure may also be implemented by one or more special-purpose computers, which are composed of a combination of a processor and a memory programmed to execute one or more functions and a processor composed of one or more hardware logic circuits. In addition, a computer program may also be stored in a computer-readable non-transitional tangible recording medium as an instruction executed by a computer. The method for implementing the functions of each part included in the ECU4 does not necessarily include software, and all of its functions may be implemented using one or more hardware.

[0341] It is also possible to realize multiple functions of one constituent element in the above-mentioned embodiment by multiple constituent elements, or realize one function of one constituent element by multiple constituent elements. In addition, it is also possible to realize multiple functions of multiple constituent elements by one constituent element, or realize one function realized by multiple constituent elements by one constituent element. In addition, it is also possible to omit a part of the structure of the above-mentioned embodiment. In addition, it is also possible to add or replace at least a part of the structure of the above-mentioned embodiment with the structure of other above-mentioned embodiment.

[0342] In addition to the above-mentioned ECU4, the present disclosure may be implemented in various forms such as a system having the ECU4 as a component, a program for causing a computer to function as the ECU4, a non-transitory physical recording medium such as a semiconductor memory recording the program, and a service providing method.

[0343] [Technical ideas disclosed in this specification]

[0344] [Project 1]

[0345] A service providing system (1), comprising:

[0346] A vehicle control system (2) includes a plurality of electronic control devices (4-7) mounted on a vehicle and connected to an on-vehicle network (8); and

[0347] A server (3) is configured to be able to communicate data with the vehicle control system.

[0348] The vehicle control system comprises a cooperation control unit (40) configured to realize cooperation between a service system function block (33) and function blocks (35, 36), wherein the service system function block is configured to provide a service to the vehicle, and the function block is configured to execute a predetermined process in the vehicle.

[0349] The functional block includes a functional interface (37, 38) configured to convert an access request sent from the service system functional block in a vehicle-independent form into a vehicle-dependent form.

[0350] The above-mentioned cooperative control unit has:

[0351] A request forwarding unit (S40) configured to forward the access request sent from the service system function block to the control system function block; and

[0352] an access log generating unit (S70) configured to generate an access log including at least one of the number of times the service system function block uses the function interface and the amount of communication data generated by the service system function block using the function interface, based on the execution status of the access request by the plurality of electronic control devices;

[0353] The server is configured to calculate an interface usage fee generated by the service system function block using the function interface, using the access log created by the cooperation control unit.

[0354] [Project 2]

[0355] The service providing system described in item 1, wherein:

[0356] The interface utilization count includes the number of times the plurality of electronic control devices execute and complete the processing corresponding to the access request, ie, the execution completion count.

[0357] [Item 3]

[0358] The service providing system described in item 1 or item 2, wherein:

[0359] The number of interface utilizations includes the number of times that the plurality of electronic control devices do not need to execute processing corresponding to the access request, that is, the number of unnecessary executions.

[0360] [Item 4]

[0361] The service providing system according to any one of items 1 to 3, wherein:

[0362] The interface utilization count includes the number of times the plurality of electronic control devices cannot execute processing corresponding to the access request due to occurrence of an abnormality, that is, the execution abnormality count.

[0363] [Item 5]

[0364] The service providing system according to any one of items 1 to 4, wherein:

[0365] The number of interface utilizations includes the number of times that the plurality of electronic control devices execute and complete processing corresponding to the access request in each of a plurality of vehicle states of the vehicle equipped with the vehicle control system.

[0366] [Item 6]

[0367] The service providing system according to any one of items 1 to 5, wherein:

[0368] The communication data volume includes a cumulative value of the data volume acquired by the service system function block due to the plurality of electronic control devices executing processes corresponding to the access requests.

[0369] [Item 7]

[0370] A server (3), comprising:

[0371] A communication unit (12) configured to perform data communication with a vehicle control system (2), the vehicle control system comprising a plurality of electronic control devices (4-7) mounted on a vehicle and connected to an on-vehicle network (8), and further comprising a functional interface (37, 38) configured to convert an access request expressed in a form independent of the vehicle into a form dependent on the vehicle when receiving an access request expressed in a form independent of the vehicle from a service system functional block (33) configured to provide a service to the vehicle equipped with the plurality of electronic control devices; and

[0372] A charge calculation unit (15) is configured to use the access log to calculate the interface usage fee generated by the service system function block using the function interface when receiving the access log from the vehicle control system, wherein the access log is generated based on the execution status of the access request by the multiple electronic control devices to include at least one of the number of times the service system function block uses the function interface and the amount of communication data generated by the service system function block using the function interface.

[0373] [Item 8]

[0374] A vehicle-mounted device is a vehicle-mounted device (4) mounted on a vehicle and connected to a plurality of electronic control devices (5 to 7) via an on-vehicle network (8), wherein the device comprises:

[0375] A functional interface (37, 38) configured to convert an access request expressed in a vehicle-independent form into a vehicle-dependent form when receiving an access request expressed in a vehicle-independent form from a service system functional block (33) configured to provide a service to a vehicle equipped with the vehicle-mounted device;

[0376] an access log creating unit (S70) configured to create an access log including at least one of the number of times the service system function block uses the function interface and the amount of communication data generated by the service system function block using the function interface, based on the execution status of the access request by the plurality of electronic control devices; and

[0377] The log sending unit (S90) is configured to send the access log to a server (3) installed outside the vehicle-mounted device.

[0378] [Item 9]

[0379] The vehicle-mounted device according to item 8, comprising:

[0380] Function blocks (35, 36) are configured to include the above-mentioned functional interface and to execute predetermined processing in the above-mentioned vehicle; and

[0381] A cooperation control unit (40) is configured to realize cooperation between the service system function block and the function block.

[0382] The cooperation control unit includes the access log creating unit.

[0383] [Item 10]

[0384] A service providing method is a service providing method executed by a service providing system (1) having a vehicle control system (2) and a server (3), wherein the vehicle control system has a plurality of electronic control devices (4-7) mounted on a vehicle and connected to an in-vehicle network (8), and the server is configured to be able to perform data communication with the vehicle control system, wherein:

[0385] The vehicle control system comprises a cooperation control unit (40) configured to realize cooperation between a service system function block (33) and function blocks (35, 36), wherein the service system function block is configured to provide a service to the vehicle, and the function block is configured to execute a predetermined process in the vehicle.

[0386] The functional block includes a functional interface (37, 38) configured to convert an access request sent from the service system functional block in a vehicle-independent form into a vehicle-dependent form.

[0387] The cooperation control unit transfers the access request sent from the service system function block to the function block.

[0388] The collaborative control unit generates an access log including at least one of the number of times the service system function block utilizes the function interface and the amount of communication data generated by the service system function block utilizing the function interface based on the execution status of the access request by the plurality of electronic control devices.

[0389] The server calculates an interface usage fee generated by the service system function block using the function interface, using the access log created by the cooperation control unit.

[0390] [Item 11]

[0391] A service provider that enables a computer to function as:

[0392] A communication unit (12) configured to perform data communication with a vehicle control system (2), the vehicle control system comprising a plurality of electronic control devices (4-7) mounted on a vehicle and connected to an on-vehicle network (8), and further comprising a functional interface (37, 38) configured to convert an access request expressed in a form independent of the vehicle into a form dependent on the vehicle when receiving an access request expressed in a form independent of the vehicle from a service system functional block (33) configured to provide a service to the vehicle equipped with the plurality of electronic control devices; and

[0393] A charge calculation unit (15) is configured to use the access log to calculate the interface usage fee generated by the service system function block using the function interface when receiving the access log from the vehicle control system, wherein the access log is generated based on the execution status of the access request by the multiple electronic control devices to include at least one of the number of times the service system function block uses the function interface and the amount of communication data generated by the service system function block using the function interface.

[0394] [Item 12]

[0395] A service providing method is a service providing method executed by a server of a service providing system (1) having a vehicle control system (2) and a server (3), wherein the vehicle control system has a plurality of electronic control devices (4-7) mounted on a vehicle and connected to an on-board network (8), and further has a functional interface (37, 38) configured to convert an access request expressed in a form independent of the vehicle into a form dependent on the vehicle when receiving an access request expressed in a form independent of the vehicle from a service system functional block (33) configured to provide services to a vehicle equipped with the plurality of electronic control devices, wherein the server is configured to be able to perform data communication with the vehicle control system, wherein:

[0396] The server communicates data with the vehicle control system.

[0397] When the server receives the access log from the vehicle control system, it uses the access log to calculate the interface usage fee generated by the service system function block using the function interface. The access log is prepared based on the execution status of the access request by the multiple electronic control devices to include at least one of the number of times the service system function block uses the function interface and the amount of communication data generated by the service system function block using the function interface.

[0398] [Item 13]

[0399] A service providing program for causing a computer of an on-vehicle device (4) mounted on a vehicle and connected to a plurality of electronic control devices (5 to 7) via an on-vehicle network (8) to function as the following components:

[0400] A functional interface (37, 38) configured to convert an access request expressed in a vehicle-independent form into a vehicle-dependent form when receiving an access request expressed in a vehicle-independent form from a service system functional block (33) configured to provide a service to a vehicle equipped with the vehicle-mounted device;

[0401] an access log creating unit (S70) configured to create an access log including at least one of the number of times the service system function block uses the function interface and the amount of communication data generated by the service system function block using the function interface, based on the execution status of the access request by the plurality of electronic control devices; and

[0402] The log sending unit (S90) is configured to send the access log to a server (3) installed outside the vehicle-mounted device.

[0403] [Item 14]

[0404] A service providing method is a service providing method executed by an on-vehicle device (4) mounted on a vehicle and connected to a plurality of electronic control devices (5 to 7) via an on-vehicle network (8), wherein:

[0405] The vehicle-mounted device comprises a functional interface (37, 38) configured to convert the access request into a vehicle-dependent form when receiving an access request expressed in a vehicle-independent form from a service system functional block (33) configured to provide a service to a vehicle equipped with the vehicle-mounted device.

[0406] The vehicle-mounted device generates an access log including at least one of the number of times the service system function block utilizes the function interface and the amount of communication data generated by the service system function block utilizing the function interface based on the execution status of the access request by the plurality of electronic control devices.

[0407] The vehicle-mounted device transmits the access log to a server (3) installed outside the vehicle-mounted device.

[0408] [Item 15]

[0409] The service providing system according to any one of items 1 to 6, wherein:

[0410] The collaboration control unit further includes a resource recording unit (S74, S76), the resource recording unit being configured to create a resource access log (AL1 to AL5) recording resource consumption information related to resources consumed in the processing corresponding to the access request to the functional interface of the functional block,

[0411] The server is configured to calculate the interface usage fee using the resource access log created by the cooperation control unit.

[0412] [Item 16]

[0413] The service provision system described in item 15, wherein:

[0414] The resource consumption information is included in the processing corresponding to the access request to the functional interface possessed by the functional block, including at least one of the amount of calculation required to actuate the actuator and the amount of calculation required to process the detection data representing the detection result of the sensor to the service system functional block.

[0415] [Item 17]

[0416] The service providing system described in item 15 or item 16, wherein:

[0417] The resource consumption information includes at least one of the type and number of actuators that have been operated and the type, number, and operating time of sensors that have been used in the process corresponding to the access request to the function interface of the function block.

[0418] [Item 18]

[0419] The service providing system described in any one of items 15 to 17, wherein:

[0420] The resource consumption information is included in the processing corresponding to the access request to the functional interface possessed by the functional block, including at least one of the types and numbers of the multiple electronic control devices or systems that cooperate to operate the actuator, and the types and numbers of the multiple electronic control devices or systems that cooperate to operate the sensor and process data.

[0421] [Item 19]

[0422] The service providing system described in any one of items 15 to 18, wherein:

[0423] The resource consumption information includes at least one of an amount of power consumed to operate an actuator and an amount of power consumed to operate a sensor and process data in the process corresponding to the access request to the function interface provided in the function block.

[0424] [Item 20]

[0425] The service providing system described in any one of items 15 to 19, wherein:

[0426] The resource consumption information includes at least one of a communication amount required to operate an actuator and a communication amount required to operate a sensor and process data in the process corresponding to the access request to the functional interface provided in the functional block.

[0427] [Item 21]

[0428] The service providing system described in any one of items 15 to 20, wherein:

[0429] The server is configured to change the weight of the resource consumption information according to the functional interface and calculate the interface usage fee.

[0430] [Item 22]

[0431] The service providing system described in any one of items 15 to 21, wherein:

[0432] The server is configured to calculate the interface usage fee by changing a weight for the resource consumption information according to a margin of the resource at a time when the resource is consumed.

Claims

1. A service providing system (1), wherein: have: A vehicle control system (2) includes a plurality of electronic control devices (4-7) mounted on a vehicle and connected to an on-vehicle network (8); and A server (3) is configured to be able to communicate data with the vehicle control system. The vehicle control system comprises a cooperation control unit (40) configured to realize cooperation between a service system function block (33) and function blocks (35, 36), wherein the service system function block is configured to provide a service to the vehicle, and the function block is configured to execute a predetermined process in the vehicle. The functional block includes a functional interface (37, 38) configured to convert an access request sent from the service system functional block in a vehicle-independent form into a vehicle-dependent form. The above-mentioned cooperative control unit has: A request forwarding unit (S40) configured to forward the access request sent from the service system functional block to the functional block; and an access log generating unit (S70) configured to generate an access log based on the execution status of the access request by the plurality of electronic control devices, the access log including at least one of the number of times the service system function block uses the function interface and the amount of communication data generated by the service system function block using the function interface, The server is configured to calculate an interface usage fee generated by the service system function block using the function interface, using the access log created by the cooperation control unit.

2. The service providing system according to claim 1, wherein: The interface utilization count includes the number of times the plurality of electronic control devices execute and complete the processing corresponding to the access request, ie, the execution completion count.

3. The service providing system according to claim 1 or 2, wherein: The number of interface utilizations includes the number of times that the plurality of electronic control devices do not need to execute processing corresponding to the access request, that is, the number of unnecessary executions.

4. The service providing system according to claim 1 or 2, wherein: The interface utilization count includes the number of times the plurality of electronic control devices cannot execute processing corresponding to the access request due to occurrence of an abnormality, that is, the execution abnormality count.

5. The service providing system according to claim 1 or 2, wherein: The number of interface utilizations includes the number of times the plurality of electronic control devices execute and complete processing corresponding to the access request in each of a plurality of vehicle states of the vehicle equipped with the vehicle control system.

6. The service providing system according to claim 1 or 2, wherein: The communication data volume includes a cumulative value of the data volume acquired by the service system function block due to the plurality of electronic control devices executing processes corresponding to the access requests.

7. A server (3), wherein: have: A communication unit (12) configured to perform data communication with a vehicle control system (2), the vehicle control system comprising a plurality of electronic control devices (4-7) mounted on a vehicle and connected to an on-board network (8), and further comprising a functional interface (37, 38) configured to convert an access request expressed in a form independent of the vehicle into a form dependent on the vehicle when receiving an access request expressed in a form independent of the vehicle from a service system functional block (33) configured to provide a service to the vehicle equipped with the plurality of electronic control devices; as well as A charge calculation unit (15) is configured to use the access log to calculate the interface usage fee generated by the service system function block using the function interface when receiving the access log from the vehicle control system, wherein the access log is generated based on the execution status of the access request by the multiple electronic control devices to include at least one of the number of times the service system function block uses the function interface and the amount of communication data generated by the service system function block using the function interface.

8. A vehicle-mounted device, which is a vehicle-mounted device (4) mounted on a vehicle and connected to a plurality of electronic control devices (5 to 7) via a vehicle-mounted network (8), wherein: have: A functional interface (37, 38) configured to convert an access request expressed in a vehicle-independent form into a vehicle-dependent form when receiving an access request expressed in a vehicle-independent form from a service system functional block (33) configured to provide a service to a vehicle equipped with the vehicle-mounted device; an access log creating unit (S70) configured to create an access log including at least one of the number of times the service system function block uses the function interface and the amount of communication data generated by the service system function block using the function interface, based on the execution status of the access request by the plurality of electronic control devices; and The log sending unit (S90) is configured to send the access log to a server (3) installed outside the vehicle-mounted device.

9. The vehicle-mounted device according to claim 8, wherein: have: Function blocks (35, 36) are configured to include the above-mentioned functional interface and to execute predetermined processing in the above-mentioned vehicle; and A cooperation control unit (40) is configured to realize cooperation between the service system function block and the function block. The cooperation control unit includes the access log creating unit.

10. A service providing method, the method being executed by a service providing system (1) having a vehicle control system (2) and a server (3), the vehicle control system having a plurality of electronic control devices (4 to 7) mounted on a vehicle and connected to an in-vehicle network (8), the server being configured to be able to perform data communication with the vehicle control system, wherein: The vehicle control system comprises a cooperation control unit (40) configured to realize cooperation between a service system function block (33) and function blocks (35, 36), wherein the service system function block is configured to provide a service to the vehicle, and the function block is configured to execute a predetermined process in the vehicle. The functional block includes a functional interface (37, 38) configured to convert an access request sent from the service system functional block in a vehicle-independent form into a vehicle-dependent form. The cooperation control unit transfers the access request sent from the service system function block to the function block. The collaborative control unit generates an access log including at least one of the number of times the service system function block utilizes the function interface and the amount of communication data generated by the service system function block utilizing the function interface based on the execution status of the access request by the plurality of electronic control devices. The server calculates an interface usage fee generated by the service system function block using the function interface, using the access log created by the cooperation control unit.

11. A service provider for causing a computer to function as: A communication unit (12) configured to perform data communication with a vehicle control system (2), the vehicle control system comprising a plurality of electronic control devices (4-7) mounted on a vehicle and connected to an on-vehicle network (8), and further comprising a functional interface (37, 38) configured to convert an access request expressed in a form independent of the vehicle into a form dependent on the vehicle when receiving an access request expressed in a form independent of the vehicle from a service system functional block (33) configured to provide a service to the vehicle equipped with the plurality of electronic control devices; and A charge calculation unit (15) is configured to use the access log to calculate the interface usage fee generated by the service system function block using the function interface when receiving the access log from the vehicle control system, wherein the access log is generated based on the execution status of the access request by the multiple electronic control devices to include at least one of the number of times the service system function block uses the function interface and the amount of communication data generated by the service system function block using the function interface.

12. A service providing method, the method being executed by the server of a service providing system (1) having a vehicle control system (2) and a server (3), the vehicle control system having a plurality of electronic control devices (4-7) mounted on a vehicle and connected to an on-board network (8), and further comprising a functional interface (37, 38) configured to convert an access request expressed in a form independent of the vehicle into a form dependent on the vehicle when receiving an access request expressed in a form independent of the vehicle from a service system functional block (33) configured to provide services to a vehicle equipped with the plurality of electronic control devices, the server being configured to be able to perform data communication with the vehicle control system, wherein: The server communicates data with the vehicle control system. When the server receives the access log from the vehicle control system, it uses the access log to calculate the interface usage fee generated by the service system function block using the function interface. The access log is prepared based on the execution status of the access request by the multiple electronic control devices to include at least one of the number of times the service system function block uses the function interface and the amount of communication data generated by the service system function block using the function interface.

13. A service providing program for causing a computer of an on-vehicle device (4) mounted on a vehicle and connected to a plurality of electronic control devices (5 to 7) via an on-vehicle network (8) to function as the following components: A functional interface (37, 38) configured to convert an access request expressed in a vehicle-independent form into a vehicle-dependent form when receiving an access request expressed in a vehicle-independent form from a service system functional block (33) configured to provide a service to a vehicle equipped with the vehicle-mounted device; an access log creating unit (S70) configured to create an access log including at least one of the number of times the service system function block uses the function interface and the amount of communication data generated by the service system function block using the function interface, based on the execution status of the access request by the plurality of electronic control devices; and The log sending unit (S90) is configured to send the access log to a server (3) installed outside the vehicle-mounted device.

14. A service providing method, which is executed by an on-vehicle device (4) mounted on a vehicle and connected to a plurality of electronic control devices (5 to 7) via an on-vehicle network (8), wherein: The vehicle-mounted device comprises a functional interface (37, 38) configured to convert the access request into a vehicle-dependent form when receiving an access request expressed in a vehicle-independent form from a service system functional block (33) configured to provide a service to a vehicle equipped with the vehicle-mounted device. The vehicle-mounted device generates an access log including at least one of the number of times the service system function block utilizes the function interface and the amount of communication data generated by the service system function block utilizing the function interface based on the execution status of the access request by the plurality of electronic control devices. The vehicle-mounted device transmits the access log to a server (3) installed outside the vehicle-mounted device.

15. The service providing system according to claim 1 or 2, wherein: The collaboration control unit further includes a resource recording unit (S74, S76), the resource recording unit being configured to create a resource access log (AL1 to AL5) recording resource consumption information related to resources consumed in the processing corresponding to the access request to the functional interface of the functional block, The server is configured to calculate the interface usage fee using the resource access log created by the cooperation control unit.

16. The service providing system according to claim 15, wherein: The resource consumption information is included in the processing corresponding to the access request to the functional interface possessed by the functional block, including at least one of the amount of calculation required to actuate the actuator and the amount of calculation required to process the detection data representing the detection result of the sensor to the service system functional block.

17. The service providing system according to claim 15, wherein: The resource consumption information includes at least one of the type and number of actuators that have been operated and the type, number, and operating time of sensors that have been used in the process corresponding to the access request to the function interface of the function block.

18. The service providing system according to claim 15, wherein: The resource consumption information is included in the processing corresponding to the access request to the functional interface possessed by the functional block, including at least one of the types and numbers of the multiple electronic control devices or systems that cooperate to operate the actuator, and the types and numbers of the multiple electronic control devices or systems that cooperate to operate the sensor and process data.

19. The service providing system according to claim 15, wherein: The resource consumption information includes at least one of an amount of power consumed to operate an actuator and an amount of power consumed to operate a sensor and process data in the process corresponding to the access request to the function interface provided in the function block.

20. The service providing system according to claim 15, wherein: The resource consumption information includes at least one of a communication amount required to operate an actuator and a communication amount required to operate a sensor and process data in the process corresponding to the access request to the functional interface provided in the functional block.

21. The service providing system according to claim 15, wherein: The server is configured to change the weight of the resource consumption information according to the functional interface and calculate the interface usage fee.

22. The service providing system according to claim 15, wherein: The server is configured to calculate the interface usage fee by changing a weight for the resource consumption information according to a margin of the resource at a time when the resource is consumed.

Images