Mobility service providing method, mobility service providing system, server device, and program

Abstract

To provide a technology associated with a mobility service that causes a vehicle connected to a network to execute a variety of applications.SOLUTION: A cloud server 5 delivers a requested application to an edge-mounted vehicle satisfying a delivery requirement associated with the requested application. An edge device 3 executes the requested application delivered from the cloud server 5 using a resource of the edge-mounted vehicle, and informs the cloud server 5 of resource information associated with a use state of the resource related to execution of the requested application. The cloud server 5 generates first price information charged for a user providing the requested application and second price information charged for a holder of the edge-mounted vehicle according to resource information informed from the edge device 3.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a technology for effectively utilizing resources possessed by a connected car. [Background technology]

[0002] Patent Document 1 describes a technology for connecting a vehicle to a network and uploading and downloading various data between the vehicle and the network. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2010-200123 Summary of the Invention [Problem to be solved by the invention]

[0004] With the spread of mobility services, it is now possible to access vehicles via networks and realize various applications that utilize the functions and resources of the vehicles. For example, there may be service providers who want to run applications in desired vehicles and obtain the results.

[0005] One aspect of the present disclosure provides a technology related to a mobility service that allows vehicles connected to a network to execute various applications. [Means for solving the problem]

[0006] A mobility service providing method according to one aspect of the present disclosure provides a service in which an edge-equipped vehicle, which is a vehicle equipped with an edge device (3) that communicates with a server device (5), executes a requested application, which is an application registered in the server device. The server device determines, as a distribution destination vehicle, an edge-equipped vehicle that satisfies distribution requirements set in association with the requested application, and distributes the requested application to the edge device mounted in the distribution destination vehicle. The edge device executes the requested application distributed from the server device using resources provided in the edge-equipped vehicle, and notifies the server device of resource information related to the usage status of the resources related to the execution of the requested application. The server device generates, in accordance with the resource information notified by the edge device, first compensation information to be charged to a user who requested processing of the requested application and second compensation information to be charged to an owner of the edge-equipped vehicle that provided the resources.

[0007] According to this method, the edge-equipped vehicle can execute a requested application using the resources of the edge-equipped vehicle. Furthermore, according to this method, compensation can be demanded from both the resource user and the resource provider. Therefore, a new business can be provided that matches, for example, the desires of vehicle owners who want to make a profit by providing the resources of edge-equipped vehicles with the needs of program developers and others who are willing to pay a fee to use the processing power of the resources.

[0008] A mobility service providing system according to one aspect of the present disclosure includes a server device (5) and an edge device (3). The edge device is mounted on a vehicle and communicates with the server device. The edge device also includes an application execution unit (43) and a status notification unit (441). The application execution unit is configured to execute a requested application, which is an application distributed from the server device, using resources provided in the edge-equipped vehicle, with the vehicle mounted on the edge device being considered an edge-equipped vehicle. The status notification unit is configured to allow the edge-equipped vehicle, which is a vehicle mounted on the edge device, to grasp resource information regarding the usage status of resources related to the execution of the requested application and notify the server device. The server device includes an application distribution unit (642) and an application billing unit (643). The application distribution unit is configured to determine an edge-equipped vehicle that satisfies distribution requirements set in association with the requested application as a distribution destination vehicle, and distribute the requested application to the edge device mounted in the distribution destination vehicle. The application charging unit is configured to generate first compensation information to be charged to the user who requested the processing of the requested application and second compensation information to be charged to the owner of the edge-equipped vehicle that provided the resource, in accordance with the resource information notified from the edge device.

[0009] With this configuration, it is possible to obtain the same effects as those obtained by the above-described mobility service providing method. A server device according to one aspect of the present disclosure includes an application distribution unit (642) and an application billing unit (643), and constitutes the above-mentioned mobility service providing system together with the edge device. With this configuration, the above-mentioned mobility service providing system can be constructed together with the edge device.

[0010] An edge device according to one aspect of the present disclosure includes an application execution unit (43) and a status notification unit (441), and together with the server device, constitutes the above-described mobility service providing system. With this configuration, the above-described mobility service providing system can be constructed together with the server device.

[0011] A program according to an aspect of the present disclosure causes a computer included in the server device 5 to function as an application distribution unit 642 and an application billing unit 643. Such a program can realize each function of the server device. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a block diagram showing the configuration of a mobility IoT system. [Figure 2] FIG. 2 is a block diagram showing a configuration of an edge device. [Figure 3] FIG. 2 is a block diagram showing the configuration of a cloud server. [Figure 4] FIG. 2 is a functional block diagram of an edge device and a cloud server. [Figure 5] This is a state transition diagram of the rental infrastructure status. [Figure 6] FIG. 10 is a state transition diagram of a processing status. [Figure 7] FIG. 10 is a sequence diagram showing the operation of the application monitoring main module. [Figure 8] FIG. 10 is a sequence diagram illustrating the operation of an application management thread. [Figure 9] FIG. 10 is a sequence diagram illustrating the operation of an application management thread. [Figure 10] 10 is a table illustrating an example of a data structure of a processing status. [Figure 11] 10 is a table illustrating an example of a data structure of a user profile. [Figure 12] 10 is a list illustrating an example of a data structure of a configuration requirement specification profile. [Figure 13] 1 is a table illustrating an example of a data structure of a certificate. [Figure 14] 10 is a list illustrating an example of a data structure of a CE status. [Figure 15] FIG. 1 is an explanatory diagram showing an outline of the operation of the mobility IoT system under normal circumstances. [Figure 16] FIG. 1 is an explanatory diagram showing an outline of the operation of the mobility IoT system when applying for application registration. [Figure 17] FIG. 10 is an explanatory diagram showing an outline of the operation of the mobility IoT system during calculation of a request application. [Figure 18] FIG. 1 is an explanatory diagram showing an outline of the operation of the mobility IoT system when a self-contained application is normally terminated. [Figure 19] FIG. 10 is an explanatory diagram showing an outline of the operation of the mobility IoT system when a CL side interruption request is made. [Figure 20] FIG. 1 is an explanatory diagram showing an outline of the operation of the mobility IoT system when a vehicle-side interruption request is made. [Figure 21] FIG. 1 is an explanatory diagram showing an outline of the operation of the mobility IoT system when abnormal processing is detected. [Figure 22] FIG. 1 is an explanatory diagram showing an outline of the operation of the mobility IoT system regarding post-billing billing. [Figure 23] FIG. 1 is an explanatory diagram showing an outline of the operation of the mobility IoT system regarding advance charging and billing. DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. [1. Overall structure] The mobility IoT system 1 shown in Figure 1 includes multiple edge devices 3, a cloud server 5, and a user terminal 7. IoT is an abbreviation for Internet of Things. The mobility IoT system 1 corresponds to the mobility service providing system in the present disclosure, the method implemented in the mobility IoT system 1 corresponds to the mobility service providing method in the present disclosure, and the cloud server 5 corresponds to the server device in the present disclosure.

[0014] The edge device 3 is mounted on the vehicle and acts as an edge computer that acts as an intermediary between the vehicle and the cloud server 5, collecting vehicle information and controlling the vehicle. The cloud server 5 communicates with the edge device 3 via the wide area communication network NW, thereby managing a database that stores vehicle information provided by the edge device 3, and providing users with an interface for accessing the database and the edge device 3. Users, also called third parties, include application developers, application users, computing system users, etc.

[0015] The user terminal 7 is a terminal device used by a user of the mobility IoT system 1. The user terminal 7 accesses the cloud server 5 using a graphic user interface (hereinafter, GUI) provided by the cloud server 5.

[0016] Here, we will explain a configuration for realizing a service in the mobility IoT system 1 whereby a vehicle equipped with an edge device 3 (hereinafter referred to as an edge-equipped vehicle) can execute various programs by lending its resources to a person who wishes to use it. The resources refer to the computing resources of the CPU, and devices such as cameras and various sensors mounted on the vehicle. The method of providing various services to edge-equipped vehicles corresponds to the program execution service providing method in this disclosure.

[0017] [2. Edge Devices] [2-1. Hardware configuration] As shown in FIG. 2, the edge device 3 includes a wireless communication unit 31, a vehicle IF unit 32, a storage unit 33, and a control unit .

[0018] The wireless communication unit 31 communicates with the cloud server 5 via the wide area communication network NW by wireless communication. The vehicle IF unit 32 is connected to various in-vehicle devices via the in-vehicle network of the edge-equipped vehicle, etc., and acquires various information from the in-vehicle devices. The in-vehicle devices connected to the vehicle IF unit 32 include devices that are originally installed in the edge-equipped vehicle, as well as exterior devices that are added later.

[0019] The storage unit 33 stores vehicle information and the like that is acquired via the vehicle IF unit 32 and uploaded to the cloud server 5. The control unit 34 includes a CPU 341 and a semiconductor memory (hereinafter, referred to as memory) 342 such as a ROM and a RAM.

[0020] [2-2. Functional configuration] 4, the edge device 3 includes a vehicle communication management unit 41, a cloud communication management unit 42, an MIoT core unit 43, and a vehicle-side application management unit 44. The functions of these units 41 to 44 are realized by a CPU 341 executing a program stored in a memory 342.

