WO2023277032A1 - モビリティサービス提供システム、モビリティサービス提供サーバ、車両データ提供方法、プログラム - Google Patents
モビリティサービス提供システム、モビリティサービス提供サーバ、車両データ提供方法、プログラム Download PDFInfo
- Publication number
- WO2023277032A1 WO2023277032A1 PCT/JP2022/025812 JP2022025812W WO2023277032A1 WO 2023277032 A1 WO2023277032 A1 WO 2023277032A1 JP 2022025812 W JP2022025812 W JP 2022025812W WO 2023277032 A1 WO2023277032 A1 WO 2023277032A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- vehicle
- data
- access
- access request
- service providing
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 88
- 238000013475 authorization Methods 0.000 claims description 154
- 238000012545 processing Methods 0.000 claims description 77
- 238000004891 communication Methods 0.000 claims description 69
- 230000006870 function Effects 0.000 claims description 41
- 230000004044 response Effects 0.000 claims description 23
- 239000000284 extract Substances 0.000 claims description 8
- 238000012384 transportation and delivery Methods 0.000 claims description 5
- 238000002716 delivery method Methods 0.000 claims 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 131
- 230000008569 process Effects 0.000 description 45
- 238000010586 diagram Methods 0.000 description 27
- 230000005540 biological transmission Effects 0.000 description 15
- 238000013500 data storage Methods 0.000 description 13
- 238000006243 chemical reaction Methods 0.000 description 7
- 238000013523 data management Methods 0.000 description 7
- 230000000694 effects Effects 0.000 description 7
- 238000007726 management method Methods 0.000 description 7
- 238000010606 normalization Methods 0.000 description 5
- 230000008859 change Effects 0.000 description 3
- 238000012549 training Methods 0.000 description 3
- 102100034112 Alkyldihydroxyacetonephosphate synthase, peroxisomal Human genes 0.000 description 2
- 101000799143 Homo sapiens Alkyldihydroxyacetonephosphate synthase, peroxisomal Proteins 0.000 description 2
- 238000000848 angular dependent Auger electron spectroscopy Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 101000654386 Homo sapiens Sodium channel protein type 9 subunit alpha Proteins 0.000 description 1
- 102100031367 Sodium channel protein type 9 subunit alpha Human genes 0.000 description 1
- 238000009825 accumulation Methods 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 239000010705 motor oil Substances 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
-
- 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
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/123—Traffic control systems for road vehicles indicating the position of vehicles, e.g. scheduled vehicles; Managing passenger vehicles circulating according to a fixed timetable, e.g. buses, trains, trams
- G08G1/127—Traffic control systems for road vehicles indicating the position of vehicles, e.g. scheduled vehicles; Managing passenger vehicles circulating according to a fixed timetable, e.g. buses, trains, trams to a central station ; Indicators in a central station
- G08G1/13—Traffic control systems for road vehicles indicating the position of vehicles, e.g. scheduled vehicles; Managing passenger vehicles circulating according to a fixed timetable, e.g. buses, trains, trams to a central station ; Indicators in a central station the indicator being in the form of a map
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- 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
- G07C5/00—Registering or indicating the working of vehicles
- G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
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.
- acquiring vehicle data there are two main methods: acquiring data directly from the actual vehicle, and acquiring data from the shadow on the cloud using a virtual environment such as a digital twin, which completes the process in the cloud. .
- This disclosure provides a technique for realizing data provision according to usage in a mobility service provision system.
- One aspect of the present disclosure is a mobility service providing system comprising an in-vehicle device and a mobility service providing server.
- the in-vehicle device is configured to collect vehicle data, which is data that is installed in a vehicle and acquired from the vehicle.
- the mobility service providing server is configured to perform wireless communication with the vehicle-mounted device.
- the in-vehicle device is configured to voluntarily repeatedly transmit vehicle data to the mobility service providing server and to transmit vehicle data to the mobility service providing server in response to a request from the mobility service providing server.
- the mobility service providing server includes a storage unit, an interface unit, a first control unit, and a second control unit.
- the storage unit is configured to store vehicle data acquired from the vehicle-mounted device by wireless communication at predetermined time points.
- the interface unit is configured to receive a first access request and a second access request from outside.
- the first control unit is configured to acquire the vehicle data from the storage unit and provide the vehicle data to the request source via the interface unit when the interface unit receives the first access request.
- the second control unit accesses the onboard unit to obtain the access result including the vehicle data from the onboard unit and provides it to the request source via the interface unit. Configured.
- the vehicle data acquired from the vehicle equipped with the onboard device and stored in the storage unit of the mobility service providing server and the onboard device are installed. It is possible to acquire any vehicle data possessed by the vehicle.
- One aspect of the present disclosure is a mobility service providing server that includes a storage unit, an interface unit, a first control unit, and a second control unit.
- the storage unit is configured to store vehicle data provided from an in-vehicle device mounted in the vehicle.
- the interface unit is configured to receive the first access request and the second access request from the outside.
- the first control unit is configured to acquire the vehicle data from the storage unit and provide the vehicle data to the request source via the interface unit when the interface unit receives the first access request.
- the second control unit accesses the onboard unit to obtain the access result including the vehicle data from the onboard unit and provides it to the request source via the interface unit. Configured.
- a mobility service providing system having the above effects can be constructed.
- a mobility service providing server to which a vehicle data providing method is applied includes a storage unit and an interface unit.
- vehicle data when the interface unit receives the first access request, vehicle data is acquired from the storage unit and provided to the requester via the interface unit. Further, when the interface unit receives the second access request, the access result including the vehicle data is acquired from the vehicle-mounted device by accessing the vehicle-mounted device, and provided to the request source via the interface unit.
- a computer that executes the program constitutes a mobility service providing server together with a storage unit and an interface unit.
- the program causes the computer to function as the first control unit and the second control unit.
- the first control unit acquires the vehicle data from the storage unit and provides the vehicle data to the request source via the interface unit.
- the second control unit accesses the vehicle-mounted device to obtain an access result including vehicle data from the vehicle-mounted device, and provides the access result to the request source via the interface unit.
- 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 first 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 for data acquisition using a first data acquisition API that is an open API; FIG. 10 is a diagram showing the structure of specification information of a second data acquisition request; FIG. 4 is a flowchart of vehicle data acquisition processing executed by a vehicle control unit; FIG. 11 is a sequence diagram showing a procedure of data acquisition using a second data acquisition API, which is a close API; FIG. 2 is a block diagram showing a connection state of an ECU mounted on a vehicle; FIG. FIG. 10 is a diagram showing the configuration of a server-side authorization database that a management center has in the second embodiment; FIG.
- FIG. 11 is a block diagram showing the functional configuration of an edge device in the second embodiment
- FIG. FIG. 10 is a diagram showing the configuration of a vehicle-side authorization database that the edge device has in the second embodiment
- FIG. 10 is a sequence diagram showing a two-step authorization procedure in which authorization processing is executed by both the management center and the edge device
- FIG. 10 is a sequence diagram showing a procedure for vehicle-side independent authorization in which authorization processing is executed only on the edge device side;
- 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.
- vehicle I/F vehicle interface
- 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, a plurality of ECUs 220, a plurality of 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 1st, 2nd, 3rd, 4th, 5th, 6th, 7th and 8th 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 . Each time vehicle data is transmitted from the edge device 2, the shadow creating 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. Data such as “version” and “power_status” are transmitted from the edge device 2 separately from the standardized vehicle data when the values change.
- 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 are a wake-up state in which all functions can be used, and a low power consumption sleep state in which some functions are stopped.
- 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 first data acquisition API 146, a second data acquisition API 147, and a vehicle control API 148 are provided.
- the login API 145 is an API provided for authenticating service users. Both the first data acquisition API 146 and the second data acquisition API 147 are APIs 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 access requests are made through the first data acquisition API 146, the second data acquisition API 147, and the vehicle control API 148. If so, execute the authorization process. 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 first data acquisition API 146 is one of the open APIs used for accessing information with low confidentiality.
- the second data acquisition API 147 is one of close APIs used when accessing highly confidential information.
- the vehicle control API 148 is one of close APIs used when controlling a vehicle on which the edge device 2 is mounted.
- the acquisition of highly confidential data may be provided by a closed API, and the acquisition of less confidential data may be provided by an open API.
- the acquisition of highly confidential data may be provided by the closed API, and the acquisition of the less confidential data may be provided by the open API.
- the control related to vehicle running may be provided by the closed API, and the control not related to vehicle running may be provided by the open API.
- the first data acquisition API 146 which is an open API, is used to access the vehicle data (that is, the index 126 and the shadow 114) accumulated in the management center 3. .
- the second data acquisition API 147 and the vehicle control API 148 which are close APIs, are used to access the vehicle on which the edge device 2 is mounted.
- the close API may be used for part of the vehicle data accumulated in the management center 3 (that is, highly confidential information, etc.).
- the first data acquisition API 146, the second data acquisition API 147, 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 invalid. Judged as approved. 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 authentication processing unit 144 determines authorization. do. If it is determined to be authorized, the authentication processing unit 144 transfers the access request to the access target as indicated by an arrow L25. Specifically, when the access API is an open API such as the first data acquisition API 146, the access request is transferred to the shadow 114 to be accessed. If the access API is a closed API such as second data acquisition API 147 and vehicle control API 148, the access request is forwarded to the actual vehicle to be accessed. 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 (hereinafter referred to as a first data acquisition request) input via the first data acquisition API 146, which is an open API, is processed by the index acquisition unit 127.
- An access request (hereinafter referred to as a second data acquisition request) input via the second data acquisition API 147, which is a close API, and an access request (hereinafter referred to as a vehicle control request) input via the vehicle control API 148 are It is processed by the vehicle control unit 130 .
- a first data acquisition process which is a series of processes executed when the first data acquisition API 146 receives a first data acquisition request, will be described. Specifically, it is the first data acquisition process when an access request is transmitted from the access API to the access target after the authentication process and the authorization process are performed in FIG.
- the first data acquisition process is a process of acquiring specified data from the shadow 114 managed within the management center 3 using the first data acquisition API 146 .
- 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 first data acquisition API 146 receives the first 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 first data acquisition request. If the designation information is the vehicle ID list, the process proceeds to S120. , the process proceeds 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_ersion” shown 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 sends a shadow access request in which the data designation information indicated in the first data acquisition request is added to the shadow list generated in S150, to the data acquisition unit 119 of the shadow management unit 112. output and terminate the process.
- the index acquisition unit 127 generates a shadow list upon receiving the first data acquisition request from the first 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 first 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 first data acquisition API 146 that made the request.
- a second data acquisition process which is a series of processes executed when the second data acquisition API 147 receives a data acquisition request (hereinafter referred to as a second data acquisition request), will be described. Specifically, it is the second data acquisition process when an access request is transmitted from the access API to the access target after the authentication process and authorization process are performed in FIG.
- the second data acquisition process is a process of specifying a vehicle and acquiring specified data from the specified vehicle.
- the designation information includes vehicle designation information, vehicle authentication information, notification destination information, and data designation information.
- One vehicle ID is indicated in the vehicle designation information.
- the vehicle authentication information is information for authenticating the vehicle on which the edge device 2 is mounted, and consists of the owner ID assigned to the vehicle owner and the vehicle password. Vehicle authentication information is maintained by the vehicle as well as service users authorized to access the vehicle.
- the notification destination information is address information (for example, url) that indicates the notification destination of the encrypted information used to decrypt the encrypted access result (that is, the ciphertext).
- the data specification information is the same as the specification information included in the first data acquisition request.
- 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 vehicle control unit 130 generates encryption information used for encrypting data and decrypting the encrypted data.
- encryption and decryption the same key (that is, common key) may be used, or different keys (that is, encryption key and decryption key) may be used.
- the vehicle control unit 130 creates a encrypted information, especially the key used for decryption (that is, the common key or the decryption key).
- the vehicle control unit 130 In S230, the vehicle control unit 130 generates a vehicle access request by removing the notification destination information from the specification information of the second data acquisition request, and sends the vehicle access request to the target vehicle having the vehicle ID indicated in the vehicle specification information. and transmits a vehicle access request via the communication unit 32 .
- the vehicle control unit 130 determines whether or not there is a response to the vehicle access request from the target vehicle via the communication unit 32. If there is no response, the same steps are repeated to wait. , the process proceeds to S250.
- the vehicle access request here is a data acquisition request from the vehicle, and is processed by the edge device 2 in the vehicle. After performing the authentication process, the edge device 2 acquires vehicle data corresponding to the data designation information from itself or from the ECUs 210, 220, 230, etc. connected via the vehicle I/F 12. FIG. The edge device 2 transmits the acquired vehicle data to the management center 3 via the communication unit 13 . If the vehicle data cannot be obtained from the ECUs 210, 220, 230, etc., an error is transmitted to the management center 3. Vehicle control unit 130 receives these as responses from the vehicle.
- vehicle control unit 130 encrypts the content of the response from the vehicle with the key (that is, the common key or the encryption key) used for encryption generated in S210, and transmits the encrypted response content to the request source. It returns to the second data acquisition API 147 and terminates the processing.
- the content of the response from the vehicle may include, for example, the data specified by the data specifying information and a notification that the authentication in the vehicle has failed.
- the vehicle control unit 130 generates encryption information when a second data acquisition request is input from the second data acquisition API 147 as indicated by an arrow L41. Vehicle control unit 130 then transmits the generated decryption key to the notification destination indicated in the second data acquisition request, as indicated by arrow L42. Along with this, the vehicle control unit 130 transmits to the vehicle a vehicle access request obtained by removing the notification destination information from the designation information of the second data acquisition request, as indicated by an arrow L43. That is, the vehicle control unit 130 transmits the decryption key to the notification destination at the stage of transmitting the vehicle access request to the vehicle.
- the edge device 2 mounted on the vehicle having the vehicle ID indicated in the vehicle designation information receives the vehicle access request, it collates the vehicle authentication information indicated in the vehicle access request with the vehicle authentication information of the own vehicle. to authenticate.
- the edge device 2 sends a response including a notification to that effect to the management center 3.
- the edge device 2 acquires the specified data indicated by the data specifying information from the vehicle and transmits a response including the acquired specified data to the management center 3, as indicated by an arrow L44.
- the specified data may be data possessed by the edge device 2 or may be data acquired from another electronic control device via the vehicle I/F 12 . If the edge device 2 fails to acquire the designated data, the edge device 2 transmits a response including a notification indicating acquisition failure to the management center 3 .
- the vehicle control unit 130 Upon receiving the response, the vehicle control unit 130 encrypts the content of the response and returns it to the second data acquisition API 147, as indicated by an arrow L45.
- the service user who made the second data acquisition request decrypts the encrypted response content acquired via the second data acquisition API 147 using the decryption key sent to the notification destination, thereby obtaining the response content can know
- the notification destination to which the decryption key is sent may be the second data acquisition API 147 itself.
- the vehicle control unit 130 may transmit the encrypted response content to the notification destination.
- the vehicle control API 148 can control the vehicle via the edge device 2 with the same series of processing as the second data acquisition API 147 .
- the control designation information is information for controlling actuators and the like of the vehicle, and designates which actuator is to be controlled and how. For example, the door can be locked or unlocked by sending an instruction to an electronic control device that controls door locking via the vehicle I/F of the edge device.
- the edge device 2 Upon receiving the vehicle access request via the communication unit 13, the edge device 2 performs authentication processing. After that, when the edge device 2 is notified of execution completion or execution failure from the ECUs 210, 220, 230 or the like connected via the vehicle I/F 12, the edge device 2 transmits a response including a notification representing them to the management center 3. do.
- the mobility IoT system 1 corresponds to a mobility service providing system
- the management center 3 corresponds to a mobility service providing server
- the edge device 2 corresponds to an in-vehicle device.
- the shadow storage unit 113 corresponds to the first database
- the index storage unit 125 corresponds to the second database.
- the API provider 122 corresponds to an interface.
- the service user ID and token correspond to user identification information.
- a function of performing authorization processing in the authentication processing unit 144 corresponds to the authorization unit.
- the processing of S210-S220 corresponds to the encryption information generation section
- the processing of S250-S260 corresponds to the encryption section.
- the first data acquisition request corresponds to the first access request
- the second data acquisition request and vehicle control request correspond to the second access request.
- the service user can use the first data acquisition API 146, which is an open API, to acquire the vehicle data of the target vehicle from which data is to be acquired from the shadow 114 of the target vehicle. .
- the service user can use the second data acquisition API 147, which is a closed API, to directly acquire vehicle data possessed by the target vehicle from the target vehicle.
- the second data acquisition API 147 which is a closed API, to directly acquire vehicle data possessed by the target vehicle from the target vehicle.
- the service user can use the second data acquisition API 147, which is a closed API, to directly acquire vehicle data possessed by the target vehicle from the target vehicle.
- the service user can use the second data acquisition API 147, which is a closed API, to directly acquire vehicle data possessed by the target vehicle from the target vehicle.
- the service user can use the second data acquisition API 147, which is a closed API, to directly acquire vehicle data possessed by the target vehicle from the target vehicle.
- real-time data can be acquired instead of past data stored by the shadow 114 . Therefore,
- the access APIs 146 to 148 confirm the service user's access authority (that is, authorization class, authorization object) and deny access beyond the authority. Therefore, it is possible to provide flexible services according to service users.
- the shadow specifying information is extracted from the index 126 extracted by searching the digital twin 123 using the vehicle specifying information and the time specifying information. Generate. Therefore, it is possible to easily acquire arbitrary vehicle data from the present to the past of a specific vehicle, vehicle data of vehicles that existed in a specified area at a specified time, and the like. As a result, the vehicle data acquired by the first data acquisition API 146 can be used, for example, for traffic analysis and prediction services.
- the mechanism for processing authorization for access requests using APIs on the management center 3 side was explained.
- at least one of the management center 3 and the edge device 2 processes the authorization for the access request to the vehicle using the API (that is, the second data acquisition request and the vehicle control request).
- the API that is, the second data acquisition request and the vehicle control request.
- the management center 3 comprises a server-side authorization DB instead of authorization object DB and authorization class DB.
- the server-side authorization DB is provided, for example, in the authorization information storage unit 142 shown in FIG.
- the server-side authorization DB stores "authorization object” and "access authority” in association with "service user ID”.
- "Service user ID” and "authorization object” are the same as those described in the authorization object DB.
- the "access authority” is a list of access targets to which the service user identified by the “service user ID” is permitted to access the vehicle identified by the "authorization object”.
- "Access authority” includes, for example, "Door”, “Trunk”, “ALL”, and the like. "Door” indicates that there is access authority for unlocking and locking the door. “Trunk” indicates that there is access authority for opening and closing the trunk. "ALL” indicates that there is access authority for all access objects that can be provided by the vehicle.
- the access authority that the service user has for vehicle access requests that is, information that defines the accessible range by vehicle access requests is set.
- the second unit 102 of the edge device 2 has a vehicle access API 107 in addition to the GPOS 105 and the second application 106 .
- the vehicle access API 107 receives a vehicle access request from the management center 3 and executes vehicle-side authorization processing (hereinafter referred to as vehicle-side authorization processing).
- vehicle-side authorization processing hereinafter referred to as vehicle-side authorization processing.
- the edge device 2 also includes a vehicle-side authorization DB used for vehicle-side authorization processing.
- the vehicle-side authorization DB is provided, for example, in the storage unit 14 or the flash memory 25 shown in FIG.
- the vehicle-side authorization DB stores "authorized users” and "access authority” in association with "service user IDs".
- the "authorized user” lists the IDs of vehicle users who may actually use the vehicle (hereinafter referred to as vehicle user IDs). In other words, a plurality of “authorized users” may be associated with one "service user ID”.
- “Access authority” is the same as the explanation for the server-side authorization DB. "Access authority” is set for each "authorized user”.
- the access authority possessed by the vehicle user regarding the vehicle access request that is, the range accessible by the vehicle access request. Defined information is set.
- the requester is, for example, a vehicle user using a vehicle.
- a vehicle user may be a vehicle owner or a user who rents a vehicle.
- the requestor is identified by a vehicle user ID.
- a service provided by the service providing server 4 is identified by a service user ID.
- the service providing server 4 Upon receiving the vehicle access request from the requester, the service providing server 4 accesses the login API 145 provided by the API providing unit 122 of the management center 3 and executes authentication processing.
- the authentication process procedure is the same as in the first embodiment, as indicated by arrows L21 and L22.
- the service providing server 4 uses the access API provided by the API providing unit 122 as indicated by an arrow L51 to request vehicle access (i.e., acquire the second data) in response to the request from the requester. request or vehicle control request) to the management center 3.
- the vehicle access request includes a token granted by authentication processing, a vehicle user ID, vehicle designation information, and data designation information or control designation information.
- the vehicle designation information is information for designating a vehicle to be accessed (hereinafter, designated vehicle).
- Data designation information or control designation information is information for specifying a specific access target. Access targets include vehicle data and various in-vehicle devices.
- 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 vehicle access request. Next, the authentication processing unit 144 searches the server-side authorization DB of the authorization information storage unit 142 to extract the "authorization object" and "access authority” associated with the specified "service user ID”. Further, the authentication processing unit 144 determines whether or not the extracted "authorization object” includes the specified vehicle indicated in the vehicle access request, that is, whether access to the specified vehicle is permitted in the service provided by the service user. Determine whether or not Further, the authentication processing unit 144 determines whether or not the extracted "access authority” includes the access target indicated in the vehicle access request, that is, whether access to the access target is permitted in the service provided by the service user. Determine whether or not
- the authentication processing unit 144 determines that it is not authorized. If it is determined that the request is not authorized, the authentication processing unit 144 notifies the requester of access denial on the grounds that the service user is outside the authority of the service user via the access API and the service providing server 4, as indicated by an arrow L52.
- the vehicle access API 107 of the edge device 2 mounted on the designated vehicle executes vehicle-side authorization processing.
- the second unit 102 refers to the vehicle-side authorization DB to determine the "authorized user" and "access authority" associated with the "service user ID” indicated in the vehicle access request. Extract. Next, the second unit 102 determines whether the extracted "authorized user” includes the vehicle user ID of the requester indicated in the access request, i.e. whether the requester is permitted to access the designated vehicle. Determine whether or not In addition, the second unit 102 determines whether or not the extracted "access authority" includes the access target indicated in the access request, that is, whether or not the requester is permitted to access the access target. judge.
- the second unit 102 determines that the request is not authorized. If the second unit 102 determines that the request is not authorized, the second unit 102 transmits an access denial to the management center 3 via the vehicle access API 107, as indicated by the arrow L54. Upon receiving the access denial, the management center 3 notifies the requester of the access denial via the access API and the service providing server 4, as indicated by an arrow L55.
- the second unit 102 determines that the request is authorized. If it is determined to be authorized, second unit 102 transmits a control instruction to the access target as indicated by arrow L56, and receives an access result from the access target as indicated by arrow L57. Furthermore, the second unit 102 transmits the access result to the management center 3 via the vehicle access API 107, as indicated by an arrow L58. Upon receiving the access result, the management center 3 notifies the requester of the access result via the access API and the service providing server 4, as indicated by an arrow L59.
- the access result notification may be encrypted as described in the first embodiment.
- the service providing server 4 Upon receiving the vehicle access request from the requester, the service providing server 4 accesses the login API 145 provided by the API providing unit 122 of the management center 3 and executes authentication processing.
- the authentication process procedure is the same as in the first embodiment, as indicated by arrows L21 and L22.
- the service providing server 4 uses the access API provided by the API providing unit 122 to send a vehicle access request to the management center 3 in response to the request from the requester, as indicated by an arrow L51. output.
- the management center 3 Upon receiving the access request from the service providing server 4, the management center 3 transmits the vehicle access request to the specified vehicle via the vehicle control unit 130 as indicated by the arrow L53 without executing the center side authorization process. .
- the vehicle access API 107 of the edge device 2 mounted on the designated vehicle executes vehicle-side authorization processing.
- the procedure after transmitting the result of vehicle-side authorization processing to the management center 3 is the same as the procedure described in the two-stage authorization above, as indicated by arrows L54 to L59.
- the vehicle side authorization processing is omitted.
- the vehicle-side authorization processing is omitted in the sequence shown in FIG. 30, and a series of sequences when the vehicle-side authorization processing determines that the vehicle is not authorized is omitted.
- the authorization information storage unit 142 provided with the server-side authorization DB corresponds to the server-side storage unit
- the authentication processing unit 144 that executes server-side authorization processing corresponds to the server-side authorization unit
- the storage unit 14 or the flash memory 25 provided with the vehicle-side authorization DB corresponds to the vehicle-side storage unit
- the vehicle API 107 that executes the vehicle-side authorization process corresponds to the vehicle-side authorization unit.
- the content of the server-side authorization DB corresponds to service-specific authorization information
- the content of the vehicle-side authorization DB corresponds to user-specific authorization information.
- the management center 3 performs authorization processing (that is, server-side authorization processing) for each service user, and the edge device 2 performs authorization processing (for each vehicle user). That is, vehicle side authorization processing) is performed.
- authorization processing that is, server-side authorization processing
- the edge device 2 performs authorization processing (for each vehicle user). That is, vehicle side authorization processing) is performed.
- two-stage authorization in which both the server-side authorization process and the vehicle-side authorization process are performed, access denial in the vehicle-side authorization process can be suppressed, and the amount of communication between the management center 3 and the edge device 2 can be suppressed.
- the processing load on the management center 3 can be reduced.
- the center side single authorization the processing load on the edge device 2 can be reduced.
- control unit 31 and techniques thereof described in this embodiment were provided by configuring a processor and memory programmed to perform one or more functions embodied by a computer program. It may also be implemented by a dedicated computer. Alternatively, the controller 31 and techniques described herein may be implemented by a dedicated computer provided by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the control unit 31 and techniques described in this embodiment may be 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. It may also be implemented by one or more dedicated computers configured in combination. 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 Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Economics (AREA)
- Remote Sensing (AREA)
- General Health & Medical Sciences (AREA)
- Radar, Positioning & Navigation (AREA)
- Development Economics (AREA)
- Accounting & Taxation (AREA)
- Operations Research (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- Human Resources & Organizations (AREA)
- Marketing (AREA)
- Primary Health Care (AREA)
- Strategic Management (AREA)
- Tourism & Hospitality (AREA)
- Theoretical Computer Science (AREA)
- Traffic Control Systems (AREA)
Abstract
Description
[1-1.システム概要]
本実施形態のモビリティIoTシステム1は、図1に示すように、複数のエッジ装置2と、管理センター3と、サービス提供サーバ4とを備える。IoTは、Internet of Thingsの略である。
[1-2-1.装置構成]
エッジ装置2は、図2に示すように、マイクロコンピュータ11と、車両インタフェース(以下、車両I/F)12と、通信部13と、記憶部14とを備える。
エッジ装置2は、ROM23に格納されたプログラムを第1コア21が実行することにより実現される機能ブロックとして、図3に示すように、第1ユニット101を備える。エッジ装置2は、ROM23に格納されたプログラムを第2コア22が実行することにより実現される機能ブロックとして、第2ユニット102を備える。
エッジ装置2が車両データを収集して自発的に管理センター3に送信する一連の処理について説明する。
[1-3―1.装置構成]
管理センター3は、図10に示すように、制御部31と、通信部32と、記憶部33とを備える。
管理センター3は、ROM42に格納されたプログラムをCPU41が実行することにより実現される機能ブロックとして、図11に示すように、車両側ユニット110と、サービス側ユニット120とを備える。車両へのアクセスに近い側の機能ブロックが車両側ユニット110であり、サービス提供サーバ4からのアクセスに近い側の機能ブロックがサービス側ユニット120である。これら2つの機能ブロックは、疎結合に構成される。
図12に示すように、シャドウ管理部112は、エッジ装置2から取得した車両データを蓄積する機能を実現する構成として、シャドウ作成部115と、シャドウ記憶部113と、最新インデックス作成部116と、最新インデックス記憶部117とを備える。
図5および図12に示すように、サービス側ユニット120は、API提供部122を備える。API提供部122は、管理センター3が有する機能を、サービス提供サーバ4等の外部のサービス提供者に利用させるために用意されたインタフェースである。以下では、API提供部122等を利用するモビリティIoTシステム1のユーザをサービスユーザという。サービスユーザは、例えば車両トランクへの宅配を行うサービス事業者である。
第1データ取得API146が第1データ取得要求を受け付けた場合に実行される一連の処理である第1データ取得処理について説明する。具体的には、図18において認証処理および認可処理が行われた後、アクセスAPIからアクセス対象へアクセス要求が送信されたときの第1データ取得処理である。第1データ取得処理は、第1データ取得API146を用いて、管理センター3内で管理されるシャドウ114から指定したデータを取得する処理である。
第2データ取得API147がデータ取得要求(以下、第2データ取得要求)を受け付けた場合に実行される一連の処理である第2データ取得処理について説明する。具体的には、図18において認証処理および認可処理が行われた後、アクセスAPIからアクセス対象へアクセス要求が送信されたときの第2データ取得処理である。第2データ取得処理は、車両を指定して、その指定した車両から指定したデータを取得する処理である。
以上説明した実施形態において、モビリティIoTシステム1はモビリティサービス提供システムに相当し、管理センター3はモビリティサービス提供サーバに相当し、エッジ装置2は車載機に相当する。シャドウ記憶部113は第1データベースに相当し、インデックス記憶部125は第2データベースに相当する。API提供部122はインタフェース部に相当する。サービスユーザIDおよびトークンはユーザ識別情報に相当する。認証処理部144において認可処理を実施する機能が認可部に相当する。S210~S220の処理は暗号情報生成部に相当し、S250~S260の処理は暗号化部に相当する。第1データ取得要求が第1アクセス要求に相当し、第2データ取得要求および車両制御要求が第2アクセス要求に相当する。
以上詳述した実施形態によれば、以下の効果を奏する。
[2-1.第1実施形態との相違点]
第2実施形態は、基本的な構成は第1実施形態と同様であるため、相違点について以下に説明する。なお、第1実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。
管理センター3は、認可オブジェクトDBおよび認可クラスDBの代わりにサーバ側認可DBを備える。サーバ側認可DBは、例えば、図12に示した認可情報記憶部142に設けられる。
図28に示すように、第2実施形態では、エッジ装置2の第2ユニット102が、GPOS105および第2アプリケーション106に加えて、車両アクセスAPI107を備える。
管理センター3による認可処理(以下、サーバ側認可処理)およびエッジ装置2による認可処理(すなわち、車側認可処理)をいずれも実行する2段階認可の手順を、図30のシーケンス図を用いて説明する。
認可処理をエッジ装置2でのみ実行する車側単独認可の手順を、図31のシーケンス図を用いて説明する。
認可処理をエッジ装置2でのみ実行するセンター側単独認可の手順について説明する。
以上説明した実施形態において、サーバ側認可DBが設けられる認可情報記憶部142がサーバ側記憶部に相当し、サーバ側認可処理を実行する認証処理部144がサーバ側認可部に相当する。車側認可DBが設けられる記憶部14又はフラッシュメモリ25が車側記憶部に相当し、車側認可処理を実行する車両API107が車側認可部に相当する。サーバ側認可DBの内容がサービス別認可情報に相当し、車側認可DBの内容がユーザ別認可情報に相当する。
以上詳述した第2実施形態によれば、前述した第1実施形態の効果(1a)を奏し、さらに、以下の効果を奏する。
以上、本開示の一実施形態について説明したが、本開示は上記実施形態に限定されるものではなく、種々変形して実施することができる。
Claims (13)
- 車両に搭載され前記車両から取得されるデータである車両データを収集するように構成された車載機(2)と、
前記車載機との無線通信を行うように構成されたモビリティサービス提供サーバ(3)と、
を備え、
前記車載機は、繰り返し前記車両データを前記モビリティサービス提供サーバに自発的に送信すると共に、前記モビリティサービス提供サーバからの要求に応じて前記車両データを前記モビリティサービス提供サーバに送信するように構成され、
前記モビリティサービス提供サーバは、
前記無線通信により前記車載機から取得した所定時点ごとの前記車両データを記憶するように構成された記憶部(113,125)と、
外部からの第1アクセス要求および第2アクセス要求を受け付けるように構成されたインタフェース部(122)と、
前記インタフェース部が前記第1アクセス要求を受け付けた場合、前記記憶部から前記車両データを取得し、前記インタフェース部を介して要求元に提供するように構成された第1制御部(119,127)と、
前記インタフェース部が前記第2アクセス要求を受け付けた場合、前記車載機にアクセスすることで該車載機から前記車両データを含むアクセス結果を取得し、前記インタフェース部を介して要求元に提供するように構成された第2制御部(130)と、
を備えるモビリティサービス提供システム。 - 請求項1に記載のモビリティサービス提供システムであって、
前記第2制御部は、前記車両データを前記車載機から取得するため前記車載機に送信する取得要求と共に、前記車載機に予め割り当てられた車両認証情報を送信するように構成され、
前記車載機は、前記車両認証情報による認証に成功した場合に、前記取得要求によって要求された前記車両データを前記モビリティサービス提供サーバに送信するように構成された、
モビリティサービス提供システム。 - 請求項1に記載のモビリティサービス提供システムであって、
前記モビリティサービス提供サーバを利用したモビリティサービスの提供元毎に、前記第2アクセス要求によるアクセス可能な範囲を規定するサービス別認可情報を記憶するように構成されたサーバ側記憶部(142)と、
前記第2アクセス要求を受け付けた場合、前記サービス別認可情報を参照して、前記モビリティサービスの提供元が、前記第2アクセス要求に示されたアクセス対象となる車両である対象車両へのアクセス権限を有するか否かを判定し、前記アクセス権限を有すると判定された場合に、前記対象車両に搭載された前記車載機へのアクセスを認可するように構成されたサーバ側認可部(144)と、
を更に備え、
前記車載機は、
前記対象車両へのアクセスを要求する可能性がある車両ユーザ毎に、前記第2アクセス要求によるアクセス可能な範囲を規定するユーザ別認可情報を記憶するように構成された車側記憶部(14,25)と、
前記モビリティサービス提供サーバから前記第2アクセス要求を受け付けた場合、前記ユーザ別認可情報を参照して、前記第2アクセス要求を要求した車両ユーザが、前記第2アクセス要求に示されたアクセス対象に対する前記アクセス権限を有するか否かを判定し、前記アクセス権限を有すると判定された場合に、前記アクセス対象へのアクセスを認可するように構成された車側認可部(107)と、
を更に備える、
モビリティサービス提供システム。 - 請求項1に記載のモビリティサービス提供システムであって、
前記車載機は、
前記第2アクセス要求に示されたアクセス対象となる車両である対象車両へのアクセスを要求する可能性がある車両ユーザ毎に、前記第2アクセス要求によるアクセス可能な範囲を規定するユーザ別認可情報を記憶するように構成された車側記憶部(14,25)と、
前記モビリティサービス提供サーバから前記第2アクセス要求を受け付けた場合、前記ユーザ別認可情報を参照して、前記第2アクセス要求を要求した車両ユーザが、前記第2アクセス要求に示されたアクセス対象に対するアクセス権限を有するか否かを判定し、前記アクセス権限を有すると判定された場合に、前記アクセス対象へのアクセスを認可するように構成された車側認可部(107)と、
を更に備える、
モビリティサービス提供システム。 - 請求項1から請求項4までのいずれか1項に記載のモビリティサービス提供システムであって、
前記車載機が送信する前記車両データには、前記車両から取得されるローデータを加工した加工データが含まれ、前記モビリティサービス提供サーバからの要求に応じて前記車載機が送信する前記車両データには、加工される前の前記ローデータが含まれる
モビリティサービス提供システム。 - 車両に搭載された車載機から提供される車両データを記憶するように構成された記憶部と、
外部から第1アクセス要求および第2アクセス要求を受け付けるように構成されたインタフェース部と、
前記インタフェース部が前記第1アクセス要求を受け付けた場合、前記記憶部から前記車両データを取得し、前記インタフェース部を介して要求元に提供するように構成された第1制御部と、
前記インタフェース部が前記第2アクセス要求を受け付けた場合、前記車載機にアクセスすることで該車載機から前記車両データを含むアクセス結果を取得し、前記インタフェース部を介して要求元に提供するように構成された第2制御部と、
を備えるモビリティサービス提供サーバ。 - 請求項6に記載のモビリティサービス提供サーバであって、
前記第1アクセス要求および前記第2アクセス要求には、当該モビリティサービス提供サーバを利用したサービスを提供するサービスユーザを識別するユーザ識別情報が含まれ、
前記インタフェース部は、
前記ユーザ識別情報を、取得可能な前記車両データの範囲を表す認可クラスに対応づけて記憶する認可情報記憶部(142)と、
前記第1アクセス要求および前記第2アクセス要求に示された前記ユーザ識別情報に基づいて、前記認可情報記憶部から取得される前記認可クラスに従って、前記第1アクセス要求および前記第2アクセス要求に示された取得の対象となる前記車両データが、該認可クラスによって認可された権限の範囲外である場合に、取得要求の受け付けを拒否する認可部(144)と、
を更に備えるモビリティサービス提供サーバ。 - 請求項6または請求項7に記載のモビリティサービス提供サーバであって、
前記記憶部は、
前記車載機から自発的に送信され、同時刻における前記車載機を搭載した前記車両の状態を表す前記車両データの一群をシャドウとし、該シャドウが生成された時間を表す情報をシャドウバージョンとして記憶するように構成された第1データベース(113)と、
前記第1データベースに蓄積された前記シャドウのそれぞれに対応して生成されるインデックスを記憶するように構成された第2データベース(125)と、
を備え、
前記インデックスは、前記シャドウに属する前記車両データの提供元となった前記車両を提供元車両として、前記シャドウから抽出される前記提供元車両を特定する車両識別情報と、前記提供元車両の位置情報と、前記シャドウバージョンとを含み、
前記第1制御部は、前記第1アクセス要求に示された取得条件に該当する前記インデックスを、前記第2データベースから抽出し、抽出された前記インデックスから特定される前記シャドウを前記第1データベースから取得するように構成された、
モビリティサービス提供サーバ。 - 請求項8に記載のモビリティサービス提供サーバであって、
前記第1制御部は、前記取得条件に時刻または時間範囲を指定する時間指定情報が含まれる場合、前記シャドウバージョンが前記時間指定情報に該当する前記インデックスを、前記第2データベースから抽出するように構成された
モビリティサービス提供サーバ。 - 請求項8または請求項9に記載のモビリティサービス提供サーバであって、
前記第1制御部は、前記取得条件に地理的領域を指定するエリア指定情報が含まれる場合、前記位置情報が前記エリア指定情報で指定されたエリア内を示す前記インデックスを、前記第2データベースから抽出するように構成された
モビリティサービス提供サーバ。 - 請求項6から請求項10までのいずれか一項に記載のモビリティサービス提供サーバであって、
前記第2制御部は、
前記インタフェース部が前記第2アクセス要求を受け付けた場合、暗号情報を生成して、前記第2アクセス要求で指定された通知先に、前記暗号情報を用いて生成された暗号文の復号に用いる鍵を送信する暗号情報生成部(S210~S220)と、
前記第2アクセス要求に従って、前記車載機に要求することで取得した前記車両データを、前記暗号情報生成部にて生成された前記暗号情報を用いて暗号化して前記インタフェース部を介して要求元に提供する暗号化部(S250~S260)と、
を備える
モビリティサービス提供サーバ。 - 車両に搭載された車載機から提供される車両データを記憶するように構成された記憶部と、外部から第1アクセス要求および第2アクセス要求を受け付けるように構成されたインタフェース部と、を備えるモビリティサービス提供サーバにおける車両データ提供方法であって、
前記インタフェース部が前記第1アクセス要求を受け付けた場合、前記記憶部から前記車両データを取得し、前記インタフェース部を介して要求元に提供し、
前記インタフェース部が前記第2アクセス要求を受け付けた場合、前記車載機にアクセスすることで該車載機から前記車両データを含むアクセス結果を取得し、前記インタフェース部を介して要求元に提供する
車両データ提供方法。 - 車両に搭載された車載機から提供される車両データを記憶するように構成された記憶部、および外部から第1アクセス要求および第2アクセス要求を受け付けるように構成されたインタフェース部と共にモビリティサービス提供サーバを構成するコンピュータを、
前記インタフェース部が前記第1アクセス要求を受け付けた場合、前記記憶部から前記車両データを取得し、前記インタフェース部を介して要求元に提供する第1制御部、
前記インタフェース部が前記第2アクセス要求を受け付けた場合、前記車載機にアクセスすることで該車載機から前記車両データを含むアクセス結果を取得し、前記インタフェース部を介して要求元に提供する第2制御部
として機能させるためのプログラム。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202280046531.7A CN117581280A (zh) | 2021-07-02 | 2022-06-28 | 移动性服务提供系统、移动性服务提供服务器、车辆数据提供方法、程序 |
JP2023531991A JPWO2023277032A1 (ja) | 2021-07-02 | 2022-06-28 | |
US18/397,605 US20240129735A1 (en) | 2021-07-02 | 2023-12-27 | Mobility service providing system, mobility service providing server, vehicle data providing method, and storage medium |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021-110905 | 2021-07-02 | ||
JP2021110905 | 2021-07-02 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US18/397,605 Continuation US20240129735A1 (en) | 2021-07-02 | 2023-12-27 | Mobility service providing system, mobility service providing server, vehicle data providing method, and storage medium |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2023277032A1 true WO2023277032A1 (ja) | 2023-01-05 |
Family
ID=84690061
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2022/025812 WO2023277032A1 (ja) | 2021-07-02 | 2022-06-28 | モビリティサービス提供システム、モビリティサービス提供サーバ、車両データ提供方法、プログラム |
Country Status (4)
Country | Link |
---|---|
US (1) | US20240129735A1 (ja) |
JP (1) | JPWO2023277032A1 (ja) |
CN (1) | CN117581280A (ja) |
WO (1) | WO2023277032A1 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2023064054A (ja) * | 2021-10-25 | 2023-05-10 | ウーブン・アルファ株式会社 | 運転者ではないユーザーに運転情報を提供する方法及びシステム |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170078472A1 (en) * | 2011-11-16 | 2017-03-16 | Autoconnect Holdings Llc | On board vehicle presence reporting module |
US20170124871A1 (en) * | 2015-10-30 | 2017-05-04 | Faraday&Future Inc. | System and method for vehicle data communication |
JP2019530917A (ja) * | 2016-07-25 | 2019-10-24 | スイス リインシュランス カンパニー リミテッド | テレマティックス接続サーチエンジンを使用する動的なスコアベースの危険性測定及び集約のためのインテリジェントな自己適応型車両用装置及びその対応する方法 |
JP2020013557A (ja) * | 2018-06-13 | 2020-01-23 | トヨタ自動車株式会社 | 車両リスク評価用のデジタルツイン |
JP2020184322A (ja) * | 2019-03-29 | 2020-11-12 | トヨタ モーター ノース アメリカ,インコーポレイティド | 利害関係者との間における車両データの共有 |
-
2022
- 2022-06-28 WO PCT/JP2022/025812 patent/WO2023277032A1/ja active Application Filing
- 2022-06-28 JP JP2023531991A patent/JPWO2023277032A1/ja active Pending
- 2022-06-28 CN CN202280046531.7A patent/CN117581280A/zh active Pending
-
2023
- 2023-12-27 US US18/397,605 patent/US20240129735A1/en active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170078472A1 (en) * | 2011-11-16 | 2017-03-16 | Autoconnect Holdings Llc | On board vehicle presence reporting module |
US20170124871A1 (en) * | 2015-10-30 | 2017-05-04 | Faraday&Future Inc. | System and method for vehicle data communication |
JP2019530917A (ja) * | 2016-07-25 | 2019-10-24 | スイス リインシュランス カンパニー リミテッド | テレマティックス接続サーチエンジンを使用する動的なスコアベースの危険性測定及び集約のためのインテリジェントな自己適応型車両用装置及びその対応する方法 |
JP2020013557A (ja) * | 2018-06-13 | 2020-01-23 | トヨタ自動車株式会社 | 車両リスク評価用のデジタルツイン |
JP2020184322A (ja) * | 2019-03-29 | 2020-11-12 | トヨタ モーター ノース アメリカ,インコーポレイティド | 利害関係者との間における車両データの共有 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2023064054A (ja) * | 2021-10-25 | 2023-05-10 | ウーブン・アルファ株式会社 | 運転者ではないユーザーに運転情報を提供する方法及びシステム |
JP7482960B2 (ja) | 2021-10-25 | 2024-05-14 | ウーブン・バイ・トヨタ株式会社 | 運転者ではないユーザーに運転情報を提供する方法及びシステム |
US12067816B2 (en) | 2021-10-25 | 2024-08-20 | Woven By Toyota, Inc. | Method and system for providing driving information to non-driver user |
Also Published As
Publication number | Publication date |
---|---|
JPWO2023277032A1 (ja) | 2023-01-05 |
CN117581280A (zh) | 2024-02-20 |
US20240129735A1 (en) | 2024-04-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US12046085B2 (en) | System, method, and apparatus for managing vehicle data collection | |
US7401233B2 (en) | Method, system, and apparatus for dynamic data-driven privacy policy protection and data sharing | |
CN109791566B (zh) | 控制加密车载数据访问的系统和方法 | |
JP7043736B2 (ja) | 車両用電子制御装置及び車両用サービス管理システム | |
CN106874461A (zh) | 一种工作流引擎支持多数据源配置安全访问系统及方法 | |
US20240129735A1 (en) | Mobility service providing system, mobility service providing server, vehicle data providing method, and storage medium | |
US8484309B2 (en) | Owner controlled access to shared data resource | |
CN115443637A (zh) | 用于管理车辆数据收集的系统、方法和装置 | |
CN108734017B (zh) | 驾驶数据共享方法和装置、系统和计算机存储介质 | |
CN102870093A (zh) | 利用虚拟化和证明来远程维护电子网络中多个客户端的系统和方法 | |
CN112118221B (zh) | 基于区块链的面向隐私数据共享的权能访问控制方法 | |
US11902374B2 (en) | Dynamic vehicle data extraction service | |
US20230169805A1 (en) | Fleet data collection using a unified model to collect data from heterogenous vehicles | |
CN113347133A (zh) | 车载设备的认证方法及装置 | |
KR101803651B1 (ko) | 차량 클라우드 서비스 접속을 위한 인증 방법 | |
Kim et al. | Introducing attribute-based access control to AUTOSAR | |
WO2023277031A1 (ja) | モビリティサービス基盤サーバ、モビリティサービス提供システム、車両アクセス制御方法、プログラム | |
WO2023277030A1 (ja) | モビリティサービス基盤サーバ、モビリティサービス提供システム、車両アクセス制御方法、プログラム | |
JPWO2023277032A5 (ja) | ||
WO2023277185A1 (ja) | 車載装置、データ生成方法、データ生成プログラムおよび車両システム | |
WO2023276894A1 (ja) | センター、管理方法および管理プログラム | |
WO2023276957A1 (ja) | センター、管理システム、管理方法および管理プログラム | |
WO2023276960A1 (ja) | システム、センター、及び制御プログラム | |
JP2005295377A (ja) | プログラム配信システム、プログラム配信装置および車載ゲートウェイ装置 | |
WO2023097157A1 (en) | Dynamic vehicle data extraction service |
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: 22833178 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2023531991 Country of ref document: JP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 202280046531.7 Country of ref document: CN |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 22833178 Country of ref document: EP Kind code of ref document: A1 |