WO2023277031A1 - モビリティサービス基盤サーバ、モビリティサービス提供システム、車両アクセス制御方法、プログラム - Google Patents

モビリティサービス基盤サーバ、モビリティサービス提供システム、車両アクセス制御方法、プログラム Download PDF

Info

Publication number
WO2023277031A1
WO2023277031A1 PCT/JP2022/025811 JP2022025811W WO2023277031A1 WO 2023277031 A1 WO2023277031 A1 WO 2023277031A1 JP 2022025811 W JP2022025811 W JP 2022025811W WO 2023277031 A1 WO2023277031 A1 WO 2023277031A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
control
unit
data
mobility service
Prior art date
Application number
PCT/JP2022/025811
Other languages
English (en)
French (fr)
Inventor
正俊 小見山
顕匠 滝
凌非 謝
繁 梶岡
真紀子 田内
Original Assignee
株式会社デンソー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社デンソー filed Critical 株式会社デンソー
Priority to CN202280046549.7A priority Critical patent/CN117651980A/zh
Priority to JP2023531990A priority patent/JPWO2023277031A1/ja
Publication of WO2023277031A1 publication Critical patent/WO2023277031A1/ja
Priority to US18/397,685 priority patent/US20240127646A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
    • G07C9/00309—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y10/00—Economic sectors
    • G16Y10/40—Transportation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y40/00—IoT characterised by the purpose of the information processing
    • G16Y40/30—Control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks

Definitions

  • This disclosure relates to technology for providing mobility services.
  • Patent Document 1 describes a digital twin simulation that reproduces the state of a vehicle in the real world in virtual space by collecting vehicle data from the vehicle.
  • This disclosure provides techniques for improving the reliability of vehicle access related to mobility services.
  • the mobility service infrastructure server includes a vehicle-side unit and a service-side unit.
  • 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 the vehicle-mounted device and that represent the state of the vehicle at a specific time.
  • the service side unit has a second database and an interface section.
  • a second database stores an index corresponding to each of the shadows stored in the first database and having information used in retrieving the shadows.
  • the interface unit is configured to receive access requests from the outside.
  • the vehicle-side unit accesses the target vehicle by performing wireless communication with an in-vehicle device mounted on the target vehicle, which is the vehicle to be accessed. It further comprises a vehicle control unit configured as above.
  • the vehicle control unit is configured to perform relay control in response to control instructions transmitted and received to and from the vehicle-mounted device.
  • the mobility service providing system includes an in-vehicle device mounted on a vehicle and the mobility service infrastructure server described above.
  • a mobility service infrastructure server to which a vehicle access control method is applied includes a first database, a second database, and an interface unit.
  • the interface unit when the interface unit receives an access request to a vehicle, access to the target vehicle is performed by performing wireless communication with an in-vehicle device installed in the target vehicle, which is the vehicle to be accessed. do.
  • relay control is executed for control instructions sent and received to and from the vehicle-mounted device.
  • a computer that executes a program constitutes a mobility service infrastructure server together with a first database, a second database, and an interface unit.
  • the program causes the computer to function as a vehicle control unit.
  • the vehicle control unit accesses the target vehicle by performing wireless communication with an in-vehicle device mounted on the target vehicle, which is the vehicle to be accessed.
  • the vehicle control unit is configured to perform relay control in response to a control instruction transmitted/received to/from the vehicle-mounted device when accessing the target vehicle.
  • FIG. 1 is a block diagram showing the configuration of a mobility IoT system
  • FIG. 3 is a block diagram showing the configuration of an edge device
  • FIG. 3 is a functional block diagram showing a functional configuration of an edge device
  • FIG. 4 is a diagram showing the structure of a frame; It is a figure which shows the structure of a vehicle data conversion table. It is a figure which shows the 1st hierarchy of standardized vehicle data, and a data format. It is a figure which shows the structure of standardized vehicle data.
  • FIG. 3 is a functional block diagram showing the functional configuration of a management center;
  • FIG. 3 is a functional block diagram showing functional configurations of a mobility GW and a data management unit;
  • FIG. FIG. 4 is a diagram showing the configuration of a shadow; It is a figure which shows the structure of a newest index.
  • FIG. 4 is a diagram showing the structure of an index;
  • FIG. 4 is a diagram showing the configuration of an authorization object database held by an authorization information storage unit;
  • FIG. 4 is a diagram showing the structure of an authorization class database held by an authorization information storage unit; 4 is a sequence diagram showing operations of an API provider;
  • FIG. FIG. 10 is a diagram showing the configuration of specification information of a data acquisition request and a shadow access request;
  • FIG. 10 is an explanatory diagram of a designation method for area designation; 8 is a flowchart of shadow list generation processing executed by an index acquisition unit; FIG. 10 is a sequence diagram showing a procedure of data acquisition using a data acquisition API; FIG. 4 is a diagram showing a configuration of designation information of a vehicle control request; FIG. FIG. 5 is a sequence diagram showing a typical operation when a vehicle control request is received; 1 is a diagram showing a configuration of a vehicle equipped with a vehicle control unit and an edge device related to a vehicle control request; FIG. It is a figure which shows the registration content to a control-history memory
  • FIG. 8 is a flowchart of reception processing executed by a reception unit; 4 is a flowchart of sequential processing executed in reception processing; FIG. 10 is a flowchart of wakeup processing executed in reception processing; FIG. 4 is a flowchart of priority processing executed in reception processing; 6 is a flowchart of transmission-side processing executed by a transmission management unit; 6 is a flow chart of receiving-side processing executed by a reception management unit; FIG. 10 is a sequence diagram showing operations when the power supply state of a vehicle that is the target of a vehicle control request is on; FIG. 5 is a sequence diagram showing operations when there is no response from the vehicle to the control instruction; 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; FIG. 2 is a block diagram showing a connection state of an ECU mounted on a vehicle; FIG.
  • the mobility IoT system 1 of this embodiment includes a plurality of edge devices 2, a management center 3, and a service providing server 4, as shown in FIG. IoT is an abbreviation for Internet of Things.
  • the edge device 2 is mounted on the vehicle and has a function of performing data communication with the management center 3 via the wide area wireless communication network NW.
  • 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 plurality of edge devices 2 and the service providing server 4 via the wide area wireless communication network NW.
  • 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 a plurality of service providing servers 4 having different service contents.
  • the service providing server 4 may be configured on-premises or in the cloud.
  • the service providing server 4 may be configured as a server that is physically the same as the management center 3 .
  • the edge device 2 includes a microcomputer 11, a vehicle interface (hereinafter referred to as vehicle I/F) 12, a communication section 13, and a storage section 14, as shown in FIG.
  • 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 section 26, and a bus 27.
  • the microcomputer 11 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-transitional material recording medium.
  • the ROM 23 corresponds to a non-transitional substantive recording medium storing programs. Also, by executing this program, a method corresponding to the program is executed.
  • first core 21 and the second core 22 may be configured as hardware using one or a plurality of ICs or the like.
  • the flash memory 25 is a data rewritable nonvolatile memory.
  • the flash memory 25 includes a standardized vehicle data storage section 25a for storing standardized vehicle data, which will be described later.
  • the input/output unit 26 is a circuit for inputting/outputting data between the outside of the microcomputer 11 and the first core 21 and the second core 22 .
  • 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/output to each other.
  • the vehicle I/F 12 is an input/output circuit for inputting/outputting signals between the electronic control unit and sensors mounted on the vehicle.
  • the vehicle I/F 12 includes a power supply voltage input port, a general-purpose input/output port, a CAN communication port, an Ethernet communication port, and the like.
  • a 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.
  • the edge device 2 can transmit and receive communication frames to and from other electronic control devices.
  • the communication unit 13 performs data communication with the management center 3 via the wide area wireless communication network NW.
  • the storage unit 14 is a storage device for storing various data.
  • the vehicle is equipped with one ECU 210, multiple ECUs 220, multiple ECUs 230, an external communication device 240, and an internal communication network 250.
  • ECU is an abbreviation for Electronic Control Unit.
  • the ECU 210 realizes coordinated control of the vehicle as a whole by integrating the plurality of ECUs 220 .
  • the ECU 220 is provided for each domain divided according to the function of the vehicle, and mainly controls a plurality of ECUs 230 existing within that domain. Each ECU 220 is connected to a subordinate ECU 230 via a lower-layer network (for example, CAN) provided individually.
  • the ECU 220 has a function of centrally managing access rights and the like for the ECU 230 under its control and performing user authentication and the like. Domains are, for example, powertrain, body, chassis and cockpit.
  • the ECU 230 connected to the ECU 220 belonging to the powertrain domain includes, for example, an ECU 230 that controls the engine, an ECU 230 that controls the motor, an ECU 230 that controls the battery, and the like.
  • the ECUs 230 connected to the ECU 220 belonging to the body domain include, for example, the ECU 230 that controls the air conditioner, the ECU 230 that controls the doors, and the like.
  • the ECU 230 connected to the ECU 220 belonging to the chassis domain includes, for example, an ECU 230 that controls brakes, an ECU 230 that controls steering, and the like.
  • the ECU 230 connected to the ECU 220 belonging to the cockpit domain includes, for example, the ECU 230 that controls the display of meters and navigation, and the ECU 230 that controls input devices operated by the vehicle occupants.
  • the vehicle-external communication device 240 performs data communication with a vehicle-external communication device (for example, a cloud server) via the wide area wireless communication network NW.
  • a vehicle-external communication device for example, a cloud server
  • the in-vehicle communication network 250 includes CAN FD and Ethernet.
  • CAN FD is an abbreviation for CAN with Flexible Data Rate.
  • the CAN FD connects the ECU 210 with each ECU 220 and the external communication device 240 via a bus.
  • Ethernet individually connects ECU 210 to each ECU 220 and external communication device 240 .
  • the ECU 210 is an electronic control unit mainly composed of a microcomputer including a CPU 210a, a ROM 210b and a RAM 210c.
  • Various functions of the microcomputer are realized by the CPU 210a executing a program stored in a non-transitional substantive recording medium.
  • the ROM 210b corresponds to the non-transitional substantive recording medium storing the program.
  • a method corresponding to the program is executed.
  • a part or all of the functions executed by the CPU 210a may be configured as hardware using one or a plurality of ICs or the like. Further, the number of microcomputers constituting ECU 210 may be one or more.
  • Each of the ECU 220, the ECU 230, and the external communication device 240 is an electronic control device, similar to the ECU 210, mainly composed of a microcomputer having a CPU, a ROM, a RAM, and the like. Further, the number of microcomputers constituting ECU 220, ECU 230 and external communication device 240 may be one or more.
  • ECU 220 is an ECU that controls one or more ECUs 230
  • ECU 210 is an ECU that controls one or more ECUs 220 or controls ECUs 220 and 230 of the entire vehicle including external communication device 240 .
  • the edge device 2 is connected to the ECU 210 so that data communication with the ECU 210 is possible. 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 a request regarding vehicle control to the ECU 210 and to the ECUs 220 and 230 via the ECU 210 .
  • the edge device 2 includes a first unit 101 as a functional block implemented by the first core 21 executing a program stored in the ROM 23, as shown in FIG.
  • the edge device 2 includes a second unit 102 as a functional block implemented by the second core 22 executing a program stored in the ROM 23 .
  • the first unit 101 comprises a real-time operating system (RTOS) 103 and a first application 104 .
  • RTOS real-time operating system
  • the first application 104 executes 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 in order to execute various processes for controlling the vehicle.
  • the RTOS 103 manages the first application 104 so as to ensure real-time processing by the first application 104 .
  • the second unit 102 comprises a general-purpose operating system (hereinafter referred to as GPOS) 105 and a second application 106.
  • GPOS general-purpose operating system
  • the second application 106 executes processing related to services provided by the service providing server 4 .
  • the second application 106 is configured to be able to access the standardized vehicle data storage section 25a of the flash memory 25 and refer to the standardized vehicle data in order to execute service-related processing.
  • the GPOS 105 is basic software installed in the edge device 2 to operate various applications, and manages the second application 106 .
  • the vehicle I/F 12 Upon receiving the communication frame, the vehicle I/F 12 determines the communication protocol of the communication frame based on the communication port that received the communication frame. Specifically, the vehicle I/F 12 determines that the communication protocol of the received communication frame is the CAN communication protocol, for example, when the communication frame is received at the CAN communication port. For example, when a communication frame is received at an Ethernet communication port, the vehicle I/F 12 determines that the communication protocol of the received communication frame is the Ethernet communication protocol.
  • the vehicle I/F 12 determines whether or not the communication frame is to be processed by the edge device 2. When it is determined that the communication frame is to be processed, It outputs the received communication frame to the first unit 101 .
  • a CAN frame consists of a start of frame, an arbitration field, a control field, a data field, a CRC field, an ACK field and an end of frame, as shown in FIG.
  • the arbitration field consists of an 11-bit or 29-bit identifier (that is, ID) and a 1-bit RTR bit.
  • CANID the 11-bit identifier used in CAN communication.
  • the CANID is set in advance based on the content of data included in the CAN frame, the source of the CAN frame, the destination of the CAN frame, and the like.
  • the data field consists of first data, second data, third data, fourth data, fifth data, sixth data, seventh data and eighth data of 8 bits (ie, 1 byte).
  • each of the 1st to 8th data in the data field will also be referred to as CAN data.
  • the vehicle I/F 12 determines whether it is a processing target based on the CANID.
  • the first unit 101 When the first unit 101 acquires a communication frame output from the vehicle I/F 12, it extracts identification information and data from the communication frame, and creates standard format data composed of the identification information and data.
  • the first unit 101 stores the created standard format data in the flash memory 25 .
  • the first unit 101 creates standard format data composed of CANID and first to eighth data.
  • the first unit 101 updates the standard format data by overwriting the standard format data. do.
  • the second core 22 acquires the standard format data from the flash memory 25.
  • 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 consists of CANID and 1st to 8th data, the second core 22 divides the 1st to 8th data into 8 Extract CAN data.
  • the writing and reading of the standard format data by the first unit 101 and the second unit 102 may use the RAM 24 instead of the flash memory 25 .
  • the second core 22 refers to the vehicle data conversion table 23a stored in the ROM 23, and converts each of the divided extraction data into control labels and vehicle data.
  • the vehicle data conversion table 23a includes normalization information and semantic information.
  • the normalization information is information for normalizing the extracted data so that the same physical quantity has the same value regardless of the vehicle type or vehicle manufacturer.
  • Semantic information is information for converting normalized vehicle data into meaningful vehicle data.
  • the normalized and semantized vehicle data is also referred to as processed data
  • the vehicle data before normalization and semanticization is also referred to as raw data.
  • Raw data refers to data indicated by, for example, a data field of a CAN frame.
  • the normalization information of the vehicle data conversion table 23a includes setting items such as "CANID”, "ECU”, “position”, “DLC”, “unique label”, “resolution”, and “offset ” and “Unit”.
  • ECU is information indicating the source ECU of the CAN frame.
  • ENG indicates an engine ECU.
  • Position is information indicating the position of CAN data in the data field.
  • DLC is information indicating the data length. DLC stands for Data Length Code.
  • Unique label is information indicating a control label. For example, "ETHA” indicates intake air temperature, and "NE1" indicates engine speed. “Resolution” is information indicating a numerical value per bit.
  • the semantic information of the vehicle data conversion table 23a is, for example, as shown in FIG. It includes a conversion formula that converts to "steering angle” by subtracting .
  • this conversion formula the vehicle data representing the "steering movement angle” and the vehicle data representing the "steering zero point” are converted into the vehicle data representing the "steering angle” which means “steering amount from the reference position". be done.
  • the second core 22 hierarchizes the converted vehicle data and stores it in the flash memory 25 . Specifically, the second core 22 stores the converted vehicle data in the corresponding area of the standardized vehicle data storage section 25 a provided in the flash memory 25 .
  • the standardized vehicle data storage unit 25a stores standardized vehicle data configured by layering vehicle data.
  • the standardized vehicle data is created for each vehicle (that is, for each edge device 2) and has multiple hierarchical structures.
  • the standardized vehicle data one or more items are set for each of multiple hierarchies.
  • the standardized vehicle data includes "attribute information”, “power training”, “energy”, “ADAS/AD”, “body”, Equipped with “Multimedia” and “Other”.
  • ADAS stands for Advanced Driver Assistance System.
  • AD stands for Autonomous Driving.
  • “Attribute information”, “power training”, “energy” and the like correspond to categories.
  • each vehicle data has "unique label", "ECU”, "data type”, “data size”, “data value” and “data unit” as items. "Unique label” and “ECU” are as described above. "Data type”, “data size” and “data unit” indicate the type, size and unit of the numerical value indicated by the "data value”.
  • the standardized vehicle data has at least the second and third hierarchies in addition to the first hierarchy.
  • the second hierarchy is the hierarchy immediately below the first hierarchy
  • the third hierarchy is the hierarchy immediately below the second hierarchy.
  • the standardized vehicle data are items set in the normalization and semantic processing described above.
  • Standardized vehicle data has a hierarchical data structure.
  • attribute information which is an item in the first hierarchy, includes "vehicle identification information”, “vehicle attribute”, “transmission configuration”, and “firmware version” as items in the second hierarchy.
  • vehicle identification information is a category name indicating information that can uniquely identify a vehicle.
  • Vehicle attribute is a category name indicating the type of vehicle.
  • Transport configuration is a category name indicating information about transmission.
  • firmware version is a category name indicating information about the firmware of the vehicle.
  • Powertrain which is an item in the first hierarchy, is a category name indicating information related to powertrain.
  • Power training includes items such as “accelerator pedal”, “engine”, and “engine oil” as items in the second hierarchy.
  • the “accelerator pedal” includes one or more pieces of vehicle data such as the state and opening of the accelerator pedal.
  • Engine includes one or more individual vehicle data such as engine state, number of revolutions, and the like. Items in the second hierarchy also correspond to categories. The same applies to the other items of the first hierarchy.
  • Energy which is an item in the first layer, is a category name indicating information related to energy. "Energy” includes items such as “battery state”, “battery configuration”, and “fuel” as items in the second hierarchy.
  • Vehicle identification information which is an item of the second hierarchy, has “vehicle identification number”, “vehicle number”, and “license plate” as items of the third hierarchy.
  • Items in the third hierarchy are one or more individual vehicle data, and are also called items. That is, in the hierarchical structure of the standardized vehicle data, items at the lowest level are called items, and items other than the lowest level (that is, items having lower levels) are called categories.
  • Vehicle attribute which is an item in the second hierarchy, has items such as "brand name”, “model”, and “year of manufacture” as items in the third hierarchy.
  • Transmission configuration which is an item of the second hierarchy, has “transmission type” as an item of the third hierarchy.
  • the second core 22 determines that the first layer is “attribute information” and the second layer is The converted vehicle data is stored in the storage area of "vehicle identification information" whose third layer is "vehicle identification number".
  • “Others” may include, for example, location information acquired via the vehicle I/F 12 from a GPS device mounted on the vehicle, that is, latitude, longitude, and altitude.
  • vehicle I/F 12 when vehicle I/F 12 acquires vehicle data from the vehicle, vehicle I/F 12 performs communication protocol determination, as indicated by arrow L12. Further, vehicle I/F 12 filters unnecessary vehicle data as indicated by arrow L13, and outputs necessary vehicle data to first unit 101 as indicated by arrow L14.
  • the first unit 101 When the first unit 101 acquires vehicle data from the vehicle I/F 12, it converts the vehicle data into a standard format as indicated by an arrow L15, and flashes the vehicle data converted into the standard format as indicated by an arrow L16. Store in memory 25 .
  • the second unit 102 When the second unit 102 acquires the vehicle data converted into the standard format from the flash memory 25 as indicated by arrow L17, it converts the acquired vehicle data as indicated by arrow L18. Furthermore, the second unit 102 structures the converted data to create standardized vehicle data, as indicated by an arrow L19.
  • Timing information representing the timing of transmitting data to the management center 3 is set in each vehicle data belonging to the standardized vehicle data.
  • the timing information is set according to the degree of data change, the importance of the data, and the like so that the more frequently changing data and the higher the importance of the data, the shorter the cycle.
  • the timing information is, for example, a 500 ms period, a 2 s period, a 4 s period, a 30 s period, a 300 s period, a 12 hour period, or the like.
  • the second core 22 executes transmission processing in a transmission unit time (for example, 250 ms) cycle.
  • the first frequency data which is vehicle data transmitted in a cycle of 500 ms
  • the second frequency data which is vehicle data transmitted in a 1s period
  • the data of each group is transmitted at different transmission timings. That is, by transmitting each vehicle data according to a transmission schedule set in advance, it is possible to suppress the concentration of transmission of many vehicle data at the same transmission timing. Also, by transmitting each vehicle data at a frequency according to its characteristics, efficient transmission is realized.
  • the management center 3 includes a control section 31, a communication section 32, and a storage section 33, as shown in FIG.
  • the control unit 31 is an electronic control device mainly composed of a microcomputer including a CPU 41, a ROM 42, a RAM 43, and the like.
  • Various functions of the microcomputer are realized by the CPU 41 executing a program stored in a non-transitional substantive recording medium.
  • the ROM 42 corresponds to the non-transitional substantive recording medium storing the program. Also, by executing this program, a method corresponding to the program is executed.
  • a part or all of the functions executed by the CPU 41 may be configured as hardware using one or a plurality of ICs or the like. Further, the number of microcomputers constituting the control unit 31 may be one or more.
  • the communication unit 32 performs data communication with the plurality of edge devices 2 and the service providing server 4 via the wide area wireless communication network NW.
  • MQTT which is a publish/subscribe type simple and lightweight protocol, is used for communication with the edge device 2 .
  • MQTT stands for Message Queue Telemetry Transport.
  • the storage unit 33 is a storage device for storing various data.
  • the management center 3 includes a vehicle-side unit 110 and a service-side unit 120 as functional blocks implemented by the CPU 41 executing programs stored in the ROM 42, as shown in FIG.
  • the vehicle-side unit 110 is the functional block closer to access to the vehicle
  • the service-side unit 120 is the functional block closer to the access from the service providing server 4 . These two functional blocks are loosely coupled.
  • 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.
  • the electronic circuit may be realized by a digital circuit including many logic circuits, an analog circuit, or a combination thereof.
  • 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 an access request to the vehicle and a function of managing data received from the vehicle.
  • the mobility GW 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 containing vehicle data provided for each vehicle on which the edge device 2 is mounted.
  • a shadow 114 indicates a group of vehicle data for a certain vehicle. Shadow 114 is generated based on the standardized vehicle data sent from edge device 2 .
  • the vehicle control unit 130 has a function of controlling a vehicle equipped with the edge device 2 via the edge device 2 according to instructions from the service providing server 4 .
  • 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 manager 121 and an API provider 122 .
  • API is an abbreviation for Application Programming Interface.
  • the data management unit 121 has a function of managing a digital twin 123, which is a virtual space for providing vehicle access independent of changes in vehicle connection status.
  • the data management section 121 manages data necessary for accessing vehicle data managed by the vehicle-side unit 110 .
  • 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 APIs for accessing vehicles and acquiring vehicle data.
  • the shadow management unit 112 includes a shadow creation unit 115 , a shadow storage unit 113 , a latest index creation unit 116 , a shadow storage unit 113 , a shadow storage unit 116 , and a shadow storage unit 113 . and a latest index storage unit 117 .
  • the shadow creation unit 115 receives structured standardized vehicle data from the edge device 2 . Every time vehicle data is transmitted from the edge device 2, the shadow creation unit 115 updates the standardized vehicle data by overwriting the corresponding area of the structured standardized vehicle data with the transmitted vehicle data. Shadow creator 115 may receive a portion of the structured standardized vehicle data. A shadow creation unit 115 creates a new shadow 114 using the updated standardized vehicle data. The shadow creating unit 115 stores 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 add arbitrary information such as a serial number and store it in the shadow storage unit 113 . The shadow storage unit 113 stores a plurality of shadows 114 created in chronological order for each vehicle. In other words, the shadow 114 can be regarded as a copy of the state of the vehicle equipped with the edge device 2 at a certain time.
  • a single shadow 114 is a vehicle data group of a certain vehicle at a predetermined time, and includes a vehicle data group represented by the standardized data structure shown in FIG. Note that the timing at which the shadow creation unit 115 receives the structured standardized vehicle data via the communication unit 32 differs depending on the vehicle.
  • a new shadow 114 may be created at the same timing for all vehicles.
  • the shadow creating unit 115 may create new shadows 114 for all vehicles at regular intervals. Past shadows 114 are accumulated in the shadow storage unit 113 for each vehicle. Shadows 114 that have passed a certain period of time may be deleted sequentially.
  • the shadow 114 includes a vehicle data storage section 114a and a device data storage section 114b.
  • the vehicle data storage unit 114a stores "object-id”, "Shadow_version” and "mobility-data” as data related to the vehicle on which the edge device 2 is mounted.
  • object-id is a character string that identifies the vehicle equipped with the edge device 2, and functions as a partition key.
  • Shadow_version is a numerical value indicating the version of the shadow 114, and a time stamp indicating the creation time is set each time the shadow 114 is created.
  • the device data storage unit 114b stores “object-id”, “update_time”, “version”, “power_status”, “power_status_timestamp”, “notify_reason” as data about the hardware, software, and status of the edge device 2. " is stored.
  • object-id is the same as described for the vehicle data storage unit 114a.
  • update_time is a numerical value indicating the update time.
  • “version” is a character string indicating the version of the hardware and software of the edge device 2.
  • 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 can be used, and a “power-off” state in which some functions are stopped to reduce power consumption.
  • power_status_timestamp is a numerical value indicating the notification time of the system status.
  • notify_reason is a character string indicating the reason for notification.
  • the shadow 114 includes information on the edge device 2 in addition to the vehicle data group.
  • the device data storage unit 114b may store the information of 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 in the ROM 42 or the like instead of accumulating past data for each time stamp.
  • the latest index creation unit 116 acquires the latest shadow 114 for each vehicle from the shadow storage unit 113 and creates the 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 (that is, for each object-id).
  • the latest index 118 includes "gateway-id", “object-id”, “shadow-version”, “vin”, “location-lon”, “location-lat” and “location-alt " is stored.
  • object-id and "shadow-version” are the same as those described for the shadow 114.
  • gateway-id is information that identifies the mobility GW 111. This is information for identifying a plurality of management centers 3, for example, if they are provided for each country.
  • vin is a registration number unique to the vehicle on which the edge device 2 is mounted.
  • location-lon is information indicating the latitude at which the vehicle equipped with the edge device 2 is located.
  • location-lat is information indicating the longitude at which the vehicle equipped with the edge device 2 is located.
  • location-alt is information indicating the altitude at which the vehicle equipped with the edge device 2 is located.
  • the data management unit 121 includes an index creation unit 124 and an index storage unit 125 as components for realizing a function of accumulating the latest index 118 acquired from the shadow management unit 112 as an index 126. .
  • the index creation unit 124 acquires the latest index 118 from the latest index storage unit 117 according to a preset acquisition schedule, and uses the acquired latest index 118 to create an index 126 for the digital twin 123 .
  • the index creation unit 124 then sequentially stores the created indexes 126 in the index storage unit 125 .
  • the index storage unit 125 stores a plurality of 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 on the digital twin 123, which is virtual space-time.
  • the indices 126 are "timestamp”, “schedule-type”, “gateway-id”, “object-id”, “shadow-version”, “vin”, “location” and “alt”. to store
  • timestamp is a time stamp indicating the time when the index 126 was created in milliseconds.
  • Schedule-type indicates whether the scheduler that created the data is regular or event. If it is regular, 'schedule-type' is set to 'Repeat', and if it is an event, 'schedule-type' is set to 'Event'.
  • location is information inherited from “location-lon” and “location-lat” of the latest index 118
  • alt is information inherited from “location-alt” of the latest index 118.
  • the shadow management unit 112 may have a configuration in which the latest index creation unit 116 and the latest index storage unit 117 are omitted.
  • the index creation unit 124 may acquire the shadows 114 stored in the shadow storage unit 113 and create the index 126 .
  • index creation unit 124 creates index 126 using latest index 118 obtained from 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.
  • the data management unit 121 may have a configuration in which the index creation unit 124 and the index storage unit 125 are omitted.
  • the index acquisition unit 127 acquires the vehicle data specified by the data acquisition unit 119 using the object-id and time stamp (that is, shadow-version) specified via the API provision unit 122. may be requested.
  • the service-side unit 120 has an API provider 122 .
  • the API providing unit 122 is an interface prepared for allowing an external service provider such as the service providing server 4 to use the functions of the management center 3 .
  • a user of the mobility IoT system 1 who uses the API providing unit 122 or the like is hereinafter referred to as a service user.
  • a service user is, for example, a service provider that makes home deliveries to the trunk of a vehicle.
  • 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, as shown in FIG. Further, as types of APIs provided to service users, a login API 145, a data acquisition API 146, and a vehicle control API 148 are provided.
  • the login API 145 is an API provided for authenticating service users.
  • Data acquisition API 146 is an API provided for service users to acquire data.
  • a vehicle control API 148 is an API provided for the service user to control the vehicle.
  • the authentication information storage unit 141 stores "authentication information" in association with the "service user ID".
  • “Service user ID” is identification information that uniquely identifies a service user.
  • “Authentication information” is information for authenticating the identity of the service user, and is, for example, a preset password.
  • the authorization information storage unit 142 includes an authorization object database (hereinafter referred to as authorization object DB) and an authorization class DB.
  • authorization object DB an authorization object database
  • authorization class DB an authorization class DB
  • the authorization object DB stores "authorization class”, "authorization object” and "expiration date” in association with "service user ID”.
  • “Authorization class” is information representing the scope of authority granted to a service user.
  • An “authorization object” is a list of vehicle “object-ids” that are permitted to be accessed by a service user.
  • “Expiration date” is the start date and end date of the period during which the registered contents are valid.
  • the authorization object DB is a database that indicates the registered contents of the authority of each service user with respect to the mobility IoT system 1 . Multiple registrations for one service user may be made in the authorization object DB, provided that the 'authorization objects' are different or the 'expiration dates' do not overlap.
  • the authorization class DB stores "API information”, "acquisition authority”, and "expiration date” in association with the "authorization class".
  • the authorization class DB is a database representing the specific contents of the "authorization class”.
  • Authorization class is information identifying a plurality of classes representing the data range to which authorization is granted. A class may exist.
  • the “authorization class” is not limited to the classification of the data range in which data can be read and written, and may be the classification of the operation control range in which the operation can be controlled.
  • 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.
  • “Acquisition authority” is a list of obtainable data permitted for the service user of the corresponding "authorization class".
  • the authorization class is "open"
  • the data included in the "acquisition authority” is limited to information that can be freely accessed by anyone, and may include, for example, vehicle location information and altitude information.
  • 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 the vehicle on which the edge device 2 is mounted. 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 types of accessible data may be set for each class. may be set differently.
  • Acquirable data are listed here as the acquisition authority, but in place of or in addition to the acquirable data, an available function, for example, for a vehicle equipped with the edge device 2 Control types and the like may be listed. Acquirable data are enumerated, for example, from the data items shown in FIG.
  • the vehicle identification information storage unit 143 stores table information that associates the "object-id" uniquely assigned to the vehicle on which the edge device 2 is mounted and the "vin" of the vehicle.
  • the authentication processing unit 144 executes authentication processing when an authentication request is made through the login API 145, and executes authorization processing when an access request is made through the data acquisition API 146 and the vehicle control API 148. . Authentication processing and authorization processing will be described later.
  • the login API 145 is used when a service user logs into the mobility IoT system 1.
  • the authentication processing unit 144 executes 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 .
  • a token which is data serving as a certificate for permitting access to the mobility IoT system 1, is returned. .
  • the data acquisition API 146 is an API used to access vehicle data (that is, index 126 and shadow 114) accumulated in the management center 3, as indicated by L1 in FIG.
  • the vehicle control API 148 is an API used to access a vehicle on which the edge device 2 is mounted, as indicated by L2 in FIG.
  • the data acquisition API 146 and the vehicle control API 148 are collectively referred to as access APIs.
  • the access API receives an access request from a service user
  • the authentication processing unit 144 executes authorization processing.
  • the authentication processing unit 144 When the authorization process is executed, the authentication processing unit 144 identifies the "service user ID” from the “token” added to the access request. Next, the authentication processing unit 144 identifies the “authorization class” and “authorization object” of the identified “service user ID” by searching the authorization object DB of the authorization information storage unit 142 . Furthermore, the authentication processing unit 144 determines whether or not the vehicle to be accessed indicated in the access request is indicated in the "authorization object", that is, whether or not access to the vehicle specified by the service user is permitted. judge. The authentication processing unit 144 also 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 designated “authorization class”. Determine whether use of the specified API is permitted.
  • the authentication processing unit 144 refers to the authorization class DB to determine whether or not the instruction indicated in the access request is within the scope of the “acquisition authority” of the specified “authorization class”. It is determined whether or not access to the instruction content requested by the user is permitted. 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 is judged to be unapproved. If it is determined to be unauthorized, the authentication processing unit 144 notifies the service user of access denial via the access API, as indicated by arrow L24.
  • 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 judge. If it is determined to be authorized, authentication processing unit 144 transfers the access request to shadow 114 or the actual vehicle to be accessed, as indicated by arrow L25. After that, as indicated by arrow L26, the access result returned from the access target is provided to the service user via the access API.
  • the management center 3 includes an index acquisition unit 127, a data acquisition unit 119, and a vehicle control unit 130 as components for realizing access requests via the access API.
  • the index acquisition unit 127 implements a function of acquiring data from the index 126 accumulated in the index storage unit 125 .
  • the data acquisition unit 119 implements a function of acquiring data from the shadows 114 accumulated in the shadow storage unit 113 .
  • the vehicle control unit 130 implements a function of accessing a vehicle in which the edge device 2 is mounted using a communication function with the edge device 2 .
  • 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.
  • An access request (hereinafter referred to as a vehicle control request) input via the vehicle control API 148 is processed by the vehicle control unit 130 .
  • a data acquisition process which is a series of processes executed when the data acquisition API 146 receives a data acquisition request, will be described. Specifically, it is data acquisition processing when an access request is transmitted from the access API to the access target after authentication processing and authorization processing are performed in FIG.
  • the data acquisition process is a process of acquiring specified data from the shadow 114 managed within the management center 3 using the data acquisition API 146 .
  • the specified information included in the data acquisition request will be explained.
  • the specified information is set by the service user.
  • the designation information includes vehicle designation information, time designation information, and data designation information.
  • the vehicle designation information is information for designating the vehicle for which data is to be obtained (hereinafter referred to as the target vehicle).
  • the vehicle designation information includes a method of listing the vehicle IDs (that is, object-id or vin) of the target vehicle in a list format, and a method of designating a geographical area where the target vehicle exists (hereinafter referred to as area designation).
  • the target vehicle may be designated according to the vehicle type, model, or the like.
  • Rectangular designation is a method of designating a rectangular geographic area using upper left corner coordinates and lower right corner coordinates. Coordinates are expressed using latitude and longitude.
  • Polygon designation is a method of designating a geographical area of a polygon by coordinates of n vertices of the polygon.
  • Neighborhood designation is a method of designating a circular geographical area by center coordinates and a distance from the center coordinates.
  • the time designation information is information that designates the timing at which the data was generated.
  • the time designation information is represented by the starting time and range.
  • the range is, for example, a value in which the time width is represented by an integer equal to or greater than 1, with the generation cycle of the latest index 118 being the unit of time.
  • the data specification information is information that specifies the data to be acquired.
  • the data designation information may be represented in the form of a list of item names of data indicated in the standardized vehicle data, or may be indicated by specifying category names indicated in the standardized vehicle data. If you specify a category name, all items belonging to that category are specified. If neither item name nor category name is specified, all items are specified.
  • the data that can be specified by the item name may include raw data that is not included in the standardized vehicle data.
  • the data designation information may include the CANID of the CAN frame associated with the raw data.
  • the method of setting the vehicle designation information, time designation information, and data designation information shown here is an example, and is not limited to the above method.
  • shadow list generation processing executed by the index acquisition unit 127 when the data acquisition API 146 receives a data acquisition request will be described using the flowchart of FIG.
  • the index acquisition unit 127 refers to the vehicle designation information indicated in the data acquisition request. If the designation information is a vehicle ID list, the process proceeds to S120. to S130.
  • the index acquisition unit 127 refers to the index storage unit 125, and has the "object-id” indicated in the vehicle ID list and the "timestamp” within the time range indicated in the time designation information. and the process proceeds to S150.
  • the index acquisition unit 127 sets a search area for searching for the target vehicle according to the area designation indicated by the designation information.
  • the index acquisition unit 127 refers to the index storage unit 125, and has a "location" within the search area set in S130, and a "timestamp" within the time range indicated by the time designation information. , and the process proceeds to S150.
  • the index acquisition unit 127 In S150, the index acquisition unit 127 generates shadow identification information by combining "object-id" and "shadow-version” indicated in the index 126 for each index 126 extracted in S120 or S140.
  • the generated shadow identification information constitutes a shadow identification information list (hereinafter referred to as a shadow list) listing shadow identification information.
  • the index acquisition unit 127 outputs to the data acquisition unit 119 of the shadow management unit 112 a shadow access request in which the data designation information indicated in the data acquisition request is added to the shadow list generated in S150. to end the process.
  • the index acquisition unit 127 generates a shadow list upon receiving a data acquisition request from the data acquisition API 146 as indicated by an arrow L31.
  • the shadow list is generated according to acquisition conditions, with vehicle designation information and time designation information indicated in the data acquisition request as acquisition conditions.
  • index acquisition section 127 outputs a shadow access request combining the generated shadow list and data designation information to data acquisition section 119, as indicated by arrow L32.
  • the data acquisition unit 119 refers to the shadow storage unit 113 to acquire the shadow 114 corresponding to each shadow specifying information indicated in the shadow list of the shadow access request. Extract. Furthermore, the data acquisition unit 119 extracts specified data, which is data indicated by the data specifying information of the shadow access request, from each of the extracted shadows 114 . As indicated by an arrow L33, the data acquisition unit 119 returns the extracted specified data as an access result to the data acquisition API 146 that made the request.
  • a vehicle control process which is a series of processes executed when the vehicle control API 148 receives a vehicle control request from a service user, will be described.
  • the vehicle control process is a process of designating a vehicle and requesting control of the designated vehicle (hereinafter referred to as a target vehicle).
  • the process of requesting control may be, for example, a process of requesting the operation of the vehicle-mounted device, or a process of requesting acquisition of data stored by the edge device 2 or the ECUs 210 , 220 , 230 .
  • 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.
  • One vehicle ID is indicated in the vehicle designation information.
  • a vehicle specified from the vehicle ID is the target vehicle.
  • the vehicle ID corresponds to vin or object-id described above.
  • 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.
  • the control designation information indicates the specific contents of the control to be executed by the target vehicle. For example, it includes key operation of various doors such as each seat door and trunk door, operation of acoustic equipment such as horn and buzzer, operation of various lamps such as headlamps and hazard lamps, and operation of various sensors such as cameras and radars.
  • the control designation information may include information indicating which device is to operate in what manner.
  • the control designation information may indicate one control, or may indicate a plurality of controls to be executed continuously in the form of a list. It should be noted that the controls shown in list form must be executed in the order listed.
  • the control designation information may include an acquisition operation of data stored by the edge device 2 or the ECUs 210, 220, and 230.
  • Priority information indicates the priority when transmitting a control instruction generated based on a vehicle control request to the target vehicle.
  • the priority information may be set by the service user who is the source of the request, or may be automatically set according to the content of control indicated in the control designation information.
  • the vehicle control API 148 may set the priority based on a predetermined rule.
  • the time limit information indicates the final time at which control of the target vehicle is permitted.
  • the time limit information is set with, for example, the time when the vehicle control request is input plus 10 minutes as the limit.
  • the time limit information may be set by the service user who is the source of the request, or may be automatically set according to the details of the control requested of the vehicle.
  • the vehicle control API 148 may set the control time information based on a predetermined rule.
  • the vehicle authentication information is information used to determine whether or not the target vehicle can accept the control instruction, and consists of an owner ID and a password that identify the owner of the target vehicle.
  • Vehicle authentication information is maintained on the vehicle and also on service users authorized to access the vehicle. In the case of a shared car, the vehicle authentication information may be composed of a user ID for identifying the user of the target vehicle and a password.
  • FIG. 24 shows a case of transmitting one control instruction for simplicity.
  • Vehicle control unit 130 executes relay control in response to the control instruction.
  • Relay control includes, for example, control for improving the reliability of vehicle control realized by accessing the target vehicle.
  • the edge device 2 mounted on the vehicle Upon receiving a control instruction from the management center 3, the edge device 2 mounted on the vehicle performs authentication by comparing the vehicle authentication information indicated in the control instruction with the vehicle authentication information possessed by the own vehicle.
  • the edge device 2 sends a response including a notification to that effect to the management center 3.
  • the edge device 2 causes the application specified by the execution target information to execute the control indicated by the control designation information.
  • the application requests ECU 210 to execute control according to the control designation information.
  • ECU 210 requests execution of control from ECUs 220 and 230 to be controlled.
  • the edge device 2 transmits a response including the control execution result to the management center 3, as indicated by an arrow L43.
  • the vehicle control unit 130 Upon receiving the response, the vehicle control unit 130 returns the content of the response to the vehicle control API 148 as indicated by an arrow L44.
  • 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.
  • the control history storage unit 134 stores history data of control instructions to be transmitted 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.
  • the designation information stored as history data includes vehicle designation information, priority information, and control designation information.
  • the order ID is a serial number assigned to history data (ie, control instructions) registered in the control history storage unit 134 .
  • control status predefined statuses for control instructions are listed, and in association with this status, a time stamp representing the time when the corresponding status changed is stored.
  • the status includes a state in which a control instruction transmission request is received, a control instruction transmission state, a response reception state, and the like.
  • the reception unit 131, the transmission management unit 132, and the reception management unit 133 refer to the shadow 114 of the target vehicle stored in the control history storage unit 134 and the shadow storage unit 113 to execute processing.
  • the reception unit 131 first executes the order processing.
  • the reception unit 131 refers to the vehicle control request specification information, determines whether or not a plurality of controls are described in list format in the control instruction information. , and if one control is described, the process proceeds to S330.
  • the reception unit 131 generates a plurality of control instructions from the vehicle control request, and advances the process to S340. Specifically, when the number of controls indicated in 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 copied from the original vehicle control request for portions other than the control instruction information, and the control instruction information indicates one control.
  • the reception unit 131 generates one control instruction from the vehicle control request, and advances the process to S340.
  • the control instruction has contents obtained by directly inheriting the specification information of the vehicle control request.
  • the reception unit 131 adds an order ID to the control instruction, and ends the process.
  • serial numbers are assigned as order IDs in the order in which control instructions are received.
  • order IDs are assigned to the plurality of control instructions in the order of control indicated in the control instruction information of the original vehicle control request. do.
  • Unit control includes not only simple contents such as “lights on” and “lights off”, but also “turns on and off the horn twice at 100msec intervals” and “turns the headlights on and off three times at 200msec intervals".
  • the content may be such as That is, the unit control may be a unit control that designates repetition of the same type of control, including interval information.
  • Such a control instruction corresponds to a specific control instruction. Since the delay until each control instruction reaches the edge device 2 varies depending on the situation at the time, it is difficult for the management center 3 to manage control intervals.
  • the edge device 2 transmits an instruction to turn on the horn to the ECU 210, waits for 100 msec, transmits an instruction to turn off the horn, waits for 100 msec, transmits an instruction to turn on the horn, and waits for 100 msec. and send an instruction to turn off the horn.
  • the reception unit 131 executes wakeup processing in S220.
  • the reception unit 131 acquires "power_status" indicated in the latest shadow 114 of the target vehicle from the shadow storage unit 113.
  • the power status of the edge device 2 is known from this "power_status”.
  • the receiving unit 131 determines whether or not the "power_status" indicates that the power is on. If the power is on, the process is terminated. do.
  • the reception unit 131 transmits a wake-up instruction to the edge device 2 of the target vehicle.
  • the edge device 2 transitions from the power-off or sleep state to the power-on or wakeup state.
  • the reception unit 131 waits for a certain period of time (for example, 1 second) and returns the process to S410.
  • the vehicle control unit 130 may be configured to refer to the latest "mobility_data" (that is, standardized vehicle data) of the shadow 114 and issue power control instructions to devices other than the edge device 2 .
  • the latest "mobility_data” that is, standardized vehicle data
  • an ignition power source ON instruction is transmitted to the electronic control device that controls the power source via the edge device 2 .
  • a camera activation instruction is transmitted via the edge device 2 .
  • the reception unit 131 registers the control instruction in the control history storage unit 134 as history data.
  • the control status at the time of registration is set to "Accept" indicating that control has been accepted.
  • the reception unit 131 executes priority processing and ends the processing.
  • the reception unit 131 acquires priority information of the control instruction to be processed.
  • the priority information as shown in FIG. 23, is set as specification information for the vehicle control request, and is registered in the control history storage unit 134 in association with the control instruction, as shown in FIG.
  • the reception unit 131 determines whether or not the priority information obtained has priority settings. to S530.
  • the reception unit 131 sets the priority information to low priority, and shifts the process to S540. For example, if there are three or more priority levels, the lowest priority value is set.
  • the reception unit 131 determines whether or not the priority information setting is high priority, and if the priority is high, the process proceeds to S550.
  • the process proceeds to S560. For example, if the priority is set, it may be determined that the priority is high, or if the priority value is equal to or greater than a predetermined threshold, it may be determined that the priority is high.
  • a queue is a buffer having a data structure that allows data to be retrieved in the order in which it was written.
  • the reception unit 131 registers the control instruction in the non-priority queue, and advances the process to S570.
  • the receiving unit 131 gives priority to the priority queue, sequentially extracts the control instructions from the priority queue and the non-priority queue, passes the extracted control instructions to the transmission management unit 132, and ends the process.
  • Giving priority to the priority queue may mean, for example, that data is retrieved from the priority queue as long as data remains in the priority queue, and data is retrieved from the non-priority queue only when there is no data in the priority queue. Also, the priority queue may retrieve data at a higher rate than the non-priority queue.
  • Transmission-side processing executed by the transmission management unit 132 will be described with reference to the flowchart shown in FIG.
  • the transmission-side processing is processing when a control instruction is extracted from the priority queue or the non-priority queue and transmitted to the edge device 2 in S570.
  • the transmission management unit 132 acquires the time limit information included in the instruction information of the control instruction provided by the reception unit 131 (that is, the time limit information shown in FIG. 23).
  • the transmission management unit 132 determines whether or not the current time exceeds the time limit indicated in the time limit information. If not exceeded, the process proceeds to S640. For example, it is conceivable that the current time exceeds the time limit because it takes time to be taken out of the non-priority queue. It should be noted that a time earlier than the time limit may be used for determining whether or not the time limit is exceeded by the time required for the control instruction to reach the vehicle from the management center 3 . Furthermore, a time earlier than the time limit may be used by the amount of time required for the vehicle to complete execution of the control instruction. That is, when the time required for the control instruction to reach the vehicle and for the execution to be completed exceeds the time limit information, the process may proceed to S630.
  • the process may proceed to S640, and if it is determined that the motor is not stopped, the process may proceed to S630.
  • the transmission management unit 132 transmits a completion notification notifying that the control has failed to the requesting vehicle control API 148, updates the control status of the control history storage unit 134 to control failure, and terminates the process. do.
  • the transmission management unit 132 acquires corresponding data associated with the control instruction provided from the reception unit 131 from the shadow 114 of the target vehicle.
  • the corresponding data may be acquired from the latest shadow 114 of the target vehicle.
  • Corresponding data is data with the latest time stamp 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 the control instruction is executed. For example, when the control instruction is to unlock a door, the corresponding data is vehicle data representing the state of the key of the door to be unlocked.
  • the corresponding data is vehicle data representing the state of the headlights to be turned on.
  • the corresponding data is vehicle data representing the state of the equipment to be controlled or the ECUs 210 , 220 , 230 .
  • the transmission management unit 132 determines whether or not the corresponding data is the value after the execution of control. If not, the process proceeds to S670. Note that the processing of S640 to S660 may be omitted in the case of a control instruction for which no corresponding data exists.
  • the transmission management unit 132 transmits a completion notification notifying that the control was successful to the requesting vehicle control API 148, updates the control status of the control history storage unit 134 to control success, and terminates the process. do.
  • the transmission management unit 132 executes transmission of the control instruction. That is, it publishes MQTT messages representing control directives 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 "transmitted".
  • the transmission management unit 132 checks the control status of the control history storage unit 134. In other words, it confirms which of the control statuses has the latest time stamp written.
  • the transmission management unit 132 determines whether or not the control status is "Complete” indicating that the control instruction has normally reached the target vehicle. If it is not "Complete”, the process proceeds to S710.
  • the transmission management unit 132 transmits a completion notification notifying that the control was successful to the vehicle control API 148 that made the request, and updates the control status of the control history storage unit 134 to control success. exit.
  • the transmission management unit 132 determines whether or not the elapsed time from the transmission of the control instruction has timed out. The process proceeds to S730. It should be noted that the determination of whether or not the time has expired is made based on whether or not the time has exceeded a preset allowable time (for example, 10 minutes). Note that the allowable time may be set based on time limit information specified when requesting vehicle control.
  • the transmission management unit 132 waits for a predetermined period of time (for example, 1 minute), and then returns the process to S680.
  • 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 terminates the process. That is, the transmission management unit 132 performs the invalidation process to notify the vehicle that the vehicle does not need to execute the control instruction that has already been transmitted to the vehicle.
  • the invalidation process may be omitted, and the service user who receives the timeout notification may decide whether or not to execute the control equivalent to the invalidation process. That is, for example, a vehicle control request to turn on the lights is input from the vehicle control API 148, but when a timeout notification is returned, the service user may leave the vehicle control request as it is, or just in case, turn off the lights. Requests may be input from vehicle control API 148 .
  • Receiving-side processing executed by the reception management unit 133 will be described with reference to the flowchart shown in FIG. This process is repeatedly executed.
  • the reception management unit 133 determines whether or not a wakeup completion notification has been received in response to the wakeup instruction transmitted in S430. If not, the process proceeds to S830.
  • the reception management unit 133 updates the "power_status" of the shadow 114 of the target vehicle to "power on” and ends the process. In response to this update, the determination at S420 is affirmative.
  • the reception management unit 133 determines whether or not an arrival notification has been received in response to the control instruction transmitted in the previous S670. is not received, the process ends.
  • the reception management unit 133 updates the control status of the history data stored in the control history storage unit 134 from "Accept” to "Complete” for the control instruction to be notified of arrival, and completes the process. In response to this update, the determination at S690 is affirmative.
  • the edge device 2 includes a wakeup control unit 201 and an instruction execution unit 202, as shown in FIG.
  • the wake-up control unit 201 manages the power state of the vehicle in which the edge device 2 is mounted.
  • the vehicle power supply state includes a low power consumption sleep state in which some functions are stopped and a wakeup state in which all functions are activated.
  • the wake-up control unit 201 receives a wake-up instruction addressed to the own vehicle from the management center 3 while the own vehicle is in the sleep state, the wake-up control unit 201 changes the power state of the edge device 2 to the wake-up state, and notifies the wake-up completion. to the management center 3.
  • the instruction execution unit 202 operates when the power supply state of the own vehicle is in the wakeup state.
  • the instruction execution unit 202 performs authentication by comparing the vehicle authentication information attached to the control instruction with the vehicle authentication information possessed by the own vehicle. or let the corresponding electronic control unit execute it.
  • the instruction execution unit 202 transmits a response to that effect to the management center 3 if authentication fails, and transmits a control result to the management center 3 if control is executed.
  • the reception unit 131 registers history data of control instructions in the control history storage unit 134, as indicated by an arrow L51. By registering the history data, the control status of the history data is set to "Accept”. Further, the reception unit 131 transmits a control instruction to the transmission management unit 132 as indicated by an arrow L52.
  • the transmission management unit 132 Upon receiving the control instruction, the transmission management unit 132 checks the "power_status" of the shadow 114 of the target vehicle, as indicated by an arrow L53. Since “power_status” is "power on”, transmission management unit 132 transmits a control instruction to the target vehicle as indicated by arrow L54. After that, the transmission management unit 132 periodically checks the control status of the history data, as indicated by an arrow L55.
  • the target vehicle that has received the control instruction returns an arrival notification to the management center 3 indicating that the control instruction has been received normally, as indicated by arrow L56.
  • the reception management unit 133 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 an arrow L57.
  • the transmission management unit 132 When the transmission management unit 132 periodically confirms the history data and confirms that the control status has changed to "Complete", the transmission management unit 132 issues a completion notification indicating that the control instruction has been completed normally, as indicated by an arrow L58. is sent to the requesting vehicle control API 148 .
  • the transmission management unit 132 transmits a control instruction to the target vehicle and starts periodic monitoring of the history data. are the same as those shown in FIG.
  • the transmission management unit 132 After transmitting the control instruction to the target vehicle, the transmission management unit 132 keeps the control status of the history data "Accept" even after the time limit indicated in the time limit information or the preset allowable time elapses. In this case, as indicated by an arrow L59, a time-out notification indicating abnormal termination is transmitted to the vehicle control API 148 of the request source.
  • the "power_status" of the shadow 114 of the target vehicle is "power off” reflecting the power state of the edge device 2 of the target vehicle.
  • the process from the registration of history data by the reception unit 131 to the confirmation of the "power_status" of the shadow 114 of the target vehicle by the transmission management unit 132 is shown in FIG. Same as content.
  • transmission management unit 132 Since the "power_status" of shadow 114 of the target vehicle confirmed by transmission management unit 132 is "power off", transmission management unit 132 transmits a wake-up instruction to the target vehicle as indicated by arrow L60. . Thereafter, the transmission management unit 132 periodically confirms the "power_status" of the target vehicle.
  • the target vehicle 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.
  • the reception management unit 133 Upon receiving the wakeup 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 an arrow L62.
  • the transmission management unit 132 periodically confirms that the "power_status" of the edge device 2 of the target vehicle has changed to "power on”. , to transmit a control instruction to the target vehicle.
  • the mobility IoT system 1 corresponds to a mobility service providing system
  • the management center 3 corresponds to a mobility service base server
  • the edge device 2 corresponds to an in-vehicle device.
  • the shadow manager 112 corresponds to the first database
  • the data manager 121 corresponds to the second database.
  • the API provider 122 corresponds to an interface.
  • the processing of S230 corresponds to the history registration unit
  • the processing of S310 to S340 corresponds to the order control unit
  • the processing of S510 to S570 corresponds to the priority processing unit.
  • the processing of S610 to S620 corresponds to the pre-transmission determination section.
  • the processes of S680 to S700 and S720 correspond to the delivery confirmation section
  • the processes of S710 and S730 correspond to the invalidation section
  • the processes of S630 and S830 to S840 correspond to the history update section.
  • the control status "Accept” corresponds to the accepted state
  • "Complete” corresponds to the completed state
  • the vehicle control request corresponds to the access request.
  • each control instruction implements one independent control, and each control instruction is given an order ID using a serial number. Further, on the vehicle side that receives the control instruction, the control is executed in the order according to the serial number indicated in the order ID. Therefore, even if the order of control instructions reaching the vehicle is changed due to the influence of the communication environment between the management center 3 and the vehicle (i.e., the edge device 2), the vehicle side does not recognize the request source of the vehicle control request as intended. Control can be executed according to the order to be executed. 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 with strict order, changing the order of control may result in completely different control or meaningless control. You can prevent the situation from occurring.
  • the mobility IoT system 1 After transmitting the control instruction to the vehicle, the mobility IoT system 1 repeatedly checks the control status. When the status changes to indicate that there is a response from the vehicle, a completion notification is returned to the requester of the vehicle control request. Returns a timeout notification to the origin. Therefore, according to the mobility IoT system 1, it is possible to inform the requester of the vehicle control request that the control instruction has reached the vehicle and that the control instruction has not reached the vehicle within the allowable time. As a result, the source of the vehicle control request can take appropriate measures according to whether or not the control instruction has arrived.
  • the mobility IoT system 1 Before sending the control instruction, the mobility IoT system 1 checks the "power_status" of the target vehicle by referring to the shadow 114 of the target vehicle, and if the power is off, sends a wake-up instruction. . That is, the control instruction is transmitted after the target vehicle is transitioned to a state in which the control instruction can be executed. Therefore, in the mobility IoT system 1, even when the engine of the target vehicle is off, the target vehicle can be activated and the control can be executed.
  • history data is stored in the control history storage unit 134 in units of control instructions, but may be stored in units of vehicle control requests (that is, units of requests from the vehicle control API 148).
  • the vehicle control unit 130 is configured to directly return the response from the edge device 2 to the control instruction to the requesting vehicle control API 148 in control instruction units.
  • the present disclosure is not limited to this, and when a plurality of control instructions are generated from one vehicle control request, the responses from the edge device 2 to the control instructions are grouped in units of vehicle control requests, and the request source vehicle control It may be configured to return to API 148 .
  • the edge device 2 in response to a control instruction from the management center 3, the edge device 2 sends a response to the management center 3 at the point when the execution of the control content is completed. , the response may be sent to the management center 3.
  • Control unit 31 and techniques described in this disclosure may be provided by configuring a processor and memory programmed to perform one or more functions embodied by a computer program. It may be implemented by a computer. Alternatively, the controller 31 and techniques described in this disclosure may be implemented by a dedicated computer provided by configuring the processor with one or more dedicated hardware logic circuits. Alternatively, the controller 31 and techniques described in this disclosure are a combination of a processor and memory programmed to perform one or more functions and a processor configured by one or more hardware logic circuits. may be implemented by one or more dedicated computers configured by Computer programs may also be stored as computer-executable instructions on a computer-readable non-transitional tangible storage medium. The method of realizing the function of each unit included in the control unit 31 does not necessarily include software, and all the functions may be realized using one or more pieces of hardware.
  • a plurality of functions possessed by one component in the above embodiment may be realized by a plurality of components, or a function possessed by one component may be realized by a plurality of components. . Also, a plurality of functions possessed by a plurality of components may be realized by a single component, or a function realized by a plurality of components may be realized by a single component. Also, part of the configuration of the above embodiment may be omitted. Also, at least part of the configuration of the above embodiment may be added or replaced with respect to the configuration of the other above embodiment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Accounting & Taxation (AREA)
  • Operations Research (AREA)
  • Traffic Control Systems (AREA)

Abstract

車両側ユニット（１１０）は、車両制御部（１３０）を有する。車両制御部は、サービス側ユニット（１２０）に設けられたインタフェース部（１２２）が車両に対するアクセス要求を受け付けた場合、アクセスの対象となる車両である対象車両に搭載された車載機（２）との無線通信を行うことで、対象車両へのアクセスを実行する。車両制御部は、車載機との間で送受信される制御指示に対して、中継制御を実行する。

Description

モビリティサービス基盤サーバ、モビリティサービス提供システム、車両アクセス制御方法、プログラム 関連出願の相互参照
　本国際出願は、２０２１年７月２日に日本国特許庁に出願された日本国特許出願第２０２１－１１０９０４号に基づく優先権を主張するものであり、日本国特許出願第２０２１－１１０９０４号の全内容を本国際出願に参照により援用する。
　本開示は、モビリティサービスを提供する技術に関する。
　特許文献１には、車両から車両データを収集することによって現実世界の車両の状態を仮想空間で再現するデジタルツインシミュレーションが記載されている。
特開２０１９－１５３２９１号公報
　モビリティサービスの広がりを受け、システム経由で車両にアクセスして、車両の有する機能を利用した様々なアプリケーションを実現することが検討されている。
　本開示は、モビリティサービスに関わる車両アクセスの信頼性を向上させる技術を提供する。
　本開示の一態様は、モビリティサービス基盤サーバである。モビリティサービス基盤サーバは、車両側ユニットと、サービス側ユニットと、を備える。
　車両側ユニットは、車両に搭載された車載機から提供される車両データに基づいて、車両毎に生成され、特定の時刻における車両の状態を表す複数のシャドウを記憶する第１データベースを有する。
　サービス側ユニットは、第２データベースおよびインタフェース部を有する。第２データベースは、第１データベースに蓄積されたシャドウのそれぞれに対応し、シャドウの検索に使用される情報を有するインデックスを記憶する。インタフェース部は、外部からのアクセス要求を受け付けるように構成される。
　車両側ユニットは、インタフェース部が車両に対するアクセス要求を受け付けた場合、アクセスの対象となる車両である対象車両に搭載された車載機との無線通信を行うことで、対象車両へのアクセスを実行するように構成された車両制御部を更に備える。車両制御部は、車載機との間で送受信される制御指示に対して、中継制御を実行するように構成される。
　このような構成によれば、車両アクセスの信頼性を向上させることができる。
　本開示の一態様は、モビリティサービス提供システムである。モビリティサービス提供システムは、車両に搭載される車載機と、上述のモビリティサービス基盤サーバと、を備える。
　本開示の一態様は、車両アクセス制御方法である。車両アクセス制御方法が適用されるモビリティサービス基盤サーバは、第１データベースと、第２データベースと、インタフェース部とを備える。
　車両アクセス制御方法では、インタフェース部が車両に対するアクセス要求を受け付けた場合、アクセスの対象となる車両である対象車両に搭載された車載機との無線通信を行うことで、対象車両へのアクセスを実行する。対象車両へのアクセスにおいて、車載機との間で送受信される制御指示に対して、中継制御を実行する。
　本開示の一態様は、プログラムである。プログラムを実行するコンピュータは、第１データベース、第２データベース、インタフェース部と共にモビリティサービス基盤サーバを構成する。
　プログラムは、コンピュータを、車両制御部として機能させる。車両制御部は、インタフェース部が車両に対するアクセス要求を受け付けた場合、アクセスの対象となる車両である対象車両に搭載された車載機との無線通信を行うことで、対象車両へのアクセスを実行するように構成される。また、車両制御部は、対象車両へのアクセスにおいて車載機との間で送受信される制御指示に対して、中継制御を実行するように構成される。
モビリティＩｏＴシステムの構成を示すブロック図である。 エッジ装置の構成を示すブロック図である。 エッジ装置の機能的な構成を示す機能ブロック図である。 フレームの構成を示す図である。 車両データ変換テーブルの構成を示す図である。 標準化車両データの第１階層と、データフォーマットとを示す図である。 標準化車両データの構成を示す図である。 標準化車両データの作成手順を示すシーケンス図である。 データ送信タイミングを示すタイミングチャートである。 管理センターの構成を示すブロック図である。 管理センターの機能的な構成を示す機能ブロック図である。 モビリティＧＷおよびデータ管理部の機能的な構成を示す機能ブロック図である。 シャドウの構成を示す図である。 最新インデックスの構成を示す図である。 インデックスの構成を示す図である。 認可情報記憶部が有する認可オブジェクトデータベースの構成を示す図である。 認可情報記憶部が有する認可クラスデータベースの構成を示す図である。 ＡＰＩ提供部の動作を示すシーケンス図である。 データ取得要求の指定情報およびシャドウアクセス要求の構成を示す図である。 エリア指定の指定方法の説明図である。 インデックス取得部が実行するシャドウリスト生成処理のフローチャートである。 データ取得ＡＰＩを利用したデータ取得の手順を示すシーケンス図である。 車両制御要求の指定情報の構成を示す図である。 車両制御要求を受け付けた場合の典型的な動作を示すシーケンス図である。 車両制御要求に関わる車両制御部およびエッジ装置を搭載する車両の構成を示す図である。 制御履歴記憶部への登録内容を示す図である。 受付部が実行する受付処理のフローチャートである。 受付処理において実行される順序処理のフローチャートである。 受付処理において実行されるウェイクアップ処理のフローチャートである。 受付処理において実行される優先処理のフローチャートである。 送信管理部が実行する送信側処理のフローチャートである。 受信管理部が実行する受信側処理のフローチャートである。 車両制御要求の対象となる車両の電源状態がオンであった場合の動作を示すシーケンス図である。 車両から制御指示に対する応答がない場合の動作を示すシーケンス図である。 車両制御要求の対象となる車両の電源状態がオフであった場合の動作を示すシーケンス図である。 車両に搭載されるＥＣＵの接続状態を示すブロック図である。
　以下に本開示の実施形態を図面とともに説明する。
　［１．システム概要］
　本実施形態のモビリティＩｏＴシステム１は、図１に示すように、複数のエッジ装置２と、管理センター３と、サービス提供サーバ４とを備える。ＩｏＴは、Internet of Thingsの略である。
　エッジ装置２は、車両に搭載され、広域無線通信網ＮＷを介して、管理センター３とデータ通信を行う機能を有する。
　管理センター３は、モビリティＩｏＴシステム１を管理する装置である。管理センター３は、広域無線通信網ＮＷを介して、複数のエッジ装置２およびサービス提供サーバ４との間でデータ通信を行う機能を有する。
　サービス提供サーバ４は、例えば、車両の運行を管理するサービスを提供するために設置されたサーバである。なお、モビリティＩｏＴシステム１は、サービス内容が互いに異なる複数のサービス提供サーバ４を備えてもよい。サービス提供サーバ４は、オンプレミスで構成されてもよいし、クラウドで構成されてもよい。また、サービス提供サーバ４は、管理センター３と物理的に同じサーバとして構成されてもよい。
　［２．エッジ装置］
　［２－１．装置構成］
　エッジ装置２は、図２に示すように、マイクロコンピュータ１１と、車両インタフェース（以下、車両Ｉ／Ｆ）１２と、通信部１３と、記憶部１４とを備える。
　マイクロコンピュータ１１は、第１コア２１と、第２コア２２と、ＲＯＭ２３と、ＲＡＭ２４と、フラッシュメモリ２５と、入出力部２６と、バス２７とを備える。
　マイクロコンピュータ１１の各種機能は、第１コア２１および第２コア２２が非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。この例では、ＲＯＭ２３が、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。
　なお、第１コア２１および第２コア２２が実行する機能の一部または全部を、一つあるいは複数のＩＣ等によりハードウェア的に構成してもよい。
　フラッシュメモリ２５は、データ書き換え可能な不揮発性メモリである。フラッシュメモリ２５は、後述する標準化車両データを格納する標準化車両データ格納部２５ａを備える。
　入出力部２６は、マイクロコンピュータ１１の外部と第１コア２１および第２コア２２との間でデータの入出力を行わせるための回路である。
　バス２７は、第１コア２１、第２コア２２、ＲＯＭ２３、ＲＡＭ２４、フラッシュメモリ２５および入出力部２６を、互いにデータ入出力可能に接続する。
　車両Ｉ／Ｆ１２は、車両に搭載された電子制御装置およびセンサ等との間で信号の入出力を行わせるための入出力回路である。
　車両Ｉ／Ｆ１２は、電源電圧入力ポート、汎用入出力ポート、ＣＡＮ通信ポートおよびイーサネット通信ポートなどを備える。ＣＡＮ通信ポートは、ＣＡＮ通信プロトコルに従ってデータの送受信を行うためのポートである。イーサネット通信ポートは、イーサネット通信プロトコルに基づいてデータの送受信を行うためのポートである。ＣＡＮは、Controller Area Networkの略である。ＣＡＮは登録商標である。イーサネットは登録商標である。
　ＣＡＮ通信ポートおよびイーサネット通信ポートには、車両に搭載された他の電子制御装置が接続される。エッジ装置２は、他の電子制御装置との間で通信フレームの送受信を行うことができる。
　通信部１３は、広域無線通信網ＮＷを介して、管理センター３とデータ通信を行う。
　記憶部１４は、各種データを記憶するための記憶装置である。
　図３６に示すように、車両には、一つのＥＣＵ２１０と、複数のＥＣＵ２２０と、複数のＥＣＵ２３０と、車外通信装置２４０と、車内通信網２５０とが搭載される。ＥＣＵは、Electronic Control Unitの略である。
　ＥＣＵ２１０は、複数のＥＣＵ２２０を統括することにより、車両全体として連携がとれた制御を実現する。
　ＥＣＵ２２０は、車両における機能によって区分けしたドメイン毎に設けられ、主として、そのドメイン内に存在する複数のＥＣＵ２３０の制御を実行する。各ＥＣＵ２２０は、それぞれ個別に設けられた下層ネットワーク（例えば、ＣＡＮ）を介して配下のＥＣＵ２３０と接続される。ＥＣＵ２２０は、配下のＥＣＵ２３０に対するアクセス権限などを一元的に管理し利用者の認証等を行う機能を有する。ドメインは、例えば、パワートレーン、ボデー、シャシおよびコックピット等である。
　パワートレーンのドメインに属するＥＣＵ２２０に接続されるＥＣＵ２３０は、例えば、エンジンを制御するＥＣＵ２３０、モータを制御するＥＣＵ２３０、および、バッテリを制御するＥＣＵ２３０等を含む。
　ボデーのドメインに属するＥＣＵ２２０に接続されるＥＣＵ２３０は、例えば、エアコンを制御するＥＣＵ２３０、および、ドアを制御するＥＣＵ２３０等を含む。
　シャシドメインに属するＥＣＵ２２０に接続されるＥＣＵ２３０は、例えば、ブレーキを制御するＥＣＵ２３０、および、ステアリングを制御するＥＣＵ２３０等を含む。
　コックピットのドメインに属するＥＣＵ２２０に接続されるＥＣＵ２３０は、例えば、メータおよびナビゲーションの表示を制御するＥＣＵ２３０、および、車両の乗員によって操作される入力装置を制御するＥＣＵ２３０等を含む。
　車外通信装置２４０は、広域無線通信網ＮＷを介して、車両外の通信装置（例えば、クラウドサーバ）との間でデータ通信を行う。
　車内通信網２５０は、ＣＡＮ　ＦＤとイーサネットとを備える。ＣＡＮ　ＦＤは、CAN with Flexible Data Rateの略である。ＣＡＮ　ＦＤは、ＥＣＵ２１０と各ＥＣＵ２２０および車外通信装置２４０とをバス接続する。イーサネットは、ＥＣＵ２１０と各ＥＣＵ２２０および車外通信装置２４０との間を個別に接続する。
　ＥＣＵ２１０は、ＣＰＵ２１０ａ、ＲＯＭ２１０ｂおよびＲＡＭ２１０ｃ等を備えたマイクロコンピュータを中心に構成された電子制御装置である。マイクロコンピュータの各種機能は、ＣＰＵ２１０ａが非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。この例では、ＲＯＭ２１０ｂが、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。なお、ＣＰＵ２１０ａが実行する機能の一部または全部を、一つあるいは複数のＩＣ等によりハードウェア的に構成してもよい。また、ＥＣＵ２１０を構成するマイクロコンピュータの数は１つでも複数でもよい。
　ＥＣＵ２２０、ＥＣＵ２３０および車外通信装置２４０は、いずれも、ＥＣＵ２１０と同様に、ＣＰＵ、ＲＯＭおよびＲＡＭ等を備えたマイクロコンピュータを中心に構成された電子制御装置である。また、ＥＣＵ２２０、ＥＣＵ２３０および車外通信装置２４０を構成するマイクロコンピュータの数は１つでも複数でもよい。ＥＣＵ２２０は、１以上のＥＣＵ２３０を統括するＥＣＵであり、ＥＣＵ２１０は、１以上のＥＣＵ２２０を統括する、または車外通信装置２４０を含む車両全体のＥＣＵ２２０，２３０を統括するＥＣＵである。
　エッジ装置２は、ＥＣＵ２１０との間でデータ通信可能となるようにＥＣＵ２１０に接続される。すなわち、エッジ装置２は、ＥＣＵ２１０を介して、ＥＣＵ２１０，２２０，２３０の情報を受信する。またエッジ装置２は、車両制御に関する要求を、ＥＣＵ２１０へ送信したり、ＥＣＵ２１０を介してＥＣＵ２２０，２３０へ送信したりする。
　［２－２．機能構成］
　エッジ装置２は、ＲＯＭ２３に格納されたプログラムを第１コア２１が実行することにより実現される機能ブロックとして、図３に示すように、第１ユニット１０１を備える。エッジ装置２は、ＲＯＭ２３に格納されたプログラムを第２コア２２が実行することにより実現される機能ブロックとして、第２ユニット１０２を備える。
　第１ユニット１０１は、リアルタイムオペレーティングシステム（以下、ＲＴＯＳ）１０３と、第１アプリケーション１０４とを備える。
　第１アプリケーション１０４は、車両を制御するための各種処理を実行する。第１アプリケーション１０４は、車両を制御するための各種処理を実行するために、フラッシュメモリ２５の標準化車両データ格納部２５ａにアクセスして標準化車両データを参照することが可能に構成されている。
　ＲＴＯＳ１０３は、第１アプリケーション１０４による処理のリアルタイム性を確保することができるように、第１アプリケーション１０４を管理する。
　第２ユニット１０２は、汎用オペレーティングシステム（以下、ＧＰＯＳ）１０５と、第２アプリケーション１０６とを備える。
　第２アプリケーション１０６は、サービス提供サーバ４により提供されるサービスに関連した処理を実行する。第２アプリケーション１０６は、サービスに関連した処理を実行するために、フラッシュメモリ２５の標準化車両データ格納部２５ａにアクセスして標準化車両データを参照することが可能に構成されている。
　ＧＰＯＳ１０５は、各種アプリケーションを動作させるためにエッジ装置２に搭載された基本ソフトウェアであり、第２アプリケーション１０６を管理する。
　［２－３．データ収集処理］
　エッジ装置２が車両データを収集して自発的に管理センター３に送信する一連の処理について説明する。
　まず、車両Ｉ／Ｆ１２が実行する処理を説明する。
　車両Ｉ／Ｆ１２は、通信フレームを受信すると、通信フレームを受信した通信ポートに基づいて、通信フレームの通信プロトコルを判定する。具体的には、車両Ｉ／Ｆ１２は、例えば、ＣＡＮ通信ポートで通信フレームを受信した場合には、受信した通信フレームの通信プロトコルはＣＡＮ通信プロトコルであると判定する。また車両Ｉ／Ｆ１２は、例えば、イーサネット通信ポートで通信フレームを受信した場合には、受信した通信フレームの通信プロトコルはイーサネット通信プロトコルであると判定する。
　そして車両Ｉ／Ｆ１２は、通信フレームの識別情報に基づいて、エッジ装置２での処理対象となる通信フレームであるか否かを判定し、処理対象となる通信フレームであると判定した場合に、受信した通信フレームを第１ユニット１０１へ出力する。
　ＣＡＮフレームは、図４に示すように、スタートオブフレーム、アービトレーションフィールド、コントロールフィールド、データフィールド、ＣＲＣフィールド、ＡＣＫフィールドおよびエンドオブフレームにより構成されている。なお、アービトレーションフィールドは、１１ビットまたは２９ビットのアイデンティファイア（すなわち、ＩＤ）と１ビットのＲＴＲビットで構成される。
　また、ＣＡＮ通信で使用する１１ビットのアイデンティファイアをＣＡＮＩＤという。ＣＡＮＩＤは、ＣＡＮフレームに含まれるデータの内容、ＣＡＮフレームの送信元、およびＣＡＮフレームの送信先等に基づいて予め設定されている。
　データフィールドは、それぞれ８ビット（すなわち１バイト）の第１データ、第２データ、第３データ、第４データ、第５データ、第６データ、第７データおよび第８データで構成される。以下、データフィールドの第１～８データのそれぞれをＣＡＮデータともいう。
　このため、車両Ｉ／Ｆ１２は、ＣＡＮフレームを受信した場合には、ＣＡＮＩＤに基づいて、処理対象であるか否かを判定する。
　次に、第１ユニット１０１が実行する処理を説明する。
　第１ユニット１０１は、車両Ｉ／Ｆ１２から出力された通信フレームを取得すると、通信フレームから、識別情報とデータとを抽出し、識別情報とデータとで構成される標準フォーマットデータを作成する。第１ユニット１０１は、作成した標準フォーマットデータをフラッシュメモリ２５に記憶する。例えば、第１ユニット１０１は、ＣＡＮフレームを取得した場合には、ＣＡＮＩＤと第１～８データとで構成される標準フォーマットデータを作成する。
　なお、第１ユニット１０１は、作成した標準フォーマットデータと同一の識別情報を含む標準フォーマットデータが既にフラッシュメモリ２５に記憶されている場合、その標準フォーマットデータに上書きすることによって、標準フォーマットデータを更新する。
　次に、第２ユニット１０２が実行する処理を説明する。
　第２コア２２は、標準フォーマットデータをフラッシュメモリ２５から取得する。
　そして第２コア２２は、取得した標準フォーマットデータに含まれるデータを分割する。例えば、ＣＡＮフレームから生成された標準フォーマットデータは、ＣＡＮＩＤと、第１～８データとで構成されているため、第２コア２２は、第１～８データを１バイト毎に分割し、８つのＣＡＮデータを抽出する。なお、第１ユニット１０１および第２ユニット１０２による標準フォーマットデータの書込みおよび読出しは、フラッシュメモリ２５でなくＲＡＭ２４を用いても良い。
　さらに第２コア２２は、ＲＯＭ２３に格納された車両データ変換テーブル２３ａを参照して、分割された各抽出データを、制御ラベルおよび車両データに変換する。
　車両データ変換テーブル２３ａは、正規化情報と、意味化情報とを備える。
　正規化情報は、車種および車両製造企業に関わらず同一の物理量が同一の値になるように抽出データを正規化するための情報である。
　意味化情報とは、正規化された車両データを用いて、意味のある車両データに変換するための情報である。以下では、正規化および意味化された車両データを加工データ、正規化および意味化される前の車両データをローデータともいう。ローデータは、例えばＣＡＮフレームのデータフィールドで示されるデータを指す。
　車両データ変換テーブル２３ａの正規化情報は、図５に示すように、設定項目として、例えば「ＣＡＮＩＤ」、「ＥＣＵ」、「ポジション」、「ＤＬＣ」、「ユニークラベル」、「解像度」、「オフセット」および「単位」を備える。
　「ＥＣＵ」は、ＣＡＮフレームの送信元のＥＣＵを示す情報である。例えば、「ＥＮＧ」は、エンジンＥＣＵであることを示す。
　「ポジション」は、データフィールド内におけるＣＡＮデータの位置を示す情報である。「ＤＬＣ」は、データ長を示す情報である。ＤＬＣは、Data Length Codeの略である。
　「ユニークラベル」は、制御ラベルを示す情報である。例えば、「ＥＴＨＡ」は吸気温を示し、「ＮＥ１」はエンジン回転数を示す。「解像度」は、１ビット当たりの数値を示す情報である。
　したがって、「ＣＡＮＩＤ」、「ＥＣＵ」、「ポジション」、「ＤＬＣ」および「ユニークラベル」によって、標準フォーマットデータから、「ユニークラベル」に対応するデータが抽出される。さらに抽出データは、「解像度」および「オフセット」により、「単位」で表される値に換算された、車両データに変換される。
　また、車両データ変換テーブル２３ａの意味化情報は、例えば、図５に示すように、制御ラベルが「ＳＳＡ」である「操舵移動角度」から、制御ラベルが「ＳＳＡＺ」である「操舵ゼロ点」を減算することにより「操舵角」に変換する変換式を含む。この変換式により、「操舵移動角度」を表す車両データと、「操舵ゼロ点」を表す車両データとから、「基準位置からの操舵量」という意味を有する「操舵角」を表す車両データに変換される。
　第２コア２２は、変換された車両データを階層化してフラッシュメモリ２５に記憶する。具体的には、第２コア２２は、変換された車両データを、フラッシュメモリ２５に設けられた標準化車両データ格納部２５ａの対応領域に格納する。
　標準化車両データ格納部２５ａは、車両データを階層化して構成される標準化車両データを格納する。
　標準化車両データは、車両毎（すなわち、エッジ装置２毎）に作成され、複数の階層構造を有している。標準化車両データでは、複数の階層のそれぞれに対して、１または複数の項目が設定されている。例えば、図６に示すように、標準化車両データは、最上位の第１階層に設定される項目として、「属性情報」、「パワトレ」、「エネルギー」、「ＡＤＡＳ／ＡＤ」、「ボデー」、「マルチメディア」および「その他」を備える。ＡＤＡＳは、Advanced Driver Assistance Systemの略である。ＡＤは、Autonomous Drivingの略である。「属性情報」、「パワトレ」および「エネルギー」等はカテゴリに相当する。
　また各車両データは、項目として、「ユニークラベル」、「ＥＣＵ」、「データ型」、「データサイズ」、「データ値」および「データ単位」を備える。「ユニークラベル」および「ＥＣＵ」は、前述の通りである。「データ型」、「データサイズ」および「データ単位」は、「データ値」で示される数値に関する型、サイズ、単位を示す。
　図７に示すように、標準化車両データは、第１階層に加えて、少なくとも第２階層および第３階層を備える。第２階層は第１階層の直下の階層であり、第３階層は第２階層の直下の階層である。標準化車両データは、前述した正規化および意味化の処理において設定された項目である。標準化車両データは、階層化されたデータ構造を有する。
　例えば、第１階層の項目である「属性情報」は、第２階層の項目として、「車両識別情報」、「車両属性」、「トランスミッション構成」および「ファームウェアバージョン」等を備える。「車両識別情報」は、車両を一意に識別できる情報を示すカテゴリ名である。「車両属性」は、車両の種類を示すカテゴリ名である。「トランスミッション構成」は、トランスミッションに関する情報を示すカテゴリ名である。「ファームウェアバージョン」は、車両のファームウェアに関する情報を示すカテゴリ名である。
　また、第１階層の項目である「パワトレ」は、パワートレーンに関する情報を示すカテゴリ名である。「パワトレ」は、第２階層の項目として、「アクセルペダル」、「エンジン」および「エンジンオイル」等を備える。「アクセルペダル」には、アクセルペダルの状態、開度など１以上の車両データが含まれる。「エンジン」には、エンジンの状態、回転数など１以上の個々の車両データが含まれる。第２階層の項目もカテゴリに相当する。他の第１階層の項目についても同様である。
　また、第１階層の項目である「エネルギー」は、エネルギーに関する情報を示すカテゴリ名である。「エネルギー」は、第２階層の項目として、「バッテリ状態」、「バッテリ構成」および「燃料」等を備える。
　また、第２階層の項目である「車両識別情報」は、第３階層の項目として、「車両識別番号」、「車体番号」および「ナンバープレート」を備える。第３階層の項目は、１以上の個々の車両データであり、アイテムとも言う。つまり、標準化車両データの階層構造において、最下層の項目をアイテム、最下層以外の項目（すなわち、下位階層を有する項目）をカテゴリという。
　また、第２階層の項目である「車両属性」は、第３階層の項目として、「ブランド名」、「モデル」および「製造年」等を備える。
　また、第２階層の項目である「トランスミッション構成」は、第３階層の項目として、「トランスミッション種別」を備える。
　例えば、第２コア２２は、変換された車両データの制御ラベルが「車両識別情報」である場合には、標準化車両データ格納部２５ａにおいて第１階層が「属性情報」であり且つ第２階層が「車両識別情報」であり且つ第３階層が「車両識別番号」である格納領域に、変換された車両データを格納する。
　「その他」には、例えば、車両に搭載されたＧＰＳ装置から車両Ｉ／Ｆ１２を介して取得される位置情報、すなわち、緯度、経度、高度が含まれてもよい。
　次に、図８に示すシーケンス図を用いて、エッジ装置２が標準化車両データを作成する手順を説明する。
　矢印Ｌ１１で示すように、車両Ｉ／Ｆ１２が車両から車両データを取得すると、車両Ｉ／Ｆ１２は、矢印Ｌ１２で示すように、通信プロトコル判定を行う。さらに車両Ｉ／Ｆ１２は、矢印Ｌ１３で示すように不要な車両データをフィルタリングし、矢印Ｌ１４で示すように、必要な車両データを第１ユニット１０１へ出力する。
　第１ユニット１０１は、車両Ｉ／Ｆ１２から車両データを取得すると、矢印Ｌ１５で示すように、車両データを標準フォーマットに変換し、矢印Ｌ１６で示すように、標準フォーマットに変換された車両データをフラッシュメモリ２５に記憶する。
　第２ユニット１０２は、矢印Ｌ１７で示すように、標準フォーマットに変換された車両データをフラッシュメモリ２５から取得すると、矢印Ｌ１８で示すように、取得した車両データを変換する。さらに第２ユニット１０２は、矢印Ｌ１９で示すように、変換したデータを構造化して標準化車両データを作成する。
　次に、エッジ装置２が実行するデータ送信処理の手順を説明する。
　標準化車両データに属する各車両データには、管理センター３にデータを送信するタイミングを表すタイミング情報が、それぞれ設定される。タイミング情報は、データが変化する度合いやデータの重要度等に応じて、頻繁に変化するデータほど、重要度が高いデータほど周期が短くなるように設定される。タイミング情報は、例えば、５００ｍｓ周期、２ｓ周期、４ｓ周期、３０ｓ周期、３００ｓ周期、１２時間周期等である。
　第２コア２２は、送信単位時間（例えば２５０ｍｓ）周期で送信処理を実行する。
　図９に示すように、５００ｍｓ周期で送信する車両データである第１頻度データを、２グループに分けて、送信タイミング毎に交互に送信する。同様に、１ｓ周期で送信する車両データである第２頻度データを、２グループまたは４グループに分けて各グループのデータを異なる送信タイミング送信する。つまり、各車両データを、あらかじめ設定された送信スケジュールに従って送信することにより、同じ送信タイミングに多くの車両データの送信が集中することを抑制する。また、各車両データを、その特性に応じた頻度で送信することにより、効率の良い送信を実現する。
　［３．管理センター］
　［３―１．装置構成］
　管理センター３は、図１０に示すように、制御部３１と、通信部３２と、記憶部３３とを備える。
　制御部３１は、ＣＰＵ４１、ＲＯＭ４２およびＲＡＭ４３等を備えたマイクロコンピュータを中心に構成された電子制御装置である。マイクロコンピュータの各種機能は、ＣＰＵ４１が非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。この例では、ＲＯＭ４２が、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。なお、ＣＰＵ４１が実行する機能の一部または全部を、一つあるいは複数のＩＣ等によりハードウェア的に構成してもよい。また、制御部３１を構成するマイクロコンピュータの数は１つでも複数でもよい。
　通信部３２は、広域無線通信網ＮＷを介して、複数のエッジ装置２およびサービス提供サーバ４との間でデータ通信を行う。なお、エッジ装置２との通信には、パブリッシュ／サブスクライブ型のシンプルで軽量なプロトコルであるＭＱＴＴが用いられる。ＭＱＴＴは、Message Queue Telemetry Transportの略である。
　記憶部３３は、各種データを記憶するための記憶装置である。
　［３－２．機能構成］
　管理センター３は、ＲＯＭ４２に格納されたプログラムをＣＰＵ４１が実行することにより実現される機能ブロックとして、図１１に示すように、車両側ユニット１１０と、サービス側ユニット１２０とを備える。車両へのアクセスに近い側の機能ブロックが車両側ユニット１１０であり、サービス提供サーバ４からのアクセスに近い側の機能ブロックがサービス側ユニット１２０である。これら２つの機能ブロックは、疎結合に構成される。
　管理センター３を構成するこれらの要素を実現する手法はソフトウェアに限るものではなく、その一部または全部の要素について、一つあるいは複数のハードウェアを用いて実現してもよい。例えば、上記機能がハードウェアである電子回路によって実現される場合、その電子回路は多数の論理回路を含むデジタル回路、またはアナログ回路、あるいはこれらの組合せによって実現してもよい。
　車両側ユニット１１０は、車両へのアクセスおよび車両から受信したデータを管理する機能を有する。車両側ユニット１１０は、モビリティゲートウェイ（以下、モビリティＧＷ）１１１を備える。モビリティＧＷ１１１は、車両へのアクセス要求を車両へ中継する機能の他、車両から受信したデータを管理する機能を有する。
　モビリティＧＷ１１１は、シャドウ管理部１１２と、車両制御部１３０とを備える。シャドウ管理部１１２は、エッジ装置２を搭載する車両毎に設けられた車両データを収容するシャドウ１１４を管理する機能を備える。シャドウ１１４は、ある車両の車両データ群を示す。シャドウ１１４は、エッジ装置２から送信される標準化車両データに基づいて生成される。車両制御部１３０は、サービス提供サーバ４からの指示に従って、エッジ装置２を介して、該エッジ装置２を搭載している車両を制御する機能を備える。
　サービス側ユニット１２０は、サービス提供サーバ４からの要求を受け付けるとともに、車両データの提供を行う。サービス側ユニット１２０は、データ管理部１２１と、ＡＰＩ提供部１２２とを備える。ＡＰＩは、Application Programming Interfaceの略である。
　データ管理部１２１は、車両の接続状態の変化に依存しない車両アクセスを提供するための仮想空間であるデジタルツイン１２３を管理する機能を備える。データ管理部１２１は、車両側ユニット１１０で管理する車両データへのアクセスに必要なデータを管理する。
　ＡＰＩ提供部１２２は、サービス提供サーバ４がモビリティＧＷ１１１およびデータ管理部１２１へアクセスするための標準インタフェースである。ＡＰＩ提供部１２２は、サービス提供サーバ４に対し、車両へのアクセスや車両データを取得するためのＡＰＩを提供する。
　［３－２－１．データ蓄積機能］
　図１２に示すように、シャドウ管理部１１２は、エッジ装置２から取得した車両データを蓄積する機能を実現する構成として、シャドウ作成部１１５と、シャドウ記憶部１１３と、最新インデックス作成部１１６と、最新インデックス記憶部１１７とを備える。
　シャドウ作成部１１５は、エッジ装置２から構造化された標準化車両データを受信する。　シャドウ作成部１１５は、エッジ装置２から車両データが送信される毎に、送信された車両データを、構造化された標準化車両データの該当領域に上書きすることにより、標準化車両データを更新する。シャドウ作成部１１５は、構造化された標準化車両データの一部を受信してもよい。シャドウ作成部１１５は、更新された標準化車両データを用いて、新たなシャドウ１１４を作成する。シャドウ作成部１１５は、作成したシャドウ１１４をシャドウ記憶部１１３に蓄積する。シャドウ作成部１１５は、更新された標準化車両データを用いて新たなシャドウ１１４を作成する際、通し番号など任意の情報を付与してシャドウ記憶部１１３に記憶してもよい。シャドウ記憶部１１３には、車両毎に、時系列的に作成された複数のシャドウ１１４が記憶される。つまり、シャドウ１１４は、エッジ装置２を搭載した車両のある時刻における状態をコピーしたものとみなすことができる。
　一つのシャドウ１１４は、ある車両の所定時刻の車両データ群であり、図１３に示す標準化されたデータ構造で表される車両データ群を含む。なお、シャドウ作成部１１５が、通信部３２を介して、構造化された標準化車両データを受信するタイミングは、車両によって異なる。新たなシャドウ１１４の作成は、全ての車両に対して同じタイミングで行ってもよい。シャドウ作成部１１５は、新たなシャドウ１１４の作成を、全ての車両に対して一定周期で行ってもよい。シャドウ記憶部１１３には、車両毎に、過去のシャドウ１１４が蓄積されている。一定期間経過したシャドウ１１４は順次削除されてもよい。
　図１３に示すように、シャドウ１１４は、車両データ格納部１１４ａと、デバイスデータ格納部１１４ｂとを備える。
　車両データ格納部１１４ａは、エッジ装置２を搭載している車両に関するデータとして、「ｏｂｊｅｃｔ－ｉｄ」、「Ｓｈａｄｏｗ＿ｖｅｒｓｉｏｎ」および「ｍｏｂｉｌｉｔｙ－ｄａｔａ」を格納する。
　「ｏｂｊｅｃｔ－ｉｄ」は、エッジ装置２を搭載している車両を識別する文字列であり、パーティションキーとして機能する。
　「Ｓｈａｄｏｗ＿ｖｅｒｓｉｏｎ」は、シャドウ１１４のバージョンを示す数値であり、シャドウ１１４が作成される毎に、作成された時刻を示すタイムスタンプが設定される。
　「ｍｏｂｉｌｉｔｙ－ｄａｔａ」は、上記の標準化車両データである。
　デバイスデータ格納部１１４ｂは、エッジ装置２に搭載されているハードウェア、ソフトウェア、および状態に関するデータとして、「ｏｂｊｅｃｔ－ｉｄ」、「ｕｐｄａｔｅ＿ｔｉｍｅ」、「ｖｅｒｓｉｏｎ」、「ｐｏｗｅｒ＿ｓｔａｔｕｓ」、「ｐｏｗｅｒ＿ｓｔａｔｕｓ＿ｔｉｍｅｓｔａｍｐ」、「ｎｏｔｉｆｙ＿ｒｅａｓｏｎ」を格納する。
　「ｏｂｊｅｃｔ－ｉｄ」は、車両データ格納部１１４ａにて説明したものと同じである。
　「ｕｐｄａｔｅ＿ｔｉｍｅ」は、更新時刻を示す数値である。
　「ｖｅｒｓｉｏｎ」は、エッジ装置２のハードウェアおよびソフトウェアのバージョンを示す文字列である。
　「ｐｏｗｅｒ＿ｓｔａｔｕｓ」は、エッジ装置２のシステム状態を示す文字列である。具体的には、全ての機能を利用可能な「電源オン」状態、一部の機能を停止した低消費電力の「電源オフ」状態がある。
　「ｐｏｗｅｒ＿ｓｔａｔｕｓ＿ｔｉｍｅｓｔａｍｐ」は、システム状態の通知時刻を示す数値である。
　「ｎｏｔｉｆｙ＿ｒｅａｓｏｎ」は、通知理由を示す文字列である。
　このようにシャドウ１１４は、車両データ群に加え、エッジ装置２の情報を含む。なお、デバイスデータ格納部１１４ｂは、エッジ装置２の情報をシャドウ１１４に含めず別でＲＯＭ４２等に記憶してもよい。デバイスデータ格納部１１４ｂは、エッジ装置２の情報を、タイムスタンプ毎に過去のデータを蓄積するのではなく、最新のデータのみをＲＯＭ４２等に記憶してもよい。
　上記デバイスデータ格納部１１４ｂに格納される「ｖｅｒｓｉｏｎ」「ｐｏｗｅｒ＿ｓｔａｔｕｓ」「ｎｏｔｉｆｙ＿ｒｅａｓｏｎ」等は、上記の標準化車両データとは別で、変化が生じたときにエッジ装置２から通知される。
　最新インデックス作成部１１６は、シャドウ記憶部１１３から車両毎に最新のシャドウ１１４を取得し、取得したシャドウ１１４を用いて最新インデックス１１８を作成する。そして最新インデックス作成部１１６は、作成した最新インデックス１１８を最新インデックス記憶部１１７に記憶する。最新インデックス記憶部１１７には、車両毎（すなわち、ｏｂｊｅｃｔ－ｉｄ毎）に１つの最新インデックス１１８が記憶される。
　図１４に示すように、最新インデックス１１８は、「ｇａｔｅｗａｙ－ｉｄ」、「ｏｂｊｅｃｔ－ｉｄ」、「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」、「ｖｉｎ」、「ｌｏｃａｔｉｏｎ－ｌｏｎ」、「ｌｏｃａｔｉｏｎ－ｌａｔ」および「ｌｏｃａｔｉｏｎ－ａｌｔ」を格納する。
　「ｏｂｊｅｃｔ－ｉｄ」、「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」は、シャドウ１１４にて説明したものと同様である。
　「ｇａｔｅｗａｙ－ｉｄ」は、モビリティＧＷ１１１を識別する情報である。管理センター３が、例えば、国別に設けられる等して複数存在する場合に、これらを識別する情報である。
　「ｖｉｎ」は、エッジ装置２を搭載している車両固有の登録番号である。
　「ｌｏｃａｔｉｏｎ－ｌｏｎ」は、エッジ装置２を搭載している車両が存在する緯度を示す情報である。
　「ｌｏｃａｔｉｏｎ－ｌａｔ」は、エッジ装置２を搭載している車両が存在する経度を示す情報である。
　「ｌｏｃａｔｉｏｎ－ａｌｔ」は、エッジ装置２を搭載している車両が存在する高度を示す情報である。
　図１２に示すように、データ管理部１２１は、シャドウ管理部１１２から取得された最新インデックス１１８をインデックス１２６として蓄積する機能を実現する構成として、インデックス作成部１２４と、インデックス記憶部１２５とを備える。
　インデックス作成部１２４は、最新インデックス記憶部１１７から予め設定された取得スケジュールに従って最新インデックス１１８を取得し、取得した最新インデックス１１８を用いてデジタルツイン１２３用のインデックス１２６を作成する。そしてインデックス作成部１２４は、作成したインデックス１２６をインデックス記憶部１２５に順次記憶する。インデックス記憶部１２５には、車両毎に、時系列的に作成された複数のインデックス１２６が記憶される。つまり、インデックス記憶部１２５に記憶されたインデックス１２６のそれぞれが、仮想的な時空間であるデジタルツイン１２３上に存在する車両を表す。
　図１５に示すように、インデックス１２６は、「ｔｉｍｅｓｔａｍｐ」、「ｓｃｈｅｄｕｌｅ－ｔｙｐｅ」、「ｇａｔｅｗａｙ－ｉｄ」、「ｏｂｊｅｃｔ－ｉｄ」、「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」、「ｖｉｎ」、「ｌｏｃａｔｉｏｎ」および「ａｌｔ」を格納する。
　「ｔｉｍｅｓｔａｍｐ」は、インデックス１２６が作成された時刻をミリ秒単位で示すタイムスタンプである。
　「ｓｃｈｅｄｕｌｅ－ｔｙｐｅ」は、データ作成元のスケジューラが定期であるかイベントであるかを示す。定期である場合には「ｓｃｈｅｄｕｌｅ－ｔｙｐｅ」は「Ｒｅｐｅａｔ」に設定され、イベントである場合には「ｓｃｈｅｄｕｌｅ－ｔｙｐｅ」は「Ｅｖｅｎｔ」に設定される。
　「ｇａｔｅｗａｙ－ｉｄ」、「ｏｂｊｅｃｔ－ｉｄ」「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」、「ｖｉｎ」は、最新インデックス１１８から引き継いだ情報である。
　「ｌｏｃａｔｉｏｎ」は、最新インデックス１１８の「ｌｏｃａｔｉｏｎ－ｌｏｎ」、「ｌｏｃａｔｉｏｎ－ｌａｔ」から引き継いだ情報であり、「ａｌｔ」は、最新インデックス１１８の「ｌｏｃａｔｉｏｎ－ａｌｔ」から引き継いだ情報である。
　ここで、シャドウ管理部１１２は、最新インデックス作成部１１６および最新インデックス記憶部１１７を省略した構成としてもよい。この場合、インデックス作成部１２４は、シャドウ記憶部１１３に記憶されているシャドウ１１４を取得してインデックス１２６を生成してもよい。望ましくは、インデックス作成部１２４は、最新インデックス記憶部１１７から取得した最新インデックス１１８を用いてインデックス１２６を生成する。これは、モビリティＧＷ１１１とデータ管理部１２１とを疎結合とする構成の一つである。
　さらに、データ管理部１２１は、インデックス作成部１２４およびインデックス記憶部１２５を省略した構成としてもよい。この場合、例えば、インデックス取得部１２７は、ＡＰＩ提供部１２２を介して指定されたｏｂｊｅｃｔ－ｉｄとタイムスタンプ（すなわち、ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ）を用いて、データ取得部１１９に指定された車両データの取得を要求してもよい。
　［３－２－２．サービス提供機能］
　図５および図１２に示すように、サービス側ユニット１２０は、ＡＰＩ提供部１２２を備える。ＡＰＩ提供部１２２は、管理センター３が有する機能を、サービス提供サーバ４等の外部のサービス提供者に利用させるために用意されたインタフェースである。以下では、ＡＰＩ提供部１２２等を利用するモビリティＩｏＴシステム１のユーザをサービスユーザという。サービスユーザは、例えば車両トランクへの宅配を行うサービス事業者である。
　ＡＰＩ提供部１２２は、図１２に示すように、認証情報記憶部１４１と、認可情報記憶部１４２と、車両識別情報記憶部１４３と、認証処理部１４４とを備える。また、サービスユーザに提供するＡＰＩの種類として、ログインＡＰＩ１４５と、データ取得ＡＰＩ１４６と、車両制御ＡＰＩ１４８とを備える。
　ログインＡＰＩ１４５は、サービスユーザの認証を行うために提供されるＡＰＩである。データ取得ＡＰＩ１４６は、サービスユーザがデータを取得するために提供されるＡＰＩである。車両制御ＡＰＩ１４８は、サービスユーザが車両に対する制御を行うために提供されるＡＰＩである。
　認証情報記憶部１４１は、「サービスユーザＩＤ」に対応づけて「認証情報」を記憶する。「サービスユーザＩＤ」は、サービスユーザを一意に識別する識別情報である。「認証情報」は、サービスユーザ本人であることを認証するための情報であり、例えば、あらかじめ設定されたパスワードである。
　認可情報記憶部１４２は、認可オブジェクトデータベース（以下、認可オブジェクトＤＢ）と、認可クラスＤＢとを備える。
　図１６に示すように、認可オブジェクトＤＢは、「サービスユーザＩＤ」に対応づけて、「認可クラス」「認可オブジェクト」「有効期限」を記憶する。「認可クラス」は、サービスユーザに対して認可された権限の範囲を表す情報である。「認可オブジェクト」は、サービスユーザによるアクセスが許可された車両の「ｏｂｊｅｃｔ－ｉｄ」のリストである。「有効期限」は、登録内容が有効な期間の開始年月日および終了年月日である。つまり、認可オブジェクトＤＢは、モビリティＩｏＴシステム１に対する各サービスユーザの権限についての登録内容を示すデータベースである。認可オブジェクトＤＢには、「認可オブジェクト」が異なっているか、または、「有効期限」が重複していなければ、１のサービスユーザについて複数の登録がされてもよい。
　図１７に示すように、認可クラスＤＢは、「認可クラス」に対応づけて「ＡＰＩ情報」「取得権限」「有効期限」を記憶する。認可クラスＤＢは、「認可クラス」の具体的な内容を表すデータベースである。
　「認可クラス」は、認可を与えるデータ範囲を表す複数のクラスを識別する情報であり、例えば、認可クラスの低い順に「ｏｐｅｎ」「Ｃｌａｓｓ０」「ｃｌａｓ１」「ｃｌａｓｓ２」「ｃｌａｓｓ３」「Ｆｕｌｌ」の６クラスが存在してもよい。「認可クラス」は、データに対し読み出しや書き込みができるデータ範囲のクラス分けに限定されず、動作を制御できる動作制御範囲のクラス分け等であってもよい。
　「ＡＰＩ情報」は、対応する「認可クラス」のサービスユーザに提供するＡＰＩのｕｒｌである。ｕｒｌは、Uniform Resource Locatorの略である。
　「取得権限」は、対応する「認可クラス」のサービスユーザに対して許可された取得可能なデータのリストである。認可クラスが「ｏｐｅｎ」である場合、「取得権限」に含まれるデータは、誰もが自由にアクセスできる情報に限られ、例えば、車両の位置情報、高度情報が含まれてもよい。認可クラスが「Ｆｕｌｌ」である場合、「取得権限」に含まれるデータは、管理センター３が管理する全ての情報、およびエッジ装置２を搭載する車両から取得可能な全ての情報が含まれる。認可クラスが「Ｃｌａｓｓ０」～「Ｃｌａｓｓ３」の場合、クラスが０～３に上がるに従って、アクセス可能なデータの数が増加するように設定されてもよいし、クラス毎に、アクセス可能なデータの種類が異なるように設定されてもよい。
　ここでは取得権限として、取得可能なデータが列挙されているが、取得可能なデータの代わりに、または、取得可能なデータに加えて、利用可能な機能、例えば、エッジ装置２を搭載した車両に対する制御の種類等が列挙されてもよい。取得可能なデータとしては、例えば図７に示すデータ項目の中から列挙される。
　「有効期限」が重複していなければ、１の「認可クラス」に複数の設定が存在してもよい。
　車両識別情報記憶部１４３は、エッジ装置２が搭載された車両に一意に割り当てられた「ｏｂｊｅｃｔ－ｉｄ」と、その車両の「ｖｉｎ」とを対応づけたテーブル情報を記憶する。
　認証処理部１４４は、ログインＡＰＩ１４５を介して認証要求が行われた場合に、認証処理を実行し、データ取得ＡＰＩ１４６および車両制御ＡＰＩ１４８を介してアクセス要求が行われた場合に、認可処理を実行する。認証処理および認可処理いついては後述する。
　ＡＰＩ提供部１２２を介したアクセス要求に関わる手順を、図１８を用いて説明する。
　ログインＡＰＩ１４５は、サービスユーザがモビリティＩｏＴシステム１にログインする際に用いられる。
　矢印Ｌ２１で示すように、ログインＡＰＩ１４５がサービスユーザからの認証要求を受け付けると、認証処理部１４４が認証処理を実行する。認証処理では、ログインＡＰＩ１４５により入力された「サービスユーザＩＤ」「認証情報」を、認証情報記憶部１４１の登録内容と照合する。照合の結果、情報が一致した場合、すなわち、認証に成功した場合は、矢印Ｌ２２で示すように、認証結果として、モビリティＩｏＴシステム１へのアクセスを許可する証明書となるデータであるトークンを返す。
　データ取得ＡＰＩ１４６は、図１１中のＬ１に示すように、管理センター３に蓄積された車両データ（すなわち、インデックス１２６およびシャドウ１１４）へのアクセスに用いるＡＰＩである。車両制御ＡＰＩ１４８は、図１１中のＬ２に示すように、エッジ装置２が搭載された車両へのアクセスに用いるＡＰＩである。
　以下では、データ取得ＡＰＩ１４６、および車両制御ＡＰＩ１４８を、総称してアクセスＡＰＩという。図１８中の矢印Ｌ２３で示すように、アクセスＡＰＩは、サービスユーザからのアクセス要求を受け付けると、認証処理部１４４が認可処理を実行する。
　認可処理が実行されると、認証処理部１４４は、アクセス要求に付加された「トークン」から「サービスユーザＩＤ」を特定する。次に、認証処理部１４４は、認可情報記憶部１４２の認可オブジェクトＤＢを検索することで、特定された「サービスユーザＩＤ」の「認可クラス」「認可オブヘクト」を特定する。更に、認証処理部１４４は、アクセス要求に示されたアクセス対象の車両が、「認可オブジェクト」に示されているか否か、すなわち、サービスユーザが指定した車両へのアクセスが許可されているか否かを判定する。また、認証処理部１４４は、認可クラスＤＢを参照して、アクセス要求に用いられたアクセスＡＰＩが、指定された「認可クラス」の「ＡＰＩ情報」に含まれるか否か、すなわち、サービスユーザが指定したＡＰＩの利用が許可されているか否かを判定する。また、認証処理部１４４は、認可クラスＤＢを参照して、アクセス要求に示された指示内容が、特定された「認可クラス」の「取得権限」の範囲内であるか否か、すなわち、サービスユーザが要求する指示内容に対しアクセスが許可されているか否かを判定する。そして、アクセス対象の車両が「認可オブジェクト」に示されていない場合、アクセスＡＰＩが「ＡＰＩ情報」に含まれない場合、または指示内容が「取得権限」の範囲外である場合、認証処理部１４４は不認可と判定する。不認可と判定した場合、認証処理部１４４は、矢印Ｌ２４で示すように、アクセスＡＰＩを介して、サービスユーザにアクセス拒否を通知する。アクセス対象の車両が「認可オブジェクト」に示され、かつ、アクセスＡＰＩが「ＡＰＩ情報」に含まれ、かつ、指示内容が「取得権限」の範囲内にある場合、認証処理部１４４は、認可と判定する。認可と判定した場合、認証処理部１４４は、矢印Ｌ２５で示すように、アクセス要求を、アクセス対象であるシャドウ１１４または実車両へ転送する。その後、矢印Ｌ２６で示すように、アクセス対象から返送されるアクセス結果は、アクセスＡＰＩを介して、サービスユーザに提供される。
　なお、アクセスＡＰＩでは、車両を特定する情報として、「ｏｂｊｅｃｔ－ｉｄ」および「ｖｉｎ」のいずれを用いてもよく、「ｖｉｎ」が用いられている場合は、車両識別情報記憶部１４３を参照し、「ｖｉｎ」を「ｏｂｊｅｃｔ－ｉｄ」に変換してもよい。
　図１２に示すように、管理センター３は、アクセスＡＰＩを介したアクセス要求を実現するための構成として、インデックス取得部１２７と、データ取得部１１９と、車両制御部１３０とを備える。インデックス取得部１２７は、インデックス記憶部１２５に蓄積されたインデックス１２６からデータを取得する機能を実現する。データ取得部１１９は、シャドウ記憶部１１３に蓄積されたシャドウ１１４からデータを取得する機能を実現する。車両制御部１３０は、エッジ装置２との通信機能を利用して、エッジ装置２を搭載する車両にアクセスする機能を実現する。
　つまり、データ取得ＡＰＩ１４６を介して入力されるアクセス要求（以下、データ取得要求）は、インデックス取得部１２７にて処理される。また、車両制御ＡＰＩ１４８を介して入力されるアクセス要求（以下、車両制御要求）は、車両制御部１３０にて処理される。
　［３－３．データ取得処理］
　データ取得ＡＰＩ１４６がデータ取得要求を受け付けた場合に実行される一連の処理であるデータ取得処理について説明する。具体的には、図１８において認証処理および認可処理が行われた後、アクセスＡＰＩからアクセス対象へアクセス要求が送信されたときのデータ取得処理である。データ取得処理は、データ取得ＡＰＩ１４６を用いて、管理センター３内で管理されるシャドウ１１４から指定したデータを取得する処理である。
　まず、データ取得要求に含まれる指定情報について説明する。指定情報は、サービスユーザによって設定される。
　図１９に示すように、指定情報は、車両指定情報と、時間指定情報と、データ指定情報とを含む。
　車両指定情報は、データ取得の対象となる車両（以下、対象車両）を指定するための情報である。車両指定情報は、対象車両の車両ＩＤ（すなわち、ｏｂｊｅｃｔ－ｉｄまたはｖｉｎ）をリスト形式で列挙する方法と、対象車両が存在する地理的領域を指定（以下、エリア指定）する方法とがある。他にも、車種や型式等により、対象車両を指定してもよい。
　エリア指定する方法は、図２０に示すように、矩形指定、および多角形指定、近傍指定の３種類が存在する。矩形指定は、矩形の地理的領域を、左上隅座標、右下隅座標によって指定する方法である。座標は、緯度、経度を用いて表される。多角形指定は、多角形の地理的領域を、多角形が有するｎ個の頂点の各座標によって指定する方法である。近傍指定は、円形の地理的領域を、中心座標と中心座標からの距離によって指定する方法である。
　図１９に戻り、時間指定情報は、データが生成されたタイミングを指定する情報である。時間指定情報は、起点となる時刻、およびレンジによって表される。レンジは、例えば、最新インデックス１１８の生成周期を単位時間として、時間幅を１以上の整数で表した値である。
　データ指定情報は、取得するデータを指定する情報である。データ指定情報は、標準化車両データに示されたデータのアイテム名をリスト形式で表してもよいし、標準化車両データに示されたカテゴリ名を指定することで表してもよい。カテゴリ名を指定した場合、そのカテゴリに属するすべてのアイテムが指定されたことになる。また、アイテム名およびカテゴリ名がいずれも指定されていない場合は、全アイテムが指定されたことになる。また、アイテム名によって指定可能なデータには、標準化車両データには含まれないローデータが含まれてもよい。例えば、データ指定情報には、ローデータに対応づけられたＣＡＮフレームのＣＡＮＩＤが含まれてもよい。
　なお、ここで示した車両指定情報、時間指定情報、データ指定情報の設定の仕方は一例であり、上記方法に限定されるものではない。
　次に、データ取得ＡＰＩ１４６がデータ取得要求を受け付けた場合に、インデックス取得部１２７が実行するシャドウリスト生成処理を、図２１のフローチャートを用いて説明する。
　Ｓ１１０では、インデックス取得部１２７は、データ取得要求に示された車両指定情報を参照し、指定情報が車両ＩＤリストであれば、処理をＳ１２０に移行し、指定情報がエリア指定であれば、処理をＳ１３０に移行する。
　Ｓ１２０では、インデックス取得部１２７は、インデックス記憶部１２５を参照して、車両ＩＤリストに示された「ｏｂｊｅｃｔ－ｉｄ」を有し、かつ、時間指定情報に示された時間範囲内の「ｔｉｍｅｓｔａｍｐ」を有する全てのインデックス１２６を抽出して、処理をＳ１５０に進める。
　Ｓ１３０では、インデックス取得部１２７は、指定情報に示されたエリア指定に従って、対象車両を探索する探索エリアを設定する。
　続くＳ１４０では、インデックス取得部１２７は、インデックス記憶部１２５を参照して、Ｓ１３０で設定された探索エリア内の「ｌｏｃａｔｉｏｎ」を有し、且つ、時間指定情報に示された時間範囲内の「ｔｉｍｅｓｔａｍｐ」を有する全てのインデックス１２６を抽出して、処理をＳ１５０に進める。
　Ｓ１５０では、インデックス取得部１２７は、Ｓ１２０またはＳ１４０で抽出されたインデックス１２６のそれぞれについて、インデックス１２６に示された「ｏｂｊｅｃｔ－ｉｄ」と「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」とを組み合わせたシャドウ特定情報を生成する。生成されたシャドウ特定情報は、シャドウ特定情報を列挙したシャドウ特定情報リスト（以下、シャドウリスト）の構成要素となる。
　続くＳ１６０では、インデックス取得部１２７は、Ｓ１５０にて生成されたシャドウリストに、データ取得要求に示されたデータ指定情報を付加したシャドウアクセス要求を、シャドウ管理部１１２のデータ取得部１１９に出力して、処理を終了する。
　図２２に示すように、インデックス取得部１２７は、矢印Ｌ３１で示すように、データ取得ＡＰＩ１４６からデータ取得要求を受け取ると、シャドウリストを生成する。シャドウリストは、データ取得要求に示された車両指定情報および時間指定情報を取得条件とし、この取得条件に従って生成される。また、インデックス取得部１２７は、矢印Ｌ３２で示すように、生成したシャドウリストとデータ指定情報とを組み合わせたシャドウアクセス要求をデータ取得部１１９に出力する。
　データ取得部１１９は、インデックス取得部１２７からのシャドウアクセス要求が入力されると、シャドウ記憶部１１３を参照して、シャドウアクセス要求のシャドウリストに示された各シャドウ特定情報に対応するシャドウ１１４を抽出する。さらに、データ取得部１１９は、抽出されたシャドウ１１４のそれぞれから、シャドウアクセス要求のデータ指定情報に示されたデータである指定データを抽出する。データ取得部１１９は、矢印Ｌ３３で示すように、抽出した指定データをアクセス結果として、要求元となったデータ取得ＡＰＩ１４６に返送する。
　［３－４．車両制御処理］
　車両制御ＡＰＩ１４８がサービスユーザからの車両制御要求を受け付けた場合に実行される一連の処理である車両制御処理について説明する。車両制御処理は、車両を指定して、その指定した車両（以下、対象車両）に対して制御を要求する処理である。制御を要求する処理は、例えば、車載機器の動作を要求する処理でもよいし、エッジ装置２またはＥＣＵ２１０，２２０，２３０が記憶するデータの取得を要求する処理でもよい。
　まず、車両制御要求に含まれる指定情報について説明する。
　図２３に示すように、サービスユーザが指定する指定情報は、車両指定情報と、実行対象情報と、制御指定情報と、優先度情報と、制限時間情報と、車両認証情報とを含む。
　車両指定情報には、一つの車両ＩＤが示される。車両ＩＤから特定される車両が対象車両である。車両ＩＤは、前述したｖｉｎまたはｏｂｊｅｃｔ－ｉｄに相当する。
　実行対象情報は、制御指定情報に示された制御内容を、対象車両に実装されたどのアプリケーションに実行させるかを指定する情報であり、アプリケーションを識別するアプリＩＤが示される。
　制御指定情報は、対象車両に実行させる具体的な制御の内容を示す。例えば、各席のドアおよびトランクドア等の各種ドアの鍵操作、ホーンおよびブザー等の音響機器の操作、ヘッドランプおよびハザードランプ等の各種ランプの操作、カメラおよびレーダ等の各種センサの操作が含まれてもよい。制御指定情報は、どの機器にどのような動作をさせるかを示す情報が含まれてもよい。制御指定情報は、一つの制御が示されてもよいし、連続して実行される複数の制御がリスト形式で示されてもよい。なお、リスト形式で示された制御は、リスト順に実行される必要があるものとする。また、制御指定情報として、エッジ装置２またはＥＣＵ２１０，２２０，２３０が記憶するデータの取得操作が含まれてもよい。
　優先度情報は、車両制御要求に基づいて生成される制御指示を、対象車両に向けて送信する際の優先度を示す。ここでは、高優先度と低優先度に２レベルに設定される。優先度情報は、要求元となるサービスユーザによって設定されてもよいし、制御指定情報に示された制御の内容に応じて自動的に設定されてもよい。また、車両制御ＡＰＩ１４８が、所定のルールに基づいて、優先度を設定してもよい。
　制限時間情報は、対象車両での制御が許容される最終時刻を示す。制限時間情報は、例えば、車両制御要求が入力された時刻＋１０分を限度として設定される。制限時間情報は、優先度情報と同様に、要求元となるサービスユーザによって設定されてもよいし、車両に要求する制御の内容に応じて自動的に設定されてもよい。また、車両制御ＡＰＩ１４８が、所定のルールに基づいて、制御時間情報を設定してもよい。
　車両認証情報は、対象車両が制御指示を受け入れてよいか否かの判定に用いる情報であり、対象車両の所有者を識別するオーナーＩＤとパスワードとで構成される。車両認証情報は、車両に保持されると共に、その車両へのアクセスが許可されたサービスユーザにも保持される。なお、シェアカーの場合には、対象車両の利用者を識別する利用者ＩＤとパスワードとで車両認証情報を構成してもよい。
　図２４に示すように、車両制御部１３０は、矢印Ｌ４１で示すように、車両制御ＡＰＩ１４８から車両制御要求が入力されると、矢印Ｌ４２で示すように、車両制御要求に基づいて生成される１または複数の制御指示を対象車両に向けて送信する。図２４では、簡単のため１つの制御指示を送信する場合を示す。車両制御部１３０は制御指示に対して、中継制御を実行する。中継制御は、例えば、対象車両へのアクセスによって実現される車両制御の信頼性を向上させる制御が含まれる。
　車両に搭載されたエッジ装置２は、管理センター３から制御指示を受信すると、制御指示に示された車両認証情報と、自車両が有する車両認証情報とを照合して認証を行う。
　認証に失敗した場合、エッジ装置２は、その旨を表す通知を含んだ応答を管理センター３に送信する。
　認証に成功した場合、エッジ装置２は、実施対象情報から特定されるアプリケーションに、制御指定情報に示された制御を実行させる。アプリケーションは、制御指定情報に従い、ＥＣＵ２１０に対し、制御の実行を要求する。ＥＣＵ２１０は、制御の対象となるＥＣＵ２２０，２３０へ制御の実行を要求する。また、エッジ装置２は、矢印Ｌ４３で示すように、制御の実施結果を含んだ応答を管理センター３に送信する。
　応答を受信した車両制御部１３０は、矢印Ｌ４４で示すように、応答内容を車両制御ＡＰＩ１４８に返送する。
　［３－５、通信制御］
　車両制御部１３０が車両との通信時に実行する通信制御について説明する。
　図２５に示すように、車両制御部１３０は、受付部１３１と、送信管理部１３２と、受信管理部１３３と、制御履歴記憶部１３４とを備える。
　制御履歴記憶部１３４は、車両に送信する制御指示の履歴データを記憶する。履歴データには、車両制御要求に示された指定情報の一部に加えて、オーダーＩＤと、制御ステータスとが含まれる。
　図２６に示すように、履歴データとして記憶される指定情報は、車両指定情報と、優先度情報と、制御指定情報とが含まれる。オーダーＩＤは、制御履歴記憶部１３４に登録された履歴データ（すなわち、制御指示）にシリアルに付与される番号である。制御ステータスは、制御指示についてあらかじめ定義されたステータスが列挙され、このステータスと対応づけて、該当するステータスに変化した時刻を表すタイムスタンプが記憶される。なお、ステータスには、制御指示の送信要求を受け付けた状態、制御指示を送信した状態、応答を受信した状態などがある。
　受付部１３１、送信管理部１３２、受信管理部１３３は、制御履歴記憶部１３４およびシャドウ記憶部１１３に記憶された対象車両のシャドウ１１４を参照して処理を実行する。
　［３－５－１．受付処理］
　車両制御ＡＰＩ１４８が車両制御要求を受け付けた場合に、受付部１３１が実行する受付処理を、図２７のフローチャートを用いて説明する。
　Ｓ２１０では、受付部１３１は、まず、順序処理を実行する。
　ここで順序処理を、図２８のフローチャートを用いて説明する。
　Ｓ３１０では、受付部１３１は、車両制御要求の指定情報を参照し、制御指示情報に複数の制御がリスト形式で記載されているか否かを判定し、リスト形式で記載されていれば処理をＳ３２０に移行し、一つの制御が記載されていれば処理をＳ３３０に移行する。
　Ｓ３２０では、受付部１３１は、車両制御要求から複数の制御指示を生成して、処理をＳ３４０に進める。具体的には、制御指示情報にリスト形式で示された制御の数がＮ個である場合、一つの車両制御要求からＮ個の制御指示を生成する。生成されるＮ個の制御指示は、制御指示情報以外の部分は、元の車両制御要求からのコピーが用いられ、制御指示情報には一つの制御が示される。
　Ｓ３３０では、受付部１３１は、車両制御要求から一つの制御指示を生成して、処理をＳ３４０に進める。具体的には、制御指示は、車両制御要求の指定情報をそのまま受け継いだ内容となる。
　Ｓ３４０では、受付部１３１は、制御指示にオーダーＩＤを付与して、処理を終了する。基本的には、制御指示を受け付けた順にシリアルな番号をオーダーＩＤとして付与する。Ｓ３２０にて一つの車両制御要求から複数の制御指示が生成された場合は、これらの複数の制御指示には、元の車両制御要求の制御指示情報に示された制御の順番にオーダーＩＤを付与する。
　ここで、制御指示情報において、リスト形式で指定される個別の制御を単位制御とする。単位制御は、「ライト点灯」や「ライト消灯」等のような単純な内容だけでなく、「ホーンを１００ｍｓｅｃ間隔でオンオフを２回繰り返す」や「ヘッドライトを２００ｍｓｅｃ間隔でオンオフを３回繰り返す」等のような内容であってもよい。すなわち、同一種類の制御の繰り返しをインターバル情報も含めて指定する内容を単位制御としてもよい。このような制御の指示が特定制御指示に相当する。個々の制御指示がエッジ装置２に到達するまでの遅延は、その時々の状況によって様々に異なるため、管理センター３側で制御のインターバルを管理することは困難である。しかし、インターバル情報を含む同一制御の繰り返しを単位制御とした場合、制御のインターバルが車両側でコントロールされるため、サービスユーザが意図する制御を車両側で忠実に再現させることができる。すなわち、エッジ装置２は、例えば、ＥＣＵ２１０に対し、ホーンをオンする指示を送信し、１００ｍｓｅｃ待機し、ホーンをオフする指示を送信し、１００ｍｓｅｃ待機し、ホーンをオンする指示を送信し、１００ｍｓｅｃ待機し、ホーンをオフする指示を送信する。
　図２７に戻り、順序処理が終了すると、続くＳ２２０では、受付部１３１は、ウェイクアップ処理を実行する。
　ここでウェイクアップ処理を、図２９のフローチャートを用いて説明する。
　Ｓ４１０では、受付部１３１は、シャドウ記憶部１１３から、対象車両の最新のシャドウ１１４に示された「ｐｏｗｅｒ＿ｓｔａｔｕｓ」を取得する。この「ｐｏｗｅｒ＿ｓｔａｔｕｓ」により、エッジ装置２の電源状態が分かる。
　続くＳ４２０では、受付部１３１は、「ｐｏｗｅｒ＿ｓｔａｔｕｓ」が電源オンであるか否かを判定し、電源オンであれば処理を終了し、電源オンではなく、電源オフであれば、処理をＳ４３０に移行する。
　Ｓ４３０では、受付部１３１は、対象車両のエッジ装置２に対してウェイクアップ指示を送信する。エッジ装置２は、ウェイクアップ指示を受信することで、電源オフまたはスリープの状態から、電源オンまたはウェイクアップの状態に遷移する。
　続くＳ４４０では、受付部１３１は一定時間（例えば１秒）待機して、処理をＳ４１０に戻す。
　つまり、「ｐｏｗｅｒ＿ｓｔａｔｕｓ」が電源オフであった場合、ウェイクアップ指示を送信することで、エッジ装置２の機能全てを利用可能なウェイクアップ状態に遷移させる。その状態変化は、車両からのウェイクアップ指示に対する応答、または車両からの周期的な車両データの送信により、管理センター３に通知されることで、対象車両のシャドウ１１４の「ｐｏｗｅｒ＿ｓｔａｔｕｓ」が電源オンに更新される。
　なお、車両制御部１３０は、シャドウ１１４の最新の「ｍｏｂｉｌｉｔｙ＿ｄａｔａ」（すなわち、標準化車両データ）を参照し、エッジ装置２以外に対する電源制御指示を行うよう構成してもよい。例えば、対象車両のイグニッション電源がオフであった場合、エッジ装置２を介して電源を制御する電子制御装置へイグニッション電源オン指示を送信する。また、対象車両に搭載され、車外または車内を撮影するカメラの電源がオフであった場合、エッジ装置２を介してカメラ起動指示を送信する。このように、対象車両へ事前の指示を送信することで、受付部１３１で受け付けた車両制御要求を、エッジ装置２で確実に実行させることができる。
　図２７に戻り、ウェイクアップ制御が終了すると、続くＳ２３０では、受付部１３１は、制御履歴記憶部１３４に制御指示を履歴データとして登録する。登録時の制御ステータスは、制御を受け付けたことを示す「Ａｃｃｅｐｔ」に設定される。
　続くＳ２４０では、受付部１３１は優先処理を実行して処理を終了する。
　ここで、優先処理を、図３０のフローチャートを用いて説明する。
　Ｓ５１０では、受付部１３１は、処理の対象となる制御指示の優先度情報を取得する。優先度情報は、図２３に示すように、車両制御要求の指定情報として設定され、図２６に示すように、制御指示に紐付けて制御履歴記憶部１３４に登録される。
　続くＳ５２０では、受付部１３１は、取得した優先度情報に優先度の設定があるか否かを判定し、優先度の設定があれば処理をＳ５４０に移行し、優先度の設定がなければ処理をＳ５３０に移行する。
　Ｓ５３０では、受付部１３１は、優先度情報を低優先度に設定して、処理をＳ５４０に移行する。例えば、優先度が３レベル以上ある場合は、最も低い優先度の値を設定する。
　Ｓ５４０では、受付部１３１は、優先度情報の設定が高優先度であるか否かを判定し、高優先度であれば処理をＳ５５０に移行し、高優先度ではなく低優先度であれば処理をＳ５６０に移行する。例えば、優先度の設定がなされている場合に高優先度であると判定してもよいし、優先度の値が所定閾値以上の場合に高優先度であると判定してもよい。
　Ｓ５５０では、受付部１３１は、制御指示を優先キューに登録して、処理をＳ５７０に進める。キューは、データを、書き込んだ順に取り出すことができるようなデータ構造を有したバッファである。
　Ｓ５６０では、受付部１３１は、制御指示を非優先キューに登録して、処理をＳ５７０に進める。
　Ｓ５７０では、受付部１３１は、優先キューを優先して、優先キューおよび非優先キューから制御指示を順番に取り出し、取り出した制御指示を送信管理部１３２に渡して処理を終了する。優先キューを優先するとは、例えば、優先キューにデータが残っている限りは優先キューからデータを取り出し、優先キューにデータがない場合にのみ、非優先キューからデータを取り出すようにしてもよい。また、優先キューの方が非優先キューより高い比率で、データを取り出すようにしてもよい。
　［３－５－２．送信側処理］
　送信管理部１３２が実行する送信側処理を、図３１に示すフローチャートを用いて説明する。送信側処理は、Ｓ５７０で優先キューまたは非優先キューから制御指示を取り出し、エッジ装置２へ送信する際の処理である。
　Ｓ６１０では、送信管理部１３２は、受付部１３１から提供される制御指示の指示情報に含まれる制限時間情報（すなわち、図２３に示す制限時間情報）を取得する。
　続くＳ６２０では、送信管理部１３２は、現在時刻が制限時間情報に示された制限時刻を超過しているか否かを判定し、制限時刻を超過していれば処理をＳ６３０に移行し、制限時刻を超過していなければ処理をＳ６４０に移行する。例えば、非優先キューから取り出されるまでに時間を要することで、現在時刻が制限時刻を超過する場合が考えられる。なお、超過しているか否かの判定には、管理センター３から車両に制御指示が到達するのに要する時間だけ、制限時刻より前の時刻を用いてもよい。さらに、車両において制御指示が実行完了するのに要する時間だけ、制限時刻より前の時刻を用いてもよい。すなわち、制御指示が車両に到達し、実行完了されるまでに要する時間が、制限時間情報を超過してしまう場合に、Ｓ６３０に移行するようにしてもよい。
　ここで、Ｓ６２０の制限時間情報での判定に代えて、車両状態の変化を条件として、制御失敗か否かを判定してもよい。例えば、制限情報として、「車両が停止中」という条件が指定された場合、最新のシャドウ１１４または標準化車両データに属するデータのうち最新タイムスタンプのデータを参照し、車両が依然として停止中か否かを判定する。そして、停止中と判定された場合、処理をＳ６４０に移行し、停止中ではないと判定された場合、処理をＳ６３０に移行するようにしてもよい。
　Ｓ６３０では、送信管理部１３２は、要求元の車両制御ＡＰＩ１４８に、制御に失敗したことを知らせる完了通知を送信すると共に、制御履歴記憶部１３４の制御ステータスを制御失敗に更新して、処理を終了する。
　Ｓ６４０では、送信管理部１３２は、制御指示をエッジ装置２へ送信した後、受付部１３１から提供される制御指示に対応づけられる対応データを、対象車両のシャドウ１１４から取得する。制御指示をエッジ装置２へ送信した後、所定時間待機してから、対応データを対象車両の最新のシャドウ１１４から取得してもよい。対応データは、標準化車両データに属するデータのうち最新タイムスタンプのデータであって、制御指示を実行する前後で変化する車両の状態に応じた値を有するデータである。例えば、制御指示がドアの解錠である場合、解錠の対象となるドアの鍵の状態を表す車両データが対応データとなる。例えば、制御指示がヘッドライトの点灯である場合、点灯の対象となるヘッドライトの状態を表す車両データが対応データとなる。対応データは、制御対象となる機器またはＥＣＵ２１０，２２０，２３０の状態を表す車両データである。
　続くＳ６５０では、送信管理部１３２は、対応データが制御実行後の値になっているか否かを判定し、制御実行後の値になっていれば、処理をＳ６６０に移行し、制御実行後の値になっていなければ、処理をＳ６７０に移行する。なお、対応データが存在しない制御指示の場合、Ｓ６４０～Ｓ６６０の処理は省略されてもよい。
　Ｓ６６０では、送信管理部１３２は、要求元の車両制御ＡＰＩ１４８に、制御に成功したことを知らせる完了通知を送信すると共に、制御履歴記憶部１３４の制御ステータスを、制御成功に更新して処理を終了する。
　Ｓ６７０では、送信管理部１３２は、制御指示の送信を実行する。つまり、制御指示を表すＭＱＴＴメッセージをＭＱＴＴブローカにパブリッシュする。合わせて、送信管理部１３２は、制御履歴記憶部１３４の制御ステータスを、送信済みに更新しておく。
　続くＳ６８０では、送信管理部１３２は、制御履歴記憶部１３４の制御ステータスを確認する。つまり、制御ステータスの中で最も新しいタイムスタンプが書き込まれているステータスが何であるかを確認する。
　続くＳ６９０では、送信管理部１３２は、制御ステータスが、制御指示が対象車両に正常に到達したことを示す「Ｃｏｍｐｌｅｔｅ」であるか否かを判定し、「Ｃｏｍｐｌｅｔｅ」であれば処理をＳ７００に移行し、「Ｃｏｍｐｌｅｔｅ」でなければ処理をＳ７１０に移行する。
　Ｓ７００では、送信管理部１３２は、要求元となった車両制御ＡＰＩ１４８に、制御に成功したことを知らせる完了通知を送信すると共に、制御履歴記憶部１３４の制御ステータスを、制御成功に更新して処理を終了する。
　Ｓ７１０では、送信管理部１３２は、制御指示を送信してからの経過時間がタイムオーバしているか否かを判定し、タイムオーバしていなければ処理をＳ７２０に移行し、タイムオーバしていれば処理をＳ７３０に移行する。なお、タイムオーバしているか否かの判定は、あらかじめ設定された許容時間（例えば１０分）を超えているか否かによって行う。なお、許容時間は、車両制御要求の際に指定される制限時間情報に基づいて設定されてもよい。
　Ｓ７２０では、送信管理部１３２は、あらかじめ設定された一定時間（例えば１分）待機した後、処理をＳ６８０に戻す。
　Ｓ７３０では、送信管理部１３２は、タイムアウト通知を、要求元となった車両制御ＡＰＩ１４８に返送すると共に、制御履歴記憶部１３４の制御ステータスを、タイムアウトによる異常終了に更新する。更に、送信管理部１３２は、制御指示に対応するＭＱＴＴメッセージを無効化して、処理を終了する。すなわち、送信管理部１３２は、既に車両へ送信した制御指示の実行を、車両にて行わなくてよい旨を車両へ通知すべく、無効化処理を行う。
　なお、無効化処理を省略して、タイムアウト通知を受けたサービスユーザに、無効化処理相当の制御を実行するか否かの判定を任せるようにしてもよい。つまり、例えば、ライトを点灯する車両制御要求を車両制御ＡＰＩ１４８から入力したが、タイムアウト通知が返ってきたときに、サービスユーザは、そのまま放置してもよいし、念のためライトを消灯する車両制御要求を車両制御ＡＰＩ１４８から入力してもよい。
　［３－５－３．受信側処理］
　受信管理部１３３が実行する受信側処理を、図３２に示すフローチャートを用いて説明する。本処理は繰り返し実行される。
　Ｓ８１０では、受信管理部１３３は、先のＳ４３０で送信されたウェイクアップ指示に対してウェイクアップ完了通知を受信したか否かを判定し、受信していれば処理をＳ８２０に移行し、受信していなければ処理をＳ８３０に移行する。
　Ｓ８２０では、受信管理部１３３は、対象車両のシャドウ１１４の「ｐｏｗｅｒ＿ｓｔａｔｕｓ」を電源オンに更新して、処理を終了する。この更新を受けて先のＳ４２０での判定は肯定判定される。
　Ｓ８３０では、受信管理部１３３は、先のＳ６７０で送信した制御指示に対して、到達通知を受信したか否かを判定し、到達通知を受信していれば処理をＳ８４０に移行し、到達通知を受信していなければ、処理を終了する。
　Ｓ８４０では、受信管理部１３３は、到達通知の対象となる制御指示について制御履歴記憶部１３４に記憶された履歴データの制御ステータスを「Ａｃｃｅｐｔ」から「Ｃｏｍｐｌｅｔｅ」に更新して、処理を修了する。この更新を受けて、先のＳ６９０での判定は肯定判定される。
　なお、図２５に示すように、エッジ装置２は、ウェイクアップ制御部２０１と、指示実行部２０２を備える。
　ウェイクアップ制御部２０１は、エッジ装置２が搭載された車両の電源状態を管理する。車両の電源状態には、一部の機能が停止した低消費電力のスリープ状態と、全ての機能が起動したウェイクアップ状態とがある。ウェイクアップ制御部２０１は、自車両がスリープ状態にあるときに、管理センター３から自車両宛のウェイクアップ指示を受信すると、エッジ装置２の電源状態をウェイクアップ状態に遷移させ、ウェイクアップ完了通知を管理センター３に送信する。
　指示実行部２０２は、自車両の電源状態がウェイクアップ状態である場合に動作する。指示実行部２０２は、制御指示に添付された車両認証情報と、自車両が有する車両認証情報とを照合することで認証を行い、認証に成功した場合に、制御指示に示された制御を自身で実行または該当する電子制御装置に実行させる。指示実行部２０２は、認証に失敗した場合には、その旨を示す応答を管理センター３に送信し、制御を実行した場合は、制御結果を管理センター３に送信する。
　［３－６．動作例］
　車両制御部１３０の動作例について説明する。
　まず、対象車両のエッジ装置２の電源状態がウェイクアップ状態にある場合の典型的な動作を、図３３を用いて説明する。なお、なお、対象車両のシャドウ１１４の「ｐｗｅｒ＿ｓｔａｔｕｓ」は、対象車両のエッジ装置２の電源状態が反映され「電源オン」となっている。
　受付部１３１は、矢印Ｌ５１で示すように、制御履歴記憶部１３４に制御指示の履歴データを登録する。履歴データの登録により、履歴データの制御ステータスは「Ａｃｃｅｐｔ」に設定される。また、受付部１３１は、矢印Ｌ５２で示すように、制御指示を送信管理部１３２に送信する。
　制御指示を受けた送信管理部１３２は、矢印Ｌ５３で示すように、対象車両のシャドウ１１４の「ｐｏｗｅｒ＿ｓｔａｔｕｓ」を確認する。「ｐｗｅｒ＿ｓｔａｔｕｓ」は「電源オン」であるため、送信管理部１３２は、矢印Ｌ５４で示すように、制御指示を対象車両に送信する。以後、送信管理部１３２は、矢印Ｌ５５で示すように、履歴データの制御ステータスを周期的に確認する。
　制御指示を受けた対象車両は、矢印Ｌ５６で示すように、制御指示を正常に受け取ったことを示す到達通知を管理センター３に返送する。
　到達通知を受信した受信管理部１３３は、矢印Ｌ５７で示すように、履歴データの制御ステータスを「Ａｃｃｅｐｔ」から「Ｃｏｍｐｌｅｔｅ」に更新する。
　送信管理部１３２は、履歴データの周期的な確認により、制御ステータスが「Ｃｏｍｐｌｅｔｅ」に変化していることを確認すると、矢印Ｌ５８で示すように、制御指示が正常に完了したことを示す完了通知を、要求元の車両制御ＡＰＩ１４８に送信する。
　次に、対象車両に制御指示を送信したが、対象車両から到達通知が返ってこない場合の動作を、図３４を用いて説明する。
　なお、矢印Ｌ５１～Ｌ５５で示すように、受付部１３１が履歴データの登録を行ってから、送信管理部１３２が対象車両に制御指示を送信し、履歴データの周期的な監視を開始するところまでは、図３３に示した内容と同様である。
　送信管理部１３２は、対象車両に制御指示を送信した後、制限時間情報に示された制限時刻、または予め設定された許容時間を経過しても、履歴データの制御ステータスが「Ａｃｃｅｐｔ」のままである場合、矢印Ｌ５９で示すように、要求元の車両制御ＡＰＩ１４８に異常終了したことを示すタイムアウト通知を送信する。
　次に、対象車両のエッジ装置２の電源状態がスリープ状態である場合の動作を、図３５を用いて説明する。なお、対象車両のシャドウ１１４の「ｐｗｅｒ＿ｓｔａｔｕｓ」は、対象車両のエッジ装置２の電源状態が反映され「電源オフ」となっている。また、矢印Ｌ５１～Ｌ５３で示すように、受付部１３１が履歴データの登録を行ってから、送信管理部１３２が対象車両のシャドウ１１４の「ｐｏｗｅｒ＿ｓｔａｔｕｓ」を確認するところまでは、図３３に示した内容と同様である。
　送信管理部１３２によって確認される対象車両のシャドウ１１４の「ｐｗｅｒ＿ｓｔａｔｕｓ」は「電源オフ」であるため、送信管理部１３２は、矢印Ｌ６０で示すように、対象車両に対してウェイクアップ指示を送信する。以後、送信管理部１３２は、周期的に対象車両の「ｐｏｗｅｒ＿ｓｔａｔｕｓ」を確認する。
　ウェイクアップ指示を受信した対象車両は、エッジ装置２の電源状態をスリープ状態からウェイクアップ状態に遷移させ、矢印Ｌ６１で示すように、ウェイクアップ完了通知を、管理センター３に返送する。
　ウェイクアップ完了通知を受信した受信管理部１３３は、矢印Ｌ６２で示すように、対象車両のシャドウ１１４の「ｐｏｗｅｒ＿ｓｔａｔｕｓ」を「電源オン」に更新する。
　送信管理部１３２は、矢印Ｌ６３で示すように、周期的な確認により、対象車両のエッジ装置２の「ｐｏｗｅｒ＿ｓｔａｔｕｓ」が「電源オン」に変化していることを確認すると、矢印Ｌ６４で示すように、対象車両に対して制御指示を送信する。
　以後の動作は、図３３および図３４に、矢印Ｌ５５～Ｌ５９で示した内容と同様である。
　［４．用語の対応］
　以上説明した実施形態において、モビリティＩｏＴシステム１はモビリティサービス提供システムに相当し、管理センター３はモビリティサービス基盤サーバに相当し、エッジ装置２は車載機に相当する。シャドウ管理部１１２は第１データベースに相当し、データ管理部１２１は第２データベースに相当する。ＡＰＩ提供部１２２はインタフェース部に相当する。Ｓ２３０の処理は履歴登録部に相当し、Ｓ３１０～Ｓ３４０の処理は順序制御部に相当し、Ｓ５１０～Ｓ５７０の処理は優先処理部に相当する。Ｓ６１０～Ｓ６２０の処理は送信前判定部に相当する。Ｓ６８０～Ｓ７００，Ｓ７２０の処理は送達確認部に相当し、Ｓ７１０，Ｓ７３０の処理は無効化部に相当し、Ｓ６３０、Ｓ８３０～Ｓ８４０の処理は履歴更新部に相当する。制御ステータスの「Ａｃｃｅｐｔ」が受諾状態に相当し、「Ｃｏｍｐｌｅｔｅ」が完了状態に相当し、車両制御要求がアクセス要求に相当する。
　［５．効果］
　以上詳述した実施形態によれば、以下の効果を奏する。
　（５ａ）モビリティＩｏＴシステム１では、車両制御要求に優先度情報が含まれ、車両制御要求から生成される制御指示を、高優先度に設定された制御指示を優先して車両に向けて送信する。従って、管理センター３側で多くの制御指示が滞留しているような状況であっても、高優先度の制御指示については、少ない遅延で送信を完了させることができる。
　（５ｂ）モビリティＩｏＴシステム１では、制御指示は、それぞれが独立した一つの制御を実現し、また、各制御指示には、シリアル番号を用いたオーダーＩＤが付与される。また、制御指示を受信する車両側では、オーダーＩＤに示されたシリアル番号に従った順番で制御を実行する。従って、管理センター３と車両（すなわちエッジ装置２）との間の通信環境等の影響で、車両に到達する制御指示の順番が入れ替わったとしても、車両側では、車両制御要求の要求元が意図する順番通りに制御を実行できる。その結果、管理センター３からの指示に基づく車両制御の安全性および信頼性を向上させることができる。例えば、厳密な順序性をもって実行する必要のある一連の制御では、制御の順番が入れ替わることによって、全く異なった制御になったり、意味のない制御になったりする可能性があるが、このような状況が発生することを抑制できる。
　（５ｃ）モビリティＩｏＴシステム１では、車両へ制御指示を送信した後、制御ステータスを繰返し確認する。そして、車両からの応答があったことを示すステータスに変化した場合は、車両制御要求の要求元に完了通知を返し、許容時間を超えてもステータスに変化がない場合は、車両制御要求の要求元にタイムアウト通知を返す。従って、モビリティＩｏＴシステム１によれば、制御指示が車両に到達したこと、および制御指示が許容時間内に車両に到達しなかったことを、車両制御要求の要求元に知らせることができる。その結果は、車両制御要求の要求元では、制御指示の到達の成否に応じた的確な対処が可能となる。
　（５ｄ）モビリティＩｏＴシステム１では、制御指示が車両に到達しても制限時刻までに制御を終了させることが不能である場合は、制御指示を送信することなく、制御に失敗したことを、車両制御要求の要求元に知らせる。また、モビリティＩｏＴシステム１では、制御指示を送信する前に、対象車両のシャドウ１１４を参照することで、制御指示に対応づけられた対応データを確認する。そして、対応データが制御実行後の値になっている場合、制御指示を送信することなく、制御に成功したことを、車両制御要求の要求元に知らせる。従って、モビリティＩｏＴシステム１によれば、無駄な制御指示の送信が抑制されるため、管理センター３と車両との間の通信量を削減できる。
　（５ｅ）モビリティＩｏＴシステム１では、制御指示を送信する前に、対象車両のシャドウ１１４を参照することで、対象車両の「ｐｏｗｅｒ＿ｓｔａｔｕｓ」を確認し、電源オフである場合、ウェイクアップ指示を送信する。つまり、対象車両を、制御指示を実行可能な状態に遷移させた上で、制御指示を送信する。従って、モビリティＩｏＴシステム１では、対象車両のエンジンがオフの状態でも、対象車両を起動して制御を実行させることができる。
　［６．他の実施形態］
　以上、本開示の一実施形態について説明したが、本開示は上記実施形態に限定されるものではなく、種々変形して実施することができる。
　（６ａ）本開示では、制御履歴記憶部１３４に履歴データが制御指示単位で記憶されているが、車両制御要求単位（すなわち、車両制御ＡＰＩ１４８からの要求単位）で記憶されてもよい。
　（６ｂ）本開示では、車両制御部１３０は、制御指示に対するエッジ装置２からの応答を、そのまま制御指示単位で、要求元の車両制御ＡＰＩ１４８に返すように構成されている。本開示は、これに限定されず、一つの車両制御要求から複数の制御指示が生成される場合、制御指示に対するエッジ装置２からの応答を、車両制御要求単位でまとめて、要求元の車両制御ＡＰＩ１４８に返すように構成されてもよい。
　（６ｃ）本開示では、管理センター３からの制御指示に対してエッジ装置２は、制御内容の実行が完了した時点で管理センター３への応答を送信しているが、制御指示を受け付けた時点で管理センター３へ応答を送信してもよい。
　（６ｄ）本開示に記載の制御部３１およびその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサおよびメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御部３１およびその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御部３１およびその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサおよびメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されてもよい。制御部３１に含まれる各部の機能を実現する手法には、必ずしもソフトウェアが含まれている必要はなく、その全部の機能が、一つあるいは複数のハードウェアを用いて実現されてもよい。
　（６ｅ）上記実施形態における１つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、１つの構成要素が有する１つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、１つの構成要素によって実現したり、複数の構成要素によって実現される１つの機能を、１つの構成要素によって実現したりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加または置換してもよい。
　（６ｆ）上述した管理センター３の他、当該管理センター３を構成要素とするシステム、当該管理センター３としてコンピュータを機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実体的記録媒体、車両アクセス制御方法など、種々の形態で本開示を実現することもできる。

Claims (14)

  1. 　車両に搭載された車載機から提供される車両データに基づいて、前記車両毎に生成され、特定の時刻における前記車両の状態を表す複数のシャドウを記憶する第１データベース（１１２）を有する車両側ユニット（１１０）と、
    　前記第１データベースに蓄積された前記シャドウのそれぞれに対応し、前記シャドウの検索に使用される情報を有するインデックスを記憶する第２データベース（１２１）、および外部からのアクセス要求を受け付けるように構成されたインタフェース部（１２２）を有するサービス側ユニット（１２０）と、
    　を備え、
    　前記車両側ユニットは、
    　前記インタフェース部が前記車両に対する前記アクセス要求を受け付けた場合、アクセスの対象となる前記車両である対象車両に搭載された前記車載機との無線通信を行うことで、前記対象車両へのアクセスを実行するように構成された車両制御部（１３０）を更に備え、
    　前記車両制御部は、
    　前記車載機との間で送受信される制御指示に対して、中継制御を実行するように構成された
    　モビリティサービス基盤サーバ。
  2. 　請求項１に記載のモビリティサービス基盤サーバであって、
    　前記車両制御部は、
    　前記車両に対して送信する前記制御指示の内容および制御ステータスを記憶する制御履歴記憶部（１３４）と、
    　前記制御履歴記憶部に前記制御指示を、前記制御ステータスを受諾状態に設定して登録する履歴登録部（Ｓ２３０）と、
    　前記制御指示の送信後、前記制御ステータスを監視することで、前記制御指示の送達を確認する送達確認部（Ｓ６８０～Ｓ７００，Ｓ７２０）、と、
    　前記制御指示に対する前記車載機からの応答の受信時に、前記制御履歴記憶部における前記制御指示の前記制御ステータスを完了状態に更新する履歴更新部（Ｓ８３０～Ｓ８４０）と、
    　を備えるモビリティサービス基盤サーバ。
  3. 　請求項２に記載のモビリティサービス基盤サーバであって、
    　前記車両制御部は、
    　前記送達確認部によって、あらかじめ設定された許容時間内に前記制御指示の送達が確認されなかった場合、前記制御指示を無効化する無効化部（Ｓ７１０，Ｓ７３０）
    　を更に備えるモビリティサービス基盤サーバ。
  4. 　請求項２または請求項３に記載のモビリティサービス基盤サーバであって、
    　前記車両制御部は、
    　前記制御指示を前記車載機へ送信する前に、前記制御指示で指定される許容時間内に、前記制御指示を前記車載機へ送信し、前記車載機での実行を完了できるか否かを判定する送信前判定部（Ｓ６１０～Ｓ６２０）を更に備え、
    　前記履歴更新部（Ｓ６３０）は、前記送信前判定部にて否定判定された場合、前記車載機への前記制御指示の送信を中止し、前記制御履歴記憶部における前記制御指示の前記制御ステータスを送信に失敗したことを示す状態に更新する
    　モビリティサービス基盤サーバ。
  5. 　請求項１から請求項４までのいずれか１項に記載のモビリティサービス基盤サーバであって、
    　前記制御指示は、優先度を有し、
    　前記車両制御部は、
    　前記制御指示の送信順を前記優先度に従って設定する優先処理部（Ｓ５１０～Ｓ５７０）
    　を備えるモビリティサービス基盤サーバ。
  6. 　請求項５に記載のモビリティサービス基盤サーバであって、
    　前記優先度は、前記アクセス要求毎に、前記インタフェース部にて設定される
    　モビリティサービス基盤サーバ。
  7. 　請求項５に記載のモビリティサービス基盤サーバであって、
    　前記優先度は、前記アクセス要求に示された制御内容に応じて決まる
    　モビリティサービス基盤サーバ。
  8. 　請求項１から請求項７までのいずれか１項に記載のモビリティサービス基盤サーバであって、
    　前記車両制御部は、
    　順序制御が必要な一連の前記制御指示に、制御の実行順を表すシリアル番号を付与する順序制御部（Ｓ３１０～Ｓ３４０）
    　を備えるモビリティサービス基盤サーバ。
  9. 　請求項８に記載のモビリティサービス基盤サーバであって、
    　前記順序制御部は、前記アクセス要求に順序制御が必要な複数の制御が含まれている場合に、該アクセス要求から複数の前記制御指示を生成し、前記制御指示のそれぞれに、前記シリアル番号を付与するように構成された、
    　モビリティサービス基盤サーバ。
  10. 　車両に搭載された車載機と、
    　前記車載機を搭載する前記車両にモビリティサービスを提供するモビリティサービス基盤サーバと、
    　を備え、
    　前記モビリティサービス基盤サーバは、
    　前記車載機から提供される車両データに基づいて、前記車両毎に複数生成され、特定の時刻における前記車両の状態を表す複数のシャドウを記憶する第１データベースを有する車両側ユニットと、
    　前記第１データベースに蓄積された前記シャドウのそれぞれに対応し、前記シャドウの検索に使用される情報を有するインデックスを記憶する第２データベース、および外部からのアクセス要求を受け付けるように構成されたインタフェース部を有するサービス側ユニットと、
    　を備え、
    　前記車両側ユニットは、
    　前記インタフェース部が前記車両に対する前記アクセス要求を受け付けた場合、アクセスの対象となる前記車両である対象車両に搭載された前記車載機との無線通信を行うことで、前記対象車両へのアクセスを実行するように構成された車両制御部を更に備え、
    　前記車両制御部は、
    　前記車載機との間で送受信される制御指示に対して、中継制御を実行するように構成された
    　モビリティサービス提供システム。
  11. 　請求項１０に記載のモビリティサービス提供システムであって、
    　前記車両制御部は、
    　前記制御指示として、前記対象車両に搭載された制御対象となる車載機器である対象機器に対する一連の指示を、各指示の制御タイミングを含めて規定した特定制御指示を送信可能に構成され、
    　前記車載機は、
    　前記特定制御指示を受信した場合、該特定制御指示に示された前記一連の指示に含まれる個々の指示を、前記制御タイミングに従って一つずつ順番に前記対象機器に対して出力するように構成された
    　モビリティサービス提供システム。
  12. 　請求項１０または請求項１１に記載のモビリティサービス提供システムであって、
    　前記車両制御部は、
    　順序制御が必要な一連の前記制御指示に、制御の実行順を表すシリアル番号を付与するように構成された順序制御部を備え、
    　前記車載機は、前記モビリティサービス基盤サーバから受信する前記制御指示を、該制御指示に付与された前記シリアル番号の順番に実行するように構成された
    　モビリティサービス提供システム。
  13. 　車両に搭載された車載機から提供される車両データに基づいて、前記車両毎に生成され、特定の時刻における前記車両の状態を表す複数のシャドウを記憶する第１データベースと、前記第１データベースに蓄積された前記シャドウのそれぞれに対応し、前記シャドウの検索に使用される情報を有するインデックスを記憶する第２データベースと、外部からのアクセス要求を受け付けるように構成されたインタフェース部とを備えるモビリティサービス基盤サーバにおける車両アクセス制御方法であって、
    　前記インタフェース部が前記車両に対する前記アクセス要求を受け付けた場合、アクセスの対象となる前記車両である対象車両に搭載された前記車載機との無線通信を行うことで、前記対象車両へのアクセスを実行し、
    　前記対象車両へのアクセスにおいて、前記車載機との間で送受信される制御指示に対して、中継制御を実行する、
    　車両アクセス制御方法。
  14. 　車両に搭載された車載機から提供される車両データに基づいて、前記車両毎に生成され、特定の時刻における前記車両の状態を表す複数のシャドウを記憶する第１データベースと、前記第１データベースに蓄積された前記シャドウのそれぞれに対応し、前記シャドウの検索に使用される情報を有するインデックスを記憶する第２データベースと、外部からのアクセス要求を受け付けるように構成されたインタフェース部と共に、モビリティサービス基盤サーバを構成するコンピュータを、
    　前記インタフェース部が前記車両に対する前記アクセス要求を受け付けた場合、アクセスの対象となる前記車両である対象車両に搭載された前記車載機との無線通信を行うことで、前記対象車両へのアクセスを実行し、該対象車両へのアクセスにおいて前記車載機との間で送受信される制御指示に対して、中継制御を実行するように構成された車両制御部として機能させるプログラム。
PCT/JP2022/025811 2021-07-02 2022-06-28 モビリティサービス基盤サーバ、モビリティサービス提供システム、車両アクセス制御方法、プログラム WO2023277031A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202280046549.7A CN117651980A (zh) 2021-07-02 2022-06-28 移动性服务基础服务器、移动性服务提供系统、车辆访问控制方法、程序
JP2023531990A JPWO2023277031A1 (ja) 2021-07-02 2022-06-28
US18/397,685 US20240127646A1 (en) 2021-07-02 2023-12-27 Mobility service base server, mobility service providing system, vehicle access control method, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-110904 2021-07-02
JP2021110904 2021-07-02

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/397,685 Continuation US20240127646A1 (en) 2021-07-02 2023-12-27 Mobility service base server, mobility service providing system, vehicle access control method, and storage medium

Publications (1)

Publication Number Publication Date
WO2023277031A1 true WO2023277031A1 (ja) 2023-01-05

Family

ID=84690051

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/025811 WO2023277031A1 (ja) 2021-07-02 2022-06-28 モビリティサービス基盤サーバ、モビリティサービス提供システム、車両アクセス制御方法、プログラム

Country Status (4)

Country Link
US (1) US20240127646A1 (ja)
JP (1) JPWO2023277031A1 (ja)
CN (1) CN117651980A (ja)
WO (1) WO2023277031A1 (ja)

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180257683A1 (en) * 2017-03-09 2018-09-13 General Electric Company System for vehicle subsystem control
JP2019153291A (ja) * 2018-02-28 2019-09-12 トヨタ自動車株式会社 デジタルツインシミュレーションに基づく車両の故障予測
US20190287079A1 (en) * 2018-03-19 2019-09-19 Toyota Jidosha Kabushiki Kaisha Sensor-based digital twin system for vehicular analysis
JP2020009428A (ja) * 2018-06-13 2020-01-16 トヨタ自動車株式会社 デジタル行動ツインに基づくコネクティッド車両のための衝突回避
JP2020013557A (ja) * 2018-06-13 2020-01-23 トヨタ自動車株式会社 車両リスク評価用のデジタルツイン
US20200065443A1 (en) * 2017-05-02 2020-02-27 The Regents Of The University Of Michigan Simulated vehicle traffic for autonomous vehicles
US20200126415A1 (en) * 2018-10-19 2020-04-23 Toyota Jidosha Kabushiki Kaisha Digital behavioral twin system for intersection management in connected environments
US10839621B1 (en) * 2019-07-24 2020-11-17 Toyota Motor Engineering & Manufacturing North America, Inc. Altering a vehicle based on driving pattern comparison

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180257683A1 (en) * 2017-03-09 2018-09-13 General Electric Company System for vehicle subsystem control
US20200065443A1 (en) * 2017-05-02 2020-02-27 The Regents Of The University Of Michigan Simulated vehicle traffic for autonomous vehicles
JP2019153291A (ja) * 2018-02-28 2019-09-12 トヨタ自動車株式会社 デジタルツインシミュレーションに基づく車両の故障予測
US20190287079A1 (en) * 2018-03-19 2019-09-19 Toyota Jidosha Kabushiki Kaisha Sensor-based digital twin system for vehicular analysis
JP2020009428A (ja) * 2018-06-13 2020-01-16 トヨタ自動車株式会社 デジタル行動ツインに基づくコネクティッド車両のための衝突回避
JP2020013557A (ja) * 2018-06-13 2020-01-23 トヨタ自動車株式会社 車両リスク評価用のデジタルツイン
US20200126415A1 (en) * 2018-10-19 2020-04-23 Toyota Jidosha Kabushiki Kaisha Digital behavioral twin system for intersection management in connected environments
US10839621B1 (en) * 2019-07-24 2020-11-17 Toyota Motor Engineering & Manufacturing North America, Inc. Altering a vehicle based on driving pattern comparison

Also Published As

Publication number Publication date
US20240127646A1 (en) 2024-04-18
CN117651980A (zh) 2024-03-05
JPWO2023277031A1 (ja) 2023-01-05

Similar Documents

Publication Publication Date Title
CN107872777B (zh) 用于车辆的服务协作系统
JP7043736B2 (ja) 車両用電子制御装置及び車両用サービス管理システム
US20220334818A1 (en) Transport component acceptance
CN105721482A (zh) 基于车联网的移动端手持车辆管理方法
WO2019114600A1 (zh) 用于管理车辆控制权限的方法和装置
US8942885B2 (en) Vehicle information transmission apparatus
US11144666B2 (en) Selective data access and data privacy via blockchain
US20230169805A1 (en) Fleet data collection using a unified model to collect data from heterogenous vehicles
Siegel Data proxies, the cognitive layer, and application locality: enablers of cloud-connected vehicles and next-generation internet of things
US20240129735A1 (en) Mobility service providing system, mobility service providing server, vehicle data providing method, and storage medium
JP2009061978A (ja) 車両共有化システム
US11902374B2 (en) Dynamic vehicle data extraction service
JP2023518402A (ja) 証明書リスト更新方法および装置
WO2023277031A1 (ja) モビリティサービス基盤サーバ、モビリティサービス提供システム、車両アクセス制御方法、プログラム
WO2023277030A1 (ja) モビリティサービス基盤サーバ、モビリティサービス提供システム、車両アクセス制御方法、プログラム
WO2020259519A1 (zh) 一种证书更新方法以及相关设备
CN103546591A (zh) 在无线环境中解析ip地址
US20230322107A1 (en) Decentralized charging locations
US11694546B2 (en) Systems and methods for automatically assigning vehicle identifiers for vehicles
JP7359055B2 (ja) 車載情報処理装置、情報処理方法及びクライアントプログラム
WO2023277185A1 (ja) 車載装置、データ生成方法、データ生成プログラムおよび車両システム
US20240126306A1 (en) Center, management method, and storage medium
US20240126937A1 (en) Center, management system, management method, and storage medium
US20240126532A1 (en) System, center, processing method, and storage medium
US20230230486A1 (en) Information system, management device and edge device

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22833177

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023531990

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 202280046549.7

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE