Mobility service providing system, vehicle access control method, and program

Abstract

To provide a mobility service providing system, a vehicle access control method, and a program.SOLUTION: In a method, when an interface unit (API providing unit 122) receives, from a service providing server 4 that provides a service to a vehicle using a mobility service infrastructure server (management center 3), an access request for requesting an operation of an in-vehicle device with respect to the vehicle, access to a target vehicle is executed by performing wireless communication with an in-vehicle device mounted on the target vehicle which is a vehicle to be accessed. A vehicle control unit 130 of a vehicle-side unit 110 performs relay control on a control instruction transmitted and received to and from the in-vehicle device.SELECTED DRAWING: Figure 11

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This international application claims priority based on Japanese Patent Application No. 2021-110903, filed with the Japan Patent Office on July 2, 2021, the entire contents of which are incorporated by reference into this international application. [Technical Field]

[0002] The present disclosure relates to techniques for providing mobility services. [Background technology]

[0003] Patent Document 1 describes a digital twin simulation that reproduces the state of a vehicle in the real world in a virtual space by collecting vehicle data from the vehicle. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2019-153291 Summary of the Invention

[0005] With the expansion of mobility services, there are plans to access vehicles via the system and realize various applications that utilize the vehicle's functions.

[0006] The present disclosure provides techniques for improving the reliability of vehicle access related to mobility services.

[0007] One aspect of the present disclosure is a mobility service infrastructure server, which includes a vehicle-side unit and a service-side unit.

[0008] The vehicle-side unit has a first database that stores a plurality of shadows that are generated for each vehicle based on vehicle data provided by an on-board device mounted on the vehicle and that represent the state of the vehicle at a specific time.

[0009] The service-side unit includes a second database and an interface unit. The second database stores an index corresponding to each shadow stored in the first database and having information used to search for the shadow. The interface unit is configured to receive an access request from an external device.

[0010] The vehicle-side unit further includes a vehicle control unit configured to execute access to the target vehicle by wirelessly communicating with an on-board device mounted in the target vehicle when the interface unit receives an access request for the vehicle. The vehicle control unit is configured to execute relay control for control instructions transmitted and received between the on-board device and the target vehicle.

[0011] This configuration can improve the reliability of vehicle access.

[0012] One aspect of the present disclosure is a mobility service providing system including an on-board device mounted in a vehicle and the above-described mobility service infrastructure server.

[0013] One aspect of the present disclosure is a vehicle access control method, wherein a mobility service infrastructure server to which the vehicle access control method is applied includes a first database, a second database, and an interface unit.

[0014] In the vehicle access control method, when an interface unit receives an access request for a vehicle, the interface unit performs wireless communication with an on-board device mounted in the target vehicle, which is the vehicle to be accessed, to access the target vehicle. In the access to the target vehicle, relay control is performed for control instructions transmitted and received between the on-board device and the target vehicle.

[0015] One aspect of the present disclosure is a program. A computer that executes the program configures a mobility service infrastructure server together with a first database, a second database, and an interface unit.

[0016] The program causes the computer to function as a vehicle control unit. The vehicle control unit is configured to, when the interface unit receives an access request for a vehicle, execute access to the target vehicle by wirelessly communicating with an on-board device mounted in the target vehicle, which is the vehicle to be accessed. The vehicle control unit is also configured to execute relay control for control instructions transmitted and received between the on-board device and the target vehicle when accessing the target vehicle. [Brief explanation of the drawings]

[0017] [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 functional block diagram showing the functional configuration of an edge device. [Figure 4] FIG. 2 is a diagram illustrating a frame configuration. [Figure 5] FIG. 4 is a diagram showing the configuration of a vehicle data conversion table. [Figure 6] FIG. 2 is a diagram showing the first layer of standardized vehicle data and the data format. [Figure 7] FIG. 2 is a diagram showing the configuration of standardized vehicle data. [Figure 8] FIG. 10 is a sequence diagram showing a procedure for creating standardized vehicle data. [Figure 9] 10 is a timing chart showing data transmission timing. [Figure 10] FIG. 2 is a block diagram showing the configuration of a management center. [Figure 11] FIG. 2 is a functional block diagram showing the functional configuration of a management center. [Figure 12]FIG. 2 is a functional block diagram showing the functional configuration of a mobility gateway and a data management unit. [Figure 13] FIG. 10 is a diagram illustrating a configuration of a shadow. [Figure 14] FIG. 10 is a diagram illustrating the configuration of the latest index. [Figure 15] FIG. 10 is a diagram illustrating the structure of an index. [Figure 16] 10 is a diagram showing a configuration of an authorization object database included in an authorization information storage unit. FIG. [Figure 17] 10 is a diagram showing the configuration of an authorization class database included in an authorization information storage unit. FIG. [Figure 18] FIG. 10 is a sequence diagram illustrating the operation of an API providing unit. [Figure 19] 10A and 10B are diagrams illustrating configurations of specification information for a data acquisition request and a shadow access request. [Figure 20] FIG. 10 is an explanatory diagram of a method for specifying an area. [Figure 21] 10 is a flowchart of a shadow list generation process executed by an index acquisition unit. [Figure 22] FIG. 10 is a sequence diagram showing a procedure for acquiring data using a data acquisition API. [Figure 23] FIG. 10 is a diagram showing the configuration of designation information of a vehicle control request. [Figure 24] FIG. 10 is a sequence diagram showing a typical operation when a vehicle control request is received. [Figure 25] FIG. 1 is a diagram illustrating a configuration of a vehicle equipped with a vehicle control unit and an edge device related to a vehicle control request. [Figure 26] FIG. 10 is a diagram showing the contents registered in a control history storage unit. [Figure 27] 10 is a flowchart of a reception process executed by a reception unit. [Figure 28] 10 is a flowchart of a sequence process executed in the reception process. [Figure 29] 10 is a flowchart of a wake-up process executed in the reception process. [Figure 30]10 is a flowchart of a priority process executed in the reception process. [Figure 31] 10 is a flowchart of a transmission side process executed by a transmission management unit. [Figure 32] 10 is a flowchart of a receiving-side process executed by a reception management unit. [Figure 33] FIG. 10 is a sequence diagram showing an operation when the power supply state of the vehicle that is the target of the vehicle control request is on. [Figure 34] FIG. 10 is a sequence diagram showing an operation when there is no response from the vehicle to a control instruction. [Figure 35] FIG. 10 is a sequence diagram showing an operation when the power supply state of a vehicle that is the target of a vehicle control request is off. [Figure 36] FIG. 2 is a block diagram showing a connection state of ECUs mounted on a vehicle. DETAILED DESCRIPTION OF THE INVENTION

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

[0019] [1. System Overview] 1, a mobility IoT system 1 of this embodiment includes a plurality of edge devices 2, a management center 3, and a service providing server 4. IoT is an abbreviation for Internet of Things.

[0020] The edge device 2 is mounted on a vehicle and has a function of performing data communication with the management center 3 via a wide area wireless communication network NW.

[0021] The management center 3 is a device that manages the mobility IoT system 1. The management center 3 has a function of performing data communication with the multiple edge devices 2 and the service providing server 4 via the wide area wireless communication network NW.

[0022] The service providing server 4 is, for example, a server installed to provide a service for managing vehicle operation. The mobility IoT system 1 may include multiple service providing servers 4 each providing different service content. The service providing server 4 may be configured on-premise or in the cloud. The service providing server 4 may also be configured as the same physical server as the management center 3.

[0023] [2. Edge Devices] [2-1.Device configuration] As shown in FIG. 2, the edge device 2 includes a microcomputer 11, a vehicle interface (hereinafter referred to as vehicle I / F) 12, a communication unit 13, and a storage unit .

[0024] The microcomputer 11 includes a first core 21, a second core 22, a ROM 23, a RAM 24, a flash memory 25, an input / output unit 26, and a bus 27.

[0025] The various functions of the microcomputer 11 are realized by the first core 21 and the second core 22 executing a program stored in a non-transitory physical recording medium. In this example, the ROM 23 corresponds to the non-transitory physical recording medium storing the program. Furthermore, the execution of this program results in the execution of a method corresponding to the program.

[0026] Note that some or all of the functions executed by the first core 21 and the second core 22 may be configured in hardware using one or more ICs or the like.

[0027] The flash memory 25 is a rewritable nonvolatile memory and includes a standardized vehicle data storage unit 25a for storing standardized vehicle data, which will be described later.

[0028] The input / output unit 26 is a circuit for inputting and outputting data between the outside of the microcomputer 11 and the first core 21 and second core 22.

[0029] The bus 27 connects the first core 21, the second core 22, the ROM 23, the RAM 24, the flash memory 25, and the input / output unit 26 so that data can be input and output to and from one another.

[0030] The vehicle I / F 12 is an input / output circuit for transmitting and receiving signals to and from electronic control devices, sensors, and the like mounted on the vehicle.

[0031] The vehicle I / F 12 includes a power supply voltage input port, a general-purpose input / output port, a CAN communication port, and an Ethernet communication port. The CAN communication port is a port for transmitting and receiving data according to the CAN communication protocol. The Ethernet communication port is a port for transmitting and receiving data based on the Ethernet communication protocol. CAN is an abbreviation for Controller Area Network. CAN is a registered trademark. Ethernet is a registered trademark.

[0032] Other electronic control units mounted on the vehicle are connected to the CAN communication port and the Ethernet communication port, and the edge device 2 can transmit and receive communication frames to and from the other electronic control units.

[0033] The communication unit 13 performs data communication with the management center 3 via the wide area wireless communication network NW.

[0034] The storage unit 14 is a storage device for storing various data.

[0035] 36, the vehicle is equipped with one ECU 210, a plurality of ECUs 220, a plurality of ECUs 230, an exterior communication device 240, and an interior communication network 250. ECU is an abbreviation for Electronic Control Unit.

[0036] The ECU 210 controls a plurality of ECUs 220 to realize coordinated control of the entire vehicle.

[0037] An ECU 220 is provided for each domain, which is divided according to the vehicle's functions, and mainly controls a plurality of ECUs 230 present in that domain. Each ECU 220 is connected to its subordinate ECUs 230 via a lower-layer network (e.g., CAN) individually provided for each ECU 220. The ECU 220 has a function of centrally managing access rights to the subordinate ECUs 230 and authenticating users. The domains are, for example, the powertrain, body, chassis, and cockpit.

[0038] The ECUs 230 connected to the ECU 220 belonging to the powertrain domain include, for example, an ECU 230 that controls the engine, an ECU 230 that controls the motor, and an ECU 230 that controls the battery.

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

[0040] The ECUs 230 connected to the ECU 220 belonging to the chassis domain include, for example, an ECU 230 that controls the brakes, an ECU 230 that controls the steering, and the like.

[0041] The ECUs 230 connected to the ECU 220 belonging to the cockpit domain include, for example, an ECU 230 that controls the display of meters and navigation, and an ECU 230 that controls input devices operated by vehicle occupants.

[0042] The external vehicle communication device 240 performs data communication with a communication device (for example, a cloud server) outside the vehicle via the wide area wireless communication network NW.

[0043] The in-vehicle communication network 250 includes CAN FD and Ethernet. CAN FD stands for CAN with Flexible Data Rate. CAN FD connects the ECU 210 to each ECU 220 and the exterior-vehicle communication device 240 via a bus. Ethernet connects the ECU 210 to each ECU 220 and the exterior-vehicle communication device 240 individually.

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

[0045] Like ECU 210, ECU 220, ECU 230, and exterior-vehicle communication device 240 are all electronic control devices mainly configured with a microcomputer including a CPU, ROM, RAM, etc. Furthermore, the number of microcomputers configuring ECU 220, ECU 230, and exterior-vehicle communication device 240 may be one or more. ECU 220 is an ECU that controls one or more ECUs 230, and ECU 210 is an ECU that controls one or more ECUs 220 or controls all ECUs 220, 230 of the entire vehicle including exterior-vehicle communication device 240.

[0046] The edge device 2 is connected to the ECU 210 so as to be able to communicate data with the ECU 210. That is, the edge device 2 receives information from the ECUs 210, 220, and 230 via the ECU 210. The edge device 2 also transmits requests related to vehicle control to the ECU 210 and to the ECUs 220 and 230 via the ECU 210.

[0047] [2-2. Functional configuration] 3, the edge device 2 includes a first unit 101 as a functional block realized by the first core 21 executing a program stored in the ROM 23. The edge device 2 includes a second unit 102 as a functional block realized by the second core 22 executing a program stored in the ROM 23.

[0048] The first unit 101 includes a real-time operating system (hereinafter referred to as RTOS) 103 and a first application 104.

[0049] The first application 104 executes various processes for controlling the vehicle. In order to execute various processes for controlling the vehicle, the first application 104 is configured to be able to access the standardized vehicle data storage unit 25a of the flash memory 25 and refer to the standardized vehicle data.

[0050] The RTOS 103 manages the first application 104 so as to ensure that the processing by the first application 104 is performed in real time.

[0051] The second unit 102 includes a general purpose operating system (hereinafter, GPOS) 105 and a second application 106.

[0052] The second application 106 executes processing related to the service provided by the service providing server 4. In order to execute processing related to the service, the second application 106 is configured to be able to access the standardized vehicle data storage unit 25a of the flash memory 25 and refer to the standardized vehicle data.

[0053] The GPOS 105 is basic software installed in the edge device 2 to run various applications, and manages the second application 106 .

[0054] [2-3. Data collection and processing] A series of processes in which the edge device 2 collects vehicle data and voluntarily transmits it to the management center 3 will be described.

[0055] First, the process executed by the vehicle I / F 12 will be described.

[0056] When the vehicle I / F 12 receives a communication frame, it determines the communication protocol of the communication frame based on the communication port through which the communication frame was received. Specifically, for example, when the vehicle I / F 12 receives the communication frame through a CAN communication port, it determines that the communication protocol of the received communication frame is the CAN communication protocol. Furthermore, for example, when the vehicle I / F 12 receives the communication frame through an Ethernet communication port, it determines that the communication protocol of the received communication frame is the Ethernet communication protocol.

[0057] Then, based on the identification information of the communication frame, the vehicle I / F 12 determines whether the communication frame is to be processed by the edge device 2, and if it determines that the communication frame is to be processed, outputs the received communication frame to the first unit 101.

[0058] As shown in Figure 4, a CAN frame consists of a start of frame, arbitration field, control field, data field, CRC field, ACK field, and end of frame. The arbitration field consists of an 11-bit or 29-bit identifier (i.e., ID) and a 1-bit RTR bit.

[0059] The 11-bit identifier used in CAN communication is called CANID, which is preset based on the data content included in the CAN frame, the sender of the CAN frame, the destination of the CAN frame, etc.

[0060] The data field is composed of 8-bit (i.e., 1 byte) first data, second data, third data, fourth data, fifth data, sixth data, seventh data, and eighth data. Hereinafter, each of the first to eighth data in the data field will also be referred to as CAN data.

[0061] Therefore, when the vehicle I / F 12 receives a CAN frame, it determines whether or not the frame is a processing target based on the CAN ID.

[0062] Next, the processing executed by first unit 101 will be described.

[0063] When first unit 101 acquires a communication frame output from vehicle I / F 12, it extracts identification information and data from the communication frame and creates standard format data consisting of the identification information and data. First unit 101 stores the created standard format data in flash memory 25. For example, when first unit 101 acquires a CAN frame, it creates standard format data consisting of a CAN ID and data 1 to 8.

[0064] If standard format data containing the same identification information as the created standard format data is already stored in flash memory 25, first unit 101 updates the standard format data by overwriting the standard format data.

[0065] Next, the processing executed by second unit 102 will be described.

[0066] The second core 22 obtains the standard format data from the flash memory 25 .

[0067] The second core 22 then divides the data included in the acquired standard format data. For example, since the standard format data generated from the CAN frame is made up of a CAN ID and first to eighth data, the second core 22 divides the first to eighth data into 1-byte pieces and extracts eight pieces of CAN data. Note that the first unit 101 and the second unit 102 may write and read the standard format data using RAM 24 instead of flash memory 25.

[0068] Furthermore, the second core 22 refers to a vehicle data conversion table 23a stored in the ROM 23 and converts each of the divided extracted data into a control label and vehicle data.

[0069] The vehicle data conversion table 23a includes normalization information and semantic information.

[0070] The normalization information is information for normalizing the extracted data so that the same physical quantity has the same value regardless of the vehicle model and vehicle manufacturer.

[0071] Semantic information is information used to convert normalized vehicle data into meaningful vehicle data. Hereinafter, normalized and semanticized vehicle data will be referred to as processed data, and vehicle data before normalization and semanticization will be referred to as raw data. Raw data refers to data indicated in the data field of a CAN frame, for example.

[0072] As shown in FIG. 5, the normalization information of the vehicle data conversion table 23a includes setting items such as "CANID," "ECU," "position," "DLC," "unique label," "resolution," "offset," and "unit."

[0073] "ECU" is information that indicates the ECU that sent the CAN frame. For example, "ENG" indicates the engine ECU.

[0074] "Position" is information that indicates the position of the CAN data within the data field. "DLC" is information that indicates the data length. DLC is an abbreviation for Data Length Code.

[0075] "Unique label" is information that indicates the control label. For example, "ETHA" indicates the intake air temperature, and "NE1" indicates the engine speed. "Resolution" is information that indicates the numerical value per bit.

[0076] Therefore, data corresponding to the "unique label" is extracted from the standard format data using "CANID," "ECU," "position," "DLC," and "unique label." The extracted data is then converted into vehicle data expressed in "units" using "resolution" and "offset."

[0077] Furthermore, the semantic information of the vehicle data conversion table 23a includes a conversion formula for converting a "steering movement angle" whose control label is "SSA" into a "steering angle" by subtracting a "steering zero point" whose control label is "SSAZ" as shown in Fig. 5. This conversion formula converts the vehicle data representing the "steering movement angle" and the vehicle data representing the "steering zero point" into vehicle data representing a "steering angle" which has the meaning of "amount of steering from a reference position."

[0078] The second core 22 hierarchically organizes the converted vehicle data and stores it in the flash memory 25. Specifically, the second core 22 stores the converted vehicle data in a corresponding area of ​​the standardized vehicle data storage unit 25a provided in the flash memory 25.

[0079] The standardized vehicle data storage unit 25a stores standardized vehicle data configured by hierarchizing vehicle data.

[0080] The standardized vehicle data is created for each vehicle (i.e., for each edge device 2) and has a multi-layered structure. In the standardized vehicle data, one or more items are set for each of the multiple layers. For example, as shown in FIG. 6, the standardized vehicle data includes the following items set in the top first layer: "Attribute Information," "Powertrain," "Energy," "ADAS / AD," "Body," "Multimedia," and "Other." ADAS stands for Advanced Driver Assistance System. AD ​​stands for Autonomous Driving. "Attribute Information," "Powertrain," and "Energy" correspond to categories.

[0081] Each vehicle data item has the following fields: "Unique Label," "ECU," "Data Type," "Data Size," "Data Value," and "Data Unit." The "Unique Label" and "ECU" are as described above. The "Data Type," "Data Size," and "Data Unit" indicate the type, size, and unit of the numerical value indicated by the "Data Value."

[0082] As shown in FIG. 7, the standardized vehicle data has at least a second and third hierarchical layers in addition to the first hierarchical layer. The second hierarchical layer is the layer immediately below the first hierarchical layer, and the third hierarchical layer is the layer immediately below the second hierarchical layer. The standardized vehicle data are items set in the normalization and semanticization processes described above. The standardized vehicle data has a hierarchical data structure.

[0083] For example, "Attribute Information," an item at the first level, includes items at the second level such as "Vehicle Identification Information," "Vehicle Attributes," "Transmission Configuration," and "Firmware Version." "Vehicle Identification Information" is a category name indicating information that can uniquely identify a vehicle. "Vehicle Attributes" is a category name indicating the type of vehicle. "Transmission Configuration" is a category name indicating information related to the transmission. "Firmware Version" is a category name indicating information related to the vehicle's firmware.

[0084] Furthermore, the first-level item "Powertrain" is a category name that indicates information about the powertrain. "Powertrain" includes second-level items such as "Accelerator Pedal," "Engine," and "Engine Oil." "Accelerator Pedal" includes one or more vehicle data items, such as the accelerator pedal status and opening degree. "Engine" includes one or more individual vehicle data items, such as the engine status and RPM. Second-level items also correspond to categories. The same applies to other first-level items.

[0085] The first-level item "Energy" is a category name that indicates information related to energy. "Energy" includes second-level items such as "Battery Status," "Battery Configuration," and "Fuel."

[0086] Furthermore, the second-level item "Vehicle Identification Information" includes third-level items "Vehicle Identification Number," "Vehicle Body Number," and "License Plate." The third-level items are one or more individual vehicle data items, also called items. In other words, in the hierarchical structure of standardized vehicle data, the items at the lowest level are called items, and items other than the lowest level (i.e., items with lower levels) are called categories.

[0087] Furthermore, the "vehicle attributes" item at the second level includes items at the third level such as "brand name," "model," and "year of manufacture."

[0088] In addition, the second-level item "transmission configuration" has a third-level item "transmission type."

[0089] For example, if the control label of the converted vehicle data is "vehicle identification information," the second core 22 stores the converted vehicle data in a storage area in the standardized vehicle data storage unit 25a where the first layer is "attribute information," the second layer is "vehicle identification information," and the third layer is "vehicle identification number."

[0090] "Other" may include, for example, location information, that is, latitude, longitude, and altitude, acquired from a GPS device mounted on the vehicle via the vehicle I / F 12.

[0091] Next, a procedure for the edge device 2 to create standardized vehicle data will be described with reference to the sequence diagram shown in FIG.

[0092] As shown by arrow L11, when vehicle I / F 12 acquires vehicle data from the vehicle, vehicle I / F 12 determines the communication protocol as shown by arrow L12. Furthermore, vehicle I / F 12 filters out unnecessary vehicle data as shown by arrow L13, and outputs necessary vehicle data to first unit 101 as shown by arrow L14.

[0093] When the first unit 101 acquires vehicle data from the vehicle I / F 12, it converts the vehicle data into a standard format as shown by arrow L15, and stores the vehicle data converted into the standard format in the flash memory 25 as shown by arrow L16.

[0094] As shown by arrow L17, second unit 102 acquires the vehicle data converted into the standard format from flash memory 25, and then converts the acquired vehicle data as shown by arrow L18. Furthermore, second unit 102 structures the converted data to create standardized vehicle data as shown by arrow L19.

[0095] Next, the procedure of the data transmission process executed by the edge device 2 will be described.

[0096] Timing information indicating the timing of transmitting the data to the management center 3 is set for each vehicle data belonging to the standardized vehicle data. The timing information is set according to the degree of change in the data, the importance of the data, etc., so that the more frequently the data changes, the shorter the cycle of the data becomes. Examples of timing information include a 500 ms cycle, a 2 s cycle, a 4 s cycle, a 30 s cycle, a 300 s cycle, a 12 hour cycle, etc.

[0097] The second core 22 executes transmission processing at intervals of a transmission unit time (for example, 250 ms).

[0098] As shown in Figure 9, first-frequency data, which is vehicle data transmitted at 500 ms intervals, is divided into two groups and transmitted alternately at each transmission timing. Similarly, second-frequency data, which is vehicle data transmitted at 1 s intervals, is divided into two or four groups, and the data in each group is transmitted at a different transmission timing. In other words, by transmitting each vehicle data according to a preset transmission schedule, it is possible to prevent the transmission of many vehicle data from concentrating at the same transmission timing. Furthermore, by transmitting each vehicle data at a frequency according to its characteristics, efficient transmission is achieved.

[0099] [3. Management Center] [3-1. Equipment configuration] As shown in FIG. 10, the management center 3 includes a control unit 31, a communication unit 32, and a storage unit 33.

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

[0101] The communication unit 32 communicates data with the edge devices 2 and the service providing server 4 via the wide area wireless communication network NW. Note that MQTT, a simple and lightweight publish / subscribe protocol, is used for communication with the edge devices 2. MQTT stands for Message Queue Telemetry Transport.

[0102] The storage unit 33 is a storage device for storing various data.

[0103] [3-2. Functional configuration] 11, the management center 3 includes a vehicle-side unit 110 and a service-side unit 120 as functional blocks realized by the CPU 41 executing a program stored in the ROM 42. The functional block closest to access to the vehicle is the vehicle-side unit 110, and the functional block closest to access from the service providing server 4 is the service-side unit 120. These two functional blocks are loosely coupled.

[0104] The method of realizing these elements that make up the management center 3 is not limited to software, and some or all of the elements may be realized using one or more pieces of hardware. For example, if the above functions are realized by electronic circuits that are hardware, the electronic circuits may be realized by digital circuits including multiple logic circuits, analog circuits, or a combination of these.

[0105] The vehicle-side unit 110 has a function of managing access to the vehicle and data received from the vehicle. The vehicle-side unit 110 includes a mobility gateway (hereinafter referred to as mobility GW) 111. The mobility GW 111 has a function of relaying a request to access the vehicle to the vehicle, as well as a function of managing data received from the vehicle.

[0106] The mobility gateway 111 includes a shadow management unit 112 and a vehicle control unit 130. The shadow management unit 112 has a function of managing a shadow 114 that stores vehicle data provided for each vehicle equipped with an edge device 2. The shadow 114 indicates a group of vehicle data for a certain vehicle. The shadow 114 is generated based on standardized vehicle data transmitted from the edge device 2. The vehicle control unit 130 has a function of controlling the vehicle equipped with the edge device 2 via the edge device 2 in accordance with instructions from the service providing server 4.

[0107] The service side unit 120 receives requests from the service providing server 4 and provides vehicle data. The service side unit 120 includes a data management unit 121 and an API providing unit 122. API is an abbreviation for Application Programming Interface.

[0108] The data management unit 121 has a function of managing the digital twin 123, which is a virtual space for providing vehicle access independent of changes in the vehicle connection status. The data management unit 121 manages data necessary for accessing the vehicle data managed by the vehicle-side unit 110.

[0109] The API providing unit 122 is a standard interface for the service providing server 4 to access the mobility GW 111 and the data management unit 121. The API providing unit 122 provides the service providing server 4 with an API for accessing a vehicle and acquiring vehicle data.

[0110] [3-2-1. Data accumulation function] As shown in Figure 12, the shadow management unit 112 includes a shadow creation unit 115, a shadow storage unit 113, a latest index creation unit 116, and a latest index storage unit 117 as components that realize the function of accumulating vehicle data obtained from the edge device 2.

[0111] The shadow creation unit 115 receives structured standardized vehicle data from the edge device 2. Each time vehicle data is transmitted from the edge device 2, the shadow creation unit 115 updates the standardized vehicle data by overwriting the transmitted vehicle data in a corresponding area of ​​the structured standardized vehicle data. The shadow creation unit 115 may receive a portion of the structured standardized vehicle data. The shadow creation unit 115 creates a new shadow 114 using the updated standardized vehicle data. The shadow creation unit 115 accumulates the created shadow 114 in the shadow storage unit 113. When creating a new shadow 114 using the updated standardized vehicle data, the shadow creation unit 115 may assign arbitrary information such as a serial number and store the new shadow 114 in the shadow storage unit 113. The shadow storage unit 113 stores multiple shadows 114 created in chronological order for each vehicle. In other words, the shadow 114 can be considered as a copy of the state of a vehicle equipped with the edge device 2 at a certain time.

[0112] One shadow 114 is a group of vehicle data for a certain vehicle at a specific time, and includes a group of vehicle data represented by the standardized data structure shown in FIG. 13. The timing at which the shadow creation unit 115 receives the structured standardized vehicle data via the communication unit 32 varies depending on the vehicle. New shadows 114 may be created at the same time for all vehicles. The shadow creation unit 115 may also create new shadows 114 at regular intervals for all vehicles. The shadow storage unit 113 stores past shadows 114 for each vehicle. Shadows 114 that have been in use for a certain period of time may be deleted sequentially.

[0113] As shown in FIG. 13, the shadow 114 includes a vehicle data storage unit 114a and a device data storage unit 114b.

[0114] The vehicle data storage unit 114a stores "object-id", "Shadow_version", and "mobility-data" as data related to the vehicle in which the edge device 2 is mounted.

[0115] "Object-id" is a character string that identifies the vehicle in which the edge device 2 is installed, and functions as a partition key.

[0116] "Shadow_version" is a numerical value indicating the version of the shadow 114, and a timestamp indicating the time of creation is set each time the shadow 114 is created.

[0117] "mobility-data" is the standardized vehicle data described above.

[0118] The device data storage unit 114b stores the following data as data relating to the hardware, software, and status installed in the edge device 2: "object-id", "update_time", "version", "power_status", "power_status_timestamp", and "notify_reason".

[0119] The "object-id" is the same as that described in the vehicle data storage unit 114a.

[0120] "update_time" is a number indicating the update time.

[0121] “Version” is a character string indicating the version of the hardware and software of the edge device 2.

[0122] "power_status" is a character string indicating the system status of the edge device 2. Specifically, there is a "power on" state in which all functions are available, and a "power off" state in which some functions are stopped and low power consumption is achieved.

[0123] "power_status_timestamp" is a number indicating the time when the system status was notified.

[0124] "notify_reason" is a string indicating the reason for the notification.

[0125] In this way, the shadow 114 includes information about the edge device 2 in addition to the vehicle data group. The device data storage unit 114b may store the information about the edge device 2 separately in the ROM 42 or the like without including it in the shadow 114. The device data storage unit 114b may store only the latest data about the edge device 2 in the ROM 42 or the like, rather than accumulating past data for each timestamp.

[0126] The "version", "power_status", "notify_reason", and the like stored in the device data storage unit 114b are separate from the standardized vehicle data and are notified by the edge device 2 when a change occurs.

[0127] The latest index creation unit 116 acquires the latest shadow 114 for each vehicle from the shadow storage unit 113, and creates a latest index 118 using the acquired shadow 114. The latest index creation unit 116 then stores the created latest index 118 in the latest index storage unit 117. The latest index storage unit 117 stores one latest index 118 for each vehicle (i.e., for each object-id).

[0128] As shown in FIG. 14, the latest index 118 stores "gateway-id", "object-id", "shadow-version", "vin", "location-lon", "location-lat", and "location-alt".

[0129] The “object-id” and “shadow-version” are the same as those explained in the shadow 114 .

[0130] The "gateway-id" is information for identifying the mobility GW 111. When there are multiple management centers 3, for example, each of which is provided for a different country, the "gateway-id" is information for identifying these management centers.

[0131] "vin" is the registration number unique to the vehicle in which the edge device 2 is installed.

[0132] "location-lon" is information indicating the latitude at which the vehicle on which the edge device 2 is mounted is located.

[0133] "location-lat" is information indicating the longitude at which the vehicle on which the edge device 2 is mounted is located.

[0134] "Location-alt" is information indicating the altitude at which the vehicle on which the edge device 2 is mounted is located.

[0135] As shown in FIG. 12, the data management unit 121 includes an index creation unit 124 and an index storage unit 125 as components for realizing the function of storing the latest index 118 acquired from the shadow management unit 112 as an index 126 .

[0136] The index creation unit 124 acquires the latest indexes 118 from the latest index storage unit 117 according to a preset acquisition schedule, and creates indexes 126 for the digital twin 123 using the acquired latest indexes 118. The index creation unit 124 then sequentially stores the created indexes 126 in the index storage unit 125. The index storage unit 125 stores multiple indexes 126 created in chronological order for each vehicle. In other words, each of the indexes 126 stored in the index storage unit 125 represents a vehicle that exists in the digital twin 123, which is a virtual space-time.

[0137] As shown in FIG. 15, the index 126 stores "timestamp", "schedule-type", "gateway-id", "object-id", "shadow-version", "vin", "location", and "alt".

[0138] "timestamp" is a timestamp indicating the time in milliseconds when the index 126 was created.

[0139] "schedule-type" indicates whether the scheduler that created the data is periodic or event. If it is periodic, "schedule-type" is set to "Repeat", and if it is event, "schedule-type" is set to "Event".

[0140] “gateway-id”, “object-id”, “shadow-version”, and “vin” are information inherited from the latest index 118.

[0141] "Location" is information inherited from "location-lon" and "location-lat" of the latest index 118, and "alt" is information inherited from "location-alt" of the latest index 118.

[0142] Here, the shadow management unit 112 may be configured to omit the latest index creation unit 116 and the latest index storage unit 117. In this case, the index creation unit 124 may acquire the shadow 114 stored in the shadow storage unit 113 to generate the index 126. Preferably, the index creation unit 124 generates the index 126 using the latest index 118 acquired from the latest index storage unit 117. This is one of the configurations in which the mobility GW 111 and the data management unit 121 are loosely coupled.

[0143] Furthermore, the data management unit 121 may be configured to omit the index creation unit 124 and the index storage unit 125. In this case, for example, the index acquisition unit 127 may request the data acquisition unit 119 to acquire the specified vehicle data by using the object-id and timestamp (i.e., shadow-version) specified via the API provision unit 122.

[0144] [3-2-2. Service provision functions] 5 and 12, the service side unit 120 includes an API providing unit 122. The API providing unit 122 is an interface provided to allow an external service provider such as the service providing server 4 to use the functions of the management center 3. Hereinafter, a user of the mobility IoT system 1 who uses the API providing unit 122 or the like is referred to as a service user. A service user is, for example, a service provider that delivers goods to the trunk of a vehicle.

[0145] 12, the API providing unit 122 includes an authentication information storage unit 141, an authorization information storage unit 142, a vehicle identification information storage unit 143, and an authentication processing unit 144. In addition, the API providing unit 122 includes a login API 145, a data acquisition API 146, and a vehicle control API 148 as types of APIs provided to the service user.

[0146] The login API 145 is an API provided for authenticating the service user. The data acquisition API 146 is an API provided for the service user to acquire data. The vehicle control API 148 is an API provided for the service user to control the vehicle.

[0147] The authentication information storage unit 141 stores "authentication information" in association with a "service user ID." The "service user ID" is identification information that uniquely identifies a service user. The "authentication information" is information for authenticating that the service user is the actual user, and is, for example, a preset password.

[0148] The authorization information storage unit 142 includes an authorization object database (hereinafter referred to as authorization object DB) and an authorization class DB.

[0149] As shown in Figure 16, the authorization object DB stores "authorization class," "authorization object," and "expiration date" in association with "service user ID." "Authorization class" is information indicating the scope of authority authorized for a service user. "Authorization object" is a list of "object-id" of vehicles to which the service user is permitted to access. "Expiration date" is the start date and end date of the period during which the registration content is valid. In other words, the authorization object DB is a database that indicates the registration content regarding the authority of each service user for the mobility IoT system 1. Multiple registrations for one service user may be made in the authorization object DB as long as the "authorization objects" are different or the "expiration dates" do not overlap.

[0150] 17, the authorization class DB stores "API information," "acquisition authority," and "expiration date" in association with "authorization class." The authorization class DB is a database that indicates the specific contents of "authorization class."

[0151] "Authorization class" is information that identifies multiple classes that indicate the data range to which authorization is given, and for example, there may be six classes, "open," "Class0," "class1," "class2," "class3," and "Full," in order of decreasing authorization class. "Authorization class" is not limited to classification of the data range in which data can be read or written, but may also be classification of the operation control range in which operations can be controlled, etc.

[0152] "API information" is the URL of the API provided to the service user of the corresponding "authorization class." URL is an abbreviation for Uniform Resource Locator.

[0153] The "acquisition authority" is a list of data that is permitted to be acquired by a service user of the corresponding "authorization class." If the authorization class is "open," the data included in the "acquisition authority" is limited to information that anyone can freely access, and may include, for example, vehicle location information and altitude information. If the authorization class is "full," the data included in the "acquisition authority" includes all information managed by the management center 3 and all information that can be acquired from a vehicle equipped with an edge device 2. If the authorization class is "Class 0" to "Class 3," the number of accessible data may be set to increase as the class increases from 0 to 3, or the type of accessible data may be set to differ for each class.

[0154] Here, the acquisition authority lists the data that can be acquired, but instead of or in addition to the data that can be acquired, available functions, such as the type of control over a vehicle equipped with the edge device 2, may be listed. The data that can be acquired is listed from the data items shown in FIG. 7, for example.

[0155] As long as the "expiration dates" do not overlap, multiple settings may exist for one "authorization class."

[0156] The vehicle identification information storage unit 143 stores table information that associates an "object-id" that is uniquely assigned to a vehicle in which the edge device 2 is installed with the "vin" of that vehicle.

[0157] The authentication processing unit 144 executes authentication processing when an authentication request is made via the login API 145, and executes authorization processing when an access request is made via the data acquisition API 146 and the vehicle control API 148. The authentication processing and authorization processing will be described later.

[0158] The procedure for making an access request via the API providing unit 122 will be described with reference to FIG.

[0159] The login API 145 is used when a service user logs in to the mobility IoT system 1.

[0160] As indicated by arrow L21, when the login API 145 receives an authentication request from a service user, the authentication processing unit 144 executes authentication processing. In the authentication processing, the "service user ID" and "authentication information" input by the login API 145 are compared with the registered contents of the authentication information storage unit 141. If the information matches as a result of the comparison, that is, if authentication is successful, a token, which is data that serves as a certificate permitting access to the mobility IoT system 1, is returned as the authentication result, as indicated by arrow L22.

[0161] 11, the data acquisition API 146 is an API used to access vehicle data (i.e., the index 126 and the shadow 114) accumulated in the management center 3. As shown in L2 in FIG. 11, the vehicle control API 148 is an API used to access a vehicle equipped with the edge device 2.

[0162] Hereinafter, the data acquisition API 146 and the vehicle control API 148 will be collectively referred to as the access API. As indicated by arrow L23 in Fig. 18, when the access API receives an access request from a service user, the authentication processing unit 144 executes authorization processing.

[0163] When the authorization process is executed, the authentication processing unit 144 identifies the "service user ID" from the "token" attached to the access request. Next, the authentication processing unit 144 searches the authorization object DB in the authorization information storage unit 142 to identify the "authorization class" and "authorization object" of the identified "service user ID." Furthermore, the authentication processing unit 144 determines whether the vehicle to be accessed indicated in the access request is indicated in the "authorization object," i.e., whether access to the vehicle specified by the service user is permitted. Furthermore, the authentication processing unit 144 refers to the authorization class DB to determine whether the access API used in the access request is included in the "API information" of the specified "authorization class," i.e., whether use of the API specified by the service user is permitted. Furthermore, the authentication processing unit 144 refers to the authorization class DB to determine whether the instruction content indicated in the access request is within the scope of the "acquisition authority" of the specified "authorization class," i.e., whether access to the instruction content requested by the service user is permitted. Then, if the vehicle to be accessed is not indicated in the "authorization object," if the access API is not included in the "API information," or if the instruction content is outside the scope of the "acquisition authority," the authentication processing unit 144 determines that the access is not authorized. If it is determined that the access is not authorized, the authentication processing unit 144 notifies the service user of the access denial via the access API, as indicated by arrow L24. If the vehicle to be accessed is indicated in the "authorization object," the access API is included in the "API information," and the instruction content is within the scope of the "acquisition authority," the authentication processing unit 144 determines that the access is authorized. If it is determined that the access is authorized, the authentication processing unit 144 transfers the access request to the shadow 114 or the actual vehicle that is the access target, as indicated by arrow L25. Thereafter, the access result returned from the access target is provided to the service user via the access API, as indicated by arrow L26.

[0164] In addition, the access API may use either "object-id" or "vin" as information to identify a vehicle, and if "vin" is used, the vehicle identification information storage unit 143 may be referenced and "vin" may be converted to "object-id."

[0165] 12, the management center 3 includes an index acquisition unit 127, a data acquisition unit 119, and a vehicle control unit 130 as components for implementing an access request via the access API. The index acquisition unit 127 realizes a function of acquiring data from an index 126 accumulated in an index storage unit 125. The data acquisition unit 119 realizes a function of acquiring data from a shadow 114 accumulated in a shadow storage unit 113. The vehicle control unit 130 realizes a function of accessing a vehicle equipped with the edge device 2 by utilizing a communication function with the edge device 2.

[0166] That is, an access request input via the data acquisition API 146 (hereinafter referred to as a data acquisition request) is processed by the index acquisition unit 127. Also, an access request input via the vehicle control API 148 (hereinafter referred to as a vehicle control request) is processed by the vehicle control unit 130.

[0167] [3-3. Data acquisition process] The data acquisition process is a series of processes executed when the data acquisition API 146 receives a data acquisition request. Specifically, this is the data acquisition process that is executed when an access request is sent from the access API to the access target after the authentication process and authorization process are performed in Fig. 18. The data acquisition process is a process in which the data acquisition API 146 is used to acquire specified data from the shadow 114 managed in the management center 3.

[0168] First, the specification information included in the data acquisition request will be described. The specification information is set by the service user.

[0169] As shown in FIG. 19, the designation information includes vehicle designation information, time designation information, and data designation information.

[0170] Vehicle designation information is information for designating vehicles (hereinafter referred to as target vehicles) from which data is to be acquired. Vehicle designation information can be obtained by listing the vehicle IDs (i.e., object-id or vin) of the target vehicles in list format, or by designating the geographical area in which the target vehicles are located (hereinafter referred to as area designation). Alternatively, target vehicles may be designated by their make and model, etc.

[0171] As shown in Figure 20, there are three methods for specifying an area: rectangle specification, polygon specification, and neighborhood specification. Rectangle specification is a method for specifying a rectangular geographical area using the coordinates of the upper left corner and the lower right corner. The coordinates are expressed using latitude and longitude. Polygon specification is a method for specifying a polygonal geographical area using the coordinates of each of the n vertices of the polygon. Neighborhood specification is a method for specifying a circular geographical area using the center coordinates and the distance from the center coordinates.

[0172] 19, the time designation information is information that designates the timing at which data was generated. The time designation information is expressed by a starting time and a range. The range is, for example, a value that represents a time width as an integer equal to or greater than 1, with the generation cycle of the latest index 118 being the unit time.

[0173] The data designation information is information that designates the data to be acquired. The data designation information may be expressed in list form as the item names of the data indicated in the standardized vehicle data, or may be expressed by designating the category names indicated in the standardized vehicle data. If a category name is designated, all items belonging to that category are designated. Furthermore, if neither an item name nor a category name is designated, all items are designated. Furthermore, data that can be designated by an item name may include raw data that is not included in the standardized vehicle data. For example, the data designation information may include the CAN ID of a CAN frame associated with the raw data.

[0174] The method of setting the vehicle specification information, time specification information, and data specification information shown here is an example, and the present invention is not limited to the above method.

[0175] Next, the shadow list generation process executed by the index acquisition unit 127 when the data acquisition API 146 receives a data acquisition request will be described with reference to the flowchart of FIG.

[0176] In S110, the index acquisition unit 127 refers to the vehicle designation information indicated in the data acquisition request, and if the designation information is a vehicle ID list, the process proceeds to S120, and if the designation information is an area designation, the process proceeds to S130.

[0177] In S120, the index acquisition unit 127 refers to the index storage unit 125 to extract all indexes 126 that have the “object-id” indicated in the vehicle ID list and have a “timestamp” within the time range indicated in the time specification information, and then proceeds to S150.

[0178] In S130, the index acquisition unit 127 sets a search area in which to search for the target vehicle in accordance with the area designation indicated in the designation information.

[0179] In the next step S140, the index acquisition unit 127 refers to the index storage unit 125 to extract all indexes 126 that have a "location" within the search area set in S130 and a "timestamp" within the time range indicated in the time specification information, and then proceeds to step S150.

[0180] In S150, for each of the indexes 126 extracted in S120 or S140, the index acquisition unit 127 generates shadow identification information by combining the "object-id" and "shadow-version" indicated in the index 126. The generated shadow identification information becomes a component of a shadow identification information list (hereinafter referred to as a shadow list) that lists the shadow identification information.

[0181] In the following S160, the index acquisition unit 127 outputs a shadow access request to the data acquisition unit 119 of the shadow management unit 112, which adds the data specification information indicated in the data acquisition request to the shadow list generated in S150, and then terminates the processing.

[0182] 22, when the index acquisition unit 127 receives a data acquisition request from the data acquisition API 146, it generates a shadow list, as indicated by arrow L31. The shadow list is generated according to the acquisition conditions, which are the vehicle designation information and time designation information indicated in the data acquisition request. In addition, the index acquisition unit 127 outputs a shadow access request that combines the generated shadow list with the data designation information to the data acquisition unit 119, as indicated by arrow L32.

[0183] When the data acquisition unit 119 receives a shadow access request from the index acquisition unit 127, it references the shadow storage unit 113 and extracts the shadows 114 corresponding to each piece of shadow identification information indicated in the shadow list of the shadow access request. Furthermore, the data acquisition unit 119 extracts designated data, which is data indicated in the data designation information of the shadow access request, from each of the extracted shadows 114. As indicated by arrow L33, the data acquisition unit 119 returns the extracted designated data as an access result to the data acquisition API 146 that originated the request.

[0184] [3-4. Vehicle control processing] The vehicle control process is a series of processes executed when the vehicle control API 148 receives a vehicle control request from a service user. The vehicle control process is a process of specifying a vehicle and requesting control of the specified vehicle (hereinafter, "target vehicle"). The process of requesting control may be, for example, a process of requesting operation of an in-vehicle device, or a process of requesting acquisition of data stored in the edge device 2 or the ECUs 210, 220, and 230.

[0185] First, the specification information included in the vehicle control request will be described.

[0186] As shown in FIG. 23, the designation information designated by the service user includes vehicle designation information, execution target information, control designation information, priority information, time limit information, and vehicle authentication information.

[0187] The vehicle specification information indicates one vehicle ID. The vehicle identified by the vehicle ID is the target vehicle. The vehicle ID corresponds to the above-mentioned vin or object-id.

[0188] The execution target information is information that specifies which application installed in the target vehicle is to execute the control content indicated in the control specification information, and indicates an application ID that identifies the application.

[0189] The control designation information indicates the specific content of control to be executed by the target vehicle. For example, it may include the operation of keys on various doors such as the front doors and trunk door, the operation of audio devices such as a horn and a buzzer, the operation of various lamps such as headlights and hazard lights, and the operation of various sensors such as a camera and radar. The control designation information may include information indicating which device is to perform what operation. The control designation information may indicate a single control, or may indicate multiple controls to be executed consecutively in a list format. Note that controls indicated in a list format must be executed in the order listed. The control designation information may also include an operation to acquire data stored in the edge device 2 or the ECUs 210, 220, and 230.

[0190] The priority information indicates the priority when a control instruction generated based on a vehicle control request is transmitted to a target vehicle. Here, two levels are set: high priority and low priority. The priority information may be set by the service user who is the requestor, or may be set automatically according to the content of the control indicated in the control specification information. Alternatively, the vehicle control API 148 may set the priority based on a predetermined rule.

[0191] The time limit information indicates the latest time that control of the target vehicle is permitted. The time limit information is set, for example, to a limit of 10 minutes from the time the vehicle control request is input. As with the priority information, the time limit information may be set by the service user who is the requestor, or may be set automatically depending on the content of the control requested of the vehicle. Alternatively, the vehicle control API 148 may set the control time information based on a predetermined rule.

[0192] Vehicle authentication information is information used to determine whether a target vehicle can accept a control command, and is composed of an owner ID and password that identify the owner of the target vehicle. The vehicle authentication information is stored in the vehicle and also in service users who are authorized to access the vehicle. In the case of a shared car, the vehicle authentication information may be composed of a user ID and password that identify the user of the target vehicle.

[0193] As shown in Fig. 24, when a vehicle control request is input from the vehicle control API 148 as indicated by arrow L41, the vehicle control unit 130 transmits one or more control instructions generated based on the vehicle control request to the target vehicle as indicated by arrow L42. For simplicity, Fig. 24 shows a case in which one control instruction is transmitted. The vehicle control unit 130 executes relay control for the control instruction. The relay control includes, for example, control to improve the reliability of vehicle control achieved by accessing the target vehicle.

[0194] When the edge device 2 mounted on the vehicle receives a control instruction from the management center 3, the edge device 2 compares the vehicle authentication information indicated in the control instruction with the vehicle authentication information possessed by the vehicle itself to perform authentication.

[0195] If the authentication fails, the edge device 2 transmits a response to the management center 3 including a notification to that effect.

[0196] If the authentication is successful, the edge device 2 causes the application identified from the implementation target information to execute the control indicated in the control specification information. The application requests the ECU 210 to execute the control in accordance with the control specification information. The ECU 210 requests the ECUs 220 and 230 to be controlled to execute the control. In addition, the edge device 2 transmits a response including the result of the execution of the control to the management center 3, as indicated by arrow L43.

[0197] Upon receiving the response, the vehicle control unit 130 returns the response content to the vehicle control API 148, as indicated by arrow L44.

[0198] [3-5, Communication Control] The communication control that the vehicle control unit 130 executes when communicating with the vehicle will be described.

[0199] As shown in FIG. 25, the vehicle control unit 130 includes a reception unit 131, a transmission management unit 132, a reception management unit 133, and a control history storage unit 134.

[0200] The control history storage unit 134 stores history data of control instructions sent to the vehicle. The history data includes an order ID and a control status in addition to part of the specified information indicated in the vehicle control request.

[0201] As shown in FIG. 26, the designation information stored as history data includes vehicle designation information, priority information, and control designation information. The order ID is a number serially assigned to history data (i.e., control instructions) registered in the control history storage unit 134. The control status lists predefined statuses for control instructions, and a timestamp indicating the time at which the status changed to the corresponding status is stored in association with each status. The statuses include a state in which a request to send a control instruction has been accepted, a state in which a control instruction has been sent, a state in which a response has been received, and the like.

[0202] The reception unit 131, the transmission management unit 132, and the reception management unit 133 execute the processing by referring to the control history storage unit 134 and the shadow 114 of the target vehicle stored in the shadow storage unit 113.

[0203] [3-5-1. Reception process] The reception process executed by the reception unit 131 when the vehicle control API 148 receives a vehicle control request will be described with reference to the flowchart of FIG.

[0204] In S210, the reception unit 131 first executes the order process.

[0205] The order process will now be described with reference to the flowchart of FIG.

[0206] In S310, the reception unit 131 refers to the specification information of the vehicle control request and determines whether or not the control instruction information lists multiple controls in list format. If the control instructions are listed in list format, the processing proceeds to S320; if one control is listed, the processing proceeds to S330.

[0207] In S320, the reception unit 131 generates a plurality of control instructions from the vehicle control request, and proceeds to S340. Specifically, if the number of controls indicated in the list format in the control instruction information is N, N control instructions are generated from one vehicle control request. The generated N control instructions are copies of the original vehicle control request except for the control instruction information, and one control is indicated in the control instruction information.

[0208] In S330, the receiving unit 131 generates one control instruction from the vehicle control request, and the process proceeds to S340. Specifically, the control instruction has content that directly inherits the specification information of the vehicle control request.

[0209] In S340, the reception unit 131 assigns an order ID to the control instruction and ends the process. Basically, a serial number is assigned as the order ID in the order in which the control instructions are received. If multiple control instructions are generated from one vehicle control request in S320, order IDs are assigned to these multiple control instructions in the order of the controls indicated in the control instruction information of the original vehicle control request.

[0210] Here, individual controls specified in a list format in the control instruction information are referred to as unit controls. Unit controls may be simple controls such as "lights on" or "lights off," or may be controls such as "turn the horn on and off twice at 100-msec intervals" or "turn the headlights on and off three times at 200-msec intervals." In other words, a unit control may specify a repetition of the same type of control, including interval information. Such control instructions correspond to specific control instructions. Because the delay until each control instruction reaches the edge device 2 varies depending on the situation, it is difficult for the management center 3 to manage the control intervals. However, if the repetition of the same control including interval information is referred to as unit control, the control intervals are controlled on the vehicle side, allowing the vehicle to faithfully reproduce the control intended by the service user. That is, for example, the edge device 2 sends an instruction to the ECU 210 to turn on the horn, waits 100 msec, sends an instruction to turn off the horn, waits 100 msec, sends an instruction to turn on the horn, waits 100 msec, and sends an instruction to turn off the horn.

[0211] Returning to FIG. 27, when the sequential processing is completed, in the subsequent S220, the reception unit 131 executes the wake-up processing.

[0212] The wake-up process will now be described with reference to the flowchart of FIG.

[0213] In S410, the reception unit 131 acquires the "power_status" indicated in the latest shadow 114 of the target vehicle from the shadow storage unit 113. The power supply state of the edge device 2 can be determined from this "power_status".

[0214] In the following S420, the reception unit 131 determines whether or not "power_status" indicates power on. If power is on, the process ends, but if power is off instead of on, the process proceeds to S430.

[0215] In S430, the reception unit 131 transmits a wake-up instruction to the edge device 2 of the target vehicle. Upon receiving the wake-up instruction, the edge device 2 transitions from a power-off or sleep state to a power-on or wake-up state.

[0216] In the next S440, the reception unit 131 waits for a certain period of time (for example, one second) and returns the process to S410.

[0217] That is, if the "power_status" is power off, a wake-up instruction is sent to transition the edge device 2 to a wake-up state in which all of its functions are available. The state change is notified to the management center 3 by a response to the wake-up instruction from the vehicle or by the vehicle periodically sending vehicle data, and the "power_status" of the shadow 114 of the target vehicle is updated to power on.

[0218] The vehicle control unit 130 may be configured to refer to the latest "mobility_data" (i.e., standardized vehicle data) of the shadow 114 and issue power control instructions to devices other than the edge device 2. For example, if the ignition power of the target vehicle is off, an instruction to turn on the ignition power is sent via the edge device 2 to the electronic control device that controls the power supply. Also, if the power of a camera mounted on the target vehicle that takes pictures of the outside or inside of the vehicle is off, an instruction to start the camera is sent via the edge device 2. In this way, by sending advance instructions to the target vehicle, the vehicle control request accepted by the acceptance unit 131 can be reliably executed by the edge device 2.

[0219] 27, when the wake-up control is completed, in the following S230, the reception unit 131 registers the control instruction as history data in the control history storage unit 134. The control status at the time of registration is set to "Accept", which indicates that the control has been accepted.

[0220] In the following S240, the reception unit 131 executes priority processing and ends the process.

[0221] Here, the priority process will be explained using the flowchart in FIG.

[0222] In S510, the reception unit 131 acquires priority information of the control instruction to be processed. The priority information is set as designation information of the vehicle control request as shown in Fig. 23, and is associated with the control instruction and registered in the control history storage unit 134 as shown in Fig. 26.

[0223] In the next S520, the reception unit 131 determines whether or not a priority is set in the acquired priority information, and if a priority is set, the process proceeds to S540, and if no priority is set, the process proceeds to S530.

[0224] In S530, the receiving unit 131 sets the priority information to low priority, and proceeds to S540. For example, if there are three or more priority levels, the lowest priority value is set.

[0225] In S540, the reception unit 131 determines whether the priority information is set to a high priority, and if it is set to a high priority, proceeds to S550, whereas if it is set to a low priority rather than a high priority, proceeds to S560. For example, it may be determined to be a high priority if a priority has been set, or it may be determined to be a high priority if the priority value is equal to or greater than a predetermined threshold.

[0226] In S550, the reception unit 131 registers the control instruction in a priority queue, and the process proceeds to S570. A queue is a buffer having a data structure that allows data to be retrieved in the order in which it was written.

[0227] In S560, the reception unit 131 registers the control instruction in a non-priority queue, and the process proceeds to S570.

[0228] In S570, the reception unit 131 sequentially retrieves control instructions from the priority queue and non-priority queue, prioritizing the priority queue, passes the retrieved control instructions to the transmission management unit 132, and terminates the process. Prioritizing the priority queue may mean, for example, retrieving data from the priority queue as long as data remains in the priority queue, and retrieving data from the non-priority queue only when there is no data in the priority queue. Alternatively, data may be retrieved from the priority queue at a higher rate than from the non-priority queue.

[0229] [3-5-2. Sending side processing] The transmission side process executed by the transmission management unit 132 will be described with reference to the flowchart shown in Fig. 31. The transmission side process is a process performed when a control instruction is extracted from the priority queue or non-priority queue in S570 and transmitted to the edge device 2.

[0230] In S610, the transmission management unit 132 acquires the time limit information included in the instruction information of the control instruction provided from the reception unit 131 (that is, the time limit information shown in FIG. 23).

[0231] In the next step S620, the transmission management unit 132 determines whether the current time exceeds the time limit indicated in the time limit information. If the time limit has been exceeded, the process proceeds to S630. If the time limit has not been exceeded, the process proceeds to S640. For example, the current time may exceed the time limit because it takes time for the control instruction to be removed from the non-priority queue. Note that, to determine whether the time limit has been exceeded, a time before the time limit by the amount of time required for the control instruction to arrive at the vehicle from the management center 3 may be used. Furthermore, a time before the time limit by the amount of time required for the control instruction to be executed in the vehicle may be used. In other words, if the time required for the control instruction to arrive at the vehicle and be executed exceeds the time limit information, the process may proceed to S630.

[0232] Here, instead of the determination based on the time limit information in S620, a change in the vehicle state may be used as a condition for determining whether or not control has failed. For example, if the condition "vehicle is stopped" is specified as the limit information, the latest shadow 114 or the latest timestamp data in the standardized vehicle data is referenced to determine whether or not the vehicle is still stopped. If it is determined that the vehicle is stopped, the process may proceed to S640, and if it is determined that the vehicle is not stopped, the process may proceed to S630.

[0233] In S630, the transmission management unit 132 transmits a completion notification to the requesting vehicle control API 148 informing it that the control has failed, updates the control status of the control history storage unit 134 to control failure, and terminates the process.

[0234] In S640, after transmitting the control instruction to the edge device 2, the transmission management unit 132 acquires corresponding data associated with the control instruction provided by the reception unit 131 from the shadow 114 of the target vehicle. After transmitting the control instruction to the edge device 2, the transmission management unit 132 may wait a predetermined time and then acquire the corresponding data from the latest shadow 114 of the target vehicle. The corresponding data is data with the latest timestamp among the data belonging to the standardized vehicle data, and has a value corresponding to the state of the vehicle that changes before and after executing the control instruction. For example, if the control instruction is to unlock a door, the corresponding data is vehicle data indicating the state of the lock of the door to be unlocked. For example, if the control instruction is to turn on the headlights, the corresponding data is vehicle data indicating the state of the headlights to be turned on. The corresponding data is vehicle data indicating the state of the device or ECU 210, 220, 230 to be controlled.

[0235] In the next S650, the transmission management unit 132 determines whether the corresponding data has the value after control execution, and if it has the value after control execution, proceeds to S660, and if it has not the value after control execution, proceeds to S670. Note that if the control instruction does not have corresponding data, the processes of S640 to S660 may be omitted.

[0236] In S660, the transmission management unit 132 transmits a completion notification to the requesting vehicle control API 148 notifying that the control has been successful, and updates the control status of the control history storage unit 134 to "control success", and then ends the process.

[0237] In S670, the transmission management unit 132 executes transmission of the control instruction. That is, it publishes an MQTT message representing the control instruction to the MQTT broker. At the same time, the transmission management unit 132 updates the control status of the control history storage unit 134 to "sent."

[0238] In the next step S680, the transmission management unit 132 checks the control status in the control history storage unit 134. That is, it checks which of the control statuses has the most recent timestamp written therein.

[0239] In the following S690, the transmission management unit 132 determines whether the control status is "Complete," which indicates that the control instruction has reached the target vehicle successfully, and if it is "Complete," proceeds to S700; if it is not "Complete," proceeds to S710.

[0240] In S700, the transmission management unit 132 sends a completion notification to the vehicle control API 148 that made the request, informing it that the control was successful, and updates the control status of the control history memory unit 134 to control success, and then ends the processing.

[0241] In S710, the transmission management unit 132 determines whether the time elapsed since the control instruction was transmitted has expired, and if the time has not expired, the process proceeds to S720. If the time has expired, the process proceeds to S730. The determination of whether the time has expired is based on whether a preset allowable time (e.g., 10 minutes) has been exceeded. The allowable time may be set based on time limit information specified when the vehicle control request is made.

[0242] In S720, the transmission management unit 132 waits for a preset period of time (for example, one minute), and then returns the process to S680.

[0243] In S730, the transmission management unit 132 returns a timeout notification to the vehicle control API 148 that made the request, and updates the control status of the control history storage unit 134 to abnormal termination due to timeout. Furthermore, the transmission management unit 132 invalidates the MQTT message corresponding to the control instruction and ends the processing. That is, the transmission management unit 132 performs the invalidation process to notify the vehicle that the control instruction that has already been transmitted to the vehicle does not need to be executed by the vehicle.

[0244] Note that the invalidation process may be omitted, and the service user who receives the timeout notification may be allowed to decide whether or not to execute control equivalent to the invalidation process. That is, for example, if a vehicle control request to turn on the lights is input from the vehicle control API 148, when a timeout notification is returned, the service user may leave it as it is, or may input a vehicle control request to turn off the lights from the vehicle control API 148 just to be safe.

[0245] [3-5-3. Receiving side processing] The reception side process executed by the reception management unit 133 will be described with reference to the flowchart shown in Fig. 32. This process is executed repeatedly.

[0246] In S810, the reception management unit 133 determines whether or not a wake-up completion notification has been received in response to the wake-up instruction sent in the previous S430, and if so, proceeds to S820; if not, proceeds to S830.

[0247] In S820, the reception management unit 133 updates the "power_status" of the target vehicle's shadow 114 to power on, and then ends the process. In response to this update, the determination in the previous S420 is affirmative.

[0248] In S830, the reception management unit 133 determines whether or not an arrival notification has been received in response to the control instruction sent in the previous S670, and if an arrival notification has been received, the processing proceeds to S840; if an arrival notification has not been received, the processing terminates.

[0249] In S840, the reception management unit 133 updates the control status of the history data stored in the control history storage unit 134 for the control instruction that is the target of the arrival notification from "Accept" to "Complete," and then ends the process. In response to this update, the determination in the previous S690 is affirmative.

[0250] As shown in FIG. 25, the edge device 2 includes a wake-up control unit 201 and an instruction execution unit 202.

[0251] The wake-up control unit 201 manages the power state of the vehicle equipped with the edge device 2. The vehicle's power state can be a low-power sleep state in which some functions are stopped, or a wake-up state in which all functions are activated. When the wake-up control unit 201 receives a wake-up instruction addressed to the vehicle from the management center 3 while the vehicle is in the sleep state, it transitions the power state of the edge device 2 to the wake-up state and sends a wake-up completion notification to the management center 3.

[0252] The instruction execution unit 202 operates when the power supply state of the vehicle is in a wake-up state. The instruction execution unit 202 performs authentication by comparing vehicle authentication information attached to the control instruction with vehicle authentication information held by the vehicle, and if the authentication is successful, the instruction execution unit 202 executes the control indicated in the control instruction itself or causes the corresponding electronic control unit to execute it. If the authentication fails, the instruction execution unit 202 transmits a response indicating this to the management center 3, and if the control has been executed, the instruction execution unit 202 transmits the control result to the management center 3.

[0253] [3-6. Example of operation] An example of the operation of the vehicle control unit 130 will be described.

[0254] First, a typical operation when the power state of the edge device 2 of the target vehicle is in the wake-up state will be described with reference to Fig. 33. Note that the "pwer_status" of the shadow 114 of the target vehicle reflects the power state of the edge device 2 of the target vehicle and is set to "power on."

[0255] The reception unit 131 registers history data of the control instruction in the control history storage unit 134, as indicated by arrow L51. By registering the history data, the control status of the history data is set to "Accept." Furthermore, the reception unit 131 transmits the control instruction to the transmission management unit 132, as indicated by arrow L52.

[0256] Upon receiving the control instruction, the transmission management unit 132 checks the "power_status" of the Shadow 114 of the target vehicle, as shown by arrow L53. Because the "power_status" is "power on," the transmission management unit 132 transmits a control instruction to the target vehicle, as shown by arrow L54. Thereafter, the transmission management unit 132 periodically checks the control status of the history data, as shown by arrow L55.

[0257] The target vehicle that has received the control instruction returns an arrival notification to the management center 3, as indicated by arrow L56, indicating that the control instruction has been received normally.

[0258] Upon receiving the arrival notification, the reception management unit 133 updates the control status of the history data from "Accept" to "Complete", as indicated by arrow L57.

[0259] When the transmission management unit 132 periodically checks the historical data and confirms that the control status has changed to "Complete," it sends a completion notification indicating that the control instruction has been completed successfully to the requesting vehicle control API 148, as shown by arrow L58.

[0260] Next, the operation when a control instruction is sent to a target vehicle but an arrival notification is not returned from the target vehicle will be described with reference to FIG.

[0261] As shown by arrows L51 to L55, the process from when the reception unit 131 registers the historical data until when the transmission management unit 132 transmits a control instruction to the target vehicle and starts periodic monitoring of the historical data is the same as that shown in Figure 33.

[0262] After sending a control instruction to the target vehicle, if the control status of the history data remains "Accept" even after the time limit indicated in the time limit information or the preset allowable time has elapsed, the transmission management unit 132 sends a timeout notification to the requesting vehicle control API 148 indicating an abnormal termination, as shown by arrow L59.

[0263] Next, the operation when the power state of the edge device 2 of the target vehicle is in a sleep state will be described with reference to Fig. 35. Note that the "power_status" of the shadow 114 of the target vehicle reflects the power state of the edge device 2 of the target vehicle and is set to "power off." Also, as indicated by arrows L51 to L53, the process from when the reception unit 131 registers the history data until when the transmission management unit 132 checks the "power_status" of the shadow 114 of the target vehicle is the same as that shown in Fig. 33.

[0264] The transmission management unit 132 checks that the "power_status" of the shadow 114 of the target vehicle is "power off," so the transmission management unit 132 sends a wake-up command to the target vehicle, as indicated by arrow L60. Thereafter, the transmission management unit 132 periodically checks the "power_status" of the target vehicle.

[0265] Upon receiving the wake-up instruction, the target vehicle transitions the power state of the edge device 2 from the sleep state to the wake-up state, and returns a wake-up completion notification to the management center 3, as indicated by arrow L61.

[0266] Upon receiving the wake-up completion notification, the reception management unit 133 updates the "power_status" of the shadow 114 of the target vehicle to "power on", as indicated by arrow L62.

[0267] When the transmission management unit 132 periodically checks that the "power_status" of the edge device 2 of the target vehicle has changed to "power on", as shown by arrow L63, it sends a control instruction to the target vehicle, as shown by arrow L64.

[0268] The subsequent operations are the same as those indicated by arrows L55 to L59 in FIGS.

[0269] [4. Terminology] In the above-described embodiment, the mobility IoT system 1 corresponds to a mobility service providing system, the management center 3 corresponds to a mobility service infrastructure server, and the edge device 2 corresponds to an on-board device. The shadow management unit 112 corresponds to a first database, and the data management unit 121 corresponds to a second database. The API provision unit 122 corresponds to an interface unit. The process of S230 corresponds to a history registration unit, the processes of S310 to S340 correspond to a sequence control unit, and the processes of S510 to S570 correspond to a priority processing unit. The processes of S610 to S620 correspond to a pre-transmission determination unit. The processes of S680 to S700 and S720 correspond to a delivery confirmation unit, the processes of S710 and S730 correspond to an invalidation unit, and the processes of S630 and S830 to S840 correspond to a history update unit. The control status "Accept" corresponds to an acceptance state, "Complete" corresponds to a completion state, and a vehicle control request corresponds to an access request.

[0270] [5. Effects] According to the embodiment described above in detail, the following effects are achieved.

[0271] (5a) In the mobility IoT system 1, priority information is included in the vehicle control request, and control instructions generated from the vehicle control request are transmitted to the vehicle with priority given to control instructions set to high priority. Therefore, even in a situation where many control instructions are backed up at the management center 3, transmission of high-priority control instructions can be completed with little delay.

[0272] (5b) In the mobility IoT system 1, each control instruction realizes an independent control, and each control instruction is assigned an order ID using a serial number. Furthermore, the vehicle that receives the control instructions executes the control in the order according to the serial number indicated in the order ID. Therefore, even if the order of the control instructions arriving at the vehicle is changed due to factors such as the communication environment between the management center 3 and the vehicle (i.e., the edge device 2), the vehicle can execute the control in the order intended by the requester of the vehicle control request. As a result, the safety and reliability of vehicle control based on instructions from the management center 3 can be improved. For example, in a series of controls that must be executed in a strict order, changing the order of the controls may result in completely different or meaningless control, but this prevents such a situation from occurring.

[0273] (5c) After sending a control instruction to a vehicle, the mobility IoT system 1 repeatedly checks the control status. If the status changes to indicate a response from the vehicle, a completion notification is returned to the requester of the vehicle control request. If the status does not change even after an allowable time has elapsed, a timeout notification is returned to the requester of the vehicle control request. Therefore, the mobility IoT system 1 can notify the requester of the vehicle control request that the control instruction has reached the vehicle, or that the control instruction did not reach the vehicle within the allowable time. As a result, the requester of the vehicle control request can take appropriate action depending on whether the control instruction has reached the vehicle.

[0274] (5d) In the mobility IoT system 1, if the control instruction reaches the vehicle but it is not possible to complete the control by the time limit, the mobility IoT system 1 notifies the requester of the vehicle control request that the control has failed without sending the control instruction. Furthermore, before sending the control instruction, the mobility IoT system 1 checks the corresponding data associated with the control instruction by referring to the shadow 114 of the target vehicle. If the corresponding data matches the value after control execution, the mobility IoT system 1 notifies the requester of the vehicle control request that the control has been successful without sending the control instruction. Therefore, the mobility IoT system 1 suppresses the transmission of unnecessary control instructions, thereby reducing the amount of communication between the management center 3 and the vehicle.

[0275] (5e) Before transmitting a control instruction, the mobility IoT system 1 checks the "power_status" of the target vehicle by referencing the shadow 114 of the target vehicle, and if the power is off, transmits a wake-up instruction. In other words, the mobility IoT system 1 transmits the control instruction after transitioning the target vehicle to a state where it can execute the control instruction. Therefore, the mobility IoT system 1 can start up the target vehicle and execute control even when the engine of the target vehicle is off.

[0276] 6. Other Embodiments Although one embodiment of the present disclosure has been described above, the present disclosure is not limited to the above embodiment and can be implemented in various modifications.

[0277] (6a) In the present disclosure, the control history storage unit 134 stores history data in units of control instructions, but the history data may be stored in units of vehicle control requests (that is, units of requests from the vehicle control API 148).

[0278] (6b) In the present disclosure, the vehicle control unit 130 is configured to return responses from the edge device 2 to the control instructions to the requesting vehicle control API 148 on a control instruction basis as they are. The present disclosure is not limited to this, and when multiple control instructions are generated from one vehicle control request, the vehicle control unit 130 may be configured to return responses from the edge device 2 to the control instructions to the requesting vehicle control API 148 on a vehicle control request basis.

[0279] (6c) In the present disclosure, in response to a control instruction from the management center 3, the edge device 2 sends a response to the management center 3 when the execution of the control content is completed, but the edge device 2 may also send a response to the management center 3 when the control instruction is received.

[0280] (6d) The control unit 31 and its method described herein may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to execute one or more functions embodied in a computer program. Alternatively, the control unit 31 and its 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 31 and its method described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to execute one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored in a computer-readable non-transitory tangible recording medium as instructions to be executed by a computer. The method for implementing the functions of each unit included in the control unit 31 does not necessarily need to include software; all of the functions may be implemented using one or more hardware devices.

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

[0282] (6f) In addition to the management center 3 described above, the present disclosure can also be realized in various forms, such as a system including the management center 3 as a component, a program for causing a computer to function as the management center 3, a non-transient physical recording medium such as a semiconductor memory on which this program is recorded, and a vehicle access control method.

Claims

1. A mobility service providing system having a mobility service infrastructure server (3) configured to be able to communicate with a vehicle, and a service providing server (4) configured to be able to communicate with the mobility service infrastructure server and providing a service to the vehicle using a function provided by the mobility service infrastructure server, The mobility service infrastructure server a vehicle-side unit (110) having a first database (112) that stores a plurality of shadows, which are vehicle data groups that are generated for each vehicle based on vehicle data provided by an on-board device mounted on the vehicle and that represent the state of the vehicle at a specific time; a service-side unit (120) having a second database (121) that stores an index corresponding to each of the shadows stored in the first database and having information used to search for the shadows, and an interface unit (122) configured to receive an access request from the service providing server; Equipped with The vehicle-side unit includes: a vehicle control unit (130) configured to, when the interface unit receives the access request requesting operation of an on-board device for the vehicle, execute access to the target vehicle by wirelessly communicating with the on-board device mounted in the target vehicle, the vehicle being the target of access; The vehicle control unit The vehicle-mounted device is configured to execute relay control in response to control instructions transmitted and received between the vehicle-mounted device and the vehicle-mounted device. Mobility service provision system.

2. A mobility service providing system comprising: an on-board device mounted on a vehicle; a mobility service infrastructure server configured to be able to communicate with the vehicle; and a service providing server configured to be able to communicate with the mobility service infrastructure server and providing a service to the vehicle using a function provided by the mobility service infrastructure server, The mobility service infrastructure server a vehicle-side unit having a first database that stores a plurality of shadows, which are vehicle data groups that are generated for each vehicle based on the vehicle data provided by the on-board device and represent the state of the vehicle at a specific time; a service-side unit having a second database that stores indexes corresponding to the shadows stored in the first database and having information used to search for the shadows, and an interface unit configured to receive access requests from the service providing server; Equipped with The vehicle-side unit includes: a vehicle control unit configured to, when the interface unit receives the access request requesting operation of an in-vehicle device for the vehicle, execute access to the target vehicle by wirelessly communicating with the in-vehicle device mounted in the target vehicle, the vehicle being the target of access; The vehicle control unit configured to execute relay control for control instructions transmitted to and received from the vehicle-mounted device, The vehicle-mounted device is configured to receive the control instruction and execute the content of the control instruction. Mobility service provision system.

3. 3. The mobility service providing system according to claim 1 or 2, The service side unit an index acquisition unit (127) configured to acquire the index from the second database; The vehicle-side unit includes: a data acquisition unit (119) configured to acquire the vehicle data from the first database using the index acquired by the index acquisition unit when the interface unit receives the access request requesting acquisition of data for the vehicle; Mobility service provision system.

4. A vehicle access control method in a mobility service infrastructure server comprising: a first database that stores a plurality of shadows, each of which is a group of vehicle data that is generated for each vehicle based on vehicle data provided by an onboard device mounted on the vehicle and that represents a state of the vehicle at a specific time; a second database that stores indexes that correspond to each of the shadows stored in the first database and have information used to search for the shadows; and an interface unit configured to receive access requests from an external device, When the interface unit receives the access request from a service providing server that provides a service to the vehicle using a function provided by the mobility service infrastructure server, the interface unit performs wireless communication with the on-board device installed in the target vehicle, which is the vehicle to be accessed, to access the target vehicle; In accessing the target vehicle, a relay control is performed for a control instruction transmitted and received between the vehicle-mounted device and the target vehicle. Vehicle access control methods.

5. a first database storing a plurality of shadows, which are vehicle data groups that are generated for each vehicle based on vehicle data provided by an on-board device mounted on the vehicle and that represent the state of the vehicle at a specific time; a second database storing indexes that correspond to each of the shadows stored in the first database and have information used to search for the shadows; and an interface unit configured to receive access requests from an external device, the computer constituting a mobility service infrastructure server, When the interface unit receives an access request from a service providing server that provides services to the vehicle using the functions provided by the mobility service infrastructure server, requesting operation of on-board equipment for the vehicle, the program functions as a vehicle control unit configured to access the target vehicle by wirelessly communicating with the on-board equipment installed in the target vehicle, which is the vehicle that is the target of access, and to perform relay control for control instructions sent and received between the on-board equipment and the target vehicle when accessing the target vehicle.

Images