[0021] The vehicle communication management unit 41 manages communication with on-board devices executed via the vehicle IF unit 32. The on-board devices include standard devices such as electronic control units and sensors that are normally installed in a vehicle, as well as exterior devices that are optionally retrofitted to the vehicle.

[0022] The cloud communication management unit 42 manages communication with the cloud server 5 executed via the wireless communication unit 31 . The MIoT core unit 43 provides a function as an edge computer that mediates between the cloud and the vehicle. Specifically, the MIoT core unit 43 provides a function to collect vehicle information of a vehicle equipped with the edge device 3 (hereinafter referred to as an edge-equipped vehicle) and upload it to the cloud server 5, and a function to control the edge-equipped vehicle according to instructions from the cloud server 5. The MIoT core unit 43 also provides a function to execute applications downloaded from the cloud server 5. In other words, the MIoT core unit 43 corresponds to an application execution unit in the present disclosure.

[0023] The MIoT core unit 43 includes hardware 431, middleware 432, a vehicle information database (hereinafter referred to as vehicle DB) 433, and an application 434. The hardware 431 includes the devices provided in the edge device 3, such as the CPU 341 and the memory 342, as well as the in-vehicle devices connected via the vehicle IF unit 32.

[0024] The middleware 432 abstracts the hardware 431 and includes basic software that provides various services necessary for executing the application 434, and drivers for supporting special processing that cannot be standardized. The basic software includes an operating system (hereinafter referred to as OS) and a hardware abstraction layer (hereinafter referred to as HAL). The drivers include a resource status (hereinafter referred to as RS) acquisition driver that acquires the status of the hardware 431. The OS kernel includes a system call processing unit M8 that processes system calls from the application 434.

[0025] The vehicle DB 433 is a database that stores vehicle information collected via the vehicle communication management unit 41 and provided to the cloud server 5, and is provided in the storage unit 33. The application 434 is a program that uses the functions provided by the middleware 432 to access the hardware 431 and realize various functions. The application 434 includes applications that are initially installed, as well as applications that are distributed from the cloud server 5 or the like. The distributed applications include applications that are requested for processing by users (hereinafter referred to as request applications). A plurality of applications 434 may be deployed at the same time.

[0026] The requested applications include non-vehicle-related jobs and vehicle-related jobs. Vehicle-related jobs are jobs that are to be executed in the vehicle and do not make sense if executed by a computer other than the vehicle. Non-vehicle-related jobs are jobs other than vehicle-related jobs.

[0027] Furthermore, there are two types of request applications: resident and self-contained. A resident request application is an application that repeatedly processes routine jobs such as monitoring and data collection for a specified period of time. A resident request application is collected by the cloud server 5 (i.e., deleted from the edge device 3) when an interruption request is received from the cloud server 5 or when abnormal processing is detected during the execution of the request application. Specifically, resident request applications are expected to monitor vehicle sensors, collect road information, collect weather information, and collect information when a vehicle accident occurs.

[0028] A complete-type requested application is an application that processes a non-routine job whose process ends with the output of the calculation result. Similar to the resident-type, a complete-type requested application is collected by the cloud server 5 upon an interruption request from the cloud server 5, upon detection of abnormal processing, or upon normal process completion. Specifically, a complete-type requested application is expected to be an application that requires large-scale parallel calculations such as simulations and mathematical and scientific calculations, high-speed calculations, or special-purpose calculation libraries.

[0029] The vehicle-side application management unit 44 includes a vehicle-side application monitoring unit 441. The vehicle-side application monitoring unit 441 provides a function of managing a requested application. As shown in Fig. 7, the vehicle-side application monitoring unit 441 includes an application monitoring main module M1, a vehicle state determination module M2, an ECU state determination module M3, and an application management thread M4. The application management thread M4 is provided for each installed request application. Furthermore, as shown in Fig. 8, the vehicle-side application monitoring unit 441 includes an order determination module M5, an application state determination module M6, and a continuation determination module M7.

[0030] The application monitoring main module (hereinafter referred to as the main module) M1 updates the rental infrastructure status according to the determination results from the vehicle state determination module M2 and the ECU state determination module M3. The main module M1 notifies the application management thread M4 associated with the requesting application that is the notification destination of these determination results and the notification from the cloud server 5 received via the cloud communication management unit 42.

[0031] Furthermore, the main module M1 mediates between each application management thread M4 and the cloud server 5 exchanges information including processing status, metadata, calculation results, and various notifications. The rental board status updated by the main module M1 has two states: "Not available for rental" and "Available for rental," as shown in Figure 5. The rental board status transitions depending on the vehicle state obtained from the vehicle state determination module M2 and the ECU state obtained from the ECU state determination module M3.

[0032] If the rental platform status is "Not available for rental," it indicates that the edge-equipped vehicle is unable to accept and execute the requested application. If the rental platform status is "Available for rental," it indicates that the edge-equipped vehicle is able to accept and execute the requested application.

[0033] The edge device 3 has a wake-up state in which all functions are available, and a sleep state in which the functions that can be provided are limited. The vehicle-side application monitoring unit 441 functions in the wake-up state, and the rental platform status immediately after transitioning to the wake-up state becomes "rental unavailable."

[0034] When the rental board status is "unavailable for rental", the main module M1 updates the rental board status to "available for rental" when rental preparation is complete and the vehicle state determination results and the ECU state determination results are both normal.When the rental board status is "available for rental", the main module M1 updates the rental board status to "unavailable for rental" when at least one of the vehicle state determination results and the ECU state determination results is abnormal.

[0035] The vehicle state determination module M2 determines whether the vehicle state is "normal" or "abnormal." The vehicle condition determination module M2 may determine an "abnormal" state when vehicle maintenance needs to be prioritized over providing the rental infrastructure, and may determine a "normal" state when the rental infrastructure is in a state where it can be provided.

[0036] The vehicle information referenced by the vehicle state determination module M2 may include the voltage of the vehicle battery device that receives power supply from the edge device 3, whether there is access contention with exterior devices, whether an advanced driver assistance system (hereinafter referred to as "ADAS") function including automatic braking and obstacle avoidance is activated, etc. The vehicle information referenced by the vehicle state determination module M2 may also include the detection value of an acceleration sensor that detects sudden braking and collisions, the position of a shift lever for detecting a parking state, whether a diagnostic trouble code (hereinafter referred to as "DTC") has been issued, etc.

[0037] The judgment logic used in the vehicle state judgment module M2 is selected for the purpose of detecting the possibility that the lending of the edge device 3 may hinder safe driving of the vehicle, and there may be various design concepts for each vehicle.

[0038] In one example of the determination logic used in the vehicle state determination module M2, the condition for determining that the vehicle state is "normal" may include the condition that the shift lever of the host vehicle is in "Park (P)." In this case, the condition for lending resources is limited to a stopped vehicle, so that the requesting app can be prevented from interfering with the execution of a process that may affect safety while driving.

[0039] In one example of the determination logic used in the vehicle state determination module M2, the condition for determining that the vehicle state is "abnormal" may include the voltage of the vehicle battery falling below a certain threshold. In this case, it is possible to prevent the vehicle battery from being consumed due to the lending of resources, which could prevent the vehicle's core functions, such as starting the engine and the ECU, from being disabled. In this case, the lending of resources is not limited to vehicles that are stopped, but can also be applied to vehicles that are moving.

[0040] In one example of the determination logic used in the vehicle state determination module M2, the condition for determining that the vehicle state is “normal” may include the fact that the ADAS function is not activated in the host vehicle. In this case, when performing highly urgent vehicle control such as automatic braking or obstacle avoidance, such highly urgent vehicle control can be prioritized over the processing of the requesting application.

[0041] The determination logic used in the vehicle state determination module M2 may be designed by the automobile manufacturer or the user. Furthermore, the function of the vehicle state determination module M2 not only differs for each vehicle or user, but also needs to respond immediately to changes in the vehicle state. Therefore, although it is intended to be located on the edge device 3 side, it may also be located on the cloud server 5 side.

[0042] The ECU state determination module M3 determines whether the state of the edge device 3 is "normal" or "abnormal," and also determines the "load status" of the edge device 3. The "load status" may be expressed in two stages, "high load" and "low load," or may be expressed in multiple stages of three or more stages.

[0043] The ECU status determination module M3 determines the status of the edge device 3 as "abnormal" if there is a possibility that the status of the edge device 3 may be impaired or that the safe operation of the vehicle may be impaired, and determines the status as "normal" if this does not apply.

[0044] The result of the "load status" determination may be used, for example, to adjust the load balance between edge devices 3 when the cloud server 5 selects a destination vehicle, which is an edge-equipped vehicle to which the requested application will be delivered.

[0045] The function of the ECU state determination module M3 is determined by the performance of the edge device 3, so it is assumed that it will be disposed on the edge device 3 side, but it may also be disposed on the cloud server 5 side. The information referenced by the ECU state determination module M3 may include the voltage of the auxiliary battery, the temperatures of the central processing unit and the graphics processing unit, the operating frequency of the cores, and the presence or absence of an abnormal signal from an exterior device connected to the edge device 3. The information referenced by the ECU state determination module M3 may also include information for the purpose of maintenance management, such as software updates for the OS, middleware, hardware drivers, and security software provided in the edge device 3, or software updates for other in-vehicle ECUs.

[0046] The judgment logic used in the ECU state judgment module M3 is designed based on the criterion of detecting the possibility that the lending of resources managed by the edge device 3 may hinder safe driving of the vehicle, and various design concepts may be used depending on the type of vehicle.

[0047] In one example of the determination logic used in the ECU state determination module M3, detecting an abnormal temperature in the central processing unit or the graphics processing unit may be included in the conditions for determining an "abnormality." In this case, it is possible to prevent fires caused by heat generated by hardware included in the edge device 3, and ultimately vehicle fires.

[0048] In one example of the judgment logic used in the ECU status judgment module M3, the conditions for judging an abnormality may include a situation in which the edge device 3 is unable to provide resources, such as when a maintenance management procedure such as a software update is being performed.

[0049] In one example of the judgment logic used in the ECU status judgment module M3, the conditions for judging an abnormality may include detecting an abnormality in the operating frequency of the core or the external device, or other resource conditions that may prevent the normal processing of the requested application from being completed.

[0050] The application management thread M4 schedules the allocation of CPU processing time using an order determination module M5 based on the priority set for the requesting application. The application management thread M4 also outputs a command to the kernel's system call processing unit M8 to execute the requested application according to the scheduling results. The application management thread M4 also uses a continuation determination module M7 to determine whether to continue the requested application based on the vehicle status and ECU status notified from the main module M1, the CL-side stop request notified from the cloud server 5, and the determination result from the application status determination module M6. The application management thread M4 updates the processing status according to the determination result of the continuation determination, and executes processing according to the processing status. The processing status indicates the processing status of the requesting application, and is set for each requesting application.

[0051] As shown in Figure 6, the processing status has six states: "Preparing for calculation," "Calculation processing," "Normal termination processing," "Stop processing 1," "Stop processing 2," and "Stop processing 3." Note that "Stop processing 1," "Stop processing 2," and "Stop processing 3" are collectively referred to as "Stop processing in progress." Although all of these are stop processing, stop processing 1 to 3 are distinguished by the transition conditions to the stop processing, etc.

[0052] If the processing status is "preparing for calculation", the application management thread M4 executes calculation preparation processing, including preprocessing such as initializing the application monitoring process and verifying the certificate, and when the calculation preparation processing is completed, it updates the processing status to "calculation processing in progress".

[0053] If the processing status is "during calculation processing," the application management thread M4 executes calculation processing. Furthermore, if the continuation determination module M7 determines that the requested application has terminated normally during "during calculation processing," the application management thread M4 updates the processing status to "normal termination processing in progress." Furthermore, if the application management thread M4 receives a CL stop request from the cloud server 5 during "during calculation processing," the application management thread M4 updates the processing status to "stop processing 1." If the application state determination module M6 determines that the requested application is in an abnormal state during "during calculation processing," the application management thread M4 updates the processing status to "stop processing 2." If the main module M1 notifies the application management thread M4 of an abnormal vehicle state or an abnormal ECU state during "during calculation processing," the application management thread M4 updates the processing status to "stop processing 3."

[0054] If the processing status is "normal termination processing in progress", the application management thread M4 executes normal termination processing, and when the normal termination processing is completed, updates the processing status to "preparing for calculation".

[0055] When the processing status is "Stop Processing 1," the application management thread M4 executes the first stop processing, which is the stop processing upon normal termination, and when the first stop processing is completed, updates the processing status to "Preparing for calculation."

[0056] If the processing status is "Stop Processing 2," the application management thread M4 executes a second stop processing to suspend the processing in a resumable state, and when the second stop processing is completed, it updates the processing status to "Preparing for calculation."

[0057] If the processing status is "Stop Processing 3," the application management thread M4 executes the third stop processing, which is the stop processing in the event of an abnormal termination, and when the third stop processing is completed, updates the processing status to "Preparing for calculation."

[0058] [2-3. Application monitoring main module processing] The processing executed by the main module M1 will be explained below with reference to the state transition diagram of the rental infrastructure status shown in FIG. 5 and the sequence diagram of FIG.

[0059] After completing initialization (S1) by starting the system, the main module M1 sets the rental base status to "rental stopped" (S2). After that, the main module M1 obtains the vehicle state determination result from the vehicle state determination module M2 by polling (S3), and obtains the ECU state determination result from the ECU state determination module M3 (S4).

[0060] The main module M1 updates the rental board status according to a combination of the acquired vehicle state determination results and ECU state determination results (S5). Specifically, the main module M1 updates the rental board status to "Available for Rental" when the "vehicle state" determined by the vehicle state determination module M2 and the "ECU state" determined by the ECU state determination module M3 are both "normal." Furthermore, the main module M1 updates the rental board status to "Not Available for Rental" when at least one of the "vehicle state" and the "ECU state" is "abnormal." Note that the "load status" determination result by the ECU state determination module M3 is not used to update the rental board status. The "load status" is notified to the cloud server 5 and is used on the cloud server 5 side, for example, when determining a destination vehicle, which is an edge-equipped vehicle to which the requested application will be delivered from the perspective of load balancing.

[0061] If there is at least one application management thread M4, the main module M1 notifies each application management thread M4 of the acquired "vehicle state" and "ECU state" (S6).

[0062] When the rental infrastructure status is "available for rental," the main module M1 checks whether an application distribution notification indicating that the requested application is being distributed has been received from the cloud server 5 via the cloud communication management unit 42 (S7).

[0063] When the main module M1 confirms that the application distribution notification has been received, it performs authentication using the certificate attached to the request application (S8). If the authentication of the certificate is successful, the main module M1 starts an application management thread that manages the execution of the request application associated with the application distribution notification (S9). The certificate has the contents shown in FIG. 13, the details of which will be described later.

[0064] [2-4. Application management thread processing] The processing executed by the application management thread M4 will be described with reference to the state transition diagram of the processing status shown in FIG. 6 and the sequence diagrams shown in FIGS.

[0065] When the application management thread M4 is started by the main module M1, it sets the processing status of the requested application to "preparing for calculation" (S11). The application management thread M4 executes an initialization process to apply the distributed requested application to the vehicle so that it can be executed using the function provided by the MIoT core unit 43 (S12).

[0066] The application management thread M4 obtains an order list representing a schedule for allocating CPU processing time by requesting the order determination module M5 to determine the processing order (S13). If the priority option item of the certificate is set to "Priority", the order determination module M5 sets the order list so that more processing time than usual is allocated.

[0067] The application management thread M4 issues a system call to allocate CPU processing time to each application, including the requesting application, according to the acquired order list (S14). The system call is issued to a system call processing unit M8 in the kernel of the OS included in the middleware 432. Thereafter, the requesting application is started by the OS and executes a predetermined operation.

[0068] After starting the requested application, the application management thread M4 updates the processing status to "calculation processing in progress" (S15). In other words, the processes of S12 to S14 are calculation preparation processes for preparing the execution environment of the requested application distributed from the cloud server 5.

[0069] When the processing of the requested application is started, the application management thread M4 repeats the processing of S16 to S21 described below and an interference processing for intervening in the execution of the requested application. The application management thread M4 checks whether a CL-side interruption request notification has been received from the cloud server 5 (S16). The application management thread M4 also checks the "vehicle status" and "ECU status" notified by the main module M1 (S17).

[0070] The application management thread M4 inquires of the application state determination module M6 about the state of the requested application associated with the application management thread M4 (hereinafter referred to as the application state), and obtains a determination message indicating the determination result of the application state (S18).

[0071] The application state determination module M6 determines whether the application state is "normal," "abnormal," or "normal termination." The application state determination module M6 determines the application state as "normal" if the calculation processing based on the requesting application is proceeding normally, determines the application state as "abnormal" if suspicious behavior is detected in the calculation processing, and determines the application state as "normal termination" if the calculation processing has terminated normally.

[0072] The criteria for determining "normal" may include that the CPU usage rate by the requesting application is lower than a reference value, that the memory usage rate is lower than a reference value, that the communication buffer usage rate is lower than a reference value, etc. The criteria for determining "normal" may also include that neither a memory leak nor unauthorized access to an area outside the permitted memory has occurred, that there has been no access to an exterior device other than that specified, that there has been no access to information without the permission of the vehicle owner, that there has been no unauthorized data transmission to the outside, etc.

[0073] The application state determination module M6 may acquire resource status information to be referenced in determining the application state by requesting an RS acquisition driver included in the middleware 432. The resource status information may include an average CPU usage rate, an average memory usage rate, a maximum CPU usage rate, a maximum memory usage rate, and usage time for each external device, as shown in Fig. 10. The resource status information corresponds to the resource information in the present disclosure.

[0074] The average and maximum CPU usage rates are the average and maximum usage rates of the CPU that executed the requesting application. The average and maximum memory usage rates are the average and maximum usage rates of the memory used when the requesting application was executed. The external device usage time indicates the time the external device was used by the requesting application, and if multiple external devices are used, it is recorded for each external device. The resource status information may further include accessed memory addresses, communication volume, communication buffer usage rate, etc.

[0075] The application management thread M4 inputs information such as whether or not there is a CL side stop request, the vehicle state, the ECU state, the application state, etc. to the continuation determination module M7, and obtains a determination message from the continuation determination module M7 indicating the continuation determination result regarding the continuation of the application (S19).

[0076] If the application state is abnormal, the continuation determination module M7 sets the continuation determination result to "abnormal application state." If at least one of the "vehicle state" and "ECU state" is abnormal, the continuation determination module M7 sets the continuation determination result to "abnormal vehicle state / ECU state." If there is a CL side interrupt request, the continuation determination module M7 sets the continuation determination result to "CL side interrupt request."

[0077] If the requested application is a self-contained application and the application status is "normal termination", the continuation determination module M7 determines the continuation determination result as "normal termination". If none of the above continuation determination results apply, the continuation determination module M7 determines the continuation determination result as "continue".

[0078] The process (S31) in which the main module M1 notifies the application management thread M4 of the "vehicle state" and "ECU state" acquired by its own process, and the confirmation and determination processes S16 to S19 in the application management thread M4 are repeatedly executed in parallel. Furthermore, when the main module M1 receives a CL stop request or a monitoring cancellation request from the cloud server 5 via the cloud communication management unit 42, it executes processes S32 and S33 in which it transfers these to each application management thread M4.

[0079] If the requested application to be managed is a self-contained or resident application and the calculation results need to be periodically transmitted to the cloud server 5, the application management thread M4 transmits the calculation results to the cloud server 5 via the cloud communication management unit 42 at an arbitrary event timing (S20). In addition, the application management thread M4 transmits a processing status notification to the cloud server 5 via the cloud communication management unit 42 at an arbitrary event timing for the purpose of updating the processing status held by the cloud server 5 (S21). As shown in FIG. 10, the processing status notification may include, in addition to resource status information, a serial number, notification time, application ID, processing priority, vehicle state, ECU state, CL-side stop request, processing status, etc. The serial number is a number that uniquely identifies the processing status notification sent for the requested application. The notification time is the time when the processing status notification is notified. The application ID is an identification number assigned to the requesting application. The processing priority is a value assigned to the requesting application by the user of the distributor. The vehicle state, ECU state, and CL-side stop request are information notified from the main module M1 to the application management thread M4. The processing status is a status updated by the application management thread M4.

[0080] If the continuation determination result of the continuation determination module M7 is "continue," the application management thread M4 repeatedly executes the monitoring process shown in S16 to S21. If the continuation determination result is anything other than "continue," the application management thread M4 executes interference processing described below, then notifies the main module M1 of the end of the thread, and ends the process.

[0081] As shown in FIG. 9, the application management thread M4 executes different interference processing depending on the result of the continuation determination. If the continuation determination result is "normal completion", the application management thread M4 updates the processing status to "normal completion" (S41) and transmits a processing status notification to the cloud server 5 (S42). In addition, the application management thread M4 transmits the calculation result of the requested application together with a completion notification to the cloud server 5 (S43).

[0082] If the continuation determination result is "abnormal application state," the application management thread M4 updates the processing status to "stop processing in progress / stop processing 2" (S44) and executes processing to stop the requested application (S45). Thereafter, the application management thread M4 transmits an application abnormality processing notification indicating that processing has been stopped due to the "abnormal application state" to the cloud server 5 (S46), and also transmits a processing status notification to the cloud server 5 (S47).

[0083] If the continuation determination result is "vehicle state / ECU state abnormality," the application management thread M4 updates the processing status to "stop processing in progress / stop processing 3" (S48) and executes processing to stop the requesting application (S49). Thereafter, the application management thread M4 transmits a vehicle-side interruption notification indicating that processing has been stopped due to the "vehicle state / ECU state abnormality" to the cloud server 5 (S50), and also transmits a processing status notification and a metadata notification to the cloud server 5 (S51).

[0084] If the continuation determination result is "CL-side interruption request," the application management thread M4 updates the processing status to "stop processing in progress / stop processing 1" (S52) and executes processing to stop the requesting application (S53). Thereafter, the application management thread M4 transmits an interruption completion notification indicating that the processing has been stopped in response to the "CL-side interruption request" (S54), and also transmits a processing status notification and a metadata notification to the cloud server 5 (S55).

[0085] The metadata transmitted by the metadata notification may include a group of restart data necessary to restart the requesting application from the interrupted position, a group of diagnostic data necessary to identify the cause of an abnormality or high load, etc. The group of restart data and the group of diagnostic data may include an executable file, a parameter set for various calculation management at the time of interruption, a physics parameter set at the time of interruption, etc.

[0086] The application management thread M4 checks whether there is a monitoring cancellation request from the cloud server 5 (S56). If the application management thread checks that there is a monitoring cancellation request, it deletes the requested application (S57), sends a management cancellation completion notification to the cloud server 5 (S58), and stops processing.

[0087] [3. Cloud Server] [3-1. Hardware configuration] As shown in FIG. 3, the cloud server 5 includes a communication unit 51, a storage unit 52, and a control unit 53.

[0088] The communication unit 51 communicates with the edge device 3 and the user terminal 7 via the wide area communication network NW. The storage unit 52 is used as a database that accumulates the vehicle information acquired via the communication unit 51 and uploaded from each of the plurality of edge devices 3.

[0089] The control unit 53 includes a CPU 531 and a semiconductor memory (hereinafter, referred to as memory) 532 such as a ROM and a RAM. [3-2. Functional configuration] 4, the cloud server 5 is divided into blocks according to function and includes a GW / communication management unit 61, a GUI / dashboard 62, a service core unit 63, and a CL-side application management unit 64. The functions of these units 61 to 64 are realized by a CPU 531 executing a program stored in a memory 532.

[0090] The GW / communications management unit 61 associates the vehicle information uploaded through communication with the edge device 3 with the vehicle position where the vehicle information was acquired, etc., and creates a shadow DB, which is a database that accumulates the information for each vehicle.

[0091] The GUI / dashboard 62 provides a graphic interface used when accessing the cloud server 5 via the user terminal 7 . The service core unit 63 includes an API unit 631, a user authentication unit 632, and a database management unit (hereinafter referred to as DB management unit) 633.

[0092] The API unit 631 provides an API for app development and the like for users who develop applications using the mobility IoT system 1. API stands for Application Programming Interface. The API unit 631 provides an API for accessing the shadow DB to acquire vehicle information, an API for accessing the edge device 3 to acquire information directly from the vehicle equipped with the edge device 3, an API for controlling the vehicle equipped with the edge device 3, and the like.

[0093] The user authentication unit 632 provides a function for authenticating a user who uses the API unit 631 . The DB management unit 633 provides a function for realizing access to the shadow DB in response to a request from the API unit 631 .

[0094] The CL-side application management unit 64 includes an application authentication unit 641 , an application distribution unit 642 , an application billing unit 643 , and a CL-side application monitoring unit 644 . The application authentication unit 641 provides a function for authenticating the safety of an application developed by a user, and issues a certificate to the authenticated application.

[0095] Applications are authenticated by evaluating them against various evaluation criteria, including power consumption, excessive load on external devices, excessive memory access and consumption, interference with core systems, and the user's past history of unauthorized use. If the evaluation results for all of these evaluation criteria are within the acceptable range, a certificate is issued.

[0096] The application authentication unit 641 stores and manages the user profile and deployment specification request profile provided by the user when requesting authentication of an application, and the certificate issued for the authenticated application in a user DB, deployment specification DB, and certificate DB, respectively. The user DB, deployment specification DB, and certificate DB are provided, for example, in the storage unit 52. An application that is registered by being authenticated by the application authentication unit 641 becomes a requested application to be distributed to edge-equipped vehicles. The application authentication unit 641 not only manages the registration of requested applications, but also manages updates, deletions, etc.

[0097] The application authentication unit 641 registers, updates, and deletes a requested application at the request of the user who created the requested application. The application authentication unit 641 also forcibly revokes the certificate and deletes the registration of a requested application that has engaged in unauthorized behavior at the distribution destination.

[0098] The user profile is information for linking the requesting application with the user. As shown in Fig. 11, the user profile may include the application ID, certificate number, deployment requirement specification profile ID, certificate status, destination edge ID, user ID, registered user name, financial institution name, financial institution account number, and charge amount at the time of priority processing request.

[0099] The app ID is an identification number uniquely assigned to a requesting app, which is an authenticated application. The certificate number is the number of the certificate issued to the requesting app (hereinafter referred to as the target app) identified by the app ID. The deployment requirement specification profile ID is an identification number assigned to the deployment requirement specification profile linked to the target app. The certificate status indicates whether the certificate identified by the certificate number is valid or invalid. The destination edge ID is an identification number assigned to the edge device 3 to which the target app is to be delivered. The user ID is an identification number assigned to the user who requested registration of the target app. The registered user name is the registered name of the user identified by the user ID. The transaction financial institution name and transaction financial account number are the name and account number of the financial institution used for charging and paying the user identified by the user ID. The charge amount when priority processing is requested is the charge amount when the user requests priority processing for the execution of the requesting app.

[0100] The deployment requirement specification profile is information indicating distribution requirements, which are requirements imposed on the distribution destination of the requested application. As shown in Fig. 12, the deployment requirement specification profile may include a deployment requirement specification profile ID, a user ID, an application ID, a certificate number, a priority option, a deployment environment option, etc.

[0101] The deployment requirement specification profile ID, user ID, application ID, and certificate number are explained in the user profile, so explanation will be omitted. However, the application ID indicated in the user profile is an identification number of the requested application (i.e., the application of interest) linked to the deployment requirement specification profile identified by the deployment requirement specification profile ID. The user ID and certificate number are information that identify the user and certificate number linked to the application of interest. The priority option is information that indicates whether or not to allow use of a function that sets the processing priority of the application of interest.

[0102] The deployment environment options indicate requirements necessary for executing the target application, etc. The deployment environment options may include vehicle static requirements and vehicle dynamic requirements, which are delivery requirements for the edge-equipped vehicle, and edge static requirements and edge dynamic requirements, which are delivery requirements for the edge device 3.

[0103] Vehicle static requirements may include basic vehicle information such as VIN, vehicle model, year and type, exterior equipment, modified parts, optional equipment, and fuel type. VIN stands for Vehicle Identification Number and is a number that can identify the vehicle manufacturer, vehicle model, and year. In addition to this basic vehicle information, vehicle static requirements may also include vehicle usage history information and owner information. Vehicle usage history information includes accident history, accident cause, years of ownership, and previous owners. Owner information includes the age and gender of the vehicle owner, years of ownership, the industry and business type of the owning corporation, and the number of vehicles owned by the corporation.

[0104] Vehicle dynamic requirements may include vehicle interior environment information, vehicle exterior environment information, vehicle status information, device and function usage information, occupant information, time-series data information, etc. Vehicle environment information includes, for example, vehicle interior temperature, humidity, smoking, odors, interior dirt, load weight, and items inside the vehicle. Vehicle exterior environment information includes, for example, temperature, rainfall, humidity, air pressure, dense fog, snowfall, wind pressure, road surface conditions, surrounding vehicle information, surrounding pedestrian information, presence or absence of construction work, white lines and road signs, animal traffic, outside air pollution (e.g., fire, factory accident, chemical contamination), presence or absence of accidents, wanted vehicle status, wanted person passing, emergency vehicle passing, submersion, airborne objects, and vehicle location (e.g., country, prefecture, highway, urban area, industrial area, suburban area, underground / aboveground, specific area). Vehicle status information includes, for example, parking status, engine status, abnormal status, remaining fuel, vehicle speed, acceleration / deceleration, shift lever position, accelerator position, engine RPM, yaw rate, and brake pressure. Device / function usage information includes, for example, wipers, turn signals, lamps, seat position, door opening / closing, locks, acceleration / deceleration, sudden steering / steering, automatic parking function usage frequency, cruise control, autopilot, horn usage frequency, air conditioning usage frequency, window opening / closing rate, shift lever operation, ADAS function, and light usage frequency / time. Occupant information includes, for example, number of passengers, passenger age, passenger gender, passenger health status, passenger psychological state, occupancy rate, riding time, continuous riding time, operating rate, operating time length, passenger boarding / exiting time / pattern, in-vehicle media usage frequency / content, and driving habits. Time series data information includes, for example, time series data of the above-mentioned parameters.

[0105] The edge static requirements may include basic edge information such as RAM / ROM capacity, CPU type, clock, number of cores, operating frequency, installed applications, ROM usage capacity, installed external devices, etc.

[0106] The edge dynamic requirements may include edge status information such as RAM usage, CPU utilization, edge status anomalies, rental infrastructure status, and processing status. The user can use these distribution requirements to specify the distribution destination of the requested application.

[0107] The certificate is used to guarantee the authenticity of the requested application to the distribution destination of the requested application. As shown in Fig. 13, the certificate may include a certificate number, an application ID, a certificate status, a user ID, a priority option, and the like.

[0108] However, the application ID indicated in the certificate is the identification number of the requesting application (that is, the application of interest) linked to the certificate identified by the certificate number. The certificate number, certificate status, user ID, and priority option are explained in the user profile and the configuration requirement specification profile, so explanations are omitted here.

[0109] The application distribution unit 642 distributes the requested application, which is an application that has been authenticated and given a certificate by the application authentication unit 641, to a pre-registered edge-equipped vehicle. The application distribution unit 642 selects a distribution destination by referring to the user profile DB, the deployment requirement specification profile DB, the certificate DB, the CE status DB, and the processing status DB.

[0110] The CE status is information indicating the static status and dynamic status of the edge-equipped vehicle and the edge device 3. CE stands for vehicle-edge. The CE status is generated by the edge device 3 and transmitted to the cloud server 5 by a CE status notification. As shown in FIG. 14, the CE status may include information such as an edge ID, rental infrastructure status, vehicle state, ECU state, location, vehicle static information, vehicle dynamic information, edge static information, and edge dynamic information. Static information is information that does not change over time, and dynamic information is information that changes over time. The shadow DB provided in the GW / communication management unit 61 may be used as the CE status DB. The CE status DB stores an individual CE status for each vehicle equipped with the edge device 3. The CE status DB corresponds to the individual vehicle database in this disclosure.

[0111] The edge ID is identification information that identifies the edge device 3. The rental infrastructure status indicates the rental infrastructure status of the edge device 3 identified by the edge ID (hereinafter referred to as the target edge). The vehicle state determination indicates the determination result of the vehicle state determination module M2. The ECU state determination indicates the determination result of the ECU state determination module M3. The location is information that indicates the location of the target vehicle that generated the CE status notification. The vehicle static information, vehicle dynamic information, edge static information, and edge dynamic information are information that correspond to the vehicle static requirements, vehicle dynamic requirements, edge static requirements, and edge dynamic requirements in the placement requirement specification profile, respectively, and are information unique to the target edge. Note that the vehicle static information, vehicle dynamic information, edge static information, and edge dynamic information do not necessarily have to include all of the information indicated as vehicle static requirements, vehicle dynamic requirements, edge static requirements, and edge dynamic requirements.

[0112] When the application distribution unit 642 receives an application distribution request from the application authentication unit 641, it references the deployment requirement specification DB and extracts the distribution requirements (i.e., computation specifications, presence or absence of exterior equipment, etc.) indicated in the deployment requirement specification profile linked to the requested application to be distributed. The application distribution unit 642 further references the CE status DB and determines a distribution destination from among edge-equipped vehicles whose rental platform status is "rentable" and that satisfy the extracted distribution requirements, and distributes the requested application to the determined distribution destination. If multiple edge-equipped vehicles are extracted, the distribution destination may be determined according to an algorithm that determines the distribution destination based on the margin of computation specifications, information on past billing amounts, specifications of exterior equipment, etc.

[0113] If the requested application is a non-vehicle job, for example, edge static requirements or edge dynamic requirements may be used as the delivery requirements. In this case, the application delivery unit 642 refers to the CE status DB, extracts edge-equipped vehicles whose ROM / RAM capacity, CPU operating rate, and other information indicated in the edge static information and edge dynamic information satisfy the delivery requirements, and determines the delivery destination from among the extracted edge-equipped vehicles.

[0114] When the requested application is a vehicle-related job, for example, a vehicle static requirement, a vehicle dynamic requirement, an edge static requirement, and an edge dynamic requirement may be used as the delivery requirement. Specific examples 1 to 6 in this case are shown below.

[0115] In specific example 1, the user is an OEM or exterior product developer who wants to understand the usage status and usage methods of their in-vehicle products and use the information for product development, evaluation, and improvement. In this case, the distribution requirements include, for example, the vehicle model, number of occupants, and roads on which the products are driven. The application distribution unit 642 references the CE status DB and collates basic vehicle information, owner information, in-vehicle environment information, out-vehicle environment information, vehicle status, device and function usage information, occupant information, and time-series data information to determine an edge-equipped vehicle that meets the distribution requirements as the distribution destination. As an example, a developer of in-vehicle cameras may be the user and distribute an application that monitors the usage status of their in-vehicle cameras to edge-equipped vehicles.

[0116] Specific example 2 is a case in which the user is an app or exterior device developer who requires survey testing, large-scale testing, or pre-production field testing but cannot provide the necessary environment. In this case, distribution requirements include, for example, exterior device, weather, and region. The app distribution unit 642 references the CE status DB and compares basic vehicle information, usage history information, owner information, interior environment information, exterior environment information, vehicle status, device and function usage information, occupant information, and time-series data information to determine an edge-equipped vehicle that meets the distribution requirements as the distribution destination. One example is a software developer who serves as the user and distributes an application for developing road environment learning algorithms for autonomous driving to edge-equipped vehicles. To increase learning intensity, the software developer needs to prepare a large-scale environment that allows for various combinations of the above information groups.

[0117] In specific example 3, the user is a MaaS operator that collects dynamic and static information related to vehicle type, industry, driving environment, region, owner, occupant, and device usage, and handles big data that stratifies and processes the collected information based on certain criteria. In this case, distribution requirements include, for example, the weather during driving, whether or not the vehicle is driving at high speeds, the driving region, a specific industry, and the occupant demographics. The application distribution unit 642 references the CE status DB and compares basic vehicle information, usage history information, owner information, in-vehicle environment information, out-vehicle environment information, vehicle status, device and function usage information, occupant information, and time-series data information, and determines an edge-equipped vehicle that meets the distribution requirements as the distribution destination. One example is a case in which a ride-hailing service operator is the user and distributes an application to survey taxi vehicle operating areas and passenger pick-up and drop-off points to taxis equipped with the edge device 3. Other examples include a psychological state survey application for drivers who frequently accelerate and decelerate suddenly, a health management application for bus passengers, and a health management application for drivers of vehicles traveling on highways, to edge-equipped vehicles.

[0118] Specific example 4 is a case where the user is an application developer who needs to develop applications and collect data for rare vehicles, special vehicles, and vehicles equipped with special exterior devices. In this case, the distribution requirements include, for example, the presence or absence of a motor for the lifting arm of a large heavy machine or a brake braking device of a large transport vehicle. The application distribution unit 642 references the CE status DB and compares basic vehicle information, owner information, in-vehicle environment information, vehicle status, device and function usage information, and time-series data information, and determines an edge-equipped vehicle that meets the distribution requirements as the distribution destination. One example is a case where a brake control ECU developer is the user and distributes a brake deterioration monitoring application for a large transport vehicle to an edge-equipped vehicle.

[0119] Specific example 5 is a case where users are public institutions, MaaS operators, news organizations, and facility maintenance operators who require dynamic data outside the vehicle cabin, such as for collecting road information, weather information, construction information, and accident detection. In this case, distribution requirements include, for example, an exterior camera, image recognition functions for weather, people, objects, events, and road conditions, a hygrometer, and the presence or absence of wipers. The application distribution unit 642 references the CE status DB, compares in-vehicle environment information, exterior environment information, and time-series data information, and determines edge-equipped vehicles that meet the distribution requirements as distribution destinations. One example is a case where a map distribution service provider is the user and distributes an application for developing automatic map generation algorithms to edge-equipped vehicles. Other examples include applications for on-demand vehicle interior cleaning and on-demand refueling services, and large-scale local weather sampling applications aimed at improving weather forecast accuracy to edge-equipped vehicles.

[0120] Specific example 6 is a case where the user is an investigative agency or detective agency that wants to track vehicles and people involved in traffic and non-traffic incidents and accidents. In this case, the distribution requirements include, for example, an exterior camera and image recognition functions for weather, people, events, etc. The application distribution unit 642 references the CE status DB, collates the exterior environment information and time-series data information, and determines an edge-equipped vehicle that meets the distribution requirements as the distribution destination. One example is a case where the police are the user and distribute an exterior video collection application to edge-equipped vehicles.

[0121] The application distribution unit 642 also has a function of collecting and deleting a requested application that has been distributed to the edge device 3 in accordance with a deletion request from a user or a deletion request from the CL-side application monitoring unit 644. The CL-side application monitoring unit 644 updates the contents of the CE status DB and the processing status DB in accordance with various notifications received from registered edge-equipped vehicles, and transmits instructions, etc. to the edge device 3 as necessary. In addition, the CL-side application monitoring unit 644 outputs a request to delete the distributed requested application to the application authentication unit 641 and the application distribution unit 642, and a settlement trigger, etc. to the application billing unit 643 in accordance with the updated DB contents.

[0122] When a settlement trigger is input, the application billing unit 643 generates billing information indicating the charge to the user and margin information indicating the consideration to be paid to the edge holder. The billing information and margin information are generated based on the resource usage log shown in the processing status DB, the user information shown in the user profile DB, and the edge holder information. Note that the billing information corresponds to the first consideration information in this disclosure, and the margin information corresponds to the second consideration information in this disclosure.

[0123] The application billing unit 643 performs billing processing for the user and settlement processing for the edge holder based on the generated billing information. Note that the edge holder information may include an edge ID, a holder ID, a registered holder name, a financial institution name, a financial account number, etc. The edge ID is identification information that identifies the edge device 3. The holder ID is identification information assigned to the holder of the edge device 3 identified by the edge ID (hereinafter referred to as the target edge device). The registered holder name is the registered name of the holder identified by the holder ID. The financial institution name and financial account number are the name of the financial institution and the account number used for billing and payment to the user identified by the holder ID.

[0124] The billing information may include a basic charge based on resource usage and an additional charge for using a priority option. The processing priority selectable in the priority option may be a binary system of "with priority" or "without priority," or may be a multi-level system or arbitrarily weighted. In this case, the additional charge amount may vary depending on the type of priority option. The basic charge amount may vary depending on the time of day or season, according to the overall resource availability throughout the system. For example, a low fee may be set during late-night hours when vehicle usage is low and resources are available, whereas a high fee may be set during rush hour hours when vehicle usage is high and resources are limited. Similarly, a high fee may be set during periods when vehicle usage is high and resources are limited, such as holidays, consecutive weekends, and weekends, and a low fee may be set during other periods.

[0125] Here, the charge to the user, i.e., the payment from the user, may be something other than money. For example, the price of the service provided by the user may be discounted, a coupon may be issued, or goods such as content may be provided free of charge. Furthermore, the consideration paid to the edge holder may also be something other than money. For example, the edge holder may receive a discount on a service they want to receive, receive a coupon, receive points, electronic money, a complimentary coupon, or obtain goods such as desired content free of charge.

[0126] [4. System Operation Overview] An overview of the operations related to the execution of a request application in the mobility IoT system 1 will be described with reference to FIGS.

[0127] When the requested application has not been distributed to the edge-equipped vehicle, as shown in Fig. 15, the vehicle-side application monitoring unit 441 periodically transmits a CE status notification to the cloud server 5 (A1). The content of the CE status notification is the same as the content of the CE status shown in Fig. 14.

[0128] The CL-side application monitoring unit 644, which has received the CE status notification, updates the CE status DB in accordance with the content of the CE status notification (A2). That is, the CE status of the Edge-equipped vehicle registered in the cloud server 5 is stored in the CE status DB, and the content thereof is updated periodically.

[0129] As shown in FIG. 16, when a user requests the cloud server 5 to register an application (B1), the application authentication unit 641 examines the application. If the safety of the application is confirmed as a result of the examination, the application authentication unit 641 issues a certificate and registers it in the certificate DB. Hereinafter, an application for which a certificate has been issued will be referred to as a "requested application." Furthermore, the application authentication unit 641 registers the user profile and deployment requirement specification profile attached to the registration application in the user DB and the deployment requirement specification DB (B2). Thereafter, the application authentication unit 641 notifies the user of the examination result (B3) and requests the application distribution unit 642 to distribute the application (B4).

[0130] Upon receiving the distribution request, the application distribution unit 642 determines a distribution destination in accordance with the deployment requirement specification profile associated with the requested application and the CE status of the edge-equipped vehicle stored in the CE status DB (B5). Then, the application distribution unit 642 distributes the requested application to the determined distribution destination (B6). Furthermore, the application distribution unit 642 provides the CL-side application monitoring unit 644 with distribution destination information including information identifying the edge device 3 to which the requested application has been distributed (B7).

[0131] The CL-side application monitoring unit 644 transmits an application distribution notification to the edge device 3 of the distribution destination in accordance with the provided distribution destination information (B8). The vehicle-side application monitoring unit 441 of the edge device 3 that has received the application distribution notification starts executing the distributed request application and starts monitoring the execution status (i.e., whether or not abnormal processing is occurring) and the resource usage status (B9). Furthermore, the vehicle-side application monitoring unit 441 transmits a monitoring start notification to the cloud server 5 (B10).

[0132] Although not shown in the figures, when a user requests the cloud server 5 to delete an application, the application authentication unit 641 deletes the registration contents of the user DB, deployment requirement specification DB, and certificate DB that are linked to the requested application to be deleted. Furthermore, the application authentication unit 641 notifies the user of a result indicating that the deletion has been completed.

[0133] Furthermore, when a user requests an application update from the cloud server 5, the application authentication unit 641 updates the registered contents of the user DB, deployment requirement specification DB, and certificate DB associated with the requested application to be updated. Furthermore, the application authentication unit 641 notifies the user of the result indicating that the update has been completed.

[0134] As shown in Fig. 17, the vehicle-side application monitoring unit 441 monitors the execution state and resource usage status of the requesting application while the processing status is "calculation processing in progress" (C1), and periodically transmits the details obtained through monitoring to the cloud server 5 as a processing status notification (C2). The contents of the processing status notification are the same as the processing status shown in Fig. 10. In other words, the vehicle-side application monitoring unit 441 corresponds to a status notification unit. Note that if the requesting application is resident, the calculation result is also transmitted at the timing specified by the requesting application.

[0135] Upon receiving the processing status notification, the CL-side application monitor 644 updates the processing status DB in accordance with the contents of the processing status notification (C3). Furthermore, when the user inquires about the processing status of the cloud server 5 (C4), the CL-side application monitoring unit 644 reads the processing status of the application ID specified in the inquiry from the processing status DB and notifies the user (C5).

[0136] As shown in FIG. 18, when the processing status is “calculation processing in progress”, if the vehicle-side application monitoring unit 441 detects the normal termination of a self-contained requested application (D1), it transmits the calculation result of the requested application together with a termination notification to the cloud server 5 (D2).

[0137] The CL-side application monitor 644 transmits a monitoring termination request to the edge device 3 that is the source of the received termination notification (D3). In response to the received monitoring cancellation request, the vehicle-side application monitoring unit 441 cancels monitoring of the requesting application (D4) and transmits a monitoring cancellation completion notification to the cloud server 5 (D5).

[0138] Upon receiving the notification of completion of monitoring cancellation, the CL-side application monitoring unit 644 transmits an application deletion instruction to the application distribution unit 642 (D6), and also transmits a completion notification with the calculation result attached to the user (D7).

[0139] The application distribution unit 642 transmits an application deletion instruction to the edge device 3 that is the distribution destination of the requested application indicated in the deletion request, instructing the edge device 3 to delete the requested application (D7). When the MIoT core unit 43 of the edge device 3 receives the application deletion instruction, it deletes the requested application as instructed.

[0140] As shown in FIG. 19, when the cloud server 5 receives a request from a user to suspend a requested application whose processing status is "calculation in progress" (E1), the CL-side application monitoring unit 644 identifies the edge device 3 to which the requested application that is the subject of the suspension request is to be delivered, and transmits a CL-side suspension request to the identified edge device 3 (E2).

[0141] Upon receiving the CL-side interruption request, the vehicle-side application monitoring unit 441 executes a stop process to stop the requested application in a state in which the application can be resumed (E3), and transmits an interruption completion notification together with the metadata to the cloud server 5 (E4).

[0142] Thereafter, similar to D3 to D8 described above, a request to stop monitoring is sent (E5), monitoring is stopped (E6), a notification that monitoring has been stopped is sent (E7), a deletion request is made to the application distribution unit 642 (E8), a notification of interruption completion is sent instead of a termination notification (E9), an instruction to delete the application is sent (E10), and the requested application is deleted at the edge device 3.

[0143] When a user issues a command to resume the request application whose processing has been interrupted and collected by the cloud server 5, a new destination is selected and the request application is delivered to the selected destination together with the metadata attached to the interruption completion notice. The edge device 3 to which the request application has been delivered along with the metadata uses the metadata to resume processing of the request application from the point where it was interrupted.

[0144] 20, when the vehicle-side application monitoring unit 441 detects "vehicle state / ECU state abnormality" as the continuation determination result for a request application whose processing status is "calculation processing" (F1), the vehicle-side application monitoring unit 441 executes a third stop process to stop the request application (F2). Furthermore, the vehicle-side application monitoring unit 441 transmits a vehicle-side interruption notification together with the metadata to the cloud server 5 (F3).

[0145] Thereafter, similar to D3 to D8 described above, a request to stop monitoring is sent (F4), monitoring is stopped (F5), a notification of completion of monitoring is sent (F6), a deletion request is made to the application distribution unit 642 (F7), a vehicle-side interruption notification is sent instead of a termination notification (F8), an application deletion instruction is sent (F9), and the requested application is deleted at the edge device 3.

[0146] 21, when the vehicle-side application monitoring unit 441 detects an "application status abnormality" as the continuation determination result for a request application whose processing status is "calculation processing" (G1), the vehicle-side application monitoring unit 441 executes a second stop process to stop the request application (G2). Furthermore, the vehicle-side application monitoring unit 441 transmits an abnormality processing notification together with the metadata to the cloud server 5 (G3).

[0147] Thereafter, similarly to D3 to D5 described above, a monitoring cancellation request is sent (G4), monitoring cancellation is executed (G5), and a monitoring cancellation completion notification is sent (G6). Thereafter, the CL-side application monitoring unit 644 transmits a request to the application distribution unit 642 and the application authentication unit 641 to delete the requested application that has been distributed to the edge device 3 that has sent the abnormality processing notification (G7).

[0148] The application distribution unit 642 transmits an application deletion instruction to the edge device 3 that is the distribution destination of the requested application indicated in the deletion request, instructing the edge device 3 to delete the requested application (G8). Upon receiving the application deletion instruction, the MIoT core unit 43 of the edge device 3 deletes the requested application.

[0149] In response to the deletion request, the application authentication unit 641 updates the user DB etc. so that the certificate associated with the requested application that is the target of the deletion request is invalidated (G9). Furthermore, the application authentication unit 641 transmits to the user an authentication revocation notice indicating that the authentication of the requested application in which the abnormal processing occurred has been revoked (G10).

[0150] Next, an overview of operations related to billing in the mobility IoT system 1 will be described with reference to FIGS. 22 and 23. FIG. FIG. 22 shows the operation when charging is performed after the fact according to the amount of resources used to execute the requested application.

[0151] As shown in FIG. 22, when the processing status is “calculation processing in progress”, the vehicle-side application monitoring unit 441 monitors the request application (H1) and repeatedly transmits a processing status notification indicating the processing status, which is information obtained by monitoring, to the cloud server 5 (H2).

[0152] The CL-side application monitor 644 updates the processing status DB in accordance with the content of the received processing status notification (H3). When a settlement process trigger is input (H4), the application billing unit 643 refers to the processing status DB, etc., and calculates billing information and margin information (H5). The settlement process trigger may be generated automatically at a preset timing (for example, once a month), or may be generated in response to an instruction from an administrator who manages the cloud server 5.

[0153] The application billing unit 643 bills the user based on the generated billing information and the financial institution information registered in the user DB (H6), and confirms the billing from the user (H7).

[0154] The application billing unit 643 pays the payment to the vehicle owner based on the generated margin information and the financial institution information registered in the owner DB (H8). 23 shows the operation when a pre-payment is made before the requested application is actually executed by an auction or the like. The vehicles that are expected to be auctioned include rare vehicles, special vehicles, vehicles equipped with special exterior devices, vehicles equipped with high-grade edge devices 3, vehicles equipped with special applications, etc. The auction is planned based on a proposal by the vehicle owner or the administrator of the cloud server 5, etc.

[0155] 23, the application billing unit 643 presents the available resources to be auctioned to the user (J1). The resources to be auctioned correspond to the specific resources in the present disclosure.

[0156] The user submits a bid for the resource he or she wishes to use (J2). The application billing unit 643 determines the user according to the bid amount, and generates billing information and margin information according to the bid amount (J3).

[0157] Thereafter, similar to H6 to H8, the user is billed (J4), the bill is confirmed by the user (J5), and the payment is made to the vehicle owner (J6). In the case of advance billing, a function may be provided to collect additional fees or forcibly stop the requested application if resource usage exceeds the conditions presented at the time of bidding. Also, in J2, the bid amount presented by the user corresponds to the bid information in this disclosure, and in J3, the determined user corresponds to the authorized user in this disclosure.

[0158] [5. Effects] According to the embodiment described above in detail, the following effects are achieved. (5a) In the mobility IoT system 1, when the vehicle state and the ECU state are both normal, the edge-equipped vehicle can be made to execute the requested application using the resources provided in the edge-equipped vehicle.

[0159] For example, if the conditions for determining that a vehicle's condition is normal include low load with ample resource processing capacity, the resources of an edge-equipped vehicle that is an idle asset can be effectively utilized.

[0160] Furthermore, instead of determining that the vehicle condition is normal when the vehicle is under low load, the vehicle condition may be determined to be normal when no emergency event, such as the automatic braking or collision, has occurred. In this case, even when the processing capacity of the resource is low, the vehicle becomes "available for rental" and can receive the requested application. For example, it becomes possible to distribute a requested application that has a function to collect vehicle driving data regardless of the vehicle's load condition.

[0161] (5b) In the mobility IoT system 1, resource users are charged and resource providers are paid in return. This allows for a new business opportunity that matches the desires of vehicle owners who want to make profits by effectively utilizing the resources of edge-equipped vehicles with the needs of program developers and others who want to use the processing power of the resources even if it means paying a fee.

[0162] (5c) In the mobility IoT system 1, the processing load of the cloud server 5 can be distributed to edge-equipped vehicles, thereby reducing the cost required to operate the cloud server 5.

[0163] (5d) In the mobility IoT system 1, resource allocation and the amount charged to the user are changed according to the priority of the requested application. Therefore, flexible operation according to the needs of the user who provides the requested application can be realized.

[0164] (5e) In the mobility IoT system 1, by changing the amount charged to users depending on the overall resource availability across the entire system, users can be guided to use resources during times when there is a large amount of resource availability.

[0165] 6. 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 modified forms.

[0166] (6a) In the present disclosure, a single cloud server 5 performs all of the tasks of collecting information about vehicles and edge devices 3, distributing requested applications, and billing. However, the functions of the cloud server 5 may be configured to be realized by multiple servers.

