WO2024224746A1 - Data accumulation device, in-vehicle device, intermediate server, data collection device, computer program, and data processing method - Google Patents

Abstract

Provided are a data accumulation device, an in-vehicle device, an intermediate server, a data collection device, a computer program, and a data processing method that make it possible to increase the value of data generated in a vehicle and reduce the concentration of data on a server. The data storage device includes: a data reception unit that receives data from a sensor mounted on a vehicle; a policy reception unit that receives and stores an accumulation policy; and a data accumulation unit that accumulates the data received by the data reception unit, in accordance with the accumulation policy stored by the policy reception unit.

Description

DATA STORAGE DEVICE, ON-VEHICLE DEVICE, INTERMEDIATE SERVER, DATA COLLECTION DEVICE, COMPUTER PROGRAM, AND DATA PROCESSING METHOD

This disclosure relates to a data storage device, an in-vehicle device, an intermediate server, a data collection device, a computer program, and a data processing method. This application claims priority to Japanese Application No. 2023-070535 filed on April 24, 2023, and incorporates all of the contents of said Japanese application by reference.

Currently, data generated in connected cars is stored in servers and other devices for use. In the future, the number of connected cars is expected to increase rapidly, and the number of sensors installed in each connected car is likely to increase as well. As a result, the amount of data handled by servers and other devices is likely to increase exponentially. Meanwhile, most of the data sent to servers in this way is fragmented. As a result, when providing some kind of service to connected cars or users, the data stored in servers is difficult to use, making it difficult to increase the added value of the service. In other words, at present, the value of data stored in servers and other devices is considered to be low.

One proposal for solving these problems is disclosed in Patent Document 1. The technology disclosed in Patent Document 1 correlates two types of data collected in a vehicle. As an example, it cites the correlation of images from an onboard camera with the vehicle's mileage.

JP 2019-185430 A

A data storage device according to one aspect of this disclosure includes a data receiving unit that receives data from a sensor mounted on a vehicle, a policy receiving unit that receives and stores a storage policy, and a data storage unit that stores the data received by the data receiving unit according to the storage policy stored by the policy receiving unit.

The present invention can be realized not only as a data storage device having such characteristic processing units, but also as a data storage method having such characteristic processing steps, or as a program for causing a computer to execute such steps. It can also be realized as a semiconductor integrated circuit that realizes part or all of the data storage device, or as a data storage system that includes the data storage device.

FIG. 1 is a schematic diagram for explaining the problems of the conventional technology. FIG. 2 is a schematic diagram showing the configuration of a data processing system according to the first embodiment of the present disclosure. FIG. 3 is a schematic diagram showing an overview of data processing in the data processing system shown in FIG. FIG. 4 is a diagram showing a network device configuration in a vehicle used in a data processing system according to the present disclosure. FIG. 5 is a block diagram showing the functional configuration of a vehicle and a user terminal which constitute a part of the data processing system. FIG. 6 is a diagram showing an example of the configuration of a data table of the in-vehicle data generating unit shown in FIG. FIG. 7 is a diagram showing another example of the configuration of the data table of the in-vehicle data generating unit shown in FIG. FIG. 8 is a flowchart showing a control structure of a program executed in the user terminal shown in FIG. FIG. 9 is a flowchart showing a part of a control structure of the flowchart shown in FIG. FIG. 10 is a flowchart representing a control structure of a program executed by the vehicle shown in FIG. 5 in response to receiving the storage policy. FIG. 11 is a flowchart representing a control structure of a program executed by the vehicle shown in FIG. 5 in response to receiving a request for providing in-vehicle data. FIG. 12 is a flowchart showing a control structure of an on-board DB (Database) management program executed by the on-board data management unit shown in FIG. FIG. 13 is a block diagram showing the hardware configuration of a computer for realizing the zone ECU (Electronic Control Unit) and user terminal shown in FIG. 5. FIG. 14 is a schematic diagram showing a schematic configuration of a data processing system according to the second embodiment of the present disclosure.

[Problem to be solved by this disclosure]
The technology disclosed in Patent Document 1 is said to have the effect of making it possible to easily obtain video from an on-board camera at the time of an event, for example, if the distance traveled by a vehicle until the occurrence of that event is known.

However, the effect of the technology disclosed in Patent Document 1 is limited to making it easy to obtain one data from another, and there is a problem in that it cannot be used to obtain new information from accumulated data. In addition, it does not address the problem of data concentration on servers, etc. There remains the possibility that data processing on the server will be hindered due to data concentration on the server. Therefore, the technology described in Patent Document 1 has the problem of not being able to increase the value of data generated in vehicles, and not being able to reduce the load on the server.

The purpose of this disclosure is to provide a data storage device, an in-vehicle device, an intermediate server, a data collection device, a computer program, and a data processing method that can increase the value of data generated in vehicles and reduce data concentration on servers.

[Effects of the present disclosure]
As described above, according to this disclosure, it is possible to provide a data storage device, an in-vehicle device, an intermediate server, a data collection device, a computer program, and a data processing method that can increase the value of data generated in a vehicle and reduce data concentration on a server.

[Description of the embodiments of the present disclosure]
In the following description and drawings, the same parts are denoted by the same reference numerals. Therefore, detailed description thereof will not be repeated. Note that at least some of the embodiments described below may be combined in any manner.

(1) A data storage device according to a first aspect of this disclosure includes a data receiving unit that receives data from a sensor mounted on a vehicle, a policy receiving unit that receives and stores a storage policy, and a data storage unit that stores the data received by the data receiving unit in accordance with the storage policy stored by the policy receiving unit. With this configuration, even different data storage devices can store data from sensors in accordance with a common storage policy. This can increase the value of data generated in vehicles and reduce data concentration on servers.

(2) In (1) above, the data storage device may further include a data providing unit that, in response to the establishment of a condition for providing data stored in the data storage unit to an external party, reads data determined by the condition from the data storage unit and transmits the data to a destination determined by the condition. With this configuration, even different data storage devices can store data according to a common storage policy and transmit the data to the destination. The destination, for example a server or a terminal device that creates the data, can receive and process data generated in the same format according to the storage policy. This increases the value of data generated in vehicles and reduces data concentration on servers.

(3) In (2) above, the storage policy may be assigned a unique identifier, and the storage policy may include data item information that specifies the data items to be stored, and the data storage unit may include a database that, in response to the policy receiving unit receiving a new storage policy having an identifier that has not been stored by the policy receiving unit, stores the data in a new data table that stores each data item specified by the new storage policy in each column. With this configuration, the data storage device can start storing data required for a new service by using the new storage policy. In either data transmission system, data storage according to the new storage policy begins. As a result, the data storage device can store appropriate data corresponding to the start of a new service, increasing the value of data generated in the vehicle and reducing data concentration on the server.

(4) In (3) above, the policy receiving unit may replace the first storage policy with the second storage policy in response to receiving a new second storage policy having the same identifier as the identifier of the first storage policy stored by the policy receiving unit. With this configuration, an identifier can be specified to replace an old storage policy with a new storage policy. In either data transmission system, data storage according to the new storage policy begins. This makes it possible to store appropriate data in response to continuous changes in services, increase the value of data generated in vehicles, and reduce data concentration on servers.

(5) In (3) above, the policy receiving unit may, in response to receiving a storage policy modification instruction specifying an identifier of the first storage policy stored by the policy receiving unit, modify the first storage policy in accordance with the modification instruction. With this configuration, an identifier can be specified to modify an old storage policy and change it to a new storage policy. In either data transmission system, data storage according to the new storage policy begins. This makes it possible to store appropriate data in response to continuous changes in services, increase the value of data generated in vehicles, and reduce data concentration on servers.

(6) In (4) or (5) above, the data storage unit may change the data table created according to the first storage policy in accordance with the changed storage policy in response to a change in the first storage policy. With this configuration, data created according to an old storage policy can be remade into data that complies with a new storage policy. This makes it possible to store appropriate data in response to continuous changes in services, increase the value of data generated in vehicles, and reduce data concentration on servers.

(7) In (6) above, the data storage device may further include a priority assignment unit that assigns a priority to each of the columns of the multiple data tables according to the number of data tables that have a data item corresponding to the column in common. With this configuration, data items used in multiple data tables can be distinguished from other data items. The importance of each data item becomes clear, and the handling of data items can be easily distinguished.

(8) In the above (7), the data storage device may further include a data management unit that, in response to the available data capacity in the data storage unit falling below a threshold, deletes, from among the columns of the plurality of data tables, columns that have been assigned a lower priority by the priority assignment unit than the other columns. With this configuration, when the storage conditions of the database become severe, the data storage capacity can be reduced by deleting data items with a lower priority, thereby increasing the available storage capacity.

(9) In (3) above, the storage policy may include data processing information that specifies a method of data processing to be performed on the data received by the data receiving unit, and the data item information may further include a data item that is the result of the data processing. In data processing, the results of calculations performed on collected data may be used. By performing such data processing in the data storage device, it is possible to omit performing such data processing in the device that ultimately uses the data.

(10) In the above (1), in response to receiving a data provision request from an external source, the data providing unit may read data determined by the data provision request from the data storage unit and provide the data to a destination determined in association with the data provision request. With this configuration, the data collecting device can immediately obtain data required to execute a service and in a format suitable for data processing by transmitting a data provision request to the data providing system.

(11) In the above (1), when a transmission condition specified by the first storage policy stored by the storage policy receiving unit is met, the data providing unit may read data determined by the first storage policy from the data storage unit and transmit the data to a destination determined in association with the first storage policy. With this configuration, the data collecting device can obtain data necessary for executing a service and in a format suitable for data processing when a specified transmission condition is met, without having to request data itself.

(12) In the above (1), when the communication cost with a destination specified by the first storage policy stored by the storage policy receiving unit falls below a threshold, the data providing unit may read data determined by the first storage policy from the data storage unit, and aggregate and transmit the data to a destination determined in association with the first storage policy. With this configuration, the data collecting device can obtain data required to execute a service and in a format suitable for data processing at a stable communication cost, without having to request data itself.

(13) The in-vehicle device according to the second aspect of this disclosure includes any one of the data storage devices described above in (1) to (12). With this configuration, even different in-vehicle devices can store data according to a common storage policy. This increases the value of data generated in the vehicle and reduces data concentration on the server.

(14) The intermediate server according to the third aspect of this disclosure is an intermediate server including any one of the data storage devices described above in (1) to (12), in which the data receiving unit receives the data from one or more vehicles, and the policy receiving unit receives and stores a storage policy from a server different from the intermediate server. With this configuration, instead of the in-vehicle device storing the data, the intermediate server receives the data from the in-vehicle device and processes the data in accordance with the storage policy. This storage policy is used in common by multiple intermediate servers. As a result, even if different intermediate servers collect data from different in-vehicle devices, data in accordance with a common storage policy can be stored in the data storage device. This increases the value of data generated in vehicles and reduces data concentration on the server.

(15) A data collection device according to a fourth aspect of this disclosure includes a storage policy creation unit for creating a storage policy, a storage policy storage unit for assigning a unique identifier to the storage policy maintained by the storage policy creation unit and storing the storage policy, and a storage policy synchronization processing unit for synchronizing the storage policy stored in the storage policy storage unit with a storage policy held by another device and having the same identifier as the storage policy. With this configuration, the configuration of data required for a service provided by the data collection device is specified by the storage policy. It becomes possible to update the storage policy based on the identifier, and it is easy to respond even if the method of storing required data changes as the service changes.

(16) In (15) above, the data collection device may be capable of executing one or more data usage programs each of which provides a predetermined service using data obtained from a vehicle, and the storage policy creation unit may analyze each of the one or more data usage programs and, for each data usage program, identify the data to be processed, thereby generating or updating the storage policy for that data usage program. With this configuration, the data collection device can receive data stored in a format that complies with the storage policy for each of the one or more data usage programs, and immediately use the data to provide a service. In other words, the value of the data can be increased.

(17) A computer program according to a fifth aspect of this disclosure causes a computer to function as a data receiving unit that receives data from a sensor mounted on a vehicle, a policy receiving unit that receives and stores a storage policy, and a data storage unit that stores the data received by the data receiving unit in accordance with the storage policy stored by the policy receiving unit. With this configuration, even different vehicle-mounted devices can store data from sensors in accordance with a common storage policy by executing this program. This can therefore increase the value of data generated in vehicles and reduce data concentration on servers.

(18) A computer program according to a sixth aspect of this disclosure causes a computer to function as a storage policy creation unit for maintaining a storage policy, a storage policy storage unit for assigning a unique identifier to the storage policy created by the storage policy creation unit and storing it, and a storage policy synchronization processing unit for synchronizing a storage policy stored in the storage policy storage unit with a storage policy held by another device and having the same identifier as the storage policy. With this configuration, the configuration of data necessary for providing a service is specified by the storage policy. It becomes possible to update the storage policy based on the identifier, and it is easy to respond even if the method of storing necessary data changes as the service changes.

(19) A data processing method according to a seventh aspect of this disclosure includes a data receiving step in which a computer receives data from a sensor mounted on a vehicle, a policy receiving step in which the computer receives and stores a storage policy, and a data storage step in which the computer stores the data received in the data receiving step in accordance with the storage policy stored in the policy receiving step. With this configuration, even if different vehicle-mounted devices execute this method, data from the sensors can be stored in accordance with a common storage policy. This increases the value of data generated in the vehicle and reduces data concentration on the server.

