System, center, control program, system processing method, and center processing method

Abstract

In the present invention, a mobility GW (11) of a management center (3) acquires a plurality of vehicle data pieces from a data collection device (2). When vehicle data transmitted from the data collection device (2) is received, the mobility GW (11) uses the received vehicle data to perform an update so as to add to vehicle data stored in a shadow storage unit (112). In addition, at a second cycle that does not need to be synchronized with the timing for updating the vehicle data, the most recent index obtained from the vehicle data stored in the shadow storage unit (112) is used to perform an update so as to add the index stored in an index storage unit (125).

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] The present disclosure relates to a system for transmitting vehicle data from an in-vehicle device to a center for processing, a center for processing vehicle data transmitted from the in-vehicle device, and a control program for the center. [Background technology]

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

[0004] In recent years, with the spread of mobility services, fleet services have been provided that allow service managers to centrally manage managed vehicles by, for example, periodically collecting vehicle data such as GPS information from managed vehicles and displaying the locations of the managed vehicles on a map screen in a browser. [Prior art documents] [Patent documents]

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

[0006] In a system that performs the above-mentioned digital twin simulation, vehicle data is transmitted from an on-board device to a center at regular intervals, and the center manages the transmitted vehicle data.

[0007] Incidentally, there are various types of vehicle data transmitted from the on-board device to the center, such as vehicle data that changes significantly in a short period of time and therefore should be transmitted frequently (e.g., vehicle speed data), and vehicle data that changes infrequently in a short period of time and therefore does not need to be transmitted very frequently (e.g., water temperature data).

[0008] On the other hand, when the center receives the vehicle data, it may perform processing to update the stored vehicle data each time the data is received. Furthermore, it may perform processing such as converting the received vehicle data into data that is easy to use depending on the mobility service (for example, taking into account the necessity or use of the service).

[0009] However, after detailed consideration by the inventors, it was found that there was a problem in that if the center were to update the vehicle data that changes in a short period of time or that rarely changes in a short period of time as described above when it received the data, or to process the data into data that is easy to use in mobility services, the computational load would increase.

[0010] For example, 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.

[0011] The present disclosure desirably provides a technique that can reduce the computational load on the center side.

[0012] a) One aspect of the present disclosure is a system including a plurality of on-board devices mounted in a plurality of vehicles, and a center capable of data communication with each of the plurality of on-board devices.

[0013] The vehicle-mounted device includes a first storage unit that stores vehicle data transmitted from another device in the vehicle in which the vehicle-mounted device is installed, and a transmission control unit that transmits the vehicle data to the center at a first interval.

[0014] The center includes a second storage unit that stores the vehicle data sequentially transmitted from the vehicle-mounted device, and a third storage unit that stores an index, which is information associated with the vehicle data stored in the second storage unit.

[0015] The center further includes a first update unit that, when receiving vehicle data transmitted from the vehicle-mounted device, updates the received vehicle data by adding it to the vehicle data stored in the second memory unit, and a second update unit that updates the vehicle data by adding an index stored in the third memory unit in association with the latest data of the vehicle data stored in the second memory unit at a second period that does not require synchronization with the update timing by the first update unit.

[0016] As a result, in the system of the present disclosure, the index stored in the third storage unit can be updated at a second cycle that is different from the first cycle for transmitting vehicle data, thereby reducing the calculation load on the center. For example, by setting the second cycle to a cycle that is longer than the first cycle that is set to transmit vehicle data at a high frequency, the calculation load on the center can be reduced.

[0017] Furthermore, when vehicle data is used in a mobility service, the index that can extract the vehicle data can be updated at an appropriate timing (i.e., the second cycle), which also reduces the calculation load on the center.

[0018] b) Another aspect of the present disclosure is a center capable of data communication with a plurality of on-board devices mounted in a plurality of vehicles, each via a communication device.

[0019] The center includes a communication unit that receives vehicle data transmitted from the vehicle-mounted device at a first period, a second memory unit that stores the vehicle data, and a third memory unit that stores an index, which is information associated with the vehicle data stored in the second memory unit.

[0020] Furthermore, the center includes a first update unit that, when receiving vehicle data via the communication unit, uses the received vehicle data to update and add it to the vehicle data stored in the second memory unit, and a second update unit that updates and adds an index stored in the third memory unit in association with the latest data of the vehicle data stored in the second memory unit at a second period that does not require synchronization with the update timing by the first update unit.

[0021] As a result, the center of the present disclosure can update the index stored in the third storage unit at a second cycle different from the first cycle for transmitting vehicle data, thereby reducing the calculation load on the center. Also, when vehicle data is used in a mobility service, the index from which the vehicle data can be extracted can be updated at an appropriate timing (i.e., the second cycle), which also reduces the calculation load on the center.

[0022] c) Yet another aspect of the present disclosure is a control program executed by a center capable of data communication with a plurality of on-board devices mounted in a plurality of vehicles, each via a communication device.

[0023] This control program receives vehicle data transmitted from the in-vehicle device at a first period, stores the vehicle data in a second memory unit, and stores an index, which is information associated with the vehicle data stored in the second memory unit, in a third memory unit.

[0024] Furthermore, when vehicle data is received, the received vehicle data is used to update the vehicle data stored in the second storage unit by adding it to the vehicle data stored in the second storage unit, and in a second period that does not require synchronization with the timing of this update, the index stored in the third storage unit is updated by adding it to the latest data of the vehicle data stored in the second storage unit in association with it.

[0025] As a result, the control program of the present disclosure can update the index stored in the third storage unit at a second cycle that is different from the first cycle for transmitting vehicle data, thereby reducing the computational load on the center. Also, when vehicle data is used in a mobility service, the index that can extract the vehicle data can be updated at an appropriate timing (i.e., at the second cycle), which also reduces the computational load on the center. [Brief explanation of the drawings]

[0026] [Figure 1] FIG. 1 is a block diagram showing a configuration of a mobility IoT system according to a first embodiment. [Figure 2] FIG. 2 is a block diagram showing the configuration of a data collection device. [Figure 3] FIG. 2 is a block diagram showing the configuration of a management center. [Figure 4] FIG. 2 is a functional block diagram showing the functional configuration of the data collection device. [Figure 5] FIG. 2 is a functional block diagram showing the functional configuration of a management center. [Figure 6] FIG. 1 is a diagram illustrating the configuration of a CAN frame. [Figure 7] 10 is a flowchart illustrating a data standardization process. [Figure 8] FIG. 4 is a diagram showing the configuration of a vehicle data conversion table. [Figure 9] FIG. 2 is a diagram showing the first layer of standardized vehicle data and the data format. [Figure 10] FIG. 2 is a diagram showing the configuration of standardized vehicle data. [Figure 11] FIG. 10 is a sequence diagram showing a procedure for creating standardized vehicle data. [Figure 12] FIG. 2 is a functional block diagram showing the functional configuration of a scheduling system for a data collection device. [Figure 13] FIG. 10 is a diagram showing update timings according to types of vehicle data. [Figure 14] FIG. 10 is a diagram illustrating transmission periods according to types of vehicle data. [Figure 15] 10 is a flowchart showing the first half of a data transmission process. [Figure 16] 10 is a flowchart showing the second half of the data transmission process. [Figure 17] 10 is a timing chart showing data transmission timing. [Figure 18] FIG. 1 is a sequence diagram showing the flow of data in a mobility IoT system. [Figure 19] FIG. 4 is a diagram showing the structure of vehicle data to be transmitted. [Figure 20] FIG. 2 is a functional block diagram showing the functional configuration of a mobility gateway and a data management unit. [Figure 21] FIG. 10 is a diagram illustrating a configuration of a shadow. [Figure 22] FIG. 10 is a diagram illustrating the configuration of the latest index. [Figure 23] FIG. 10 is a diagram illustrating the structure of an index. [Figure 24] FIG. 24A is a flowchart showing the processing of the mobility gateway, and FIG. 24B is a flowchart showing the processing of the data management unit. [Figure 25] FIG. 10 is a diagram showing a specific example of a request. [Figure 26] FIG. 2 is a block diagram showing a connection state of ECUs mounted on a vehicle. [Figure 27] FIG. 10 is a block diagram showing the configuration of a mobility IoT system according to a second embodiment. [Figure 28] FIG. 2 is a functional block diagram showing the functional configuration of a service-side unit. [Figure 29] FIG. 10 is a diagram showing the structure of an index including data other than vehicle data. [Figure 30] FIG. 1 is a diagram showing the area in which a vehicle travels and the extent of rain. [Figure 31] FIG. 10 is a sequence diagram showing a data flow in the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0027] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. [1. First embodiment] [1-1. Overall structure] The mobility IoT system 1 of the first embodiment has a function of managing vehicle states on the cloud, and as shown in Fig. 1, includes a plurality of data collection devices (i.e., edge devices) 2, a management center 3, and a service providing server 4. IoT is an abbreviation for Internet of Things.

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

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

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

[0031] As shown in FIG. 2, the data collection device 2 includes a microcomputer 11, a vehicle interface (hereinafter referred to as vehicle I / F) 12, a communication device 13, and a storage unit .

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

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

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

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

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

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

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

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

[0040] The CAN communication port and the Ethernet communication port are connected to other electronic control units mounted on the vehicle, allowing the data collection device 2 to transmit and receive communication frames to and from the other electronic control units.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0055] 3, the management center 3 includes a control unit 31, a communication unit 32, and a storage unit 33. The storage unit 33 includes a second storage unit 33a and a third storage unit 33b, which will be described later.

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

[0057] The communication unit 32 performs data communication between the plurality of data collection devices 2 and the service providing server 4 via the wide area wireless communication network NW.

[0058] The storage unit 33 is a storage device for storing various data. [1-2. Functions of the data collection device] Next, the functions of the data collecting device 2 will be described.

[0059] 4, the data collection device 2 includes a first unit 101 as a functional block realized by the first core 21 executing a program stored in the ROM 23. The data collection device 2 includes a second unit 102 as a functional block realized by the second core 22 executing a program stored in the ROM 23.

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

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

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

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

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

[0065] The second application 106 also executes processes related to scheduling when transmitting vehicle data. To execute the processes related to scheduling, the second application 106 is configured to be able to access the rule storage unit 25b of the flash memory 25 and refer to the transmission period of each vehicle data.

[0066] The GPOS 105 is basic software installed in the data collection device 2 to run various applications, and manages the second application 106 . [1-3. Functions of the Management Center] Next, the functions of the management center 3 will be described.

[0067] The management center 3 includes a vehicle-side unit 110 and a service-side unit 120 as functional blocks realized by the CPU 41 executing a program stored in the ROM 42, as shown in FIG.

[0068] The side closer to access to the vehicle is the vehicle-side unit 110, and the side closer to access from the service providing server 4 is the service-side unit 120. The functional blocks are divided into two, and these two functional blocks are loosely coupled.

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

[0070] 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 a request to access the vehicle to the vehicle, as well as a function of managing data received from the vehicle.

[0071] The mobility GW 111 includes a shadow storage unit 112 and a vehicle control unit 113. The shadow storage unit 112 stores a shadow 114 that contains vehicle data for each vehicle equipped with a data collection device 2. The shadow 114 indicates a group of vehicle data for a certain vehicle. The vehicle control unit 113 has a function of controlling the vehicle equipped with the data collection device 2 based on instructions from the service providing server 4.

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

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

[0074] The access API 122 is a standard interface for the service providing server 4 to access the mobility GW 111 and the data management unit 121. The access API 122 provides the service providing server 4 with an API for accessing a vehicle and acquiring vehicle data. [1-4. Processing performed by vehicle I / F] Next, the processing executed by the vehicle I / F 12 will be described.

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

[0076] Then, the 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 the first unit 101 if it determines that the communication frame is necessary.

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

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

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

[0080] Therefore, when the vehicle I / F 12 receives a CAN frame, it determines whether or not the received CAN frame is necessary based on the CAN ID. [1-5. Processing performed by the first unit] Next, the processing executed by first unit 101 will be described.

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

[0082] If standard format data containing the same identification information as the created standard format data is already stored in the flash memory 25, the first unit 101 updates the standard format data by overwriting and storing the standard format data. [1-6. Processing performed by the second unit] Next, a description will be given of the procedure of the data standardization process executed by the second unit 102. The data standardization process is a process that is repeatedly executed while the microcomputer 11 is in operation.

[0083] When the data standardization process is executed, the second core 22 first determines in S10 whether a preset standardization execution condition is met, as shown in FIG.

[0084] The standardization execution condition is that at least one of the first high-frequency standardization condition, the second high-frequency standardization condition, the third high-frequency standardization condition, the first low-frequency standardization condition, the second low-frequency standardization condition, the event standardization condition, and the invariant standardization condition, which will be described later, is met.

[0085] The first high-frequency standardization condition is that a preset first high-frequency standardization period (for example, 500 ms in the first embodiment) has elapsed.

[0086] The second high-frequency standardization condition is that a preset second high-frequency standardization period (for example, 2 seconds in the first embodiment) has elapsed.

[0087] The third high-frequency standardization condition is that a preset third high-frequency standardization period (for example, 4 seconds in the first embodiment) has elapsed.

[0088] The first low-frequency standardization condition is that a preset first low-frequency standardization period (for example, 30 seconds in the first embodiment) has elapsed.

[0089] The second low-frequency standardization condition is that a preset second low-frequency standardization period (for example, 300 seconds in the first embodiment) has elapsed.

[0090] The event standardization condition is that a preset event standardization period (for example, 12 hours in the first embodiment) has elapsed. Note that the first to third high-frequency standardization periods may also be adopted as the event standardization condition.

[0091] The invariant standardization condition is that the current processing of S10 is the first processing of S10 since the microcomputer 11 has been started up.

[0092] If the standardization execution condition is not satisfied, the second core 22 terminates the data standardization process. On the other hand, if the standardization execution condition is satisfied, the second core 22 acquires, in S20, standard format data corresponding to the satisfied standardization condition out of the seven standardization conditions constituting the standardization execution condition from the flash memory 25. For example, if the second high-frequency standardization condition is satisfied, the second core 22 acquires, in S20, standard format data corresponding to the second high-frequency standardization condition.

[0093] Then, in S30, 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 is made up of a CAN ID and first to eighth pieces of data, the second core 22 divides the first to eighth pieces of data into 1-byte pieces and extracts eight pieces of CAN data.

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

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

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

[0097] Semantic information is information for converting normalized vehicle data into meaningful vehicle data.

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

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

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

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

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

[0103] Furthermore, the semantic information of the vehicle data conversion table 23a is, for example, a conversion formula for converting a "steering movement angle" whose control label is "SSA" into a "steering angle" by subtracting a "steering zero point" whose control label is "SSAZ" as shown in Fig. 8. In this way, the vehicle data representing the "steering movement angle" and the vehicle data representing the "steering zero point" are converted into vehicle data representing a "steering angle" which has the meaning of "amount of steering from a reference position."

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

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

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

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

[0108] As shown in FIG. 10, the standardized vehicle data has at least a second and third hierarchical levels in addition to the first hierarchical level. The second hierarchical level is the level immediately below the first hierarchical level, and the third hierarchical level is the level immediately below the second hierarchical level. The standardized vehicle data are items set in the normalization and semantic processing described above. The standardized vehicle data has a hierarchical data structure.

[0109] For example, the "attribute information" item in the first layer includes "vehicle identification information," "vehicle attributes," "transmission configuration," and "firmware version" as items in the second layer.

[0110] "Vehicle identification information" is a category name that indicates information that can uniquely identify a vehicle. "Vehicle attributes" is a category name that indicates the type of vehicle. "Transmission information" is a category name that indicates information about the transmission. "Firmware version" is a category name that indicates information about the vehicle's firmware.

[0111] In addition, the first-level item "powertrain" is a category name indicating powertrain information, and the second-level items include "accelerator pedal," "engine," and "engine oil."

[0112] "Accelerator pedal" includes one or more vehicle data items, such as the accelerator pedal status and opening degree. "Engine" includes one or more individual vehicle data items, such as the engine status and RPM. These second-level items also correspond to categories. The same applies to other first-level items.

[0113] Furthermore, "energy," which is an item in the first hierarchy, includes items in the second hierarchy such as "battery state," "battery configuration," and "fuel."

[0114] Furthermore, the second-level item "Vehicle Identification Information" includes third-level items "Vehicle Identification Number," "Vehicle Body Number," and "License Plate." These third-level items include one or more individual vehicle data (also called items).

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

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

[0117] These items are also called items, and items with lower levels are also called categories.

[0118] For example, if the control label of the converted vehicle data is "vehicle identification information," the second core 22 stores the converted vehicle data in a storage area in the standardized vehicle data storage unit 25a where the first layer is "attribute information," the second layer is "vehicle identification information," and the third layer is "vehicle identification number." [1-7. Procedure for creating standardized vehicle data] Next, a procedure for the data collection device 2 to create standardized vehicle data will be described with reference to the sequence diagram shown in FIG.

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

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

[0121] As shown by arrow L17, second unit 102 acquires the vehicle data converted into the standard format from flash memory 25, and then converts the acquired vehicle data as shown by arrow L18. Furthermore, second unit 102 structures the converted data to create standardized vehicle data as shown by arrow L19. [1-8. Scheduling of transmission data] Next, a description will be given of scheduling of transmission data (i.e., vehicle data to be transmitted) performed by the data collection device 2. That is, a description will be given of transmission interval control when the data collection device 2 transmits vehicle data to the management center 3.

[0122] 12, the scheduling system of the data collecting device 2 can be realized by the rules stored in the rule storage unit 25b of the flash memory 25 and the processing of the periodic control unit 106a. Note that the periodic control unit 106a can be realized by the processing of the second application 106.

[0123] The rule is a rule for determining the transmission period (i.e., the first period) to the management center 3 depending on the type of vehicle data. In Fig. 12, types Data 1 and Data 2 indicate data whose transmission period is set according to a predetermined rule 1, Data 3 and Data 4 indicate data whose transmission period is set according to rule 2 which is different from rule 1, and Data 5 and Data 6 indicate data whose transmission period is set according to rule 3 which is different from rules 1 and 2.

[0124] The setting items of the rules in scheduling include "item," "transmission frequency," "initial synchronization timing," "category," etc. 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 started. The transmission cycle may be set for each vehicle data item (i.e., item), or may be set for each vehicle data category.

[0125] The specific details will be explained below.

[0126] As shown in Fig. 13, vehicle data includes various types of vehicle data categorized into categories such as vehicle identification information, vehicle attributes, engine, engine oil, and drive mode. Furthermore, the various types of vehicle data are each classified into specific categories or items. For example, the category of vehicle identification information is divided into items such as vehicle identification number, vehicle number, and license plate; the engine is divided into engine on / off state and engine RPM; and the engine oil is divided into engine oil, etc.

[0127] The frequency of transmission of these classified vehicle data (i.e., transmission frequency: transmission cycle) is set based on the period of transmission from other electronic control units via CAN, the degree of change in the vehicle data value, etc. For example, if the frequency of transmission from other electronic control units is low to begin with, it may be possible to lower the transmission frequency (i.e., lengthen the transmission cycle). Also, even if the frequency of transmission from other electronic control units is high, it may be possible to lower the transmission frequency (i.e., lengthen the transmission cycle) because, for example, the value of the cooling water temperature does not change suddenly.

[0128] Specifically, for example, since engine speed changes in a short period of time, a short transmission cycle is set so that data is transmitted frequently. For example, since engine oil temperature does not change in a short period of time, a relatively long transmission cycle is set so that data is transmitted less frequently than the high frequency. For example, the fuel-saving ECO mode operating state is set as event data that indicates that state, for example, a short transmission cycle corresponding to the high frequency. Note that a longer transmission cycle than the high frequency can also be used for event data. For example, since the vehicle identification number only needs to be transmitted initially from the corresponding vehicle, it is set as invariant data, for example, to be transmitted only at the first transmission. Specifically, for example, the vehicle identification number can be set to be transmitted at the first transmission from the vehicle after the ignition switch of the vehicle is turned on. Note that, in the rule table shown in FIG. 13, specific numerical values ​​may be entered as the transmission frequency setting value taking into account the update timing.

[0129] Furthermore, as shown in Fig. 14, vehicle data that is transmitted frequently (i.e., high-frequency data) and vehicle data that is transmitted infrequently (i.e., low-frequency data) may be further classified according to the necessity of transmission. Fig. 14 is a table showing details of transmission frequencies related to rules. Note that the table showing transmission periods according to the type of vehicle data as shown in Fig. 14 is stored in advance in, for example, the rule storage unit 25b of the data collection device 2.

[0130] For example, as will be described in detail later, the transmission period of the vehicle data is set by a predetermined calculation formula "mod{(tx+β) / (T×α)}." If this calculation formula is 0, transmission is performed.

[0131] Specifically, for example, first and second high-frequency data are set as high-frequency data to be transmitted at a cycle of one second. If the amount of data is large, this high-frequency data can be divided into multiple pieces and transmitted. For example, it can be divided in half and transmitted continuously every half the transmission cycle (for example, every 500 ms). The same applies to other vehicle data to be transmitted.

[0132] Also, for example, the third and fourth high-frequency data are set as high-frequency data to be transmitted at a cycle of four seconds, and the fifth and sixth high-frequency data are set as high-frequency data to be transmitted at a cycle of eight seconds.

[0133] For example, first and second low-frequency data are set as low-frequency data to be transmitted at a cycle of one minute. Furthermore, third and fourth low-frequency data are set as low-frequency data to be transmitted at a cycle of ten minutes.

[0134] The vehicle data set as described above is transmitted to the management center 3 by the communication device 13 at a transmission period corresponding to each vehicle data.

[0135] Although the data collection device 2 spontaneously transmits the vehicle data to the management center 3 based on the transmission cycle, the rules and transmission cycle may be changed based on instructions from the management center 3 side. [1-9. Data transmission process procedure by data collection device] Next, a description will be given of the procedure of the data transmission process to the management center 3 executed by the data collection device 2. The data transmission process is a process that is repeatedly executed while the microcomputer 11 is in operation.

[0136] When the data transmission process is executed, the second core 22 first determines whether a preset first high-frequency transmission condition is met in S110, as shown in Fig. 15. The first high-frequency transmission condition is that mod {tx / (T x 2)} is 0, where tx is the current time and T is the transmission interval setting value (for example, 500 ms in the first embodiment).

[0137] Here, if the first high-frequency transmission condition is not met, the second core 22 proceeds to S130. On the other hand, if the first high-frequency transmission condition is met, the second core 22 extracts, from the standardized vehicle data storage unit 25a, the vehicle data that is set as the first high-frequency data from the vehicle data that constitutes the standardized vehicle data in S120, transmits it to the management center 3, and proceeds to S130.

[0138] In S130, the second core 22 determines whether a preset second high-frequency transmission condition is met. The second high-frequency transmission condition is that mod {(tx+T) / (T×2)} is 0.

[0139] Here, if the second high-frequency transmission condition is not met, the second core 22 proceeds to S150. On the other hand, if the second high-frequency transmission condition is met, the second core 22 extracts, from the standardized vehicle data storage unit 25a, the vehicle data set as the second high-frequency data from the vehicle data that constitutes the standardized vehicle data in S140, transmits it to the management center 3, and proceeds to S150.

[0140] In S150, the second core 22 determines whether a preset third high-frequency transmission condition is met. The third high-frequency transmission condition is that mod {tx / (T×8)} is 0.

[0141] Here, if the third high-frequency transmission condition is not met, the second core 22 proceeds to S170. On the other hand, if the third high-frequency transmission condition is met, the second core 22 extracts, from the standardized vehicle data storage unit 25a, the vehicle data set as the third high-frequency data from the vehicle data that constitutes the standardized vehicle data in S160, transmits it to the management center 3, and proceeds to S170.

[0142] In S170, the second core 22 determines whether a fourth high-frequency transmission condition is met. The fourth high-frequency transmission condition is that mod {(tx+T) / (T×8)} is 0.

[0143] Here, if the fourth high-frequency transmission condition is not met, the second core 22 proceeds to S190. On the other hand, if the fourth high-frequency transmission condition is met, the second core 22 extracts, from the standardized vehicle data storage unit 25a, the vehicle data set as the fourth high-frequency data from the vehicle data that constitutes the standardized vehicle data in S180, transmits the vehicle data to the management center 3, and proceeds to S190.

[0144] In S190, the second core 22 determines whether a preset fifth high-frequency transmission condition is met. The fifth high-frequency transmission condition is that mod{tx / (T×16)} is 0.

[0145] Here, if the fifth high-frequency transmission condition is not met, the second core 22 proceeds to S210. On the other hand, if the fifth high-frequency transmission condition is met, the second core 22 extracts, from the standardized vehicle data storage unit 25a, the vehicle data set as the fifth high-frequency data from the vehicle data that constitutes the standardized vehicle data in S200, transmits it to the management center 3, and proceeds to S210.

[0146] In S210, the second core 22 determines whether a preset sixth high-frequency transmission condition is met. The sixth high-frequency transmission condition is that mod {(tx+T) / (T×16)} is 0.

[0147] Here, if the sixth high-frequency transmission condition is not met, the second core 22 proceeds to S230. On the other hand, if the sixth high-frequency transmission condition is met, the second core 22 extracts, from the standardized vehicle data storage unit 25a, the vehicle data set as the sixth high-frequency data from the vehicle data constituting the standardized vehicle data in S180, transmits it to the management center 3, and proceeds to S230.

[0148] In S230, the second core 22 determines whether a preset first low-frequency transmission condition is met. The first low-frequency transmission condition is that mod {tx / (T×120)} is 0.

[0149] If the first low-frequency transmission condition is not met, the second core 22 proceeds to S250. On the other hand, if the first low-frequency transmission condition is met, the second core 22 extracts, from the standardized vehicle data storage unit 25a, the vehicle data that is set as the first low-frequency data from the vehicle data that constitutes the standardized vehicle data in S240, transmits it to the management center 3, and then proceeds to S250.

[0150] When the process proceeds to S250, the second core 22 determines whether a preset second low-frequency transmission condition is met, as shown in Fig. 16. The second low-frequency transmission condition is that mod{(tx+T) / (T×120)} is 0.

[0151] If the second low-frequency transmission condition is not met, the second core 22 proceeds to S270. On the other hand, if the second low-frequency transmission condition is met, the second core 22 extracts, from the standardized vehicle data storage unit 25a, the vehicle data set as the second low-frequency data from the vehicle data that constitutes the standardized vehicle data in S260, transmits the extracted vehicle data to the management center 3, and then proceeds to S270.

[0152] In S270, the second core 22 determines whether a preset third infrequent transmission condition is met. The third infrequent transmission condition is that mod {tx / (T×1200)} is 0.

[0153] If the third low-frequency transmission condition is not met, the second core 22 proceeds to S290. On the other hand, if the third low-frequency transmission condition is met, the second core 22 extracts, from the standardized vehicle data storage unit 25a, the vehicle data set as the third low-frequency data from the vehicle data constituting the standardized vehicle data in S280, transmits the extracted vehicle data to the management center 3, and then proceeds to S290.

[0154] In S290, the second core 22 determines whether a preset fourth low-frequency transmission condition is met. The fourth low-frequency transmission condition is that mod {(tx+T) / (T×1200)} is 0.

[0155] Here, if the fourth low-frequency transmission condition is not met, the second core 22 proceeds to S310. On the other hand, if the fourth low-frequency transmission condition is met, the second core 22 extracts, from the standardized vehicle data storage unit 25a, the vehicle data set as the fourth low-frequency data from the vehicle data that constitutes the standardized vehicle data in S300, transmits the extracted vehicle data to the management center 3, and then proceeds to S310.

[0156] When the process proceeds to S310, the second core 22 determines whether a preset event transmission condition is met. The event transmission condition is that mod{tx / (T×172800)} is 0. Note that any of the first to sixth high-frequency transmission conditions may be adopted as the event transmission condition.

[0157] If the event transmission condition is not met, the second core 22 proceeds to S330. On the other hand, if the event transmission condition is met, the second core 22 extracts the vehicle data set in the event data from the standardized vehicle data storage unit 25a among the vehicle data constituting the standardized vehicle data in S320, transmits it to the management center 3, and proceeds to S330.

[0158] When the process proceeds to S330, the second core 22 determines whether a preset constant transmission condition is met. The constant transmission condition is that the current process of S330 is the first process of S330 since the microcomputer 11 was started.

[0159] If the invariant transmission condition is not satisfied, the second core 22 ends the data transmission process. On the other hand, if the invariant transmission condition is satisfied, the second core 22 extracts, in S340, the vehicle data that is set as invariant data from the standardized vehicle data storage unit 25a, from the vehicle data that constitutes the standardized vehicle data, and transmits it to the management center 3, and ends the data transmission process.

[0160] As shown in Figure 17, if time t0 is the initial transmission timing, the first high-frequency data, the third high-frequency data, the fifth high-frequency data, the first low-frequency data, the third low-frequency data, the event data, and the invariant data are transmitted at time t0.

[0161] The first high frequency data is transmitted every 1000 ms from time t0. If the data is divided into two, each of the two pieces of data may be transmitted every 500 ms, which is half the transmission period. If other data is also divided into two, each of the two pieces of data may be transmitted at half the timing of the transmission period.

[0162] The second high frequency data is transmitted at time t1, which is 500 ms after time t0, and thereafter is transmitted every 1000 ms after time t1.

[0163] The third high frequency data is transmitted every 4 seconds after time t0. The fourth high frequency data is transmitted at time t4, which is 2 seconds after time t0, and thereafter is transmitted every 4 seconds after time t4.

[0164] The fifth high frequency data is transmitted every 8 seconds after time t0. The sixth high frequency data is transmitted 4 seconds after time t0, and thereafter every 8 seconds.

[0165] The first low-frequency data is transmitted every minute after time t0. The second low-frequency data is transmitted 30 seconds after time t0, and then every minute thereafter.

[0166] The third low-frequency data is transmitted every 10 minutes from time t0. The fourth low-frequency data is transmitted 5 minutes after time t0, and then every 10 minutes thereafter.

[0167] The event data is transmitted every 12 hours from time t0. The event data may be transmitted at the same timing as the first to sixth high frequency data.

[0168] Here, the flow of data between the vehicle, the data collecting device 2, and the management center 3 will be collectively explained using the sequence diagram shown in FIG.

[0169] As indicated by arrow L21, vehicle data is transmitted to the scheduling system of the data collection device 2 from each sensor and each electronic control device disposed in the vehicle.

[0170] Specifically (see FIG. 26, for example), the data collection device (i.e., edge device) 2 instructs the ECU 210 having a relay function to collect data by specifying which data to acquire from which ECU. The ECU 210 receives designated data transmitted from a designated ECU among the data transmitted from each ECU 220 via the in-vehicle communication network 250, and transmits the designated data to the data collection device 2. The data collection device 2 may request each ECU 220 to transmit data via the ECU 210. The data collection device 2 normalizes and semantizes the received vehicle data, and forms it into standardized vehicle data with a hierarchical structure.

[0171] The scheduling system sets the transmission period of the vehicle data according to the above-mentioned rules, and also divides the vehicle data as necessary.

[0172] Then, as indicated by arrow L22, the vehicle data is transmitted to the vehicle-side unit 110 of the management center 3 in accordance with the set transmission cycle. Note that the scheduling system may transmit a divided portion of the standardized vehicle data or may transmit all of the standardized vehicle data in accordance with the set transmission cycle.

[0173] The vehicle-side unit 110 stores the received vehicle data in the second storage unit 33a. That is, the received vehicle data is synchronously stored in the second storage unit 33a. Note that the second storage unit 33a may be, for example, a shadow storage unit 112 (see, for example, FIG. 20).

[0174] As will be described later, the service side unit 120 also includes a third storage unit 33b. The service side unit 120 acquires the latest vehicle data created from the vehicle data stored in the second storage unit 33a, i.e., the latest index 118 (see, for example, FIG. 20) that allows vehicle data to be searched, at a cycle different from that for acquiring the vehicle data from the second storage unit 33a, i.e., asynchronously (for example, every second), and stores the data in the third storage unit 33b. Note that an example of the third storage unit 33b is the index storage unit 125 (see, for example, FIG. 20).

[0175] The vehicle data transmitted from the data collecting device 2 to the management center 3 is structured, for example, as shown in FIG.

[0176] In this vehicle data, "attributes" indicates attribute information, "firmware-version" indicates the firmware version, and "mobility-id-information" indicates information that identifies the vehicle. This "attributes" corresponds to the attribute information in Figure 10.

[0177] The "mobility-id-information" is, for example, "vehicle-makers-serial-number" (i.e., vehicle number), "vehicle-registration-no" (i.e., license plate number), or "vin" (i.e., vehicle identification number). This "mobility-id-information" corresponds to the vehicle identification information in FIG. 10.

[0178] In this way, the data collecting device 2 forms the vehicle data into the data structure shown in FIG. 10 or FIG.

[0179] The transmitted data is compressed and base64 encoded. [1-10. Configuration of Mobility GW and Data Management Unit] As shown in FIG. 20, the mobility GW 111 includes a shadow creating unit 115, a latest index creating unit 116, and a latest index storage unit 117.

[0180] The shadow creation unit 115 updates the standardized vehicle data by overwriting the transmitted vehicle data in the corresponding area of ​​the structured standardized vehicle data each time the vehicle data is transmitted from the data collection device 2 at a transmission period (i.e., the first period) set according to the type of vehicle data. The shadow creation unit 115 then uses the updated standardized vehicle data to create a new shadow 114. The shadow creation unit 115 then stores the created shadow 114 in the shadow storage unit 112. As a result, the shadow storage unit 112 stores, for each vehicle, multiple shadows 114 with different creation times. The shadow creation unit 115 receives the standardized vehicle data formed in a hierarchical structure from the data collection device 2. The shadow creation unit 115 may receive hierarchically structured data of part of the standardized vehicle data. When creating a new shadow 114 using the updated standardized vehicle data, the shadow creation unit 115 may add any information such as a serial number and store the new shadow 114 in the shadow storage unit 112.

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

[0182] As a result, the standardized vehicle data is overwritten (i.e., updated) in the first cycle, and the sequentially updated standardized vehicle data is stored in the shadow storage unit 112 as the shadow 114. In other words, the vehicle data stored in the shadow 114 is updated according to time. In addition, in the case of vehicle data with a long transmission cycle, the value of the vehicle data received last time is stored in the shadow 114.

[0183] The following configuration may also be adopted. The cloud may be configured to create the shadow 114 not at the timing when the vehicle data is received from the data collection device 2 (i.e., the first cycle), but at a third cycle unrelated to the first cycle. Furthermore, since data is sent from the data collection device 2 at a transmission cycle for each vehicle data, in the above-described embodiment, the shadow 114 was created each time, but the shadow 114 may also be created at a timing unrelated to the timing at which the vehicle data was received (i.e., the third cycle). Furthermore, the vehicle data received from the data collection device 2 may be stored in the free space of the shadow memory unit 112 in the structure of standardized vehicle data (for example, as a temporary shadow), and at the timing of the third period, a shadow 114 with a shadow-version or the like attached may be created and stored in the shadow memory unit 112. The third period is set to be shorter than the second period, but may be the same as the second period or may be set to be longer than the second period. Data is transmitted from the shadow 114 to the index 126 at the second period.

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

[0185] 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.

[0186] The "object-id" is a number for identifying a vehicle. For example, multiple shadows 114 corresponding to a certain vehicle have the same "object-id." When vehicle data for a certain vehicle is first received by the management center 3, an "object-id" is assigned to identify the vehicle.

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

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

[0189] The device data storage unit 114b stores "object-id," "update_time," "version," "power_status," "power_status_timestamp," and "notify_reason" as data related to the hardware and software installed in the data collecting device 2. This information is transmitted from the data collecting device 2 separately from the standardized vehicle data when a change occurs.

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

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

[0192] “Version” is a character string indicating the version of the hardware and software of the data collection device 2.

[0193] "power_status" is a character string indicating the system status of the data collecting device 2 (for example, off, on, etc.).

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

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

[0196] In this way, the shadow 114 includes information about the data collecting device 2 in addition to the vehicle data group. The device data storage unit 114b may store the information about the data collecting 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 about the data collecting device 2 in the ROM 42, rather than accumulating past data for each timestamp.

[0197] The latest index creation unit 116 acquires the latest shadow 114 for each vehicle from the shadow storage unit 112, and creates a latest index 118 (also referred to as a first index, for example) 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.

[0198] The latest index 118 and the index 126, which will be described later, are parameter information that serve as keys when searching the shadow 114 from the shadow storage unit 112. In other words, the latest index 118 and the index 126 are data that are configured from a portion of the vehicle data (i.e., standardized vehicle data) and are associated with the vehicle data. The latest index 118 is parameter information based on the latest vehicle data. The latest index creation unit 116 generates the latest index 118 by using vehicle data acquired from the data collection device 2 or by generating data itself.

[0199] In other words, the vehicle data stored in the shadow memory unit 112 is updated every first period as described above, so the latest index memory unit 117 stores the latest index 118 for each vehicle every first period.

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

[0201] The "gateway-id" is information for identifying the mobility GW 111.

[0202] "Object-id" is information for identifying the vehicle in which the data collection device 2 is mounted.

[0203] The "shadow-version" corresponds to the "Shadow_version" of the shadow 114. That is, the "shadow-version" is information that identifies the shadow 114, and a timestamp is set.

[0204] "vin" is the registration number unique to the vehicle in which the data collection device 2 is installed.

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

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

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

[0208] As shown in FIG. 20, the data management unit 121 includes an index creation unit 124 and an index storage unit 125.

[0209] The index creation unit 124 acquires the latest index 118 from the latest index storage unit 117 at predetermined intervals (i.e., a second interval different from the first interval), i.e., periodically (e.g., every second), and creates an index 126 (also referred to as a second index, for example) using the acquired latest index 118. Then, the index creation unit 124 stores the created index 126 in the index storage unit 125. As a result, the index storage unit 125 stores a plurality of indexes 126, each created at a different time, for each vehicle.

[0210] That is, since the index 126 stored in the index storage unit 125 is created for each second period as described above, the index 126 for each vehicle is stored for each second period in the index storage unit 125. In this way, the index 126 is updated for each second period.

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

[0212] "timestamp" is a timestamp indicating the time in milliseconds.

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

[0214] The "gateway-id" is information for identifying the mobility GW 111. The "object-id" is information for identifying the vehicle in which the data collection device 2 is mounted.

[0215] "shadow-version" is a timestamp of the gateway and is information that identifies the shadow 114. "vin" is the registration number unique to the vehicle in which the data collection device 2 is installed.

[0216] "Location" is information indicating the latitude and longitude of the vehicle on which the data collection device 2 is mounted. "Alt" is information indicating the altitude at which the vehicle on which the data collection device 2 is mounted is located.

[0217] Here, 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 to generate the index 126. Preferably, the index creation unit 124 generates the index 126 using the latest index 118 acquired from the latest index storage unit 117. This is one of the configurations in which the mobility GW 111 and the data management unit 121 are loosely coupled.

[0218] Furthermore, the configuration may be such that the index creation unit 124 and the index storage unit 125 are not provided. For example, the index acquisition unit 127 may use the object-id and timestamp (e.g., shadow-version) specified by the access API 122 to request the data acquisition unit 119 to acquire the specified vehicle data.

[0219] Here, the processing flow in the mobility GW 111 and data management unit 121 described above will be explained together.

[0220] 24A, the mobility GW 111 determines whether vehicle data has been received in S410. If the determination is affirmative, the process proceeds to S420, whereas if the determination is negative, the process ends.

[0221] In S420 , the standardized vehicle data is overwritten based on the received vehicle data, and a shadow 114 is created and stored in the shadow storage unit 112 .

[0222] In the next step 430, the latest index 118 is created based on the shadow 114 and stored in the latest index storage unit 117, after which the process is temporarily terminated.

[0223] 24B, the data management unit 121 determines in S510 whether it is a fixed timing for creating and storing the index 126 (i.e., the second cycle for updating the index 126). If the determination is affirmative, the process proceeds to S520, whereas if the determination is negative, the process is temporarily terminated.

[0224] In S520, an index 126 is created based on the latest index 118 stored in the latest index storage unit 117, and is stored in the index storage unit 125, after which the process ends.

[0225] 20, the mobility GW 111 includes a data acquisition unit 119. The data management unit 121 includes an index acquisition unit 127.

[0226] The index acquisition unit 127 provides an index 126 capable of identifying the shadow 114 in order to acquire vehicle data corresponding to the specified parameters from the shadow 114 .

[0227] In addition, when the index acquisition unit 127 receives a request from the access API 122 instructing the acquisition of specified data for a specified vehicle at a specified time, it acquires from the index storage unit 125 an index 126 corresponding to the specified time and specified vehicle of the received request.

[0228] Furthermore, the index acquisition unit 127 designates the shadow 114 identified based on the acquired index 126 as the designated shadow and transmits a request to the data acquisition unit 119 to instruct acquisition of designated data in the designated shadow. Specifically, since the shadow 114 is uniquely determined by the "object-id" and "shadow-version", the index acquisition unit 127 requests the data acquisition unit 119 to acquire the designated data using the "object-id" and "shadow-version".

[0229] When the data acquisition unit 119 receives a request from the index acquisition unit 127 , it extracts the specified data from the specified shadow indicated by the received request and transmits the extracted specified data to the access API 122 .

[0230] Here, the extracted designated data may be transmitted to the access API 122 via the index acquisition unit 127 .

[0231] In addition, in order to obtain specified data for a specified vehicle at a specified time, the access API 122 may obtain the corresponding index 126 from the index storage unit 125 via the index obtaining unit 127, and request the data obtaining unit 119 to obtain the specified data using the obtained index 126 (e.g., object-id and shadow-version).

[0232] 25 are specific examples of requests transmitted from the service providing server 4 to the access API 122. In other words, the requests are APIs for acquiring vehicle data that are provided to the service providing server 4 by the access API 122.

[0233] Request RQ1 is a request to obtain the latitude (i.e., data whose "item-names" is "latitude") for the vehicle whose "object-id" is "dt-000002" and the vehicle whose "object-id" is "dt-000008" from 5:17:10.5 seconds to 10 seconds on August 27, 2019.

[0234] Through the access API 122 that has received the request RQ1, the index acquisition unit 127 acquires, from the index storage unit 126, a "shadow-version" that can identify the shadow 114 that corresponds to the "object-id" and the time information. Then, the index acquisition unit 127 instructs the data acquisition unit 119 to acquire the "latitude" that corresponds to the "object-id" and the "shadow-version." The data acquisition unit 119 acquires the corresponding vehicle data from the shadow storage unit 112, and the vehicle data is sent to the access API 122.

[0235] Request RQ2 is a request to obtain the latitude of vehicles located between 5:17:10.5 and 10 seconds on August 27, 2019, in the rectangular area specified by the upper left point specified by the longitude represented by 135.8974670767784 and the altitude represented by 36.16643474082275, and the lower right point specified by the longitude represented by 139.7863560656673 and the altitude represented by 35.05532363071164.

[0236] Through the access API 122 that has received the request RQ2, the index acquisition unit 127 acquires from the index storage unit 126 a list of "object-ids" of vehicles that exist within the specified area at the specified time, and acquires the "shadow-version" of the "object-id" at the specified time. The index acquisition unit 127 then instructs the data acquisition unit 119 to acquire the "latitude" that corresponds to the "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 sent to the access API 122.

[0237] Request RQ3 is a request to obtain information on all items in the category "ADAS / AD" at 5:17:10.5 on August 27, 2019, from the vehicle whose "object-id" is "dt-000002" and the vehicle whose "object-id" is "dt-000008".

[0238] The index acquisition unit 127 acquires, via the access API 122 that has received the request RQ3, a "shadow-version" that can identify the shadow 114 that corresponds to the "object-id" and the time information, from the index storage unit 126. The index acquisition unit 127 then instructs the data acquisition unit 119 to acquire information on all items in the category "ADAS / AD" that corresponds to the "object-id" and the "shadow-version." The data acquisition unit 119 acquires the corresponding vehicle data from the shadow storage unit 112, and the vehicle data is sent to the access API 122.

[0239] In the management center 3 configured as described above, as shown by arrow L1 in Figure 5, the service providing server 4 identifies the shadow 114 corresponding to the specified vehicle by accessing the digital twin 123 of the data management unit 121 via the access API 122.

[0240] Then, the service providing server 4 transmits a control instruction including the designated shadow and the control content to the vehicle control unit 113 of the mobility GW 111, as indicated by the arrow L2 in FIG.

[0241] As a result, the vehicle control unit 113 transmits a control instruction to the data collection device 2 of the vehicle corresponding to the specified shadow. Then, when the control instruction is received by the data collection device 2, control based on the control instruction is executed in the vehicle equipped with the data collection device 2. [1-11. Effects, etc.] (1a) The mobility IoT system 1 of the first embodiment includes a plurality of data collection devices 2 mounted on a plurality of vehicles, respectively, and a management center 3 capable of data communication with each of the plurality of data collection devices 2.

[0242] The data collection device 2 is configured to store vehicle data transmitted from other devices in the vehicle on which the data collection device 2 is mounted, for example, in a flash memory 25. Also, for example, the second core 22 is configured to transmit the vehicle data to the management center 3 at a first cycle.

[0243] The management center 3 is configured to store the vehicle data sequentially transmitted from the data collecting device 2 in a shadow storage unit 112 as, for example, a shadow 114, and to store a latest index 118 that includes a portion of the vehicle data and is associated with the vehicle data in a latest index storage unit 117. The management center 3 is also configured to store an index 126 created from the latest index 118 in an index storage unit 125.

[0244] Then, when the management center 3 receives the vehicle data transmitted from the data collection device 2, it uses the received vehicle data to update the shadow 114 stored in the shadow storage unit 112 and the latest index 118 stored in the latest index storage unit 117. Furthermore, it updates the index 126 stored in the index storage unit 125 using the latest index 118 at a second cycle (for example, a fixed cycle) that does not require synchronization with the timing of updating the vehicle data.

