API evaluation system and program

Abstract

The invention provides an API evaluation system and a program. An information acquisition unit (S410-S420) acquires an API access log indicating the usage status of an API in response to a request from an application installed in a vehicle. A sales-related index generation unit (S480-S490) generates a sales-related index on the basis of a log statistical value, which is for each vehicle category in which vehicles are classified on the basis of vehicle sales data, and which counts the results of API access logs for each category of APIs. The sales-related index is an API index indicating the magnitude of the influence of the API on the application program and the user of the vehicle. The output unit (S510) outputs the sales-related index.

Description

[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. Technical Field

[0002] This disclosure relates to techniques for evaluating APIs. Background Technology

[0003] Patent Document 1 describes a technique that provides a method for extracting the location of incompatibility between an application and a platform and for eliminating the incompatibility.

[0004] Patent Document 1: Japanese Patent Application Publication No. 2013-164879

[0005] Vehicle functionality is provided via an Application Programming Interface (API). The API may be upgraded as needed to accommodate structural changes in sensors, actuators, ECUs, etc., used to implement these functions, as well as to accommodate additional changes in supported OEMs or vehicle models, or to improve ease of use. Upgraded APIs are expected to be backward compatible so that they can be used without requiring changes to existing applications.

[0006] However, since maintaining backward compatibility for all APIs requires a significant amount of effort and time, it is necessary to appropriately select APIs for backward compatibility and develop APIs efficiently.

[0007] In existing technologies, a problem has been found where only information is obtained to eliminate incompatibility, but it is impossible to determine whether compatibility is truly necessary. Summary of the Invention

[0008] One aspect of this disclosure provides a technique for evaluating an API regarding backward compatibility.

[0009] One aspect of this disclosure is an API evaluation system comprising an information acquisition unit, a sales-related metric generation unit, and an output unit. The information acquisition unit acquires API access logs for APIs based on requests from applications installed in vehicles, wherein the API is an interface providing vehicle functionality, and the API access logs indicate the usage status of the API. The sales-related metric generation unit generates sales-related metrics based on log statistics, wherein the log statistics are compiled according to each vehicle category categorized based on vehicle sales data related to vehicle sales, and according to each type of API, summarizing the API access logs. Sales-related metrics are API metrics that represent the magnitude of the impact of the API on the application and vehicle users. The output unit outputs the sales-related metrics.

[0010] Based on this structure, the generated sales correlation metrics can be used to filter APIs that should prioritize maintaining backward compatibility, enabling efficient API development.

[0011] One aspect of this disclosure is an API evaluation system comprising an access log storage unit, a sales data storage unit, an information acquisition unit, a sales-related metric generation unit, and an output unit. The access log storage unit collects and accumulates API access logs from the vehicle based on requests from applications installed on the vehicle, where the API is an interface providing vehicle functionality, and the API access logs indicate the usage status of the API. The sales data storage unit accumulates vehicle sales data related to vehicle sales. The information acquisition unit acquires API access logs and vehicle sales data from the access log storage unit and the sales data storage unit. The sales-related metric generation unit generates sales-related metrics based on log statistics, where the log statistics are the results of API access log statistics for each vehicle category categorized according to vehicle sales data, and for each type of API. The sales-related metrics are API metrics that represent the magnitude of the impact of the API on the application and vehicle users. The output unit outputs the sales-related metrics.

[0012] Based on this structure, the generated sales correlation metrics can be used to filter APIs that should prioritize maintaining backward compatibility, enabling efficient API development.

[0013] One aspect of this disclosure is a program that enables a computer to function as an information acquisition unit, a sales-related indicator generation unit, and an output unit.

[0014] By executing such a procedure, the same effect as the API evaluation system described above can be obtained. Attached Figure Description

[0015] Figure 1This is a block diagram representing the hardware structure of the API evaluation system.

[0016] Figure 2 This is a block diagram representing the functional structure of the API evaluation system.

[0017] Figure 3 This is an explanatory diagram representing the contents of the application action log.

[0018] Figure 4 This is a flowchart of application log management processing.

[0019] Figure 5 This is an illustration of the contents of the API access log.

[0020] Figure 6 This is a flowchart of API log management and processing.

[0021] Figure 7 This is an illustration showing the content of application information managed by the app store.

[0022] Figure 8 This is an illustration showing the impact of information on security protection assets managed by the app store.

[0023] Figure 9 This is an illustration of API access logs with additional information accumulated in the app store.

[0024] Figure 10 This is an explanatory diagram showing the contents of vehicle sales data managed by the vehicle sales database.

[0025] Figure 11 This is a flowchart of API metric calculation and processing.

[0026] Figure 12 This is a chart illustrating the basic API metrics.

[0027] Figure 13 This is an explanatory diagram illustrating the statistical methods used in calculating API access logs that take into account application usage.

[0028] Figure 14 This is an explanatory diagram illustrating an example of how API metrics take into account the number of app downloads.

[0029] Figure 15 This is an explanatory diagram illustrating an example of how API metrics are calculated, taking into account the evaluation of the application.

[0030] Figure 16 This is an illustration of the statistical methods used in calculating API metrics that take into account vehicle sales data from API access logs.

[0031] Figure 17 This is an explanatory diagram illustrating an example of API metrics that take into account vehicle sales data.

[0032] Figure 18 This is an explanatory diagram illustrating the calculation example of the API metric that takes into account the impact of protecting assets. Detailed Implementation

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

[0034] [1. Structure]

[0035] like Figure 1 As shown, the API evaluation system 1 of this embodiment includes an in-vehicle system 100 installed in a vehicle, an application store 200, a vehicle sales database (DB) 300, and a terminal device 400. DB is an abbreviation for database. In addition to manual driving functions, the vehicle may also have automatic driving functions. The vehicle may also be a hybrid vehicle with an engine and an electric motor as driving sources. The vehicle is not limited to vehicles with automatic driving functions or hybrid vehicles; it may also be a vehicle with only manual driving functions, or a vehicle with only an engine or only an electric motor as driving sources. Hereinafter, the vehicle equipped with the in-vehicle system 100 will simply be referred to as a vehicle.

[0036] The vehicle system 100 includes one electronic control unit (hereinafter, ECU) 2, multiple ECUs 3, multiple ECUs 4, an external communication device 5, and an internal communication network 6. ECU is an abbreviation for Electronic Control Unit.

[0037] ECU2 achieves overall coordinated control of the vehicle by unifying multiple ECU3.

[0038] ECU3 is configured according to each domain defined by function within the vehicle, primarily controlling multiple ECU4s residing within its domain. Each ECU3 connects to its subordinate ECU4s via a separately configured lower-level network. This lower-level network may use, for example, a Controller Area Network (CAN). CAN is a registered trademark. ECU3 has functions such as unified management of access permissions for its subordinate ECU4s and user authentication. Domains may include, for example, the powertrain, body, chassis, and cockpit.

[0039] ECU4, which is connected to ECU3 belonging to the powertrain domain, includes, for example, ECU4 that controls the engine, ECU4 that controls the motor, and ECU4 that controls the battery.

[0040] ECU4, which is connected to ECU3 belonging to the vehicle body, includes, for example, ECU4 that controls the air conditioning and ECU4 that controls the doors.

[0041] ECU4, which is connected to ECU3 belonging to the chassis domain, includes, for example, an ECU that controls the brakes and an ECU4 that controls the steering.

[0042] ECU4, which is connected to ECU3 belonging to the cockpit domain, includes, for example, ECU4 containing displays for controlling instruments and navigation, and ECU4 controlling HMI devices operated by the vehicle occupants. HMI is short for Human Machine Interface.

[0043] The vehicle external communication device 5 communicates with other vehicle external devices such as the app store 200 via a wide area wireless communication network.

[0044] The in-vehicle communication network 6 features CAN with Flexible Data Rate (hereinafter, CAN FD) and Ethernet. Ethernet is a registered trademark. CAN FD can also connect ECU2 to each of ECU3 and external communication devices 5 via a bus. Ethernet can also independently connect ECU2 to each of ECU3 and to external communication devices 5.

[0045] ECU2 is an electronic control device centered around a microcomputer, including CPU2a, ROM2b, and RAM2c. The various functions of the microcomputer are implemented by CPU2a executing programs stored on a non-transitional physical recording medium. In this example, ROM2b is equivalent to the non-transitional physical recording medium storing the program. Furthermore, by executing this program, methods corresponding to the program are performed. Additionally, one or more ICs or similar hardware components can be used to construct part or all of the functions executed by CPU2a. Moreover, the number of microcomputers constituting ECU2 can be one or more.

[0046] ECU3, ECU4, and the external communication device 5 are all electronic control devices centered around a microcomputer equipped with a CPU, ROM, and RAM, just like ECU2. Furthermore, the number of microcomputers constituting ECU3, ECU4, and the external communication device 5 can be one or more.

[0047] Hereinafter, without special distinction, ECU2, ECU3, ECU4 and external communication device 5 will be referred to as vehicle-mounted devices 2 to 5.

[0048] Like the App Store 200 and Vehicle Sales DB300, the ECU is an electronic control device centered around a microcomputer equipped with a CPU, ROM, and RAM. The various functions of the microcomputer are implemented by the CPU executing programs stored on a non-transitional physical recording medium. In this example, the ROM is equivalent to the non-transitional physical recording medium storing the program. Furthermore, by executing this program, methods corresponding to the program are performed. In addition, one or more ICs or similar hardware components can constitute part or all of the functions executed by the CPU. Furthermore, the number of microcomputers constituting the ECU can be one or more.

[0049] The app store 200 is configured to communicate with at least the in-vehicle system 100 and the terminal device 400, and is a cloud server that manages service applications (hereinafter, applications) executed by the in-vehicle system 100. The app store 200 sells applications installed on the in-vehicle system 100, and collects application action logs indicating the application's operational status and API access logs indicating access status from the application to APIs from the in-vehicle system 100 where the applications are installed. Furthermore, the app store 200 generates application usage fee collection data and API usage fee collection data based on the application action logs and API access logs. The application usage fee collection data is used to collect application usage fees from application purchasers (hereinafter, users). The API usage fee collection data is used to collect API usage fees from application developers or operators (hereinafter, service providers).

[0050] The vehicle sales DB300 is configured to communicate with at least the terminal device 400, and is a cloud server that accumulates data related to vehicle sales and provides the accumulated data according to requests from the terminal device 400, etc.

[0051] Terminal device 400 is an electronic control device centered around a microcomputer including CPU 401, ROM 402, and RAM 403. Various functions of the microcomputer are implemented by CPU 401 executing programs stored on a non-transitional physical recording medium. In this example, ROM 402 is equivalent to a non-transitional physical recording medium storing the program. Furthermore, by executing this program, methods corresponding to the program are executed. Additionally, some or all of the functions executed by CPU 401 can be configured in hardware form by one or more ICs. Furthermore, the number of microcomputers constituting terminal device 400 can be one or more.

[0052] The terminal device 400 also includes a communication unit 404 and an input / output unit 405. The communication unit 404 conducts data communication with the application store 200 and the vehicle sales DB300, etc., via a wide-area wireless communication network. The input / output unit 405 includes various input devices for receiving input from the operator of the terminal device 400 and various output devices for displaying the results of processing in the terminal device 400 to the operator. Input devices may include a keyboard, pointing device, touch panel, microphone, etc. Output devices may include a display, speaker, printer, etc.

[0053] Terminal device 400 performs at least one metric calculation process. This metric calculation process collects information from the app store 200 and the vehicle sales DB300 and calculates API metrics. API metrics are used to evaluate each API in order to determine which API should be prioritized for backward compatibility when updating APIs installed in the vehicle. Details regarding the metric calculation process will be described later.

[0054] [2. Functional Structure]

[0055] The various functions of API evaluation system 1 are explained.

[0056] [2-1. In-vehicle system]

[0057] like Figure 2 As shown, the vehicle system 100 functions as an equipment management unit 10, a vehicle function module group 20, an API gateway 30, and a service provision unit 40. The functions of the vehicle system 100 are shared by each of the vehicle-mounted devices 2 to 5 belonging to the vehicle system 100.

[0058] [2-1-1. Equipment Management Department]

[0059] The Equipment Management Department manages various vehicle equipment mounted on vehicles.

[0060] The Equipment Management Department 10 operates the vehicle equipment according to the operating instructions from the Vehicle Functional Module Group 20 and notifies the Vehicle Functional Module Group of the operating results. The vehicle equipment may also include actuators, sensors, storage devices, HMI devices, etc. For example, if the vehicle equipment is an actuator, the operating results may indicate whether the actuator terminated normally or abnormally. If the vehicle equipment is a sensor, the operating results may also show the data detected by the sensor. If the vehicle equipment is a storage device, the result notification may also show the data read from the storage device.

[0061] The equipment management unit 10 can also be configured to, in addition to operating the vehicle equipment according to the operating instructions from the vehicle function module group 20, spontaneously detect the status of the vehicle equipment and notify the vehicle function module group.

[0062] [2-1-2. Vehicle Functional Module Group]

[0063] Vehicle function module group 20 is a collection of vehicle function modules, where each vehicle function module is a module that performs processing to realize various functions utilizing the vehicle equipment. The functions of the vehicle function modules are provided via application programming interfaces (hereinafter, APIs) 31. Vehicle function modules can also be classified according to the vehicle's actions that the service provision unit 40 can easily request, such as status recognition, motion system equipment control, Human Machine Interface (hereinafter, HMI) system equipment control, and body system equipment control.

[0064] State recognition corresponds to actions that identify the location of vehicles, pedestrians, and other conditions surrounding the vehicle itself. Vehicle functional modules classified as state recognition may control vehicle equipment (e.g., cameras and millimeter-wave sensors) that fall under the category of recognition control.

[0065] Motion system equipment control corresponds to the vehicle's driving system actions such as turning, driving, and stopping. Vehicle functional modules classified as motion system equipment control include vehicle equipment (e.g., actuators) belonging to braking control and steering control as control objects.

[0066] HMI system equipment control corresponds to vehicle actions associated with information prompts to the user. Vehicle functional modules classified as HMI system equipment control include, for example, vehicle equipment belonging to display control and voice control (e.g., displays, speakers, etc.) as controlled objects.

[0067] Body system equipment control corresponds to the actions of the vehicle's body systems in relation to the vehicle environment. Vehicle functional modules classified as body system equipment control include, for example, vehicle equipment belonging to lighting control, HVAC control, and seat control (e.g., actuators). HVAC is an acronym for heating, ventilation, and air conditioning systems.

[0068] [2-1-3. Service Provision Department]

[0069] Service provision unit 40 utilizes vehicle equipment managed by equipment management unit 10 to perform various functions, such as information collection, anti-theft, and remote operation, by executing application 41 downloaded and installed from application store 200. Multiple applications 41 may exist.

[0070] Application 41 basically utilizes the functions of various vehicle equipment to achieve the service for the purpose by accessing the vehicle function modules belonging to the vehicle function module group 20 via API gateway 30 and via API 31.

[0071] Users can purchase application 41 from app store 200. Applications purchased from app store 200 are installed on any of the in-vehicle devices 2-5. Furthermore, users can appropriately update or delete the application 41 installed on in-vehicle devices 2-5.

[0072] Furthermore, in the case of an application that provides services for obtaining vehicle information from multiple vehicles and analyzing vehicle behavior, driver driving operations, etc., the service provider that provides application 41 may obtain permission from the vehicle user to install application 41 on any one of the vehicle-mounted devices 2 to 5.

[0073] Application 41 can be installed not only on any of the vehicle-mounted devices 2 to 5, but also on an external device that is remotely connected to the vehicle-in-vehicle communication network 6 via the external communication device 5.

[0074] Service provision department 40 includes application management department 42 and application action log DB43.

[0075] The application management unit 42 appropriately performs the following processing: based on the monitoring results of the operation status of the application 41 installed in the vehicle, it generates an application action log and accumulates it in the application action log DB43, and uploads the accumulated application action log to the application store 200. The application management unit 42 and the application action log DB43 can also be distributed in all vehicle devices 2 to 5 that have the possibility of installing the application 41, or they can be integrated in any one of the vehicle devices 2 to 5.

[0076] like Figure 3 As shown, the application action logs accumulated in the application action log DB43 are stored in a correspondence with the "application ID". The "application ID" is the identifier of application 41 provided by the app store 200. The application action logs are categorized into basic data and processing data. The basic data is updated continuously based on the action status of application 41. The processing data is generated when the application action logs are uploaded to the app store 200. The application action log DB43 can also store only basic data.

[0077] Hereinafter, the application identified by the "Application ID" will be referred to as the object application.

[0078] The basic data includes "Application Execution Count," "Application Execution Time," "Monitoring Start Time," and "Final Execution Time." "Application Execution Count" is the number of times the target application is launched in the vehicle system 100. "Application Execution Time" is the time the target application is executed in the vehicle system 100. "Monitoring Start Time" indicates the time at which the count of "Application Execution Count" and the accumulation of "Application Execution Time" for the target application begin. "Final Execution Time" indicates the time when the target application was last executed. Furthermore, if the elapsed time from the time represented by "Final Execution Time" to the current time is longer than a preset inactivity allowable time, the "Application Execution Count" is set to a value indicating that the target application is inactive.

[0079] The processed data includes "application execution count per unit time" and "application execution time per unit time". The "application execution count per unit time" is calculated based on the "application execution count" included in the basic data and the period from the time indicated by the "monitoring start time" to the time of upload (hereinafter, 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. The unit of time can be, for example, every 24 hours, or every day. The processed data is normalized to allow for simple accumulation when statistically analyzing the "application execution count" and "application execution time" uploaded from multiple vehicle systems 100 to the app store 200.

[0080] Next, use Figure 4 The flowchart illustrates the application log management process performed by the Application Management Department 42.

[0081] If the vehicle system starts up to 100%, the application log management process will be executed repeatedly.

[0082] In S110, the application management unit 42 determines whether the application 41 belonging to the service provision unit 40 has been started. If the application 41 has been started, the processing is moved to S120. If the application 41 has not been started, the processing is moved to S140.

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

[0084] In the following S130, the application management unit 42 updates the "application execution count" and "final execution time" in the application action log stored in the application action log DB43 for the started application 41 and then ends the processing. Specifically, the application management unit 42 updates the "application execution count" by counting up by 1, and updates the "final execution time" based on the time information obtained in S120.

[0085] In S140, the application management unit 42 determines whether the application 41 belonging to the service provision unit 40 has stopped. If the application 41 has stopped, the processing is moved to S150; if the application 41 has not stopped, the processing is moved to S170.

[0086] In S150, the application management unit 42 obtains time information indicating the current time (i.e., the time when the application 41 stops).

[0087] In the next step, S160, the application management unit 42 updates the "application execution time" in the application action log stored in the application action log DB43 for the stopped application 41, and then terminates the process. Specifically, the application management unit 42 updates the application execution time by adding the time from application 41's start to stop, calculated based on the time information obtained in the previous steps S120 and S150, to the "application execution time" stored in the application action log DB43.

[0088] In S170, the application management unit 42 determines whether the log sending conditions for the application action log are met. If the log sending conditions are met, the processing is moved to S180; if the log sending conditions are not met, the processing ends. The log sending conditions for the application action log can be after a certain period (e.g., 1 day, 1 week, 1 month), or a specified date, or an upload instruction from the application store 200.

[0089] In S180, the application management unit 42 obtains time information indicating the current time (i.e., the time when the application action log is uploaded).

[0090] In the following S190, the application management unit 42 generates processing data based on the basic data of the application action log stored in the application action log DB43. Specifically, it calculates the monitoring time from the time shown in the "monitoring start time" of the basic data to the current time shown in the time information obtained in S180. Furthermore, it 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. Additionally, it calculates the non-running time from the time shown in the "final execution time" to the current time shown in the time information obtained in S180. Moreover, if the calculated non-running time exceeds the allowed time, it sets values ​​indicating inactivity for the "application execution count" and "application execution count per unit time" of the basic data.

[0091] In the following S200, the application management unit 42 sends (i.e., uploads) the application action log along with the time information obtained in S180 to the application store 200. Furthermore, the uploaded application action log can be all of the basic data and the processed data, or only the basic data or only the processed data. If only the basic data is uploaded, the processed data can also be generated on the application store 200 side.

[0092] In the following S210, the application management unit 42 resets the "application execution count," "application execution time," and "monitoring start time" in the basic data of the application action log stored in the application action log DB43, and then ends the processing. Specifically, the "application execution count" and "application execution time" are cleared to zero, and the "monitoring start time" is set to the time information obtained in S180.

[0093] Furthermore, this section explains that the timing for uploading application action logs is the same for all applications 41, but the timing for uploading can also vary for each application 41.

[0094] [2-1-4. API Gateway]

[0095] Return to Figure 2 API gateway 30 provides interfaces for connecting applications 41 to each other and for applications 41 to hardware. API gateway 30 includes an access control unit 31, an API management unit 32, and an API access log DB 33.

[0096] If the access control unit 31 receives an API access request (hereinafter, an API call) from the application 41, it determines whether the API call can be accepted based on the request format and the access permissions possessed by the caller. If the access control unit 31 determines that the API call can be accepted, it forwards the API call to the vehicle function module group 20. More specifically, it forwards the API call to the vehicle-mounted devices 2 to 5 where the vehicle function modules implementing API call processing are located. In addition, the access control unit 31 forwards the response (hereinafter, the API response) to the API call obtained from the vehicle function module group 20 to the calling application 41. If the access control unit 31 determines that the API call cannot be accepted, it abandons the API call. In this case, it may also notify the calling application 41 of the abandonment of the API call.

[0097] API Management Unit 32 executes the actions of Monitoring Access Control Unit 31, generates API access logs, and accumulates the generated API access logs into API Access Log DB33. Additionally, API Management Unit 32 appropriately performs the process of uploading the API access logs accumulated in API Access Log DB33 to Application Store 200.

[0098] API access logs can also utilize information recorded regarding charges levied on the caller of the API 41.

[0099] like Figure 5 As shown, the API access logs accumulated in the API access log DB33 are categorized and stored by each "API provider application ID", each "API-ID", and each "caller application ID".

[0100] "API Provider Application ID" is the identifier of the API provider application. The API provider application is the vehicle function module that provides the API. Since there are cases where the same API is provided by multiple API provider applications, the "API Provider Application ID" is used to identify which API provider application's API was used. In cases where the same API is provided by multiple API provider applications, this helps select which API provider's API to use, for example, in a way that reduces communication costs. "API-ID" is the identifier of the API. "Caller Application ID" is the identifier of the application that made the API call, i.e., the caller application 41.

[0101] API access logs include "API call count", "API execution completion count", "API execution not required count", "API execution exception count", and "API communication data volume".

[0102] "API Call Count" refers to the number of times an API call was made. "API Execution Completion Count" refers to the number of times an API call completed normally and the requested operation was fulfilled. "API Execution Required Count" refers to the number of times an API call completed normally, but the requested operation was already performed and then canceled. For example, receiving a request to open a window, but the window is already open, etc. "API Execution Error Count" refers to the number of times an API call failed to complete normally, or the number of times an API call completed normally but the requested operation was not fulfilled. "API Data Traffic" is the cumulative value of the amount of data obtained by the calling application through API calls.

[0103] In other words, the API access log records which application used which API, how much, and what the results were.

[0104] Next, use Figure 6 The flowchart illustrates the API log management process performed by the API Management Department 32.

[0105] If the vehicle system starts up to 100%, log management processing will be executed repeatedly.

[0106] In S310, the API management unit 32 determines whether the access control unit 31 has accepted the API call. If accepted, the processing is moved to S320; otherwise, the processing is moved to S330. Furthermore, the API call must contain at least the information of "API provider application ID," "API-ID," and "caller application ID."

[0107] In S320, the API Management Department 32 updates the "API call count" in the API access log stored in the API access log DB33 for the API that was called by the API and then ends the process. Specifically, the value of "API call count" is counted up by 1.

[0108] In S330, the API management unit 32 determines whether the access control unit 31 has forwarded the API response. If the API response has been forwarded, the processing is moved to S340; if the API response has not been forwarded, the processing is moved to S350.

[0109] In step S340, the API management unit 32 updates the API access log stored in the API access log DB33 based on the content of the API response to the API that has forwarded the API response, and then terminates the processing. Specifically, if the API response indicates that the processing based on the API call has been completed normally, the API management unit 32 updates the "API execution completion count". If the API response indicates that the processing based on the API call has not been completed normally, the "API execution exception count" is updated. In addition, if the processing based on the API call is completed normally but the requested operation is not required, the "API not required execution count" is updated. Furthermore, if data communication has been performed through the processing based on the API call, the "API communication data volume" is updated.

[0110] In step S350, the API management unit 32 determines whether the log sending conditions for the API access log are met. If the log sending conditions are met, the processing is moved to step S360; otherwise, the processing ends. The log sending conditions for the API access log can be the same as or different from the log sending conditions for the application action log.

[0111] In S360, the API Management Unit 32 obtains vehicle information containing information related to the vehicle model and target sales country. The target sales country is information indicating the region where the vehicle is sold. The vehicle information is obtained from information sources (e.g., the ECU of the body system). Vehicle information can be obtained using the API or through other methods. Vehicle information can be obtained from the information source each time, but it can also be obtained only once from the information source when the vehicle is started and stored in the API access log DB33, etc., and then obtained from the API access log DB33 thereafter.

[0112] In the following S370, the API Management Department 32 obtains time information indicating the current time (i.e., the time when the API access log was uploaded).

[0113] In the next step S380, the API Management Department 32 will send (i.e. upload) the data of the vehicle information obtained in S360 and the time information obtained in S370 to the API access log stored in the API access log DB33 to the application store 200.

[0114] In the following S390, the API Management Department 32 resets the API access log and terminates the process. After the reset, the values ​​of all items in the API access log are cleared to zero.

[0115] [2-2. App Store]

[0116] Return to Figure 2 The app store 200 has an app provision department 51, a log acquisition department 52, an information database 53, and a log database 54.

[0117] Application providing unit 51 downloads applications 41 stored in information DB53 to vehicle system 100, etc., based on requests from users or service providers. Application providing unit 51 accumulates the download count of each application 41, calculated by application ID, into information DB53 as part of the application information.

[0118] In addition to Application 41 and application information, DB53 also stores API security protection asset data.

[0119] like Figure 7 As shown, application information is categorized by "Application ID" and includes items such as "Number of Downloads", "Total Application Execution Time", "Application Rating", and "Number of API Uses".

[0120] "Download Count" represents the cumulative value obtained by counting the downloads of application 41, the object application identified by "Application ID," and the activity count, which represents the number of applications actually running. The activity count is a log statistic that includes the number of object applications not represented as inactive in the "Application Execution Count" or "Application Execution Count per Unit Time" sections of the application action log. In other words, the cumulative download count is updated every time application 41 is downloaded, and the activity count is updated every time an application action log is uploaded.

[0121] "Total Application Execution Time" is a log statistic that includes the "Application Execution Time" contained in the application action logs. In other words, the "Total Application Execution Time" is updated every time an application action log is uploaded.

[0122] "App ratings" refers to information indicating user feedback on an app. "App ratings" can include, for example, the results of statistical analysis of app reviews collected from app review websites. In other words, "app ratings" are updated based on the statistical results of the reviews.

[0123] "API Usage Count" indicates the number of times each API is called for all APIs used in the object application. "API Usage Count" is not the actual number of times the API is used, but rather the number of times the object application makes API calls, as requested by the service provider that registers the object application in the app store.

[0124] like Figure 8 As shown, API security asset data is data that establishes a correspondence between "API-ID" and "security asset data." "Security asset data" is defined from the perspective of attributes defined as security assets, namely S.F.O.P. S stands for Safety, referring to APIs that provide functions affecting security. F stands for Financial, referring to APIs that provide functions affecting the property of businesses or individuals. O stands for Operational, referring to APIs that provide functions affecting the operational performance of vehicles. P stands for Privacy, referring to APIs that provide functions affecting privacy information. API security asset data is generated by the manufacturers of the API-providing applications, etc. Figure 8 In the table shown, circles indicate influence.

[0125] The log acquisition unit 52 sequentially accumulates the application action logs and API access logs uploaded from the vehicle system 100 into the log DB 54, and updates the logs based on the application action logs. Figure 7 The application information shown includes "Number of Downloads" and "Total Application Execution Time". Application action logs can accumulate both basic and processed data, or only processed data.

[0126] In addition, such as Figure 9 As shown, in log DB54, the "API Access Log" is stored together with the "Upload Time", "Vehicle Model", and "Target Sales Country" uploaded from the vehicle system 100 along with the "API Access Log". Figure 9 The "API Access Log" contains Figure 5 The table shown is the whole.

[0127] [2-3. Vehicle Sales DB]

[0128] The vehicle sales DB300 is a cloud server that accumulates vehicle sales data. It provides the accumulated vehicle sales data based on requests from terminal devices such as the terminal device 400.

[0129] like Figure 10 As shown, the vehicle sales data accumulated in the vehicle sales DB300 includes items such as "Total Number of Units Sold" and "Period Since Mass Production Began" for each "Vehicle Category". In this embodiment, "Vehicle Category" is categorized by each "Model Type" and by each "Target Sales Country".

[0130] [2-4. Terminal Device]

[0131] Terminal device 400 is operated by the API administrator who manages the APIs, and at least performs API metric generation processing. API metric generation processing is the process of generating API metrics to prioritize APIs for maintaining backward compatibility when updating multiple APIs. Maintaining backward compatibility means that existing applications used before the update can continue to be used through the updated APIs.

[0132] use Figure 11 The flowchart illustrates the API metric generation process performed by the terminal device 400. The evaluation value generation process begins upon the operation of initiating the process by the terminal device 400.

[0133] In S410, terminal device 400 obtains application action logs and API access logs from application store 200.

[0134] In the next step S420, the terminal device 400 obtains vehicle sales data from the vehicle sales DB300.

[0135] In the next S430, such as Figure 12 As shown, the terminal device 400 calculates the "total number of executions of the first API" and the "total amount of the first API" by counting the "number of API calls" and "API fee amount" in the API access log for each "API-ID". The statistical results and calculation results can also be stored in RAM 403.

[0136] The "API fee amount" is calculated, for example, by statistically analyzing the "API call count," "API execution completion count," "API execution not required count," "API execution exception count," and "API communication data volume" contained in the API access logs for each "API-ID," and then summing these statistics using pre-defined weighting values. Additionally, the "total API fee amount" can also be obtained from an external server that determines the fee amount for each API based on the API access logs.

[0137] In the following S440, the terminal device 400 calculates API metrics based on the statistical results in S430. Specifically, the terminal device 400 keeps the "total number of first API executions" and "total first API fee amount" as API metrics, and calculates the "total first API usage rate" and "total first API execution rate".

[0138] "Total API Usage" is the number of times each application's API is used, calculated using the "Downloads" included in the application information, through formula (1). The "Downloads" are cumulative values.

[0139] [Formula 1]

[0140] (1)

[0141] "API Total Execution Rate" is the number of API executions per application within the average execution time. It is calculated using the "Total Application Execution Time" and "Number of Downloads" contained in the application information, through formula (2). Among them, the "Number of Downloads" uses the cumulative value.

[0142] [Equation 2]

[0143] (2)

[0144] In simple terms, API metrics calculated in this way give higher ratings to APIs with more executions, higher fees, higher usage rates, and higher execution rates, and these APIs are given higher priority for backward compatibility during API updates.

[0145] In the subsequent S450, such as Figure 13 As shown, the terminal device 400 counts the number of API calls in the API access log for each "Application ID" and each "API-ID". Furthermore, in equations (1) and (2), the statistical value of the number of API calls in this step is used instead of the total number of API executions to calculate the "API utilization rate" and "API execution rate" for each "Application ID" and each "API-ID". The statistical results and calculation results can also be stored in RAM 403.

[0146] In the following S460, the terminal device 400 calculates the "second total API utilization rate" and the "second total API execution rate" based on the "API utilization rate" and "API execution rate" calculated in S450 for each "application ID" and each "API-ID," as well as the "number of downloads" shown in the application information. The "second total API utilization rate" and the "second total API execution rate" are API metrics that take into account the "number of downloads."

[0147] Specifically, such as Figure 14 As shown, weighted values ​​are assigned based on the number of downloads, with higher weighted values ​​resulting from a larger number of downloads. Here, the number of downloads is divided into five stages: 0-500, 501-1000, 1001-5000, 5001-10000, and 10001, with weighted values ​​ranging from 1 to 5. The division of downloads and the values ​​of the weighted values ​​(hereinafter, download-related information) can be preset or set each time by the API administrator of the operating terminal device 400. When download-related information is preset, for example, information stored in the application store 200's information DB53 can be obtained, or it can be pre-stored in the ROM 402. Furthermore, based on... Figure 13 The table calculates the "API usage rate" and "API execution rate" in S450 based on the "download count" corresponding to each "Application ID". Figure 14 This example illustrates statistics for a single "API-ID". Here, we show the case where "API-ID" = 1. That is, for all "API-IDs", a value is created... Figure 14 The same statistical table. The statistical table can also be stored in RAM403.

[0148] By according to Figure 14 The statistics table based on "download count" shown in the upper paragraph uses a weighted sum of "API usage rate" and "API execution rate" for each "API-ID" to calculate the "second API usage rate" and "second total API usage rate". In other words, based on... Figure 14 The table above is calculated using 5×2+4×3+3×1+2×1+1×1. Figure 14 The table below shows the "Second API Total Usage" when "API-ID" = 1. Similarly, the "Second API Total Execution Rate" when "API-ID" = 1 is calculated using 5 × 10 + 4 × 20 + 3 × 5 + 2 × 2 + 1 × 2. The calculation result can also be stored in RAM 403.

[0149] API metrics calculated in this way prioritize APIs that are frequently used in applications downloaded to multiple vehicles, giving them higher ratings and increasing their priority for maintaining backward compatibility during API updates. As denoted by <1>, "API-ID" = 1. Figure 14 In the case of the table below, based on the "weighted sum of API utilization values", the priority order is <1> → <2> <4> → <5> → <3>. Additionally, based on the "weighted sum of API execution rates", the priority order is <2> → <1> → <4> → <5> → <3>.

[0150] In the following S470, the terminal device 400 calculates the "second total number of API executions" based on the "API usage rate" and "API execution rate" calculated in S450 for each "Application ID" and each "API-ID," as well as the "application evaluation" shown in the application information. The "second total number of API executions" is an API metric that takes into account the "application evaluation."

[0151] Specifically, such as Figure 15 As shown, the "application evaluation," where a higher evaluation value becomes a larger value, is used as a "weighted value." Here, a weighted value of 1 to 5 is used. The "weighted value" can be adjusted each time by the API administrator of the operating terminal device 400, etc. Furthermore, refer to... Figure 7 The statistical value of "API call count" is calculated in S450 based on the "evaluation of application" corresponding to each "application ID". Figure 15 This example illustrates a statistic for a single "API-ID". Here, we show the case where "API-ID" = 1. That is, for all "API-IDs", a value is created... Figure 15 The same statistical table. The statistical table can also be stored in RAM403.

[0152] By using a weighted sum of the "API call count" statistics based on the "application evaluation" statistical table, and then calculating the "total number of second API executions" for each "API-ID", the total number of API executions is determined. In other words, based on... Figure 15 The table above is calculated using 5×1000+4×5000+3×1000+2×200+1×100. Figure 15 The table below shows the "Total Execution Count of the Second API" where "API-ID" = 1. The calculation result can also be stored in RAM 403.

[0153] API metrics calculated in this way prioritize frequently used APIs that receive high user ratings, thus increasing their priority for backward compatibility during API updates. Figure 15 In the case of the table below, the priority order is <1>→<4>→<2>→<3>→<5>.

[0154] In the following S480, such as Figure 16 As shown, terminal device 400 counts the number of API calls and the amount of API fees in the API access log for each API ID and for each vehicle category (i.e., vehicle model and target country of sale). The statistical results can also be stored in RAM 403.

[0155] In the following S490, the terminal device 400 calculates "API execution count by category" and "API fee amount by category" based on the "API call count" and "API fee amount" calculated in S480 for each "API-ID" and each "vehicle category," as well as the "number of units sold" and "period since mass production" shown in the vehicle sales data. "API execution count by category" and "API fee amount by category" are API metrics that take into account the vehicle sales data.

[0156] Specifically, such as Figure 17 As shown, the "first multiplication rate" is allocated based on the "period from the start of mass production," where the longer the "period from the start of mass production," the smaller the "first multiplication rate." Here, it is 1.5 if it is less than 5 years, 1 if it is 5 years or more but less than 10 years, and 0 if it is 10 years or more. The information indicating the allocation method of the "first multiplication rate" (hereinafter, mass production period related information) can be preset or set each time by the API manager of the operating terminal device 400, etc. In the case of preset mass production period related information, for example, information stored in the vehicle sales DB300, etc., can be obtained, or it can be preset in ROM402. Moreover, by multiplying each of the "API usage rate" and "API fee amount" counted in S480 by the "number of units sold" corresponding to the "vehicle category" and the "first multiplication rate" corresponding to the "period from the start of mass production," the "number of executions by category" and the "fee amount by category" are calculated for each category that becomes a statistical unit.

[0157] For example, Figure 17 The table in the lower section shows the "Number of Executions by Category" when "API-ID" = 1, "Model Type" = A, and "Target Sales Country" = a. That is, based on... Figure 10 The table shows "Total Sales Units" and "Period from Start of Mass Production". Figure 16 The "API call count" shown and Figure 17 The "first multiplication rate" shown in the upper paragraph is calculated using 100 × 100,000 × 1.5. Similarly, the "charge amount by category" is calculated using 10,000 × 100,000 × 1.5. The calculation results can also be stored in RAM403.

[0158] APIs that are frequently used in vehicle categories with high sales volumes and short production cycles, and which also generate high revenue within those vehicle categories, will have higher calculated API metrics. In other words, APIs that maintain backward compatibility during updates and are expected to continue to be heavily used in the future will be prioritized. Conversely, if the production cycle is long, API usage is anticipated to decrease due to factors such as scrapped vehicles, and therefore, the "first multiplication rate" will be set to 0, making them excluded from evaluation. Furthermore, the statistical results of "execution count by category" and "revenue amount by category" calculated for each "API-ID" can also be used as API metrics.

[0159] In the following S500, the terminal device 400 calculates the "total number of third API executions" and the "total amount of third API charges", which are API metrics that take into account the "security protection assets".

[0160] Specifically, such as Figure 18 As shown, a "second multiplication rate" is assigned based on the category of "security protection asset". Here, S is set to 10, F to 5, O to 3, and P to 5. The information indicating the allocation method of the "second multiplication rate" (hereinafter, protection asset association information) can be preset or set each time by the API administrator of the operating terminal device 400. In the case of preset protection asset association information, for example, information stored in the information DB53 of the application store 200 can be obtained, or it can be preset in ROM 402. Then, the statistical values ​​of "API call count" and "API fee amount" counted in S430, i.e., "first API total execution count" and "first API total fee amount", are multiplied by the "second multiplication rate". As a result, "third API total execution count" and "third API total fee amount" are calculated for each "API-ID" that becomes a statistical unit. The calculation results can also be stored in RAM 403.

[0161] API metrics calculated in this way give high ratings to APIs that are frequently used and have an impact on SFOP’s perspective, and prioritize maintaining backward compatibility when updating APIs.

[0162] In the following S510, the terminal device 400 outputs the calculated API metrics to a display screen, etc., and then ends the processing. Alternatively, the terminal device 400 can also send the calculated API metrics to a server that accumulates API metrics, or to other terminal devices that utilize the API metrics.

[0163] API administrators can prioritize updates for each API to maintain backward compatibility, based on a single API metric or a combination of multiple API metrics.

[0164] [3. Correspondence of terms]

[0165] In this embodiment, the "total usage rate of the second API," "total execution rate of the second API," and "total number of executions of the second API" are equivalent to the application-related indicators of this disclosure. In this embodiment, the "number of API executions by category" and "fee amount by category" are equivalent to the sales-related indicators of this disclosure. In this embodiment, the "total number of executions of the third API" and "total fee amount of the third API" are equivalent to the security-related indicators of this disclosure. In this embodiment, S410-S420 are equivalent to the information acquisition unit of this disclosure, S430-S440 are equivalent to the basic indicator generation unit of this disclosure, and S450-S470 are equivalent to the application-related indicator generation unit of this disclosure. In this embodiment, S480-S490 are equivalent to the sales-related indicator generation unit of this disclosure, S500 is equivalent to the security-related indicator generation unit of this disclosure, and S510 is equivalent to the output unit of this disclosure. In this embodiment, the application store 200 is equivalent to the access log storage unit of this disclosure, and the vehicle sales DB300 is equivalent to the sales data storage unit of this disclosure.

[0166] [4. Effects]

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

[0168] In API evaluation system 1, API metrics are calculated based on the number of times an API is used, its usage frequency, application usage patterns, vehicle sales data, and the impact on security assets. By referring to these API metrics, the impact of each API on the applications using the API and the users of those applications can be quantified. Based on the magnitude of this impact, APIs that should be prioritized for maintaining backward compatibility can be easily selected.

[0169] This section explains the specific methods for extracting APIs that should maintain backward compatibility using various API metrics.

[0170] For example, firstly, extract the top 50% of APIs from all APIs based on their values ​​of API metrics that take into account the application's usage (i.e., "second API total usage rate" or "second API total execution rate"). In other words, extract APIs that are frequently used in applications used across multiple vehicles.

[0171] Next, from the first extraction API, we extract the top 50% of APIs whose values ​​take into account vehicle sales data (i.e., "API execution count by category" or "API fee amount by category") (hereinafter, the second extraction API). In other words, we extract APIs that are expected to be used extensively in the future.

[0172] Next, we extract the top 20% of APIs from all APIs based on their values ​​that take into account the impact on security protection assets (i.e., "Total Number of Third API Executions" or "Total Fees for Third API"). In other words, we extract the APIs that are important from the perspective of security protection assets.

[0173] Finally, the merged version of the second and third extraction APIs is set as the API that should maintain backward compatibility.

[0174] [5. Other implementation methods]

[0175] The embodiments of this disclosure have been described above, but this disclosure is not limited to the above embodiments and can be implemented in various ways.

[0176] (5a) In the above embodiment, as an API metric that takes into account the number of "downloads" of the application, a weighted sum of the statistical values ​​of "API usage rate" and "API execution rate" was used, but a weighted sum of the statistical values ​​of "API call count" could also be used. In addition, as an API metric that takes into account the "evaluation of the application", a weighted sum of the statistical values ​​of "API call count" was used, but a weighted sum of the statistical values ​​of "API usage rate" and "API execution rate" could also be used.

[0177] (5b) In the above embodiments, when calculating API metrics that take into account vehicle sales data, both “number of units sold” and “first multiplication rate” based on “the period from the start of mass production” are used, but either “number of units sold” or “first multiplication rate” may be used. Alternatively, instead of directly using the value of “number of units sold”, a “third multiplication rate” set based on the number of units sold may be used.

[0178] (5c) In the above embodiments, the API metrics considering security protection assets are not limited to "total number of first API executions" and "total first API fee amount". For example, the API metrics considering security protection assets can also be generated by multiplying any API metric other than "total number of first API executions" and "total first API fee amount" by a "second multiplication rate".

[0179] (5d) The vehicle-mounted devices 2-5, application store 200, vehicle sales DB300, terminal device 400 (hereinafter, control device group) and their methods described in this disclosure can also be implemented by a dedicated computer, which is provided by a processor programmed to perform one or more functions embodied in a computer program and a memory. Alternatively, the control device group and its methods described in this disclosure can also be implemented by a dedicated computer, which is provided by a processor composed of one or more dedicated hardware logic circuits. Alternatively, the control device group and its methods described in this disclosure can also be implemented by one or more dedicated computers, which are composed of a processor programmed to perform one or more functions and a memory, and a processor composed of one or more hardware logic circuits. In addition, the computer program can also be stored as instructions executed by a computer on a computer-readable non-transitional tangible recording medium. The method of implementing the functions of each part included in the control device group does not necessarily need to include software, and all its functions can be implemented using one or more hardware components.

[0180] (5e) Multiple functions of one component in the above embodiments can also be achieved by multiple components, or one function of one component can be achieved by multiple components. Alternatively, multiple functions of multiple components can be achieved by one component, or one function achieved by multiple components can be achieved by one component. Furthermore, a portion of the structure of the above embodiments can be omitted. Additionally, at least a portion of the structure of other above embodiments can be added to or replaced.

[0181] (5d) In addition to the API evaluation system described above, this disclosure can also be implemented in various forms such as a system that includes the API evaluation system as a component, a program for enabling a computer to function as the API evaluation system, a recording medium of a non-transitional entity such as a semiconductor memory that records the program, and an API evaluation index generation method.

[0182] [6. Technical concepts disclosed in this specification]

[0183] [Project 1]

[0184] An API evaluation system, comprising:

[0185] The information acquisition unit (400: S410~S420) acquires API access logs for an API based on a request from an application installed in the vehicle. The API is an interface used to provide vehicle functions, and the API access logs indicate the usage status of the API.

[0186] The sales-related metric generation unit (400: S480~S490) generates sales-related metrics based on log statistics. These log statistics are compiled by statistically analyzing API access logs for each vehicle category categorized according to vehicle sales data related to the aforementioned vehicles, and for each type of API. The sales-related metrics are API metrics that represent the magnitude of the impact of the API on the application and the users of the aforementioned vehicles.

[0187] Output section (400:S510) outputs the above sales-related indicators.

[0188] [Project 2]

[0189] An API evaluation system, comprising:

[0190] Access log storage unit (200) collects and accumulates API access logs from the vehicle for APIs based on requests from applications installed in the vehicle, wherein the API is an interface used to provide vehicle functions, and the API access logs indicate the usage status of the API.

[0191] Sales data storage department (300) accumulates vehicle sales data related to the sales of the aforementioned vehicles;

[0192] The information acquisition unit (400: S410-S420) acquires the API access log and the vehicle sales data from the access log storage unit and the sales data storage unit.

[0193] The Sales-Related Metrics Generation Department (400: S480-S490) generates sales-related metrics based on log statistics. These log statistics are compiled by statistically analyzing API access logs for each vehicle category categorized according to vehicle sales data and for each type of API. The sales-related metrics are API metrics representing the magnitude of the impact of the API on the application and the users of the vehicles.

[0194] Output section (400:S510) outputs the above sales-related indicators.

[0195] [Project 3]

[0196] According to the API evaluation system described in Project 1 or Project 2, wherein,

[0197] The aforementioned sales-related indicator generation unit calculates the aforementioned sales-related indicators by multiplying the multiplication rate set based on the aforementioned vehicle sales data with the aforementioned log statistics values ​​calculated for each of the aforementioned vehicle categories and for each type of the aforementioned API.

[0198] [Project 4]

[0199] According to any one of Projects 1 to 3, the API evaluation system, wherein,

[0200] The above vehicle categories are defined using at least one of the vehicle model and the sales region of the above vehicles.

[0201] [Project 5]

[0202] According to any one of Projects 1 to 4, the API evaluation system, wherein,

[0203] The aforementioned vehicle sales data includes the number of units sold for the aforementioned vehicles and at least one of the periods from the commencement of mass production of the aforementioned vehicles.

[0204] [Project 6]

[0205] According to any one of Projects 1 to 5, the API evaluation system, wherein,

[0206] The log statistics mentioned above include at least one of the number of API calls and the amount of API charges. The number of API calls refers to the number of times the application calls the API, and the amount of API charges is the amount of money charged to the provider of the application based on the amount of communication data used with the API.

[0207] [Project 7]

[0208] According to any one of Projects 1 to 6, the API evaluation system, wherein,

[0209] The aforementioned information acquisition department further acquires data indicating whether there is an impact on security protection assets for each type of the aforementioned API.

[0210] The aforementioned API evaluation system also includes a security correlation indicator generation unit (300: S500). This unit generates security correlation indicators by multiplying the multiplication rate set for each category of the aforementioned security protected assets with the aforementioned log statistics. These security correlation indicators are API indicators that take into account the impact on the aforementioned security protected assets.

[0211] [Project 8]

[0212] According to any one of Projects 1 to 7, the API evaluation system, wherein,

[0213] The aforementioned information acquisition unit also acquires application action logs containing the number of times the aforementioned application, installed in the aforementioned vehicle, was executed and the execution time.

[0214] The log statistics above include at least one of API usage rate and API execution rate. The API usage rate is the number of times the aforementioned API is used for each of the aforementioned applications, and the API execution rate is the number of times the aforementioned API is used per average execution time of the aforementioned application.

[0215] The aforementioned API evaluation system also includes an application-related metric generation unit (300: S450~S470). This unit generates application-related metrics based on log statistics. The log statistics are the results of API access logs for each type of application and each type of API. The application-related metrics are API metrics that take into account the usage of the applications.

[0216] [Project 9]

[0217] According to the API evaluation system described in Project 8, where...

[0218] The aforementioned application-related metric generation unit generates the aforementioned application-related metrics by weighting and summing the aforementioned log statistics values ​​using a weighted value set for each type of the aforementioned application based on the cumulative value of the aforementioned applications downloaded to the aforementioned vehicle.

[0219] [Project 10]

[0220] According to the API evaluation system described in Project 8 or Project 9, wherein...

[0221] The aforementioned application-related metric generation unit generates the aforementioned application-related metrics by weighting the aforementioned log statistics by using a weighted value set for each category of the aforementioned application based on user evaluations of the aforementioned application.

[0222] [Project 11]

[0223] According to any one of Items 1 to 10, the API evaluation system, wherein,

[0224] It also has a basic indicator generation department, which generates basic indicators based on log statistics. The log statistics are the results of the API access logs for each type of API. The basic indicators are API indicators that take into account the usage of the API.

Claims

1. An API evaluation system, comprising: The information acquisition unit (400: S410~S420) acquires API access logs for the API based on requests from applications installed in the vehicle. The API mentioned above is an interface used to provide vehicle functions, and the API access log indicates the usage status of the API. The sales-related metric generation unit (400: S480~S490) generates sales-related metrics based on log statistics. These log statistics are compiled by statistically analyzing API access logs for each vehicle category categorized according to vehicle sales data related to the aforementioned vehicles, and for each type of API. The sales-related metrics are API metrics that represent the magnitude of the impact of the API on the application and the users of the aforementioned vehicles. Output section (400:S510) outputs the above sales-related indicators.

2. An API evaluation system, comprising: The access log storage unit (200) collects and accumulates API access logs from the aforementioned vehicle based on requests from applications installed in the vehicle, wherein... The API mentioned above is an interface used to provide vehicle functions, and the API access log indicates the usage status of the API. Sales data storage department (300) accumulates vehicle sales data related to the sales of the aforementioned vehicles; The information acquisition unit (400: S410-S420) acquires the API access log and the vehicle sales data from the access log storage unit and the sales data storage unit. The Sales-Related Metrics Generation Department (400: S480-S490) generates sales-related metrics based on log statistics. These log statistics are compiled by statistically analyzing API access logs for each vehicle category categorized according to vehicle sales data and for each type of API. The sales-related metrics are API metrics representing the magnitude of the impact of the API on the application and the users of the vehicles. Output section (400:S510) outputs the above sales-related indicators.

3. The API evaluation system according to claim 1 or claim 2, wherein, The aforementioned sales-related indicator generation unit calculates the aforementioned sales-related indicators by multiplying the multiplication rate set based on the aforementioned vehicle sales data with the aforementioned log statistics values ​​calculated for each of the aforementioned vehicle categories and for each type of the aforementioned API.

4. The API evaluation system according to claim 1 or claim 2, wherein, The above vehicle categories are defined using at least one of the vehicle model and the sales region of the above vehicles.

5. The API evaluation system according to claim 1 or claim 2, wherein, The aforementioned vehicle sales data includes the number of units sold for the aforementioned vehicles and at least one of the periods from the commencement of mass production of the aforementioned vehicles.

6. The API evaluation system according to claim 1 or claim 2, wherein, The log statistics mentioned above include at least one of the number of API calls and the amount of API charges. The number of API calls refers to the number of times the application calls the API, and the amount of API charges is the amount of money charged to the provider of the application based on the amount of communication data used with the API.

7. The API evaluation system according to claim 1 or claim 2, wherein, The aforementioned information acquisition department further acquires data indicating whether there is an impact on security protection assets for each type of the aforementioned API. The aforementioned API evaluation system also includes a security correlation indicator generation unit (300: S500). This unit generates security correlation indicators by multiplying the multiplication rate set for each category of the aforementioned security protected assets with the aforementioned log statistics. These security correlation indicators are API indicators that take into account the impact on the aforementioned security protected assets.

8. The API evaluation system according to claim 1 or claim 2, wherein, The aforementioned information acquisition unit also acquires application action logs, which contain the number of times the aforementioned application installed on the aforementioned vehicle was executed and the execution time. The log statistics above include at least one of API usage rate and API execution rate. The API usage rate is the number of times the aforementioned API is used for each of the aforementioned applications, and the API execution rate is the number of times the aforementioned API is used per average execution time of the aforementioned application. The aforementioned API evaluation system also includes an application-related metric generation unit (300: S450~S470), which generates application-related metrics based on log statistics. The log statistics are the results of API access logs for each type of application and each type of API. The application-related metrics are API metrics that take into account the usage of the application.

9. The API evaluation system according to claim 8, wherein, The aforementioned application-related metric generation unit generates the aforementioned application-related metrics by weighting and summing the aforementioned log statistics values ​​using a weighted value set for each type of the aforementioned application based on the cumulative value of the aforementioned applications downloaded to the aforementioned vehicle.

10. The API evaluation system according to claim 8, wherein, The aforementioned application-related metric generation unit generates the aforementioned application-related metrics by weighting the aforementioned log statistics by using a weighted value set for each category of the aforementioned application based on user evaluations of the aforementioned application.

11. The API evaluation system according to claim 1 or claim 2, wherein, It also has a basic indicator generation department, which generates basic indicators based on log statistics. The log statistics are the results of the API access logs for each type of API. The basic indicators are API indicators that take into account the usage of the API.

12. A program that enables a computer to function as a functional unit: The information acquisition unit (S410-S420) acquires API access logs for the API based on requests from applications installed in the vehicle. The aforementioned APIs are interfaces that provide the functions of the aforementioned vehicles, and the API access logs indicate the usage status of these APIs. The sales-related metric generation unit (S480-S490) generates sales-related metrics based on log statistics. These log statistics are compiled by statistically analyzing API access logs for each vehicle category categorized according to vehicle sales data related to the aforementioned vehicles, and for each type of API. The sales-related metrics are API metrics that represent the magnitude of the impact of the API on the application and the users of the aforementioned vehicles. The output section (S510) outputs the aforementioned sales-related indicators.

Images