Vehicle data management system

Abstract

The invention suppresses the calculation cost. A vehicle data management system manages data acquired in a vehicle in an external server. The vehicle detects a first event and a second event from a plurality of types of time-series data, and if a category of the time-series data in which the first event is detected is repeated with a category of the time-series data in which the second event is detected. In the case where a first event and a second event are included, and a first predetermined period including the first event and at least a part of a second predetermined period including the second event overlap, first data of the first event and second data of the second event are integrated to generate integrated data, and the integrated data and index data related to the integrated data are transmitted to a server. The server 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 in the presence of a request from the user, and provides the first data and the second data to the user.

Description

Technical Field

[0001] This invention relates to the technical field of vehicle data management systems. Background Technology

[0002] As such a system, for example, the following system is proposed: when a first upload object event and a second upload object event occur while the vehicle is in motion, and there is an overlap between the period of the first upload object event and the period of the second upload object event, the priority of the first upload object event and the priority of the second upload object event are compared, and data within the overlap period is excluded from the dataset related to the upload object event with the lower priority (see Patent Document 1).

[0003] Existing technical documents

[0004] Patent documents

[0005] Patent Document 1: Japanese Patent Application Publication No. 2022-157157

[0006] In the technology described in Patent Document 1, the computational cost of an external server may increase. Summary of the Invention

[0007] The present invention was made in view of the above circumstances, and its objective is to provide a vehicle data management system that can suppress computing costs.

[0008] One aspect of the present invention is a vehicle data management system that manages data acquired in the vehicle on a server external to the vehicle. The vehicle includes a processing unit configured to: detect data with a predetermined pattern from multiple time-series data corresponding to multiple sensors as events; if a first event and a second event are detected from the multiple time-series data, obtain first data from the time-series data that detected the first event as data including a first predetermined period of the first event, and obtain second data from the time-series data that detected the second event as data including a second predetermined period of the second event; if the category of the time-series data that detected the first event overlaps with the category of the time-series data that detected the second event, and at least a portion of the first predetermined period overlaps with the second predetermined period, integrate the first data and the second data to generate integrated data; and send the integrated data and index data associated with the integrated data to the server, the server including: an extraction unit that, immediately after receiving the integrated data and the index data, or in the presence of a request from a user, extracts the first data and the second data from the integrated data based on the index data; and a providing unit that provides the first data and the second data to the user. Attached Figure Description

[0009] Figure 1 This is a block diagram illustrating an example of a management system implementation.

[0010] Figure 2 This is a conceptual diagram illustrating the concept of data processing in a vehicle according to an implementation method.

[0011] Figure 3 This is a flowchart illustrating an example of the vehicle's movement in an implementation method.

[0012] Figure 4 This is a conceptual diagram representing the data processing concept in a server as described in the implementation method.

[0013] Figure 5 This is a block diagram illustrating another example of a management system for implementing an implementation method.

[0014] Explanation of reference numerals in the attached figures:

[0015] 1, 2: Management system; 10, 10a: Vehicles; 20: Server; 30: Terminal. Detailed Implementation

[0016] Reference Figures 1 to 4The implementation method of the vehicle data management system will be described below. Hereinafter, the implementation method of the vehicle data management system will be described using management system 1.

[0017] exist Figure 1 In this system, management system 1 includes vehicle 10, server 20, and terminal 30. Terminal 30 is a terminal held by a user. It should be noted that the user can be an end user. Vehicle 10 can be a vehicle owned by the user holding terminal 30. However, vehicle 10 can also be a vehicle owned by someone different from the user holding terminal 30.

[0018] Vehicle 10, server 20, and terminal 30 are configured to communicate with each other via a network. It should be noted that vehicle 10 can be a connected car.

[0019] Vehicle 10 has multiple sensors (not shown). These sensors may include internal and external sensors. External sensors may include image sensors (e.g., cameras). Vehicle 10 has an acquisition and transmission unit 11. Collection conditions 12 are stored in the vehicle 10's memory (not shown). The acquisition and transmission unit 11 has an event processing unit 111 and multiple data input units 112.

[0020] Multiple data input units 112 acquire time-series data from one assigned sensor. The acquisition and transmission unit 11 acquires multiple time-series data corresponding to multiple sensors by acquiring the time-series data from the assigned sensors through the multiple data input units 112.

[0021] The data input unit 112 will be described below. Each data input unit 112 may include: an input interface for inputting time-series data output from a sensor; a data acquisition unit for acquiring the time-series data input to the input interface; and a ring buffer for accumulating the time-series data acquired by the data acquisition unit for a certain period of time. That is, in the acquisition and transmission unit 11, time-series data can be accumulated in the ring buffer for each sensor.

[0022] It should be noted that the time-series data acquired by the data acquisition unit is assigned a timestamp representing an absolute moment. It should also be noted that the ring buffer can be configured on either volatile or non-volatile memory. When the ring buffer reaches its maximum size, it is overwritten sequentially starting from the oldest data.

[0023] The event processing unit 111 may include an event detection generation unit, an instance buffer, a sending queue, and an instance sending unit. The event detection generation unit detects events from the time-series data within the circular buffer of the data input unit 112 based on the event detection logic determined in the collection condition 12. For example, the event detection generation unit can detect data with a defined pattern from the time-series data within the circular buffer as events. That is, the acquisition and sending unit 11 detects events from multiple time-series data based on the collection condition 12.

[0024] Here, the collection condition 12 includes at least the event category, the event detection logic, the deadline for sending the detected event to the server 20, and the event duration. Here, "event duration" refers to the period from a time earlier than the time the event occurred to a time later than the time the event occurred. It should be noted that, hereinafter, "the deadline for sending the detected event to the server 20" will be appropriately referred to as the "final deadline".

[0025] When an event is detected from time-series data, the event detection generation unit determines the data, including the specified period of the detected event, as the collection target data based on the period of the event determined in collection condition 12. The event detection generation unit stores information related to the collection target data as instances in an instance buffer. At this time, the event detection generation unit assigns an ID to the instance to uniquely identify the instance. Here, the instance is metadata, and the collection target data itself is retained in a circular buffer.

[0026] For example, the ID can be a timestamp-based ID such as UUIDv7. If configured this way, instances can be easily retrieved based on time information. However, the ID is not limited to timestamp-based IDs such as UUIDv7.

[0027] Reference Figure 2 The Incident Handling Department 111 will be explained. Figure 2 In the example shown, multiple time-series data corresponding to various sensors are cited, including application log data, camera data, CAN (Controller Area Network) data, and diagnostic data. Figure 2 In the diagram, the solid lines extending along the time axis represent the periods during which data detected as events (i.e., the data collected from the objects) existed.

[0028] exist Figure 2In the example shown, as the collection object data for application logs (refer to "AppLog"), there are collection object data D1 and collection object data D2. As the collection object data for cameras (refer to "Camera"), there are collection object data D3 and collection object data D4. As the collection object data for CAN, there is collection object data D5. As the collection object data for diagnostics (refer to "Diag"), there is collection object data D6.

[0029] exist Figure 2 In this context, time t2 is the time when the events included in each of the collected object data D1, collected object data D3, and collected object data D5 are detected. Time t1 is a time that is a first period earlier than the time t2 when the event is detected (in other words, the time when the event occurs). Time t4 is a time that is a second period later than the time t2 when the event is detected (in other words, the time when the event occurs). As mentioned above, the first period and the second period are periods related to the period of the event determined in collection condition 12. It should be noted that the first period and the second period can be the same or different.

[0030] Time t5 is the time when the events included in each of the collected object data D2, collected object data D4, and collected object data D6 are detected. Time t3 is the time one period earlier than the time t5 when the event was detected (in other words, the time when the event occurred). Time t6 is the time two periods later than the time t5 when the event was detected (in other words, the time when the event occurred).

[0031] exist Figure 2 In the example shown, regarding application logs, instances of collected object data D1 and collected object data D2 are stored in an instance buffer. The instance of collected object data D1 is assigned ID1 as its ID. The instance of collected object data D2 is assigned ID2 as its ID.

[0032] Regarding the camera, instances of collected object data D3 and collected object data D4 are stored in an instance buffer. The instance of collected object data D3 is assigned ID1 as its ID. The instance of collected object data D4 is assigned ID2 as its ID.

[0033] Regarding CAN, instance In3 of collected object data D5 is stored in the instance buffer. Instance In3 is assigned ID1 as its ID. Regarding diagnostics, instance In4 of collected object data D6 is stored in the instance buffer. Instance In4 is assigned ID2 as its ID.

[0034] An instance of collecting object data contains information related to the start and end times of the object data collection. It should be noted that the information related to the start and end times can be information representing the start and end times respectively, or it can be pointers (such as line numbers or byte offsets) that are equivalent to the start and end times respectively.

[0035] The event detection generation unit merges two instances that share common data types and overlap within the same time period into a single virtual instance from multiple instances stored in the instance buffer. It should be noted that "type" can also be referred to as "category".

[0036] For example, collection object data D1 and collection object data D2 are collection object data for application logs. Therefore, it can be said that instances of collection object data D1 and collection object data D2 share a common type of data. In addition, such as Figure 2 As shown, the time intervals from time t3 to time t4 for instances of collected object data D1 and D2 are repeated. Therefore, the event detection generation unit can merge instances of collected object data D1 and D2 into a single virtual instance In1. Virtual instance In1 is stored in an instance buffer.

[0037] The event detection generation unit sets the information related to the start time contained in the instance of collected object data D1 and the information related to the start time contained in the instance of collected object data D2, specifically the information related to the earlier start time, as the start time-related information of the virtual instance In1. Furthermore, the event detection generation unit sets the information related to the end time contained in the instance of collected object data D1 and the information related to the end time contained in the instance of collected object data D2, specifically the information related to the later end time, as the end time-related information of the virtual instance In1. Figure 2 In the example shown, time t1 is the start time of virtual instance In1, and time t6 is the end time of virtual instance In1. The event detection generation unit stores the IDs (specifically ID1 and ID2) of the instances collecting object data D1 and D2 in virtual instance In1.

[0038] The event detection generation unit also stores data shared by the instances of collected object data D1 and collected object data D2 in virtual instance In1. The event detection generation unit then deletes this shared data from both instances of collected object data D1 and collected object data D2. As a result, at least one of the instances of collected object data D1 and collected object data D2 retains data that is not shared between them. It should be noted that if no non-shared data exists, the event detection generation unit deletes at least one of the instances of collected object data D1 and collected object data D2 from the instance buffer.

[0039] For example, object data D3 and object data D4 are object data collected by the camera. Therefore, it can be said that instances of object data D3 and instances of object data D4 share a common type of data. In addition, such as Figure 2 As shown, the time intervals from time t3 to time t4 for instances of collected object data D3 and D4 are repeated. Therefore, the event detection generation unit can merge the instances of collected object data D3 and D4 into a single virtual instance In2. The virtual instance In2 is stored in the instance buffer.

[0040] The event detection generation unit sets the information related to the start time contained in the instance of collected object data D3 and the information related to the start time contained in the instance of collected object data D4, specifically the information related to the earlier start time, as the start time-related information of the virtual instance In2. Furthermore, the event detection generation unit sets the information related to the end time contained in the instance of collected object data D3 and the information related to the end time contained in the instance of collected object data D4, specifically the information related to the later end time, as the end time-related information of the virtual instance In2. The event detection generation unit stores the respective IDs (specifically ID1 and ID2) of the instances of collected object data D3 and collected object data D4 in the virtual instance In2.

[0041] The event detection generation unit also stores data shared between instances of collected object data D3 and collected object data D4 in virtual instance In2. The event detection generation unit then deletes this shared data from both instances of collected object data D3 and collected object data D4. As a result, at least one of the instances of collected object data D3 and collected object data D4 retains data that is not shared between them. It should be noted that if no non-shared data exists, the event detection generation unit deletes at least one of the instances of collected object data D3 and collected object data D4 from the instance buffer.

[0042] For example, suppose there is no data type shared with CAN's collected object data D5. In this case, the event detection generation unit does not integrate instance In3 of collected object data D5 with other instances. Similarly, suppose there is no data type shared with diagnostic collected object data D6. In this case, the event detection generation unit does not integrate instance In4 of collected object data D6 with other instances. It should be noted that instances In3 and In4 can also be referred to as actual instances.

[0043] For example, application log data and camera data can be the same type of data. Figure 2 As shown, the time periods from time t1 to time t6 of virtual instances In1 and In2 overlap. Therefore, the event detection generation unit can merge virtual instances In1 and In2 into a single virtual instance In5. This merging process is repeated until all instances in the instance buffer that share common data types and overlap within the instance's time period are merged into a single virtual instance. It should be noted that the instance buffer can also store both actual instances and virtual instances.

[0044] The receiving and sending unit 11 sends the instance to the server 20 based on the final deadline determined in collection condition 12. Figure 2 In the example shown, the deadline for an event detected at time t2 could be time t7. Furthermore, the deadline for an event detected at time t5 could be time t8.

[0045] For example, the acquisition and sending unit 11 sends instance In3 to server 20 at time t7. Specifically, in event processing unit 111, instance In3 is stored in the sending queue before time t7. Then, the instance sending unit of event processing unit 111 sends instance In3 stored in the sending queue to server 20 at time t7. Similarly, the acquisition and sending unit 11 sends instance In4 to server 20 at time t8.

[0046] For example, virtual instance In5 is an instance associated with both the event detected at time t2 and the event detected at time t5. In this embodiment, the earlier of the two times, time t7 (the final deadline for the event detected at time t2) and time t8 (the final deadline for the event detected at time t5), is set as the final deadline for virtual instance In5. Therefore, the acquisition and transmission unit 11 sends virtual instance In5 to the server 20 at time t7.

[0047] When sending an instance to server 20, in addition to the instance, the acquisition and sending unit 11 also sends to server 20 data in the circular buffer referenced by the instance (i.e., data equivalent to acquiring object data) and an index associated with the instance. If the instance is a real instance, the index contains the ID of the real instance and the time period of the real instance (e.g., information related to the start and end times). If the instance is a virtual instance, the index contains the ID of the virtual instance, the ID of the instance referenced by the virtual instance (in other words, the integrated instance), and the time period.

[0048] Next, refer to Figure 3 The flowchart in (a) explains the event detection processing performed by the event detection and acquisition unit of the event processing unit 111. Figure 3 In step (a), the event detection processing unit reads new data from the ring buffer (step S101). Next, the event detection processing unit determines whether all triggered sensing processes have been completed (step S102). If it is determined in step S102 that all triggered sensing processes have been completed (step S102: Yes), the process ends.

[0049] If, in step S102, it is determined that not all triggered sensing processes have been completed (step S102: No), the event detection and acquisition unit confirms the occurrence of an event through the triggered logic (step S103). Next, the event detection and acquisition unit determines whether the occurrence of an event has been sensed (step S104). If, in step S104, it is determined that no event has been sensed (step S104: No), the event detection and acquisition unit performs the process of step S102.

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

[0051] Next, refer to Figure 3 The flowchart in (b) illustrates the instance integration processing performed by the event detection and acquisition unit. Figure 3 In step (b), the event detection and acquisition unit determines whether any instance in the instance buffer is unintegrable (step S201). If it is determined in step S201 that an instance is unintegrable (step S201: Yes), the process ends.

[0052] If the process in step S201 determines that the instances can be integrated (step S201: No), the event detection and acquisition unit determines whether the combination of all instances in the instance buffer has been confirmed (step S202). If the process in step S202 determines that the combination of all instances has been confirmed (step S202: Yes), the event detection and acquisition unit performs the process in step S201.

[0053] If, during the processing in step S202, it is determined that not all combinations of instances have been confirmed (step S202: No), the event detection and acquisition unit retrieves the next combination of instances (step S203). Next, the event detection and acquisition unit determines whether data of a type shared by two instances is being collected and whether the time period overlaps (step S204).

[0054] If, in step S204, it is determined that data of a type shared by the two instances will not be collected, or that the time periods do not overlap (step S204: No), the event detection and acquisition unit proceeds to step S202. Conversely, if, in step S204, it is determined that data of a type shared by the two instances will be collected, and the time periods overlap (step S204: Yes), the event detection and acquisition unit generates a virtual instance (step S205). In this case, the event detection and acquisition unit collects data of the types shared by the two instances. The event detection and acquisition unit sets the start time of the earlier instance and the end time of the later instance as the start and end times of the virtual instance. The event detection and acquisition unit sets the earlier deadline of the two instances as the deadline of the virtual instance. The event detection and acquisition unit appends the virtual instance to the instance buffer. The event detection and acquisition unit retains only data of types that are not shared between the two instances.

[0055] Next, the event detection and acquisition unit determines whether the retained collection objects are an empty set for each of the two instances (step S206). If it is determined in step S206 that the retained collection objects are an empty set (step S206: Yes), the event detection and acquisition unit deletes the instance with the empty collection objects from the instance buffer (step S207). Afterwards, the event detection and acquisition unit performs the process of step S202. If it is determined in step S206 that the retained collection objects are not an empty set (step S206: No), the event detection and acquisition unit performs the process of step S202.

[0056] Next, refer to Figure 3 The flowchart in (c) illustrates the deadline processing performed by the event handling unit 111. Figure 3 In step (c), the event handling unit 111 determines whether the final deadline of all instances in the instance buffer has been confirmed (step S301). If it is determined in step S301 that the final deadline of all instances has been confirmed (step S301: Yes), the process ends.

[0057] If, during the processing in step S301, it is determined that not all instances' final deadlines have 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 instance's final deadline is after the current time (step S303).

[0058] If, in step S303, it is determined that the final 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 circular buffer, assigns an index, and stores it in the transmission queue (step S304). Afterward, the event processing unit 111 performs the processing of step S301. On the other hand, if, in step S303, it is determined that the final deadline of the instance is not after the current time (step S303: No), the event processing unit 111 performs the processing of step S301.

[0059] return Figure 1 The receiving and accumulation unit 21 of server 20 stores the instances and indexes received from vehicle 10 in database 23. At this time, the receiving and accumulation unit 21 sends a receipt confirmation to vehicle 10.

[0060] For example, the receiving accumulation unit 21 can extract the original instance (i.e., the actual instance) from the virtual instance immediately after receiving the virtual instance and the index. (See reference...) Figure 4 The method for extracting the original instance is explained. It should be noted that... Figure 4 In the middle, to and Figure 2 Shared parts are indicated by the same reference numerals.

[0061] Suppose that the index of virtual instance In5 contains the start time t1 and end time t4 for ID1 and the start time t3 and end time t6 for ID2.

[0062] The receiving accumulation unit 21 can extract an instance of application log collection object data D1 from the virtual instance In5 based on the start time t1 and end time t4 of ID1 contained in the above index. The receiving accumulation unit 21 can also extract an instance of camera collection object data D3 from the virtual instance In5 based on the start time t1 and end time t4 of ID1 contained in the above index. The receiving accumulation unit 21 can also extract an instance of application log collection object data D2 from the virtual instance In5 based on the start time t3 and end time t6 of ID2 contained in the above index. The receiving accumulation unit 21 can also extract an instance of camera collection object data D4 from the virtual instance In5 based on the start time t3 and end time t6 of ID2 contained in the above index. As a result, it is possible to... Figure 4 The following paragraph shows the extraction of actual instances.

[0063] It should be noted that using the start and end times in the extraction of the original instance incurs a cost of O(logN) to O(N). For example, if the row number and byte offset at the beginning of the data from the virtual instance are used in the extraction of the original instance, the cost is O(1).

[0064] return Figure 1 The query sending unit 31 of terminal 30 sends the instance request from the user as a query to the query processing unit 22 of server 20. The query may include obtaining all instances, obtaining instances with the same ID prefix, obtaining instances with a specific ID, obtaining instances with a specific event category, or a combination of these. In the query, as filtering conditions, it may include part or all of the ID, VIN (Vehicle Identification Number), which identifies the collection conditions and event categories.

[0065] When server 20 receives a query from terminal 30, the query processing unit 22 of server 20 will send the original instance of the query request to terminal 30 (that is, provide the original instance to the user).

[0066] It should be noted that the retrieval of the original instance is not limited to immediately following the receipt of the virtual instance and index. For example, the original instance can also be retrieved after sufficient time has elapsed since the initial instance received from server 20 and the final deadline determined according to the collection conditions, up to the point where all virtual instances are sent to server 20 (in other words, uploaded). For example, the original instance can also be retrieved if server 20 receives a query from terminal 30 (in other words, if a user request exists).

[0067] (Technical effect)

[0068] In management system 1, as described above, duplicate data is consolidated by creating virtual instances. Therefore, management system 1 prevents duplicate data (i.e., the same data) from being sent multiple times from vehicle 10 to server 20. As a result, communication costs and server operating costs are reduced. Furthermore, management system 1 sets deadlines for each instance, so even if events occur consecutively, instances are guaranteed to be sent to server 20 as long as the deadline is reached. As a result, in vehicle 10, instances are prevented from being consolidated indefinitely. Therefore, according to management system 1, computational costs can be suppressed, and the amount of communication data can be reduced.

[0069] (First variation)

[0070] Reference Figure 5 A first variation of the vehicle data management system will be described below. Hereinafter, management system 2 will be used to describe the first variation of the vehicle data management system. Figure 5 In the system, the management system 2 includes a vehicle 10a, a server 20, and a terminal 30. The vehicle 10a has an acquisition and transmission unit 11a and an acquisition and transmission unit 11b.

[0071] After the acquisition and sending unit 11a detects an event from data, it can delegate the acquisition and sending of other data to the acquisition and sending unit 11b. At this time, in order for the acquisition and sending unit 11b to determine the other data, the acquisition and sending unit 11a can send information such as the ID, event category, and the type of data representing the object to the acquisition and sending unit 11b. The acquisition and sending unit 11b can generate an instance based on the information sent from the acquisition and sending unit 11a and the collection condition 12. The acquisition and sending unit 11b can also send this instance to the server 20.

[0072] (Second variation)

[0073] In reference Figure 3 In the instance integration process illustrated in flowchart (b), it takes O(N) time to confirm the combination of all instances in the instance buffer. 2 The computational cost of sorting is O(logN), and the computational cost of subsequent processing is O(N). Therefore, in instance consolidation processing, the instances in the instance buffer can first be sorted in ascending order of their start and end times. Then, instance consolidation processing can be performed efficiently by consolidating the sorted instances in ascending order. In this case, the computational cost of sorting is O(logN), and the computational cost of subsequent processing is O(N). That is, in the second variation, instance consolidation processing can be performed with a computational cost of O(NlogN).

[0074] (Third variation)

[0075] exist Figure 2 In the example shown, the period for collecting object data D1 to D6 (i.e., the period from the start time to the end time) is the same. However, sometimes it is desirable to make the period of events concerning one sensor, as determined in collection condition 12, different from the periods of events concerning other sensors. Figure 2 In the example shown, if CAN data is collected over a longer period than other data, the acquisition and transmission unit 11 can send instances (e.g., virtual instances) that have been segmented for each predetermined period shorter than the collection period to the server 20. In this case, the acquisition and transmission unit 11 can append the start and end times of each segmented instance to the index associated with the segmented instance.

[0076] For example, the start and end times of the first segmentation instance can be included in the index associated with the first segmentation instance. The start and end times of both the first and second segmentation instances can be included in the index associated with the second segmentation instance subsequently sent to server 20 from the first segmentation instance. The start and end times of the first, second, and third segmentation instances can be included in the index associated with the third segmentation instance subsequently sent to server 20 from the second segmentation instance.

[0077] The following describes the inventive solutions derived from the embodiments and variations described above.

[0078] One aspect of the invention is a vehicle data management system that manages data acquired in the vehicle on a server external to the vehicle. The vehicle includes a processing unit configured to: detect data with a predetermined pattern from multiple time-series data corresponding to multiple sensors as events; if a first event and a second event are detected from the multiple time-series data, obtain first data from the time-series data that detected the first event as data including a first predetermined period of the first event, and obtain second data from the time-series data that detected the second event as data including a second predetermined period of the second event; if the category of the time-series data that detected the first event overlaps with the category of the time-series data that detected the second event, and at least a portion of the first predetermined period overlaps with the second predetermined period, integrate the first data and the second data to generate integrated data; and send the integrated data and index data associated with the integrated data to the server, the server including: an extraction unit that, immediately after receiving the integrated data and the index data, or in the presence of a request from a user, extracts the first data and the second data from the integrated data based on the index data; and a providing unit that provides the first data and the second data to the user.

[0079] In the above embodiments, "acquisition and transmission unit 11" is an example equivalent to "processing unit", "receive and accumulation unit 21" is an example equivalent to "extraction unit", and "query processing unit 22" is an example equivalent to "providing unit".

[0080] In this vehicle data management system, the index data may also include first information related to the start and end times of the first data and second information related to the start and end times of the second data.

[0081] In this vehicle data management system, the processing unit may set a first timing and a second timing, wherein the first timing is based on the timing of sending the first data to the server during the first specified period, and the second timing is based on the timing of sending the second data to the server during the second specified period. The timing at which the integrated data is sent to the server is the earlier of the first timing and the second timing.

[0082] This invention is not limited to the embodiments described above. Modifications may be made without departing from the spirit or spirit of the invention as read in its entirety from the claims and description. Vehicle data management systems that are modified in this way are also included within the scope of this invention.

Claims

1. A vehicle data management system, wherein data acquired from the vehicle is managed on a server external to the vehicle, wherein, The vehicle includes a processing unit, which is configured to: Events are identified by detecting data with a defined pattern from multiple time series data corresponding to multiple sensors. In the case of detecting a first event and a second event from the multiple time series data, first data is obtained from the time series data in which the first event was detected as data including a first predetermined period of the first event, and second data is obtained from the time series data in which the second event was detected as data including a second predetermined period of the second event; If the category of the time series data of the first event is found to be the same as the category of the time series data of the second event, and at least a portion of the first specified period is found to be the same as the second specified period, the first data and the second data are integrated to generate integrated data. as well as The integrated data and the index data associated with the integrated data are sent to the server. The server has the following features: The extraction unit, immediately after receiving the integrated data and the index data, or in the event of a request from a user, extracts the first data and the second data from the integrated data based on the index data; as well as The providing unit provides the first data and the second data to the user.

2. The vehicle data management system according to claim 1, wherein, The index data includes first information related to the start and end times of the first data and second information related to the start and end times of the second data.

3. The vehicle data management system according to claim 1, wherein, The processing unit sets a first timing and a second timing, wherein the first timing is based on the timing of sending the first data to the server during the first specified period, and the second timing is based on the timing of sending the second data to the server during the second specified period. The timing at which the integrated data is sent to the server is the earlier of the first and second timings.

Images