[0245] As a result, in the present mobility IoT system 1, the index 126 stored in the index storage unit 125 can be updated at a second cycle that is different from the first cycle for transmitting vehicle data, thereby reducing the calculation load on the management center 3. For example, by setting the second cycle to a cycle that is longer than the first cycle that is set to transmit vehicle data at a high frequency, the calculation load on the management center 3 can be reduced.

[0246] Furthermore, when vehicle data is used in a mobility service, 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 calculation load on the management center 3.

[0247] The vehicle control unit 113 may obtain control instructions from the service providing server 4 via the access API 122 of the service-side unit 120. Providing the access API 122 in the service-side unit 120 and providing the vehicle control unit 113 in the vehicle-side unit 110 is also one configuration in which the two units are loosely coupled.

[0248] (1b) In response to a request from a service providing server 4 capable of data communication with the mobility IoT system, the mobility IoT system 1 of this first embodiment can provide vehicle data stored in the shadow memory unit 112 to the service providing server 4 using the index 126 stored in the index memory unit 125.

[0249] (1c) In the mobility IoT system 1 of the first embodiment, when vehicle data is transmitted to the management center 3 at a first cycle, if there is vehicle data that is updated frequently and vehicle data that is updated infrequently, the transmission cycle for the vehicle data that is updated infrequently can be set shorter than the transmission cycle for the vehicle data that is updated infrequently. This will be described in detail below.

[0250] In order to manage the vehicle status on the cloud and instantly reflect the vehicle status, it is conceivable that vehicle data will be sent from the vehicle to the management center 3 at regular intervals. However, the vehicle data may include data that changes little and does not require frequent updates, data that changes frequently and requires frequent updates, and attribute data that does not change once synchronized.

[0251] Furthermore, the continuous transmission of vehicle data results in an increase in the amount of data, which in turn increases communication volume and data management costs. Furthermore, transmitting large amounts of data requires a stable communication environment, but the vehicle environment is subject to rapid change, making it difficult to maintain stable communication.

[0252] Therefore, in the first embodiment, an appropriate transmission period is determined depending on the type of vehicle data. That is, the transmission period of vehicle data that is updated frequently is set shorter than the transmission period of vehicle data that is updated infrequently. This makes it possible to reduce the amount of transmission data as much as possible.

[0253] That is, in the first embodiment, the above-described scheduling function makes it possible to optimize the data update frequency of the vehicle state for each vehicle data, thereby reducing the amount of data and communication overhead.

[0254] In the first embodiment described above, 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 unit, the flash memory 25 corresponds to the first memory unit, the communication unit 32 corresponds to the communication unit, the second memory unit 33a corresponds to the second memory unit, the third memory unit 33b corresponds to the third memory unit, the mobility GW111 corresponds to the first update unit, and the data management unit 121 corresponds to the second update unit.

[0255] <Modification> In addition to the above example, for example, even if the latest index 118 is not stored in advance, the data management unit 121 (i.e., the second update unit) may search the shadow 114 stored in the shadow storage unit 112 (i.e., the second storage unit 33a), extract the equivalent of the latest index 118, and update the data (i.e., the index 126) stored in the index storage unit 125 (i.e., the third storage unit 33b). Note that the mobility IoT system 1 (e.g., the management center 3) may have the function of the service providing server 4. [2. Second Embodiment] Next, a second embodiment will be described.

[0256] The second embodiment has the same basic configuration as the first embodiment, and therefore the following mainly describes the differences from the first embodiment. Note that the same reference numerals as those in the first embodiment indicate the same configuration, and reference is made to the preceding description.

[0257] In the second embodiment, the management center 3 communicates with the service providing server 4 or another external service server 201 to acquire necessary external data (for example, data on weather and traffic conditions). [2-1.Configuration] 27, in the second embodiment, the mobility IoT system 1 includes a management center 3 and a service providing server 4, similar to the first embodiment. The management center 3 includes a service side unit 120 and a vehicle side unit 110. In addition, each vehicle is equipped with a data collection device 2.

[0258] In particular, in the second embodiment, an external service server 201 is connected to the management center 3 so as to be able to perform data communications. This external service server 201 is a server that can supply information on weather such as rain, and information on road congestion conditions (for example, information other than vehicle data).

[0259] Therefore, in this mobility IoT system 1, based on a request from the management center 3, information such as weather information (i.e., weather information) such as rain and traffic congestion status (i.e., traffic congestion information) can be obtained from the external service server 201.

[0260] In the second embodiment, the management center 3 can also acquire vehicle data from the data collection device 2 at a first cycle. The service-side unit 120 can acquire the latest index 118 from the vehicle-side unit 110 at a second cycle (for example, at regular intervals) that is different from the first cycle. [2-2. Service side unit] As shown in Figure 28, the service-side instance 203 of the service-side unit 120 manages time and issues events that instruct specific operations at specific intervals based on information in a database 205 (i.e., DB) that manages events.

[0261] Based on this event, the service side unit 120, like the first embodiment, acquires the latest index 118 created from the vehicle data included in each shadow 114. Then, the service side unit 120 creates an index 126 from the latest index 118 and stores it in the index storage unit 125 (i.e., DB).

[0262] Furthermore, the service side unit 120 acquires external data based on the event. That is, the service side unit 120 acquires weather information and traffic congestion information by requesting the weather information and traffic congestion information from the external service server 201 via the API.

[0263] Weather information may include information indicating which area (e.g., a rectangular area defined by latitude and longitude) is experiencing rain at a certain time. Similarly, traffic congestion information may include information indicating which area is experiencing traffic congestion at a certain time.

[0264] This weather information and traffic congestion information is stored in the index storage unit 125 in association with the index 126 of the vehicle data, for example.

[0265] FIG. 29 shows the structure of an index (hereinafter referred to as a composite index) associated with weather information and traffic congestion information.

[0266] In this composite index, the above-mentioned "object-id" (i.e., the vehicle ID), "location" (i.e., the vehicle's horizontal position), "alt" (i.e., the vehicle's height), and "timestamp" (i.e., the time) information is stored, as well as information regarding "event."

[0267] This information about the "event" indicates the rectangular range of the event. For example, as shown in Figure 30, the area of ​​rain is indicated by a rectangle on a plane representing the ground. [2-3. Operation] Next, the overall operation of the mobility IoT system 1 of the second embodiment will be described.

[0268] As shown in FIG. 31, each vehicle data is transmitted separately from the data collecting device 2 to the vehicle-side unit 110 in the first cycle.

[0269] The service-side unit 120 acquires the latest index 118 from the vehicle-side unit 110 in a second cycle different from the first cycle.

[0270] Furthermore, 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.

[0271] In response to the request, the external service server 201 transmits weather information and the like to the service side unit 120 .

[0272] The service-side unit 120 associates and stores the latest index 118 acquired from the vehicle-side unit 110 with the weather information, etc. acquired from the external service server 201. That is, the service-side unit 120 creates a composite index as shown in Fig. 29 and stores it in the index storage unit 125, for example.

[0273] Here, when a request for the vehicle speed of a vehicle traveling in the rain within a certain area at a certain time is made from the service providing server 4 via the access API 122, the corresponding composite index is extracted from the index storage unit 125 of the service side unit.

[0274] Next, based on the composite index, the shadow memory unit 112 of the vehicle-side unit 110 is accessed, and the vehicle and vehicle speed that meet the above conditions are extracted from the shadow 114 of the shadow memory unit 112, and the vehicle speed information is sent to the service providing server 4.

[0275] This allows the service providing server 4 to acquire information on vehicle speeds that satisfy the desired conditions. [2-4. Effects] The second embodiment provides the same effects as the first embodiment.

[0276] In the second embodiment, the third storage unit 33b is configured to store data other than vehicle data in association with (i.e., integrated with) the index (i.e., composite index) 126. The data other than vehicle data is data supplied from an external server other than the service providing server 4 (i.e., the external service server 201).

[0277] That is, in the second embodiment, a composite index is created as the index 126 of the vehicle data, which includes weather information and traffic congestion information acquired from the external service server 201.

[0278] Therefore, in the second embodiment, it is possible to provide more advanced services in response to requests from the service providing server 4.

[0279] For example, a servicer can easily obtain vehicle data that meets the conditions by simply specifying the VIN, time, and location (i.e., latitude and longitude) of the vehicle for which they want data, without having to access the vehicle directly, making the service possible.

[0280] For example, a servicer can set a time, location range, and event (e.g., a rainy area) in the API, and obtain vehicle data only from vehicles that are in a rainy area within the specified location range at that time. [3. Other embodiments] Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments and can be implemented in various modifications.

[0281] The configuration and method for controlling the system and center described herein may be implemented by a special-purpose computer provided by configuring a processor and memory programmed to execute one or more functions embodied in a computer program. Alternatively, the configuration and method for controlling the system and center described herein may be implemented by a special-purpose computer provided by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the configuration and method for controlling the system and center described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to execute one or more functions with a processor configured with one or more hardware logic circuits.

[0282] The computer program may also be stored as instructions executed by a computer on a computer-readable non-transitory storage medium. The method for realizing the functions of each part included in the system does not necessarily have to include software, and all of the functions may be realized using one or more pieces of hardware.

[0283] In each of the above embodiments, multiple functions of one component may be realized by multiple components, or one function of one component may be realized by multiple components. Furthermore, multiple functions of multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Furthermore, part of the configuration of each of the above embodiments may be omitted. Furthermore, at least part of the configuration of each of the above embodiments may be added to or substituted for the configuration of another of the above embodiments.

[0284] In addition to the above-described system, in-vehicle device, and center, the present disclosure can be realized in various ways, such as a method implemented by a system, a method implemented by an in-vehicle device, a method implemented by a center, etc. Furthermore, the present disclosure can be realized in various forms, such as a program for causing a computer to function as a system, an in-vehicle device, or a center, a non-transitory physical recording medium such as a semiconductor memory on which this program is recorded, and a data management method.

Claims

1. The system comprises a plurality of on-board devices (2) mounted on a plurality of vehicles, respectively, and a center (3) capable of data communication with each of the plurality of on-board devices, The in-vehicle device a first storage unit (25) that stores vehicle data transmitted from another device in the vehicle in which the on-board device is installed, and a transmission control unit (22) that transmits the vehicle data to the center at a first cycle; The center: a second storage unit (33a) for storing the vehicle data sequentially transmitted from the in-vehicle device; a third storage unit (33b) for storing an index, which is information associated with the vehicle data stored in the second storage unit; a first updating unit (111) that, when receiving the vehicle data transmitted from the in-vehicle device, updates the received vehicle data by adding the vehicle data stored in the second storage unit; a second update unit (121) that updates the vehicle data by adding the index stored in the third storage unit in association with the latest data of the vehicle data stored in the second storage unit in a second cycle that does not require synchronization with the update timing by the first update unit; A system (1) comprising:

2. 10. The system of claim 1, the second storage unit is configured to store the vehicle data sequentially transmitted from the in-vehicle device and latest vehicle data that includes a portion of the vehicle data and is associated with the vehicle data; the third storage unit is configured to store the index of the vehicle data stored in the second storage unit; the first update unit is configured, when receiving the vehicle data transmitted from the in-vehicle device, to update the vehicle data and the latest vehicle data stored in the second storage unit using the received vehicle data; the second update unit is configured to update the index stored in the third storage unit based on the latest vehicle data stored in the second storage unit, at the second period that does not require synchronization with a timing of updating the vehicle data stored in the second storage unit. system.

3. 3. The system according to claim 1 or claim 2, The center: In response to a request from a service providing unit (4) that provides a service to the vehicle, the vehicle data stored in the second storage unit is acquired using the index stored in the third storage unit, and the acquired vehicle data is provided to the service providing unit. system.

4. 3. The system according to claim 1 or claim 2, The in-vehicle device When the vehicle data is transmitted to the center in the first cycle, if there is the vehicle data with a high update frequency and the vehicle data with a lower update frequency than the high update frequency, the transmission cycle of the vehicle data with a high update frequency is set to be shorter than the transmission cycle of the vehicle data with a low update frequency. system.

5. 3. The system according to claim 1 or claim 2, The center: In order to update the index, the latest data of the vehicle data is acquired from the second storage unit at a fixed cycle asynchronously with the first cycle. system.

6. 3. The system according to claim 1 or claim 2, The center: and creating a shadow including the vehicle data asynchronously with the first period. system.

7. 3. The system according to claim 1 or claim 2, The third storage unit is configured to store data other than the vehicle data in association with the index stored in the third storage unit. system.

8. A center (3) capable of data communication with a plurality of on-board devices (2) mounted on a plurality of vehicles, respectively, via communication devices (13), a communication unit (32) that receives vehicle data transmitted from the in-vehicle device in a first cycle; a second storage unit (33a) for storing the vehicle data; a third storage unit (33b) for storing an index, which is information associated with the vehicle data stored in the second storage unit; a first updating unit (111) that, when receiving the vehicle data via the communication unit, updates the vehicle data stored in the second storage unit by adding the received vehicle data to the vehicle data; a second update unit (121) that updates the vehicle data by adding the index stored in the third storage unit in association with the latest data of the vehicle data stored in the second storage unit in a second cycle that does not require synchronization with the update timing by the first update unit; Equipped with Center.

9. A control program executed by a center (3) capable of data communication with a plurality of on-board devices (2) mounted on a plurality of vehicles via respective communication devices (13), receiving vehicle data transmitted from the in-vehicle device in a first cycle; storing the vehicle data in a second storage unit (33a), and storing an index, which is information associated with the vehicle data stored in the second storage unit, in a third storage unit (33b); When the vehicle data is received, the received vehicle data is used to update the vehicle data stored in the second storage unit by adding it to the vehicle data; updating the vehicle data by adding the index stored in the third storage unit in association with the latest data of the vehicle data stored in the second storage unit at a second period that does not require synchronization with the timing of the update; A control program for performing a function.

10. A processing method executed by a computer in a system including a plurality of on-board devices (2) mounted on a plurality of vehicles, respectively, and a center (3) capable of data communication with each of the plurality of on-board devices, the method comprising: In the in-vehicle device, storing vehicle data transmitted from other devices in the vehicle in which the on-board device is installed in a first storage unit (25), and transmitting the vehicle data to the center at a first cycle; At the center, storing the vehicle data sequentially transmitted from the in-vehicle device in a second storage unit (33a), storing an index, which is information associated with the vehicle data stored in the second storage unit, in a third storage unit (33b), and when receiving the vehicle data transmitted from the in-vehicle device, updating the vehicle data stored in the second storage unit so that the received vehicle data is added to the vehicle data stored in the second storage unit; updating the vehicle data by adding the index stored in the third storage unit in association with the latest data of the vehicle data stored in the second storage unit at a second period that does not require synchronization with the timing of the update; How the system handles things.

11. A processing method executed by a computer in a center (3) capable of data communication with a plurality of on-board devices (2) mounted on a plurality of vehicles via respective communication devices (13), comprising: receiving vehicle data transmitted from the in-vehicle device at a first period, storing the vehicle data in a second storage unit (33a), and storing an index, which is information associated with the vehicle data stored in the second storage unit, in a third storage unit (33b); When the vehicle data is received, the received vehicle data is used to update the vehicle data stored in the second storage unit by adding it to the vehicle data; updating the vehicle data by adding the index stored in the third storage unit in association with the latest data of the vehicle data stored in the second storage unit at a second period that does not require synchronization with the timing of the update; How the center handles it.

Images