WO2023276957A1 - センター、管理システム、管理方法および管理プログラム - Google Patents

センター、管理システム、管理方法および管理プログラム Download PDF

Info

Publication number
WO2023276957A1
WO2023276957A1 PCT/JP2022/025586 JP2022025586W WO2023276957A1 WO 2023276957 A1 WO2023276957 A1 WO 2023276957A1 JP 2022025586 W JP2022025586 W JP 2022025586W WO 2023276957 A1 WO2023276957 A1 WO 2023276957A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
data
shadow
side unit
unit
Prior art date
Application number
PCT/JP2022/025586
Other languages
English (en)
French (fr)
Inventor
正俊 小見山
顕匠 滝
凌非 謝
繁 梶岡
真紀子 田内
Original Assignee
株式会社デンソー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社デンソー filed Critical 株式会社デンソー
Priority to JP2023531944A priority Critical patent/JPWO2023276957A1/ja
Priority to CN202280046997.7A priority patent/CN117616479A/zh
Publication of WO2023276957A1 publication Critical patent/WO2023276957A1/ja
Priority to US18/398,490 priority patent/US20240126937A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/10—Geometric CAD
    • G06F30/15—Vehicle, aircraft or watercraft design
    • 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
    • G06Q10/00—Administration; Management
    • 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/10—Services