(20) A data processing method according to an eighth aspect of this disclosure includes a creation step in which a computer creates a storage policy, a storage policy storage step in which the computer assigns a unique identifier to the storage policy created in the creation step and stores it, and a synchronization processing step in which the computer synchronizes the storage policy stored in the storage policy storage unit with a storage policy held by another device and having the same identifier as the storage policy. With this configuration, the configuration of data necessary for providing a service is specified by the storage policy. It becomes possible to update the storage policy based on the identifier, and it is easy to respond even if the method of storing necessary data changes as the service changes.

[Details of the embodiment of the present disclosure]
Specific examples of the data storage device, the in-vehicle device, the intermediate server, the data collection device, the computer program, and the data processing method according to the embodiments of the present disclosure will be described below with reference to the drawings. Note that the present disclosure is not limited to these examples, but is defined by the claims, and is intended to include all modifications within the meaning and scope equivalent to the claims.

1. First embodiment Fig. 1 shows an outline of data processing in a conventional server or the like. Referring to Fig. 1, in a conventional data processing system 50, data 68, 70, 72, etc. generated in individual vehicles 60, 62, 64, etc. are all transmitted to a server 74 via a network 66. The server 74 creates information for, for example, driving assistance based on the data, and distributes the information to each of the vehicles 60, 62, 64, etc., or each user.

In this configuration, data is concentrated on server 74, which may strain server 74's resources and cause problems in providing services. In addition, the data sent from each vehicle to server 74 is fragmented, which is problematic in that it is difficult for server 74 to use the data to provide certain services.

FIG. 2 shows a schematic configuration of the data processing system 100 in the first embodiment of this disclosure. Referring to FIG. 2, in this embodiment, each of the vehicles 110, 112, 114, etc. processes data generated in the vehicle in advance and stores the data. Then, when a data collection device 128 consisting of a server, user terminal, etc. requests the provision of data, the vehicle that receives the request reads the requested data 120, 122, 124, etc. from the stored data and provides it to the data collection device 128 via the network 126.

In addition, in this embodiment, the following mechanism is provided to prepare the data required by the data collection device 128 through data processing in the vehicle 110, etc.

FIG. 3 shows a schematic configuration of the data processing 150. Referring to FIG. 3, the data processing 150 includes a server-side processing 162 and a vehicle-side processing 160.

The server-side processing 162 creates, for each application (hereafter simply referred to as "app") 172, a storage policy 170 that specifies the method of storing data used in that app. The storage policy 170 specifies what data is to be stored and how frequently, what data processing is to be performed on the data, how to identify the stored data items, and so on. Data processing includes, for example, statistical processing methods, classification, summarization, calculations between data items, units, data format, compression methods for data that requires compression, storage methods, and information required to ensure security. For example, when a calculation is performed between data items, a data item for storing the calculation result is added and specified.

The storage policy can be said to be similar to the design concept of a database data table for accumulating data required for processing. As mentioned above, the storage policy can be said to be a parameter for shaping and storing in-vehicle data according to its intended use. Although there are no particular limitations to the storage policy, it is typically information for defining the column configuration of each data table, the format of the data items in each column, the frequency of data acquisition, etc. In the case of an in-vehicle device, possible data items for each column include the date and time of data acquisition, location, vehicle speed at the time of data acquisition, type of road the vehicle was traveling on when the data was acquired, driving scene, occurring event, data storage period, sensor data priority, and target sensor.

The server-side processing 162 distributes this storage policy 170 to vehicles that are the subject of data collection. The server-side processing 162 also sends a data request to each vehicle when each application 172 is executed so that each application 172 sends the data it requires, and a data request 174 is executed, which is a process that receives data from each vehicle and provides it to each application 172. At this time, all of the data provided to the data request 174 is data that has been stored based on the same storage policy. As a result, each application 172 can immediately use this data for processing. Even if the data is provided from different vehicles, if it is based on the same storage policy, it will be in the same format, allowing for efficient and accurate processing.

The storage policy may include information that identifies the terminal to which data is to be provided according to the storage policy. If the information that identifies the terminal to which data is to be provided is different from the terminal that created the storage policy, the data stored according to the storage policy is sent to a terminal other than the device that created the storage policy.

The vehicle-side processing 160 includes a data storage processing 190 that receives and stores a storage policy received from the server-side processing 162, and stores data from the on-board sensor 164 according to the storage policy. In this embodiment, the data is stored in an on-board DB 192. The vehicle-side processing 160 in this embodiment further includes an on-board data providing processing 194 that, in response to a data provision request to provide specific data to the data collection device 128, reads the specified data from the on-board DB 192 and provides it to the data collection device 128.

In other words, in this embodiment, data processing is not centralized in a server, but is executed in each vehicle, so-called distributed processing is adopted. Then, by distributing in advance from the data collection device 128 to each vehicle how to accumulate data in distributed processing, the data collection device 128 can receive data that has already been processed. As a result, the data collection device 128 has the effect of being able to immediately use the received data without preprocessing it. Also, if the same accumulation policy is distributed to each vehicle for data required for the same processing, data with the same configuration is transmitted from each vehicle to the data collection device 128. The data can be used effectively without being unified or fragmented, making it difficult to use. In other words, by accumulating data in accordance with the accumulation policy in each vehicle, the value of the data can be increased. Also, when there is a change or addition to the service executed by the data collection device 128, it is possible to quickly collect information about the changed service and the new service by changing or adding the accumulation policy accordingly. As a result, the value of data can be continuously improved, and various services can be developed.

To perform this processing, a unique identifier is assigned to each storage policy. By making these identifiers unique, it becomes possible to update or delete storage policies. This identifier can be anything that is unique, but for example, the name of the corresponding service or the identifier of the service can be used.

This embodiment will be described in detail below. FIG. 4 shows an example of an in-vehicle network 250 that is mounted on a vehicle and includes various electronic devices that perform electronic data processing and control within the vehicle. Referring to FIG. 4, this in-vehicle network 250 includes a central ECU 240 and zone ECUs 262 and 264 that are connected to the central ECU 240 via a network and manage networks of separate zones. The zone ECUs 262 and 264 each reduce the load on the central ECU 240 by controlling each part of the network that they manage. Although not shown, the in-vehicle network is provided with a wireless communication device for wirelessly communicating with the outside of the vehicle. The zone ECU 262 is an example of a data storage device in this embodiment. The ECU is also an example of an in-vehicle device.

The network managed by zone ECU 262 is connected to sensors such as acceleration sensor 288, on-board camera 290, and lidar 292, as well as ECUs 266, 268, 270, and 272 for controlling various parts of the vehicle. The example shown in FIG. 4 is just one example, and many other sensors and ECUs are connected to zone ECU 262 via the network.

