API evaluation system and program

Abstract

An information acquisition unit (S410-S420) acquires API access logs each indicating the usage status of API in accordance with a request from an application installed in a vehicle. A sales-related index generation unit (S480-S490) generates a sales-related index in accordance with a log aggregation value which is a result of aggregating the API access logs for each type of API and for each vehicle classification in which vehicles are classified by vehicle sales data. The sales-related index is an API index indicating the magnitude of the influence of the API on a user of the vehicle and on the application. An output unit (S510) outputs the sales-related index.

Description

API evaluation system and program CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] The present disclosure relates to techniques for evaluating APIs.

[0003] Japanese Patent Application Laid-Open No. 2003-124993 discloses a technique for extracting the location of incompatibility between an application and a platform, and providing a method for resolving the incompatibility.

[0004] JP 2013-164879 A

[0005] Vehicle functions are provided via an application programming interface (API). APIs are updated as needed to accommodate changes in the configuration of sensors, actuators, ECUs, etc. that implement the functions, to accommodate an increase in the number of supported OEMs and vehicle models, and to improve usability. It is desirable for the updated APIs to be backward compatible so that they can be used without making changes to existing applications.

[0006] However, maintaining backward compatibility for all APIs requires a huge amount of work, so it is necessary to develop APIs efficiently by appropriately selecting APIs that maintain backward compatibility.

[0007] It has been found that the conventional technology only provides information for resolving incompatibility, but is unable to determine whether or not it is really necessary to maintain compatibility.

[0008] One aspect of the present disclosure provides techniques for evaluating APIs for maintaining backward compatibility.

[0009] One aspect of the present disclosure is an API evaluation system comprising an information acquisition unit, a sales-related index generation unit, and an output unit. The information acquisition unit acquires API access logs representing usage status of APIs, which are interfaces for providing vehicle functions in accordance with requests from applications installed in a vehicle. The sales-related index generation unit generates sales-related indexes according to log aggregation values, which are results of aggregating API access logs, for each vehicle category that classifies vehicles based on vehicle sales data related to vehicle sales and for each API type. The sales-related indexes are API indexes that represent the magnitude of the impact that the APIs have on users of the applications and the vehicle. The output unit outputs the sales-related indexes.

[0010] With this configuration, APIs that should be prioritized in terms of maintaining backward compatibility can be selected using the generated sales-related indexes, allowing for efficient API development.

[0011] One aspect of the present disclosure is an API evaluation system comprising an access log storage unit, a sales data storage unit, an information acquisition unit, a sales-related index generation unit, and an output unit. The access log storage unit collects and stores API access logs from a vehicle, representing usage status of APIs, which are interfaces for providing vehicle functions in accordance with requests from applications installed in the vehicle. The sales data storage unit stores vehicle sales data related to vehicle sales. The information acquisition unit acquires the API access logs and vehicle sales data from the access log storage unit and the sales data storage unit. The sales-related index generation unit generates sales-related indexes according to log aggregation values, which are the results of aggregating API access logs for each vehicle category obtained by classifying vehicles based on the vehicle sales data and for each API type. The sales-related indexes are API indexes that represent the magnitude of the impact that an API has on users of the application and the vehicle. The output unit outputs the sales-related indexes.

[0012] With this configuration, APIs that should be prioritized in terms of maintaining backward compatibility can be selected using the generated sales-related indexes, allowing for efficient API development.

[0013] One aspect of the present disclosure is a program that causes a computer to function as an information acquisition unit, a sales-related index generation unit, and an output unit.

[0014] By executing such a program, it is possible to obtain the same effect as the API evaluation system described above.

[0015] 1 is a block diagram showing a hardware configuration of an API evaluation system; 2 is a block diagram showing a functional configuration of the API evaluation system; 3 is an explanatory diagram showing the contents of an application operation log; 4 is a flowchart of an application log management process; 5 is an explanatory diagram showing the contents of an API access log; 6 is a flowchart of an API log management process; 7 is an explanatory diagram showing the contents of application information managed in an application store; 8 is an explanatory diagram showing the contents of information representing the impact on security-protected assets managed in an application store; 9 is an explanatory diagram showing an API access log with additional information accumulated in an application store; 10 is an explanatory diagram showing the contents of vehicle sales data managed in a vehicle sales DB; 11 is a flowchart of an API index calculation process; 12 is an explanatory diagram of basic API indexes; 13 is an explanatory diagram showing a method of aggregating API access logs used when calculating an API index taking into account application usage; 14 is an explanatory diagram showing an example of calculating an API index taking into account the number of application downloads; 15 is an explanatory diagram showing an example of calculating an API index taking into account application evaluation; 16 is an explanatory diagram showing a method of aggregating API access logs used when calculating an API index taking into account vehicle sales data; 17 is an explanatory diagram showing an example of calculating an API index taking into account vehicle sales data; 18 is an explanatory diagram showing an example of calculating an API index taking into account the impact on security-protected assets;

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

[0017] [1. Configuration] As shown in FIG. 1 , the API evaluation system 1 of this embodiment includes an in-vehicle system 100 mounted on a vehicle, an app store 200, a vehicle sales DB 300, and a terminal device 400. DB stands for database. The vehicle may have an automatic driving function in addition to a manual driving function. The vehicle may be a hybrid vehicle having an engine and an electric motor as a driving source. The vehicle is not limited to a vehicle having an automatic driving function or a hybrid vehicle, but may 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. Hereinafter, a vehicle equipped with the in-vehicle system 100 will be simply referred to as a vehicle.

[0018] The in-vehicle system 100 includes one electronic control unit (hereinafter referred to as ECU) 2, a plurality of ECUs 3, a plurality of ECUs 4, an external communication device 5, and an internal communication network 6. ECU is an abbreviation for Electronic Control Unit.

[0019] The ECU 2 controls a plurality of ECUs 3 to realize coordinated control of the entire vehicle.

[0020] An ECU 3 is provided for each domain, which is divided according to the vehicle's functions, and mainly controls the multiple ECUs 4 present within that domain. Each ECU 3 is connected to its subordinate ECUs 4 via a lower-layer network that is individually provided for each ECU 3. The lower-layer network may be, for example, a Controller Area Network (hereinafter, CAN). CAN is a registered trademark. The ECU 3 has the function of centrally managing access rights and the like for the subordinate ECUs 4 and authenticating users. The domains may be, for example, a powertrain, a body, a chassis, a cockpit, etc.

[0021] The ECUs 4 connected to the ECU 3 belonging to the powertrain domain include, for example, an ECU 4 that controls the engine, an ECU 4 that controls the motor, and an ECU 4 that controls the battery.

[0022] The ECUs 4 connected to the ECU 3 belonging to the body domain include, for example, an ECU 4 that controls an air conditioner, an ECU 4 that controls doors, and the like.

[0023] The ECUs 4 connected to the ECU 3 belonging to the chassis domain include, for example, an ECU that controls the brakes and an ECU 4 that controls the steering.

[0024] The ECUs 4 connected to the ECU 3 belonging to the cockpit domain include, for example, an ECU 4 that controls the display of meters and navigation systems, and an ECU 4 that controls an HMI device operated by a vehicle occupant, etc. HMI is an abbreviation for Human Machine Interface.

[0025] The external vehicle communication device 5 performs data communication with external vehicle devices such as the app store 200 via a wide area wireless communication network.

[0026] The in-vehicle communication network 6 includes CAN with Flexible Data Rate (hereinafter referred to as CAN FD) and Ethernet. Ethernet is a registered trademark. The CAN FD may connect the ECU 2 to each ECU 3 and the exterior-vehicle communication device 5 via a bus. The Ethernet may connect the ECU 2 to each ECU 3 and the exterior-vehicle communication device 5 individually.

[0027] The ECU 2 is an electronic control device mainly composed of a microcomputer including a CPU 2a, a ROM 2b, a RAM 2c, etc. Various functions of the microcomputer are realized by the CPU 2a executing a program stored in a non-transitory tangible recording medium. In this example, the ROM 2b corresponds to the non-transitory tangible recording medium storing the program. Furthermore, the execution of this program executes a method corresponding to the program. Note that some or all of the functions executed by the CPU 2a may be configured as hardware using one or more ICs, etc. Furthermore, the number of microcomputers constituting the ECU 2 may be one or more.

[0028] The ECU 3, the ECU 4, and the exterior communication device 5 are all electronic control devices that are mainly configured with a microcomputer including a CPU, a ROM, a RAM, etc., similar to the ECU 2. The number of microcomputers that make up the ECU 3, the ECU 4, and the exterior communication device 5 may be one or more.

[0029] Hereinafter, the ECU 2, ECU 3, ECU 4, and the external communication device 5 will be referred to as the in-vehicle devices 2 to 5 unless otherwise specified.

[0030] The app store 200 and the vehicle sales DB 300 are electronic control devices configured around a microcomputer equipped with a CPU, ROM, RAM, etc., similar to an ECU. Various functions of the microcomputer are realized by the CPU executing a program stored in a non-transitory tangible recording medium. In this example, the ROM corresponds to the non-transitory tangible recording medium storing the program. Furthermore, the execution of this program executes a method corresponding to the program. Note that some or all of the functions executed by the CPU may be configured in hardware using one or more ICs, etc. Furthermore, the number of microcomputers that make up the ECU may be one or more.

[0031] The app store 200 is a cloud server configured to be capable of communicating with at least the in-vehicle system 100 and the terminal device 400, and manages service apps (hereinafter, apps) executed by the in-vehicle system 100. The app store 200 sells apps to be installed in the in-vehicle system 100, and collects, from the in-vehicle system 100 in which the apps are installed, app operation logs indicating the operation status of the apps and API access logs indicating the access status from the apps to APIs. Furthermore, the app store 200 generates app usage fee collection data, API usage fee collection data, and the like, based on the app operation logs and API access logs. The app usage fee collection data is data for collecting app usage fees from app purchasers (hereinafter, users). The API usage fee collection data is data for collecting API usage fees from app developers or operators (hereinafter, servicers).

[0032] The vehicle sales DB 300 is configured to be capable of communicating with at least the terminal device 400, and is a cloud server that stores data related to vehicle sales and provides the stored data in response to requests from the terminal device 400, etc.

[0033] The terminal device 400 is an electronic control device mainly configured with a microcomputer including a CPU 401, a ROM 402, a RAM 403, etc. The various functions of the microcomputer are realized by the CPU 401 executing a program stored in a non-transitory tangible recording medium. In this example, the ROM 402 corresponds to the non-transitory tangible recording medium storing the program. Furthermore, the execution of this program results in the execution of a method corresponding to the program. Note that some or all of the functions executed by the CPU 401 may be configured as hardware using one or more ICs, etc. Furthermore, the number of microcomputers constituting the terminal device 400 may be one or more.

[0034] The terminal device 400 further includes a communication unit 404 and an input / output unit 405. The communication unit 404 performs data communication with the app store 200, the vehicle sales DB 300, and the like via a wide-area wireless communication network. The input / output unit 405 includes various input devices for receiving input from an operator of the terminal device 400, and various output devices for presenting the results of processing by the terminal device 400 to the operator. The input devices may include a keyboard, a pointing device, a touch panel, a microphone, and the like. The output devices may include a display, a speaker, a printer, and the like.

[0035] The terminal device 400 executes at least an index calculation process. The index calculation process is a process of collecting information from the app store 200 and the vehicle sales DB 300 and calculating an API index. The API index is an index used to evaluate each API in order to determine which API should be given priority in maintaining backward compatibility when updating the API installed in the vehicle. The index calculation process will be described in detail later.

[0036] 2. Functional Configuration Various functions provided in the API evaluation system 1 will be described.

[0037] 2, the in-vehicle system 100 has functions as an equipment management unit 10, a vehicle function module group 20, an API gateway 30, and a service providing unit 40. The functions of the in-vehicle system 100 are shared by the in-vehicle devices 2 to 5 belonging to the in-vehicle system 100.

[0038] [2-1-1. Equipment Management Unit] The equipment management unit 10 manages a plurality of types of vehicle equipment mounted on the vehicle.

[0039] The equipment management unit 10 operates the vehicle equipment in accordance with an operation instruction from the vehicle function module group 20 and notifies the vehicle function module group of the operation result. The vehicle equipment may include an actuator, a sensor, a storage device, an HMI device, etc. For example, if the vehicle equipment is an actuator, the operation result may indicate that the actuator has completed normally or abnormally. If the vehicle equipment is a sensor, the operation result may indicate data detected by the sensor. If the vehicle equipment is a storage device, the result notification may indicate data read from the storage device.

[0040] The equipment management unit 10 may be configured to operate the vehicle equipment in accordance with an operation instruction from the vehicle function module group 20, as well as to autonomously detect the state of the vehicle equipment and notify the vehicle function module group.

[0041] [2-1-2. Vehicle Function Module Group] The vehicle function module group 20 is a collection of vehicle function modules that execute processes to realize various functions using vehicle equipment. The functions of the vehicle function modules are provided via an application programming interface (hereinafter, API) 31. The vehicle function modules may be classified according to the vehicle operations that are likely to be requested by the service providing unit 40, such as, for example, state recognition, motion system equipment control, human machine interface (hereinafter, HMI) system equipment control, and body system equipment control.

[0042] State recognition corresponds to the operation of recognizing the vehicle itself and the situation around the vehicle, such as the positions of vehicles and pedestrians. A vehicle function module classified as state recognition controls, for example, vehicle equipment that belongs to recognition control (e.g., a camera, a millimeter wave sensor, etc.).

