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

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-board device, intermediate server, data collection device, computer program, and data processing method

[0001] 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 by reference all of the contents of said Japanese application.

[0002] Currently, data generated in connected cars is accumulated on servers and other devices for use. It is expected that the number of connected cars will increase rapidly in the future, and the number of sensors installed in each connected car will likely also increase. As a result, the amount of data handled by servers and other devices may increase exponentially. Meanwhile, most of the data transmitted to servers in this way is fragmented. Therefore, when providing a service to connected cars or users, the data accumulated on servers is difficult to use, making it difficult to increase the added value of the service. In other words, the value of data accumulated on servers and other devices is currently considered to be low.

[0003] One proposal to solve this problem is disclosed in Patent Document 1. The technology disclosed in Patent Document 1 correlates two types of data collected in a vehicle. For example, it correlates images from an on-board camera with the vehicle's mileage.

[0004] Japanese Patent Application Laid-Open No. 2019-185430

[0005] 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 in accordance with the storage policy stored by the policy receiving unit.

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

[0007] FIG. 1 is a schematic diagram for explaining problems with the prior art. FIG. 2 is a schematic diagram showing the configuration of a data processing system according to a 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. 2. FIG. 4 is a diagram showing the configuration of network devices in a vehicle used in the 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 constituting part of the data processing system. FIG. 6 is a diagram showing an example configuration of a data table of the in-vehicle data generation unit shown in FIG. 5. FIG. 7 is a diagram showing another example configuration of a data table of the in-vehicle data generation unit shown in FIG. 5. FIG. 8 is a flowchart showing the control structure of a program executed in the user terminal shown in FIG. 5. FIG. 9 is a flowchart showing the control structure of a part of the flowchart shown in FIG. 8. FIG. 10 is a flowchart showing the control structure of a program executed by the vehicle shown in FIG. 5 in response to receiving a storage policy. FIG. 11 is a flowchart showing the control structure of a program executed by the vehicle shown in FIG. 5 in response to receiving a request to provide in-vehicle data. FIG. 12 is a flowchart showing the control structure of an in-vehicle DB (Database) management program executed by the in-vehicle data management unit shown in FIG. 5. Fig. 13 is a block diagram showing the hardware configuration of a computer for realizing the zone ECU (Electronic Control Unit) and the user terminal shown in Fig. 5. Fig. 14 is a schematic diagram showing the general configuration of a data processing system according to a second embodiment of the present disclosure.

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

[0009] However, the effect of the technology disclosed in Patent Document 1 is limited to making it easy to obtain other data from one data, and there is a problem that it cannot be used to obtain new information from accumulated data. Furthermore, it does not address the problem of data concentration on servers, etc. The concentration of data on servers may cause problems in data processing on the servers. Therefore, the technology described in Patent Document 1 has the problem of not being able to increase the value of data generated in vehicles, nor reducing the load on servers.

[0010] 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 a vehicle and reduce data concentration on a server.

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

[0012] [Description of the embodiments of the present disclosure] In the following description and drawings, the same components 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.

[0013] (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. This configuration allows different data storage devices to store data from the sensors in accordance with a common storage policy. This increases the value of data generated in the vehicle and reduces data concentration on a server.

[0014] (2) In the above (1), 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 device, 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, such as 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.

[0015] (3) In the above (2), the storage policy may be assigned a unique identifier, and the storage policy may include data item information specifying data items to be stored. The data storage unit may include a database that, in response to the policy receiving unit receiving a new storage policy having an identifier not stored by the policy receiving unit, stores the data in a new data table in which each data item specified by the new storage policy is stored 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 any data transmission system, data storage according to the new storage policy begins. Therefore, the data storage device can store appropriate data corresponding to the start of a new service, increasing the value of data generated in vehicles and reducing data concentration on servers.

[0016] (4) In the above (3), 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. This configuration allows the old storage policy to be replaced with the new storage policy by specifying the identifier. In either data transmission system, data storage according to the new storage policy begins. This allows appropriate data to be stored in response to continuous changes in services, increases the value of data generated in vehicles, and reduces data concentration on servers.

[0017] (5) In the above (3), 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 allows appropriate data to be stored in response to continuous changes in services, increasing the value of data generated in vehicles and reducing data concentration on servers.

[0018] (6) In the above (4) or (5), in response to a change in the first storage policy, the data storage unit may change the data table created in accordance with the first storage policy in accordance with the changed storage policy. This configuration allows data created in accordance with the old storage policy to be remade into data in accordance with the new storage policy. This allows appropriate data to be stored in response to continuous changes in services, increases the value of data generated in vehicles, and reduces data concentration on servers.

[0019] (7) In the above (6), the data storage device may further include a priority assigning unit that assigns a priority to each of the columns of the multiple data tables according to the number of data tables that share a data item corresponding to the column. This configuration makes it possible to distinguish between data items used in multiple data tables and other data items. The importance of each data item becomes clear, making it easy to distinguish how to handle the data items.

[0020] (8) In the above (7), the data storage device may further include a data management unit that, in response to the data capacity available 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 assigning unit than 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 lower priority, thereby increasing the available storage capacity.

[0021] (9) In the above (3), 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.

[0022] (10) In the above (1), in response to receiving a data provision request from an external device, 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 necessary for executing a service and in a format suitable for data processing by transmitting a data provision request to the data providing system.

[0023] (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 predetermined transmission condition is met, without having to request data provision itself.

[0024] (12) In the above (1), when the communication cost with the destination specified by the first storage policy stored by the storage policy receiving unit falls below a threshold, the data providing unit may read the data determined by the first storage policy from the data storage unit, aggregate the data, and transmit the aggregated data to the 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 at a stable communication cost without having to request the provision of data itself.

[0025] (13) A second aspect of the present disclosure provides an in-vehicle device that includes any one of the data storage devices described above in (1) to (12). This configuration allows different in-vehicle devices to 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.

[0026] (14) An intermediate server according to a third aspect of this disclosure is an intermediate server including any one of the data storage devices described in (1) to (12), wherein 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 shared by multiple intermediate servers. As a result, even if different intermediate servers collect data from different in-vehicle devices, the data can be stored in the data storage device in accordance with the common storage policy. This increases the value of data generated in vehicles and reduces data concentration on the server.

[0027] (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 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 storage policy specifies the configuration of data required for a service provided by the data collection device. The storage policy can be updated based on the identifier, making it easy to accommodate changes in the method of storing required data as the service changes.

[0028] (16) In the above (15), the data collection device may be capable of executing one or more data utilization programs that each provide a predetermined service using data obtained from a vehicle, and the storage policy creation unit may analyze each of the one or more data utilization programs and identify the data to be processed for each data utilization program, thereby generating or updating the storage policy for the data utilization 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 utilization programs, and immediately use the data to provide a service. In other words, the value of the data can be increased.

[0029] (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 on-board devices can store data from the sensors in accordance with a common storage policy by executing this program. This increases the value of data generated in the vehicle and reduces data concentration on a server.

[0030] (18) A computer program according to a sixth aspect of the present disclosure causes a computer to function as 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, 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 that has the same identifier as the storage policy. With this configuration, the storage policy specifies the configuration of data required to provide a service. The storage policy can be updated based on the identifier, making it easy to respond to changes in the method of storing required data as the service changes.

[0031] (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 on-board 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 a server.

[0032] (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 the policy; and a synchronization step in which the computer synchronizes the storage policy stored in the storage policy storage unit with a storage policy held by another device that has the same identifier as the storage policy. With this configuration, the storage policy identifies the configuration of data required to provide a service. The storage policy can be updated based on the identifier, making it easy to respond to changes in the method of storing required data as the service changes.

[0033] [Details of the embodiments of the present disclosure] Specific examples of a data storage device, an in-vehicle device, an intermediate server, a data collection device, a computer program, and a data processing method according to 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.

[0034] 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 this data, and distributes the information to each of the vehicles 60, 62, 64, etc. or each user.

[0035] In this configuration, data is concentrated on the server 74, which may cause a shortage of resources for the server 74 and hinder the provision of services. In addition, the data transmitted from each vehicle to the server 74 is fragmented, which is problematic in that it is difficult for the server 74 to use the data to provide certain services.

[0036] 2 shows a schematic configuration of a data processing system 100 according to a first embodiment of the present disclosure. Referring to FIG. 2, in this embodiment, each of vehicles 110, 112, 114, etc. processes data generated by the vehicle in advance and stores the processed data. When a data collection device 128, which may be a server, a user terminal, or the like, 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 the data to data collection device 128 via network 126.

[0037] In this embodiment, the following mechanism is provided to prepare the data required by the data collection device 128 by data processing in the vehicle 110 or the like.

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

[0039] Server-side processing 162 creates, for each application (hereinafter simply referred to as "app") 172, a storage policy 170 that specifies how data used in that app will be stored. Storage policy 170 defines what data will be stored, how often, what data processing will 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 formats, compression methods for data that requires compression, storage methods, and information required for security. For example, when a calculation is performed between data items, a data item for storing the calculation results is added and specified.

[0040] The storage policy can be considered similar to the design concept of a database data table for accumulating data required for processing. As described above, the storage policy can be considered a parameter for arranging and storing in-vehicle data according to its intended use. The storage policy is not particularly limited, but is typically information for specifying the column structure 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 at the time of data acquisition, driving scene, occurring event, data storage period, sensor data priority, and target sensor.

[0041] The server-side processing 162 distributes this storage policy 170 to vehicles that are the subject of data collection. When each application 172 is executed, the server-side processing 162 sends a data provision request to each vehicle so that each application 172 transmits the data it requires. A data provision request 174 is executed, which receives data from each vehicle and provides it to each application 172. All of the data provided to the data provision request 174 at this time has been stored based on the same storage policy. As a result, each application 172 can immediately use this data for processing. Even if data is provided from different vehicles, data based on the same storage policy has the same format, enabling efficient and accurate processing.

[0042] The storage policy may include information specifying the terminal to which data is to be provided in accordance with the storage policy. If the information specifying the terminal to which data is to be provided is different from the terminal that created the storage policy, the data stored in accordance with the storage policy is sent to a terminal other than the device that created the storage policy.

[0043] 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 sensors 164 in accordance with the storage policy. In this embodiment, the data is stored in an on-board DB 192. The vehicle-side processing 160 according to 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 the data to the data collection device 128.

[0044] That is, in this embodiment, data processing is not centralized on a server but is performed in each vehicle, so-called distributed processing. Furthermore, by distributing information on how data is to be stored in distributed processing from the data collection device 128 to each vehicle in advance, the data collection device 128 can receive data that has already been processed. As a result, the data collection device 128 can immediately use the received data without performing preprocessing on the data. Furthermore, by distributing the same storage policy to each vehicle for data required for the same processing, each vehicle transmits data with the same configuration to the data collection device 128. Data can be used effectively without being unified or fragmented, making it difficult to use. In other words, by storing data in each vehicle according to the storage policy, the value of the data can be increased. Furthermore, when there are changes or additions to the services executed by the data collection device 128, the storage policy can be changed or added accordingly, making it possible to quickly collect information on the changed and new services. As a result, the value of data can be continuously improved, enabling the development of various services.

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

[0046] 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 for separate zones. The zone ECUs 262 and 264 each control various components of the networks they manage, thereby reducing the load on the central ECU 240. 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 ECUs are also an example of in-vehicle devices.

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

[0048] Similarly, sensors such as an acceleration sensor 286, an in-vehicle 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.

[0049] 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 connected to the network managed by the zone ECU 264.

[0050] 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 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 by communicating with a zone ECU 262 that constitutes a data storage device. The 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 connected to multiple user terminals like the user terminal 362 and may function as a server that provides services to users via these user terminals.

[0051] The user terminal 362 includes the various applications 436 described above, a storage policy creation unit 434 that analyzes the processing content of the various applications 436 (the content of data processing performed by the programs) and, based on the analysis results, identifies the data to be processed, 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, in response to the storage policy creation unit 434 creating a new storage policy or modifying an existing storage policy, synchronizes the storage policy registered in the storage policy memory unit 432 with the storage policy held by the in-vehicle network 250, 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. The zone ECU 262 stores a destination list 450 that identifies 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.

[0052] In the following description, the user terminal 362 is 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 in multiple vehicles, or from multiple on-board devices in a single vehicle. To enable such data acquisition, the on-board data acquisition unit 438 has the destination list 450 described above. The destination list 450 holds information (such as, but not limited to, an IP address) identifying the ECU from which data is to be acquired. The user terminal 362 performs the following processing on each ECU listed in the destination list 450, thereby enabling the acquisition of a large number of data items with the same configuration from multiple on-board devices.

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

[0054] The zone ECU 262 includes a temporary buffer 402 that temporarily stores data from 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.

[0055] 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 immediate start of storage of new data in accordance with changes in the content of the service, even when the content of the data to be stored 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 storage policy identifier may be transmitted to the zone ECU 262. In this case, a new storage policy is generated by replacing data items designated as differences in the storage policies stored in the storage policy storage unit 406 with the new content.

[0056] When a storage policy is changed, it is desirable to change existing data to a format that conforms to 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 be stored, the existing data can be used to change the data table to conform to the new storage policy simply by redefining the format of the data item or adding a new data item.

[0057] 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 the data items specified in the data provision request from the data storage unit 408, and if data processing is specified by the storage policy, performing such data processing and providing the data to the in-vehicle data acquisition unit 438.

[0058] The data storage unit 408 includes an on-board 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 predetermined grammar, and an on-board data table creation unit 412 that, when the storage policy receiving unit 404 receives a new storage policy, creates a new data table in the on-board DB 418 that is specified by the storage policy, and, in response to the storage policy receiving unit 404 receiving a modified storage policy already stored in the storage policy memory unit 406, changes the existing data table to a data table that conforms to the new storage policy.

[0059] When the in-vehicle data table creation unit 412 creates an in-vehicle data table, it determines in which storage device the data table should be placed, taking into consideration factors such as the data acquisition frequency, the size of the acquired data, the reference frequency, the data storage period, and the capacity of the available storage device. If necessary, separate databases may be created in different storage devices, and different data tables may be created in databases located 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 that can communicate with the in-vehicle device via a network. Note that this data needs to be stored 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)).

[0060] 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 in accordance with 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 referred to as "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, when the available storage capacity falls below a threshold, deleting part of the data stored in the in-vehicle DB 418, thereby increasing the available storage capacity of the in-vehicle DB 418. When the in-vehicle data management unit 416 deletes data, it basically saves the important keys specified by the important key update unit 420 and deletes other data. When there is no data that can be deleted other than the important key, the in-vehicle data management unit 416 deletes data items with low priority among the important keys. It is also possible to consider priority when determining which data to delete. It is considered that deleting low-priority data will have less impact than deleting high-priority data. Therefore, when available storage capacity is running low, low-priority data may be deleted.

[0061] 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 representing one record of sensor data collected in time series and stored in the in-vehicle DB 418. However, the first row in FIG. 6 indicates the names of data items included in each record and is not an actual record. Each column in the first row is referred to as 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.

[0062] 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. By saving the sensor data in a file and the file name in the on-board DB 418 in this way, even if it is necessary to save data common to multiple data tables, the amount of accumulated data does not increase unnecessarily. Furthermore, sensor data that is not referenced in any data table is considered to be virtually unused. Therefore, the data may be discarded as needed. As a result, the capacity of the data storage medium can be used effectively.

[0063] The priority is specified by the data requester. For example, if a priority of "1" is specified, only data from records with a priority value of "1" is retrieved and transmitted. If a priority of "2" is specified, only data from records with a priority value of "2" or less is retrieved and transmitted. The same applies below. However, this disclosure is not limited to this. For example, regardless of the specified priority value, only data from records with the same priority value may be retrieved and transmitted. This priority is primarily determined 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) associated with each application and the service provision format. The service provision format differs depending on, for example, whether it is necessary to immediately provide the user with processing results based on the data when requested by the user.

[0064] 7 shows an example of another data table 480. Referring to FIG. 7, this data table 480 is a data table for collectively 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.

[0065] Both the data table 460 shown in FIG. 6 and the 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 have no other column names in common. In this embodiment, a data item that is commonly included in 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.

[0066] 8 is a flowchart showing the control structure of a program for implementing the functions of user terminal 362 shown in FIG. 5. This program is started when execution of a certain application is initiated. This program first searches for a storage policy corresponding to the running application in storage policy storage unit 432 of FIG. 5 (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 a matching storage policy is found (step 522).

[0067] If the determination in step 522 is affirmative, 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 of whether the application has been updated in this step can be made by comparing the version of the application at the time of the previous execution with the version at the time of the current execution. Of course, if the application is an executable file, for example, this determination can also be made by comparing the hash of the file.

[0068] If the determination in step 524 is negative, no change to the storage policy is necessary. Therefore, control proceeds to step 526, where a request for in-vehicle data is made to the zone ECU 262 shown in FIG. 5 . This data request specifies specific data items, for example, according to data described in the application. The simplest implementation method is to directly copy the data items specified in an SQL statement issued by the application to the data request when the application issues the SQL statement to read data from the database. To achieve this, the database name, data table name, and data item names required for application execution are determined during application design, and the application is created accordingly. By copying these database names, data table names, and data items into the data storage policy, the in-vehicle data providing unit 410 shown in FIG. 5 can easily create SQL statements to be issued to the in-vehicle DB 418 in the zone ECU 262 based on the SQL statement issued by the application and information from the in-vehicle 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 .

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

[0070] On the other hand, if the determination in step 522 is negative or if 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 simultaneously create storage policies for multiple applications. 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. Upon receiving this storage policy, the storage policy receiving unit 404 determines whether the storage policy needs to be saved or updated 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 indicating this to the storage policy synchronization processing unit 430. When the user terminal 362 confirms this notification in step 536, the control proceeds to step 526. The subsequent processing is the same as when no storage policy needs to be created.

[0071] In this example, step 526 requests the in-vehicle device to immediately provide data. However, this disclosure is not limited to such an embodiment. For example, the data provision request may specify that data be provided periodically. When the in-vehicle device receives such a data provision request, it may not only transmit the data at the same date and time, but may also provide the data in bulk under optimal conditions, such as communication standby time and communication cost, as long as the frequency or date and time do not significantly differ from the specified frequency or date and time. In this case, rather than requesting data transmission from the service side, instructions such as transmission frequency may be included in the storage policy. Note that determining whether the communication cost is optimal is generally difficult. Therefore, a communication cost threshold may be set in advance, and data transmission may be performed when the actual communication cost falls below or is equal to or less than the threshold. In this case, the communication cost can typically be considered the time required to transmit a unit amount of data. The time required for communication can be calculated by periodically transmitting a ping command to the other device, based on the delay time until a response is received, and the amount of data to be transmitted.

[0072] Referring to Figure 9, step 532 in Figure 8 includes step 560, which branches the control flow 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 application if 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.

[0073] 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 data read instructions 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.

[0074] FIG. 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 activated in response to the reception of the storage policy. Referring to FIG. 10 , this program includes step 600, which branches the control flow depending on whether a storage policy (application) with the same identifier as the received storage policy exists, and step 602, which updates a data table created in accordance with the existing storage policy in accordance with the newly received storage policy if the determination in step 600 is affirmative. Specifically, this process extracts, for each related data table, differences between each column in that table and each column defined for that 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 the command statement to the in-vehicle DB 418. While such a command statement varies depending on the database, an alter table statement, for example, is used.

[0075] Furthermore, the storage policy receiving unit 404 updates the important keys of the on-board DB 418 in response to changes in the configuration of the data tables in the on-board DB 418 due to these updates (step 604). Furthermore, the storage policy receiving unit 404 updates the data in each data table, if necessary, in response to changes in the configuration of the data tables (step 606). In the case of data deletion, the change is reflected in the on-board DB 418 as soon as the column name is deleted from the data table. On the other hand, when a column is newly created, if the data is stored, the 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 data items in existing columns are to be stored in that column, the corresponding data processing is performed, and the results are substituted for the newly created column.

[0076] 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 each new or updated storage policy as the identifier of the application that uses that storage policy.

[0077] 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, this data is substituted into the data table to generate on-board data (step 612). In the following step 614, the storage policy synchronization processing unit 430 in FIG. 5 is notified that the data table has been created, and execution of this program is terminated.

[0078] 11 shows a control structure of a program executed by in-vehicle data providing unit 410 when in-vehicle data acquisition unit 438 shown in FIG. 5 transmits a data provision request to in-vehicle data providing unit 410. Referring to FIG. 11, this program is started in response to 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 specified data items from in-vehicle DB 418, based on the database name, data table name, and data items included in the received data provision request.

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

[0080] 12 shows the control structure of a program for on-board data management executed by the on-board data management unit 416. The 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 the amount of data stored increases. Furthermore, the storage capacity of the storage device available to the zone ECU 262 is limited. Therefore, as the amount of data increases, the storage space available to the on-board DB 418 decreases, and if nothing is done, the on-board DB 418 will be unable to store new data. 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 maintain the data capacity available to the on-board DB 418 at an appropriate level or higher.

[0081] 12 , this program includes step 680, which branches the control flow according to whether the storage utilization rate, which indicates the ratio of the area used by the data accumulation unit 408 to the storage capacity available to the on-board DB 418, is equal to or greater than a predetermined value, for example, 80%. If the determination in step 680 is negative, there is no particular problem with the storage capacity for the on-board DB 418. Therefore, execution of this program ends. If the determination in step 680 is positive, then in step 682, the control flow further branches according to whether or not keys (data items) other than the important keys exist. If the determination in step 682 is positive, i.e., if keys other than the important keys exist, 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, where the important keys are deleted. At this time, the important keys are deleted in order, starting with the key that shares the fewest number of data tables. After this, control returns to step 680.

[0082] As described above, according to this embodiment, a storage policy corresponding to an application executed on the user terminal 362 is created and transmitted to the zone ECU 262. The zone ECU 262 manages data items in the in-vehicle DB 418 according to the 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 accesses the in-vehicle DB 418 using the data item name (column name) included in the data provision request, reads the corresponding data, and transmits it to the in-vehicle data acquisition unit 438. The in-vehicle DB 418 stores data in the format required by the various applications 436. As a result, there is no need to interpose a server or the like between the vehicle 360 ​​and the user terminal 362 and have the server centralize data processing. When a new application is executed on the user terminal 362 or an existing application is updated, causing changes to the data items used, the storage policy is updated in accordance with the changes. Thereafter, data is stored in accordance with the updated storage policy in the zone ECU 262. Furthermore, if data recovery is possible, past data can also be reproduced.

[0083] Therefore, according to the first embodiment, the value of data generated in a vehicle can be increased and data concentration on a server can be avoided. A storage policy for data used by the user terminal 362 is automatically exchanged between the zone ECU 262 and the user terminal 362 of a specific vehicle, and data required by the user terminal 362 can be obtained from the zone ECU 262 at any time. The format of the data is already tailored to the needs of each application on the user terminal 362, and the data can be used for driving assistance and the like without requiring the user terminal 362 to perform a large amount of data processing.

[0084] 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, and then the data used by the new service can be received from each vehicle. If the content of the service is updated, a new storage policy can be created.

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

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

[0087] Zone ECU 262 further includes a low-speed bus 810 connected to 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 low-speed bus 810.

[0088] The operation of a computer is well known, and what is meaningful in the embodiments is the function of the programs it executes. Therefore, the following description will not describe the operation of the computer itself.

[0089] 2. Second Embodiment In the first embodiment described above, as shown in FIG. 2 , in order for the data collection device 128 to collect highly valuable data that is required for a service, a data accumulation policy corresponding to each application is distributed from the data collection device 128 to the vehicle 110 or the like. The vehicle 110 or the like 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.

[0090] The storage policy may be distributed to intermediate servers 962, 964, 966, etc. (hereinafter referred to as "intermediate server 962, etc.") located between the data collection device 958 that uses the data and the vehicles, and the intermediate server 962, etc. may process and 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 the zone ECU 262 shown in the first embodiment. In this case, as an example, when the data collection device 958 sends a data provision request specifying data items to the intermediate server 962, the intermediate server 962 reads the specified data items from the on-board DB 418 ( FIG. 5 ) and transmits the data items to the data collection device 958 as data 972. When the intermediate server 964 and the intermediate server 966 receive a data provision request from a device such as the data collection device 958, they also read the specified data items from the on-board DB 418 ( FIG. 5 ) and transmit the data items to the data collection device 958 as data 974 and 976.

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

[0092] <First Usage 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, in order to collect case data when an insurance payment case occurs, the insurance company creates a storage policy specifying the date and time of the accident and the video footage taken by the onboard camera at the time of the accident as data items, and distributes the policy to contracted vehicles. Then, for example, when an accident occurs, the onboard device of each vehicle stores data specifying the time of the accident and the video data taken by the onboard camera immediately before the accident. The storage policy can also specify a deletion deadline for the stored 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. Furthermore, when an insurance payment case occurs, the insurance company can request other vehicles to provide a desired data collection, such as video footage taken by the onboard camera when a similar event occurred or an event close to the accident occurred, and can thereby receive the data necessary for assessing the insurance payment, allowing the assessment to be performed in a short time. The data required for assessment is stored in a format suitable for use by the service, so when the data is provided, the service can use it immediately, which increases the value of the data.

[0093] <Second Use Example> The above embodiment can also be used to collect model learning data for autonomous driving assistance. For example, a storage policy is created that specifies the data format and priority of each data item for the model learning data used for autonomous driving, including video data from an onboard forward camera, date and time, collection intervals for point cloud data from a lidar, occurring events, driver speech data or their recognition results, and driver steering, braking, or accelerator operations. By distributing this storage policy to multiple vehicles, information necessary for the model learning data can be automatically collected in a desired format. Each vehicle can store only data that may be needed later depending on the model learning target, thereby efficiently utilizing storage resources. Furthermore, during use, by specifying priorities and requesting each vehicle to send data, data in the same format that includes all necessary data items but does not include unnecessary items can be provided from multiple vehicles. This facilitates automating processes such as labeling the learning data, thereby generating large amounts of high-quality data necessary for model learning.

[0094] The functions of the zone ECU 262 are implemented by programs executed by a computer. Therefore, the zone ECU 262 may be an ECU programmed with these programs, or may be implemented by incorporating these programs into an existing ECU, GW (Gateway), or the like.

[0095] Each process (each function) in the above-described embodiments is realized by a processing circuit (circuitry) including one or more processors. The processing circuit may be configured by 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 processes. The one or more processors may execute each of the processes according to the program read from the one or more memories, or according to a logic circuit designed in advance to execute each of the 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 a plurality of physically separated computers may cooperate with each other via a network such as a local area network (LAN), a wide area network (WAN), the Internet, etc. The program may be installed into 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 compact disc read-only memory (CD-ROM), a digital versatile disc read-only memory (DVD-ROM), or a semiconductor memory, and installed into the memory from the recording medium.

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

[0097] 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 In-vehicle 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 storage unit 408 Data storage unit 410 In-vehicle data providing unit 412 In-vehicle data table creation unit 414 In-vehicle data generation unit 416 In-vehicle 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 In-vehicle data acquisition unit 450 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

1. a data receiving unit that receives data from a sensor mounted on the vehicle; a policy receiving unit that receives and stores 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.

2. The data storage device according to claim 1, further comprising a data providing unit that, in response to a condition for providing data stored in the data storage unit to an external device being met, reads data determined by the condition from the data storage unit and transmits the data to a destination determined by the condition.

3. The storage policy is assigned a unique identifier; the storage policy includes data item information that specifies 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.

4. The data storage device of 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.

5. The data storage device of claim 3, wherein the policy receiving unit, in response to receiving an instruction to modify a storage policy specifying an identifier of a first storage policy stored by the policy receiving unit, modifies the first storage policy in accordance with the modification instruction.

6. The data storage device according to claim 4 or claim 5, wherein the data storage unit, in response to a change in the first storage policy, changes the data table created in accordance with the first storage policy in accordance with the changed storage policy.

7. 7. 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 plurality of data tables according to the number of data tables that have a data item corresponding to the column in common.

8. 8. The data storage device according to claim 7, further comprising a data management unit that, in response to the data capacity available in the data storage unit falling below a threshold, deletes, from among the columns of the plurality of data tables, a column that has a lower priority assigned by the priority assigning unit than other columns.

9. The data storage device of claim 3, wherein the storage policy includes data processing information that specifies the method of data processing to be performed between the data received by the data receiving unit, and the data item information further includes data items that are the result of the data processing.

10. 3. The data storage device according to claim 2, wherein, in response to receiving a data provision request from an external device, the data providing unit 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.

11. The data storage device of 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 met, and transmits the data to a destination determined in relation to the first storage policy.

12. The data storage device of claim 2, wherein the data providing unit reads data determined by the first storage policy from the data storage unit when the communication cost between the data providing unit and the destination specified by the first storage policy stored by the 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.

13. An in-vehicle device comprising the data storage device according to any one of claims 1 to 5 and claims 9 to 12.

14. An intermediate server including the data storage device according to any one of claims 1 to 5 and claims 9 to 12, the data receiving unit receives the data from one or more vehicles; The policy receiving unit is an intermediate server that performs processing to receive and store the storage policy from a server different from the intermediate server.

15. a storage policy creation unit for creating 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 data collection device including 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 that has the same identifier as the storage policy.

16. The data collection device each 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 described in 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.

17. Computer, a data receiving unit that receives data from a sensor mounted on the vehicle; a policy receiving unit that receives and stores a storage policy; a computer program that causes the data receiving unit to function as a data storage unit that stores the data received by the policy receiving unit in accordance with the storage policy stored by the policy receiving unit;

18. Computer, a storage policy creation unit for creating 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 storage unit with a storage policy held by another device that has the same identifier as the storage policy.

19. 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 saved in the policy receiving step.

20. a creating 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 the policy; A data processing method including a synchronization processing step in which a computer synchronizes the storage policy stored in the storage policy storage step with a storage policy held by another device that has the same identifier as the storage policy.

Images