Similarly, sensors such as an acceleration sensor 286, an onboard camera 284, and a lidar 282, as well as ECUs 274, 276, 278, and 280 for controlling various parts of the vehicle, are connected to the network managed by the zone ECU 264.

In the embodiment described below, the vehicle-side processing 160 shown in FIG. 3 is implemented in the zone ECU 262 shown in FIG. 4. The zone ECU 262 and the zone ECU 264 are connected via a network. Therefore, the zone ECU 262 is also supplied with data from sensors and the like that are connected to the network managed by the zone ECU 264.

With reference to FIG. 5, a data processing system 350 including a vehicle 360 and a user terminal 362 will be described as an example of a data processing system. In this example, the user terminal 362 communicates with a zone ECU 262 constituting a data storage device, and functions as a data collection device that collects data required by various applications 436 running on the user terminal 362 from the in-vehicle network 250. This user terminal 362 provides information only to the user who uses the user terminal 362. However, this disclosure is not limited to such an embodiment. For example, the user terminal 362 may be a server that is connected to multiple user terminals such as the user terminal 362 and provides services to users via these user terminals.

The user terminal 362 includes the various applications 436 described above, a storage policy creation unit 434 that analyzes the processing contents (contents of data processing performed by the program) of the various applications 436 and identifies the data to be processed based on the analysis results, thereby performing maintenance such as creating and modifying data storage policies, a storage policy memory unit 432 that stores the storage policies created by the storage policy creation unit 434, a storage policy synchronization processing unit 430 that synchronizes the storage policy registered in the storage policy memory unit 432 with the storage policy held by the in-vehicle network 250 in response to the storage policy creation unit 434 creating a new storage policy or modifying an existing storage policy, and an in-vehicle data acquisition unit 438 that, when the various applications 436 are operating, specifies data items required by the various applications 436 and sends a data provision request to the zone ECU 262, and provides the values of the provided data items to the various applications 436. In addition, the zone ECU 262 holds a destination list 450 that specifies multiple destinations for each storage policy, and the storage policy synchronization processing unit 430 and the in-vehicle data acquisition unit 438 operate by referring to this destination list 450.

In the following description, the user terminal 362 will be described as acquiring data only from the zone ECU 262. However, this disclosure is not limited to such an example. The user terminal 362 may acquire data from on-board devices of multiple vehicles, or may acquire data from multiple on-board devices of a single vehicle. To enable such data acquisition, the on-board data acquisition unit 438 has the above-mentioned destination list 450. The destination list 450 holds information (such as, but not limited to, an IP address) that identifies the ECU from which data is to be acquired. The user terminal 362 performs the processing described below for each ECU listed in the destination list 450, making it possible to acquire a large amount of data items with the same configuration from multiple on-board devices.

The in-vehicle network 250 includes a zone ECU 262 and various sensors 370, including an in-vehicle camera, a lidar, an acceleration sensor, etc. The zone ECU 262 receives data from the various sensors 370 via the network.

The zone ECU 262 includes a temporary buffer 402 that temporarily stores data from the various sensors 370, a raw data storage unit 400 that receives data from the various sensors 370 and temporarily stores the data in the temporary buffer 402, a storage policy receiving unit 404 that receives a storage policy from the storage policy synchronization processing unit 430, and a storage policy memory unit 406 that stores the storage policy received by the storage policy receiving unit 404.

If a storage policy with the same identifier as the received storage policy is stored in the storage policy storage unit 406, the storage policy receiving unit 404 replaces the storage policy stored in the storage policy storage unit 406 with the newly received storage policy. This process allows for the storage of new data to begin immediately in accordance with changes in the content of the data to be stored when the service content changes. Note that an example of replacing an old storage policy with a new storage policy has been given here. However, this disclosure is not limited to such an embodiment. The changes between the old and new storage policies and the identifier of the storage policy may be transmitted to the zone ECU 262. In this case, a new storage policy is generated by replacing the data items designated as differences in the storage policies stored in the storage policy storage unit 406 with the new contents.

When a storage policy is changed, it is desirable to change existing data to a format that complies with the new storage policy if possible. For example, if the number of digits in a database is increased, or if it is specified that new data items generated by operations between existing data are to be stored, the data table can be changed to one that complies with the new storage policy by simply redefining the format of the data item or adding a new data item using the existing data.

The zone ECU 262 further includes a data storage unit 408 for processing the data stored in the temporary buffer 402 in accordance with a storage policy received from the user terminal 362 and storing the data, and an in-vehicle data providing unit 410 for responding to a data provision request from the in-vehicle data acquisition unit 438 of the user terminal 362, reading from the data storage unit 408 the data items specified by the data provision request, and, if data processing is specified by the storage policy, processing the data and providing it to the in-vehicle data acquisition unit 438.

The data storage unit 408 includes an in-vehicle DB 418, which is a database that stores data and outputs data specified by a search request in response to a search request that conforms to a specified grammar, and an in-vehicle data table creation unit 412 that creates a new data table specified by a new storage policy in the in-vehicle DB 418 when the storage policy receiving unit 404 receives the new storage policy, and changes the existing data table to a data table that conforms to the new storage policy in response to the storage policy receiving unit 404 receiving a modified storage policy already stored in the storage policy memory unit 406.

When the in-vehicle data table creation unit 412 creates an in-vehicle data table, it takes into consideration the frequency of data acquisition, the size of the acquired data, the frequency of reference, the data storage period, and the capacity of the available storage device to determine in which storage device the data table should be placed. If necessary, separate databases may be created in different storage devices, and different data tables may be created in databases in different storage devices. The storage device may be a storage device built into the in-vehicle device, a storage device directly added to the in-vehicle device, or a storage device capable of communicating with the in-vehicle device via a network. It is necessary to store these data for a certain period of time. Therefore, at least when the vehicle is stopped, the database data needs to be stored in a non-volatile storage device (such as a hard disk or SSD (Solid State Drive)).

The data storage unit 408 further includes an in-vehicle data generation unit 414 for adding data temporarily stored in the temporary buffer 402 to a data table corresponding to each storage policy created by the in-vehicle data table creation unit 412 according to each storage policy stored in the storage policy storage unit 406, or for modifying existing data, an important key update unit 420 for updating information on important data items (these are called "important keys") in each data table maintained by the in-vehicle DB 418 when the contents stored in the storage policy storage unit 406 are changed, and an in-vehicle data management unit 416 for monitoring the available storage capacity of the in-vehicle DB 418, and performing a process of increasing the available storage capacity of the in-vehicle DB 418 by deleting part of the data stored in the in-vehicle DB 418 when the available storage capacity falls below a threshold. When the in-vehicle data management unit 416 deletes data, it basically saves the important key specified by the important key update unit 420 and deletes the other data. When there is no data that can be deleted other than the important keys, the in-vehicle data management unit 416 deletes data items with low priority among the important keys. Note that priority can also be taken into consideration when determining which data to delete. It is believed that deleting low-priority data will have less impact than deleting high-priority data. Therefore, when available storage capacity becomes scarce, low-priority data may be deleted.

FIG. 6 shows an example of the configuration of a sensor data table 460, which is an example of a data table created in the in-vehicle DB 418. Referring to FIG. 6, this sensor data table 460 is shown in a matrix format, with each row showing one record of sensor data collected in time series and stored in the in-vehicle DB 418. However, the first row in FIG. 6 shows the name of the data item included in each record, and is not an actual record. Each column in the first row is called a "column." For example, each record includes a date and time column 462, a sensor ID column, a sensor data column, and a priority column.

The sensor ID is an identifier assigned to each sensor in each vehicle. The sensor data is output data from each sensor, and includes different data depending on the function of each sensor. In this embodiment, the sensor data item stores the file name in which the sensor data is saved. The actual sensor data is stored in a file specified by this file name, for example, in an on-board storage device. In this way, by saving the sensor data in a file and storing the file name in the on-board DB 418, the amount of accumulated data does not increase unnecessarily, even if it is necessary to save data common to multiple data tables. Furthermore, sensor data that is not referenced in any data table is considered to be virtually unused. Therefore, data may be discarded at appropriate times. As a result, the capacity of the data storage medium can be used effectively.

The priority is specified by the data requester. For example, if "1" is specified as the priority, only the data of records with a priority value of "1" is extracted and sent. If "2" is specified as the priority, only the data of records with a priority value of "2" or less is extracted and sent. The same applies below. However, this disclosure is not limited to this. For example, regardless of the specified priority value, only the data of records with the same priority value may be extracted and sent. This priority is determined primarily by the priority of the application that uses each data. The priority of an application is basically determined by the ASIL (Automotive Safety Integrity Level) to which each application is related, and the form of service provision. The form of service provision differs from the perspective of whether it is necessary to immediately provide the user with the processing results based on the data when a request is made by the user.

FIG. 7 shows another example of data table 480. Referring to FIG. 7, this data table 480 is a data table for managing data that is highly related to each other when some event is recorded in a vehicle. Data table 480 includes a date and time column 422 indicating the date and time when the event was recorded, a vehicle speed column indicating the vehicle speed at that time, a road type column indicating the type of road the vehicle was traveling on when the event was recorded, an event column indicating the type of event, and a data file name of the data recorded by the sensor at that time.

Both data table 460 shown in FIG. 6 and data table 480 shown in FIG. 7 include a "date and time" column (date and time column 462 in FIG. 6, and date and time column 422 in FIG. 7), and no other column names are common. In this embodiment, a data item that is common to multiple data tables, such as date and time columns 462 and 422, is called an important key. An important key is assigned an importance level according to the number of data tables (with different storage policies) that share the data item. In this embodiment, the importance level is the number of data tables that share the data item itself.

FIG. 8 is a flowchart showing the control structure of a program for implementing the functions of the user terminal 362 shown in FIG. 5. This program is started when execution of an application is started. This program first searches the storage policy storage unit 432 in FIG. 5 for a storage policy that corresponds to the running application (step 520). This search can be performed, for example, by assigning an identifier that is the same as the name of the application to the storage policy. Then, the control flow branches depending on whether or not a matching storage policy is found (step 522).

If the determination in step 522 is positive, it is determined whether the launched application has been updated since the previous execution, and the flow of control is branched according to the result (step 524). The determination in this step of whether the application has been updated can be made by comparing the version of the application when it was executed last time with the version when it is executed this time. Of course, when the application is an executable file, for example, this can also be done by comparing the hash of the file.

If the determination in step 524 is negative, no change is required to the storage policy. Therefore, control proceeds to step 526, where a request for on-board data is made to the zone ECU 262 shown in FIG. 5. The data request here specifies a specific data item according to data described in the application, for example. The simplest implementation method is to transcribe the data items specified by the SQL statement when the application issues an SQL statement to read data from the database into the request. To do this, when the application is designed, the database name, data table name, and data item name required when the application is executed are determined, and the application is created accordingly. If these database names, data table names, and data items are transcribed into the data storage policy, the on-board data providing unit 410 shown in FIG. 5 can easily create an SQL statement to be issued to the on-board DB 418 in the zone ECU 262 based on the SQL statement issued by the application, based on information from the on-board data acquisition unit 438. The in-vehicle data providing unit 410 issues this SQL statement to the in-vehicle DB 418 shown in FIG. 5 and reads the requested data items from the in-vehicle DB 418.

Following step 526, the in-vehicle data acquisition unit 438 receives the in-vehicle data from the in-vehicle data provision unit 410 shown in FIG. 5 and stores the data in a storage device (not shown) in the user terminal 362 (step 528). Then, the various applications 436 shown in FIG. 5 perform predetermined processing on the in-vehicle data (step 530), and the processing ends.

On the other hand, when the determination in step 522 is negative and when the determination in step 524 is positive, a new storage policy is created (step 532). The processing in step 530 is performed in a process independent of each application. Therefore, it may be necessary to create storage policies for multiple applications at the same time. The creation of a new storage policy will be described later with reference to FIG. 9. In the following step 534, the storage policy created in step 532 is shared and updated. Specifically, at this time, the storage policy synchronization processing unit 430 shown in FIG. 5 stores the newly created storage policy in the storage policy storage unit 432 and simultaneously transmits it to the storage policy receiving unit 404. The storage policy receiving unit 404 receives this storage policy, determines whether it is necessary to store and update the storage policy, and performs the necessary processing. The storage policy reception performed by the storage policy receiving unit 404 at this time will be described later with reference to FIG. 10. When the storage policy receiving unit 404 completes the storage and update processing of the received storage policy, it transmits a notification to the storage policy synchronization processing unit 430 indicating that the processing is completed. When the user terminal 362 confirms this notification in step 536, control proceeds to step 526. The following processing is the same as when no storage policy needs to be created.

In this example, the in-vehicle device is requested to provide data immediately in step 526. However, this disclosure is not limited to such an embodiment. For example, the data provision request may specify that data is to be provided periodically. When the in-vehicle device receives such a provision request, it may not only transmit the data at the same date and time, but may also provide the data collectively under the best conditions, such as communication standby and communication cost, within a range that does not greatly differ from the specified frequency or date and time. In this case, instead of making a request to transmit data from the service side, an instruction such as a transmission frequency may be included in the storage policy. It is basically difficult to determine whether the communication cost is optimal. Therefore, a threshold value for the communication cost may be determined in advance, and data may be transmitted when the actual communication cost falls below the threshold value or is equal to or less than the threshold value. The communication cost in this case can typically be considered as the time required to transmit a unit amount of data. The time required for communication can be calculated based on the delay time until a response is received from a periodic transmission of a ping command to the other device and the amount of data to be transmitted.

Referring to FIG. 9, step 532 in FIG. 8 includes step 560, which branches the flow of control depending on whether there are multiple applications for which a storage policy is to be created, step 568, which extracts a data read command for the relevant application when the determination in step 560 is negative, and step 570, which creates a single storage policy based on the read command extracted in step 568 and terminates the process.

The program further includes a step 562 for determining the priority of each application when the determination in step 560 is negative, a step 564 for extracting a data read command in each application, and a step 566 for creating an individual storage policy for each application based on the information obtained in steps 562 and 564, and terminating the process.

10 shows the control structure of a program executed by the storage policy receiving unit 404 shown in FIG. 5 when a storage policy is received from the storage policy synchronization processing unit 430 shown in FIG. 5. This program is started in response to receiving the storage policy. Referring to FIG. 10, this program includes step 600 for branching the flow of control according to whether or not there is a storage policy (application) having the same identifier as the received storage policy, and step 602 for updating the data table created in accordance with the existing storage policy in accordance with the newly received storage policy when the determination in step 600 is affirmative. Specifically, this process extracts the differences between each column of each related data table and each column defined in the data table by the new storage policy. This process further generates a command statement for making changes to each data table corresponding to the differences, and issues it to the in-vehicle DB 418. Such a command statement differs depending on the database, but an alter table command, for example, is used.

Furthermore, in response to the changes occurring in the configuration of the data tables in the in-vehicle DB 418 due to these updates, the storage policy receiving unit 404 updates the important keys in the in-vehicle DB 418 (step 604). Furthermore, in response to the changes occurring in the configuration of the data tables, the storage policy receiving unit 404 updates the data in each data table, if necessary (step 606). In the case of data deletion, when the column name is deleted from the data table, the change is immediately reflected in the in-vehicle DB 418. On the other hand, when a column is newly created, if that data is stored, that data is substituted for the data item corresponding to that column in each record. When a column is newly created and the results of some operation performed between the data items of existing columns are to be stored in that column, the corresponding data processing is performed and the result is substituted for the newly created column.

In the next step 608, a notification that the data table update has been completed is sent from the storage policy receiving unit 404 shown in FIG. 5 to the storage policy synchronization processing unit 430, and execution of this program ends. Note that the storage policy receiving unit 404 manages the storage policies by assigning the same identifier to the new storage policy or the updated storage policy as the identifier of the application that uses the storage policy.

On the other hand, if the determination in step 600 is negative, a new data table having a record structure (column configuration) according to the specified storage policy is created (step 610). Furthermore, if there is existing data to be substituted for each data item of each record in the new data table, the data is substituted into the data table to generate in-vehicle data (step 612). In the following step 614, the storage policy synchronization processing unit 430 in FIG. 5 is notified that the creation of the data table has been completed, and execution of this program is terminated.

FIG. 11 shows the control structure of a program executed by the in-vehicle data providing unit 410 when the in-vehicle data acquisition unit 438 shown in FIG. 5 transmits a data provision request to the in-vehicle data providing unit 410. Referring to FIG. 11, this program is started in response to the in-vehicle data providing unit 410 receiving the above-mentioned data provision request. This program includes a step 650 of creating an SQL statement for reading out a specified data item from the in-vehicle DB 418 based on the database name, data table name, and data item included in the received data provision request.

This program further includes step 652 of receiving an array of data search results from the in-vehicle DB 418 using the SQL statement created in step 650 by inputting the SQL statement from the in-vehicle DB 418, and step 654 of sending the search results received in step 652 to the in-vehicle data acquisition unit 438 of the terminal that sent the data request (user terminal 362 in the example shown in FIG. 5), and terminating the process.

Figure 12 shows the control structure of a program for on-board data management executed by the on-board data management unit 416. On-board data management here refers to the management of available storage space in the storage device used by the on-board DB 418. The storage space used by the on-board DB 418 increases as data is stored. Also, the storage capacity of the storage device available to the zone ECU 262 is finite. Therefore, as the amount of data increases, the storage space available to the on-board DB 418 decreases, and if nothing is done, new data will not be able to be stored in the on-board DB 418. Therefore, it is necessary to monitor the amount of data used by the on-board DB 418 and the storage capacity available to the data accumulation unit 408, and to keep the data capacity available to the on-board DB 418 at an appropriate level or higher.

12, this program includes step 680 for branching the flow of control according to whether or not the storage usage rate, which indicates the ratio of the area used by data accumulation unit 408 to the storage capacity available to in-vehicle DB 418, is a predetermined value, for example, 80% or more. If the determination in step 680 is negative, there is no problem with the storage capacity for in-vehicle DB 418. Therefore, execution of this program ends.
If the determination in step 680 is positive, the flow of control is further branched in step 682 according to whether or not there are keys (data items) other than the important keys. If the determination in step 682 is positive, that is, if there are keys other than the important keys, control proceeds to step 684, where any key other than the important keys is selected and deleted by some method, and control returns to step 680. If the determination in step 682 is negative, control proceeds to step 686. In step 686, the important keys are deleted. At this time, the important keys are deleted in order starting from those with the fewest number of data tables sharing the key. After this, control returns to step 680.

As described above, according to this embodiment, a storage policy according to the application executed in the user terminal 362 is created and transmitted to the zone ECU 262. The zone ECU 262 manages the data items of the in-vehicle DB 418 according to this storage policy, and stores data according to each data item. When a data provision request for various applications 436 is transmitted from the in-vehicle data acquisition unit 438 of the user terminal 362 to the in-vehicle data provision unit 410 of the zone ECU 262, the in-vehicle data provision unit 410 uses the data item name (column name) included in the data provision request to access the in-vehicle DB 418, reads out the corresponding data, and transmits it to the in-vehicle data acquisition unit 438. The in-vehicle DB 418 stores data according to the format required by the various applications 436. As a result, there is no need to intervene a server between the vehicle 360 and the user terminal 362 and have the server aggregate data processing. When a new application is executed in the user terminal 362, or when an existing application is updated and a change occurs in the data items used, the storage policy is updated according to the change. From then on, the zone ECU 262 stores data according to the updated storage policy. If data recovery is possible, past data can also be reproduced.

Therefore, according to this first embodiment, it is possible to increase the value of data generated in vehicles and avoid data concentration on a server. Between the zone ECU 262 of a specific vehicle and the user terminal 362, storage policies regarding data to be used by the user terminal 362 are automatically exchanged, and data required by the user terminal 362 can be obtained from the zone ECU 262 at any time. The format is already formatted according to the needs of each application of the user terminal 362, and the data can be used for driving assistance and the like without the user terminal 362 having to process a large amount of data.

In addition, a storage policy can be created and used for each application. Therefore, if a new vehicle is to handle a new service, the terminal or server that provides that service can create a storage policy according to the application for providing that service and distribute it to each vehicle, allowing the data used by the new service to be provided by each vehicle. If the content of the service is updated, a new storage policy can be created as well.

The zone ECU 262 and the user terminal 362 in the above embodiment are essentially computers. The hardware configuration of the computer that realizes the zone ECU 262 is shown below. The user terminal 362 can also be realized by a similar computer.

Referring to FIG. 13, the zone ECU 262 includes an MPU (Micro Processing Unit) 802, which is a processor, a high-speed bus 800 to which the MPU 802 is connected, an SRAM (Static Random Access Memory) 804 connected to the high-speed bus 800, a flash memory 806 connected to the high-speed bus 800, and a ROM (Read-Only Memory) 808 connected to the high-speed bus 800. The SRAM 804 holds data necessary for executing programs, etc. The flash memory 806 stores a program 826 for implementing functions realized by the zone ECU 262. The ROM 808 stores a boot-up program for the zone ECU 262, etc.

The zone ECU 262 further includes a low-speed bus 810 connected to the high-speed bus 800 via a bridge 812, and a serial I/F (Interface) 814, an ADC (Analog-to-Digital Converter) 816, a timer/counter 818, a clock generator 820, a power supply control unit 822, and a general-purpose I/F 824, all of which are connected to the low-speed bus 810.

The operation of a computer is well known, and what is meaningful in the embodiment is the function of the program it executes. Therefore, the following explanation will not cover the operation of the computer itself.

2. Second embodiment In the above-described first embodiment, as shown in FIG. 2, in order to collect data that is required by the data collection device 128 for a service and has high value, the data collection device 128 distributes a data accumulation policy corresponding to each application to the vehicle 110, etc. The vehicle 110, etc. accumulates data items according to this accumulation policy and transmits them directly to the data collection device 128. However, this disclosure is not limited to such an embodiment. Referring to FIG. 14, a data processing system 950 according to the second embodiment of this disclosure includes a plurality of intermediate servers 962, 964, and 966 that can communicate with each other via a network 960, and a data collection device 958 that collects data from these intermediate servers.

The storage policy may be distributed to intermediate servers 962, 964, 966, etc. (hereinafter referred to as "intermediate server 962, etc.") that are located between the data collection device 958 that uses the data and the vehicle, and the intermediate server 962, etc. may process or store the data collected from the vehicles within its management area in accordance with the storage policy. That is, each of the intermediate servers 962, etc. may have a configuration similar to that of the zone ECU 262 shown in the first embodiment. In this case, as an example, when the data collection device 958 transmits a data provision request specifying a data item to the intermediate server 962, the intermediate server 962 reads out the specified data item from the in-vehicle DB 418 (Figure 5) and transmits the data item to the data collection device 958 as data 972. When intermediate server 964 and intermediate server 966 receive a data provision request from a device such as data collection device 958, they read the specified data items from in-vehicle DB 418 (Figure 5) and transmit the data items to data collection device 958 as data 974 and 976.

This second embodiment also avoids data concentration on a server, and distributed processing of data is performed in the intermediate server 962 and the like. The intermediate server 962 and the like accumulates data in accordance with the accumulation policy received from the data collection device 958. Therefore, the data collection device 958 creates an accumulation policy regarding data used by applications executed by the data collection device 958 and distributes it to the intermediate server 962 and the like, thereby having the effect of receiving data in a format that can be efficiently used by those applications.

<First use example>
The above-described embodiment can be applied to, for example, driving behavior-linked telematics insurance (PAYD (Pay As You Drive) type). In this case, the insurance company creates an accumulation policy that specifies the date and time of the accident and the video of the on-board camera at the time of the accident as data items in order to collect case data when an insurance payment case occurs, and distributes the policy to contract-related vehicles. Then, for example, when an accident occurs, the on-board device of each vehicle accumulates data that specifies the time of the accident and the video data of the on-board camera immediately before the accident. The accumulation policy can also specify a deletion deadline for the accumulated data. By doing so, video data when no accident occurs can be deleted when the deletion deadline arrives. As a result, the storage device can be used efficiently. In addition, when an insurance payment case occurs, the insurance company can receive the data necessary for the assessment of the insurance payment and perform the assessment in a short time by requesting other vehicles to provide a desired data collection, such as the video of the on-board camera when a similar event occurs or an event close to the occurrence of an accident. Data necessary for the assessment, which is in a format suitable for use by the service, is stored together. This has the effect of allowing the service to use the data immediately upon receiving it, thereby increasing the value of the data.

<Second use example>
The above embodiment can also be used to collect model learning data for autonomous driving assistance. For example, as learning data for a model used for autonomous driving, an accumulation policy is created that specifies the data format and the priority of each data item for data used for learning, such as image data from an on-board front camera, date and time, collection intervals for point cloud data from a lidar, occurring events, driver's speech data, or the recognition results thereof, steering operation by the driver, brake or accelerator operation. By distributing the accumulation policy to multiple vehicles, information required for the model learning data can be automatically collected in a desired format. In each vehicle, only data that may be required later depending on the learning target of the model can be stored, and storage resources can be effectively utilized. In addition, when using the system, by specifying a priority and requesting each vehicle to send data, data of the same format that does not include unnecessary items and has all the necessary data items is provided from multiple vehicles. Therefore, it becomes easy to automate labeling processing of learning data, and a large amount of high-quality data required for model learning can be generated.

The functions of the zone ECU 262 described above are realized by programs executed by a computer. Therefore, the zone ECU 262 may be an ECU programmed by these programs, or may be realized by incorporating these programs into an existing ECU, GW (Gateway), etc.

Each process (each function) in the above-mentioned embodiments is realized by a processing circuit (circuitry) including one or more processors. The processing circuit may be composed of an integrated circuit that combines one or more memories, various analog circuits, and various digital circuits in addition to the one or more processors. The one or more memories store programs (instructions) that cause the one or more processors to execute each of the above processes. The one or more processors may execute each of the above processes according to the programs read from the one or more memories, or may execute each of the above processes according to a logic circuit designed in advance to execute each of the above processes. The processor may be any of various processors suitable for computer control, such as a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), a DSP (Digital Signal Processor), an FPGA (Field-Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), and a DPU (Data Processing Unit). Note that the physically separated processors may cooperate with each other to execute the above processes. For example, the processors mounted on each of a number of physically separated computers may cooperate with each other via a network such as a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet to execute the above processes. The program may be installed in the memory from an external server device or the like via the network, or may be distributed in a state stored in a recording medium such as a CD-ROM (Compact Disc Read-Only Memory), a DVD-ROM (Digital Versatile Disc Read-Only Memory), or a semiconductor memory, and installed in the memory from the recording medium.

The embodiments disclosed herein should be considered to be illustrative and not restrictive in all respects. The scope of the present disclosure is indicated not by the detailed description of the disclosure, but by each claim in the claims, and is intended to include all modifications within the scope and meaning equivalent to the wording of the claims.

50, 100, 350, 950 Data processing system 60, 62, 64, 110, 112, 114, 360 Vehicle 66, 126, 960 Network 68, 70, 72, 120, 122, 124, 972, 974, 976 Data 74 Server 128, 958 Data collection device 150 Data processing 160 Vehicle side processing 162 Server side processing 164 Sensor 170 Storage policy 172 Each application 174 Data provision request 190 Data storage processing 192, 418 In-vehicle DB
194 In-vehicle data provision processing 240 Central ECU
250 In-vehicle network 262, 264 Zone ECU
266, 268, 270, 272, 274, 276, 278, 280 ECU
282, 292 Lidar 284, 290 Vehicle-mounted camera 286, 288 Acceleration sensor 362 User terminal 370 Various sensors 400 Raw data storage unit 402 Temporary buffer 404 Storage policy receiving unit 406, 432 Storage policy memory unit 408 Data storage unit 410 Vehicle-mounted data providing unit 412 Vehicle-mounted data table creation unit 414 Vehicle-mounted data generating unit 416 Vehicle-mounted data management unit 420 Important key update unit 422, 462 Date and time column 430 Storage policy synchronization processing unit 434 Storage policy creation unit 436 Various applications 438 Vehicle-mounted data acquisition unit 450 Transmission destination list 460 Sensor data table 480 Data table 800 High-speed bus 802 MPU
804 SRAM
806 Flash memory 808 ROM
810 Low-speed bus 812 Bridge 814 Serial I/F
816 ADC
818 Timer/Counter 820 Clock Generator 822 Power Supply Control Unit 824 General-Purpose I/F
826 Program 962, 964, 966 Intermediate server

Claims (20)

A data receiving unit that receives data from a sensor mounted on the vehicle;
a policy receiving unit for receiving and storing a storage policy;
a data storage unit that stores the data received by the data receiving unit in accordance with the storage policy stored by the policy receiving unit. The data storage device according to claim 1 further includes a data providing unit that, in response to the establishment of a condition for providing data stored in the data storage unit to an external device, reads data determined by the condition from the data storage unit and transmits the data to a destination determined by the condition. The storage policy is assigned a unique identifier; and
The storage policy includes data item information that specifies the data items to be stored;
The data storage device of claim 2, wherein the data storage unit includes a database that stores the data in a new data table that stores each data item specified by the new storage policy in each column in response to the policy receiving unit receiving a new storage policy having an identifier that has not been stored by the policy receiving unit. The data storage device according to claim 3, wherein the policy receiving unit replaces the first storage policy with the second storage policy in response to receiving a new second storage policy having the same identifier as the identifier of the first storage policy stored by the policy receiving unit. The data storage device according to claim 3, wherein the policy receiving unit, in response to receiving an instruction to modify a storage policy that specifies an identifier of a first storage policy stored by the policy receiving unit, modifies the first storage policy according to the modification instruction. The data storage device according to claim 4 or 5, wherein the data storage unit, in response to a change in the first storage policy, changes the data table created according to the first storage policy according to the changed storage policy. The data storage device according to claim 6, further comprising a priority assignment unit that assigns a priority to each of the columns of the multiple data tables according to the number of data tables that have a data item corresponding to the column in common. The data storage device according to claim 7, further comprising a data management unit that deletes, from among the columns of the plurality of data tables, a column that has a lower priority assigned by the priority assignment unit than other columns in response to the data capacity available in the data storage unit falling below a threshold value. The data storage device according to claim 3, wherein the storage policy includes data processing information that specifies a method of data processing to be performed between the data received by the data receiving unit, and the data item information further includes a data item that is a result of the data processing. The data storage device according to claim 2, wherein the data providing unit, in response to receiving a data provision request from an external source, reads data determined by the data provision request from the data storage unit and provides the data to a destination determined in association with the data provision request. The data storage device according to claim 2, wherein the data providing unit reads data determined by the first storage policy from the data storage unit when a transmission condition specified by the first storage policy stored by the policy receiving unit is satisfied, and transmits the data to a destination determined in association with the first storage policy. The data storage device according to claim 2, wherein the data providing unit reads data determined by the first storage policy from the data storage unit when the communication cost with the destination specified by the first storage policy stored by the storage policy receiving unit falls below a threshold value, and aggregates and transmits the data to the destination determined in association with the first storage policy. An in-vehicle device including a data storage device according to any one of claims 1 to 12. An intermediate server including the data storage device according to any one of claims 1 to 12,
The data receiving unit receives the data from one or more vehicles,
The policy receiving unit is an intermediate server that performs a process of receiving and storing the storage policy from a server different from the intermediate server. a storage policy creation unit for creating a storage policy;
a storage policy storage unit for storing the storage policy maintained by the storage policy creation unit by assigning a unique identifier to the storage policy;
A data collection device including an accumulation policy synchronization processing unit for synchronizing an accumulation policy stored in the accumulation policy memory unit with an accumulation policy held by another device, the accumulation policy having the same identifier as the accumulation policy. The data collection device includes:
Each of the devices is capable of executing one or more data utilization programs that utilize data obtained from the vehicle to provide a predetermined service;
The data collection device of claim 15, wherein the storage policy creation unit analyzes each of the one or more data usage programs and generates or updates the storage policy for each data usage program by identifying the data to be processed for that data usage program. Computer,
A data receiving unit that receives data from a sensor mounted on the vehicle;
a policy receiving unit for receiving and storing a storage policy;
a computer program causing the data receiving unit to function as a data storage unit that stores the data received by the data receiving unit in accordance with the storage policy stored by the policy receiving unit; Computer,
a storage policy creation unit for maintaining a storage policy;
a storage policy storage unit for storing the storage policy created by the storage policy creation unit by assigning a unique identifier to the storage policy;
A computer program that functions as a storage policy synchronization processing unit for synchronizing a storage policy stored in the storage policy memory unit with a storage policy held by another device and having the same identifier as the storage policy. A data receiving step in which a computer receives data from a sensor mounted on the vehicle;
a policy receiving step in which the computer receives and stores the storage policy;
a data storage step in which a computer stores the data received in the data receiving step in accordance with the storage policy stored in the policy receiving step. A creating step in which a computer creates a storage policy;
a storage policy storage step of storing the storage policy created in the creation step by the computer by assigning a unique identifier to the storage policy;
A data processing method including a synchronization processing step in which a computer synchronizes a storage policy stored in the storage policy memory unit with a storage policy held by another device, the storage policy having the same identifier as the storage policy.

Images