[0043] The control of the motoring equipment corresponds to the driving operation of the vehicle, such as turning, running, stopping, etc. The vehicle function module classified as the motoring equipment control controls, for example, vehicle equipment (e.g., actuators) that belong to brake control and steering control.

[0044] The HMI equipment control corresponds to the vehicle operation related to the presentation of information to the user. The vehicle function module classified as the HMI equipment control controls, for example, vehicle equipment (e.g., a display, a speaker, etc.) that belongs to the display control and sound control.

[0045] Body equipment control corresponds to the operation of the vehicle body system in relation to the vehicle environment. Vehicle function modules classified as body equipment control control vehicle equipment (e.g., actuators) belonging to, for example, light control, HVAC control, and seat control. HVAC is an acronym for heating, ventilation, and air conditioning, collectively known as the air conditioning system.

[0046] [2-1-3. Service Providing Unit] The service providing unit 40 executes the apps 41 downloaded and installed from the app store 200, thereby realizing various functions, such as information collection, theft prevention, remote control, etc., using the vehicle equipment managed by the equipment management unit 10. There may be multiple apps 41.

[0047] The application 41 basically accesses the vehicle function modules belonging to the vehicle function module group 20 via the API 31 via the API gateway 30, thereby utilizing the functions of various vehicle equipment and realizing the desired service.

[0048] A user can purchase an app 41 from the app store 200. The app purchased from the app store 200 is installed in one of the in-vehicle devices 2 to 5. In addition, the user can update or delete the app 41 installed in the in-vehicle device 2 to 5 as needed.

[0049] In addition, in the case of an app used to provide a service that acquires vehicle information from many vehicles and analyzes vehicle behavior and driver driving operations, etc., the servicer that provides app 41 may install app 41 on any of the in-vehicle devices 2 to 5 with the permission of the vehicle user.

[0050] The application 41 may be installed not only in one of the in-vehicle devices 2 to 5 but also in an external device remotely connected to the in-vehicle communication network 6 via the external communication device 5 .

[0051] The service providing unit 40 includes an application management unit 42 and an application operation log DB 43 .

[0052] The application management unit 42 generates application operation logs based on the results of monitoring the operation status of the application 41 installed in the vehicle, stores the generated application operation logs in the application operation log DB 43, and appropriately executes a process of uploading the stored application operation logs to the application store 200. The application management unit 42 and the application operation log DB 43 may be distributed and located in all of the in-vehicle devices 2 to 5 in which the application 41 may be installed, or may be integrated and located in one of the in-vehicle devices 2 to 5.

[0053] As shown in FIG. 3 , the application operation logs accumulated in the application operation log DB 43 are stored in association with an "application ID." The "application ID" is an identifier of the application 41 provided by the application store 200. The application operation logs are classified into basic data and processed data. The basic data is updated as needed depending on the operation status of the application 41. The processed data is generated when the application operation log is uploaded to the application store 200. The application operation log DB 43 may store only basic data.

[0054] Hereinafter, an application identified by an "application ID" will be referred to as a target application.

[0055] The basic data includes "application execution count," "application execution time," "monitoring start time," and "last execution time." "application execution count" is the number of times the target application has been launched in the in-vehicle system 100. "application execution time" is the time the target application has been executed in the in-vehicle system 100. "monitoring start time" indicates the time at which counting of the "application execution count" and accumulation of the "application execution time" for the target application began. "last execution time" indicates the time at which the target application was last executed. Note that if the elapsed time from the time indicated by the "last execution time" to the current time is longer than a preset allowable inactivity time, the "application execution count" is set to a value indicating that the target application is inactive.

[0056] The processed data includes the "number of times an application is executed per unit time" and the "application execution time per unit time." The "number of times an application is executed per unit time" is calculated based on the "number of times an application is executed per unit time" included in the basic data and the period from the time indicated by the "monitoring start time" to the time of upload (hereinafter referred to as the monitoring period). The "application execution time per unit time" is calculated based on the "application execution time" included in the basic data and the monitoring period. For example, a 24-hour period, i.e., a day, may be used as the unit time. The processed data is normalized data that can be simply accumulated when aggregating the "number of times an application is executed" and "application execution time" uploaded to the application store 200 from many in-vehicle systems 100.

[0057] Next, the application log management process executed by the application management unit 42 will be described with reference to the flowchart of FIG.

[0058] The application log management process is repeatedly executed when the in-vehicle system 100 is started.

[0059] In S110, the application management unit 42 determines whether the application 41 belonging to the service providing unit 40 has started, and if the application 41 has started, the process proceeds to S120, and if the application 41 has not started, the process proceeds to S140.

[0060] In S120, the application management unit 42 acquires time information indicating the current time (i.e., the time when the application 41 is started).

[0061] In the next step S130, the application management unit 42 updates the "application execution count" and the "last execution time" of the application 41 in the application operation log stored in the application operation log DB 43, and then ends the process. Specifically, the application management unit 42 updates the "application execution count" by counting it up by 1, and updates the "last execution time" with the time information acquired in step S120.

[0062] In S140, the application management unit 42 determines whether the application 41 belonging to the service providing unit 40 has stopped, and if the application 41 has stopped, the process proceeds to S150, and if the application 41 has not stopped, the process proceeds to S170.

[0063] In S150, the application management unit 42 acquires time information indicating the current time (i.e., the time when the application 41 was stopped).

[0064] In the next step S160, the application management unit 42 updates the "application execution time" of the application operation log stored in the application operation log DB 43 for the stopped application 41, and then ends the process. Specifically, the application management unit 42 updates the "application execution time" stored in the application operation log DB 43 by adding the time from when the application 41 is started to when it is stopped, which is calculated according to the time information acquired in the previous steps S120 and S150.

[0065] In S170, the application management unit 42 determines whether a log transmission condition for the application operation log is satisfied. If the log transmission condition is satisfied, the process proceeds to S180. If the log transmission condition is not satisfied, the process ends. The log transmission condition for the application operation log may be the passage of a certain period (e.g., one day, one week, or one month), a specified date, or receipt of an upload instruction from the application store 200.

[0066] In S180, the application management unit 42 acquires time information indicating the current time (i.e., the time when the application operation log is to be uploaded).

[0067] In the next step S190, the application management unit 42 generates processed data according to the basic data of the application operation log stored in the application operation log DB 43. Specifically, the application management unit 42 calculates a monitoring time from the time indicated by the "monitoring start time" in the basic data to the current time indicated by the time information acquired in S180. The application management unit 42 then calculates the "application execution count per unit time" by dividing the "application execution count" by the monitoring time, and calculates the "application execution time per unit time" by dividing the "application execution time" by the monitoring time. The application management unit 42 also calculates an inactive time from the time indicated by the "last execution time" to the current time indicated by the time information acquired in S180. If the calculated inactive time exceeds the allowable time, the application management unit 42 sets values ​​indicating inactivity to the "application execution count" and "application execution count per unit time" in the basic data.

[0068] In the next step S200, the application management unit 42 transmits (i.e., uploads) the application operation log together with the time information acquired in step S180 to the application store 200. Note that the application operation log to be uploaded may include all of the basic data and the processed data, or may include only the basic data or only the processed data. When uploading only the basic data, the processed data may be generated on the application store 200 side.

[0069] In the next S210, the application management unit 42 resets the "application execution count," "application execution time," and "monitoring start time" among the basic data of the application operation log stored in the application operation log DB 43, and then ends the process. Specifically, the "application execution count" and "application execution time" are cleared to zero, and the "monitoring start time" is set to the time information acquired in S180.

[0070] Although the above description is given assuming that the timing of uploading the application operation logs is the same for all the applications 41, the timing of uploading may be different for each application 41.

[0071] 2, the API gateway 30 provides an interface that connects the applications 41 with each other and with hardware. The API gateway 30 includes an access control unit 31, an API management unit 32, and an API access log DB 33.

[0072] When the access control unit 31 receives an API access request (hereinafter, API call) from the application 41, it determines whether the API call can be accepted from a formal standpoint, such as the request format and the access authority held by the caller. If the access control unit 31 determines that the API call can be accepted, it transfers the API call to the vehicle function module group 20. More specifically, it transfers the API call to the in-vehicle devices 2 to 5 that contain vehicle function modules that implement processing based on the API call. The access control unit 31 also transfers a response to the API call (hereinafter, API response) obtained from the vehicle function module group 20 to the application 41 that made the call. If the access control unit 31 determines that the API call cannot be accepted, it discards the API call. In this case, it may notify the application 41 that the API call has been discarded.

[0073] The API management unit 32 monitors the operation of the access control unit 31, generates an API access log, and executes a process of storing the generated API access log in the API access log DB 33. The API management unit 32 also executes a process of uploading the API access log stored in the API access log DB 33 to the app store 200 as needed.

[0074] The API access log may use information recorded for billing the application 41 that made the API call.

[0075] As shown in FIG. 5, the API access logs accumulated in the API access log DB 33 are stored categorized by "API providing application ID", "API-ID", and "call source application ID".

[0076] The "API providing app ID" is an identifier of an API providing app. An API providing app is a vehicle function module that provides an API. Since the same API may be provided by multiple API providing apps, the "API providing app ID" identifies which API providing app the API belonging to has been used. When the same API is provided by multiple API providing apps, the API belonging to which API providing app is used is selected, for example, so as to reduce communication costs. The "API-ID" is an identifier of the API. The "calling app ID" is an identifier of the calling app 41, which is the app that made the API call.

[0077] The API access log includes the "number of API calls," "number of API execution completions," "number of API unnecessary executions," "number of API abnormal executions," "API communication data volume," and the like.

[0078] The "number of API calls" is the number of times an API call was made. The "number of completed API executions" is the number of times an API call was completed successfully and the requested operation was completed. The "number of times API execution was not required" is the number of times an API call was completed successfully, but the requested operation had already been achieved and the operation was canceled. For example, this is counted when a request to open a window was received but the window was already in an open state. The "number of abnormal API executions" is the number of times an API call was not completed successfully, or the number of times an API call was completed successfully but the requested operation was not achieved. The "API data communication volume" is the cumulative value of the amount of data acquired by the calling application 41 through API calls.

[0079] That is, the API access log records which application used which API, how much it used, and what the results of the use were.

[0080] Next, the API log management process executed by the API management unit 32 will be described with reference to the flowchart of FIG.

[0081] The log management process is repeatedly executed when the in-vehicle system 100 is started.

[0082] In S310, the API management unit 32 determines whether the API call has been accepted by the access control unit 31, and if accepted, proceeds to S320, and if not accepted, proceeds to S330. The API call includes at least information about the "API providing application ID," "API-ID," and "caller application ID."

[0083] In S320, the API management unit 32 updates the "number of API calls" in the API access log stored in the API access log DB 33 for the API that was called, and then ends the process. Specifically, the value of the "number of API calls" is counted up by 1.

[0084] In S330, the API management unit 32 determines whether or not an API response has been transferred by the access control unit 31, and if an API response has been transferred, the processing proceeds to S340, and if an API response has not been transferred, the processing proceeds to S350.

[0085] In S340, the API management unit 32 updates the API access log stored in the API access log DB 33 for the API to which the API response was transferred in accordance with the contents of the API response, and then ends the processing. Specifically, if the API response indicates that the processing based on the API call was completed successfully, the API management unit 32 updates the "number of API execution completions." If the API response indicates that the processing based on the API call was not completed successfully, the API management unit 32 updates the "number of API execution abnormalities." Furthermore, if the processing based on the API call was completed successfully but the requested operation was not necessary, the API management unit 32 updates the "number of API executions not required." Furthermore, if data communication was performed by the processing based on the API call, the API management unit 32 updates the "API communication data volume."

[0086] In S350, the API management unit 32 determines whether the log transmission condition for the API access log is satisfied, and if the log transmission condition is satisfied, the process proceeds to S360, and if the log transmission condition is not satisfied, the process ends. The log transmission condition for the API access log may be the same as or different from the log transmission condition for the application operation log.

[0087] In S360, the API management unit 32 acquires vehicle information including information about the vehicle model and destination country. The destination country is information indicating the sales region of the vehicle. The vehicle information is acquired from information stored in an information source (e.g., a body-related ECU). The vehicle information may be acquired using an API, or may be acquired by a method other than an API. The vehicle information may be acquired from the information source every time, or may be acquired only once from the information source when the vehicle is started and stored in the API access log DB 33, etc., and thereafter acquired from the API access log DB 33.

[0088] In the next step S370, the API management unit 32 acquires time information indicating the current time (i.e., the time when the API access log is to be uploaded).

[0089] In the next step S380, the API management unit 32 transmits (i.e., uploads) to the app store 200 the data that includes the API access log stored in the API access log DB 33, the vehicle information acquired in S360, and the time information acquired in S370.

[0090] In the next step S390, the API management unit 32 resets the API access log and ends the process. In the reset API access log, the values ​​of all items are cleared to zero.

[0091] 2-2. App Store Returning to FIG. 2, the app store 200 includes an app providing unit 51, a log acquiring unit 52, an information DB 53, and a log DB .

[0092] In response to a request from a user or a servicer, the application providing unit 51 downloads the application 41 stored in the information DB 53 to the in-vehicle system 100, etc. The application providing unit 51 accumulates the number of downloads of each application 41 for each application ID in the information DB 53 as part of the application information.

[0093] The information DB 53 stores the applications 41 and application information as well as API security protected asset data.

[0094] As shown in FIG. 7, the application information is classified by "application ID" and includes items such as "number of downloads," "total application execution time," "application rating," and "number of API uses."

[0095] The "number of downloads" indicates a cumulative value obtained by counting the number of downloads of the target app, which is the app 41 identified by the "app ID," and an active number indicating the number of apps that are actually running. The active number is a log aggregate value obtained by aggregating the number of target apps that are not indicated as inactive in the "number of app executions" or "number of app executions per unit time" included in the app operation log. In other words, the cumulative value of the number of downloads is updated every time the app 41 is downloaded, and the active number is updated every time the app operation log is uploaded.

[0096] The "total application execution time" is a log aggregate value obtained by aggregating the "application execution time" included in the application operation log for the target application. In other words, the "total application execution time" is updated every time an application operation log is uploaded.

[0097] The "app rating" is information indicating the user's rating of the app. For example, the "app rating" is the result of aggregating app ratings collected on an app rating site or the like. In other words, the "app rating" is updated whenever the aggregated rating results are obtained.

[0098] The "number of API uses" is information indicating the number of API calls made for each API used in the target application. The "number of API uses" is not the number of times the API is actually used, but the number of API calls made by the target application, and is applied for by the servicer that registers the target application in the application store 200.

[0099] The API security protected asset data is data that associates "API-ID" with "security protected asset data" as shown in Figure 8. The "security protected asset data" is set from the perspective of S.F.O.P., which is an attribute defined as a security protected asset. S stands for Safety and means that the API provides a function that affects safety. F stands for Financial and means that the API provides a function that affects the assets of a company or individual. O stands for Operational and means that the API provides a function that affects the operational performance of a vehicle. P stands for Privacy and means that the API provides a function that affects privacy information. The API security protected asset data is generated by the manufacturer of the API providing application, etc. In the table shown in Figure 8, a circle indicates that there is an impact.

[0100] The log acquisition unit 52 sequentially accumulates the application operation logs and API access logs uploaded from the in-vehicle system 100 in the log DB 54, and updates the "number of downloads" and "total application execution time" of the application information shown in Fig. 7 based on the application operation logs. The application operation logs may accumulate both basic data and processed data, or may accumulate only processed data.

[0101] 9, the log DB 54 stores the "API access log" together with the "upload time," "vehicle type," and "destination country" that are uploaded together with the "API access log" from the in-vehicle system 100. The "API access log" in FIG. 9 includes the entire table shown in FIG. 5.

[0102] [2-3. Vehicle Sales DB] The vehicle sales DB 300 is a cloud server that stores vehicle sales data, and provides the stored vehicle sales data in response to a request from the terminal device 400 or the like.

[0103] 10, the vehicle sales data stored in the vehicle sales DB 300 includes items such as "total number of units sold" and "period since start of mass production" for each "vehicle category." In this embodiment, the "vehicle category" is classified by "vehicle model" and "country of destination."

[0104] [2-4. Terminal Device] The terminal device 400 is operated by an API administrator who manages APIs, and executes at least an API index generation process. The API index generation process is a process for generating API indexes used to select APIs that should be prioritized for maintaining backward compatibility when updating many APIs. Maintaining backward compatibility means that the updated API allows existing apps that were in use before the update to continue to be used.

[0105] The API index generation process executed by the terminal device 400 will be described with reference to the flowchart of Fig. 11. The evaluation value generation process is started when an operation to start the process is performed on the terminal device 400.

[0106] In S410 , the terminal device 400 acquires the application operation log and the API access log from the application store 200 .

[0107] In the next step S420 , the terminal device 400 acquires vehicle sales data from the vehicle sales DB 300 .

[0108] In the next S430, the terminal device 400 calculates the "total number of first API executions" and the "total first API charge amount" by tallying the "number of API calls" and the "API charge amount" in the API access log for each "API-ID," as shown in Fig. 12. The tallying results and the calculation results may be stored in the RAM 403.

[0109] The "API charge amount" is calculated by, for example, aggregating the "number of API calls," "number of API executions completed," "number of unnecessary API executions," "number of abnormal API executions," and "API communication data volume" contained in the API access log for each "API-ID," and then weighting and adding the aggregated values ​​using a preset weight value. Note that the "total API charge amount" may be obtained from an external server that determines the charge amount for each API based on the API access log.

[0110] In the next step S440, the terminal device 400 calculates API indices based on the results of the counting in step S430. Specifically, the terminal device 400 uses the "total number of first API executions" and the "total first API billing amount" as API indices, and further calculates a "total first API usage rate" and a "total first API execution rate."

[0111] The "total API usage rate" is the number of times the API is used per application, and is calculated using the "number of downloads" included in the application information according to formula (1). Note that the "number of downloads" is a cumulative value.

[0112] The "total API execution rate" is the number of API executions per average execution time of one application, and is calculated using the "total application execution time" and "number of downloads" included in the application information using formula (2). Note that the "number of downloads" is a cumulative value.

[0113] The API index calculated in this way simply gives higher ratings to APIs that are executed frequently, charged a high amount, and have high usage and execution rates, and gives a higher priority to maintaining backward compatibility when updating APIs.

[0114] In the next S450, the terminal device 400 counts the "API call count" in the API access log for each "application ID" and "API-ID," as shown in FIG. 13. Furthermore, in the formulas (1) and (2), the "API usage rate" and "API execution rate" are calculated for each "application ID" and "API-ID" using the counted value of the "API call count" in this step instead of the "total API execution count." The counting results and calculation results may be stored in RAM 403.

[0115] In the next S460, the terminal device 400 calculates a "second API total usage rate" and a "second API total execution rate" based on the "API usage rate" and "API execution rate" calculated for each "app ID" and "API-ID" in S450, and the "number of downloads" indicated in the app information. The "second API total usage rate" and the "second API total execution rate" are API indexes that take into account the "number of downloads."

[0116] Specifically, as shown in FIG. 14 , a weighted value is assigned according to the “number of downloads,” with the larger the “number of downloads,” the larger the weighted value. Here, the number of downloads is divided into five categories: 0 to 500, 501 to 1000, 1001 to 5000, 5001 to 10000, and 10001 and above, and weighted values ​​of 1 to 5 are assigned to each category. The categories of the number of downloads and the weighted values ​​(hereinafter, “download-related information”) may be set in advance or may be set each time by an API administrator or the like operating the terminal device 400. If the download-related information is set in advance, it may be acquired from, for example, the information DB 53 of the app store 200, or may be pre-stored in the ROM 402. Then, based on the table in FIG. 13 , the “API usage rate” and “API execution rate” calculated in S450 are tallied for each “number of downloads” corresponding to the “app ID.” FIG. 14 shows an example of aggregating the information for one “API-ID.” Here, the case where "API-ID" = 1 is shown. In other words, a summary table similar to that shown in Fig. 14 is created for all "API-IDs." The summary table may be stored in RAM 403.

[0117] According to the summary table based on the "number of downloads" shown in the upper part of FIG. 14, a "second API usage rate" and a "second total API usage rate" are calculated for each "API-ID" by performing weighted addition using a "weight value" for each of the "API usage rate" and "API execution rate." That is, the "second total API usage rate" for "API-ID"=1 shown in the table in the lower part of FIG. 14 is calculated by 5×2+4×3+3×1+2×1+1×1 according to the table in the upper part of FIG. 14. Similarly, the "second total API execution rate" for "API-ID"=1 is calculated by 5×10+4×20+3×5+2×2+1×2. The calculation results may be stored in RAM 403.

[0118] The API index calculated in this way gives a high rating to APIs that are frequently used in apps downloaded to many vehicles, and therefore prioritizes maintaining backward compatibility when updating the API. In the case of the table in the lower part of Figure 14, where "API-ID" = 1 is represented by <1>, the order of priority is <1> → <2> <4> → <5> → <3> when viewed in terms of the "weighted sum of API usage rates." Furthermore, the order of priority is <2> → <1> → <4> → <5> → <3> when viewed in terms of the "weighted sum of API execution rates."

[0119] In the next S470, the terminal device 400 calculates the "second API total execution count" based on the "API usage rate" and "API execution rate" calculated for each "application ID" and "API-ID" in S450, and the "application rating" indicated in the application information. The "second API total execution count" is an API index that takes into account the "application rating."

[0120] Specifically, as shown in FIG. 15 , the "app rating," which increases as the rating increases, is used as the "weight." Here, weights of 1 to 5 are used. The "weight" may be adjusted each time by an API administrator or the like who operates the terminal device 400. Then, with reference to FIG. 7 , the aggregated values ​​of the "number of API calls" calculated in S450 are tallied for each "app rating" corresponding to an "app ID." FIG. 15 shows an example of tallying for one "API-ID." Here, the case where "API-ID" = 1 is shown. In other words, a summary table similar to that in FIG. 15 is created for all "API-IDs." The summary table may be stored in RAM 403.

[0121] According to a summary table based on the "application evaluation," the "total number of executions of the second API" is calculated for each "API-ID" by performing weighted addition using the "weight value" on the total value of the "number of API calls." That is, the "total number of executions of the second API" for "API-ID"=1 shown in the table at the bottom of FIG. 15 is calculated by 5×1000+4×5000+3×1000+2×200+1×100 according to the table at the top of FIG. 15. The calculation result may be stored in RAM 403.

[0122] In the API index calculated in this way, APIs that are frequently used in apps that receive high user ratings are given a high rating, and maintaining backward compatibility when updating the API is given a high priority. In the case of the table in the lower part of Figure 15, the order of priority is <1> → <4> → <2> → <3> → <5>.

[0123] In the next S480, the terminal device 400 counts the "number of API calls" and "API charge amount" in the API access log for each "API-ID" and "vehicle classification" (i.e., "vehicle type" and "destination country"), as shown in Fig. 16. The counting results may be stored in the RAM 403.

[0124] In the next S490, terminal device 400 calculates the "number of API calls by category" and the "API charge amount" based on the "number of API calls" and the "API charge amount" calculated for each "API-ID" and "vehicle category" in S480, as well as the "number of units sold" and the "period since the start of mass production" indicated in the vehicle sales data. The "number of API executions by category" and the "API charge amount by category" are API indices that take into account the vehicle sales data.

[0125] Specifically, as shown in FIG. 17 , a “first multiplier” is assigned according to the “period from the start of mass production,” with the “first multiplier” being a smaller value the longer the “period from the start of mass production.” Here, the first multiplier is set to 1.5 if the period is less than five years, 1 if the period is five to ten years, and 0 if the period is ten years or more. Information indicating how to assign the “first multiplier” (hereinafter, “mass-production period-related information”) may be set in advance or may be set each time by an API administrator or the like operating terminal device 400. If the mass-production period-related information is set in advance, for example, the information may be acquired from vehicle sales DB 300 or the like, or may be pre-stored in ROM 402. Then, the “API usage rate” and “API charge amount” tallied in S480 are multiplied by the “number of units sold” corresponding to the “vehicle classification” and the “first multiplier” corresponding to the “period from the start of mass production,” respectively, to calculate the “number of executions by classification” and the “charge amount by classification” for each classification that serves as the aggregation unit.

[0126] For example, the "number of executions by category" in the case where "API-ID" = 1, "vehicle type" = A, and "destination country" = a shown in the table at the bottom of FIG. 17 is calculated as follows: That is, it is calculated as 100 x 100,000 x 1.5 according to the "total number of units sold" and "period from start of mass production" shown in the table at the top of FIG. 10, the "number of API calls" shown in FIG. 16, and the "first multiplier" shown at the top of FIG. 17. Similarly, the "amount charged by category" is calculated as 10,000 x 100,000 x 1.5. The calculation result may be stored in RAM 403.

[0127] The API index calculated in this manner is larger for APIs that are frequently used in vehicle categories with a large number of units sold and a short period since the start of mass production, and for which the amount charged for that vehicle category is high. In other words, for APIs that are expected to be used frequently in the future, maintaining backward compatibility when updating the API is a high priority. Conversely, if the period since the start of mass production exceeds a certain period, a decrease in API usage is expected due to vehicle scrapping, etc., so the "first multiplier" is set to 0, and the API is therefore excluded from evaluation. Note that the "number of executions by category" and "amount charged by category" calculated in this manner may be aggregated for each "API-ID" and the aggregated results may be used as the API index.

[0128] In the next step S500, the terminal device 400 calculates the "third API total execution count" and the "third API total charge amount", which are API indices that take into account the "security protected asset".

[0129] Specifically, as shown in FIG. 18 , a "second multiplier" is assigned according to the classification of the "security protected asset." Here, S is set to 10, F to 5, O to 3, and P to 5. Information indicating how to assign the "second multiplier" (hereinafter referred to as protected asset-related information) may be set in advance, or may be set each time by an API administrator or the like operating the terminal device 400. If the protected asset-related information is set in advance, it may be acquired from, for example, information DB 53 of the app store 200, or may be pre-stored in ROM 402. Then, the aggregated values ​​of the "number of API calls" and "API charge amount" tallied in S430, i.e., the "total number of first API executions" and "total first API charge amount," are multiplied by the "second multiplier." As a result, the "total number of third API executions" and "total third API charge amount" are calculated for each "API-ID" that serves as the aggregation unit. The calculation results may be stored in RAM 403.