Definitions

  • the present disclosure relates to a center for managing vehicle data, a management system, a management method, and a management program.
  • 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.
  • Vehicle data that can be obtained through CAN communication does not have a format that is easy for users who use vehicle data to use. This is because, for example, the data that can be acquired from the CAN communication frame differs depending on the vehicle manufacturer, vehicle type, shipping time, and the like. As a result of the inventor's detailed study, users who want to handle vehicle data need specialized knowledge such as the structure of CAN communication frames and buses through which data flows, and cannot easily access vehicle data. problem was found.
  • This disclosure facilitates the use of vehicle data.
  • One aspect of the present disclosure is a center comprising a vehicle-side unit and a service-side unit.
  • the vehicle-side unit is connected to multiple in-vehicle devices mounted on each of multiple vehicles so that data communication is possible.
  • the service side unit is capable of data communication with the service providing unit.
  • the vehicle side unit is equipped with a shadow creation section.
  • the shadow creating unit is configured to repeatedly acquire a vehicle data group formed in a first data structure in which a plurality of vehicle data are classified into respective categories from each of the plurality of in-vehicle devices. Then, the shadow creation unit creates, as a shadow, a vehicle data group to which vehicle identification information for identifying the vehicle and timing identification information for identifying the timing at which the vehicle data is acquired is added to each vehicle, and the shadow is generated on the vehicle side. It is configured to be stored in a first data structure in a shadow store provided in the unit.
  • the service-side unit is equipped with an instruction unit.
  • the instruction unit receives, from the service providing unit, a request instructing acquisition of the corresponding vehicle data with specific vehicle data or a specific category as designated data among a plurality of vehicle data constituting the vehicle data group, Based on the request, it is configured to instruct the vehicle-side unit to acquire specified data of a predetermined vehicle at a predetermined time from the shadow storage section of the vehicle-side unit.
  • shadows have a data structure classified by multiple categories, and multiple vehicle data are arranged in a hierarchical structure. Therefore, the center of the present disclosure can access a plurality of vehicle data that make up the shadow by the data name of specific vehicle data or the category name of a specific category, facilitating the use of vehicle data. be able to.
  • a management system (1) comprising a plurality of in-vehicle devices mounted in each of a plurality of vehicles to acquire vehicle data from the vehicles, and a center managing the vehicle data.
  • the center includes a vehicle-side unit and a service-side unit.
  • the vehicle-side unit also includes a shadow creating section.
  • the service-side unit also includes an instruction section.
  • the management system of the present disclosure configured in this manner is a system that includes the center of the present disclosure, and can obtain the same effects as the center of the present disclosure.
  • Yet another aspect of the present disclosure is a management method performed at a center comprising a vehicle-side unit and a service-side unit.
  • the vehicle-side unit repeatedly acquires, from each of the plurality of in-vehicle devices, a vehicle data group formed in a first data structure in which a plurality of vehicle data are classified into respective categories, and identifies the vehicle for each vehicle.
  • a group of vehicle data to which identification information and timing identification information for identifying the timing at which the vehicle data is acquired is created as a shadow, and stored in a shadow storage section provided in the vehicle-side unit in the form of a first data structure. memorize with
  • the service-side unit receives from the service providing unit a request instructing acquisition of the corresponding vehicle data with specific vehicle data or a specific category as designated data among the plurality of vehicle data constituting the vehicle data group. Then, based on the request, the vehicle-side unit is instructed to acquire specified data of a predetermined vehicle at a predetermined time from the shadow storage section of the vehicle-side unit.
  • the management method of the present disclosure is a method executed by the center of the present disclosure, and by executing the method, the same effects as those of the center of the present disclosure can be obtained.
  • Yet another aspect of the present disclosure is a management program that causes a computer of a center that includes a vehicle-side unit and a service-side unit to function as a shadow creating section and an instruction section.
  • a computer controlled by the management program of the present disclosure can constitute part of the center of the present disclosure, and can obtain the same effects as the center of the present disclosure.
  • FIG. 1 is a block diagram showing the configuration of a mobility IoT system;
  • FIG. It is a block diagram which shows the structure of a data collection device.
  • 3 is a block diagram showing the configuration of a management center;
  • FIG. It is a functional block diagram which shows the functional structure of a data collection device.
  • 3 is a functional block diagram showing the functional configuration of a management center;
  • FIG. It is a figure which shows the structure of a CAN frame.
  • It is a flow chart which shows data normalization processing.
  • 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. 4 is a sequence diagram showing a procedure for creating standardized vehicle data; 4 is a flowchart showing the first half of data transmission processing; FIG. 11 is a flowchart showing the second half of data transmission processing; FIG. 4 is a timing chart showing data transmission timing; 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. It is a figure which shows the specific example of a request.
  • FIG. 2 is a block diagram showing a connection state of an ECU mounted on a vehicle; FIG.
  • the mobility IoT system 1 of this embodiment includes a plurality of data collection 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 data collection 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 data collecting 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 with different service contents.
  • These service providing servers 4 may be configured on-premises, may be configured in the cloud, or may be configured as physically the same server as the management center 3 .
  • the data collection device 2 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.
  • the power supply voltage input port includes a +B voltage port to which +B voltage is input and an IG voltage port to which IG voltage is input.
  • the vehicle I/F 12 includes a DCDC converter and a protection circuit including a Zener diode. As a result, the power supply voltage input port is configured to be compatible with both the input of the vehicle voltage of 12V and the input of the vehicle voltage of 48V.
  • a CAN communication port is a port for sending 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 communication unit 13 performs data communication with the management center 3 via the wide area wireless communication network NW.
  • the storage unit 14 is a storage device for storing various data.
  • the vehicle is equipped with one ECU 210, multiple ECUs 220, multiple ECUs 230, an external communication device 240, and an internal communication network 250.
  • ECU is an abbreviation for Electronic Control Unit.
  • the ECU 210 realizes coordinated control of the vehicle as a whole by integrating the plurality of ECUs 220 .
  • the ECU 220 is provided for each domain divided according to the function of the vehicle, and mainly controls a plurality of ECUs 230 existing within that domain. Each ECU 220 is connected to a subordinate ECU 230 via a lower-layer network (for example, CAN) provided individually.
  • the ECU 220 has a function of centrally managing access rights and the like for the ECU 230 under its control and performing user authentication and the like. Domains are, for example, powertrain, body, chassis and cockpit.
  • the ECU 230 connected to the ECU 220 belonging to the powertrain domain includes, for example, an ECU 230 that controls the engine, an ECU 230 that controls the motor, an ECU 230 that controls the battery, and the like.
  • the ECUs 230 connected to the ECU 220 belonging to the body domain include, for example, the ECU 230 that controls the air conditioner, the ECU 230 that controls the doors, and the like.
  • the ECU 230 connected to the ECU 220 belonging to the chassis domain includes, for example, an ECU 230 that controls brakes, an ECU 230 that controls steering, and the like.
  • the ECU 230 connected to the ECU 220 belonging to the cockpit domain includes, for example, the ECU 230 that controls the display of meters and navigation, and the ECU 230 that controls input devices operated by the vehicle occupants.
  • the vehicle-external communication device 240 performs data communication with a vehicle-external communication device (for example, a cloud server) via the wide area wireless communication network NW.
  • a vehicle-external communication device for example, a cloud server
  • the in-vehicle communication network 250 includes CAN FD and Ethernet.
  • CAN FD is an abbreviation for CAN with Flexible Data Rate.
  • the CAN FD connects the ECU 210 with each ECU 220 and the external communication device 240 via a bus.
  • Ethernet individually connects ECU 210 to each ECU 220 and external communication device 240 .
  • the ECU 210 is an electronic control unit mainly composed of a microcomputer including a CPU 210a, a ROM 210b and a RAM 210c.
  • Various functions of the microcomputer are realized by the CPU 210a executing a program stored in a non-transitional substantive recording medium.
  • the ROM 210b corresponds to the non-transitional substantive recording medium storing the program.
  • a method corresponding to the program is executed.
  • a part or all of the functions executed by the CPU 210a may be configured as hardware using one or a plurality of ICs or the like. Further, the number of microcomputers constituting ECU 210 may be one or more.
  • Each of the ECU 220, the ECU 230, and the external communication device 240 is an electronic control device, similar to the ECU 210, mainly composed of a microcomputer having a CPU, a ROM, a RAM, and the like. Further, the number of microcomputers constituting ECU 220, ECU 230 and external communication device 240 may be one or more.
  • ECU 220 is an ECU that controls one or more ECUs 230
  • ECU 210 is an ECU that controls one or more ECUs 220 or controls ECUs 220 and 230 of the entire vehicle including external communication device 240 .
  • the data collection device 2 is connected to the ECU 210 so that data communication with the ECU 210 is possible. That is, data collection device 2 receives information from ECUs 210 , 220 , and 230 via ECU 210 . The data collection 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 management center 3 includes a control unit 31, a communication unit 32, and a storage unit 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 data collection devices 2 and the service providing server 4 via the wide area wireless communication network NW.
  • the storage unit 33 is a storage device for storing various data.
  • the data collection device 2 includes a first unit 101 as a functional block implemented by the first core 21 executing the program stored in the ROM 23, as shown in FIG.
  • the data collection 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 data collection device 2 to operate various applications, and manages the second application 106 .
  • the data collection device 2 may use a hypervisor in a single-core microcomputer to realize the operation of the RTOS 103 and the operation of the GPOS 105 .
  • the management center 3 includes a vehicle-side unit 110 and a service-side unit 120 as functional blocks realized by the CPU 41 executing programs stored in the ROM 42, as shown in FIG.
  • a vehicle-side unit 110 is provided on the side closer to access to the vehicle, and a service-side unit 120 is provided on the side closer to access from the service providing server 4.
  • Functional blocks are divided into two, and 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 manages 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.
  • Mobility GW 111 includes shadow storage unit 112 and vehicle control unit 113 .
  • the shadow storage unit 112 stores a shadow 114 storing vehicle data for each vehicle equipped with the data collection device 2 .
  • a shadow 114 indicates a group of vehicle data for a certain vehicle.
  • the vehicle control unit 113 has a function of controlling the vehicle on which the data collection device 2 is mounted based on 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 comprises a data management section 121 and an access API 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 access API 122 is a standard interface for the service providing server 4 to access the mobility GW 111 and the data management unit 121.
  • the access API 122 provides the service providing server 4 with APIs for accessing vehicles and acquiring vehicle data.
  • 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.
  • vehicle I/F 12 determines whether or not the communication frame is necessary based on the identification information of the communication frame, and outputs the received communication frame to first unit 101 when it is determined that it is necessary. .
  • 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 is a payload composed of 1st data, 2nd data, 3rd data, 4th data, 5th data, 6th data, 7th data and 8th data each of 8 bits (i.e. 1 byte). be.
  • 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 the received CAN frame is necessary based on the CANID.
  • the first unit 101 When the first unit 101 acquires the communication frame output from the vehicle I/F 12, it extracts the identification information and the payload from the communication frame, creates standard format data composed of the identification information and the payload, The created standard format data is stored in the flash memory 25 .
  • the first unit 101 when the first unit 101 acquires a CAN frame, the first unit 101 creates standard format data composed of CANID and first to eighth data.
  • the identification information (second identification information) included in the standard format data may not be the same as the identification information (first identification information) extracted from the communication frame.
  • the unique second identification information may be generated using the first identification information, or the identification information of the communication protocol and the first identification information may be converted to generate the second identification information.
  • the first unit 101 overwrites the standard format data and stores it. Update standard format data. That is, the flash memory 25 stores the latest standard format data for the same identification information.
  • the data normalization process is a process that is repeatedly executed while the microcomputer 11 is operating.
  • the second core 22 first determines in S10 whether or not a preset standardization execution condition is satisfied, as shown in FIG.
  • the standardization execution conditions include a first high-frequency standardization condition, a second high-frequency standardization condition, a third high-frequency standardization condition, a first low-frequency standardization condition, a second low-frequency standardization condition, an event standardization condition, and an invariant standardization condition, which will be described later. At least one of them must be established.
  • the first high-frequency standardization condition is that a preset first high-frequency standardization period (for example, 500 ms in this embodiment) elapses.
  • the second high-frequency standardization condition is that a preset second high-frequency standardization cycle (for example, 2s in this embodiment) has passed.
  • the third high-frequency standardization condition is that a preset third high-frequency standardization period (for example, 4 seconds in this embodiment) elapses.
  • the first low-frequency standardization condition is that a preset first low-frequency standardization period (for example, 30 seconds in this embodiment) elapses.
  • the second low-frequency standardization condition is that a preset second low-frequency standardization period (eg, 300 seconds in this embodiment) elapses.
  • the event standardization condition is that a preset event standardization period (for example, 12 hours in this embodiment) has passed.
  • the invariant standardization condition is that the processing of S10 this time is the first processing of S10 after the microcomputer 11 is activated.
  • the second core 22 terminates the data standardization process.
  • the second core 22 in S20, selects the standard format corresponding to the satisfied standardization condition among the seven standardization conditions that constitute the standardization execution condition. Data is obtained from flash memory 25 .
  • the second core 22 acquires standard format data corresponding to the second high-frequency standardization condition in S20.
  • the second core 22 divides the data included in the 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 second core 22 refers to the vehicle data conversion table 23a stored in the ROM 23, and converts the extracted data divided at S30 into control labels and vehicle data.
  • the control label is identification information indicating the type of 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 example, arithmetic formulas, conversion tables) for converting normalized vehicle data into meaningful vehicle data. Vehicle data before normalization may be used. Semanticization includes newly generating information that was not in the payload of the communication frame using an arithmetic expression or the like.
  • 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 identification information indicating the source ECU of the CAN frame.
  • ENG indicates an engine ECU.
  • “Position” is information indicating the position (for example, bit position) of CAN data in the data field.
  • DLC is information indicating the data length. DLC stands for Data Length Code. That is, “DLC” bits of data are extracted from the "position" of the data field.
  • 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. “Offset” indicates the offset amount of the numerical value of the data. “Unit” indicates the unit of the data.
  • the semantic information of the vehicle data conversion table 23a is, for example, as shown in FIG. is a conversion formula for converting to a "steering angle" by subtracting .
  • the vehicle data representing the "steering movement angle” and the vehicle data representing the "steering zero point” are converted into vehicle data representing the "steering angle” which means “steering amount from the reference position”.
  • a "unique label", a "unit”, etc. are given to vehicle data newly generated by semanticization.
  • vehicle data conversion table 23a for data of "shift position", which is a predetermined control label.
  • vehicle data conversion table 23a they are converted into data indicating "P range”, “N range”, “D range”, and "R range”, respectively.
  • the second core 22 hierarchizes the converted vehicle data and stores it in the flash memory 25 in S50, as shown in FIG. 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 data collection 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.
  • 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” respectively indicate the type, size and unit of the numerical value indicated by the "data value”.
  • the standardized vehicle data includes 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.
  • the 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 information is a category name indicating information about transmission.
  • firmware version is a category name indicating information about the firmware of the vehicle.
  • the item “powertrain” in the first hierarchy is a category name indicating power train information
  • the items in the second hierarchy include “accelerator pedal”, “engine”, and “engine oil”.
  • 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.
  • Energy which is an item in the first hierarchy, is a category name indicating energy information, and includes "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.
  • These third-layer items include one or more individual vehicle data (also referred to as items).
  • 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
  • transmission type as an item of the third hierarchy.
  • These third-layer items are also called items, and are the minimum units of the data structure.
  • 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".
  • 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.
  • the data transmission process is a process that is repeatedly executed while the microcomputer 11 is operating.
  • the second core 22 When the data transmission process is executed, the second core 22, as shown in FIG. 12, first determines in S110 whether or not a preset first high-frequency transmission condition is satisfied.
  • the first high-frequency transmission condition is that mod ⁇ tx/(T ⁇ 2) ⁇ is 0, where tx is the current time, T is a transmission interval set value (eg, 500 ms in this embodiment).
  • the second core 22 proceeds to S130.
  • the second core 22 selects the vehicle data set as the first high-frequency data from among the vehicle data constituting the standardized vehicle data in S120. Data is extracted from the standardized vehicle data storage unit 25a, transmitted to the management center 3, and the process proceeds to S130.
  • the vehicle data constituting the standardized vehicle data include second high-frequency data, third high-frequency data, fourth high-frequency data, fifth high-frequency data, and third high-frequency data, which will be described later.
  • the second core 22 determines whether or not a preset second high-frequency transmission condition is satisfied.
  • a second high-frequency transmission condition is that mod ⁇ (tx+T)/(T ⁇ 2) ⁇ is zero.
  • the second core 22 proceeds to S150.
  • the second core 22 selects vehicle data set as the second high-frequency data from the vehicle data constituting the standardized vehicle data in S140. Data is extracted from the standardized vehicle data storage unit 25a, transmitted to the management center 3, and the process proceeds to S150.
  • the second core 22 determines whether or not a preset third high-frequency transmission condition is satisfied.
  • a third high frequency transmission condition is that mod ⁇ tx/(T ⁇ 8) ⁇ is zero.
  • the second core 22 proceeds to S170.
  • the second core 22 selects the vehicle data set as the third high-frequency data from among the vehicle data constituting the standardized vehicle data in S160. Data is extracted from the standardized vehicle data storage unit 25a, transmitted to the management center 3, and the process proceeds to S170.
  • a fourth high-frequency transmission condition is that mod ⁇ (tx+T)/(T ⁇ 8) ⁇ is zero.
  • the second core 22 proceeds to S190.
  • the second core 22 selects the vehicle data set as the fourth high-frequency data from among the vehicle data constituting the standardized vehicle data in S180. Data is extracted from the standardized vehicle data storage unit 25a, transmitted to the management center 3, and the process proceeds to S190.
  • a fifth high-frequency transmission condition is that mod ⁇ tx/(T ⁇ 16) ⁇ is zero.
  • the second core 22 proceeds to S210.
  • the second core 22 selects the vehicle data set as the fifth high-frequency data from among the vehicle data constituting the standardized vehicle data in S200. Data is extracted from the standardized vehicle data storage unit 25a, transmitted to the management center 3, and the process proceeds to S210.
  • a sixth high-frequency transmission condition is that mod ⁇ (tx+T)/(T ⁇ 16) ⁇ is zero.
  • the second core 22 proceeds to S230.
  • the second core 22 selects the vehicle data set as the sixth high-frequency data from among the vehicle data constituting the standardized vehicle data in S180. Data is extracted from the standardized vehicle data storage unit 25a, transmitted to the management center 3, and the process proceeds to S230.
  • the second core 22 determines whether or not the preset first low-frequency transmission condition is met.
  • a first infrequent transmission condition is that mod ⁇ tx/(T ⁇ 120) ⁇ is zero.
  • the second core 22 proceeds to S250.
  • the second core 22 selects the vehicle data set as the first low-frequency data from among the vehicle data constituting the standardized vehicle data in S240. Data is extracted from the standardized vehicle data storage unit 25a, transmitted to the management center 3, and the process proceeds to S250.
  • the second core 22 determines whether or not the preset second low-frequency transmission condition is satisfied.
  • a second infrequent transmission condition is that mod ⁇ (tx+T)/(T ⁇ 120) ⁇ is zero.
  • the second core 22 proceeds to S270.
  • the second core 22 selects the vehicle data set as the second low-frequency data from among the vehicle data constituting the standardized vehicle data in S260. Data is extracted from the standardized vehicle data storage unit 25a, transmitted to the management center 3, and the process proceeds to S270.
  • the second core 22 determines whether or not the preset third low-frequency transmission condition is met.
  • a third infrequent transmission condition is that mod ⁇ tx/(T ⁇ 1200) ⁇ is zero.
  • the second core 22 proceeds to S290.
  • the second core 22 selects the vehicle data set as the third low-frequency data from among the vehicle data constituting the standardized vehicle data in S280. Data is extracted from the standardized vehicle data storage unit 25a, transmitted to the management center 3, and the process proceeds to S290.
  • the second core 22 determines whether or not the preset fourth low-frequency transmission condition is met.
  • a fourth infrequent transmission condition is that mod ⁇ (tx+T)/(T ⁇ 1200) ⁇ is zero.
  • the second core 22 proceeds to S310.
  • the second core 22 selects the vehicle data set as the fourth low-frequency data from among the vehicle data constituting the standardized vehicle data in S300. Data is extracted from the standardized vehicle data storage unit 25a, transmitted to the management center 3, and the process proceeds to S310.
  • the second core 22 determines whether or not a preset event transmission condition is satisfied.
  • the event transmission condition is that mod ⁇ tx/(T*172800) ⁇ is zero.
  • the second core 22 proceeds to S330.
  • the second core 22 stores the vehicle data set in the event data from the vehicle data constituting the standardized vehicle data in S320 as standardized vehicle data. It is extracted from the unit 25a, transmitted to the management center 3, and proceeds to S330.
  • the second core 22 determines whether or not a preset invariant transmission condition is satisfied.
  • the constant transmission condition is that the processing of S330 this time is the first processing of S330 after the microcomputer 11 is started.
  • the second core 22 terminates the data transmission process.
  • the second core 22 stores the vehicle data set as constant data in the standardized vehicle data in S340. The data is extracted from the unit 25a, transmitted to the management center 3, and the data transmission process ends.
  • first high-frequency data, third high-frequency data, fifth high-frequency data, first low-frequency data, and third low-frequency data are transmitted.
  • Frequency data, event data and persistent data are sent.
  • the first high-frequency data is transmitted every 1000 ms after time t0.
  • the second high-frequency data is transmitted at time t1 when 500 ms has passed since time t0, and thereafter every 1000 ms has passed since time t1.
  • the third high-frequency data is transmitted every 4 seconds after time t0.
  • the fourth high-frequency data is transmitted at time t4 when 2 s have passed since time t0, and thereafter every time 4 s has passed since time t4.
  • the fifth high-frequency data is transmitted every 8 seconds after time t0.
  • the sixth high-frequency data is transmitted at a time 4 s after time t0, and is transmitted every 8 s after that.
  • the first low-frequency data is transmitted each time one minute elapses from time t0.
  • the second low-frequency data is transmitted when 30 seconds have passed since time t0, and is transmitted every minute after that.
  • the third low-frequency data is transmitted every 10 minutes after time t0.
  • the fourth low-frequency data is transmitted at a time five minutes after time t0, and is transmitted every ten minutes thereafter.
  • the event data is sent every 12 hours after time t0.
  • the second application 106 of the second unit 102 performs analysis. For example, when the second application 106 is a driving diagnosis application, the second application 106 detects "sudden steering,” “sudden braking,” and “sudden acceleration,” and detects “impatient driving,” and “leisurely driving.” and output analysis results. Further, when the second application 106 is, for example, a parking monitoring application, the second application 106 detects "suspicious person found" and "vehicle intrusion".
  • the second application 106 transmits information indicating the above detection result or analysis result (hereinafter referred to as analysis information) to the management center 3 .
  • the second application 106 transmits the above-mentioned “events” such as “rapid turn” and “suspicious person found” to the management center 3 at the detected timing.
  • the second application 106 also transmits the above-mentioned “state” such as "impatient driving” to the management center 3 at the timing when the "state” is determined, or periodically transmits it to the management center 3.
  • the mobility GW 111 includes a shadow creation unit 115, a latest index creation unit 116, and a latest index storage unit 117.
  • the shadow creation unit 115 Each time vehicle data or analysis information is transmitted from the data collection device 2, the shadow creation unit 115 overwrites the transmitted vehicle data or analysis information in the corresponding area of the structured standardized vehicle data, thereby standardizing the vehicle data. Update vehicle data.
  • the shadow creation unit 115 copies the previous value to the relevant area corresponding to the "state” if the analysis information regarding the "state” is not transmitted. In addition, when the standardized vehicle data is updated and the analysis information regarding the "event” is not transmitted, the shadow creating unit 115 sets the corresponding area corresponding to the "event” to "blank (no event)". do.
  • the shadow creation unit 115 creates a new shadow 114 using the updated standardized vehicle data.
  • the shadow creating unit 115 then stores the created shadow 114 in the shadow storage unit 112 .
  • the shadow storage unit 112 stores a plurality of shadows 114 created at different times for each vehicle.
  • One 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.
  • the timing at which the shadow creation unit 115 receives the structured standardized vehicle data via the communication unit 32 differs from vehicle to vehicle, but new shadow creation is performed at the same timing for all vehicles.
  • the shadow creating unit 115 may create new shadows for all vehicles at regular intervals.
  • Past shadows 114 are accumulated for each vehicle in the shadow storage unit 112 . Shadows 114 that have passed a certain period of time may be deleted sequentially.
  • the shadow creation unit 115 receives standardized vehicle data formed in a hierarchical structure from the data collection device 2 .
  • the shadow creation unit 115 may receive part of the hierarchical structure data of the 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 112 .
  • 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 data collection device 2 is mounted.
  • object-id is a number for identifying the vehicle. An “object-id” is given each time a vehicle to be managed is registered in the management center 3 .
  • 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”, and “notify_reason” as data related to hardware and software installed in the data collection device 2. Store. These data such as “version” and “power_status” are transmitted from the data collection device 2 separately from the standardized vehicle data when a change occurs.
  • object-id is a character string that identifies the vehicle equipped with the data collection device 2, and functions as a partition key.
  • 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 data collection device 2.
  • power_status is a character string indicating the system status of the data collection device 2 (on, off, etc.).
  • 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 data collection device 2 in addition to the vehicle data group.
  • the device data storage unit 114b may store the information of the data collection device 2 separately in the ROM 42 without including it in the shadow 114.
  • the device data storage unit 114b may store only the latest data in the ROM 42 instead of accumulating past data for each time stamp as the information of the data collection device 2 .
  • the latest index creation unit 116 acquires the latest shadow 114 for each vehicle from the shadow storage unit 112 and creates the latest index 118 (also referred to as the first index) 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.
  • An index is parameter information that serves as a key when searching for the shadow 114 from the shadow storage unit 112 .
  • the latest index creation unit 116 creates the latest index 118 by using vehicle data acquired from the data collection device 2 or by generating data by itself.
  • the latest index 118 includes "gateway-id", “object-id”, “shadow-version”, “vin”, “location-lon”, “location-lat” and “location-alt " is stored.
  • gateway-id is information that identifies the mobility GW 111.
  • object-id is information that identifies the vehicle on which the data collection device 2 is mounted.
  • shadow-version corresponds to “Shadow_version” of the shadow 114. That is, “shadow-version” is information for identifying the shadow 114, and is set with a time stamp.
  • vin is a registration number unique to the vehicle on which the data collection device 2 is installed.
  • location-lon is information indicating the latitude at which the vehicle equipped with the data collection device 2 is located.
  • location-lat is information indicating the longitude at which the vehicle equipped with the data collection device 2 is located.
  • location-alt is information indicating the altitude at which the vehicle equipped with the data collection device 2 is located.
  • the data management unit 121 includes an index creation unit 124 and an index storage unit 125.
  • the index creation unit 124 periodically acquires the latest index 118 from the latest index storage unit 117, and creates an index 126 (also referred to as a second index) using the acquired latest index 118.
  • the index creation unit 124 then stores the created index 126 in the index storage unit 125 .
  • the index storage unit 125 stores a plurality of indexes 126 created at different times for each vehicle.
  • the indices 126 are "timestamp”, “schedule-type”, “gateway-id”, “object-id”, “shadow-version”, “vin”, “location” and “alt”. to store
  • timestamp is a timestamp that indicates the time 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'.
  • gateway-id is information that identifies the mobility GW 111.
  • object-id is information for identifying a vehicle in which the data collection device 2 is mounted.
  • shadow-version is the timestamp of the gateway and is information that identifies the shadow 114.
  • vin is a registration number unique to the vehicle on which the data collection device 2 is mounted.
  • location is information indicating the latitude and longitude at which the vehicle equipped with the data collection device 2 is located.
  • alt is information indicating the altitude at which the vehicle equipped with the data collection device 2 is located.
  • the latest index creation unit 116 and the latest index storage unit 117 may not be provided, and the index creation unit 124 may acquire the shadow 114 stored in the shadow storage unit 112 to 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 configuration may be such that the index creation unit 124 and the index storage unit 125 are not provided.
  • the index acquisition unit 127 requests the data acquisition unit 119 to acquire specified vehicle data using the “object-id” specified from the access API 122 and the time stamp (“shadow-version”).
  • the mobility GW 111 includes a data acquisition unit 119.
  • the data management unit 121 has an index acquisition unit 127 .
  • the index acquisition unit 127 provides an index that can identify the shadow 114 in order to acquire the vehicle data corresponding to the designated parameter from the shadow 114 .
  • the index acquisition unit 127 receives from the access API 122 a request to acquire the specified data of the specified vehicle at the specified time, the index acquisition unit 127 acquires the index 126 corresponding to the specified time and the specified vehicle of the received request from the index storage unit 125 .
  • the index acquisition unit 127 sends a request to the data acquisition unit 119 to acquire the specified data in the specified shadow, with the shadow 114 identified based on the acquired index 126 as the specified shadow. Specifically, since the shadow 114 is uniquely determined by 'object-id' and 'shadow-version', the index acquisition unit 127 uses 'object-id' and 'shadow-version' to obtain the specified data. is requested to the data acquisition unit 119 .
  • the data acquisition unit 119 Upon receiving a request from the index acquisition unit 127 , the data acquisition unit 119 extracts specified data from the specified shadow indicated by the received request, and transmits the extracted specified data to the access API 122 .
  • the extracted designated data may be transmitted to the access API 122 via the index acquisition unit 127 .
  • the access API 122 acquires the corresponding index 126 from the index storage unit 125 via the index acquisition unit 127, and the acquired index 126 ("object-id ” and “shadow-version”) may be used to request the data acquisition unit 119 to acquire the specified data.
  • Requests RQ1, RQ2, and RQ3 shown in FIG. 19 are specific examples of requests that the service providing server 4 transmits to the access API 122. In other words, it is an API for vehicle data acquisition provided by the access API 122 to the service providing server 4 .
  • the request RQ1 is sent to the vehicle whose “object-id” is “dt-000002” and the vehicle whose “object-id” is “dt-000008” on August 27, 2019 at 5:17:10 0.5 to 10 seconds latitude (ie, data whose 'item-names' is 'latitude').
  • the index acquisition unit 127 acquires from the index storage unit 125 the "shadow-version" that can identify the shadow 114 corresponding to the "object-id” and the time information. The index acquisition unit 127 then instructs the data acquisition unit 119 to acquire “latitude” corresponding to “object-id” and “shadow-version”. The data acquisition unit 119 acquires the relevant vehicle data from the shadow storage unit 112 and the vehicle data is transmitted to the access API 122 .
  • Request RQ2 is the upper left point identified by longitude 135.8974670767784 and altitude 36.16643474082275, longitude 139.7863560656673 and altitude 35.05532363071164. This is a request to acquire the latitude of a vehicle that exists for 10 seconds from 5:17:10.5 on August 27, 2019 in the area within the rectangle specified by the specified lower right point. .
  • the index acquisition unit 127 acquires from the index storage unit 125 the “object-id” list of vehicles existing in the specified area at the specified time, and obtains the “object-id” list. Get the "shadow-version” at the specified time. The index acquisition unit 127 then instructs the data acquisition unit 119 to acquire “latitude” corresponding to “object-id” and “shadow-version”. The data acquisition unit 119 acquires the relevant vehicle data from the shadow storage unit 112 and the vehicle data is transmitted to the access API 122 .
  • Request RQ3 is sent to the vehicle whose “object-id” is “dt-000002” and the vehicle whose “object-id” is “dt-000008” on August 27, 2019 at 5:17:10 This is a request for instructing acquisition of information on all items of the category "ADAS/AD” in .5 seconds.
  • the index acquisition unit 127 acquires from the index storage unit 125 the "shadow-version" that can identify the shadow 114 corresponding to the "object-id” and the time information.
  • the index acquisition unit 127 then instructs the data acquisition unit 119 to acquire information on all items of the category “ADAS/AD” corresponding to “object-id” and “shadow-version”.
  • the data acquisition unit 119 acquires the relevant vehicle data from the shadow storage unit 112 and the vehicle data is transmitted to the access API 122 .
  • the service providing server 4 can acquire the above analysis information.
  • the index acquisition unit 127 acquires the index 126 corresponding to the designated vehicle and the designated time of the received request from the index storage unit 125 .
  • the index acquisition unit 127 sets the shadow 114 specified based on the acquired index 126 as the specified shadow, and transmits a request to the data acquisition unit 119 to acquire data of the category “dangerous driving information” in the specified shadow.
  • the category “dangerous driving information” includes items such as “sudden steering,” “sudden braking,” and “sudden acceleration.” Thereby, the service providing server 4 can acquire data including “sudden steering”, “sudden braking” and “sudden acceleration”.
  • the service providing server 4 identifies the shadow 114 corresponding to the designated vehicle by accessing the digital twin 123 of the data management unit 121 via the access API 122.
  • the service providing server 4 transmits a control instruction including the specified shadow and the control content to the vehicle control unit 113 of the mobility GW 111, as indicated by an arrow L2 in FIG.
  • the vehicle control unit 113 transmits a control instruction to the data collection device 2 of the vehicle corresponding to the designated shadow.
  • the vehicle on which the data collection device 2 is mounted executes control based on the control instruction.
  • the management center 3 configured in this manner includes a vehicle-side unit 110 and a service-side unit 120.
  • the vehicle-side unit 110 is connected to a plurality of data collection devices 2 mounted on each of a plurality of vehicles so as to be able to communicate with each other.
  • the service side unit 120 is connected to the service providing server 4 so as to be capable of data communication.
  • the vehicle-side unit 110 also includes a shadow creating section 115 .
  • the shadow creation unit 115 repeatedly acquires, from each of the plurality of data collection devices 2, a vehicle data group formed in a first data structure in which a plurality of vehicle data are classified into respective categories. For each vehicle, the shadow creation unit 115 provides vehicle identification information (“object-id” in this embodiment) for identifying the vehicle, and timing identification information (“object-id” in this embodiment) for identifying the timing at which the vehicle data is acquired. Then, a vehicle data group to which "Shadow_version") is assigned is created as a shadow 114 and stored in the shadow storage section 112 provided in the vehicle-side unit 110 in the form of a first data structure.
  • vehicle identification information (“object-id” in this embodiment) for identifying the vehicle
  • timing identification information (“object-id” in this embodiment) for identifying the timing at which the vehicle data is acquired.
  • a vehicle data group to which "Shadow_version" is assigned is created as a shadow 114 and stored in the shadow storage section 112 provided in the vehicle-side unit 110 in the form of
  • the service-side unit 120 includes an index acquisition unit 127.
  • the index acquisition unit 127 receives from the service providing server 4 a request to acquire specific vehicle data or a specific category as designated data from among a plurality of vehicle data constituting the vehicle data group.
  • the vehicle-side unit 110 is instructed to acquire the specified data of the predetermined vehicle at the predetermined time from the shadow storage section 112 of the vehicle-side unit 110 .
  • the vehicle-side unit 110 acquires vehicle data corresponding to the specified data from the specified shadow 114 of the specified vehicle from the shadow storage unit 112 and transmits the vehicle data to the service-side unit 120 .
  • the service side unit 120 transmits the transmitted vehicle data to the requested service providing server 4 .
  • the shadow 114 has a first data structure in which a plurality of vehicle data are classified into respective categories, and the plurality of vehicle data are arranged in a hierarchical structure. Therefore, the management center 3 can access a plurality of vehicle data constituting the shadow 114 by using the data name of specific vehicle data or the category name of a specific category, thereby facilitating the use of vehicle data. be able to.
  • the “data name of specific vehicle data” includes, for example, the above-mentioned “vehicle identification number”, “vehicle number”, “license plate”, “brand name”, “model”, “manufacturing year” and “transmission type”.
  • the “category name of a specific category” includes, for example, the above-mentioned “attribute information”, “power training”, “energy”, “vehicle identification information”, “vehicle attribute”, “transmission configuration”, “firmware version”, " accelerator pedal”, “engine”, “engine oil”, “battery status”, “battery configuration” and “fuel”.
  • the shadow 114 includes device information formed in the second data structure and indicating the state of the in-vehicle equipment.
  • the in-vehicle equipment is hardware installed in the data collection device 2 .
  • the management center 3 can also manage the above device information.
  • the index creation unit 124 of the service-side unit 120 creates an index 126 formed in the third data structure, which is data for specifying the shadow 114 , and the index storage unit 125 provided in the service-side unit 120 . memorize to
  • the vehicle-side unit 110 also includes a latest index creation unit 116 .
  • the latest index creation unit 116 creates the latest index 118 for identifying the latest shadow 114 for each of the plurality of vehicles, and stores it in the latest index storage unit 117 provided in the vehicle-side unit 110 .
  • the index creation unit 124 repeatedly acquires the latest index 118 from the latest index storage unit 117 and creates the latest index 118 to which time information for specifying the shadow 114 corresponding to the latest index 118 is added as the index 126. and stores it in the index storage section 125 provided in the service side unit 120 .
  • the service-side unit 120 identifies the shadow 114 by referring to the index 126 (that is, without directly referencing the shadow 114). Since this index 126 is composed of information for identifying shadow 114 (that is, latest index 118) and time information, it is information that does not depend on the vehicle manufacturer, vehicle, and shipping time. Therefore, the management center 3 can allow service developers to develop services without considering differences in vehicle data formats.
  • the index acquisition unit 127 acquires the index 126 corresponding to the specified time and the specified vehicle of the request from the index storage unit 125 and identifies the shadow 114 based on the acquired index 126 .
  • the vehicle-side unit 110 also includes a data acquisition section 119 .
  • the data acquisition unit 119 acquires the shadow 114 specified by the index acquisition unit 127 from the shadow storage unit 112 , extracts specified data from the acquired shadow 114 , and transmits the specified data to the service-side unit 120 .
  • the management center 3 can provide the service providing server 4 with the specified data of the specified vehicle at the specified time.
  • one of a plurality of mutually different transmission timings is set for each of the plurality of vehicle data constituting the vehicle data group. Then, the vehicle-side unit 110 receives each of the plurality of vehicle data constituting the vehicle data group from the plurality of data collection devices 2 at the transmission timing set for the vehicle data.
  • the management center 3 can reduce the frequency of needlessly receiving vehicle data that has not been updated, and can reduce the communication processing load.
  • the data collection device 2 has a vehicle data conversion table 23a in which "resolution” and “offset” are set as normalization information.
  • the vehicle data is generated by the data collection device 2 normalizing the data acquired from the vehicle by the data collection device 2 based on the normalization information of the vehicle data conversion table 23a.
  • the management center 3 can provide the service providing server 4 with vehicle data in a format independent of vehicle type and vehicle manufacturer.
  • the vehicle data conversion table 23a further includes semantic information for converting into vehicle data generated using a plurality of normalized vehicle data.
  • the vehicle data is generated by the in-vehicle device converting using a plurality of normalized vehicle data based on the semantic information of the vehicle data conversion table 23a.
  • the management center 3 can provide the service providing server 4 with vehicle data that is meaningful using the vehicle data acquired from the vehicle by the data collection device 2 .
  • the management center 3 can collectively acquire all vehicle data related to the function or domain corresponding to the specific category by the category name of the specific category.
  • the shadow creation unit 115 of the management center 3 repeatedly acquires analysis information generated by analyzing a plurality of vehicle data from each of the plurality of data collection devices 2, and creates a shadow 114 including the acquired analysis information. create.
  • the specified data further includes analysis information.
  • the management center 3 can acquire post-analysis data from the vehicle, manage the shadow 114, and provide post-analysis data to various service providers.
  • the vehicle control unit 113 may acquire control instructions from the service providing server 4 via the access API 122 of the service-side unit 120 .
  • Providing the service-side unit 120 with the access API 122 and providing the vehicle-side unit 110 with the vehicle control section 113 is also one of the configurations in which the two units are loosely coupled.
  • the management center 3 corresponds to the center
  • the data collection device 2 corresponds to the vehicle-mounted device
  • the service providing server 4 corresponds to the service providing unit
  • the index acquisition unit 127 corresponds to the instruction unit
  • Mobility IoT system 1 corresponds to a management system.
  • the controller 31 and techniques described in this disclosure can be performed by a dedicated computer provided by configuring a processor and memory programmed to perform one or more functions embodied by a computer program. may be implemented. Alternatively, the controller 31 and techniques described in this disclosure may be implemented by a dedicated computer provided by configuring the processor with one or more dedicated hardware logic circuits. Alternatively, the controller 31 and techniques described in this disclosure are a combination of a processor and memory programmed to perform one or more functions and a processor configured by one or more hardware logic circuits. may be implemented by one or more dedicated computers configured by Computer programs may also be stored as computer-executable instructions on a computer-readable non-transitional tangible storage medium. The method of realizing the function of each unit included in the control unit 31 does not necessarily include software, and all the functions may be realized using one or more pieces of hardware.
  • a plurality of functions possessed by one component in the above embodiment may be realized by a plurality of components, or a function possessed by one component may be realized by a plurality of components. Also, a plurality of functions possessed by a plurality of components may be realized by a single component, or a function realized by a plurality of components may be realized by a single component. Also, part of the configuration of the above embodiment may be omitted. Also, at least part of the configuration of the above embodiment may be added or replaced with respect to the configuration of the other above embodiment.
  • a system having the management center 3 as a component, a program for making a computer function as the management center 3, a non-transitional physical recording medium such as a semiconductor memory recording this program, and data can also be implemented in various forms such as a management method.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Geometry (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Evolutionary Computation (AREA)
  • General Engineering & Computer Science (AREA)
  • Computational Mathematics (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Automation & Control Theory (AREA)
  • Marketing (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Traffic Control Systems (AREA)

Abstract

センター（３）は車両側ユニット（１１０）とサービス側ユニット（１２０）とを備える。車両側ユニットは、複数の車載装置（２）のそれぞれから、複数の車両データが各カテゴリに分類された第１データ構造に形成された車両データ群を繰り返し取得する。車両側ユニットは、車両毎に、車両識別情報とタイミング識別情報とが付与された車両データ群をシャドウ（１１４）として作成しシャドウ記憶部（１１２）に記憶する。サービス側ユニットは、リクエストをサービス提供ユニット（４）から受信すると、リクエストに基づいて、所定時間における所定車両の指定データをシャドウ記憶部から取得するよう車両側ユニットへ指示する。

Description

センター、管理システム、管理方法および管理プログラム 関連出願の相互参照
　本国際出願は、２０２１年７月２日に日本国特許庁に出願された日本国特許出願第２０２１－１１０９０１号に基づく優先権を主張するものであり、日本国特許出願第２０２１－１１０９０１号の全内容を参照により本国際出願に援用する。
　本開示は、車両データを管理するセンター、管理システム、管理方法および管理プログラムに関する。
　特許文献１には、車両から車両データを収集することによって現実世界の車両の状態を仮想空間で再現するデジタルツインシミュレーションが記載されている。
特開２０１９－１５３２９１号公報
　ＣＡＮ通信により取得できる車両データは、車両データを利用する利用者にとって利用しやすい形式を備えていない。これは、例えば、車両メーカー、車種および出荷時期などに応じてＣＡＮ通信フレームから取得できるデータが異なっていることが原因である。発明者の詳細な検討の結果、車両データを扱いたい利用者は、ＣＡＮ通信フレームの構造、および、データが流れるバスなどの専門的な知識が必要となり、車両データに容易にアクセスすることができないという課題が見出された。
　本開示は、車両データの利用を容易にする。
　本開示の一態様は、車両側ユニットと、サービス側ユニットとを備えるセンターである。
　車両側ユニットは、複数の車両のそれぞれに搭載された複数の車載装置とデータ通信可能に接続される。サービス側ユニットは、サービス提供ユニットとデータ通信可能である。
　車両側ユニットは、シャドウ作成部を備える。シャドウ作成部は、複数の車載装置のそれぞれから、複数の車両データが各カテゴリに分類された第１データ構造に形成された車両データ群を繰り返し取得するように構成される。そしてシャドウ作成部は、車両毎に、車両を識別する車両識別情報と、車両データを取得したタイミングを識別するためのタイミング識別情報とが付与された車両データ群をシャドウとして作成して、車両側ユニットに設けられたシャドウ記憶部に第１データ構造の形で記憶するように構成される。
　サービス側ユニットは、指示部を備える。指示部は、車両データ群を構成する複数の車両データのうち、特定の車両データ、または、特定のカテゴリを指定データとして、該当する車両データの取得を指示するリクエストをサービス提供ユニットから受信すると、リクエストに基づいて、所定時間における所定車両の指定データを車両側ユニットのシャドウ記憶部から取得するよう車両側ユニットへ指示するように構成される。
　このように構成された本開示のセンターでは、シャドウは、複数のカテゴリで分類されたデータ構造を有しており、複数の車両データが階層構造で整理されている。このため、本開示のセンターは、特定の車両データのデータ名、または、特定のカテゴリのカテゴリ名によって、シャドウを構成する複数の車両データにアクセスすることができ、車両データの利用を容易にすることができる。
　本開示の別の態様は、複数の車両のそれぞれに搭載されて車両から車両データを取得する複数の車載装置と、車両データを管理するセンターとを備える管理システム（１）である。そしてセンターは、車両側ユニットと、サービス側ユニットとを備える。また車両側ユニットは、シャドウ作成部を備える。またサービス側ユニットは、指示部を備える。
　このように構成された本開示の管理システムは、本開示のセンターを備えるシステムであり、本開示のセンターと同様の効果を得ることができる。
　本開示の更に別の態様は、車両側ユニットと、サービス側ユニットとを備えるセンターで実行される管理方法である。
　そして車両側ユニットが、複数の車載装置のそれぞれから、複数の車両データが各カテゴリに分類された第１データ構造に形成された車両データ群を繰り返し取得し、車両毎に、車両を識別する車両識別情報と、車両データを取得したタイミングを識別するためのタイミング識別情報とが付与された車両データ群をシャドウとして作成して、車両側ユニットに設けられたシャドウ記憶部に第１データ構造の形で記憶する。
　またサービス側ユニットが、車両データ群を構成する複数の車両データのうち、特定の車両データ、または、特定のカテゴリを指定データとして、該当する車両データの取得を指示するリクエストをサービス提供ユニットから受信すると、リクエストに基づいて、所定時間における所定車両の指定データを車両側ユニットのシャドウ記憶部から取得するよう車両側ユニットへ指示する。
　本開示の管理方法は、本開示のセンターにて実行される方法であり、当該方法を実行することで、本開示のセンターと同様の効果を得ることができる。
　本開示の更に別の態様は、車両側ユニットと、サービス側ユニットとを備えるセンターのコンピュータを、シャドウ作成部、および、指示部として機能させる管理プログラムである。
　本開示の管理プログラムによって制御されるコンピュータは、本開示のセンターの一部を構成することができ、本開示のセンターと同様の効果を得ることができる。
モビリティＩｏＴシステムの構成を示すブロック図である。 データ収集装置の構成を示すブロック図である。 管理センターの構成を示すブロック図である。 データ収集装置の機能的な構成を示す機能ブロック図である。 管理センターの機能的な構成を示す機能ブロック図である。 ＣＡＮフレームの構成を示す図である。 データ標準化処理を示すフローチャートである。 車両データ変換テーブルの構成を示す図である。 標準化車両データの第１階層と、データフォーマットとを示す図である。 標準化車両データの構成を示す図である。 標準化車両データの作成手順を示すシーケンス図である。 データ送信処理の前半部分を示すフローチャートである。 データ送信処理の後半部分を示すフローチャートである。 データ送信タイミングを示すタイミングチャートである。 モビリティＧＷおよびデータ管理部の機能的な構成を示す機能ブロック図である。 シャドウの構成を示す図である。 最新インデックスの構成を示す図である。 インデックスの構成を示す図である。 リクエストの具体例を示す図である。 車両に搭載されるＥＣＵの接続状態を示すブロック図である。
　以下に本開示の実施形態を図面とともに説明する。
　本実施形態のモビリティＩｏＴシステム１は、図１に示すように、複数のデータ収集装置２と、管理センター３と、サービス提供サーバ４とを備える。ＩｏＴは、Internet of Thingsの略である。
　データ収集装置２は、車両に搭載され、広域無線通信網ＮＷを介して、管理センター３とデータ通信を行う機能を有する。
　管理センター３は、モビリティＩｏＴシステム１を管理する装置である。管理センター３は、広域無線通信網ＮＷを介して、複数のデータ収集装置２およびサービス提供サーバ４との間でデータ通信を行う機能を有する。
　サービス提供サーバ４は、例えば、車両の運行を管理するサービスを提供するために設置されたサーバである。なお、モビリティＩｏＴシステム１は、サービス内容が互いに異なる複数のサービス提供サーバを備えてもよい。これらサービス提供サーバ４は、オンプレミスで構成されてもよいし、クラウドで構成されてもよく、管理センター３と物理的に同じサーバとして構成されていてもよい。
　データ収集装置２は、図２に示すように、マイクロコンピュータ１１と、車両インターフェース（以下、車両Ｉ／Ｆ）１２と、通信部１３と、記憶部１４とを備える。
　マイクロコンピュータ１１は、第１コア２１と、第２コア２２と、ＲＯＭ２３と、ＲＡＭ２４と、フラッシュメモリ２５と、入出力部２６と、バス２７とを備える。
　マイクロコンピュータ１１の各種機能は、第１コア２１および第２コア２２が非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。この例では、ＲＯＭ２３が、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。
　なお、第１コア２１および第２コア２２が実行する機能の一部または全部を、一つあるいは複数のＩＣ等によりハードウェア的に構成してもよい。
　フラッシュメモリ２５は、データ書き換え可能な不揮発性メモリである。フラッシュメモリ２５は、後述する標準化車両データを格納する標準化車両データ格納部２５ａを備える。
　入出力部２６は、マイクロコンピュータ１１の外部と第１コア２１および第２コア２２との間でデータの入出力を行わせるための回路である。
　バス２７は、第１コア２１、第２コア２２、ＲＯＭ２３、ＲＡＭ２４、フラッシュメモリ２５および入出力部２６を、互いにデータ入出力可能に接続する。
　車両Ｉ／Ｆ１２は、車両に搭載された電子制御装置およびセンサ等との間で信号の入出力を行わせるための入出力回路である。
　車両Ｉ／Ｆ１２は、電源電圧入力ポート、汎用入出力ポート、ＣＡＮ通信ポートおよびイーサネット通信ポートなどを備える。
　電源電圧入力ポートは、＋Ｂ電圧が入力される＋Ｂ電圧ポートと、ＩＧ電圧が入力されるＩＧ電圧ポートとを備える。なお、車両Ｉ／Ｆ１２は、ＤＣＤＣコンバータと、ツェナーダイオードを含む保護回路とを備える。これにより、電源電圧入力ポートは、１２Ｖの車両電圧の入力と４８Ｖの車両電圧の入力との両方に対応可能に構成されている。
　ＣＡＮ通信ポートは、ＣＡＮ通信プロトコルに従ってデータの送受信を行うためのポートである。イーサネット通信ポートは、イーサネット通信プロトコルに基づいてデータの送受信を行うためのポートである。ＣＡＮは、Controller Area Networkの略である。ＣＡＮは登録商標である。イーサネットは登録商標である。
　ＣＡＮ通信ポートおよびイーサネット通信ポートには、車両に搭載された他の電子制御装置が接続される。これにより、データ収集装置２は、他の電子制御装置との間で通信フレームの送受信を行うことができる。
　通信部１３は、広域無線通信網ＮＷを介して、管理センター３とデータ通信を行う。
　記憶部１４は、各種データを記憶するための記憶装置である。
　図２０に示すように、車両には、一つのＥＣＵ２１０と、複数のＥＣＵ２２０と、複数のＥＣＵ２３０と、車外通信装置２４０と、車内通信網２５０とが搭載される。ＥＣＵは、Electronic Control Unitの略である。
　ＥＣＵ２１０は、複数のＥＣＵ２２０を統括することにより、車両全体として連携がとれた制御を実現する。
　ＥＣＵ２２０は、車両における機能によって区分けしたドメイン毎に設けられ、主として、そのドメイン内に存在する複数のＥＣＵ２３０の制御を実行する。各ＥＣＵ２２０は、それぞれ個別に設けられた下層ネットワーク（例えば、ＣＡＮ）を介して配下のＥＣＵ２３０と接続される。ＥＣＵ２２０は、配下のＥＣＵ２３０に対するアクセス権限などを一元的に管理し利用者の認証等を行う機能を有する。ドメインは、例えば、パワートレーン、ボデー、シャシおよびコックピット等である。
　パワートレーンのドメインに属するＥＣＵ２２０に接続されるＥＣＵ２３０は、例えば、エンジンを制御するＥＣＵ２３０、モータを制御するＥＣＵ２３０、および、バッテリを制御するＥＣＵ２３０等を含む。
　ボデーのドメインに属するＥＣＵ２２０に接続されるＥＣＵ２３０は、例えば、エアコンを制御するＥＣＵ２３０、および、ドアを制御するＥＣＵ２３０等を含む。
　シャシドメインに属するＥＣＵ２２０に接続されるＥＣＵ２３０は、例えば、ブレーキを制御するＥＣＵ２３０、および、ステアリングを制御するＥＣＵ２３０等を含む。
　コックピットのドメインに属するＥＣＵ２２０に接続されるＥＣＵ２３０は、例えば、メータおよびナビゲーションの表示を制御するＥＣＵ２３０、および、車両の乗員によって操作される入力装置を制御するＥＣＵ２３０等を含む。
　車外通信装置２４０は、広域無線通信網ＮＷを介して、車両外の通信装置（例えば、クラウドサーバ）との間でデータ通信を行う。
　車内通信網２５０は、ＣＡＮ　ＦＤとイーサネットとを備える。ＣＡＮ　ＦＤは、CAN with Flexible Data Rateの略である。ＣＡＮ　ＦＤは、ＥＣＵ２１０と各ＥＣＵ２２０および車外通信装置２４０とをバス接続する。イーサネットは、ＥＣＵ２１０と各ＥＣＵ２２０および車外通信装置２４０との間を個別に接続する。
　ＥＣＵ２１０は、ＣＰＵ２１０ａ、ＲＯＭ２１０ｂおよびＲＡＭ２１０ｃ等を備えたマイクロコンピュータを中心に構成された電子制御装置である。マイクロコンピュータの各種機能は、ＣＰＵ２１０ａが非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。この例では、ＲＯＭ２１０ｂが、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。なお、ＣＰＵ２１０ａが実行する機能の一部または全部を、一つあるいは複数のＩＣ等によりハードウェア的に構成してもよい。また、ＥＣＵ２１０を構成するマイクロコンピュータの数は１つでも複数でもよい。
　ＥＣＵ２２０、ＥＣＵ２３０および車外通信装置２４０は、いずれも、ＥＣＵ２１０と同様に、ＣＰＵ、ＲＯＭおよびＲＡＭ等を備えたマイクロコンピュータを中心に構成された電子制御装置である。また、ＥＣＵ２２０、ＥＣＵ２３０および車外通信装置２４０を構成するマイクロコンピュータの数は１つでも複数でもよい。ＥＣＵ２２０は、１以上のＥＣＵ２３０を統括するＥＣＵであり、ＥＣＵ２１０は、１以上のＥＣＵ２２０を統括する、または車外通信装置２４０を含む車両全体のＥＣＵ２２０，２３０を統括するＥＣＵである。
　データ収集装置２は、ＥＣＵ２１０との間でデータ通信可能となるようにＥＣＵ２１０に接続される。すなわち、データ収集装置２は、ＥＣＵ２１０を介して、ＥＣＵ２１０，２２０，２３０の情報を受信する。またデータ収集装置２は、車両制御に関する要求を、ＥＣＵ２１０へ送信したり、ＥＣＵ２１０を介してＥＣＵ２２０，２３０へ送信したりする。
　管理センター３は、図３に示すように、制御部３１と、通信部３２と、記憶部３３とを備える。
　制御部３１は、ＣＰＵ４１、ＲＯＭ４２およびＲＡＭ４３等を備えたマイクロコンピュータを中心に構成された電子制御装置である。マイクロコンピュータの各種機能は、ＣＰＵ４１が非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。この例では、ＲＯＭ４２が、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。なお、ＣＰＵ４１が実行する機能の一部または全部を、一つあるいは複数のＩＣ等によりハードウェア的に構成してもよい。また、制御部３１を構成するマイクロコンピュータの数は１つでも複数でもよい。
　通信部３２は、広域無線通信網ＮＷを介して、複数のデータ収集装置２およびサービス提供サーバ４との間でデータ通信を行う。
　記憶部３３は、各種データを記憶するための記憶装置である。
　データ収集装置２は、ＲＯＭ２３に格納されたプログラムを第１コア２１が実行することにより実現される機能ブロックとして、図４に示すように、第１ユニット１０１を備える。データ収集装置２は、ＲＯＭ２３に格納されたプログラムを第２コア２２が実行することにより実現される機能ブロックとして、第２ユニット１０２を備える。
　第１ユニット１０１は、リアルタイムオペレーティングシステム（以下、ＲＴＯＳ）１０３と、第１アプリケーション１０４とを備える。
　第１アプリケーション１０４は、車両を制御するための各種処理を実行する。第１アプリケーション１０４は、車両を制御するための各種処理を実行するために、フラッシュメモリ２５の標準化車両データ格納部２５ａにアクセスして標準化車両データを参照することが可能に構成されている。
　ＲＴＯＳ１０３は、第１アプリケーション１０４による処理のリアルタイム性を確保することができるように、第１アプリケーション１０４を管理する。
　第２ユニット１０２は、汎用オペレーティングシステム（以下、ＧＰＯＳ）１０５と、第２アプリケーション１０６とを備える。
　第２アプリケーション１０６は、サービス提供サーバ４により提供されるサービスに関連した処理を実行する。第２アプリケーション１０６は、サービスに関連した処理を実行するために、フラッシュメモリ２５の標準化車両データ格納部２５ａにアクセスして標準化車両データを参照することが可能に構成されている。
　ＧＰＯＳ１０５は、各種アプリケーションを動作させるためにデータ収集装置２に搭載された基本ソフトウェアであり、第２アプリケーション１０６を管理する。
　なお、データ収集装置２は、シングルコアのマイクロコンピュータに、ハイパーバイザーを用いて、ＲＴＯＳ１０３での動作と、ＧＰＯＳ１０５での動作とを実現させてもよい。
　管理センター３は、ＲＯＭ４２に格納されたプログラムをＣＰＵ４１が実行することにより実現される機能ブロックとして、図５に示すように、車両側ユニット１１０と、サービス側ユニット１２０とを備える。車両へのアクセスに近い側を車両側ユニット１１０とし、サービス提供サーバ４からのアクセスに近い側をサービス側ユニット１２０とし、機能ブロックを２つに分け、これら２つの機能ブロックを疎結合に構成する。
　管理センター３を構成するこれらの要素を実現する手法はソフトウェアに限るものではなく、その一部または全部の要素について、一つあるいは複数のハードウェアを用いて実現してもよい。例えば、上記機能がハードウェアである電子回路によって実現される場合、その電子回路は多数の論理回路を含むデジタル回路、またはアナログ回路、あるいはこれらの組合せによって実現してもよい。
　車両側ユニット１１０は、車両へのアクセスおよび車両から受信したデータを管理する。車両側ユニット１１０は、モビリティゲートウェイ（以下、モビリティＧＷ）１１１を備える。モビリティＧＷ１１１は、車両へのアクセス要求を車両へ中継する機能の他、車両から受信したデータを管理する機能も有する。
　そしてモビリティＧＷ１１１は、シャドウ記憶部１１２と、車両制御部１１３とを備える。シャドウ記憶部１１２は、データ収集装置２を搭載する車両毎に車両データを収容するシャドウ１１４を記憶する。シャドウ１１４は、ある車両の車両データ群を示す。車両制御部１１３は、サービス提供サーバ４からの指示に基づいて、データ収集装置２を搭載している車両を制御する機能を備える。
　サービス側ユニット１２０は、サービス提供サーバ４からの要求を受け付けるとともに、車両データの提供を行う。サービス側ユニット１２０は、データ管理部１２１と、アクセスＡＰＩ１２２とを備える。ＡＰＩは、Application Programming Interfaceの略である。
　データ管理部１２１は、車両の接続状態の変化に依存しない車両アクセスを提供するための仮想空間であるデジタルツイン１２３を管理する機能を備える。データ管理部１２１は、車両側ユニット１１０で管理する車両データへのアクセスに必要なデータを管理する。
　アクセスＡＰＩ１２２は、サービス提供サーバ４がモビリティＧＷ１１１およびデータ管理部１２１へアクセスするための標準インターフェースである。アクセスＡＰＩ１２２は、サービス提供サーバ４に対し、車両へのアクセス、および、車両データの取得のためのＡＰＩを提供する。
　次に、車両Ｉ／Ｆ１２が実行する処理を説明する。
　車両Ｉ／Ｆ１２は、通信フレームを受信すると、通信フレームを受信した通信ポートに基づいて、通信フレームの通信プロトコルを判断する。具体的には、車両Ｉ／Ｆ１２は、例えば、ＣＡＮ通信ポートで通信フレームを受信した場合には、受信した通信フレームの通信プロトコルはＣＡＮ通信プロトコルであると判断する。また車両Ｉ／Ｆ１２は、例えば、イーサネット通信ポートで通信フレームを受信した場合には、受信した通信フレームの通信プロトコルはイーサネット通信プロトコルであると判断する。
　そして車両Ｉ／Ｆ１２は、通信フレームの識別情報に基づいて、通信フレームが必要であるか否かを判断し、必要であると判断した場合に、受信した通信フレームを第１ユニット１０１へ出力する。
　ＣＡＮフレームは、図６に示すように、スタートオブフレーム、アービトレーションフィールド、コントロールフィールド、データフィールド、ＣＲＣフィールド、ＡＣＫフィールドおよびエンドオブフレームにより構成されている。なお、アービトレーションフィールドは、１１ビットまたは２９ビットのアイデンティファイア（すなわち、ＩＤ）と１ビットのＲＴＲビットで構成される。
　また、ＣＡＮ通信で使用する１１ビットのアイデンティファイアをＣＡＮＩＤという。ＣＡＮＩＤは、ＣＡＮフレームに含まれるデータの内容、ＣＡＮフレームの送信元、およびＣＡＮフレームの送信先等に基づいて予め設定されている。
　データフィールドは、それぞれ８ビット（すなわち１バイト）の第１データ、第２データ、第３データ、第４データ、第５データ、第６データ、第７データおよび第８データで構成されるペイロードである。以下、データフィールドの第１～８データのそれぞれをＣＡＮデータともいう。
　このため、車両Ｉ／Ｆ１２は、ＣＡＮフレームを受信した場合には、ＣＡＮＩＤに基づいて、受信したＣＡＮフレームが必要であるか否かを判断する。
　次に、第１ユニット１０１が実行する処理を説明する。
　第１ユニット１０１は、車両Ｉ／Ｆ１２から出力された通信フレームを取得すると、通信フレームから、識別情報とペイロードとを抽出し、識別情報とペイロードとで構成される標準フォーマットデータを作成して、作成した標準フォーマットデータをフラッシュメモリ２５に記憶する。例えば、第１ユニット１０１は、ＣＡＮフレームを取得した場合には、ＣＡＮＩＤと第１～８データとで構成される標準フォーマットデータを作成する。ここで、標準フォーマットデータに含まれる識別情報（第２識別情報）は、通信フレームから抽出した識別情報（第１識別情報）と同一でなくとも良い。例えば、第１識別情報を用いてユニークな第２識別情報を生成しても良いし、通信プロトコルの識別情報と第１識別情報とを用いて変換し第２識別情報を生成しても良い。
　なお、第１ユニット１０１は、作成した標準フォーマットデータと同一の識別情報を含む標準フォーマットデータが既にフラッシュメモリ２５に記憶されている場合には、その標準フォーマットデータに上書きして記憶することによって、標準フォーマットデータを更新する。つまり、フラッシュメモリ２５には、同一の識別情報に関し、最新の標準フォーマットデータが記憶されている。
　次に、第２ユニット１０２が実行するデータ標準化処理の手順を説明する。データ標準化処理は、マイクロコンピュータ１１の動作中において繰り返し実行される処理である。
　データ標準化処理が実行されると、第２コア２２は、図７に示すように、まずＳ１０にて、予め設定されている標準化実行条件が成立しているか否かを判断する。
　標準化実行条件は、後述する第１高頻度標準化条件、第２高頻度標準化条件、第３高頻度標準化条件、第１低頻度標準化条件、第２低頻度標準化条件、イベント標準化条件および不変標準化条件の少なくとも何れか一つが成立することである。
　第１高頻度標準化条件は、予め設定された第１高頻度標準化周期（例えば、本実施形態では５００ｍｓ）が経過することである。
　第２高頻度標準化条件は、予め設定された第２高頻度標準化周期（例えば、本実施形態では２ｓ）が経過することである。
　第３高頻度標準化条件は、予め設定された第３高頻度標準化周期（例えば、本実施形態では４ｓ）が経過することである。
　第１低頻度標準化条件は、予め設定された第１低頻度標準化周期（例えば、本実施形態では３０ｓ）が経過することである。
　第２低頻度標準化条件は、予め設定された第２低頻度標準化周期（例えば、本実施形態では３００ｓ）が経過することである。
　イベント標準化条件は、予め設定されたイベント標準化周期（例えば、本実施形態では１２時間）が経過することである。
　不変標準化条件は、今回のＳ１０の処理が、マイクロコンピュータ１１が起動してから初回のＳ１０の処理であることである。
　ここで、標準化実行条件が成立していない場合には、第２コア２２は、データ標準化処理を終了する。一方、標準化実行条件が成立している場合には、第２コア２２は、Ｓ２０にて、標準化実行条件を構成する７つの標準化条件のうち、成立している標準化条件に対応している標準フォーマットデータをフラッシュメモリ２５から取得する。例えば、第２高頻度標準化条件が成立している場合には、第２コア２２は、Ｓ２０にて、第２高頻度標準化条件に対応している標準フォーマットデータを取得する。
　そして第２コア２２は、Ｓ３０にて、標準フォーマットデータに含まれるデータを分割する。例えば、ＣＡＮフレームから生成された標準フォーマットデータは、ＣＡＮＩＤと、第１～８データとで構成されているため、第２コア２２は、第１～８データを１バイト毎に分割し、８つのＣＡＮデータを抽出する。
　さらに第２コア２２は、Ｓ４０にて、ＲＯＭ２３に格納された車両データ変換テーブル２３ａを参照して、Ｓ３０で分割された各抽出データを、制御ラベルおよび車両データに変換する。制御ラベルは、当該車両データの種別を示す識別情報である。
　車両データ変換テーブル２３ａは、正規化情報と、意味化情報とを備える。
　正規化情報は、車種および車両製造企業に関わらず同一の物理量が同一の値になるように抽出データを正規化するための情報である。
　意味化情報とは、正規化された車両データを用いて、意味のある車両データに変換するための情報（例えば演算式、変換テーブル）である。正規化される前の車両データを用いてもよい。意味化とは、通信フレームのペイロードには無かった情報を、演算式等を用いて新たに生成することを含む。
　車両データ変換テーブル２３ａの正規化情報は、図８に示すように、設定項目として、例えば「ＣＡＮＩＤ」、「ＥＣＵ」、「ポジション」、「ＤＬＣ」、「ユニークラベル」、「解像度」、「オフセット」および「単位」を備える。
　「ＥＣＵ」は、ＣＡＮフレームの送信元のＥＣＵを示す識別情報である。例えば、「ＥＮＧ」は、エンジンＥＣＵであることを示す。
　「ポジション」は、データフィールド内におけるＣＡＮデータの位置（例えばビット位置）を示す情報である。「ＤＬＣ」は、データ長を示す情報である。ＤＬＣは、Data Length Codeの略である。つまり、データフィールドの「ポジション」から「ＤＬＣ」ビット分のデータを取り出すこととなる。
　「ユニークラベル」は、制御ラベルを示す情報である。例えば、「ＥＴＨＡ」は吸気温を示し、「ＮＥ１」はエンジン回転数を示す。「解像度」は、１ビット当たりの数値を示す情報である。「オフセット」は当該データの数値のオフセット量を示す。「単位」は当該データの単位を示す。
　したがって、「ＣＡＮＩＤ」、「ＥＣＵ」、「ポジション」、「ＤＬＣ」および「ユニークラベル」によって、標準フォーマットデータから、「ユニークラベル」に対応するデータが抽出される。さらに抽出データは、「解像度」および「オフセット」、「単位」で表される車両データに変換される。
　また、車両データ変換テーブル２３ａの意味化情報は、例えば、図８に示すように、制御ラベルが「ＳＳＡ」である「操舵移動角度」から、制御ラベルが「ＳＳＡＺ」である「操舵ゼロ点」を減算することにより「操舵角」に変換する変換式である。これにより、「操舵移動角度」を表す車両データと、「操舵ゼロ点」を表す車両データとから、「基準位置からの操舵量」という意味を有する「操舵角」を表す車両データに変換される。意味化により新たに生成された車両データに対し、「ユニークラベル」、「単位」等を付与する。
　また、所定の制御ラベルである「シフトポジション」のデータに対しても車両データ変換テーブル２３ａを有する。車両データ変換テーブル２３ａにより、それぞれ、「Ｐレンジ」、「Ｎレンジ」、「Ｄレンジ」、「Ｒレンジ」を示すデータに変換される。
　Ｓ４０の処理が終了すると、第２コア２２は、図７に示すように、Ｓ５０にて、変換された車両データを階層化してフラッシュメモリ２５に記憶する。具体的には、第２コア２２は、変換された車両データを、フラッシュメモリ２５に設けられた標準化車両データ格納部２５ａの対応領域に格納する。
　標準化車両データ格納部２５ａは、車両データを階層化して構成される標準化車両データを格納する。
　標準化車両データは、車両毎（すなわち、データ収集装置２毎）に作成され、複数の階層構造を有している。標準化車両データでは、複数の階層のそれぞれに対して、１または複数の項目が設定されている。例えば、図９に示すように、標準化車両データは、最上位の第１階層に設定される項目として、「属性情報」、「パワトレ」、「エネルギー」、「ＡＤＡＳ／ＡＤ」、「ボデー」、「マルチメディア」および「その他」を備える。ＡＤＡＳは、Advanced Driver Assistance Systemの略である。ＡＤは、Autonomous Drivingの略である。これら「属性情報」、「パワトレ」および「エネルギー」等はカテゴリに相当する。
　また各車両データは、項目として、「ユニークラベル」、「ＥＣＵ」、「データ型」、「データサイズ」、「データ値」および「データ単位」を備える。「ユニークラベル」および「ＥＣＵ」は、前述の通りである。「データ型」、「データサイズ」および「データ単位」はそれぞれ、「データ値」で示される数値に関する型、サイズおよび単位を示す。
　図１０に示すように、標準化車両データは、第１階層に加えて、少なくとも第２階層および第３階層を備える。第２階層は第１階層の直下の階層であり、第３階層は第２階層の直下の階層である。標準化車両データは、前述した正規化および意味化の処理において設定された項目である。標準化車両データは、階層化構造となるデータ構造を有する。
　例えば、第１階層の項目である「属性情報」は、第２階層の項目として、「車両識別情報」、「車両属性」、「トランスミッション構成」および「ファームウェアバージョン」等を備える。「車両識別情報」は、車両を一意に識別できる情報を示すカテゴリ名である。「車両属性」は、車両の種類を示すカテゴリ名である。「トランスミッション情報」は、トランスミッションに関する情報を示すカテゴリ名である。「ファームウェアバージョン」は、車両のファームウェアに関する情報を示すカテゴリ名である。
　また、第１階層の項目である「パワトレ」は、パワートレーン情報を示すカテゴリ名であり、第２階層の項目として、「アクセルペダル」、「エンジン」および「エンジンオイル」等を備える。「アクセルペダル」には、アクセルペダルの状態、開度など１以上の車両データが含まれる。「エンジン」には、エンジンの状態、回転数など１以上の個々の車両データが含まれる。これら第２階層もカテゴリに相当する。他の第１階層の項目についても同様である。
　また、第１階層の項目である「エネルギー」は、エネルギー情報を示すカテゴリ名であり、第２階層の項目として、「バッテリ状態」、「バッテリ構成」および「燃料」等を備える。
　また、第２階層の項目である「車両識別情報」は、第３階層の項目として、「車両識別番号」、「車体番号」および「ナンバープレート」を備える。これら第３階層の項目は、１以上の個々の車両データ（アイテムとも言う）を含む。
　また、第２階層の項目である「車両属性」は、第３階層の項目として、「ブランド名」、「モデル」および「製造年」等を備える。
　また、第２階層の項目である「トランスミッション構成」は、第３階層の項目として、「トランスミッション種別」を備える。これら第３階層の項目は、アイテムとも言い、データ構造の最小単位である。
　例えば、第２コア２２は、変換された車両データの制御ラベルが「車両識別情報」である場合には、標準化車両データ格納部２５ａにおいて第１階層が「属性情報」であり且つ第２階層が「車両識別情報」であり且つ第３階層が「車両識別番号」である格納領域に、変換された車両データを格納する。
　次に、図１１に示すシーケンス図を用いて、データ収集装置２が標準化車両データを作成する手順を説明する。
　矢印Ｌ１１で示すように、車両Ｉ／Ｆ１２が車両から車両データを取得すると、車両Ｉ／Ｆ１２は、矢印Ｌ１２で示すように、通信プロトコル判定を行う。さらに車両Ｉ／Ｆ１２は、矢印Ｌ１３で示すように不要な車両データをフィルタリングし、矢印Ｌ１４で示すように、必要な車両データを第１ユニット１０１へ出力する。
　第１ユニット１０１は、車両Ｉ／Ｆ１２から車両データを取得すると、矢印Ｌ１５で示すように、車両データを標準フォーマットに変換し、矢印Ｌ１６で示すように、標準フォーマットに変換された車両データをフラッシュメモリ２５に記憶する。
　第２ユニット１０２は、矢印Ｌ１７で示すように、標準フォーマットに変換された車両データをフラッシュメモリ２５から取得すると、矢印Ｌ１８で示すように、取得した車両データを変換する。さらに第２ユニット１０２は、矢印Ｌ１９で示すように、変換したデータを構造化して標準化車両データを作成する。
　次に、データ収集装置２が実行するデータ送信処理の手順を説明する。データ送信処理は、マイクロコンピュータ１１の動作中において繰り返し実行される処理である。
　データ送信処理が実行されると、第２コア２２は、図１２に示すように、まずＳ１１０にて、予め設定された第１高頻度送信条件が成立したか否かを判断する。第１高頻度送信条件は、現在時刻をｔｘ、送信間隔設定値（例えば、本実施形態では５００ｍｓ）をＴとして、ｍｏｄ｛ｔｘ／（Ｔ×２）｝が０であることである。
　ここで、第１高頻度送信条件が成立していない場合には、第２コア２２は、Ｓ１３０に移行する。一方、第１高頻度送信条件が成立している場合には、第２コア２２は、Ｓ１２０にて、標準化車両データを構成する車両データの中から、第１高頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ１３０に移行する。
　なお、標準化車両データを構成する車両データは、上記の第１高頻度データの他に、後述する第２高頻度データ、第３高頻度データ、第４高頻度データ、第５高頻度データ、第６高頻度データ、第１低頻度データ、第２低頻度データ、第３低頻度データ、第４低頻度データ、イベントデータおよび不変データの何れかに設定されている。そして、各車両データが第１，２，３，４，５，６高頻度データ、第１，２，３，４低頻度データ、イベントデータおよび不変データの何れに設定されているかを規定する送信頻度設定テーブルがフラッシュメモリ２５に予め記憶されている。
　Ｓ１３０に移行すると、第２コア２２は、予め設定された第２高頻度送信条件が成立したか否かを判断する。第２高頻度送信条件は、ｍｏｄ｛（ｔｘ＋Ｔ）／（Ｔ×２）｝が０であることである。
　ここで、第２高頻度送信条件が成立していない場合には、第２コア２２は、Ｓ１５０に移行する。一方、第２高頻度送信条件が成立している場合には、第２コア２２は、Ｓ１４０にて、標準化車両データを構成する車両データの中から、第２高頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ１５０に移行する。
　Ｓ１５０に移行すると、第２コア２２は、予め設定された第３高頻度送信条件が成立したか否かを判断する。第３高頻度送信条件は、ｍｏｄ｛ｔｘ／（Ｔ×８）｝が０であることである。
　ここで、第３高頻度送信条件が成立していない場合には、第２コア２２は、Ｓ１７０に移行する。一方、第３高頻度送信条件が成立している場合には、第２コア２２は、Ｓ１６０にて、標準化車両データを構成する車両データの中から、第３高頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ１７０に移行する。
　Ｓ１７０に移行すると、第２コア２２は、予め設定された第４高頻度送信条件が成立したか否かを判断する。第４高頻度送信条件は、ｍｏｄ｛（ｔｘ＋Ｔ）／（Ｔ×８）｝が０であることである。
　ここで、第４高頻度送信条件が成立していない場合には、第２コア２２は、Ｓ１９０に移行する。一方、第４高頻度送信条件が成立している場合には、第２コア２２は、Ｓ１８０にて、標準化車両データを構成する車両データの中から、第４高頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ１９０に移行する。
　Ｓ１９０に移行すると、第２コア２２は、予め設定された第５高頻度送信条件が成立したか否かを判断する。第５高頻度送信条件は、ｍｏｄ｛ｔｘ／（Ｔ×１６）｝が０であることである。
　ここで、第５高頻度送信条件が成立していない場合には、第２コア２２は、Ｓ２１０に移行する。一方、第５高頻度送信条件が成立している場合には、第２コア２２は、Ｓ２００にて、標準化車両データを構成する車両データの中から、第５高頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ２１０に移行する。
　Ｓ２１０に移行すると、第２コア２２は、予め設定された第６高頻度送信条件が成立したか否かを判断する。第６高頻度送信条件は、ｍｏｄ｛（ｔｘ＋Ｔ）／（Ｔ×１６）｝が０であることである。
　ここで、第６高頻度送信条件が成立していない場合には、第２コア２２は、Ｓ２３０に移行する。一方、第６高頻度送信条件が成立している場合には、第２コア２２は、Ｓ１８０にて、標準化車両データを構成する車両データの中から、第６高頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ２３０に移行する。
　Ｓ２３０に移行すると、第２コア２２は、予め設定された第１低頻度送信条件が成立したか否かを判断する。第１低頻度送信条件は、ｍｏｄ｛ｔｘ／（Ｔ×１２０）｝が０であることである。
　ここで、第１低頻度送信条件が成立していない場合には、第２コア２２は、Ｓ２５０に移行する。一方、第１低頻度送信条件が成立している場合には、第２コア２２は、Ｓ２４０にて、標準化車両データを構成する車両データの中から、第１低頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ２５０に移行する。
　Ｓ２５０に移行すると、第２コア２２は、図１３に示すように、予め設定された第２低頻度送信条件が成立したか否かを判断する。第２低頻度送信条件は、ｍｏｄ｛（ｔｘ＋Ｔ）／（Ｔ×１２０）｝が０であることである。
　ここで、第２低頻度送信条件が成立していない場合には、第２コア２２は、Ｓ２７０に移行する。一方、第２低頻度送信条件が成立している場合には、第２コア２２は、Ｓ２６０にて、標準化車両データを構成する車両データの中から、第２低頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ２７０に移行する。
　Ｓ２７０に移行すると、第２コア２２は、予め設定された第３低頻度送信条件が成立したか否かを判断する。第３低頻度送信条件は、ｍｏｄ｛ｔｘ／（Ｔ×１２００）｝が０であることである。
　ここで、第３低頻度送信条件が成立していない場合には、第２コア２２は、Ｓ２９０に移行する。一方、第３低頻度送信条件が成立している場合には、第２コア２２は、Ｓ２８０にて、標準化車両データを構成する車両データの中から、第３低頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ２９０に移行する。
　Ｓ２９０に移行すると、第２コア２２は、予め設定された第４低頻度送信条件が成立したか否かを判断する。第４低頻度送信条件は、ｍｏｄ｛（ｔｘ＋Ｔ）／（Ｔ×１２００）｝が０であることである。
　ここで、第４低頻度送信条件が成立していない場合には、第２コア２２は、Ｓ３１０に移行する。一方、第４低頻度送信条件が成立している場合には、第２コア２２は、Ｓ３００にて、標準化車両データを構成する車両データの中から、第４低頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ３１０に移行する。
　Ｓ３１０に移行すると、第２コア２２は、予め設定されたイベント送信条件が成立したか否かを判断する。イベント送信条件は、ｍｏｄ｛ｔｘ／（Ｔ×１７２８００）｝が０であることである。
　ここで、イベント送信条件が成立していない場合には、第２コア２２は、Ｓ３３０に移行する。一方、イベント送信条件が成立している場合には、第２コア２２は、Ｓ３２０にて、標準化車両データを構成する車両データの中から、イベントデータに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ３３０に移行する。
　Ｓ３３０に移行すると、第２コア２２は、予め設定された不変送信条件が成立したか否かを判断する。不変送信条件は、今回のＳ３３０の処理が、マイクロコンピュータ１１が起動してから初回のＳ３３０の処理であることである。
　ここで、不変送信条件が成立していない場合には、第２コア２２は、データ送信処理を終了する。一方、イベント送信条件が成立している場合には、第２コア２２は、Ｓ３４０にて、標準化車両データを構成する車両データの中から、不変データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、データ送信処理を終了する。
　図１４に示すように、時刻ｔ０が初回の送信タイミングであるとすると、時刻ｔ０に、第１高頻度データ、第３高頻度データ、第５高頻度データ、第１低頻度データ、第３低頻度データ、イベントデータおよび不変データが送信される。
　第１高頻度データは、時刻ｔ０から１０００ｍｓが経過する毎に送信される。第２高頻度データは、時刻ｔ０から５００ｍｓが経過した時刻ｔ１に送信され、その後、時刻ｔ１から１０００ｍｓが経過する毎に送信される。
　第３高頻度データは、時刻ｔ０から４ｓ経過する毎に送信される。第４高頻度データは、時刻ｔ０から２ｓが経過した時刻ｔ４に送信され、その後、時刻ｔ４から４ｓが経過する毎に送信される。
　第５高頻度データは、時刻ｔ０から８ｓ経過する毎に送信される。第６高頻度データは、時刻ｔ０から４ｓが経過した時刻に送信され、その後、８ｓが経過する毎に送信される。
　第１低頻度データは、時刻ｔ０から１分が経過する毎に送信される。第２低頻度データは、時刻ｔ０から３０ｓが経過した時刻に送信され、その後、１分が経過する毎に送信される。
　第３低頻度データは、時刻ｔ０から１０分が経過する毎に送信される。第４低頻度データは、時刻ｔ０から５分が経過した時刻に送信され、その後、１０分が経過する毎に送信される。
　イベントデータは、時刻ｔ０から１２時間が経過する毎に送信される。
　第２ユニット１０２の第２アプリケーション１０６は、解析を行う。第２アプリケーション１０６が例えば運転診断アプリである場合には、第２アプリケーション１０６は、「急ハンドル」、「急ブレーキ」および「急加速」を検出したり、「焦った運転」および「のんびり運転」といった分析結果を出力したりする。また、第２アプリケーション１０６が例えば駐車中監視アプリである場合には、第２アプリケーション１０６は、「不審者発見」および「車両内侵入」を検出する。
　第２アプリケーション１０６は、上記の検出結果または分析結果を示す情報（以下、解析情報）を管理センター３へ送信する。第２アプリケーション１０６は、上記の「急ハンドル」および「不審者発見」というような「イベント」を、検出したタイミングで管理センター３へ送信する。また第２アプリケーション１０６は、上記の「焦った運転」というような「状態」を、「状態」を判断したタイミングで管理センター３へ送信したり、定期的に管理センター３へ送信したりする。
　図１５に示すように、モビリティＧＷ１１１は、シャドウ作成部１１５と、最新インデックス作成部１１６と、最新インデックス記憶部１１７とを備える。
　シャドウ作成部１１５は、データ収集装置２から車両データまたは解析情報が送信される毎に、送信された車両データまたは解析情報を、構造化された標準化車両データの該当領域に上書きすることにより、標準化車両データを更新する。
　なお、シャドウ作成部１１５は、標準化車両データが更新される際において上記「状態」に関する解析情報が送信されていない場合には、この「状態」に対応する該当領域に前回値をコピーする。またシャドウ作成部１１５は、標準化車両データが更新される際において上記「イベント」に関する解析情報が送信されていない場合には、この「イベント」に対応する該当領域を「空欄（イベントなし）」とする。
　そしてシャドウ作成部１１５は、更新された標準化車両データを用いて、新たなシャドウ１１４を作成する。そしてシャドウ作成部１１５は、作成したシャドウ１１４をシャドウ記憶部１１２に記憶する。これにより、シャドウ記憶部１１２には、車両毎に、作成時刻が互いに異なる複数のシャドウ１１４が記憶される。一つのシャドウ１１４は、ある車両の所定時刻の車両データ群であり、図１０に示す標準化されたデータ構造で表される車両データ群を含む。なお、シャドウ作成部１１５が、通信部３２を介して、構造化された標準化車両データを受信するタイミングは、車両によってばらばらであるが、新たなシャドウ作成は、全ての車両に対し同じタイミングで行ってもよい。シャドウ作成部１１５は、新たなシャドウ作成を、全ての車両に対し一定周期で行ってもよい。シャドウ記憶部１１２には、車両毎に、過去のシャドウ１１４が蓄積されている。一定期間経過したシャドウ１１４を順次削除してもよい。
　シャドウ作成部１１５は、データ収集装置２から階層化構造に形成された標準化車両データを受信する。シャドウ作成部１１５は、標準化車両データの一部の階層化構造データを受信するとしてもよい。シャドウ作成部１１５は、更新された標準化車両データを用いて新たなシャドウ１１４を作成する際、通し番号など任意の情報を付与してシャドウ記憶部１１２に記憶してもよい。
　図１６に示すように、シャドウ１１４は、車両データ格納部１１４ａと、デバイスデータ格納部１１４ｂとを備える。
　車両データ格納部１１４ａは、データ収集装置２を搭載している車両に関するデータとして、「ｏｂｊｅｃｔ－ｉｄ」、「Ｓｈａｄｏｗ＿ｖｅｒｓｉｏｎ」および「ｍｏｂｉｌｉｔｙ－ｄａｔａ」を格納する。
　「ｏｂｊｅｃｔ－ｉｄ」は、車両を識別するための番号である。「ｏｂｊｅｃｔ－ｉｄ」は、管理する車両が管理センター３において登録される毎に付与される。
　「Ｓｈａｄｏｗ＿ｖｅｒｓｉｏｎ」は、シャドウ１１４のバージョンを示す数値であり、シャドウ１１４が作成される毎に、作成された時刻を示すタイムスタンプが設定される。
　「ｍｏｂｉｌｉｔｙ－ｄａｔａ」は、上記の標準化車両データである。
　デバイスデータ格納部１１４ｂは、データ収集装置２に搭載されているハードウェアおよびソフトウェアに関するデータとして、「ｏｂｊｅｃｔ－ｉｄ」、「ｕｐｄａｔｅ＿ｔｉｍｅ」、「ｖｅｒｓｉｏｎ」、「ｐｏｗｅｒ＿ｓｔａｔｕｓ」、「ｐｏｗｅｒ＿ｓｔａｔｕｓ＿ｔｉｍｅｓｔａｍｐ」、「ｎｏｔｉｆｙ＿ｒｅａｓｏｎ」を格納する。これら「ｖｅｒｓｉｏｎ」、「ｐｏｗｅｒ＿ｓｔａｔｕｓ」等のデータは、変化が生じたときに、標準化車両データとは別で、データ収集装置２から送信される。
　「ｏｂｊｅｃｔ－ｉｄ」は、データ収集装置２を搭載している車両を識別する文字列であり、パーティションキーとして機能する。
　「ｕｐｄａｔｅ＿ｔｉｍｅ」は、更新時刻を示す数値である。
　「ｖｅｒｓｉｏｎ」は、データ収集装置２のハードウェアおよびソフトウェアのバージョンを示す文字列である。
　「ｐｏｗｅｒ＿ｓｔａｔｕｓ」は、データ収集装置２のシステム状態（オン、オフ等）を示す文字列である。
　「ｐｏｗｅｒ＿ｓｔａｔｕｓ＿ｔｉｍｅｓｔａｍｐ」は、システム状態の通知時刻を示す数値である。
　「ｎｏｔｉｆｙ＿ｒｅａｓｏｎ」は、通知理由を示す文字列である。
　このように、シャドウ１１４は、車両データ群に加え、データ収集装置２の情報を含む。なお、デバイスデータ格納部１１４ｂは、データ収集装置２の情報をシャドウ１１４に含めず別でＲＯＭ４２に記憶してもよい。デバイスデータ格納部１１４ｂは、データ収集装置２の情報を、タイムスタンプ毎に過去のデータを蓄積するのではなく、最新のデータのみをＲＯＭ４２に記憶してもよい。
　最新インデックス作成部１１６は、シャドウ記憶部１１２から車両毎に最新のシャドウ１１４を取得し、取得したシャドウ１１４を用いて最新インデックス１１８（第１インデックスとも言う）を作成する。そして最新インデックス作成部１１６は、作成した最新インデックス１１８を最新インデックス記憶部１１７に記憶する。最新インデックス記憶部１１７には、車両毎に１つの最新インデックス１１８が記憶される。インデックスとは、シャドウ記憶部１１２からシャドウ１１４を検索する際のキーとなるパラメータ情報である。最新インデックス作成部１１６は、データ収集装置２から取得した車両データを用いたり、自身でデータを生成したりして、最新インデックス１１８を生成する。
　図１７に示すように、最新インデックス１１８は、「ｇａｔｅｗａｙ－ｉｄ」、「ｏｂｊｅｃｔ－ｉｄ」、「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」、「ｖｉｎ」、「ｌｏｃａｔｉｏｎ－ｌｏｎ」、「ｌｏｃａｔｉｏｎ－ｌａｔ」および「ｌｏｃａｔｉｏｎ－ａｌｔ」を格納する。
　「ｇａｔｅｗａｙ－ｉｄ」は、モビリティＧＷ１１１を識別する情報である。
　「ｏｂｊｅｃｔ－ｉｄ」は、データ収集装置２を搭載している車両を識別する情報である。
　「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」は、シャドウ１１４の「Ｓｈａｄｏｗ＿ｖｅｒｓｉｏｎ」に対応する。すなわち、「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」は、シャドウ１１４を識別する情報であり、タイムスタンプが設定される。
　「ｖｉｎ」は、データ収集装置２を搭載している車両固有の登録番号である。
　「ｌｏｃａｔｉｏｎ－ｌｏｎ」は、データ収集装置２を搭載している車両が存在する緯度を示す情報である。
　「ｌｏｃａｔｉｏｎ－ｌａｔ」は、データ収集装置２を搭載している車両が存在する経度を示す情報である。
　「ｌｏｃａｔｉｏｎ－ａｌｔ」は、データ収集装置２を搭載している車両が存在する高度を示す情報である。
　図１５に示すように、データ管理部１２１は、インデックス作成部１２４と、インデックス記憶部１２５とを備える。
　インデックス作成部１２４は、最新インデックス記憶部１１７から最新インデックス１１８を定期的に取得し、取得した最新インデックス１１８を用いてインデックス１２６（第２インデックスとも言う）を作成する。そしてインデックス作成部１２４は、作成したインデックス１２６をインデックス記憶部１２５に記憶する。これにより、インデックス記憶部１２５には、車両毎に、作成時刻が互いに異なる複数のインデックス１２６が記憶される。
　図１８に示すように、インデックス１２６は、「ｔｉｍｅｓｔａｍｐ」、「ｓｃｈｅｄｕｌｅ－ｔｙｐｅ」、「ｇａｔｅｗａｙ－ｉｄ」、「ｏｂｊｅｃｔ－ｉｄ」、「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」、「ｖｉｎ」、「ｌｏｃａｔｉｏｎ」および「ａｌｔ」を格納する。
　「ｔｉｍｅｓｔａｍｐ」は、ミリ秒単位で時刻を示すタイムスタンプである。
　「ｓｃｈｅｄｕｌｅ－ｔｙｐｅ」は、データ作成元のスケジューラが定期であるかイベントであるかを示す。定期である場合には「ｓｃｈｅｄｕｌｅ－ｔｙｐｅ」は「Ｒｅｐｅａｔ」に設定され、イベントである場合には「ｓｃｈｅｄｕｌｅ－ｔｙｐｅ」は「Ｅｖｅｎｔ」に設定される。
　「ｇａｔｅｗａｙ－ｉｄ」は、モビリティＧＷ１１１を識別する情報である。「ｏｂｊｅｃｔ－ｉｄ」は、データ収集装置２を搭載している車両を識別する情報である。
　「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」は、ゲートウェイのタイムスタンプであり、シャドウ１１４を識別する情報である。「ｖｉｎ」は、データ収集装置２を搭載している車両固有の登録番号である。
　「ｌｏｃａｔｉｏｎ」は、データ収集装置２を搭載している車両が存在する緯度および経度を示す情報である。「ａｌｔ」は、データ収集装置２を搭載している車両が存在する高度を示す情報である。
　ここで、最新インデックス作成部１１６および最新インデックス記憶部１１７を設けない構成とし、インデックス作成部１２４は、シャドウ記憶部１１２に記憶されるシャドウ１１４を取得してインデックス１２６を生成してもよい。望ましくは、インデックス作成部１２４は、最新インデックス記憶部１１７から取得した最新インデックス１１８を用いてインデックス１２６を生成する。これは、モビリティＧＷ１１１とデータ管理部１２１とを疎結合とする構成の一つである。
　さらに、インデックス作成部１２４およびインデックス記憶部１２５も設けない構成としてもよい。例えば、インデックス取得部１２７は、アクセスＡＰＩ１２２から指定された「ｏｂｊｅｃｔ－ｉｄ」とタイムスタンプ（「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」）とを用いて、データ取得部１１９に指定された車両データの取得を要求する。
　図１５に示すように、モビリティＧＷ１１１は、データ取得部１１９を備える。データ管理部１２１は、インデックス取得部１２７を備える。
　インデックス取得部１２７は、指定パラメータに対応する車両データをシャドウ１１４から取得するため、シャドウ１１４を特定可能なインデックスを提供する。インデックス取得部１２７は、指定時間における指定車両の指定データの取得を指示するリクエストをアクセスＡＰＩ１２２から受信すると、受信したリクエストの指定時間および指定車両に該当するインデックス１２６をインデックス記憶部１２５から取得する。
　さらにインデックス取得部１２７は、取得したインデックス１２６に基づいて特定されるシャドウ１１４を指定シャドウとして、指定シャドウにおける指定データの取得を指示するリクエストをデータ取得部１１９へ送信する。具体的には、「ｏｂｊｅｃｔ－ｉｄ」と「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」とでシャドウ１１４が一意に決まるため、インデックス取得部１２７は、「ｏｂｊｅｃｔ－ｉｄ」と「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」とを用いて、指定データの取得をデータ取得部１１９へリクエストする。
　データ取得部１１９は、インデックス取得部１２７からリクエストを受信すると、受信したリクエストが示す指定シャドウから指定データを抽出して、抽出した指定データをアクセスＡＰＩ１２２へ送信する。ここで、抽出した指定データは、インデックス取得部１２７を介してアクセスＡＰＩ１２２へ送信されてもよい。
　また、アクセスＡＰＩ１２２は、指定時間における指定車両の指定データの取得をするため、インデックス取得部１２７を介して、該当するインデックス１２６をインデックス記憶部１２５から取得し、取得したインデックス１２６（「ｏｂｊｅｃｔ－ｉｄ」と「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」）を用いてデータ取得部１１９へ指定データの取得を要求してもよい。
　図１９に示すリクエストＲＱ１，ＲＱ２，ＲＱ３は、サービス提供サーバ４がアクセスＡＰＩ１２２へ送信するリクエストの具体例である。換言すれば、アクセスＡＰＩ１２２がサービス提供サーバ４へ提供している車両データ取得用のＡＰＩである。
　リクエストＲＱ１は、「ｏｂｊｅｃｔ－ｉｄ」が「ｄｔ－０００００２」である車両と、「ｏｂｊｅｃｔ－ｉｄ」が「ｄｔ－０００００８」である車両とに対して、２０１９年８月２７日５時１７分１０．５秒から１０秒間における緯度（すなわち、「ｉｔｅｍ‐ｎａｍｅｓ」が「ｌａｔｉｔｕｄｅ」であるデータ）の取得を指示するリクエストである。
　リクエストＲＱ１を受け付けたアクセスＡＰＩ１２２を介して、インデックス取得部１２７は、「ｏｂｊｅｃｔ－ｉｄ」と時刻情報とに対応するシャドウ１１４を特定可能な「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」をインデックス記憶部１２５から取得する。そして、インデックス取得部１２７は、「ｏｂｊｅｃｔ－ｉｄ」と「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」に対応する「ｌａｔｉｔｕｄｅ」を取得するよう、データ取得部１１９に指示する。データ取得部１１９がシャドウ記憶部１１２から該当する車両データを取得し、当該車両データは、アクセスＡＰＩ１２２に送信される。
　リクエストＲＱ２は、１３５．８９７４６７０７６７７８４で表される経度と３６．１６６４３４７４０８２２７５で表される高度とで特定される左上の地点と、１３９．７８６３５６０６５６６７３で表される経度と３５．０５５３２３６３０７１１６４で表される高度とで特定される右下の地点とで特定される矩形内の領域において２０１９年８月２７日５時１７分１０．５秒から１０秒間の間に存在する車両の緯度の取得を指示するリクエストである。
　リクエストＲＱ２を受け付けたアクセスＡＰＩ１２２を介して、インデックス取得部１２７は、インデックス記憶部１２５から、指定時刻に指定領域内に存在する車両の「ｏｂｊｅｃｔ－ｉｄ」リストを取得し、当該「ｏｂｊｅｃｔ－ｉｄ」の指定時刻の「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」を取得する。そしてインデックス取得部１２７は、「ｏｂｊｅｃｔ－ｉｄ」と「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」に対応する「ｌａｔｉｔｕｄｅ」を取得するよう、データ取得部１１９に指示する。データ取得部１１９がシャドウ記憶部１１２から該当する車両データを取得し、当該車両データは、アクセスＡＰＩ１２２に送信される。
　リクエストＲＱ３は、「ｏｂｊｅｃｔ－ｉｄ」が「ｄｔ－０００００２」である車両と、「ｏｂｊｅｃｔ－ｉｄ」が「ｄｔ－０００００８」である車両とに対して、２０１９年８月２７日５時１７分１０．５秒におけるカテゴリ「ＡＤＡＳ／ＡＤ」の全項目の情報の取得を指示するリクエストである。
　リクエストＲＱ３を受け付けたアクセスＡＰＩ１２２を介して、インデックス取得部１２７は、「ｏｂｊｅｃｔ－ｉｄ」と時刻情報とに対応するシャドウ１１４を特定可能な「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」をインデックス記憶部１２５から取得する。そしてインデックス取得部１２７は、「ｏｂｊｅｃｔ－ｉｄ」と「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」に対応するカテゴリ「ＡＤＡＳ／ＡＤ」の全項目の情報を取得するよう、データ取得部１１９に指示する。データ取得部１１９がシャドウ記憶部１１２から該当する車両データを取得し、当該車両データは、アクセスＡＰＩ１２２に送信される。
　また、サービス提供サーバ４がアクセスＡＰＩ１２２へ送信するリクエストの指定データとして、上記の解析情報を指定することにより、サービス提供サーバ４が上記の解析情報を取得することが可能である。例えば、インデックス取得部１２７は、受信したリクエストの指定車両および指定時間に該当するインデックス１２６をインデックス記憶部１２５から取得する。さらにインデックス取得部１２７は、取得したインデックス１２６に基づいて特定されるシャドウ１１４を指定シャドウとして、指定シャドウにおけるカテゴリ「危険運転情報」のデータの取得を指示するリクエストをデータ取得部１１９へ送信する。なお、カテゴリ「危険運転情報」は、アイテムとして「急ハンドル」、「急ブレーキ」および「急加速」を含む。これにより、サービス提供サーバ４は、「急ハンドル」、「急ブレーキ」および「急加速」を含むデータを取得することができる。
　図５の矢印L１で示すように、サービス提供サーバ４は、アクセスＡＰＩ１２２を介してデータ管理部１２１のデジタルツイン１２３にアクセスすることによって、指定車両に対応するシャドウ１１４を特定する。そしてサービス提供サーバ４は、図４の矢印L２で示すように、指定シャドウと制御内容とを含む制御指示を、モビリティＧＷ１１１の車両制御部１１３へ送信する。これにより、車両制御部１１３は、指定シャドウに対応する車両のデータ収集装置２へ制御指示を送信する。そして、制御指示がデータ収集装置２によって受信されると、データ収集装置２を搭載する車両において、制御指示に基づいた制御が実行される。
　このように構成された管理センター３は、車両側ユニット１１０と、サービス側ユニット１２０とを備える。
　車両側ユニット１１０は、複数の車両のそれぞれに搭載された複数のデータ収集装置２とデータ通信可能に接続される。サービス側ユニット１２０は、サービス提供サーバ４とデータ通信可能に接続される。
　そして車両側ユニット１１０は、シャドウ作成部１１５を備える。
　シャドウ作成部１１５は、複数のデータ収集装置２のそれぞれから、複数の車両データが各カテゴリに分類された第１データ構造に形成された車両データ群を繰り返し取得する。そしてシャドウ作成部１１５は、車両毎に、車両を識別する車両識別情報（本実施形態では、「ｏｂｊｅｃｔ－ｉｄ」）と、車両データを取得したタイミングを識別するためのタイミング識別情報（本実施形態では、「Ｓｈａｄｏｗ＿ｖｅｒｓｉｏｎ」）とが付与された車両データ群をシャドウ１１４として作成して、車両側ユニット１１０に設けられたシャドウ記憶部１１２に第１データ構造の形で記憶する。
　サービス側ユニット１２０は、インデックス取得部１２７を備える。インデックス取得部１２７は、車両データ群を構成する複数の車両データのうち、特定の車両データ、または、特定のカテゴリを指定データとして、該当する車両データの取得を指示するリクエストをサービス提供サーバ４から受信すると、リクエストに基づいて、所定時間における所定車両の指定データを車両側ユニット１１０のシャドウ記憶部１１２から取得するよう車両側ユニット１１０へ指示する。車両側ユニット１１０は、指定された車両の指定されたシャドウ１１４から、指定データに該当する車両データをシャドウ記憶部１１２から取得し、サービス側ユニット１２０へ送信する。サービス側ユニット１２０は、送信された車両データを、リクエストしたサービス提供サーバ４へ送信する。
　このような管理センター３では、シャドウ１１４は、複数の車両データが各カテゴリに分類された第１データ構造を有しており、複数の車両データが階層構造で整理されている。このため、管理センター３は、特定の車両データのデータ名、または、特定のカテゴリのカテゴリ名によって、シャドウ１１４を構成する複数の車両データにアクセスすることができ、車両データの利用を容易にすることができる。
　なお、「特定の車両データのデータ名」とは、例えば、上記の「車両識別番号」、「車体番号」、「ナンバープレート」、「ブランド名」、「モデル」、「製造年」および「トランスミッション種別」である。また、「特定のカテゴリのカテゴリ名」とは、例えば、上記の「属性情報」、「パワトレ」、「エネルギー」、「車両識別情報」「車両属性」「トランスミッション構成」、「ファームウェアバージョン」、「アクセルペダル」、「エンジン」、「エンジンオイル」、「バッテリ状態」、「バッテリ構成」および「燃料」である。
　またシャドウ１１４は、第１データ構造に形成された車両データ群に加え、第２データ構造に形成されて車載機器の状態を示すデバイス情報を含む。車載機器は、データ収集装置２に搭載されているハードウェアである。これにより、管理センター３は、上記のデバイス情報も管理することができる。
　また、サービス側ユニット１２０のインデックス作成部１２４は、シャドウ１１４を特定するためのデータであって第３データ構造に形成されたインデックス１２６を作成し、サービス側ユニット１２０に設けられたインデックス記憶部１２５に記憶する。
　また車両側ユニット１１０は、最新インデックス作成部１１６を備える。最新インデックス作成部１１６は、複数の車両のそれぞれについて、最新のシャドウ１１４を識別するための最新インデックス１１８を作成して、車両側ユニット１１０に設けられた最新インデックス記憶部１１７に記憶する。
　またインデックス作成部１２４は、最新インデックス記憶部１１７から、最新インデックス１１８を繰り返し取得し、最新インデックス１１８に対応するシャドウ１１４を特定するための時刻情報が付与された最新インデックス１１８をインデックス１２６として作成して、サービス側ユニット１２０に設けられたインデックス記憶部１２５に記憶する。
　これにより、サービス側ユニット１２０は、インデックス１２６を参照することにより（すなわち、シャドウ１１４を直接参照することなく）、シャドウ１１４を特定する。このインデックス１２６は、シャドウ１１４を識別するための情報（すなわち、最新インデックス１１８）と、時刻情報とにより構成されているため、車両メーカー、車両および出荷時期に依存しない情報である。このため、管理センター３は、サービス開発者に、車両データの形式の差異を考慮することなくサービスを開発させることができる。
　またインデックス取得部１２７は、リクエストを受信すると、リクエストの指定時間および指定車両に該当するインデックス１２６をインデックス記憶部１２５から取得し、取得したインデックス１２６に基づいてシャドウ１１４を特定する。
　また車両側ユニット１１０は、データ取得部１１９を備える。データ取得部１１９は、インデックス取得部１２７により特定されたシャドウ１１４をシャドウ記憶部１１２から取得し、取得したシャドウ１１４から指定データを抽出してサービス側ユニット１２０へ送信する。
　これにより、管理センター３は、指定時間における指定車両の指定データをサービス提供サーバ４へ提供することができる。
　また、複数のデータ収集装置２では、車両データ群を構成する複数の車両データのそれぞれについて、互いに異なる複数の送信タイミングの何れか一つが設定される。そして車両側ユニット１１０は、複数のデータ収集装置２から、車両データ群を構成する複数の車両データのそれぞれを、車両データに設定された送信タイミングで受信する。
　これにより、管理センター３は、更新されていない車両データを無駄に受信する頻度を低減することができ、通信処理負荷を低減することができる。
　データ収集装置２は、正規化情報として「解像度」、「オフセット」が設定された車両データ変換テーブル２３ａを備える。そして車両データは、データ収集装置２が、車両からデータ収集装置２により取得されたデータを、車両データ変換テーブル２３ａの正規化情報に基づいて正規化することによって生成される。
　これにより、管理センター３は、車種および車両メーカーに依存しない形式の車両データをサービス提供サーバ４へ提供することができる。
　車両データ変換テーブル２３ａは、更に、正規化された複数の車両データを用いて生成される車両データに変換するための意味化情報を含む。そして車両データは、車載装置が、車両データ変換テーブル２３ａの意味化情報に基づいて、正規化された複数の車両データを用いて変換することによって生成される。
　これにより、管理センター３は、データ収集装置２によって車両から取得した車両データを用いて意味化された車両データをサービス提供サーバ４へ提供することができる。
　複数のカテゴリは、車両の機能またはドメインに基づいて設定される。これにより、管理センター３は、特定のカテゴリのカテゴリ名によって、特定のカテゴリに対応した機能またはドメインに関連する全ての車両データを一括して取得することができる。
　また、管理センター３のシャドウ作成部１１５は、複数のデータ収集装置２のそれぞれから、複数の車両データを解析することによって生成された解析情報を繰り返し取得し、取得した解析情報を含むシャドウ１１４を作成する。そして、上記の指定データは、さらに解析情報を含む。これにより、管理センター３は、解析後のデータを車両から取得してシャドウ１１４を管理し、様々なサービス提供者に解析後のデータを提供することができる。
　なお、車両制御部１１３は、サービス提供サーバ４からの制御指示を、サービス側ユニット１２０のアクセスＡＰＩ１２２を介して取得してもよい。サービス側ユニット１２０にアクセスＡＰＩ１２２を設け、車両側ユニット１１０に車両制御部１１３を設けることも、２つのユニットを疎結合とする構成の一つである。
　以上説明した実施形態において、管理センター３はセンターに相当し、データ収集装置２は車載装置に相当し、サービス提供サーバ４はサービス提供ユニットに相当し、インデックス取得部１２７は指示部に相当し、モビリティＩｏＴシステム１は管理システムに相当する。
　以上、本開示の一実施形態について説明したが、本開示は上記実施形態に限定されるものではなく、種々変形して実施することができる。
　本開示に記載の制御部３１およびその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサおよびメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御部３１およびその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御部３１およびその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサおよびメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されてもよい。制御部３１に含まれる各部の機能を実現する手法には、必ずしもソフトウェアが含まれている必要はなく、その全部の機能が、一つあるいは複数のハードウェアを用いて実現されてもよい。
　上記実施形態における１つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、１つの構成要素が有する１つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、１つの構成要素によって実現したり、複数の構成要素によって実現される１つの機能を、１つの構成要素によって実現したりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加または置換してもよい。
　上述した管理センター３の他、当該管理センター３を構成要素とするシステム、当該管理センター３としてコンピュータを機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実体的記録媒体、データ管理方法など、種々の形態で本開示を実現することもできる。

Claims (16)

  1. 　複数の車両のそれぞれに搭載された複数の車載装置（２）とデータ通信可能に接続される車両側ユニット（１１０）と、
    　サービス提供ユニット（４）とデータ通信可能なサービス側ユニット（１２０）とを備え、
    　前記車両側ユニットは、
    　複数の前記車載装置のそれぞれから、複数の車両データが各カテゴリに分類された第１データ構造に形成された車両データ群を繰り返し取得し、前記車両毎に、前記車両を識別する車両識別情報と、前記車両データを取得したタイミングを識別するためのタイミング識別情報とが付与された前記車両データ群をシャドウ（１１４）として作成して、前記車両側ユニットに設けられたシャドウ記憶部（１１２）に前記第１データ構造の形で記憶するように構成されたシャドウ作成部（１１５）を備え、
    　前記サービス側ユニットは、
    　前記車両データ群を構成する複数の前記車両データのうち、特定の前記車両データ、または、特定の前記カテゴリを指定データとして、該当する前記車両データの取得を指示するリクエストを前記サービス提供ユニットから受信すると、前記リクエストに基づいて、所定時間における所定車両の前記指定データを前記車両側ユニットの前記シャドウ記憶部から取得するよう前記車両側ユニットへ指示するように構成された指示部（１２７）を備えるセンター（３）。
  2. 　請求項１に記載のセンターであって、
    　前記シャドウは、前記第１データ構造に形成された前記車両データ群に加え、第２データ構造に形成されて車載機器の状態を示すデバイス情報を含むセンター。
  3. 　請求項１または請求項２に記載のセンターであって、
    　前記サービス側ユニットは、
    　前記シャドウを特定するためのデータであって第３データ構造に形成されたインデックス（１２６）を作成し、前記サービス側ユニットに設けられたインデックス記憶部（１２５）に記憶するように構成されたインデックス作成部（１２４）を備えるセンター。
  4. 　請求項３に記載のセンターであって、
    　前記車両側ユニットは、
    　複数の前記車両のそれぞれについて、最新の前記シャドウを識別するための最新インデックス（１１８）を作成して、前記車両側ユニットに設けられた最新インデックス記憶部（１１７）に記憶するように構成された最新インデックス作成部（１１６）を備え、
    　前記インデックス作成部は、
    　前記最新インデックス記憶部から、前記最新インデックスを繰り返し取得し、前記最新インデックスに対応する前記シャドウを特定するための時刻情報が付与された前記最新インデックスを前記インデックスとして作成するように構成されるセンター。
  5. 　請求項４に記載のセンターであって、
    　前記指示部は、前記リクエストを受信すると、前記所定時間および前記所定車両に該当する前記インデックスを前記インデックス記憶部から取得し、取得した前記インデックスに基づいて前記シャドウを特定するように構成され、
    　前記車両側ユニットは、
    　前記指示部により特定された前記シャドウを前記シャドウ記憶部から取得し、取得した前記シャドウから前記指定データを抽出して前記サービス側ユニットへ送信するように構成されたデータ取得部（１１９）を備えるセンター。
  6. 　請求項１～請求項５の何れか１項に記載のセンターであって、
    　複数の前記車載装置では、前記車両データ群を構成する複数の前記車両データのそれぞれについて、互いに異なる複数の送信タイミングの何れか一つが設定され、
    　前記車両側ユニットは、複数の前記車載装置から、前記車両データ群を構成する複数の前記車両データのそれぞれを、前記車両データに設定された前記送信タイミングで受信するセンター。
  7. 　請求項１～請求項６の何れか１項に記載のセンターであって、
    　前記車載装置は、正規化情報として「解像度」、「オフセット」が設定された車両データ変換テーブルを備え、
    　前記車両データは、前記車載装置が、前記車両から前記車載装置により取得されたデータを、前記車両データ変換テーブルの前記正規化情報に基づいて正規化することによって生成されるセンター。
  8. 　請求項７に記載のセンターであって、
    　前記車両データ変換テーブルは、更に、正規化された複数の前記車両データを用いて生成される前記車両データに変換するための意味化情報を含み、
    　前記車両データは、前記車載装置が、前記車両データ変換テーブルの前記意味化情報に基づいて、正規化された複数の前記車両データを用いて変換することによって生成されるセンター。
  9. 　請求項１～請求項８の何れか１項に記載のセンターであって、
    　複数の前記カテゴリは、前記車両の機能またはドメインに基づいて設定されるセンター。
  10. 　請求項１～請求項９の何れか１項に記載のセンターであって、
    　前記カテゴリは、さらに属性情報を含むセンター。
  11. 　請求項１～請求項１０の何れか１項に記載のセンターであって、
    　前記シャドウ作成部は、複数の前記車載装置のそれぞれから、複数の前記車両データを解析することによって生成された解析情報を繰り返し取得し、取得した前記解析情報を含む前記シャドウを作成し、
    　前記指定データは、さらに前記解析情報を含むセンター。
  12. 　複数の車両のそれぞれに搭載されて前記車両から車両データを取得する複数の車載装置（２）と、前記車両データを管理するセンター（３）とを備える管理システム（１）であって、
    　前記センターは、
    　複数の前記車載装置とデータ通信可能に接続される車両側ユニット（１１０）と、
    　サービス提供ユニット（４）とデータ通信可能なサービス側ユニット（１２０）とを備え、
    　前記車両側ユニットは、
    　複数の前記車載装置のそれぞれから、複数の前記車両データが各カテゴリに分類された第１データ構造に形成された車両データ群を繰り返し取得し、前記車両毎に、前記車両を識別する車両識別情報と、前記車両データを取得したタイミングを識別するためのタイミング識別情報とが付与された前記車両データ群をシャドウ（１１４）として作成して、前記車両側ユニットに設けられたシャドウ記憶部（１１２）に前記第１データ構造の形で記憶するように構成されたシャドウ作成部（１１５）を備え、
    　前記サービス側ユニットは、
    　前記車両データ群を構成する複数の前記車両データのうち、特定の前記車両データ、または、特定の前記カテゴリを指定データとして、該当する前記車両データの取得を指示するリクエストを前記サービス提供ユニットから受信すると、前記リクエストに基づいて、所定時間における所定車両の前記指定データを前記車両側ユニットの前記シャドウ記憶部から取得するよう前記車両側ユニットへ指示するように構成された指示部（１２７）を備える管理システム。
  13. 　請求項１２に記載の管理システムであって、
    　前記車載装置は、正規化情報として「解像度」、「オフセット」が設定された車両データ変換テーブルを備え、
    　前記車両データは、前記車載装置が、前記車両から前記車載装置により取得されたデータを、前記車両データ変換テーブルの前記正規化情報に基づいて正規化することによって生成される管理システム。
  14. 　請求項１３に記載の管理システムであって、
    　前記車両データ変換テーブルは、更に、正規化された複数の前記車両データを用いて生成される前記車両データに変換するための意味化情報を含み、
    　前記車両データは、前記車載装置が、前記車両データ変換テーブルの前記意味化情報に基づいて、正規化された複数の前記車両データを用いて変換することによって生成される管理システム。
  15. 　複数の車両のそれぞれに搭載された複数の車載装置（２）とデータ通信可能に接続される車両側ユニット（１１０）と、
    　サービス提供ユニット（４）とデータ通信可能なサービス側ユニット（１２０）とを備えるセンター（３）で実行される管理方法であって、
    　前記車両側ユニットが、複数の前記車載装置のそれぞれから、複数の車両データが各カテゴリに分類された第１データ構造に形成された車両データ群を繰り返し取得し、前記車両毎に、前記車両を識別する車両識別情報と、前記車両データを取得したタイミングを識別するためのタイミング識別情報とが付与された前記車両データ群をシャドウ（１１４）として作成して、前記車両側ユニットに設けられたシャドウ記憶部（１１２）に前記第１データ構造の形で記憶し、
    　前記サービス側ユニットが、前記車両データ群を構成する複数の前記車両データのうち、特定の前記車両データ、または、特定の前記カテゴリを指定データとして、該当する前記車両データの取得を指示するリクエストを前記サービス提供ユニットから受信すると、前記リクエストに基づいて、所定時間における所定車両の前記指定データを前記車両側ユニットの前記シャドウ記憶部から取得するよう前記車両側ユニットへ指示する管理方法。
  16. 　複数の車両のそれぞれに搭載された複数の車載装置（２）とデータ通信可能に接続される車両側ユニット（１１０）と、
    　サービス提供ユニット（４）とデータ通信可能なサービス側ユニット（１２０）とを備えるセンター（３）のコンピュータを、
    　前記車両側ユニットにおいて、複数の前記車載装置のそれぞれから、複数の車両データが各カテゴリに分類された第１データ構造に形成された車両データ群を繰り返し取得し、前記車両毎に、前記車両を識別する車両識別情報と、前記車両データを取得したタイミングを識別するためのタイミング識別情報とが付与された前記車両データ群をシャドウ（１１４）として作成して、前記車両側ユニットに設けられたシャドウ記憶部（１１２）に前記第１データ構造の形で記憶するように構成されたシャドウ作成部（１１５）、および、
    　前記サービス側ユニットにおいて、前記車両データ群を構成する複数の前記車両データのうち、特定の前記車両データ、または、特定の前記カテゴリを指定データとして、該当する前記車両データの取得を指示するリクエストを前記サービス提供ユニットから受信すると、前記リクエストに基づいて、所定時間における所定車両の前記指定データを前記車両側ユニットの前記シャドウ記憶部から取得するよう前記車両側ユニットへ指示するように構成された指示部（１２７）
    　として機能させるための管理プログラム。
PCT/JP2022/025586 2021-07-02 2022-06-27 センター、管理システム、管理方法および管理プログラム WO2023276957A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2023531944A JPWO2023276957A1 (ja) 2021-07-02 2022-06-27
CN202280046997.7A CN117616479A (zh) 2021-07-02 2022-06-27 中心、管理系统、管理方法以及管理程序
US18/398,490 US20240126937A1 (en) 2021-07-02 2023-12-28 Center, management system, management method, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021110901 2021-07-02
JP2021-110901 2021-07-02

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/398,490 Continuation US20240126937A1 (en) 2021-07-02 2023-12-28 Center, management system, management method, and storage medium

Publications (1)

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

Family

ID=84689935

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/025586 WO2023276957A1 (ja) 2021-07-02 2022-06-27 センター、管理システム、管理方法および管理プログラム

Country Status (4)

Country Link
US (1) US20240126937A1 (ja)
JP (1) JPWO2023276957A1 (ja)
CN (1) CN117616479A (ja)
WO (1) WO2023276957A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015176464A (ja) * 2014-03-17 2015-10-05 Ｎｅｃプラットフォームズ株式会社 通信システム、基地局、及び通信システムの制御方法
JP2020038595A (ja) * 2018-08-31 2020-03-12 株式会社デンソーテン データ収集装置、データ収集システムおよびデータ収集方法
US20200342693A1 (en) * 2019-04-29 2020-10-29 Baidu Usa Llc Data collection automation system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015176464A (ja) * 2014-03-17 2015-10-05 Ｎｅｃプラットフォームズ株式会社 通信システム、基地局、及び通信システムの制御方法
JP2020038595A (ja) * 2018-08-31 2020-03-12 株式会社デンソーテン データ収集装置、データ収集システムおよびデータ収集方法
US20200342693A1 (en) * 2019-04-29 2020-10-29 Baidu Usa Llc Data collection automation system

Also Published As

Publication number Publication date
JPWO2023276957A1 (ja) 2023-01-05
CN117616479A (zh) 2024-02-27
US20240126937A1 (en) 2024-04-18

Similar Documents

Publication Publication Date Title
JP7043736B2 (ja) 車両用電子制御装置及び車両用サービス管理システム
Chen et al. Android/OSGi-based vehicular network management system
WO2018066305A1 (ja) 車載処理装置
US20170352198A1 (en) Vehicular electronic control unit and vehicular service management system
JP5712845B2 (ja) 車両用故障診断装置
US20230169805A1 (en) Fleet data collection using a unified model to collect data from heterogenous vehicles
US11902374B2 (en) Dynamic vehicle data extraction service
WO2023276957A1 (ja) センター、管理システム、管理方法および管理プログラム
WO2023276894A1 (ja) センター、管理方法および管理プログラム
WO2023277185A1 (ja) 車載装置、データ生成方法、データ生成プログラムおよび車両システム
WO2023277032A1 (ja) モビリティサービス提供システム、モビリティサービス提供サーバ、車両データ提供方法、プログラム
WO2023276960A1 (ja) システム、センター、及び制御プログラム
US20240127646A1 (en) Mobility service base server, mobility service providing system, vehicle access control method, and storage medium
WO2023277030A1 (ja) モビリティサービス基盤サーバ、モビリティサービス提供システム、車両アクセス制御方法、プログラム
JP4259456B2 (ja) データ記録装置及びデータ記録方法
Qiu et al. A Knowledge Layer in Data-Centric Architectures in the Automotive Industry
WO2024095632A1 (ja) 車両データ収集システム、車載装置、サーバ、コンピュータプログラム、および車両データ収集方法
WO2023223819A1 (ja) 情報処理方法、通信システムおよび情報処理プログラム
JP2019219892A (ja) 交通情報処理装置、交通情報処理方法および交通情報処理プログラム
WO2023097157A1 (en) Dynamic vehicle data extraction service
CN115858203B (zh) 异构功能交互信息翻译系统及方法
CN115576952B (zh) 一种基于Unreal的车载安卓平台通信结构实现方法
JP2023104575A (ja) 情報システム、管理装置、及びエッジ装置
Feiter et al. Higher Level Protocols
CN117193267A (zh) 一种数据采集、监视系统及其管理方法

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: 22833104

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023531944

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 202280046997.7

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE