Vehicle Data Management System

Abstract

In a vehicle data management system in which data acquired in a vehicle is managed in an external server, the calculation cost of the external server is reduced. [Solution] When a vehicle detects a first event and a second event from multiple types of time-series data, and the type of time-series data in which the first event was detected overlaps with the type of time-series data in which the second event was detected, and a first predetermined period including the first event overlaps at least partially with a second predetermined period including the second event, the vehicle integrates the first data related to the first event and the second data related to the second event to generate integrated data, and transmits the integrated data and index data related to the integrated data to a server. Immediately after receiving the integrated data and the index data, or upon request from a user, the server extracts the first data and the second data from the integrated data based on the index data, and provides the first data and the second data to the user.

Description

[Technical Field]

[0001] The present invention relates to the technical field of vehicle data management systems. [Background technology]

[0002] As an example of this type of system, a system has been proposed in which, when a first upload target event and a second upload target event occur while a vehicle is traveling and there is an overlapping period between the period relating to the first upload target event and the period relating to the second upload target event, the system compares the priority of the first upload target event with the priority of the second upload target event and excludes data for the overlapping period from the data set relating to the upload target event with the lower priority (see Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2022-157157 Summary of the Invention [Problem to be solved by the invention]

[0004] The technology described in Patent Document 1 may increase the calculation costs of the external server.

[0005] The present invention has been made in view of the above circumstances, and an object of the present invention is to provide a vehicle data management system that can reduce calculation costs. [Means for solving the problem]

[0006] A vehicle data management system according to one aspect of the present invention is a vehicle data management system that manages data acquired in a vehicle in a server external to the vehicle, wherein the vehicle detects data having a predetermined pattern as an event from a plurality of types of time series data corresponding to a plurality of sensors, and when a first event and a second event are detected from the plurality of types of time series data, first data is acquired from the time series data in which the first event was detected, which is data for a first predetermined period including the first event, and second data is acquired from the time series data in which the second event was detected, which is data for a second predetermined period including the second event, and and a processing means configured to integrate the first data and the second data to generate integrated data when the type of the first data overlaps with the type of time-series data in which the second event was detected and when at least a part of the first predetermined period and the second predetermined period overlap, and to transmit the integrated data and index data related to the integrated data to the server, wherein the server comprises an extraction means that extracts the first data and the second data from the integrated data based on the index data immediately after receiving the integrated data and the index data or when requested by a user, and a provision means that provides the first data and the second data to the user. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 is a block diagram illustrating an example of a management system according to an embodiment. [Figure 2] FIG. 2 is a conceptual diagram illustrating the concept of data processing in a vehicle according to an embodiment. [Figure 3] 4 is a flowchart illustrating an example of an operation of a vehicle according to the embodiment. [Figure 4] FIG. 2 is a conceptual diagram illustrating the concept of data processing in a server according to an embodiment. [Figure 5] FIG. 10 is a block diagram illustrating another example of a management system according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0008] An embodiment of a vehicle data management system will be described with reference to Figures 1 to 4. In the following, the embodiment of the vehicle data management system will be described using a management system 1.

[0009] In FIG. 1, the management system 1 includes a vehicle 10, a server 20, and a terminal 30. The terminal 30 is a terminal owned by a user. The user may be an end user. The vehicle 10 may be a vehicle owned by a user who owns the terminal 30. However, the vehicle 10 may also be a vehicle owned by a person other than the user who owns the terminal 30.

[0010] The vehicle 10, the server 20, and the terminal 30 are configured to be able to communicate with each other via a network. The vehicle 10 may be a connected car.

[0011] The vehicle 10 has multiple types of sensors (not shown). The multiple types of sensors may include internal sensors and external sensors. The external sensors may include an image sensor (e.g., a camera). The vehicle 10 has an acquisition / transmission unit 11. Collection conditions 12 are stored in a memory (not shown) of the vehicle 10. The acquisition / transmission unit 11 has an event processing unit 111 and multiple data input units 112.

[0012] Each of the plurality of data input units 112 acquires the time series data of one assigned sensor. As the plurality of data input units 112 acquire the time series data of the assigned sensor, the acquisition / transmission unit 11 acquires a plurality of time series data respectively corresponding to the plurality of types of sensors.

[0013] The data input unit 112 will now be described. Each data input unit 112 may have an input interface to which time-series data output from a sensor is input, a data acquisition unit that captures the time-series data input to the input interface, and a ring buffer that accumulates the time-series data acquired by the data acquisition unit for a certain period of time. In other words, in the acquisition and transmission unit 11, the time-series data may be accumulated in the ring buffer for each sensor.

[0014] The time-series data acquired by the data acquisition unit is assigned a timestamp indicating absolute time. The ring buffer may be configured on volatile memory or non-volatile memory. When the ring buffer reaches its upper limit size, the oldest data is overwritten.

[0015] The event processing unit 111 may include an event detection / generation unit, an instance buffer, a transmission queue, and an instance transmission unit. The event detection / generation unit detects events from the time-series data in the ring buffer of the data input unit 112 based on event detection logic defined in the collection conditions 12. For example, the event detection / generation unit may detect data having a predetermined pattern as an event from the time-series data in the ring buffer. In other words, the acquisition / transmission unit 111 detects events from multiple pieces of time-series data based on the acquisition conditions 12.

[0016] Here, the acquisition condition 12 includes at least the event type, the event detection logic, the deadline for sending the detected event to the server 20, and the period of the event. Here, the "period of the event" means the period from the time a first period before the time the event occurred to the time a second period after the time the event occurred. Hereinafter, the "deadline for sending the detected event to the server 20" will be referred to as the "deadline" as appropriate.

[0017] When an event is detected from the time-series data, the event detection and generation unit identifies data for a predetermined period including the detected event as data to be collected, based on the period of the event defined in the collection conditions 12. The event detection and generation unit stores information about the data to be collected as an instance in the instance buffer. At this time, the event detection and generation unit assigns an ID to the instance to uniquely identify the instance. Here, the instance is meta-information, and the data to be collected itself remains in the ring buffer.

[0018] For example, the ID may be an ID based on a timestamp such as UUIDv7. This configuration allows instances to be easily searched for based on time information. However, the ID is not limited to an ID based on a timestamp such as UUIDv7.

[0019] The event processing unit 111 will be further described with reference to Fig. 2. In the example shown in Fig. 2, data related to application logs, data related to cameras, data related to CAN (Controller Area Network), and data related to diagnosis are listed as multiple time-series data corresponding to multiple types of sensors. In Fig. 2, solid lines extending along the time axis indicate periods during which data detected as events (i.e., data to be collected) exist.

[0020] In the example shown in FIG. 2, collection target data D1 and D2 exist as collection target data related to application logs (see "AppLog"). Collection target data D3 and D4 exist as collection target data related to cameras. Collection target data D5 exists as collection target data related to CAN. Collection target data D6 exists as collection target data related to diagnosis (see "Diag").

[0021] In FIG. 2, time t2 is the time when an event included in each of collection target data D1, D3, and D5 is detected. Time t1 is the time a first period before time t2 when the event is detected (in other words, the time when the event occurred). Time t4 is the time a second period after time t2 when the event is detected (in other words, the time when the event occurred). As described above, the first period and the second period are periods related to the period of the event defined in collection condition 12. Note that the first period and the second period may be the same or different.

[0022] Time t5 is the time when an event included in each of collection target data D2, D4, and D6 was detected. Time t3 is the time a first period before time t5 when the event was detected (in other words, the time when the event occurred). Time t6 is the time a second period after time t5 when the event was detected (in other words, the time when the event occurred).

[0023] 2, for an application log, an instance related to collection target data D1 and an instance related to collection target data D2 are stored in the instance buffer. The instance related to collection target data D1 is assigned an ID of ID1. The instance related to collection target data D2 is assigned an ID of ID2.

[0024] For the camera, an instance related to collection target data D3 and an instance related to collection target data D4 are stored in the instance buffer. The instance related to collection target data D3 is assigned an ID of ID1. The instance related to collection target data D4 is assigned an ID of ID2.

[0025] For CAN, instance In3 related to collection target data D5 is stored in the instance buffer. Instance In3 has been assigned ID1 as its ID. For diagnosis, instance In4 related to collection target data D6 is stored in the instance buffer. Instance In4 has been assigned ID2 as its ID.

[0026] An instance related to the collection target data includes information about the start time and end time of the collection target data. The information about the start time and end time may be information indicating the start time and end time, respectively, or may be pointers (e.g., line numbers or byte offsets) corresponding to the start time and end time, respectively.

[0027] The event detection and generation unit integrates two instances that have a common type of data and overlap in time period from multiple instances stored in the instance buffer into one virtual instance. Note that "type" may also be referred to as "category."

[0028] For example, collection target data D1 and D2 are collection target data related to application logs. Therefore, it can be said that the instance related to collection target data D1 and the instance related to collection target data D2 have a common type of data. In addition, as shown in FIG. 2, the instance related to collection target data D1 and the instance related to collection target data D2 overlap in the time period from time t3 to time t4. Therefore, the event detection and generation unit may integrate the instance related to collection target data D1 and the instance related to collection target data D2 into a single virtual instance In1. The virtual instance In1 is stored in the instance buffer.

[0029] The event detection and generation unit regards information on an earlier start time, out of information on the start time included in the instance related to collection target data D1 and information on the start time included in the instance related to collection target data D2, as information on the start time related to the virtual instance In1. Furthermore, the event detection and generation unit regards information on an later end time, out of information on the end time included in the instance related to collection target data D1 and information on the end time included in the instance related to collection target data D2, as information on the end time related to the virtual instance In1. In the example shown in FIG. 2, time t1 is the start time of the virtual instance In1, and time t6 is the end time of the virtual instance In1. The event detection and generation unit stores the IDs (specifically, ID1 and ID2) of the instance related to collection target data D1 and the instance related to collection target data D2 in the virtual instance In1.

[0030] The event detection and generation unit further stores data common to the instance related to collection target data D1 and the instance related to collection target data D2 in a virtual instance In1. The event detection and generation unit deletes the common data from each of the instance related to collection target data D1 and the instance related to collection target data D2. As a result, data that is not common to the instance related to collection target data D1 and the instance related to collection target data D2 remains in at least one of the instance related to collection target data D1 and the instance related to collection target data D2. Note that if there is no data that is not common, the event detection and generation unit deletes at least one of the instance related to collection target data D1 and the instance related to collection target data D2 from the instance buffer.

[0031] For example, collection target data D3 and D4 are collection target data related to a camera. Therefore, it can be said that the instance related to collection target data D3 and the instance related to collection target data D4 have a common type of data. In addition, as shown in FIG. 2, the instance related to collection target data D3 and the instance related to collection target data D4 overlap in the time period from time t3 to time t4. Therefore, the event detection and generation unit may integrate the instance related to collection target data D3 and the instance related to collection target data D4 into a single virtual instance In2. The virtual instance In2 is stored in the instance buffer.

[0032] The event detection and generation unit regards the information on the earlier start time, out of the information on the start time included in the instance related to collection target data D3 and the information on the start time included in the instance related to collection target data D4, as the information on the start time related to virtual instance In2. Furthermore, the event detection and generation unit regards the information on the end time included in the instance related to collection target data D3 and the information on the end time included in the instance related to collection target data D4, as the information on the end time related to virtual instance In2. The event detection and generation unit stores the IDs (specifically, ID1 and ID2) of the instance related to collection target data D3 and the instance related to collection target data D4 in virtual instance In2.

[0033] The event detection and generation unit further stores data common to the instance related to collection target data D3 and the instance related to collection target data D4 in a virtual instance In2. The event detection and generation unit deletes the common data from each of the instance related to collection target data D3 and the instance related to collection target data D4. As a result, data that is not common to the instance related to collection target data D3 and the instance related to collection target data D4 remains in at least one of the instance related to collection target data D3 and the instance related to collection target data D4. Note that if there is no data that is not common, the event detection and generation unit deletes at least one of the instance related to collection target data D3 and the instance related to collection target data D4 from the instance buffer.

[0034] For example, suppose there is no data of a common type with the collection target data D5 related to CAN. In this case, the event detection and generation unit does not integrate the instance In3 related to the collection target data D5 with other instances. For example, suppose there is no data of a common type with the collection target data D6 related to diagnosis. In this case, the event detection and generation unit does not integrate the instance In4 related to the collection target data D6 with other instances. Note that the instances In3 and In4 may be referred to as actual instances.

[0035] For example, data related to an application log and data related to a camera may be the same type of data. As shown in FIG. 2, virtual instance In1 and virtual instance In2 overlap in the time period from time t1 to time t6. Therefore, the event detection and generation unit may integrate virtual instance In1 and virtual instance In2 into a single virtual instance In5. In this way, the event detection and generation unit repeats the integration process until all instances in the instance buffer that have the same type of data and overlap in the instance time period are integrated into a single virtual instance. Note that the instance buffer may store both real instances and virtual instances.

[0036] The acquisition / transmission unit 11 transmits the instance to the server 20 based on the deadline defined in the acquisition condition 12. In the example shown in Fig. 2, the deadline for the event detected at time t2 may be time t7. Also, the deadline for the event detected at time t5 may be time t8.

[0037] For example, the acquisition and transmission unit 11 transmits the instance In3 to the server 20 at time t7. Specifically, in the event processing unit 111, the instance In3 is stored in a transmission queue by time t7. Then, the instance transmission unit of the event processing unit 111 transmits the instance In3 stored in the transmission queue to the server 20 at time t7. Similarly, the acquisition and transmission unit 11 transmits the instance In4 to the server 20 at time t8.

[0038] For example, virtual instance In5 is an instance related to both the event detected at time t2 and the event detected at time t5. In this embodiment, the earlier of time t7, which is the deadline related to the event detected at time t2, and time t8, which is the deadline related to the event detected at time t5 (i.e., time t7), is set as the deadline of virtual instance In5. Therefore, the acquisition and transmission unit 11 transmits virtual instance In5 to the server 20 at time t7.

[0039] When transmitting an instance to the server 20, the acquisition / transmission unit 11 transmits to the server 20, in addition to the instance, data in the ring buffer referenced by the instance (i.e., data corresponding to the data to be acquired) and an index associated with the instance. If the instance is a real instance, the index includes an ID associated with the real instance and a time period for the real instance (e.g., information related to the start time and end time). If the instance is a virtual instance, the index includes an ID associated with the virtual instance and an ID and time period for an instance referenced by the virtual instance (in other words, an integrated instance).

[0040] Next, the event detection process performed by the event detection acquisition unit of the event processing unit 111 will be described with reference to the flowchart in Fig. 3(a). In Fig. 3(a), the event detection processing unit reads new data from the ring buffer (step S101). Next, the event detection processing unit determines whether or not the detection process for all triggers has been completed (step S102). If it is determined in the process of step S102 that the detection process for all triggers has been completed (step S102: Yes), the process ends.

[0041] In the process of step S102, if it is determined that the detection process for all triggers has not been completed (step S102: No), the event detection acquisition unit checks the occurrence of an event using the trigger logic (step S103). Next, the event detection acquisition unit determines whether the occurrence of an event has been detected (step S104). In the process of step S104, if it is determined that the occurrence of an event has not been detected (step S104: No), the event detection acquisition unit performs the process of step S102.

[0042] If it is determined in the process of step S104 that the occurrence of an event has been detected (step S104: Yes), the event detection and acquisition unit generates an instance and stores it in the instance buffer (step S105). Thereafter, the event detection and acquisition unit performs the process of step S102.

[0043] Next, the instance integration process performed by the event detection and acquisition unit will be described with reference to the flowchart in Fig. 3(b). In Fig. 3(b), the event detection and acquisition unit determines whether any of the instances in the instance buffer cannot be integrated (step S201). If it is determined in the process of step S201 that integration is not possible (step S201: Yes), the process ends.

[0044] If it is determined in the process of step S201 that integration is possible (step S201: No), the event detection and acquisition unit determines whether or not all combinations of instances in the instance buffer have been confirmed (step S202). If it is determined in the process of step S202 that all combinations of instances have been confirmed (step S202: Yes), the event detection and acquisition unit performs the process of step S201.

[0045] If it is determined in the process of step S202 that all combinations of instances have not been checked (step S202: No), the event detection and acquisition unit extracts the next combination of instances (step S203). Next, the event detection and acquisition unit determines whether two instances are collecting data of a common type and whether their time periods overlap (step S204).

[0046] If it is determined in the processing of step S204 that the two instances do not target data of a common type or that there is no overlap in their time periods (step S204: No), the event detection and acquisition unit performs the processing of step S202. On the other hand, if it is determined in the processing of step S204 that the two instances target data of a common type and that there is an overlap in their time periods (step S204: Yes), the event detection and acquisition unit generates one virtual instance (step S205). At this time, the event detection and acquisition unit targets data of a common type between the two instances as the target for collection. The event detection and acquisition unit sets the earlier start time and the later end time of the two instances as the start time and end time of the virtual instance. The event detection and acquisition unit sets the earlier of the deadlines of the two instances as the deadline of the virtual instance. The event detection and acquisition unit adds the virtual instance to the instance buffer. The event detection and acquisition unit leaves only data that is not a common type as the target for collection in the two instances.

[0047] Next, the event detection and acquisition unit determines whether the remaining collection targets for the two instances are empty sets (step S206). If it is determined in the processing of step S206 that the remaining collection targets are empty sets (step S206: Yes), the event detection and acquisition unit deletes the instances whose remaining collection targets are empty sets from the instance buffer (step S207). Thereafter, the event detection and acquisition unit performs the processing of step S202. If it is determined in the processing of step S206 that the remaining collection targets are not empty sets (step S206: No), the event detection and acquisition unit performs the processing of step S202.

[0048] Next, the deadline processing performed by the event processing unit 111 will be described with reference to the flowchart in Fig. 3(c). In Fig. 3(c), the event processing unit 111 determines whether the deadlines of all instances in the instance buffer have been confirmed (step S301). If it is determined in the processing of step S301 that the deadlines of all instances have been confirmed (step S301: Yes), the processing ends.

[0049] In the process of step S301, if it is determined that the deadlines of all instances have not been confirmed (step S301: No), the event processing unit 111 retrieves the next instance from the instance buffer (step S302). Next, the event processing unit 111 determines whether the deadline of the instance is after the current time (step S303).

[0050] If it is determined in the process of step S303 that the deadline of the instance is after the current time (step S303: Yes), the event processing unit 111 retrieves the data referenced by the instance from the ring buffer, assigns an index to the data, and stores the data in the transmission queue (step S304). Thereafter, the event processing unit 111 performs the process of step S301. On the other hand, if it is determined in the process of step S303 that the deadline of the instance is not after the current time (step S303: No), the event processing unit 111 performs the process of step S301.

[0051] 1, the receiving and storing unit 21 of the server 20 stores the instance and index received from the vehicle 10 in the database 23. At this time, the receiving and storing unit 21 transmits a receipt confirmation to the vehicle 10.

[0052] For example, the receiving and storing unit 21 may extract the original instance (i.e., the real instance) from the virtual instance immediately after receiving the virtual instance and the index. The method for extracting the original instance will be described with reference to Fig. 4. In Fig. 4, parts that are common to Fig. 2 are denoted by the same reference numerals.

[0053] The index of the hypothetical instance In5 is assumed to include a start time t1 and an end time t4 for ID1, and a start time t3 and an end time t6 for ID2.

[0054] The receiving and storing unit 21 may extract an instance related to collection target data D1 of the application log from the virtual instance In5 based on the start time t1 and end time t4 for ID1 included in the index. The receiving and storing unit 21 may extract an instance related to collection target data D3 of the camera from the virtual instance In5 based on the start time t1 and end time t4 for ID1 included in the index. The receiving and storing unit 21 may extract an instance related to collection target data D2 of the application log from the virtual instance In5 based on the start time t3 and end time t6 for ID2 included in the index. The receiving and storing unit 21 may extract an instance related to collection target data D4 of the camera from the virtual instance In5 based on the start time t3 and end time t6 for ID2 included in the index. As a result, real instances may be extracted as shown in the lower part of FIG. 4.

[0055] Note that if the start time and end time are used to extract the original instance, the cost is O(log N) to O(N). For example, if the line number or byte offset from the beginning of the virtual instance data is used to extract the original instance, the cost is O(1).

[0056] 1, the query sending unit 31 of the terminal 30 sends an instance request from a user as a query to the query processing unit 22 of the server 20. The query may include requests to acquire all instances, acquire instances with matching ID prefixes, acquire instances with a specific ID, acquire instances with a specific event type, or a combination of these. The query may include, as filter conditions, part or all of the ID or VIN (Vehicle Identification Number) that identify the collection conditions and the event type.

[0057] When the server 20 receives a query from the terminal 30, the query processing unit 22 of the server 20 transmits the original instance requested by the query to the terminal 30 (that is, provides the original instance to the user).

[0058] The extraction of the original instance is not limited to immediately after the virtual instance and index are received. For example, the original instance may be extracted after a sufficient time has elapsed from the deadline specified by the instance and collection conditions first received by the server 20 until all virtual instances are transmitted (in other words, uploaded) to the server 20. For example, the original instance may be extracted when the server 20 receives a query from the terminal 30 (in other words, when a user requests it).

[0059] (Technical Effects) As described above, the management system 1 integrates duplicate data by creating virtual instances. Therefore, the management system 1 can prevent duplicate data (i.e., the same data) from being sent multiple times from the vehicle 10 to the server 20. As a result, communication costs and server operation costs can be reduced. Furthermore, the management system 1 sets a deadline for each instance, so that even if events occur consecutively, it can be guaranteed that the instance will be sent to the server 20 when the deadline is reached. As a result, it can be prevented from endlessly integrating instances in the vehicle 10. Therefore, the management system 1 can suppress calculation costs and reduce the amount of communication data.

[0060] (First Modification) A first modified example of the vehicle data management system will be described with reference to Fig. 5. In the following, the first modified example of the vehicle data management system will be described using a management system 2. In Fig. 5, the management system 2 includes a vehicle 10a, a server 20, and a terminal 30. The vehicle 10a includes acquisition and transmission units 11a and 11b.

[0061] After the acquisition / transmission unit 11a detects an event from one data, the acquisition / transmission unit 11a may request the acquisition / transmission unit 11b to acquire and transmit other data. At this time, the acquisition / transmission unit 11a may transmit information indicating the ID, the event type, and the target data type to the acquisition / transmission unit 11b so that the acquisition / transmission unit 11b can identify the other data. The acquisition / transmission unit 11b may generate an instance based on the information transmitted from the acquisition / transmission unit 11a and the collection conditions 12. The acquisition / transmission unit 11b may transmit the instance to the server 20.

[0062] (Second Modification) In the instance integration process described with reference to the flowchart in Figure 3(b), all combinations of instances in the instance buffer are checked, so the time required is O(N 2) computational cost. Therefore, in the instance integration process, first, the instances in the instance buffer may be sorted in ascending order of start time and end time. Then, the sorted instances are integrated in ascending order, thereby enabling efficient instance integration. In this case, the computational cost of sorting is O(log N), and the computational cost of the subsequent processes is O(N). In other words, in the second modified example, the instance integration process can be performed with a computational cost of O(N log N).

[0063] (Third Modification) In the example shown in FIG. 2, the periods (i.e., the periods from the start time to the end time) of the collection target data D1 to D6 are the same. However, there are cases where it is desired that the period of an event for one sensor defined in the collection condition 12 is different from the period of an event for another sensor. In the example shown in FIG. 2, if CAN data is collected for a longer period than other data, the acquisition and transmission unit 11 may transmit to the server 20 instances (e.g., virtual instances) of the CAN divided into predetermined periods that are shorter than the collection period. In this case, the acquisition and transmission unit 11 may add the start time and end time of each divided instance to the index related to the divided instance.

[0064] For example, an index for a first division instance may include a start time and an end time of the first division instance. An index for a second division instance sent to the server 20 after the first division instance may include a start time and an end time of the first division instance and a start time and an end time of the second division instance. An index for a third division instance sent to the server 20 after the second division instance may include a start time and an end time of the first division instance, a start time and an end time of the second division instance, and a start time and an end time of the third division instance.

[0065] Aspects of the invention derived from the above-described embodiment and modifications will be described below.

[0066] A vehicle data management system according to one aspect of the present invention is a vehicle data management system that manages data acquired in a vehicle in a server external to the vehicle, wherein the vehicle detects data having a predetermined pattern as an event from a plurality of types of time series data corresponding to a plurality of sensors, and when a first event and a second event are detected from the plurality of types of time series data, first data is acquired from the time series data in which the first event was detected, which is data for a first predetermined period including the first event, and second data is acquired from the time series data in which the second event was detected, which is data for a second predetermined period including the second event, and and a processing means configured to integrate the first data and the second data to generate integrated data when the type of the first data overlaps with the type of time-series data in which the second event was detected and when at least a part of the first predetermined period and the second predetermined period overlap, and to transmit the integrated data and index data related to the integrated data to the server, wherein the server comprises an extraction means that extracts the first data and the second data from the integrated data based on the index data immediately after receiving the integrated data and the index data or when requested by a user, and a provision means that provides the first data and the second data to the user.

[0067] In the above-described embodiment, the "acquisition and transmission unit 11" corresponds to an example of a "processing means", the "receiving and storage unit 21" corresponds to an example of an "extraction means", and the "query processing unit 22" corresponds to an example of a "provision means".

[0068] In the vehicle data management system, the index data may include first information relating to a start time and an end time of the first data, and second information relating to a start time and an end time of the second data.

[0069] In the vehicle data management system, the processing means sets a first timing for transmitting the first data to the server based on the first predetermined period, and a second timing for transmitting the second data to the server based on the second predetermined period, and the timing for transmitting the integrated data to the server may be the earlier of the first timing and the second timing.

[0070] The present invention is not limited to the above-described embodiments, but can be modified as appropriate within the scope of the claims and the gist or concept of the invention as can be read from the entire specification, and vehicle data management systems involving such modifications are also included in the technical scope of the present invention. [Explanation of symbols]

[0071] 1, 2... management system, 10, 10a... vehicle, 20... server, 30... terminal

Claims

1. A vehicle data management system that manages data acquired in a vehicle in a server external to the vehicle, The vehicle is Detecting data having a predetermined pattern as an event from multiple types of time series data corresponding to multiple sensors, When a first event and a second event are detected from the plurality of types of time-series data, first data is obtained from the time-series data in which the first event is detected, the first data being data for a first predetermined period including the first event, and second data is obtained from the time-series data in which the second event is detected, the second data being data for a second predetermined period including the second event; if a type of time-series data in which the first event is detected overlaps with a type of time-series data in which the second event is detected and if at least a part of the first predetermined period and the second predetermined period overlap, integrating the first data and the second data to generate integrated data; Transmitting the integrated data and index data relating to the integrated data to the server. a processing means configured to: The server an extracting means for extracting the first data and the second data from the integrated data based on the index data immediately after receiving the integrated data and the index data or upon a request from a user; providing means for providing the first data and the second data to the user; Equipped with Vehicle data management system.

2. The index data includes first information relating to a start time and an end time of the first data and second information relating to a start time and an end time of the second data. The vehicle data management system according to claim 1 .

3. The processing means setting a first timing for transmitting the first data to the server based on the first predetermined period and a second timing for transmitting the second data to the server based on the second predetermined period; The timing at which the integrated data is transmitted to the server is the earlier of the first timing and the second timing. The vehicle data management system according to claim 1 .

Images