[0130] The API index calculated in this way gives a high rating to APIs that are frequently used and have an impact on the SFOP perspective, and gives a high priority to maintaining backward compatibility when updating the API.

[0131] In the subsequent S510, the terminal device 400 outputs the calculated API index to a display screen or the like, and ends the processing. Note that the terminal device 400 may transmit the calculated API index to a server that accumulates API indexes or to another terminal device that uses the API indexes.

[0132] The API administrator sets the priority of updates for each API while maintaining backward compatibility according to one selected API metric or a combination of multiple API metrics.

[0133] [3. Correspondence of Terms] In this embodiment, the "second API total usage rate," "second API total execution rate," and "second API total execution count" correspond to the application-related indicators of the present disclosure. The "API execution count by category" and "charge amount by category" in this embodiment correspond to the sales-related indicators of the present disclosure. The "third API total execution count" and "third API total charge amount" in this embodiment correspond to the security-related indicators of the present disclosure. S410 to S420 in this embodiment correspond to the information acquisition unit of the present disclosure, S430 to S440 correspond to the basic indicator generation unit of the present disclosure, and S450 to S470 correspond to the application-related indicator generation unit of the present disclosure. S480 to S490 in this embodiment correspond to the sales-related indicator generation unit of the present disclosure, S500 corresponds to the security-related indicator generation unit of the present disclosure, and S510 corresponds to the output unit of the present disclosure. The app store 200 in this embodiment corresponds to the access log storage unit of the present disclosure, and the vehicle sales DB 300 corresponds to the sales data storage unit of the present disclosure.

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

[0135] The API evaluation system 1 calculates an API index according to the number of times and frequency of API use, an API index that takes into account the usage status of the app, an API index that takes into account vehicle sales data, and an API index that takes into account the impact of security protection assets. By referring to these API indexes, it is possible to quantify the impact of each API on the apps that use the API and the users who use the apps, and it becomes possible to easily select APIs for which backward compatibility should be prioritized based on the magnitude of that impact.

[0136] Here, a specific method for extracting APIs that should be developed while maintaining backward compatibility using multiple types of API indicators will be described.

[0137] For example, first, from among all APIs, APIs (hereinafter referred to as first extracted APIs) that are in the top 50% of values ​​of an API index (i.e., "second API total usage rate" or "second API total execution rate" or "second API total execution rate") that takes into account the usage status of the app are extracted. In other words, APIs that are frequently used in apps used in many vehicles are extracted.

[0138] Next, from among the first extracted APIs, APIs (hereinafter referred to as second extracted APIs) in the top 50% of API index values ​​(i.e., "number of API executions by category" or "API charge amount by category") that take into account vehicle sales data are extracted. In other words, APIs that are expected to be widely used in the future are extracted.

[0139] Next, from among all the APIs, APIs (hereinafter referred to as "third extracted APIs") that are in the top 20% of values ​​for API indexes that take into account the impact of security protection assets (i.e., "total number of executions of the third API" or "total amount charged for the third API") are extracted. In other words, APIs that are important from the perspective of security protection assets are extracted.

[0140] Finally, the merged second and third extraction APIs are set as the API for which backward compatibility should be maintained.

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

[0142] (5a) In the above embodiment, the weighted sum of the aggregated values ​​of the "API usage rate" and the "API execution rate" is used as the API index that takes into account the "number of downloads" of the app, but the weighted sum of the aggregated value of the "number of API calls" may also be used. Also, the weighted sum of the aggregated value of the "number of API calls" is used as the API index that takes into account the "rating of the app," but the weighted sum of the aggregated values ​​of the "API usage rate" and the "API execution rate" may also be used.

[0143] (5b) In the above embodiment, when calculating the API index taking into account vehicle sales data, both the "number of units sold" and the "first multiplier" based on the "period from the start of mass production" are used, but it is also possible to use only either the "number of units sold" or the "first multiplier." Also, instead of using the "number of units sold" as is, it is also possible to use a "third multiplier" that is set according to the number of units sold.

[0144] (5c) In the above embodiment, the API index that takes into account the security protection asset is not limited to the “total number of first API executions” and the “total amount charged for the first API.” The API index that takes into account the security protection asset may be generated, for example, by multiplying any API index other than the “total number of first API executions” and the “total amount charged for the first API” by a “second multiplier.”

[0145] (5d) The in-vehicle devices 2-5, app store 200, vehicle sales DB 300, and terminal device 400 (hereinafter referred to as the control device group) and the method thereof described herein may be realized by a dedicated computer provided by configuring a processor and memory programmed to execute one or more functions embodied in a computer program. Alternatively, the control device group and the method thereof described herein may be realized by a dedicated computer provided by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the control device group and the method thereof described herein may be realized by one or more dedicated computers configured by combining a processor and memory programmed to execute one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored on a computer-readable non-transitory tangible recording medium as instructions executed by a computer. The method for realizing the functions of each unit included in the control device group does not necessarily need to include software; all of the functions may be realized using one or more hardware.

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

[0147] (5d) In addition to the API evaluation system described above, the present disclosure can also be realized in various forms, such as a system that includes the API evaluation system as a component, a program for causing a computer to function as the API evaluation system, a non-transient physical recording medium such as a semiconductor memory on which this program is recorded, and a method for generating an API evaluation index.

[0148] [6. Technical Ideas Disclosed in the Present Specification] [Item 1] An API evaluation system comprising: an information acquisition unit (400: S410-S420) that acquires API access logs that indicate usage status of APIs, which are interfaces for providing vehicle functions in accordance with requests from applications installed in a vehicle; a sales-related index generation unit (400: S480-S490) that generates sales-related indexes that are API indexes that indicate the magnitude of the influence that the API has on the applications and users of the vehicle, in accordance with log aggregation values ​​that are results of aggregating the API access logs for each vehicle category that classifies the vehicles based on vehicle sales data related to sales of the vehicles and for each type of API; and an output unit (400: S510) that outputs the sales-related indexes.

[0149] [Item 2] An API evaluation system comprising: an access log storage unit (200) that collects from a vehicle and accumulates an API access log that indicates usage status of an API, which is an interface for providing vehicle functions in accordance with requests from an application installed in the vehicle; a sales data storage unit (300) that accumulates vehicle sales data related to sales of the vehicle; an information acquisition unit (400: S410 to S420) that acquires the API access log and the vehicle sales data from the access log storage unit and the sales data storage unit; a sales-related index generation unit (400: S480 to S490) that generates sales-related indexes, which are API indexes that indicate the magnitude of the influence that the API has on the application and the user of the vehicle, according to log aggregation values ​​that are results of aggregating the API access logs for each vehicle category into which the vehicles are classified according to the vehicle sales data and for each type of API; and an output unit (400: S510) that outputs the sales-related indexes.

[0150] [Item 3] The API evaluation system according to Item 1 or 2, wherein the sales-related index generation unit calculates the sales-related index by multiplying the log aggregate value, which is aggregated for each vehicle category and each API type, by a multiplication rate set according to the vehicle sales data.

[0151] [Item 4] The API evaluation system according to any one of items 1 to 3, wherein the vehicle classification is set using at least one of a vehicle model and a sales region of the vehicle.

[0152] [Item 5] An API evaluation system according to any one of items 1 to 4, wherein the vehicle sales data includes at least one of the number of vehicles sold and the period since mass production of the vehicle began. [Item 6] An API evaluation system according to any one of items 1 to 5, wherein the log aggregation value includes at least one of the number of API calls, which is the number of times the API is called by the application, and an API fee levied on the provider of the application according to the amount of communication data associated with the use of the API.

[0153] [Item 7] The API evaluation system according to any one of Items 1 to 6, wherein the information acquisition unit further acquires data indicating whether or not there is an impact on a security-protected asset for each type of API, and further comprises a security-related index generation unit (300: S500) that multiplies the log aggregate value by a multiplication rate set for each category of security-protected asset to generate a security-related index, which is an API index that takes into account the impact on the security-protected asset.

[0154] [Item 8] The API evaluation system according to any one of Items 1 to 7, wherein the information acquisition unit further acquires an application operation log including the number of times the application is executed and the execution time of the application, and the log aggregation value includes at least one of an API usage rate which is the number of times the API is used per application, and an API execution rate which is the number of times the API is used per average execution time of the application, and the API evaluation system further comprises an application-related index generation unit (300: S450 to S470) which generates, for each type of application and for each type of API, an application-related index which is an API index that takes into account the usage status of the application, according to the log aggregation value which is a result of aggregating the API access logs.

[0155] [Item 9] The API evaluation system according to Item 8, wherein the application-related index generation unit generates the application-related index by weighting and adding the log aggregate value using a weight value set for each type of application according to a cumulative value of the application downloaded to the vehicle.

[0156] [Item 10] The API evaluation system according to Item 8 or Item 9, wherein the application-related index generation unit generates the application-related index by weighting and adding the log aggregate value using a weight value set for each type of application according to a user's evaluation of the application.

[0157] [Item 11] The API evaluation system according to any one of items 1 to 10, further comprising a basic index generation unit that generates a basic index, which is an API index that takes into account the usage status of the API, according to a log aggregation value that is a result of aggregating the API access logs for each type of API.

Claims

1. An API evaluation system comprising: an information acquisition unit (400: S410-S420) that acquires an API access log indicating the usage status of an API, which is an interface for providing vehicle functions in accordance with requests from an application installed in a vehicle; a sales-related index generation unit (400: S480-S490) that generates sales-related indexes, which are API indexes that indicate the magnitude of the influence that the API has on the application and users of the vehicle, in accordance with log aggregation values ​​that are the result of aggregating the API access logs for each vehicle category into which the vehicle is classified based on vehicle sales data related to the sale of the vehicle and for each type of API; and an output unit (400: S510) that outputs the sales-related indexes.

2. An API evaluation system comprising: an access log storage unit (200) that collects from a vehicle and accumulates an API access log indicating the usage status of an API, which is an interface for providing vehicle functions in accordance with a request from an application installed in the vehicle; a sales data storage unit (300) that accumulates vehicle sales data related to the sale of the vehicle; an information acquisition unit (400: S410-S420) that acquires the API access log and the vehicle sales data from the access log storage unit and the sales data storage unit; a sales-related index generation unit (400: S480-S490) that generates sales-related indexes, which are API indexes indicating the magnitude of the influence that the API has on the application and the user of the vehicle, in accordance with log aggregation values ​​that are the result of aggregating the API access logs for each vehicle category into which the vehicles are classified according to the vehicle sales data and for each type of API; and an output unit (400: S510) that outputs the sales-related indexes.

3. An API evaluation system as described in claim 1 or claim 2, wherein the sales-related index generation unit calculates the sales-related index by multiplying the log aggregate value aggregated for each vehicle category and each API type by a multiplication rate set according to the vehicle sales data.

4. An API evaluation system according to claim 1 or 2, wherein the vehicle classification is set using at least one of the vehicle model and the vehicle sales region.

5. The API evaluation system according to claim 1 or 2, wherein the vehicle sales data includes at least one of the number of vehicles sold and the period since the start of mass production of the vehicle.

6. An API evaluation system as described in claim 1 or 2, wherein the log aggregation value includes at least one of the number of API calls, which is the number of times the API is called by the application, and an API fee levied on the provider of the application according to the amount of communication data associated with the use of the API.

7. An API evaluation system as described in claim 1 or claim 2, wherein the information acquisition unit further acquires data indicating whether or not there is an impact on a security protection asset for each type of API, and the API evaluation system further comprises a security-related index generation unit (300: S500) that generates a security-related index, which is an API index that takes into account the impact on the security protection asset, by multiplying the log summary value by a multiplication rate set for each category of the security protection asset.

8. An API evaluation system as recited in claim 1 or 2, wherein the information acquisition unit further acquires an application operation log including the number of times the application installed in the vehicle is executed and the execution time, and the log aggregation value includes at least one of an API usage rate which is the number of times the API is used per application and an API execution rate which is the number of times the API is used per average execution time of the application, and the API evaluation system further comprises an app-related index generation unit (300: S450 to S470) which generates, in accordance with the log aggregation value which is the result of aggregating the API access logs for each type of application and for each type of API, an app-related index which is an API index taking into account the usage status of the application.

9. An API evaluation system as described in claim 8, wherein the application-related index generation unit generates the application-related index by weighting and adding the log aggregation value using a weighting value set for each type of application according to a cumulative value of the application downloaded to the vehicle.

10. An API evaluation system as described in claim 8, wherein the application-related index generation unit generates the application-related index by weighting and adding the log aggregate value using a weighting value set for each type of application according to a user's evaluation of the application.

11. An API evaluation system as described in claim 1 or claim 2, further comprising a basic index generation unit that generates a basic index, which is an API index that takes into account the usage status of the API, according to a log aggregation value that is the result of aggregating the API access logs for each type of API.

12. A program causing a computer to function as: an information acquisition unit (S410-S420) that acquires API access logs indicating the usage status of APIs, which are interfaces that provide functions of a vehicle in accordance with requests from applications installed in the vehicle; a sales-related index generation unit (S480-S490) that generates sales-related indexes, which are API indexes that indicate the degree of influence that the API has on the application and the user of the vehicle, in accordance with log aggregation values ​​that are the results of aggregating the API access logs for each vehicle category into which the vehicle is classified based on vehicle sales data related to the sale of the vehicle and for each type of API; and an output unit (S510) that outputs the sales-related indexes.

Images