[0167] (6b) The resource usage status may be determined not only using direct information such as the usage rate and usage time of the CPU, memory, and exterior devices, but also using indirect information such as whether the vehicle is parked.

[0168] (6c) The control unit 34, 53 and the method described herein may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to perform one or more functions embodied in a computer program. Alternatively, the control unit 34, 53 and the method described herein may be implemented by a special-purpose computer configured by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the control unit 34, 53 and the method described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to perform one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible recording medium. The method for implementing the functions of each unit included in the control unit 34, 53 does not necessarily need to include software; all of the functions may be implemented using one or more hardware devices.

[0169] (6d) Multiple functions of one component in the above embodiments may be realized by multiple components, or one function of one component may be realized by multiple components. Also, multiple functions of multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Also, 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.

[0170] (6e) In addition to the mobility IoT system as the mobility service providing system described above, the present disclosure can also be realized in various forms, such as a cloud server and an edge device as server devices that constitute the mobility service providing system, a program for causing a computer to function as the server device or edge device, and a non-transient physical recording medium such as a semiconductor memory on which this program is recorded. [Explanation of symbols]

[0171] 1...Mobility IoT system, 3...Edge device, 5...Cloud server, 41...Vehicle communication management unit, 42...Cloud communication management unit, 43...MIoT core unit, 44...Vehicle-side application management unit, 61...GW / communication management unit, 62...GUI / dashboard, 63...Service core unit, 64...CL-side application management unit, 431...Hardware, 432...Middleware, 433...Vehicle DB, 434...Application, 441...Vehicle-side application monitoring unit, 631...API unit, 632...User authentication unit, 633...DB management unit, 641...Application authentication unit, 642...Application distribution unit, 643...Application billing unit, 644...CL-side application monitoring unit.

Claims

1. A mobility service providing method for providing a service to an edge-equipped vehicle, which is a vehicle equipped with an edge device (3) that communicates with a server device (5), by executing a requested application that is an application registered in the server device, comprising: the server device determines the edge-equipped vehicle that satisfies a distribution requirement set in association with the request application as a distribution destination vehicle; Distributing the requested application to the edge device mounted in the destination vehicle; the edge device executes the requested application distributed from the server device using resources provided in the edge-equipped vehicle, and notifies the server device of resource information relating to a usage status of the resources related to the execution of the requested application; the server device generates, in response to the resource information notified from the edge device, first compensation information to be charged to the user who requested the processing of the requested application and second compensation information to be granted or paid to the owner of the edge-equipped vehicle that provided the resource; The server device grasps the resource usage status of all the edge-equipped vehicles that can receive the distribution of the requested application, and changes the first consideration information according to the overall margin of the resources. Mobility service delivery method.

2. 2. The mobility service providing method according to claim 1, The server device accumulates vehicle information repeatedly transmitted from the edge-equipped vehicles for each edge-equipped vehicle, and determines whether the edge-equipped vehicle satisfies the distribution requirements by referring to the accumulated vehicle information, thereby determining the distribution destination vehicle. Mobility service delivery method.

3. 3. The mobility service providing method according to claim 1 or 2, As the distribution requirement, any one of static information of the edge-equipped vehicle, dynamic information of the edge-equipped vehicle, static information of the edge device, and dynamic information of the edge device is used, The static information is information that does not change over time, and the dynamic information is information that changes over time. Mobility service delivery method.

4. The mobility service providing method according to claim 3, The dynamic information of the edge-equipped vehicle includes any one of in-vehicle environment information, outside-vehicle environment information, vehicle state information, device / function usage information, occupant information, and time-series data information. Mobility service delivery method.

5. A mobility service providing method according to any one of claims 1 to 4, comprising: the request application includes one of a vehicle-related job and a non-vehicle-related job, The vehicle-related job is a job that is meaningful to be executed in the edge-equipped vehicle, and the non-vehicle-related job is a job other than the vehicle-related job. Mobility service delivery method.

6. A mobility service providing method according to any one of claims 1 to 5, The request application may be either a resident application or a self-contained application, The resident request application is an application that repeatedly executes a routine job, and the complete request application is an application that executes an atypical job whose process ends with the output of a calculation result. Mobility service delivery method.

7. A mobility service providing method according to any one of claims 1 to 6. hand, A priority is set for the requesting application, The edge device allocates the resources according to a priority; The server device changes the first consideration information according to priority. Mobility service delivery method.

8. A mobility service providing method according to any one of claims 1 to 7, comprising: the server device instructs the edge device to delete the distributed requested application when a predetermined state occurs; The edge device deletes the requested application in accordance with the deletion instruction from the server device. 、 The predetermined state includes at least one of the following: the request application is normally terminated; a request to suspend the request application is received from an external device; the edge-equipped vehicle is in an abnormal state; the edge device is in an abnormal state; and the request application is in an abnormal state. Mobility service delivery method.

9. A mobility service providing method according to any one of claims 1 to 8, comprising: The delivery requirement includes that the processing capacity of the resources of the edge-equipped vehicle is sufficient to execute the requested application. Mobility service delivery method.

10. A mobility service providing method according to any one of claims 1 to 9, comprising: The delivery requirement includes providing an exterior device necessary for executing the requested application as a resource of the edge-equipped vehicle. Mobility service delivery method.

11. A mobility service providing method according to any one of claims 1 to 10, comprising: The delivery requirement includes that the resources of the edge device of the edge-equipped vehicle are in a low load state. Mobility service delivery method.

12. A mobility service providing method according to any one of claims 1 to 11, comprising: The edge device has at least a lendable state and a non-lendable state as a rental infrastructure status, the lendable state being when both the edge-equipped vehicle and the edge device are normal, and the non-lendable state being when at least one of the edge-equipped vehicle and the edge device is abnormal, When the rental infrastructure status is in the rental available state, the edge device executes the requested application distributed from the server device. Mobility service delivery method.

13. A mobility service providing method according to any one of claims 1 to 12, comprising: The server device accepts bidding information for the use of a specific resource from multiple users, and based on the bidding information, determines the authorized user who is the user who is permitted to use the specific resource and the first compensation information to be charged to the authorized user, and based on the first compensation information, determines the second compensation information to be charged to the provider who provides the specific resource. Mobility service delivery method.

14. A server device (5); an edge device (3) mounted on a vehicle and communicating with the server device; Equipped with The edge device an application execution unit (43) configured to execute a requested application, which is an application distributed from the server device, using resources provided in the edge-equipped vehicle, with the vehicle equipped with the edge device as the edge-equipped vehicle; a status notification unit (441) configured in the edge-equipped vehicle to grasp resource information regarding the usage status of the resource related to the execution of the requested application and notify the server device; Equipped with The server device an application distribution unit (642) configured to determine the edge-equipped vehicle that satisfies distribution requirements set in association with the requested application as a distribution destination vehicle, and distribute the requested application to the edge device mounted in the distribution destination vehicle; an application billing unit (643) configured to generate, in accordance with the resource information notified from the edge device, first compensation information to be charged to the user who has requested the processing of the requested application, and second compensation information to be granted or paid to the owner of the edge-equipped vehicle that has provided the resource; Equipped with The application billing unit grasps the resource usage status of all the edge-equipped vehicles that can receive the distribution of the requested application, and changes the first consideration information according to the overall margin of the resources. Mobility service provision system.

15. A server device that is installed in a vehicle and that constitutes a mobility service providing system together with an edge device configured to execute a requested application, which is an application distributed from a server device, using resources provided in the vehicle and notify the server device of resource information related to usage status of the resources involved in the execution of the requested application, an application distribution unit (642) configured to determine the vehicle equipped with the edge device as an edge-equipped vehicle, determine the edge-equipped vehicle that satisfies distribution requirements set in association with the requested application as a distribution destination vehicle, and distribute the requested application to the edge device equipped in the distribution destination vehicle; an application billing unit (643) configured to generate, in accordance with the resource information notified from the edge device, first compensation information to be charged to the user who has requested the processing of the requested application, and second compensation information to be granted or paid to the owner of the edge-equipped vehicle that has provided the resource; Equipped with The application billing unit grasps the resource usage status of all the edge-equipped vehicles that can receive the distribution of the requested application, and changes the first consideration information according to the overall margin of the resources. Server device.

16. a computer included in the server device that constitutes a mobility service providing system, the computer being installed in a vehicle and configured to execute a requested application, which is an application distributed from a server device, using resources included in the vehicle, and notify the server device of resource information related to the usage status of the resources involved in the execution of the requested application; an application distribution unit (642) configured to determine the vehicle equipped with the edge device as an edge-equipped vehicle, determine the edge-equipped vehicle that satisfies distribution requirements set in association with the requested application as a distribution destination vehicle, and distribute the requested application to the edge device equipped in the distribution destination vehicle; an application charging unit (643) configured to generate first compensation information to be charged to a user who has requested the processing of the requested application in accordance with the resource information notified from the edge device, the first compensation information being changed in accordance with the overall availability of the resources by grasping the resource usage status of all the edge-equipped vehicles that can accept the distribution of the requested application, and second compensation information to be granted or paid to an owner of the edge-equipped vehicle that has provided the resources; A program to function as a

Images