WO2023276960A1 - システム、センター、及び制御プログラム - Google Patents

システム、センター、及び制御プログラム Download PDF

Info

Publication number
WO2023276960A1
WO2023276960A1 PCT/JP2022/025590 JP2022025590W WO2023276960A1 WO 2023276960 A1 WO2023276960 A1 WO 2023276960A1 JP 2022025590 W JP2022025590 W JP 2022025590W WO 2023276960 A1 WO2023276960 A1 WO 2023276960A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
data
vehicle data
storage unit
unit
Prior art date
Application number
PCT/JP2022/025590
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 JP2023531947A priority Critical patent/JPWO2023276960A5/ja
Priority to CN202280047008.6A priority patent/CN117597678A/zh
Publication of WO2023276960A1 publication Critical patent/WO2023276960A1/ja
Priority to US18/398,874 priority patent/US20240126532A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station

Definitions

  • the present disclosure relates to a system for transmitting and processing vehicle data from an in-vehicle device to a center, a center for processing vehicle data transmitted from the in-vehicle device, and a control program for the center.
  • 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 such as GPS information is periodically collected from vehicles subject to management and the location of the vehicles subject to management is displayed on the map screen of the browser.
  • a fleet service is provided in which a company centrally manages vehicles to be managed.
  • vehicle data is sent from the in-vehicle device to the center at regular intervals, and the center manages the sent vehicle data.
  • the vehicle data sent from the in-vehicle device to the center includes various vehicle data.
  • vehicle data that changes greatly in a short time and should be sent frequently e.g. vehicle speed data
  • vehicle data that does not change in a short time and does not need to be sent very frequently e.g. water temperature
  • vehicle data when vehicle data is used in a mobility service, it may be less necessary to process the data as described above in accordance with vehicle data that changes in a short period of time, such as vehicle speed.
  • the present disclosure provide a technology capable of reducing the computational load on the center side.
  • One aspect of the present disclosure is a system comprising a plurality of in-vehicle devices mounted in each of a plurality of vehicles, and a center capable of data communication with each of the plurality of in-vehicle devices.
  • the in-vehicle device includes a first storage unit that stores vehicle data transmitted from another device in the vehicle in which the in-vehicle device is mounted, and a transmission control unit that transmits the vehicle data to the center at a first cycle. Prepare.
  • the center includes a second storage unit that stores the vehicle data sequentially transmitted from the in-vehicle device, and a third storage unit that stores an index that is information associated with the vehicle data stored in the second storage unit. Prepare.
  • the center when the center receives the vehicle data transmitted from the in-vehicle device, the center updates the vehicle data so as to add the received vehicle data to the vehicle data stored in the second storage unit; A second update unit that updates to add the index stored in the third storage unit in association with the latest vehicle data stored in the second storage unit in a second cycle that does not require synchronization with update timing. And prepare.
  • the index stored in the third storage unit can be updated in the second period different from the first period in which the vehicle data is transmitted, thereby reducing the computational load of the center. becomes possible. For example, by setting the second period to a period longer than the first period set to transmit vehicle data at high frequency, it is possible to reduce the computational load of the center.
  • the index from which the vehicle data can be extracted can be updated at appropriate timing (that is, the second period), so the computational load on the center can be reduced from this point as well.
  • Another aspect of the present disclosure is a center capable of data communication with a plurality of in-vehicle devices mounted on each of a plurality of vehicles via respective communication devices.
  • the center is a communication unit that receives vehicle data transmitted from the in-vehicle device in the first cycle, a second storage unit that stores the vehicle data, and information associated with the vehicle data stored in the second storage unit. and a third storage unit that stores the index.
  • the center updates the vehicle data stored in the second storage unit by using the received vehicle data.
  • a second update unit that updates to add the index stored in the third storage unit in association with the latest vehicle data stored in the second storage unit in a second cycle that does not require synchronization with update timing. And prepare.
  • the center of the present disclosure can update the index stored in the third storage unit in a second cycle different from the first cycle for transmitting vehicle data, thereby reducing the computational load of the center. becomes possible. Also, when vehicle data is used in a mobility service, the index from which the vehicle data can be extracted can be updated at appropriate timing (that is, the second period), so the calculation load on the center can be reduced from this point as well.
  • Yet another aspect of the present disclosure is a control program executed by a center capable of data communication with a plurality of in-vehicle devices mounted in each of a plurality of vehicles via respective communication devices.
  • the control program receives vehicle data transmitted from the in-vehicle device in the first cycle, stores the vehicle data in the second storage unit, and indexes information associated with the vehicle data stored in the second storage unit. is stored in the third storage unit.
  • the received vehicle data is used to update the vehicle data stored in the second storage unit so as to be added, and in a second cycle that does not require synchronization with the timing of this update,
  • the index stored in the third storage unit is updated so as to be associated with the latest data of the vehicle data stored in the second storage unit.
  • the index stored in the third storage unit can be updated in the second period different from the first period in which the vehicle data is transmitted, thereby reducing the computational load of the center. becomes possible. Also, when vehicle data is used in a mobility service, the index from which the vehicle data can be extracted can be updated at appropriate timing (that is, the second period), so the calculation load on the center can be reduced from this point as well.
  • FIG. 1 is a block diagram showing the configuration of a mobility IoT system according to a first embodiment;
  • 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 structure of standardized vehicle data.
  • FIG. 4 is a sequence diagram showing a procedure for creating standardized vehicle data
  • 2 is a functional block diagram showing a functional configuration of a scheduling system for data collection devices
  • FIG. It is a figure which shows the update timing according to the kind of vehicle data. It is a figure which shows the transmission period according to the kind of 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
  • FIG. 3 is a sequence diagram showing data flow in the mobility IoT system
  • It is a figure which shows the structure of the vehicle data transmitted.
  • 3 is a functional block diagram showing functional configurations of a mobility GW and a data management unit;
  • 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. 24A is a flow chart showing processing of the mobility GW
  • FIG. 24B is a flow chart showing processing of the data management unit. 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. FIG. 2 is a block diagram showing the configuration of a mobility IoT system according to a second embodiment
  • FIG. 4 is a functional block diagram functionally showing the configuration of a service-side unit
  • FIG. It is a figure which shows the structure of the index containing data other than vehicle data. It is a figure which shows the area which a vehicle drive
  • FIG. 11 is a sequence diagram showing the flow of data in the second embodiment;
  • the mobility IoT system 1 of the first embodiment has a function of managing the vehicle state on the cloud, and as shown in FIG. A center 3 and a service providing server 4 are provided. 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 flash memory 25 corresponds to the first storage unit.
  • 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 and a rule storage section 25b for storing standardized vehicle data, which will be described later.
  • the input/output unit 26 is a circuit for inputting/outputting data between the outside of the microcomputer 11 and the first core 21 and the second core 22 .
  • the bus 27 connects the first core 21, the second core 22, the ROM 23, the RAM 24, the flash memory 25, and the input/output unit 26 so that data can be input/output to each other.
  • the vehicle I/F 12 is an input/output circuit for inputting/outputting signals between the electronic control unit and sensors mounted on the vehicle.
  • the vehicle I/F 12 includes a power supply voltage input port, a general-purpose input/output port, a CAN communication port, an Ethernet communication port, and the like.
  • a CAN communication port is a port for transmitting and receiving data according to the CAN communication protocol.
  • the Ethernet communication port is a port for transmitting and receiving data based on the Ethernet communication protocol.
  • CAN is an abbreviation for Controller Area Network. CAN is a registered trademark. Ethernet is a registered trademark.
  • the communication device 13 performs data communication with the management center 3 via the wide area wireless communication network NW.
  • the storage unit 14 is a storage device for storing various data.
  • the vehicle is equipped with one ECU 210, a plurality of ECUs 220, a plurality of ECUs 230, an external communication device 240, and an internal communication network 250.
  • ECU is an abbreviation for Electronic Control Unit.
  • the ECU 210 realizes coordinated control of the vehicle as a whole by integrating the plurality of ECUs 220 .
  • the ECU 220 is provided for each domain divided according to the function of the vehicle, and mainly controls a plurality of ECUs 230 existing within that domain. Each ECU 220 is connected to a subordinate ECU 230 via a lower-layer network (for example, CAN) provided individually.
  • the ECU 220 has a function of centrally managing access rights and the like for the ECU 230 under its control and performing user authentication and the like. Domains are, for example, powertrain, body, chassis and cockpit.
  • the ECU 230 connected to the ECU 220 belonging to the powertrain domain includes, for example, the ECU 230 that controls the engine, the ECU 230 that controls the motor, and the ECU 230 that controls the battery.
  • 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 storage unit 33 includes a second storage unit 33a and a third storage unit 33b, which will be described later.
  • 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. [1-2. Function of data collection device] Next, functions of the data collection device 2 will be described.
  • 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 second application 106 also executes processing related to scheduling when transmitting vehicle data.
  • the second application 106 is configured to access the rule storage unit 25b of the flash memory 25 and refer to the transmission cycle of each vehicle data in order to execute processing related to scheduling.
  • the GPOS 105 is basic software installed in the data collection device 2 to operate various applications, and manages the second application 106 . [1-3. Functions of Management Center] Next, functions of the management center 3 will be described.
  • 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 .
  • Access API 122 is a standard interface for service providing server 4 to access mobility GW 111 and data management unit 121 .
  • the access API 122 provides the service providing server 4 with APIs for accessing vehicles and acquiring vehicle data. [1-4. Processing executed by vehicle I/F] Next, processing executed by the vehicle I/F 12 will be described.
  • 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 consists of 1st, 2nd, 3rd, 4th, 5th, 6th, 7th and 8th data of 8 bits (ie 1 byte).
  • each of the 1st to 8th data in the data field will also be referred to as CAN data.
  • vehicle I/F12 judges whether the received CAN frame is required based on CANID, when a CAN frame is received. [1-5. Processing executed by the first unit] Next, processing executed by the first unit 101 will be described.
  • 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 data from the communication frame, creates standard format data composed of the identification information and the data, The created standard format data is stored in the flash memory 25 . For example, 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 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 cycle (for example, 500 ms in the first embodiment) elapses.
  • the second high-frequency standardization condition is that a preset second high-frequency standardization cycle (for example, 2s in the first embodiment) elapses.
  • the third high-frequency standardization condition is that a preset third high-frequency standardization period (eg, 4 seconds in the first embodiment) elapses.
  • the first low-frequency standardization condition is that a preset first low-frequency standardization period (for example, 30 seconds in the first embodiment) elapses.
  • the second low-frequency standardization condition is that a preset second low-frequency standardization period (for example, 300 seconds in the first embodiment) elapses.
  • the event standardization condition is that a preset event standardization cycle (eg, 12 hours in the first embodiment) has passed. Note that the first to third high-frequency standardization periods may be employed as event standardization conditions.
  • 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 vehicle data conversion table 23a includes normalization information and semantic information.
  • the normalization information is information for normalizing the extracted data so that the same physical quantity has the same value regardless of the vehicle type or vehicle manufacturer.
  • Semantic information is information for converting normalized vehicle data into meaningful vehicle data.
  • the normalization information of the vehicle data conversion table 23a includes setting items such as "CANID”, "ECU”, “position”, “DLC”, “unique label”, “resolution”, and “offset ” and “Unit”.
  • ECU is information indicating the source ECU of the CAN frame.
  • ENG indicates an engine ECU.
  • Position is information indicating the position of CAN data in the data field.
  • DLC is information indicating the data length. DLC stands for Data Length Code.
  • Unique label is information indicating a control label. For example, "ETHA” indicates intake air temperature, and "NE1" indicates engine speed. “Resolution” is information indicating a numerical value per bit.
  • the semantic information of the vehicle data conversion table 23a is, for example, as shown in FIG. 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”. .
  • 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” 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 that indicates 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 "power train” 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”.
  • Accelelerator pedal includes one or more pieces of vehicle data such as accelerator pedal state and degree of opening.
  • Engine includes one or more individual vehicle data such as engine state, number of revolutions, and the like. These second layers also correspond to categories. The same applies to the other items of the first hierarchy.
  • Energy which is an item in the first hierarchy, 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, has “transmission type” as an item of the third hierarchy.
  • the second core 22 determines that the first layer is “attribute information” and the second layer is The converted vehicle data is stored in the storage area of "vehicle identification information" whose third layer is "vehicle identification number”.
  • the sequence diagram shown in FIG. 11 is used to describe the procedure for the data collection device 2 to create standardized vehicle data.
  • 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, the second unit 102 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. [1-8. Transmission Data Scheduling] Next, scheduling of transmission data (that is, vehicle data to be transmitted) executed by the data collection device 2 will be described. In other words, transmission interval control when the data collection device 2 transmits vehicle data to the management center 3 will be described.
  • transmission data that is, vehicle data to be transmitted
  • the scheduling system of the data collection device 2 can be realized by the rules stored in the rule storage section 25b of the flash memory 25 and the processing of the cycle control section 106a.
  • the cycle control unit 106a can be realized by the processing of the second application 106.
  • the rule is a rule for determining the transmission cycle (that is, the first cycle) to the management center 3 according to the type of vehicle data.
  • data 1 and data 2 are data whose transmission cycle is set according to a predetermined rule 1
  • data 3 and data 4 are data whose transmission cycle is set according to rule 2 different from rule 1.
  • data 5 and data 6 indicate data in which the transmission cycle is set according to rule 3, which is different from rule 1 and rule 2.
  • the initial synchronization timing indicates the timing at which vehicle data is first transmitted to the management center 3 after the data collection device 2 is activated.
  • the transmission cycle may be set for each item of vehicle data (that is, item), or may be set for each category of vehicle data.
  • vehicle data includes various types of vehicle data classified into categories such as vehicle identification information, vehicle attributes, engine, engine oil, and drive mode. Further, various vehicle data are classified into specific categories or items. For example, the category of vehicle identification information is divided into items such as vehicle identification number, vehicle body number and license plate, engine is divided into engine on/off state and engine speed, and engine oil is divided into engine oil and the like.
  • the frequency of transmission (that is, transmission frequency: transmission period) is determined from the viewpoint of the period of transmission from other electronic control units via CAN, the degree of change in vehicle data values, and the like. is set based on For example, if the frequency of transmission from other electronic control units is low in the first place, it is conceivable to lower the frequency of transmission (that is, lengthen the transmission cycle). Also, even if the frequency of transmission from other electronic control units is high, for example, the value of the cooling water temperature does not change abruptly.
  • the transmission cycle is set to be short so as to transmit at high frequency.
  • a relatively long transmission cycle is set in which transmission is performed at a low frequency that is lower than the high frequency.
  • the ECO mode operating state for saving fuel is set to a short transmission cycle corresponding to high frequency as the event data in that state.
  • the event data a longer transmission cycle than the high frequency case can be employed.
  • the vehicle identification number can be transmitted from the corresponding vehicle first, so it is set as constant data to be transmitted only at the first transmission, for example.
  • the vehicle identification number can be set to be transmitted at the first transmission from the vehicle.
  • a specific numerical value may be described as a setting value of the transmission frequency in consideration of the update timing.
  • FIG. 14 is a table showing details of transmission frequencies for rules. Note that the table showing the transmission cycle corresponding to the type of vehicle data as shown in FIG.
  • the transmission cycle of vehicle data is set by a predetermined calculation formula "mod ⁇ (tx+ ⁇ )/(Tx ⁇ ) ⁇ ".
  • this calculation formula is 0, transmission is performed.
  • first and second high-frequency data are set as high-frequency data transmitted at a cycle of one second. If the amount of data is large, the high-frequency data can be divided into multiple parts and transmitted. For example, it can be divided into halves and transmitted continuously every half cycle of the transmission cycle (for example, every 500 ms). The same applies to other vehicle data to be transmitted.
  • third and fourth high-frequency data are set as high-frequency data to be transmitted with a period of 4 seconds.
  • fifth and sixth high-frequency data are set as high-frequency data to be transmitted with a period of eight seconds.
  • first and second low-frequency data are set as low-frequency data to be transmitted in a cycle of one minute.
  • third and fourth low-frequency data are set as low-frequency data to be transmitted with a period of 10 minutes.
  • Each vehicle data set as described above is transmitted to the management center 3 by the communication device 13 at the transmission cycle corresponding to each vehicle data.
  • the vehicle data is voluntarily transmitted by the data collection device 2 to the management center 3 based on the transmission cycle. good too.
  • Procedure of data transmission processing by data collection device Next, a procedure of data transmission processing to the management center 3 executed by the data collection device 2 will be described.
  • 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. 15, 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 the first 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 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 met, as shown in FIG.
  • 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 satisfied.
  • 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. Any one of the first to sixth high-frequency transmission conditions may be used as the event transmission condition.
  • 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 invariant data among the vehicle data constituting the standardized vehicle data in S340 as standardized vehicle data. 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 data divided into two may be transmitted each time 500 ms, which is half of the transmission period, has elapsed. Note that when other data is also divided into two, each of the data divided into two may be transmitted at half the timing of the transmission cycle.
  • 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. Note that the event data may be transmitted at the timing of transmitting the first to sixth high-frequency data.
  • Vehicle data is transmitted to the scheduling system of the data collection device 2 from each sensor and each electronic control device installed in the vehicle, as indicated by an arrow L21.
  • the data collection device (ie, edge device) 2 instructs the ECU 210 having a relay function to collect data by designating which data is to be obtained from which ECU.
  • ECU 210 receives designated data transmitted from a designated ECU among data transmitted from each ECU 220 via in-vehicle communication network 250 , and transmits the data to data collection device 2 .
  • the data collection device 2 may request data transmission from each ECU 220 via the ECU 210 so that each ECU 220 transmits data.
  • the data collection device 2 normalizes and semantically receives the received vehicle data, and forms standardized vehicle data having a hierarchical structure.
  • the scheduling system sets the vehicle data transmission cycle according to the rules described above. Also, the vehicle data is divided as necessary.
  • the vehicle data is transmitted to the vehicle-side unit 110 of the management center 3 according to the set transmission cycle.
  • the scheduling system may transmit a portion of the standardized vehicle data divided or transmit the entire standardized vehicle data according to the set transmission cycle.
  • the vehicle-side unit 110 stores the received vehicle data in the second storage section 33a. That is, the received vehicle data is synchronously stored in the second storage unit 33a.
  • the second storage unit 33a includes, for example, the shadow storage unit 112 (eg, see FIG. 20).
  • the service-side unit 120 includes a third storage section 33b.
  • the service-side unit 120 stores the latest vehicle data created from the vehicle data stored in the second storage section 33a, that is, the latest index 118 (for example, see FIG. 20) capable of searching vehicle data, in the second storage section 33a. In a period different from the acquisition of the vehicle data in (1), that is, acquired asynchronously (for example, every second), and stored in the third storage unit 33b.
  • the third storage unit 33b for example, an index storage unit 125 (see, for example, FIG. 20) can be used as the third storage unit 33b.
  • the vehicle data transmitted from the data collection device 2 to the management center 3 is data structured, for example, the example shown in FIG.
  • Attributes indicates attribute information
  • firmware-version indicates the firmware version
  • mobility-id-information indicates information identifying the vehicle. This "attributes” corresponds to the attribute information in FIG.
  • mobility-id-information is, for example, “vehicle-makers-serial-number” (i.e., vehicle number), “vehicle-gegistration-no” (i.e., license plate number), “vin” (i.e., , vehicle identification number). This "mobility-id-information" corresponds to the vehicle identification information in FIG.
  • the data collection device 2 forms the vehicle data into a data structure as shown in FIG. 10 or 19, and then transmits it to the management center 3.
  • mobility GW 111 includes shadow creation unit 115 , latest index creation unit 116 , and latest index storage unit 117 .
  • the shadow creation unit 115 Each time vehicle data is transmitted from the data collection device 2 in a transmission cycle (that is, the first cycle) set according to the type of vehicle data, the shadow creation unit 115 structures the transmitted vehicle data.
  • the standardized vehicle data is updated by overwriting the corresponding area of the standardized vehicle data.
  • the shadow creating 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.
  • Shadow creation unit 115 receives standardized vehicle data formed in a hierarchical structure from 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 .
  • a single shadow 114 is a vehicle data group of a certain vehicle at a predetermined time, and includes a vehicle data group represented by the standardized data structure shown in FIG.
  • 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. good.
  • the shadow creating unit 115 may create new shadows for all vehicles at regular intervals. Past shadows 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 standardized vehicle data is overwritten (that is, updated) in the first period, and the sequentially updated standardized vehicle data is stored as shadow 114 in the shadow storage unit 112 . That is, the vehicle data stored in the shadow 114 is updated according to the time. In the case of vehicle data with a long transmission cycle, shadow 114 stores the value of vehicle data received last time.
  • the shadow 114 may be created in the cloud not at the timing when the vehicle data is received from the data collection device 2 (that is, at the first cycle), but at the third cycle which is unrelated to the first cycle. good. In addition, since data is sent from the data collecting device 2 at the transmission cycle for each vehicle data, in the above-described embodiment, the shadow 114 was created each time. The shadow 114 may be created at the timing (that is, the third cycle).
  • the vehicle data received from the data collection device 2 is stored in the empty area of the shadow storage unit 112 in the structure of the standardized vehicle data (for example, as a temporary shadow), and at the timing of the third cycle, the shadow-version A shadow 114 may be created and stored in the shadow storage unit 112 .
  • the third period is set shorter than the second period, it may be the same as the second period or may be set longer than the second period. Data is transmitted from the shadow 114 to the index 126 in the second cycle.
  • 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. For example, multiple shadows 114 corresponding to a vehicle have the same "object-id”.
  • an "object-id" is assigned to identify the vehicle.
  • 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 pieces of information are separate from the standardized vehicle data, and are transmitted from the data collection device 2 when changes occur.
  • 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 (for example, off, on, 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.
  • 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 (for example, also called 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.
  • the latest index 118 and an index 126 are parameter information that serve as keys when searching for the shadow 114 from the shadow storage unit 112. That is, the latest index 118 and the index 126 are data that are configured from part of the vehicle data (that is, standardized vehicle data) and that are associated with the vehicle data. Note that the latest index 118 is parameter information based on the latest vehicle data.
  • 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 storage unit 117 stores the latest index 118 for each vehicle every first cycle.
  • 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 acquires the latest index 118 from the latest index storage unit 117 at each predetermined cycle (that is, a second cycle different from the first cycle), that is, periodically (for example, every second).
  • the latest index 118 is used to create an index 126 (eg, also called a second index).
  • the index creating 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 index 126 stored in the index storage unit 125 is created every second period as described above, the index 126 for each vehicle is stored in the index storage unit 125 every second period. be. Thus, the index 126 is updated every second cycle.
  • 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 configuration may be such that the latest index creation unit 116 and the latest index storage unit 117 are not provided, and the index creation unit 124 acquires the shadow 114 stored in the shadow storage unit 112 and creates 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 may request the data acquisition unit 119 to acquire specified vehicle data using the object-id and time stamp (for example, shadow-version) specified from the access API 122 .
  • the mobility GW 111 determines in S410 whether vehicle data has been received. Here, if the determination is affirmative, the process proceeds to S420, and if the determination is negative, the process is once terminated.
  • the standardized vehicle data is overwritten based on the received vehicle data, and the shadow 114 is created and stored in the shadow storage unit 112.
  • the latest index 118 is created based on the shadow 114, stored in the latest index storage unit 117, and this processing ends.
  • the data management unit 121 determines whether or not it is time to create and store the index 126 (that is, the second cycle for updating the index 126). judge.
  • the process proceeds to S520, and if a negative determination is made, the present process is temporarily terminated.
  • the index 126 is created based on the latest index 118 stored in the latest index storage unit 117, stored in the index storage unit 125, and this process is temporarily terminated.
  • 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 126 that can identify the shadow 114 in order to acquire vehicle data corresponding to the designated parameter from the shadow 114 .
  • the index acquisition unit 127 when 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. do.
  • 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 specified 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 data acquisition unit acquires the specified data using 'object-id' and 'shadow-version'. request to 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 specified data may be sent 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 in order to acquire the specified data of the specified vehicle at the specified time.
  • 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. 25 are specific examples of requests that the service providing server 4 sends 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 126 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 126 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 126 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 transmits a control instruction including the designated shadow and control details to the vehicle control unit 113 of the mobility GW 111, as indicated by the 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. Then, when the control instruction is received by the data collection device 2, the vehicle on which the data collection device 2 is mounted executes control based on the control instruction. [1-11. effects, etc.] (1a)
  • the mobility IoT system 1 of the first embodiment includes a plurality of data collection devices 2 mounted on each of a plurality of vehicles, a management center 3 capable of data communication with each of the plurality of data collection devices 2, Prepare.
  • the data collection device 2 is configured to store vehicle data transmitted from other devices in the vehicle in which the data collection device 2 is mounted, in the flash memory 25, for example. Further, for example, the second core 22 is configured to transmit vehicle data to the management center 3 in the first period.
  • the management center 3 stores the vehicle data sequentially transmitted from the data collection device 2 in the shadow storage unit 112 as, for example, a shadow 114, and updates the latest index 118 including part of the vehicle data and associated with the vehicle data. It is configured to be stored in the index storage unit 117 . Also, an index 126 created from the latest index 118 is stored in the index storage unit 125 .
  • the management center 3 uses the received vehicle data to store the shadow 114 stored in the shadow storage unit 112 and the latest index storage unit 117. update the latest index 118. Also, the latest index 118 is used to update the index 126 stored in the index storage unit 125 in a second cycle (for example, a constant cycle) that does not require synchronization with the timing of updating the vehicle data.
  • a second cycle for example, a constant cycle
  • the index 126 stored in the index storage unit 125 can be updated in a second cycle different from the first cycle in which vehicle data is transmitted. can be reduced. For example, by setting the second period to a period longer than the first period set so as to send vehicle data at high frequency, it is possible to reduce the calculation load of the management center 3 .
  • the index 126 from which the vehicle data can be extracted can be updated at an appropriate timing (i.e., the second cycle), which also reduces the computational load of the management center 3. can.
  • 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 mobility IoT system 1 of the first embodiment uses the index 126 stored in the index storage unit 125 in response to a request from the service providing server 4 capable of data communication with the mobility IoT system.
  • the vehicle data stored in the storage unit 112 can be provided to the service providing server 4 .
  • an appropriate transmission cycle is determined according to the type of vehicle data. That is, the transmission cycle of vehicle data with high update frequency is set shorter than the transmission cycle of vehicle data with low update frequency. This makes it possible to reduce the amount of transmission data as much as possible.
  • the scheduling function described above can optimize the vehicle status data update frequency for each vehicle data, so that the amount of data and communication overhead can be reduced.
  • the mobility IoT system 1 corresponds to the system
  • the management center 3 corresponds to the center
  • the data collection device 2 corresponds to the in-vehicle device
  • the service providing server 4 corresponds to the service providing unit.
  • the communication device 13 corresponds to the communication device
  • the second core 22 corresponds to the transmission control section
  • the flash memory 25 corresponds to the first storage section
  • the communication section 32 corresponds to the communication section
  • the unit 33a corresponds to the second storage unit
  • the third storage unit 33b to the third storage unit
  • the mobility GW 111 to the first update unit
  • the data management unit 121 to the second update unit.
  • the data management unit 121 (that is, the second update unit) stores the data in the shadow storage unit 112 (that is, the second storage unit 33a).
  • the stored shadow 114 may be searched, the latest index 118 equivalent may be extracted, and the data (ie, the index 126) stored in the index storage unit 125 (ie, the third storage unit 33b) may be updated.
  • the mobility IoT system 1 (for example, the management center 3) may have the function of the service providing server 4.
  • the management center 3 communicates with the service providing server 4 and another external service server 201 to acquire necessary external data (for example, data on weather and traffic conditions).
  • necessary external data for example, data on weather and traffic conditions.
  • the mobility IoT system 1 includes a management center 3 and a service providing server 4 as in the first embodiment.
  • the management center 3 includes a service side unit 120 and a vehicle side unit 110 .
  • each vehicle is equipped with a data collection device 2 .
  • an external service server 201 is connected to the management center 3 so that data communication is possible.
  • the external service server 201 is a server capable of supplying weather information such as rain and information such as road congestion conditions (for example, information other than vehicle data).
  • weather information such as rain (that is, weather information), road traffic conditions (that is, traffic congestion information), etc. are sent from the external service server 201. information can be obtained.
  • the management center 3 can acquire vehicle data from the data collection device 2 in the first cycle.
  • the service-side unit 120 can acquire the latest index 118 from the vehicle-side unit 110 at a second cycle different from the first cycle (for example, at regular time intervals).
  • the service-side instance 203 of the service-side unit 120 performs time management, and based on information in a database 205 (that is, DB) that manages events, an event instructing a predetermined operation is sent to a predetermined time. Issued every period.
  • the service-side unit 120 acquires the latest index 118 created from the vehicle data included in each shadow 114, as in the first embodiment. Then, an index 126 is created from the latest index 118 and stored in the index storage unit 125 (that is, DB).
  • the service-side unit 120 acquires external data based on the event. That is, weather information and traffic congestion information are acquired by requesting the weather information and traffic congestion information from the external service server 201 via the API.
  • the weather information includes information indicating which range (for example, a rectangular range defined by latitude and longitude) is the rain range at a certain time.
  • the congestion information includes information indicating which range is the range of congestion at a certain time.
  • the weather information and traffic congestion information are stored in the index storage unit 125 in association with the index 126 of the vehicle data.
  • FIG. 29 shows the structure of an index associated with weather information and traffic congestion information (hereinafter referred to as a composite index).
  • the above-mentioned “object-id” (that is, the ID of the vehicle), “location” (that is, the plane position of the vehicle), “alt” (that is, the height of the vehicle), and “timestamp” (that is, time) is stored, and information about "event” is stored.
  • This information about "event” indicates the rectangular range of the event. For example, as shown in FIG. 30, the rain range is indicated by a rectangle on the plane showing the ground. [2-3. motion] Next, the overall operation of the mobility IoT system 1 of the second embodiment will be described.
  • each vehicle data is separately transmitted from the data collection device 2 to the vehicle-side unit 110 in the first period.
  • the service-side unit 120 acquires the latest index 118 from the vehicle-side unit 110 in a second period different from the first period.
  • the service-side unit 120 requests weather information and the like from the external service server 201 at the timing of issuing a predetermined event.
  • the external service server 201 transmits weather information and the like to the service side unit 120 in response to the request.
  • the service-side unit 120 associates and stores the latest index 118 obtained from the vehicle-side unit 110 and the weather information and the like obtained from the external service server 201 . That is, a composite index as shown in FIG. 29 is created and stored in the index storage unit 125, for example.
  • the service providing server 4 requests the speed of a vehicle traveling in the rain in a certain area at a certain time via the access API 122, the service side unit , the corresponding composite index is extracted from the index storage unit 125 of .
  • the shadow storage unit 112 of the vehicle-side unit 110 is accessed, the vehicle and vehicle speed that satisfy the above conditions are extracted from the shadow 114 of the shadow storage unit 112, and the vehicle speed information is Send to the service providing server 4 .
  • the service providing server 4 can acquire vehicle speed information that satisfies the desired conditions.
  • the second embodiment has the same effect as the first embodiment.
  • data other than vehicle data is associated (that is, integrated) with the index (that is, compound index) 126 stored in the third storage unit 33b and stored.
  • the data other than the vehicle data is data supplied from an external server other than the service providing server 4 (that is, the external service server 201).
  • a composite index is created by adding the weather information and the traffic information obtained from the external service server 201 .
  • a more advanced service can be provided in response to a request from the service providing server 4.
  • the servicer can acquire vehicle data that meets the conditions simply by specifying the vin, time, and location (i.e., latitude and longitude) of the vehicle for which data is desired. Service can be easily provided.
  • the servicer uses the API to set the time, place range, and event (for example, rain range), so that only vehicles that are in the rain area within the predetermined place range at that time, Vehicle data can be obtained.
  • event for example, rain range
  • the arrangements and techniques for controlling the systems and centers described in this disclosure are accomplished by configuring a processor and memory programmed to perform one or more functions embodied by a computer program. It may be implemented by a provided dedicated computer. Alternatively, the configuration and techniques for controlling the systems and centers 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 arrangements and techniques for controlling the systems and centers described in this disclosure may be implemented by a processor and memory and one or more hardware logic circuits programmed to perform one or more functions. It may also be implemented by one or more dedicated computers configured in combination with configured processors.
  • the computer program may also be stored in a computer-readable non-transitional tangible recording medium as instructions executed by a computer.
  • the method of realizing the function of each part included in the system 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 each of the above embodiments 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 each of the above embodiments may be omitted. Also, at least part of the configuration of each of the above embodiments may be added or replaced with respect to the configuration of each of the above embodiments.
  • the present disclosure can be implemented in various ways, such as a method implemented by the system, a method implemented by the in-vehicle device, and a method implemented by the center. Furthermore, the present disclosure can be realized in various forms such as a program for making a computer function as a system, an in-vehicle device, or a center, a non-transitional material recording medium such as a semiconductor memory that records this program, and a data management method. can.

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の略である。これら「属性情報」、「パワトレ」および「エネルギー」等はカテゴリに相当する。
　また各車両データは、項目として、「ユニークラベル」、「ＥＣＵ」、「データ型」、「データサイズ」、「データ値」および「データ単位」を備える。「ユニークラベル」及び「ＥＣＵ」は、前述の通りである。「データ型」、「データサイズ」及び「データ単位」は、「データ値」で示される数値に関する型、サイズ、単位を示す。
　図１０に示すように、標準化車両データは、第１階層に加えて、少なくとも第２階層および第３階層を備える。第２階層は第１階層の直下の階層であり、第３階層は第２階層の直下の階層である。標準化車両データは、前述した正規化および意味化の処理において設定された項目である。標準化車両データは、階層化構造となるデータ構造を有する。
　例えば、第１階層の項目である「属性情報」は、第２階層の項目として、「車両識別情報」、「車両属性」、「トランスミッション構成」および「ファームウェアバージョン」等を備える。
　「車両識別情報」は、車両を一意に識別できる情報を示すカテゴリ名である。「車両属性」は、車両の種類を示すカテゴリ名である。「トランスミッション情報」は、トランスミッションに関する情報を示すカテゴリ名である。「ファームウェアバージョン」は、車両のファームウェアに関する情報を示すカテゴリ名である。
　また、第１階層の項目である「パワトレ」は、パワートレイン情報を示すカテゴリ名であり、第２階層の項目として、「アクセルペダル」、「エンジン」および「エンジンオイル」等を備える。
　「アクセルペダル」には、アクセルペダルの状態、開度など１以上の車両データが含まれる。「エンジン」には、エンジンの状態、回転数など１以上の個々の車両データが含まれる。これら第２階層もカテゴリに相当する。他の第１階層の項目についても同様である。
　また、第１階層の項目である「エネルギー」は、第２階層の項目として、「バッテリ状態」、「バッテリ構成」および「燃料」等を備える。
　また、第２階層の項目である「車両識別情報」は、第３階層の項目として、「車両識別番号」、「車体番号」および「ナンバープレート」を備える。これら第３階層の項目は、１以上の個々の車両データ（アイテムとも言う）を含む。
　また、第２階層の項目である「車両属性」は、第３階層の項目として、「ブランド名」、「モデル」および「製造年」等を備える。
　また、第２階層の項目である「トランスミッション構成」は、第３階層の項目として、「トランスミッション種別」を備える。
　なお、これら項目のことをアイテムとも呼び、下位階層を有する項目のことをカテゴリとも呼ぶ。
　例えば、第２コア２２は、変換された車両データの制御ラベルが「車両識別情報」である場合には、標準化車両データ格納部２５ａにおいて第１階層が「属性情報」であり且つ第２階層が「車両識別情報」であり且つ第３階層が「車両識別番号」である格納領域に、変換された車両データを格納する。
［１－７．標準化車両データの作成手順］
　次に、図１１に示すシーケンス図を用いて、データ収集装置２が標準化車両データを作成する手順を説明する。
　矢印Ｌ１１で示すように、車両Ｉ／Ｆ１２が車両から車両データを取得すると、車両Ｉ／Ｆ１２は、矢印Ｌ１２で示すように、通信プロトコル判定を行う。さらに車両Ｉ／Ｆ１２は、矢印Ｌ１３で示すように不要な車両データをフィルタリングし、矢印Ｌ１４で示すように、必要な車両データを第１ユニット１０１へ出力する。
　第１ユニット１０１は、車両Ｉ／Ｆ１２から車両データを取得すると、矢印Ｌ１５で示すように、車両データを標準フォーマットに変換し、矢印Ｌ１６で示すように、標準フォーマットに変換された車両データをフラッシュメモリ２５に記憶する。
　第２ユニット１０２は、矢印Ｌ１７で示すように、標準フォーマットに変換された車両データをフラッシュメモリ２５から取得すると、矢印Ｌ１８で示すように、取得した車両データを変換する。さらに第２ユニット１０２は、矢印Ｌ１９で示すように、変換したデータを構造化して標準化車両データを作成する。
［１－８．送信データのスケジューリング］
　次に、データ収集装置２が実行する送信データ（即ち、送信される車両データ）のスケジューリングについて説明する。つまり、データ収集装置２が管理センター３へ車両データを送信する際の送信間隔制御について説明する。
　図１２に示すように、データ収集装置２のスケジューリングシステムは、フラッシュメモリ２５のルール記憶部２５ｂに記憶されたルールと、周期制御部１０６ａの処理と、により実現できる。なお、周期制御部１０６ａは、第２アプリケーション１０６の処理により実現できる。
　前記ルールとは、車両データの種類に応じて管理センター３への送信周期（即ち、第１周期）を決定するためのルールである。なお、図１２において、種類がデータ１及びデータ２は、所定のルール１に従って送信周期を設定したデータを示し、データ３及びデータ４は、ルール１とは異なるルール２に従って送信周期を設定したデータを示し、データ５及びデータ６は、ルール１及びルール２とは異なるルール３に従って送信周期を設定したデータを示している。
　なお、スケジューリングにおける前記ルールの設定項目としては、「項目」、「送信頻度」、「初期同期タイミング」、「カテゴリ」等が含まれる。初期同期タイミングとは、データ収集装置２の起動後、最初に車両データを管理センター３へ送信するタイミングを示す。車両データの項目（即ち、アイテム）単位で送信周期を設定してもよいし、車両データのカテゴリ単位で送信周期を設定してもよい。
　以下、具体的に説明する。
　図１３に示すように、車両データとして、例えば、車両識別情報、車両属性、エンジン、エンジンオイル、ドライブモード等のカテゴリに分けられた各種の車両データがある。更に、各種の車両データは、それぞれ具体的なカテゴリ又はアイテムに分類されている。例えば、車両識別情報というカテゴリは、車両識別番号、車体番号及びナンバープレートというアイテムに区分され、エンジンはエンジンオンオフ状態及びエンジン回転数に区分され、エンジンオイルはエンジンオイル等に区分されている。
　これらの区分された車両データについては、送信する頻度（即ち、送信頻度：送信周期）は、ＣＡＮを介して他の電子制御装置から送信される周期の観点や、車両データ値の変化の程度などに基づいて設定されている。例えば、他の電子制御装置からの送信の頻度がそもそも低い場合には、送信頻度を低く（即ち、送信周期を長く）することが考えられる。また、他の電子制御装置からの送信の頻度が高い場合でも、例えば、冷却水温の値は急には変化しないので、送信頻度を低く（即ち、送信周期を長く）することが考えられる。
　具体的には、例えば、エンジン回転数は短時間で変化するので、高頻度で送信するように短い送信周期に設定されている。例えば、エンジンオイルの温度は短時間では変化しないので、前記高頻度より頻度が低い低頻度で送信する相対的に長い送信周期に設定されている。例えば、燃料を節約するＥＣＯモード動作状態は、その状態となったイベントデータとして、例えば、高頻度に対応した短い送信周期に設定されている。なお、イベントデータについては、前記高頻度の場合に比べて長い送信周期を採用することもできる。例えば、車両識別番号は、該当する車両から最初に送信すればいいので、不変データとして、例えば、初回の送信時のみ送信するように設定されている。具体的には、例えば、前記車両のイグニッションスイッチをオンした後に、当該車両からの初回の送信時に車両識別番号を送信するように設定することができる。なお、図１３に示すルールのテーブルとして、更新タイミングを考慮した送信頻度の設定値として、具体的な数値を記載してもよい。
　さらに、図１４に示すように、高頻度で送信する車両データ（即ち、高頻度データ）や低頻度で送信する車両データ（即ち、低頻度データ）は、送信の必要性に応じて一層細かく分類されていてもよい。図１４は、ルールに関し送信頻度の詳細を示すテーブルである。なお、前記図１４に示すような車両データの種類に応じた送信周期を示すテーブルは、例えば、データ収集装置２のルール記憶部２５ｂに予め記憶されている。
　例えば、後に詳述するように、所定の算出式「ｍｏｄ｛（ｔｘ＋β）／（Ｔ×α）｝」により、車両データの送信周期が設定される。なお、この算出式が０の場合に、送信が行われる。
　具体的には、例えば、１秒の周期で送信する高頻度データとして、第１、第２高頻度データが設定されている。なお、データ量が多い場合には、この高頻度データを、複数に分割して送信することができる。例えば、半分に分割して、前記送信周期の半分の周期毎（例えば、５００ｍｓ毎）に連続して送信することができる。なお、他の送信する車両データも同様である。
　また、例えば、４秒の周期で送信する高頻度データとして、第３、第４高頻度データが設定されている。さらに、例えば、８秒の周期で送信する高頻度データとして、第５、第６高頻度データが設定されている。
　また、例えば、１分の周期で送信する低頻度データとして、第１、第２低頻度データが設定されている。さらに、例えば、１０分の周期で送信する低頻度データとして、第３、第４低頻度データが設定されている。
　上述したようにして設定された各車両データは、通信機１３により、各車両データに対応した送信周期に、管理センター３に送信される。
　なお、前記各車両データは、前記送信周期に基づいてデータ収集装置２が自発的に管理センター３に送信するが、管理センター３側からの指示によって、前記ルールや送信周期を変更できるようにしてもよい。
［１－９．データ収集装置によるデータ送信処理の手順］
　次に、データ収集装置２が実行する管理センター３へのデータ送信処理の手順を説明する。データ送信処理は、マイクロコンピュータ１１の動作中において繰り返し実行される処理である。
　データ送信処理が実行されると、第２コア２２は、図１５に示すように、まずＳ１１０にて、予め設定された第１高頻度送信条件が成立したか否かを判断する。第１高頻度送信条件は、現在時刻をｔｘ、送信間隔設定値（例えば、本第１実施形態では５００ｍｓ）をＴとして、ｍｏｄ｛ｔｘ／（Ｔ×２）｝が０であることである。
　ここで、第１高頻度送信条件が成立していない場合には、第２コア２２は、Ｓ１３０に移行する。一方、第１高頻度送信条件が成立している場合には、第２コア２２は、Ｓ１２０にて、標準化車両データを構成する車両データの中から、第１高頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ１３０に移行する。
　Ｓ１３０に移行すると、第２コア２２は、予め設定された第２高頻度送信条件が成立したか否かを判断する。第２高頻度送信条件は、ｍｏｄ｛（ｔｘ＋Ｔ）／（Ｔ×２）｝が０であることである。
　ここで、第２高頻度送信条件が成立していない場合には、第２コア２２は、Ｓ１５０に移行する。一方、第２高頻度送信条件が成立している場合には、第２コア２２は、Ｓ１４０にて、標準化車両データを構成する車両データの中から、第２高頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ１５０に移行する。
　Ｓ１５０に移行すると、第２コア２２は、予め設定された第３高頻度送信条件が成立したか否かを判断する。第３高頻度送信条件は、ｍｏｄ｛ｔｘ／（Ｔ×８）｝が０であることである。
　ここで、第３高頻度送信条件が成立していない場合には、第２コア２２は、Ｓ１７０に移行する。一方、第３高頻度送信条件が成立している場合には、第２コア２２は、Ｓ１６０にて、標準化車両データを構成する車両データの中から、第３高頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ１７０に移行する。
　Ｓ１７０に移行すると、第２コア２２は、予め設定された第４高頻度送信条件が成立したか否かを判断する。第４高頻度送信条件は、ｍｏｄ｛（ｔｘ＋Ｔ）／（Ｔ×８）｝が０であることである。
　ここで、第４高頻度送信条件が成立していない場合には、第２コア２２は、Ｓ１９０に移行する。一方、第４高頻度送信条件が成立している場合には、第２コア２２は、Ｓ１８０にて、標準化車両データを構成する車両データの中から、第４高頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ１９０に移行する。
　Ｓ１９０に移行すると、第２コア２２は、予め設定された第５高頻度送信条件が成立したか否かを判断する。第５高頻度送信条件は、ｍｏｄ｛ｔｘ／（Ｔ×１６）｝が０であることである。
　ここで、第５高頻度送信条件が成立していない場合には、第２コア２２は、Ｓ２１０に移行する。一方、第５高頻度送信条件が成立している場合には、第２コア２２は、Ｓ２００にて、標準化車両データを構成する車両データの中から、第５高頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ２１０に移行する。
　Ｓ２１０に移行すると、第２コア２２は、予め設定された第６高頻度送信条件が成立したか否かを判断する。第６高頻度送信条件は、ｍｏｄ｛（ｔｘ＋Ｔ）／（Ｔ×１６）｝が０であることである。
　ここで、第６高頻度送信条件が成立していない場合には、第２コア２２は、Ｓ２３０に移行する。一方、第６高頻度送信条件が成立している場合には、第２コア２２は、Ｓ１８０にて、標準化車両データを構成する車両データの中から、第６高頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ２３０に移行する。
　Ｓ２３０に移行すると、第２コア２２は、予め設定された第１低頻度送信条件が成立したか否かを判断する。第１低頻度送信条件は、ｍｏｄ｛ｔｘ／（Ｔ×１２０）｝が０であることである。
　ここで、第１低頻度送信条件が成立していない場合には、第２コア２２は、Ｓ２５０に移行する。一方、第１低頻度送信条件が成立している場合には、第２コア２２は、Ｓ２４０にて、標準化車両データを構成する車両データの中から、第１低頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ２５０に移行する。
　Ｓ２５０に移行すると、第２コア２２は、図１６に示すように、予め設定された第２低頻度送信条件が成立したか否かを判断する。第２低頻度送信条件は、ｍｏｄ｛（ｔｘ＋Ｔ）／（Ｔ×１２０）｝が０であることである。
　ここで、第２低頻度送信条件が成立していない場合には、第２コア２２は、Ｓ２７０に移行する。一方、第２低頻度送信条件が成立している場合には、第２コア２２は、Ｓ２６０にて、標準化車両データを構成する車両データの中から、第２低頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ２７０に移行する。
　Ｓ２７０に移行すると、第２コア２２は、予め設定された第３低頻度送信条件が成立したか否かを判断する。第３低頻度送信条件は、ｍｏｄ｛ｔｘ／（Ｔ×１２００）｝が０であることである。
　ここで、第３低頻度送信条件が成立していない場合には、第２コア２２は、Ｓ２９０に移行する。一方、第３低頻度送信条件が成立している場合には、第２コア２２は、Ｓ２８０にて、標準化車両データを構成する車両データの中から、第３低頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ２９０に移行する。
　Ｓ２９０に移行すると、第２コア２２は、予め設定された第４低頻度送信条件が成立したか否かを判断する。第４低頻度送信条件は、ｍｏｄ｛（ｔｘ＋Ｔ）／（Ｔ×１２００）｝が０であることである。
　ここで、第４低頻度送信条件が成立していない場合には、第２コア２２は、Ｓ３１０に移行する。一方、第４低頻度送信条件が成立している場合には、第２コア２２は、Ｓ３００にて、標準化車両データを構成する車両データの中から、第４低頻度データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ３１０に移行する。
　Ｓ３１０に移行すると、第２コア２２は、予め設定されたイベント送信条件が成立したか否かを判断する。イベント送信条件は、ｍｏｄ｛ｔｘ／（Ｔ×１７２８００）｝が０であることである。なお、イベント送信条件としては、第１～第６高頻度送信条件のいずれかを採用してもよい。
　ここで、イベント送信条件が成立していない場合には、第２コア２２は、Ｓ３３０に移行する。一方、イベント送信条件が成立している場合には、第２コア２２は、Ｓ３２０にて、標準化車両データを構成する車両データの中から、イベントデータに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、Ｓ３３０に移行する。
　Ｓ３３０に移行すると、第２コア２２は、予め設定された不変送信条件が成立したか否かを判断する。不変送信条件は、今回のＳ３３０の処理が、マイクロコンピュータ１１が起動してから初回のＳ３３０の処理であることである。
　ここで、不変送信条件が成立していない場合には、第２コア２２は、データ送信処理を終了する。一方、不変送信条件が成立している場合には、第２コア２２は、Ｓ３４０にて、標準化車両データを構成する車両データの中から、不変データに設定されている車両データを標準化車両データ格納部２５ａから抽出して、管理センター３へ送信し、データ送信処理を終了する。
　図１７に示すように、時刻ｔ０が初回の送信タイミングであるとすると、時刻ｔ０に、第１高頻度データ、第３高頻度データ、第５高頻度データ、第１低頻度データ、第３低頻度データ、イベントデータおよび不変データが送信される。
　第１高頻度データは、時刻ｔ０から１０００ｍｓが経過する毎に送信される。なお、データを２分割する場合には、送信周期の半分の５００ｍｓが経過する毎に、各２分割されたデータを送信してもよい。なお、他のデータも２分割する場合には、送信周期の半分のタイミングで各２分割されたデータを送信してもよい。
　第２高頻度データは、時刻ｔ０から５００ｍｓが経過した時刻ｔ１に送信され、その後、時刻ｔ１から１０００ｍｓが経過する毎に送信される。
　第３高頻度データは、時刻ｔ０から４ｓ経過する毎に送信される。第４高頻度データは、時刻ｔ０から２ｓが経過した時刻ｔ４に送信され、その後、時刻ｔ４から４ｓが経過する毎に送信される。
　第５高頻度データは、時刻ｔ０から８ｓ経過する毎に送信される。第６高頻度データは、時刻ｔ０から４ｓが経過した時刻に送信され、その後、８ｓが経過する毎に送信される。
　第１低頻度データは、時刻ｔ０から１分が経過する毎に送信される。第２低頻度データは、時刻ｔ０から３０ｓが経過した時刻に送信され、その後、１分が経過する毎に送信される。
　第３低頻度データは、時刻ｔ０から１０分が経過する毎に送信される。第４低頻度データは、時刻ｔ０から５分が経過した時刻に送信され、その後、１０分が経過する毎に送信される。
　イベントデータは、時刻ｔ０から１２時間が経過する毎に送信される。なお、イベントデータは、第１～第６高頻度データを送信するタイミングで送信してもよい。
　ここで、図１８に示すシーケンス図を用いて、車両とデータ収集装置２と管理センター３との間のデータの流れを、まとめて説明する。
　矢印Ｌ２１に示すように、車両に配置された各センサや各電子制御装置から、データ収集装置２のスケジューリングシステムに車両データが送信される。
　具体的には（例えば、図２６参照）、データ収集装置（即ち、エッジ装置）２は、中継機能を有するＥＣＵ２１０に対し、どのＥＣＵからどのデータを取得するか指定してデータ収集を指示する。ＥＣＵ２１０は、車内通信網２５０を介し、各ＥＣＵ２２０から送信されるデータのうち指定されたＥＣＵから送信される指定データを受信し、データ収集装置２へ送信する。データ収集装置２は、各ＥＣＵ２２０がデータを送信するよう、ＥＣＵ２１０を介して各ＥＣＵ２２０にデータ送信を要求してもよい。データ収集装置２は、受信した車両データを正規化・意味化し、階層構造である標準化車両データに形成する。
　スケジューリングシステムは、上述したルールに従って車両データの送信周期を設定する。また、必要に応じて車両データを分割する。
　そして、矢印Ｌ２２に示すように、設定された送信周期に従って、車両データを、管理センター３の車両側ユニット１１０に送信する。なお、スケジューリングシステムは、設定された送信周期に従って、標準化車両データの分割された一部を送信してもよいし、標準化車両データの全部を送信してもよい。
　車両側ユニット１１０では、受信した車両データを第２記憶部３３ａに記憶する。つまり、受信した車両データを第２記憶部３３ａに同期して記憶する。なお、第２記憶部３３ａとしては、例えば、シャドウ記憶部１１２（例えば、図２０参照）等が挙げられる。
　また、後述するように、サービス側ユニット１２０は、第３記憶部３３ｂを備えている。サービス側ユニット１２０では、第２記憶部３３ａに記憶された車両データから作成された最新車両データ、即ち、車両データを検索可能な最新インデックス１１８（例えば、図２０参照）を、第２記憶部３３ａの車両データの取得とは異なる周期で、即ち、非同期で（例えば、１秒毎に）取得し、第３記憶部３３ｂに記憶する。なお、第３記憶部３３ｂとしては、例えば、インデックス記憶部１２５（例えば、図２０参照）が挙げられる。
　なお、データ収集装置２から管理センター３に送信される車両データはデータ構造化されており、例えば図１９に示す例が挙げられる。
　この車両データのうち、「ａｔｔｒｉｂｕｔｅｓ」は、属性情報を示し、「ｆｉｒｍｗａｒｅ－ｖｅｒｓｉｏｎ」は、ファームウェアのバージョンを示し、「ｍｏｂｉｌｉｔｙ－ｉｄ－ｉｎｆｏｒｍａｔｏｎ」は、車両を特定する情報を示す。この「ａｔｔｒｉｂｕｔｅｓ」は、図１０の属性情報に該当する。
　なお、「ｍｏｂｉｌｉｔｙ－ｉｄ－ｉｎｆｏｒｍａｔｏｎ」は、例えば、「ｖｅｈｉｃｌｅ－ｍａｋｅｒｓ－ｓｅｒｉａｌ－ｎｕｍｂｅｒ」（即ち、車体番号）、「ｖｅｈｉｃｌｅ－ｇｅｇｉｓｔｒａｔｉｏｎ－ｎｏ」（即ち、ナンバープレートの番号）、「ｖｉｎ」（即ち、車両識別番号）である。この「ｍｏｂｉｌｉｔｙ－ｉｄ－ｉｎｆｏｒｍａｔｏｎ」は、図１０の車両識別情報に該当する。
　このように、データ収集装置２は、車両データを、図１０又は図１９に示すようなデータ構造に形成した上で、管理センター３へ送信する。
　なお、送信データは、データ圧縮およびｂａｓｅ６４エンコードされている。
［１－１０．モビリティＧＷとデータ管理部の構成］
　図２０に示すように、モビリティＧＷ１１１は、シャドウ作成部１１５と、最新インデックス作成部１１６と、最新インデックス記憶部１１７とを備える。
　シャドウ作成部１１５は、データ収集装置２から車両データが、車両データの種類に応じて設定された送信周期（即ち、第１周期）で送信される毎に、送信された車両データを、構造化された標準化車両データの該当領域に上書きすることにより、標準化車両データを更新する。
　そしてシャドウ作成部１１５は、更新された標準化車両データを用いて、新たなシャドウ１１４を作成する。そしてシャドウ作成部１１５は、作成したシャドウ１１４をシャドウ記憶部１１２に記憶する。これにより、シャドウ記憶部１１２には、車両毎に、作成時刻が互いに異なる複数のシャドウ１１４が記憶される。
　シャドウ作成部１１５は、データ収集装置２から階層化構造に形成された標準化車両データを受信する。シャドウ作成部１１５は、標準化車両データの一部の階層化構造データを受信するとしてもよい。シャドウ作成部１１５は、更新された標準化車両データを用いて新たなシャドウ１１４を作成する際、通し番号など任意の情報を付与してシャドウ記憶部１１２に記憶してもよい。
　一つのシャドウ１１４は、ある車両の所定時刻の車両データ群であり、図１０に示す標準化されたデータ構造で表される車両データ群を含む。なお、通信部３２を介してシャドウ作成部１１５が構造化された標準化車両データを受信するタイミングは、車両によってばらばらであるが、新たなシャドウ作成は、全ての車両に対し同じタイミングで行っても良い。シャドウ作成部１１５は、新たなシャドウ作成を、全ての車両に対し一定周期で行っても良い。シャドウ記憶部１１２には、車両毎に、過去のシャドウが蓄積されている。一定期間経過したシャドウ１１４を順次削除してもよい。
　これにより、第１周期で標準化車両データが上書き（即ち、更新）されるとともに、シャドウ記憶部１１２に、順次更新された標準化車両データがシャドウ１１４として記憶される。つまり、時刻に応じてシャドウ１１４に記憶される車両データが更新される。なお、送信周期が長い車両データの場合、シャドウ１１４には、前回受信した車両データの値が記憶される。
　なお、下記のような構成を採用してもよい。
　クラウドでのシャドウ１１４作成を、データ収集装置２から車両データを受信したタイミング（即ち、第１周期）で行うのではなく、第１周期とは関係の無い第３周期で行うよう構成してもよい。
　また、データ取集装置２から車両データごとの送信周期でデータが送られてくるので、前述の実施形態では、その都度シャドウ１１４を作成していたが、車両データを受信したタイミングとは関係ないタイミング（即ち、第３周期）にて、シャドウ１１４を作成するようにしてもよい。
　さらに、シャドウ記憶部１１２の空き領域に、データ収集装置２から受信した車両データを標準化車両データの構造で（例えば、仮のシャドウとして）記憶しておき、第３周期のタイミングで、shadow-version等を付与したシャドウ１１４を作成して、シャドウ記憶部１１２に記憶してもよい。
　なお、第３周期は、第２周期より短く設定されるが、第２周期と同じであってもよく、第２周期より長く設定されてもよい。なお、シャドウ１１４からインデックス１２６に第２周期にてデータが送信される。
　図２１に示すように、シャドウ１１４は、車両データ格納部１１４ａと、デバイスデータ格納部１１４ｂとを備える。
　車両データ格納部１１４ａは、データ収集装置２を搭載している車両に関するデータとして、「ｏｂｊｅｃｔ－ｉｄ」、「Ｓｈａｄｏｗ＿ｖｅｒｓｉｏｎ」および「ｍｏｂｉｌｉｔｙ－ｄａｔａ」を格納する。
　「ｏｂｊｅｃｔ－ｉｄ」は、車両を識別するための番号である。例えば、ある車両に対応する複数のシャドウ１１４では、同じ「ｏｂｊｅｃｔ－ｉｄ」を有する。なお、ある車両の車両データが最初に管理センター３に受信された場合に、その車両を識別するために、「ｏｂｊｅｃｔ－ｉｄ」が付与される。
　「Ｓｈａｄｏｗ＿ｖｅｒｓｉｏｎ」は、シャドウ１１４のバージョンを示す数値であり、シャドウ１１４が作成される毎に、作成された時刻を示すタイムスタンプが設定される。
　「ｍｏｂｉｌｉｔｙ－ｄａｔａ」は、上記の標準化車両データである。
　デバイスデータ格納部１１４ｂは、データ収集装置２に搭載されているハードウェアおよびソフトウェアに関するデータとして、「ｏｂｊｅｃｔ－ｉｄ」、「ｕｐｄａｔｅ＿ｔｉｍｅ」、「ｖｅｒｓｉｏｎ」、「ｐｏｗｅｒ＿ｓｔａｔｕｓ」、「ｐｏｗｅｒ＿ｓｔａｔｕｓ＿ｔｉｍｅｓｔａｍｐ」、「ｎｏｔｉｆｙ＿ｒｅａｓｏｎ」を格納する。これらの情報は、前記標準化車両データとは別で、変化が生じた際にデータ収集装置２から送信される。
　「ｏｂｊｅｃｔ－ｉｄ」は、データ収集装置２を搭載している車両を識別する文字列であり、パーティションキーとして機能する。
　「ｕｐｄａｔｅ＿ｔｉｍｅ」は、更新時刻を示す数値である。
　「ｖｅｒｓｉｏｎ」は、データ収集装置２のハードウェアおよびソフトウェアのバージョンを示す文字列である。
　「ｐｏｗｅｒ＿ｓｔａｔｕｓ」は、データ収集装置２のシステム状態（例えば、オフ、オン等）を示す文字列である。
　「ｐｏｗｅｒ＿ｓｔａｔｕｓ＿ｔｉｍｅｓｔａｍｐ」は、システム状態の通知時刻を示す数値である。
　「ｎｏｔｉｆｙ＿ｒｅａｓｏｎ」は、通知理由を示す文字列である。
　このように、シャドウ１１４は、車両データ群に加え、データ収集装置２の情報を含む。なお、デバイスデータ格納部１１４ｂは、データ収集装置２の情報をシャドウに含めず別でROM４２に記憶してもよい。デバイスデータ格納部１１４ｂは、データ収集装置２の情報を、タイムスタンプ毎に過去のデータを蓄積するのではなく、最新のデータのみをROM４２に記憶してもよい。
　最新インデックス作成部１１６は、シャドウ記憶部１１２から車両毎に最新のシャドウ１１４を取得し、取得したシャドウ１１４を用いて最新インデックス１１８（例えば、第１インデックスともいう）を作成する。そして最新インデックス作成部１１６は、作成した最新インデックス１１８を最新インデックス記憶部１１７に記憶する。最新インデックス記憶部１１７には、車両毎に１つの最新インデックス１１８が記憶される。
　最新インデックス１１８及び後述するインデックス１２６とは、シャドウ記憶部１１２からシャドウ１１４を検索する際のキーとなるパラメータ情報である。つまり、最新インデックス１１８やインデックス１２６は、車両データ（即ち、標準化車両データ）の一部から構成されるとともに車両データに関連付けされたデータである。なお、最新インデックス１１８とは、最新の車両データに基づいたパラメータ情報である。最新インデックス作成部１１６は、データ収集装置２から取得した車両データを用いたり、自身でデータを生成したりして、最新インデックス１１８を生成する。
　つまり、シャドウ記憶部１１２に記憶される車両データは、上述したように第１周期毎に更新されるので、最新インデックス記憶部１１７には、第１周期毎に、各車両毎の最新インデックス１１８が記憶されることになる。
　図２２に示すように、最新インデックス１１８は、「ｇａｔｅｗａｙ－ｉｄ」、「ｏｂｊｅｃｔ－ｉｄ」、「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」、「ｖｉｎ」、「ｌｏｃａｔｉｏｎ－ｌｏｎ」、「ｌｏｃａｔｉｏｎ－ｌａｔ」および「ｌｏｃａｔｉｏｎ－ａｌｔ」を格納する。
　「ｇａｔｅｗａｙ－ｉｄ」は、モビリティＧＷ１１１を識別する情報である。
　「ｏｂｊｅｃｔ－ｉｄ」は、データ収集装置２を搭載している車両を識別する情報である。
　「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」は、シャドウ１１４の「Ｓｈａｄｏｗ＿ｖｅｒｓｉｏｎ」に対応する。すなわち、「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」は、シャドウ１１４を識別する情報であり、タイムスタンプが設定される。
　「ｖｉｎ」は、データ収集装置２を搭載している車両固有の登録番号である。
　「ｌｏｃａｔｉｏｎ－ｌｏｎ」は、データ収集装置２を搭載している車両が存在する緯度を示す情報である。
　「ｌｏｃａｔｉｏｎ－ｌａｔ」は、データ収集装置２を搭載している車両が存在する経度を示す情報である。
　「ｌｏｃａｔｉｏｎ－ａｌｔ」は、データ収集装置２を搭載している車両が存在する高度を示す情報である。
　前記図２０に示すように、データ管理部１２１は、インデックス作成部１２４と、インデックス記憶部１２５とを備える。
　インデックス作成部１２４は、最新インデックス記憶部１１７から最新インデックス１１８を所定周期（即ち、第１周期とは異なる第２周期）毎に、即ち定期的（例えば、１秒毎）に取得し、取得した最新インデックス１１８を用いてインデックス１２６（例えば、第２インデックスともいう）を作成する。そして、インデックス作成部１２４は、作成したインデックス１２６をインデックス記憶部１２５に記憶する。これにより、インデックス記憶部１２５には、車両毎に、作成時刻が互いに異なる複数のインデックス１２６が記憶される。
　つまり、インデックス記憶部１２５に記憶されるインデックス１２６は、上述したように第２周期毎に作成されるので、インデックス記憶部１２５には、第２周期毎に、各車両毎のインデックス１２６が記憶される。このようにして、第２周期毎に、インデックス１２６が更新される。
　図２３に示すように、インデックス１２６は、「ｔｉｍｅｓｔａｍｐ」、「ｓｃｈｅｄｕｌｅ－ｔｙｐｅ」、「ｇａｔｅｗａｙ－ｉｄ」、「ｏｂｊｅｃｔ－ｉｄ」、「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」、「ｖｉｎ」、「ｌｏｃａｔｉｏｎ」および「ａｌｔ」を格納する。
　「ｔｉｍｅｓｔａｍｐ」は、ミリ秒単位で時刻を示すタイムスタンプである。
　「ｓｃｈｅｄｕｌｅ－ｔｙｐｅ」は、データ作成元のスケジューラが定期であるかイベントであるかを示す。定期である場合には「ｓｃｈｅｄｕｌｅ－ｔｙｐｅ」は「Ｒｅｐｅａｔ」に設定され、イベントである場合には「ｓｃｈｅｄｕｌｅ－ｔｙｐｅ」は「Ｅｖｅｎｔ」に設定される。
　「ｇａｔｅｗａｙ－ｉｄ」は、モビリティＧＷ１１１を識別する情報である。「ｏｂｊｅｃｔ－ｉｄ」は、データ収集装置２を搭載している車両を識別する情報である。
　「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」は、ゲートウェイのタイムスタンプであり、シャドウ１１４を識別する情報である。「ｖｉｎ」は、データ収集装置２を搭載している車両固有の登録番号である。
　「ｌｏｃａｔｉｏｎ」は、データ収集装置２を搭載している車両が存在する緯度および経度を示す情報である。「ａｌｔ」は、データ収集装置２を搭載している車両が存在する高度を示す情報である。
　ここで、最新インデックス作成部１１６及び最新インデックス記憶部１１７を設けない構成とし、インデックス作成部１２４は、シャドウ記憶部１１２に記憶されるシャドウ１１４を取得してインデックス１２６を生成してもよい。望ましくは、インデックス作成部１２４は、最新インデックス記憶部１１７から取得した最新インデックス１１８を用いてインデックス１２６を生成する。これは、モビリティGW１１１とデータ管理部１２１とを疎結合とする構成の一つである。
　さらに、インデックス作成部１２４及びインデックス記憶部１２５も設けない構成としてもよい。例えば、インデックス取得部１２７は、アクセスAPI１２２から指定されたobject-idとタイムスタンプ（例えば、shadow-version）を用いて、データ取得部１１９に指定された車両データの取得を要求してもよい。
　ここで、上述したモビリティＧＷ１１１とデータ管理部１２１における処理の流れについて、まとめて説明する。
　図２４Ａに示すように、モビリティＧＷ１１１では、Ｓ４１０にて、車両データを受信したか否かを判定する。ここで、肯定判断されるとＳ４２０に進み、一方否定判断されると一旦本処理を終了する。
　Ｓ４２０では、受信した車両データに基づいて標準化車両データを上書きするとともに、シャドウ１１４を作成して、シャドウ記憶部１１２に記憶する。
　続く４３０では、シャドウ１１４に基づいて、最新インデックス１１８を作成して、最新インデックス記憶部１１７に記憶し、一旦本処理を終了する。
　一方、図２４Ｂに示すように、データ管理部１２１では、Ｓ５１０にて、インデックス１２６を作成して記憶する一定のタイミング（即ち、インデックス１２６を更新するための第２周期）であるか否かを判定する。ここで、肯定判断されるとＳ５２０に進み、一方否定判断されると一旦本処理を終了する。
　Ｓ５２０では、最新インデックス記憶部１１７に記憶された最新インデックス１１８に基づいてインデックス１２６を作成して、インデックス記憶部１２５に記憶し、一旦本処理を終了する。
　また、前記図２０に示すように、モビリティＧＷ１１１は、データ取得部１１９を備える。データ管理部１２１は、インデックス取得部１２７を備える。
　インデックス取得部１２７は、指定パラメータに対応する車両データをシャドウ１１４から取得するため、シャドウ１１４を特定可能なインデックス１２６を提供する。
　また、インデックス取得部１２７は、指定時間における指定車両の指定データの取得を指示するリクエストをアクセスＡＰＩ１２２から受信すると、受信したリクエストの指定時間および指定車両に該当するインデックス１２６をインデックス記憶部１２５から取得する。
　さらに、インデックス取得部１２７は、取得したインデックス１２６に基づいて特定されるシャドウ１１４を指定シャドウとして、指定シャドウにおける指定データの取得を指示するリクエストをデータ取得部１１９へ送信する。具体的には、「ｏｂｊｅｃｔ－ｉｄ」と「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」とでシャドウ１１４が一意に決まるので、「ｏｂｊｅｃｔ－ｉｄ」と「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」とを用いて、指定データの取得をデータ取得部１１９へ要求する。
　データ取得部１１９は、インデックス取得部１２７からリクエストを受信すると、受信したリクエストが示す指定シャドウから指定データを抽出して、抽出した指定データをアクセスＡＰＩ１２２へ送信する。
　ここで、抽出した指定データは、インデックス取得部１２７を介してアクセスＡＰＩ１２２へ送信されてもよい。
　また、アクセスＡＰＩ１２２は、指定時間における指定車両の指定データの取得をするため、インデックス取得部１２７を介して該当するインデックス１２６をインデックス記憶部１２５から取得し、取得したインデックス１２６（例えば、object-idとshadow-version）を用いてデータ取得部１１９へ指定データの取得を要求してもよい。
　図２５に示すリクエストＲＱ１，ＲＱ２，ＲＱ３は、サービス提供サーバ４がアクセスＡＰＩ１２２へ送信するリクエストの具体例である。換言すれば、アクセスＡＰＩ１２２がサービス提供サーバ４へ提供している車両データ取得用のＡＰＩである。
　リクエストＲＱ１は、「ｏｂｊｅｃｔ－ｉｄ」が「ｄｔ－０００００２」である車両と、「ｏｂｊｅｃｔ－ｉｄ」が「ｄｔ－０００００８」である車両とに対して、２０１９年８月２７日５時１７分１０．５秒から１０秒間における緯度（すなわち、「ｉｔｅｍ‐ｎａｍｅｓ」が「ｌａｔｉｔｕｄｅ」であるデータ）の取得を指示するリクエストである。
　リクエストＲＱ１を受け付けたアクセスＡＰＩ１２２を介して、インデックス取得部１２７は、「object-id」と時刻情報とに対応するシャドウ１１４を特定可能な「shadow-version」をインデックス記憶部１２６から取得する。そして、インデックス取得部１２７は、「object-id」と「shadow-version」に対応する「latitude」を取得するよう、データ取得部１１９に指示する。データ取得部１１９がシャドウ記憶部１１２から該当する車両データを取得し、当該車両データは、アクセスＡＰＩ１２２に送信される。
　リクエストＲＱ２は、１３５．８９７４６７０７６７７８４で表される経度と３６．１６６４３４７４０８２２７５で表される高度とで特定される左上の地点と、１３９．７８６３５６０６５６６７３で表される経度と３５．０５５３２３６３０７１１６４で表される高度とで特定される右下の地点とで特定される矩形内の領域において２０１９年８月２７日５時１７分１０．５秒から１０秒間の間に存在する車両の緯度の取得を指示するリクエストである。
　リクエストＲＱ２を受け付けたアクセスＡＰＩ１２２を介して、インデックス取得部１２７は、インデックス記憶部１２６から、指定時刻に指定領域内に存在する車両の「object-id」リストを取得し、当該「object-id」の指定時刻の「shadow-version」を取得する。そして、インデックス取得部１２７は、「object-id」と「shadow-version」に対応する「latitude」を取得するよう、データ取得部１１９に指示する。データ取得部１１９がシャドウ記憶部１１２から該当する車両データを取得し、当該車両データは、アクセスＡＰＩ１２２に送信される。
　リクエストＲＱ３は、「ｏｂｊｅｃｔ－ｉｄ」が「ｄｔ－０００００２」である車両と、「ｏｂｊｅｃｔ－ｉｄ」が「ｄｔ－０００００８」である車両とに対して、２０１９年８月２７日５時１７分１０．５秒におけるカテゴリ「ＡＤＡＳ／ＡＤ」の全項目の情報の取得を指示するリクエストである。
　リクエストＲＱ３を受け付けたアクセスＡＰＩ１２２を介して、インデックス取得部１２７は、「object-id」と時刻情報とに対応するシャドウ１１４を特定可能な「shadow-version」をインデックス記憶部１２６から取得する。そして、インデックス取得部１２７は、「object-id」と「shadow-version」に対応するカテゴリ「ＡＤＡＳ／ＡＤ」の全項目の情報を取得するよう、データ取得部１１９に指示する。データ取得部１１９がシャドウ記憶部１１２から該当する車両データを取得し、当該車両データは、アクセスＡＰＩ１２２に送信される。
　上述した構成の管理センター３においては、前記図５の矢印Ｌ１で示すように、サービス提供サーバ４は、アクセスＡＰＩ１２２を介してデータ管理部１２１のデジタルツイン１２３にアクセスすることによって、指定車両に対応するシャドウ１１４を特定する。
　そしてサービス提供サーバ４は、前記図４の矢印Ｌ２で示すように、指定シャドウと制御内容とを含む制御指示を、モビリティＧＷ１１１の車両制御部１１３へ送信する。
　これにより、車両制御部１１３は、指定シャドウに対応する車両のデータ収集装置２へ制御指示を送信する。そして、制御指示がデータ収集装置２によって受信されると、データ収集装置２を搭載する車両において、制御指示に基づいた制御が実行される。
［１－１１．効果等］
　（１ａ）本第１実施形態のモビリティＩｏＴシステム１は、複数の車両のそれぞれに搭載された複数のデータ収集装置２と、当該複数のデータ収集装置２とそれぞれデータ通信可能な管理センター３と、を備える。
　データ収集装置２は、データ収集装置２が搭載された車両における他の装置から送信された車両データを、例えばフラッシュメモリ２５に記憶するように構成されている。また、例えば、第２コア２２によって、車両データを管理センター３に対して第１周期で送信するように構成されている。
　管理センター３は、データ収集装置２から順次送信された車両データを、例えばシャドウ１１４としてシャドウ記憶部１１２に記憶するとともに、車両データの一部を含み車両データと関連付けられた最新インデックス１１８を、最新インデックス記憶部１１７に記憶するように構成されている。また、最新インデックス１１８から作成されたインデックス１２６を、インデックス記憶部１２５に記憶するように構成されている。
　そして、管理センター３では、データ収集装置２から送信された車両データを受信した際には、受信した車両データを用いて、シャドウ記憶部１１２に記憶されたシャドウ１１４と最新インデックス記憶部１１７に記憶された最新インデックス１１８とを更新する。また、車両データを更新するタイミングとの同期を必要としない第２周期（例えば、一定周期）で、最新インデックス１１８を用いて、インデックス記憶部１２５に記憶されたインデックス１２６を更新する。
　これにより、本モビリティＩｏＴシステム１では、車両データを送信する第１周期とは異なる第２周期で、インデックス記憶部１２５に記憶されるインデックス１２６を更新することができるので、管理センター３の演算負荷を低減することが可能となる。例えば、高頻度で車両データを送るように設定された第１周期よりも長い周期に、第２周期を設定することにより、管理センター３の演算負荷を低減することが可能となる。
　また、モビリティサービスで車両データを利用する場合に、その車両データを抽出できるインデックス１２６を適切なタイミング（即ち、第２周期）で更新できるので、その点からも、管理センター３の演算負荷を低減できる。
　なお、車両制御部１１３は、サービス提供サーバ４からの制御指示を、サービス側ユニット１２０のアクセスＡＰＩ１２２を介して取得してもよい。サービス側ユニット１２０にアクセスＡＰＩ１２２を設け、車両側ユニット１１０に車両制御部１１３を設けることも、２つのユニットを疎結合とする構成の一つである。
　（１ｂ）本第１実施形態のモビリティＩｏＴシステム１は、モビリティＩｏＴシステムシステムとデータ通信可能なサービス提供サーバ４からの要求に応じて、インデックス記憶部１２５に記憶されるインデックス１２６を用いて、シャドウ記憶部１１２に記憶に記憶された車両データを、サービス提供サーバ４に提供することができる。
　（１ｃ）本第１実施形態のモビリティＩｏＴシステム１は、車両データを第１周期で管理センター３に送信する場合に、更新頻度が高い車両データと更新頻度が低い車両データと、があるときには、更新頻度が高い車両データの送信周期を、更新頻度が低い車両データの送信周期よりも短く設定することができる。以下、詳細に説明する。
　クラウド上で、車両状態を管理し、車両状態を即時に反映するために、車両側から管理センター３側に、一定間隔で車両データを送信することが考えられる。ところが、車両データの中には、変化が少なく更新がそれほど必要でないデータや、変化が多く頻繁な更新が望ましいデータや、一度同期されれば変わることのない属性データなどがある。
　また、車両データを送信し続けると、データ量が肥大化し、それに伴って通信量、データ管理コストが増加する。しかも、大容量のデータを送信するためには、安定した通信環境が必要であるが、車両環境は変化が激しく、安定した通信維持をすることが困難である。
　そこで、本第１実施形態では、車両データの種類に応じて適切な送信周期を定めている。つまり、更新頻度が高い車両データの送信周期を、更新頻度が低い車両データの送信周期よりも短く設定している。これにより、送信データ量を可能な限り低減することができる。
　つまり、本第１実施形態では、上述したスケジューリング機能によって、車両状態のデータ更新頻度を車両データごとに最適化できるので、データ量と通信のオーバーヘッドとを削減することができる。
　なお、以上説明した第１実施形態において、モビリティＩｏＴシステム１はシステムに相当し、管理センター３はセンターに相当し、データ収集装置２は車載装置に相当し、サービス提供サーバ４はサービス提供ユニットに相当し、通信機１３は通信機に相当し、第２コア２２は送信制御部に相当し、フラッシュメモリ２５は第１記憶部に相当し、通信部３２は通信部に相当し、第２記憶部３３ａは第２記憶部に相当し、第３記憶部３３ｂは第３記憶部に相当し、モビリティＧＷ１１１は第１更新部相当し、データ管理部１２１は第２更新部に相当する。
　＜変形例＞
　なお、上述した例以外に、例えば、最新インデックス１１８を予め持っておかなくても、データ管理部１２１（即ち、第２更新部）が、シャドウ記憶部１１２（即ち、第２記憶部３３ａ）に記憶されたシャドウ１１４を検索して、最新インデックス１１８相当を抽出して、インデックス記憶部１２５（即ち、第３記憶部３３ｂ）に記憶されたデータ（即ち、インデックス１２６）を更新するようにしてもよい。なお、モビリティＩｏＴシステム１（例えば、管理センター３）は、サービス提供サーバ４の機能を有していてもよい。
［２．第２実施形態］
　次に、第２実施形態について説明する。
　第２実施形態は、基本的な構成は第１実施形態と同様であるため、以下では主として第１実施形態との相違点について説明する。なお、第１実施形態と同じ符号は、同一構成を示すものであって、先行する説明を参照する。
　本第２実施形態では、管理センター３は、サービス提供サーバ４は別の外部サービスサーバ２０１との通信を行って、必要な外部データ（例えば、天気や交通状態のデータ）を取得するものである。
［２－１．構成］
　図２７に示すように、本第２実施形態では、モビリティＩｏＴシステム１は、第１実施形態と同様に、管理センター３、サービス提供サーバ４を備える。管理センター３は、サービス側ユニット１２０、車両側ユニット１１０を備える。また、各車両には、それぞれデータ収集装置２が搭載されている。
　特に、本第２実施形態では、管理センター３には、外部サービスサーバ２０１がデータ通信可能に接続されている。この外部サービスサーバ２０１は、雨等の天気の情報や、道路の渋滞状況等の情報（例えば、車両データ以外の情報）を供給することができるサーバである。
　従って、このモビリティＩｏＴシステム１では、管理センター３からの要求に基づいて、外部サービスサーバ２０１から、雨等の天気の情報（即ち、天気情報）や、道路の渋滞状況（即ち、渋滞情報）等の情報を取得することができる。
　なお、本第２実施形態においても、管理センター３は、第１周期で、データ収集装置２から車両データを取得することができる。サービス側ユニット１２０側は、第１周期とは異なる第２周期で（例えば、一定時間毎に）、車両側ユニット１１０から最新インデックス１１８を取得することができる。
［２－２．サービス側ユニット］
　図２８に示すように、サービス側ユニット１２０のサービス側インスタンス２０３では、時刻管理を行うとともに、イベントを管理するデータベース２０５（即ち、ＤＢ）の情報に基づいて、所定の動作を指示するイベントを所定期間毎に発行する。
　サービス側ユニット１２０では、このイベントに基づいて、第１実施形態と同様に、各シャドウ１１４に含まれる車両データから作成された最新インデックス１１８を取得する。そして、その最新インデックス１１８からインデックス１２６を作製して、インデックス記憶部１２５（即ち、ＤＢ）に記憶する。
　また、サービス側ユニット１２０は、前記イベントに基づいて、外部データの取得を行う。つまり、外部サービスサーバ２０１に対して、ＡＰＩを介して天気情報や渋滞情報をリクエストすることにより、天気情報や渋滞情報を取得する。
　なお、天気情報としては、ある時刻において、どの範囲（例えば、緯度、経度で規定される矩形範囲）が、雨の範囲であるかを示す情報が挙げられる。同様に、渋滞情報としては、ある時刻において、どの範囲が渋滞の範囲であるかを示す情報が挙げられる。
　この天気情報や渋滞情報は、例えば、前記インデックス記憶部１２５に、車両データのインデックス１２６と関連付けて記憶される。
　図２９に、天気情報や渋滞情報と関連付けられたインデックス（以下、複合インデックス）の構成を示す。
　こと複合インデックスでは、上述した「ｏｂｊｅｃｔ－ｉｄ」（即ち、車両のＩＤ）、「ｌｏｃａｔｉｏｎ」（即ち、車両の平面位置）、「ａｌｔ」（即ち、車両の高さ）、「ｔｉｍｅｓｔａｍｐ」（即ち、時刻）の情報が記憶されるとともに、「ｅｖｅｎｔ」に関する情報が記憶される。
　この「ｅｖｅｎｔ」に関する情報とは、イベントの矩形範囲を示すものである。例えば、図３０に示すように、地上を示す平面において、雨の範囲を矩形で示すものである。
［２－３．動作］
　次に、本第２実施形態のモビリティＩｏＴシステム１における全体の動作を説明する。
　図３１に示すように、データ収集装置２から車両側ユニット１１０に、各車両データが第１周期にてバラバラに送信される。
　サービス側ユニット１２０は、第１周期とは異なる第２周期にて、車両側ユニット１１０から最新インデックス１１８を取得する。
　また、サービス側ユニット１２０は、所定のイベント発行のタイミングで、外部サービスサーバ２０１に対して天気情報等を要求する。
　外部サービスサーバ２０１は、その要求に応じて、サービス側ユニット１２０に、天気情報等を送信する。
　サービス側ユニット１２０は、車両側ユニット１１０から取得した最新インデックス１１８と、外部サービスサーバ２０１から取得した天気情報等とを、関連付けて記憶する。つまり、前記図２９に示すような複合インデックスを作成して、例えばインデックス記憶部１２５に記憶する。
　ここで、サービス提供サーバ４から、アクセスＡＰＩ１２２を介して、例えば、ある時刻に、ある地域の範囲で、雨の中を走行している車両について、車速の要求がある場合には、サービス側ユニットのインデックス記憶部１２５から該当する複合インデックスを抽出する。
　次に、その複合インデックスに基づいて、車両側ユニット１１０のシャドウ記憶部１１２にアクセスし、シャドウ記憶部１１２のシャドウ１１４から、前記条件に満たす車両及び車速を抽出して、その車速の情報を、サービス提供サーバ４に送信する。
　これによって、サービス提供サーバ４は、目的とする条件を満たす車速の情報を取得することができる。
［２－４．効果］
　本第２実施形態では、第１実施形態と同様な効果を奏する。
　また、本第２実施形態では、第３記憶部３３ｂに記憶されたインデックス（即ち、複合インデックス）１２６に、車両データ以外のデータを関連付けて（即ち、統合して）記憶するように構成されている。なお、この車両データ以外のデータは、サービス提供サーバ４以外の他の外部サーバ（即ち、外部サービスサーバ２０１）から供給されたデータである。
　つまり、本第２実施形態では、車両データのインデックス１２６として、外部サービスサーバ２０１から取得した天気情報や渋滞情報を加えた複合インデックスを作成するように構成されている。
　そのため、本第２実施形態では、サービス提供サーバ４からの要求に応じて、一層高度なサービスを提供することができる。
　例えば、サービサーは、直接に車両にアクセスしなくとも、データがほしい車両の、例えば、ｖｉｎ、時間、場所（即ち、緯度経度）を指定するだけで、その条件に該当する車両データを取得でき、容易にサービスが可能となる。
　例えば、サービサーは、ＡＰＩで、時間と場所の範囲とｅｖｅｎｔ（例えば、雨の範囲）とを設定することで、その時間に所定の場所の範囲の中の雨のエリアにいる車両に限って、車両データを取得することができる。
［３．その他の実施形態］
　以上、本開示の実施形態について説明したが、本開示は上記実施形態に限定されるものではなく、種々変形して実施することができる。
　本開示に記載のシステム及びセンターの制御を行うための構成およびその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサおよびメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載のシステム及びセンターの制御を行うための構成およびその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載のシステム及びセンターの制御を行うための構成およびその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサおよびメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。
　また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されてもよい。システムに含まれる各部の機能を実現する手法には、必ずしもソフトウェアが含まれている必要はなく、その全部の機能が、一つあるいは複数のハードウェアを用いて実現されてもよい。
　上記各実施形態における１つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、１つの構成要素が有する１つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、１つの構成要素によって実現したり、複数の構成要素によって実現される１つの機能を、１つの構成要素によって実現したりしてもよい。また、上記各実施形態の構成の一部を省略してもよい。また、上記各実施形態の構成の少なくとも一部を、他の上記各実施形態の構成に対して付加または置換してもよい。
　また、上述したシステム、車載装置、センターの他、システムが実施する方法、車載装置が実施する方法、センターが実施する方法など、種々の方法で本開示を実現することができる。さらに、システムや車載装置やセンターとしてコンピュータを機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実体的記録媒体、データ管理方法など、種々の形態で本開示を実現することもできる。

Claims (9)

  1. 　複数の車両のそれぞれに搭載された複数の車載装置（２）と、当該複数の車載装置とそれぞれデータ通信可能なセンター（３）と、を備え、
    　前記車載装置は、
    　当該車載装置が搭載された前記車両における他の装置から送信された車両データを記憶する第１記憶部（２５）と、前記車両データを前記センターに対して第１周期で送信する送信制御部（２２）と、を備え、
    　前記センターは、
    　前記車載装置から順次送信された前記車両データを記憶する第２記憶部（３３ａ）と、
    　当該第２記憶部に記憶された前記車両データと関連付けられた情報であるインデックスを記憶する第３記憶部（３３ｂ）と、
    　前記車載装置から送信された前記車両データを受信した時、当該受信した前記車両データを前記第２記憶部に記憶された前記車両データに追加するよう更新する第１更新部（１１１）と、
    　前記第１更新部による更新タイミングとの同期を必要としない第２周期で、前記第２記憶部に記憶された前記車両データの最新データに関連付けて、前記第３記憶部に記憶された前記インデックスを追加するよう更新する第２更新部（１２１）と、
    　を備えた、システム（１）。
  2. 　請求項１に記載のシステムであって、
    　前記第２記憶部は、前記車載装置から順次送信された前記車両データと、当該車両データの一部を含み当該車両データと関連付けられた最新車両データと、を記憶するように構成され、
    　前記第３記憶部は、前記第２記憶部に記憶された前記車両データの前記インデックスを記憶するように構成され、
    　前記第１更新部は、前記車載装置から送信された前記車両データを受信した時、当該受信した前記車両データを用いて、前記第２記憶部に記憶された前記車両データ及び前記最新車両データを更新するように構成され、
    　前記第２更新部は、前記第２記憶部に記憶された前記車両データを更新するタイミングとの同期を必要としない前記第２周期で、前記第２記憶部に記憶された前記最新車両データに基づいて、前記第３記憶部に記憶された前記インデックスを更新するように構成された、
    　システム。
  3. 　請求項１または請求項２に記載のシステムであって、
    　前記センターは、
    　前記車両に対するサービスを提供するサービス提供ユニット（４）からの要求に応じて、前記第３記憶部に記憶された前記インデックスを用いて、前記第２記憶部に記憶された前記車両データを取得し、前記サービス提供ユニットへ提供するように構成された、
    　システム。
  4. 　請求項１から請求項３までのいずれか１項に記載のシステムであって、
    　前記車載装置は、
    　前記車両データを前記第１周期で前記センターに送信する場合に、更新頻度が高い前記車両データと、当該高い更新頻度よりも更新頻度が低い前記車両データと、があるときには、前記更新頻度が高い前記車両データの送信周期を、前記更新頻度が低い前記車両データの送信周期よりも短く設定するように構成された、
    　システム。
  5. 　請求項１から請求項４までのいずれか１項に記載のシステムであって、
    　前記センターは、
    　前記インデックスを更新するために、前記第１周期とは非同期で、前記車両データの前記最新データを、前記第２記憶部から一定周期で取得するように構成された、
    　システム。
  6. 　請求項１から請求項５までのいずれか１項に記載のシステムであって、
    　前記センターは、
    　前記第１周期とは非同期で、前記シャドウを作成するように構成された、
    　システム。
  7. 　請求項１から請求項６までのいずれか１項に記載のシステムであって、
    　前記第３記憶部に記憶された前記インデックスに、前記車両データ以外のデータを関連付けて記憶するように構成された、
    　システム。
  8. 　複数の車両のそれぞれに搭載された複数の車載装置（２）とそれぞれ通信機（１３）を介してデータ通信可能なセンター（３）であって、
    　前記車載装置から第１周期で送信された車両データを受信する通信部（３２）と、
    　前記車両データを記憶する第２記憶部（３３ａ）と、
    　当該第２記憶部に記憶された前記車両データと関連付けられた情報であるインデックスを記憶する第３記憶部（３３ｂ）と、
    　前記通信部により前記車両データを受信した時、当該受信した前記車両データを用いて、前記第２記憶部に記憶された前記車両データに追加するよう更新する第１更新部（１１１）と、
    　前記第１更新部による更新タイミングとの同期を必要としない第２周期で、前記第２記憶部に記憶された前記車両データの最新データに関連付けて、前記第３記憶部に記憶された前記インデックスを追加するよう更新する第２更新部（１２１）と、
    　を備えた、
    　センター。
  9. 　複数の車両のそれぞれに搭載された複数の車載装置（２）とそれぞれ通信機（１３）を介してデータ通信可能なセンター（３）が実行する制御プログラムであって、
    　前記車載装置から第１周期で送信された車両データを受信し、
    　前記車両データを第２記憶部（３３ａ）に記憶し、当該第２記憶部に記憶された前記車両データと関連付けられた情報であるインデックスを第３記憶部（３３ｂ）に記憶し、
    　前記車両データを受信した時、当該受信した前記車両データを用いて、前記第２記憶部に記憶された前記車両データに追加するよう更新し、
    　前記更新のタイミングとの同期を必要としない第２周期で、前記第２記憶部に記憶された前記車両データの最新データに関連付けて、前記第３記憶部に記憶された前記インデックスを追加するよう更新する、
    　機能を実行するための制御プログラム。
PCT/JP2022/025590 2021-07-02 2022-06-27 システム、センター、及び制御プログラム WO2023276960A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2023531947A JPWO2023276960A5 (ja) 2022-06-27 システム、センター、制御プログラム、システムの処理方法、及びセンターの処理方法
CN202280047008.6A CN117597678A (zh) 2021-07-02 2022-06-27 系统、中心以及控制程序
US18/398,874 US20240126532A1 (en) 2021-07-02 2023-12-28 System, center, processing method, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021110902 2021-07-02
JP2021-110902 2021-07-02

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/398,874 Continuation US20240126532A1 (en) 2021-07-02 2023-12-28 System, center, processing method, and storage medium

Publications (1)

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

Family

ID=84689942

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/025590 WO2023276960A1 (ja) 2021-07-02 2022-06-27 システム、センター、及び制御プログラム

Country Status (3)

Country Link
US (1) US20240126532A1 (ja)
CN (1) CN117597678A (ja)
WO (1) WO2023276960A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001154725A (ja) * 1999-11-30 2001-06-08 Mitsubishi Motors Corp 車両の故障診断方法及び車両の故障診断装置並びに故障診断用プログラムを記録したコンピュータ読取可能な記録媒体
US10650621B1 (en) * 2016-09-13 2020-05-12 Iocurrents, Inc. Interfacing with a vehicular controller area network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001154725A (ja) * 1999-11-30 2001-06-08 Mitsubishi Motors Corp 車両の故障診断方法及び車両の故障診断装置並びに故障診断用プログラムを記録したコンピュータ読取可能な記録媒体
US10650621B1 (en) * 2016-09-13 2020-05-12 Iocurrents, Inc. Interfacing with a vehicular controller area network

Also Published As

Publication number Publication date
US20240126532A1 (en) 2024-04-18
CN117597678A (zh) 2024-02-23
JPWO2023276960A1 (ja) 2023-01-05

Similar Documents

Publication Publication Date Title
JP7043736B2 (ja) 車両用電子制御装置及び車両用サービス管理システム
US7043357B1 (en) Extensible navigation systems
JP7095094B2 (ja) 位置情報サービスの提供ための分散処理システムと方法
WO2018066305A1 (ja) 車載処理装置
JP6326407B2 (ja) デジタル地図を更新する方法及びシステム
US10163272B2 (en) Vehicular electronic control unit and vehicular service management system
US20230171314A1 (en) Dynamic vehicle data extraction service
JP3725022B2 (ja) 道路地図データ記録方法およびナビゲーション装置
WO2023276960A1 (ja) システム、センター、及び制御プログラム
JP2020074191A (ja) 車載処理装置
WO2023277185A1 (ja) 車載装置、データ生成方法、データ生成プログラムおよび車両システム
WO2023276957A1 (ja) センター、管理システム、管理方法および管理プログラム
WO2023276894A1 (ja) センター、管理方法および管理プログラム
JP4345228B2 (ja) 通信データ管理装置及び通信データ管理方法
CN116448090A (zh) 地图远程升级方法、系统、可读存储介质及计算机
US20240127646A1 (en) Mobility service base server, mobility service providing system, vehicle access control method, and storage medium
WO2023277030A1 (ja) モビリティサービス基盤サーバ、モビリティサービス提供システム、車両アクセス制御方法、プログラム
WO2023277032A1 (ja) モビリティサービス提供システム、モビリティサービス提供サーバ、車両データ提供方法、プログラム
JP2023524115A (ja) 経路表示方法、及び関連装置
JP2023176658A (ja) モビリティサービスシステム、及びデータ量の低減方法
JP4727097B2 (ja) 更新操作情報提供システム
WO2023097157A1 (en) Dynamic vehicle data extraction service
US20230206759A1 (en) Information notification system, management device, edge device, information notification method, method for operating management device, and non-transitory tangible storage medium
WO2021197327A1 (zh) 信号处理方法及相关设备
US20220363281A1 (en) Apparatuses, systems, methods, and techniques of distributed powertrain performance optimization and control

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023531947

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE