Vehicle history data collaborative acquisition method and system

Abstract

The application provides a vehicle history data cooperative acquisition method and system, the method comprises the following steps: a vehicle terminal pushes running data to an original database in real time; multi-dimensional time sequence features are extracted before leaving the warehouse to predict activity level, and the activity level is divided into grades and a pre-push priority score is calculated; differential leaving treatment is performed according to the grades, data encapsulation is sliced and written into a file server; high-priority documents are actively pushed to edge cache nodes during low-load periods based on the priority score; after the platform checks a request, the request is written into an asynchronous task queue, an archiving task is triggered, and when a differential package is included, the most recent complete package is used as a baseline to apply differential chain replay and restoration; the consumption end downloads slices based on a one-time download voucher, and the optimal slice size and concurrency are dynamically calculated based on the modeling of network quality of the special line log. The method realizes differential processing and pre-push through accurate prediction of activity, reduces storage overhead through semantic differential coding, and improves data transfer timeliness and resource utilization efficiency.

Description

Technical Field

[0001] This invention relates to the field of vehicle network data processing technology, and in particular to a method and system for collaborative acquisition of vehicle historical data. Background Technology

[0002] With the widespread adoption of intelligent connected vehicles, in-vehicle terminals continuously generate massive amounts of vehicle operation data at high frequencies, including GPS trajectories, CAN bus signals, and fault codes. This data converges in the automaker's raw data library, forming a high-concurrency, high-volume raw data lake. Self-built cloud platforms, acting as third-party data consumption platforms, need to periodically or on-demand acquire this historical vehicle data to support business decisions. Currently, automaker data platforms typically perform unified offline ETL processing on all vehicles at fixed intervals and store the processed data in a full-archive format on file servers for consumers to download on demand. However, this approach faces challenges in real-world scenarios with significant differences in vehicle activity levels, uneven data change frequencies, and fluctuating dedicated network quality, including processing strategy mismatch, storage and transmission redundancy, and low bandwidth utilization.

[0003] Existing methods for cross-platform transfer of vehicle historical data lack the ability to perceive and predict the individual operating patterns of vehicles. They typically employ fixed-cycle offline processing and full archiving of all vehicles without differentiation, failing to dynamically adjust data processing strategies based on the actual activity levels of vehicles. This results in processing delays for frequently operating vehicles due to fixed-cycle limitations, failing to meet the rapid response requirements of time-sensitive services such as fault diagnosis. Meanwhile, a large number of vehicles that are stationary for extended periods or operate infrequently are still triggered to complete ETL calculations and archiving processes, leading to ineffective consumption of computing resources and storage space. Summary of the Invention

[0004] In view of this, the present invention proposes a collaborative acquisition method and system for vehicle historical data. By accurately predicting vehicle activity, it achieves differentiated data processing and pre-push decision-making, reduces storage and transmission overhead by combining semantic differential coding, and improves transmission efficiency by utilizing network adaptive fragmented download. This improves the timeliness and resource utilization efficiency of vehicle historical data flow between car manufacturers and self-built clouds.

[0005] The technical solution of the present invention is implemented as follows: In a first aspect, the present invention provides a method for collaborative acquisition of vehicle historical data, comprising the following steps: S1, the vehicle terminal pushes vehicle operation data to the original database in real time at a preset cycle; S2, before triggering the outbound processing on each natural day, extract the multi-dimensional temporal features of each vehicle identification number from the original database, predict the probability distribution of the activity level of each vehicle identification number in the future time window based on the multi-dimensional temporal features, divide the vehicles into the first active level, the second dormant level and the third silent level according to the probability distribution, and calculate the pre-push priority score of each vehicle identification number. S3, at the end of each natural day, performs the corresponding offline outbound processing according to the vehicle classification level, and encapsulates the processed standard data into a preset document format and writes it to the file server in segments; S4, based on pre-push priority scoring, actively pushes the archived documents of high-priority vehicles to the edge cache node on the consumer side during the low load period of the dedicated line. When the consumer initiates a request, it first queries the local edge cache. If the cache is not hit, it initiates a data request to the vehicle manufacturer's data platform. S5, the car manufacturer's data platform performs permission verification on data requests. After the verification is successful, the request is written to the asynchronous task queue and a globally unique task identifier is generated. S6, the vehicle enterprise data platform queries or triggers archiving tasks based on task identifiers. If the requested data date range contains differential packages, the platform uses the most recent complete package as the baseline to replay and restore the complete data of the target date by applying each differential package on the differential chain in sequence. After archiving is completed, an asynchronous notification message is pushed to the consumer. S7: The consumer initiates segmented downloads to the file server based on a one-time download credential. It models network quality in real time based on historical leased line transmission logs, dynamically calculates the optimal segment size and the number of concurrent download threads, and performs breakpoint resume and integrity verification. S8, on the consumer side, performs time-series analysis on the restored vehicle historical data, extracts the data subset of the latest natural day and displays it for operators to view on the terminal.

[0006] Based on the above technical solutions, preferably, step S1 includes the following steps: S11, the vehicle terminal collects vehicle operation data at fixed intervals, and the vehicle operation data includes at least global positioning system coordinates, controller area network bus signals, fault codes and sensor status; S12, the vehicle terminal reports the collected data to the vehicle manufacturer's original database. The original database uses a message bus to partition the data by vehicle identification number and writes it into a time-series data table, which is stored in the form of raw byte stream.

[0007] Based on the above technical solutions, preferably, step S2 includes the following sub-steps: S21. Before triggering the outbound processing on each natural day, extract the multi-dimensional temporal features of each vehicle identification number from the original database. The multi-dimensional temporal features include at least the last reported time of the vehicle, the historical driving time sequence, the driving mileage sequence, the data change frequency sequence, the fault occurrence frequency sequence, the vehicle type and usage scenario label. S22, a vehicle activity prediction model is constructed based on multi-dimensional time-series features. The multi-dimensional time-series feature vector up to the current moment is used as input. After extracting the statistical features, trend features and periodic features of the time series through the feature mapping function, the probability value of each vehicle identification code belonging to the first active level, the second dormant level or the third silent level in the future time window is output. The sum of the three probability values ​​is 1. S23, vehicles whose predicted first active level probability is greater than the first preset threshold are classified as first active level, vehicles whose predicted first active level probability is between the second preset threshold and the first preset threshold are classified as second dormant level, and vehicles whose predicted first active level probability is lower than the second preset threshold are classified as third silent level. S24. Count the number of times the vehicle identification number is requested by the consumer within a historical preset period, divide the number by the total number of times all vehicles are requested within the period, and obtain the historical request frequency of the vehicle. S25, obtain the set of vehicles recently requested by the consumer, calculate the similarity between the current vehicle identification number and each vehicle in the vehicle set in three dimensions: vehicle type, usage scenario and geographical location, and take the average of the weighted sum of the similarity in the three dimensions to obtain the comprehensive similarity between the current vehicle and the recently requested vehicles. S26. The probability value of the vehicle identification number belonging to the first active level in the future time window, the historical request frequency of the vehicle, and the comprehensive similarity between the current vehicle and the recently requested vehicle are weighted and summed to obtain the pre-push priority score of each vehicle identification number.

[0008] Based on the above technical solutions, preferably, step S3 includes the following sub-steps: S31, after the end of each natural day, the offline outbound computing node extracts all the cumulative raw data up to the previous natural day from the original database, performs offline batch processing, and obtains standard data; S32, for the first active level vehicle, output a complete archive package according to the standard data, encapsulate it into a preset document format using compression encoding, and divide it into multiple fragment files according to a preset threshold and write them to the file server. S33, for the second hibernation level vehicle, the semantic differential encoder performs differential semantic differential encoding on the standard data of two consecutive days. By comparing the standard data of the current day with the standard data of the previous day, the difference is calculated to generate a differential packet. The semantic differential encoding includes trajectory point spatial hash differential encoding, controller area network bus signal numerical differential encoding, and fault code set differential encoding. S34, Write the differential packet to the file server, and associate the differential packet with the preceding complete packet or differential packet through the differential chain pointer in the index file. The differential chain pointer includes the most recent complete archive packet, a differential entry list, and the total length of the differential chain. Each entry in the differential entry list contains the date, differential type, reference packet identifier, and differential packet binary data. S35, for vehicles in the third silent level, skip the offline outbound processing and mark the data for that natural day as missing in the index file; S36, Generate an index file, which includes fragment metadata, vehicle identification number mapping, data start and end timestamps, and checksums.

[0009] Based on the above technical solutions, preferably, the semantic differential encoding in step S33 includes trajectory point spatial hash differential encoding, controller area network bus signal numerical differential encoding, and fault code set differential encoding, wherein, The spatial hash differential encoding of trajectory points is to align the GPS trajectory points of two consecutive days by time, calculate the spatial offset of each trajectory point with the corresponding trajectory point of the previous day, record only the offset code for trajectory points with spatial offset less than a preset distance threshold, and record the complete GPS coordinates for trajectory points with spatial offset greater than or equal to the preset distance threshold. The differential encoding of controller area network bus signals calculates the numerical deviation of each signal field for controller area network bus signal data over two consecutive days. For signals with deviation values ​​within the preset normal fluctuation range, the deviation code is recorded and represented by variable-length integer encoding. For signals with deviation values ​​exceeding the normal fluctuation range, the complete signal value and anomaly mark are recorded. For signals with consistent trends over multiple consecutive days, second-order differential encoding is used. The fault code set differential encoding represents the fault code set as an ordered list. The differential result includes a list of newly added fault codes, a list of disappeared fault codes, and a list of persistent fault codes. The persistent fault codes only record the fault code identifier and the number of days they last.

[0010] Based on the above technical solutions, preferably, step S4 includes the following sub-steps: S41, the vehicle manufacturer's data platform monitors the transmission load in real time, and triggers a pre-push window when the transmission bandwidth utilization rate is lower than a preset threshold. S42, within the pre-push window, push the archived documents of vehicles with a pre-push priority score higher than the preset push threshold from the file server to the edge cache node on the consumer side; S43, the edge cache node records the last K access times of each cache item. When the cache space is insufficient and needs to be evicted, the cache item with the earliest last K access time is removed first. S44, the cache window length is adaptively adjusted according to the vehicle activity level. The first active level is the first preset number of days, the second dormant level is the second preset number of days, and the third silent level does not perform pre-push. When the cache space reaches the preset limit, the cache items are sorted according to the vehicle activity level corresponding to each cache item. The cache items of the first active level vehicles have a higher retention priority than the second dormant level, and the second dormant level has a higher priority than the third silent level. S45: When a consumer initiates a data request, it first queries the local edge cache. If the cache is found, it returns the cached data directly. If the cache is not found, it sends a data request to the car manufacturer's data platform.

[0011] Based on the above technical solutions, preferably, step S6 includes the following sub-steps: S61, the vehicle enterprise data platform queries the status of the corresponding archive task based on the task identifier. If the archive task corresponding to the task identifier has not been completed, the archive task is triggered to execute. If the requested data date range contains differential packets, the most recent complete archive packet before that date is used as the baseline. The differential packets in the differential chain are applied sequentially in chronological order to perform inverse differential decoding on the trajectory points, controller area network bus signals and fault codes respectively, restore the differential data in the differential packets to complete data, and generate a complete data packet for the target date. S62, after the archiving task is completed, an asynchronous notification message is pushed to the consumer through the message queue. The notification message includes at least the task identifier, archiving completion status, index file download address and one-time download certificate. If the notification push fails, it is retried according to the exponential backoff strategy, and the backoff interval increases with the number of retries.

[0012] Based on the above technical solutions, preferably, step S7 includes the following sub-steps: S71: The consumer initiates a segmented download request to the file server based on a one-time download credential. S72, the network adaptive fragmentation scheduler constructs a network quality prediction model based on historical leased line transmission logs. The prediction model predicts the bandwidth value at future times based on the bandwidth value at historical times, so as to capture the daily and weekly cycle change patterns of network bandwidth and output the predicted network bandwidth value at future times. S73, based on the network predicted bandwidth value and the latency requirement of the current transmission task, calculate the optimal fragment size and the number of concurrent download threads. The optimal fragment size is equal to the quotient obtained by multiplying the network predicted bandwidth value by the latency requirement and then dividing by the baseline concurrency, and the quotient is limited between the preset minimum fragment size and the maximum fragment size. The optimal number of concurrent download threads is equal to the quotient obtained by dividing the predicted bandwidth by the bandwidth utilization threshold of a single thread and rounding down, and the rounded result is limited between the preset minimum number of concurrent threads and the maximum number of concurrent threads. S74, multiple download requests enter a priority scheduling queue, and bandwidth resources are allocated sequentially after being weighted and sorted according to the urgency of the business and the waiting time of the request. The urgency of the business is divided into fault analysis taking priority over trajectory playback, and trajectory playback taking priority over statistical reports. S75: When the download is interrupted, a resume request is initiated based on the offset of the downloaded data, and only the unfinished segments are retransmitted. S76. After each segment is downloaded, a checksum comparison is performed. The checksum of each segment is calculated and compared with the checksum recorded in the index file. After all segments pass the checksum, decompression and data restoration are performed.

[0013] Secondly, the present invention also provides a vehicle historical data collaborative acquisition system, implemented using a vehicle historical data collaborative acquisition method and system, including: The data acquisition module is used by the vehicle terminal to push vehicle operation data to the raw database in real time at a preset period. The activity assessment module is used to extract multi-dimensional temporal features of each vehicle identification number from the original database before triggering outbound processing on each natural day. Based on the multi-dimensional temporal features, it predicts the probability distribution of the activity level of each vehicle identification number in the future time window. According to the probability distribution, the vehicles are divided into the first active level, the second dormant level, and the third silent level, and the pre-push priority score of each vehicle identification number is calculated. The outbound processing module is used to perform corresponding offline outbound processing according to the vehicle classification level at the end of each natural day, and to encapsulate the processed standard data into a preset document format and write it to the file server in segments. The edge caching module is used to proactively push archived documents of high-priority vehicles to the edge caching nodes on the consumer side during periods of low load on the dedicated line, based on pre-push priority scoring. When the consumer initiates a request, it first queries the local edge cache, and if the cache is not hit, it initiates a data request to the vehicle manufacturer's data platform. The request scheduling module is used by the car manufacturer's data platform to perform permission verification on data requests. After the verification is successful, the request is written to the asynchronous task queue and a globally unique task identifier is generated. The archiving and replay module is used by the car manufacturer's data platform to query or trigger archiving tasks based on task identifiers. If the requested data date range contains differential packets, the module uses the most recent complete packet as the baseline and applies each differential packet on the differential chain in sequence to replay and restore the complete data of the target date. After archiving is completed, an asynchronous notification message is pushed to the consumer. The adaptive download module is used by the consumer to initiate segmented downloads to the file server based on a one-time download credential. It models network quality in real time based on historical leased line transmission logs, dynamically calculates the optimal segment size and the number of concurrent download threads, and performs breakpoint resume and integrity verification. The data display module is used by the consumer to perform time-series analysis on the restored vehicle historical data, extract the data subset of the latest natural day for display on the terminal for operators to view.

[0014] Thirdly, the present invention also provides a computer-readable storage medium storing a method and system program for collaborative acquisition of vehicle historical data, wherein the method is implemented when the program for collaborative acquisition of vehicle historical data is executed.

[0015] The vehicle historical data collaborative acquisition method and system of the present invention have the following advantages over the prior art: (1) By using multi-dimensional time-series features to drive activity prediction, vehicle classification and pre-push priority scoring are achieved, enabling cache resources to be accurately allocated to vehicle data with high request probability in advance. On this basis, combined with differentiated outbound processing executed according to activity level and proactive pre-push during low-load periods, synchronous requests during peak periods are transformed into asynchronous preloading during off-peak periods. With the help of sharded storage and asynchronous task queue mechanism, an end-to-end efficient flow link from data perception, cache pre-setting to on-demand acquisition is constructed, which improves the timeliness and resource utilization efficiency of vehicle historical data flow between car companies and self-built cloud. (2) By extracting multi-dimensional time-series features covering the last reporting time of the vehicle, historical driving time and mileage sequence, data change and fault frequency, vehicle type and usage scenario, an activity prediction model is constructed to accurately output the probability that each vehicle belongs to the first active level in the future time window. At the same time, the pre-push priority score is calculated by integrating the historical request frequency and the comprehensive similarity with the recently requested vehicle, so that cache resources can be accurately allocated to vehicle data with high request probability in advance, providing accurate classification basis and priority ranking for subsequent differentiated outbound processing and proactive pre-push. (3) By constructing an autoregressive prediction model based on historical leased line transmission logs, the daily and weekly variation patterns of network bandwidth are captured and the predicted bandwidth values ​​for future times are output. Based on this, the optimal fragment size and the number of concurrent download threads are dynamically calculated, enabling the transmission strategy to adapt to the time-varying characteristics of leased line network quality. Combined with multi-request priority scheduling, breakpoint resume and fragment verification mechanisms, the end-to-end transmission guarantee from network awareness and parameter optimization to integrity verification is realized, improving the reliability and bandwidth utilization of leased line transmission. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart of the vehicle historical data collaborative acquisition method of the present invention. Detailed Implementation

[0018] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0019] like Figure 1 As shown, in a first aspect, a method for collaboratively acquiring vehicle historical data according to the present invention includes the following steps: S1, the vehicle terminal pushes vehicle operation data to the original database in real time at a preset cycle; Step S1 includes the following steps: S11, the vehicle terminal collects vehicle operation data at fixed intervals, and the vehicle operation data includes at least global positioning system coordinates, controller area network bus signals, fault codes and sensor status; Specifically, in this embodiment, the acquisition cycle is set to 10 seconds / frame, which can be adjusted according to vehicle model and business needs, typically ranging from 5 to 30 seconds; the GPS coordinates include longitude and latitude values, used to record the vehicle's real-time location information; the controller area network bus signals include, but are not limited to, powertrain and body control signals such as vehicle speed, engine speed, battery voltage, throttle opening, and braking status; the fault codes conform to the OBD-II (On-Board Diagnostics) or UDS (Unified Diagnostic Service) standard format, used to identify abnormal states of various electronic control units in the vehicle; sensor status data includes tire pressure monitoring values, temperature readings, accelerometer triaxial data, and other vehicle body perception information; the on-board terminal encapsulates the collected data into data frames according to a preset protocol format, each frame containing the vehicle identification number, acquisition timestamp, and the actual values ​​of the aforementioned signals, ensuring data temporal consistency and traceability.

[0020] S12, the vehicle terminal reports the collected data to the vehicle manufacturer's original database. The original database uses a message bus to partition the data by vehicle identification number and writes it into a time-series data table, which is stored in the form of raw byte stream.

[0021] Specifically, the vehicle-mounted terminal establishes an encrypted transmission channel with the cloud via a fourth- or fifth-generation mobile communication network. It then uses Message Queuing Telemetry Transport Protocol (MQTT over TLS) or Hypertext Transfer Security Protocol (HTTPS) to report encapsulated data frames to the vehicle manufacturer's original database. During the reporting process, the TLS / SSL encrypted channel ensures the confidentiality and integrity of data transmission, preventing data theft or tampering during transmission. The vehicle manufacturer's original database uses a message bus architecture as the data access layer. The message bus performs hash partitioning based on the vehicle identification number (VIN), routing data for the same vehicle to the same partition to ensure the temporal order of the vehicle's data. The data is then written to the time-series data table using a combination of vehicle identification number and timestamp. The original database stores the data as a raw byte stream without performing real-time cleaning, verification, deduplication, or structured parsing. This means that outlier detection and correction, schema verification, data format conversion, and discarding of any original messages are not performed. This storage method avoids real-time data processing becoming a bottleneck for writing, ensuring write throughput in scenarios with high-frequency data reporting at the 10-second level. In addition, it preserves the integrity and authenticity of the original data, ensuring that subsequent offline batch processing can be executed based on the untampered original data source, guaranteeing the controllability of data quality and the traceability of the processing process.

[0022] S2, before triggering outbound processing on each natural day, extracts multi-dimensional temporal features of each vehicle identification number from the original database, predicts the probability distribution of the activity level of each vehicle identification number in the future time window based on the multi-dimensional temporal features, divides the vehicles into the first active level, the second dormant level and the third silent level according to the probability distribution, and calculates the pre-push priority score of each vehicle identification number.

[0023] Step S2 includes the following sub-steps: S21. Before triggering the outbound processing on each natural day, extract the multi-dimensional temporal features of each vehicle identification number from the original database. The multi-dimensional temporal features include at least the last reported time of the vehicle, the historical driving time sequence, the driving mileage sequence, the data change frequency sequence, the fault occurrence frequency sequence, the vehicle type and usage scenario label. Before the outbound processing is triggered on each natural day in this step, the activity assessment module extracts multi-dimensional temporal features of each vehicle identification number from the original database. These multi-dimensional temporal features are used to characterize the historical operating patterns and behavior patterns of the vehicles, providing a data foundation for subsequent activity prediction.

[0024] Specifically, the vehicle's last reported time reflects the activity level of its communication with the cloud. The closer the last reported time is to the current time, the more likely the vehicle is in an active state; conversely, it may be in a dormant or silent state. The historical driving time sequence records the vehicle's cumulative daily driving time over the past several calendar days. This sequence reflects the vehicle's usage patterns, such as whether it is driven at fixed times each day or whether there are periodic usage patterns. The mileage sequence records the vehicle's cumulative daily mileage over the past several calendar days. This sequence corroborates the driving time sequence, jointly reflecting the vehicle's usage intensity. The data change frequency sequence records the frequency of changes in various operating data over the past several calendar days. This sequence reflects the stability of the vehicle's operating status. A high data change frequency indicates that the vehicle is in a dynamic operating state, while a low change frequency indicates that the vehicle is stationary or parked with the engine off. The fault occurrence frequency sequence records the number of new fault codes added to the vehicle over the past several calendar days. This sequence reflects the vehicle's health status; vehicles with frequent new fault codes are more likely to be requested for fault analysis by consumers. Vehicle type is the vehicle model classification code, used to distinguish the differences in usage scenarios of different vehicle models; usage scenario label is the vehicle's business purpose label, used to distinguish the differences in driving patterns under different usage scenarios.

[0025] The aforementioned multidimensional time-series features characterize the vehicle's operational behavior from both time and attribute dimensions, providing sufficient data input for subsequent activity prediction models.

[0026] S22, a vehicle activity prediction model is constructed based on multi-dimensional time-series features. The multi-dimensional time-series feature vector up to the current moment is used as input. After extracting the statistical features, trend features and periodic features of the time series through the feature mapping function, the probability value of each vehicle identification code belonging to the first active level, the second dormant level or the third silent level in the future time window is output. The sum of the three probability values ​​is 1. This step involves building a vehicle activity prediction model to predict the activity level of vehicles within a future time window.

[0027] Specifically, using the multi-dimensional time-series feature vector up to the current moment as the model input, the model first preprocesses the input features, normalizes the numerical features, and encodes the categorical features one-hot to form a feature tensor of uniform dimension.

[0028] Subsequently, the model extracts statistical, trend, and periodic features of the time series using a feature mapping function. Statistical features include the mean, variance, maximum, minimum, and quantiles of historical driving time and mileage, used to characterize the average behavior pattern and fluctuation range of vehicles; trend features are obtained by calculating the slope of the linear regression of the time series, reflecting the direction of change in vehicle usage intensity over time; periodic features are obtained by calculating the autocorrelation coefficient and spectral analysis of the time series, used to capture the daily and weekly periodic patterns of vehicles.

[0029] The feature vector output by the feature mapping function enters the classification layer. After being normalized by the Softmax function, it outputs the probability that the vehicle belongs to each activity level within a future time window. The calculation formula of the prediction model is: ; In the formula, For the vehicle in the next cycle t +1 belongs to the first i The probability value for each activity level. L t+1 The activity level for the next cycle and L t+1 ∈{L1,L2,L3}, L 1 Representing the first level of activity, L 2 Represents the second hibernation level. L 3 Represents the third level of silence; X t As of the current moment t Multidimensional temporal feature vectors; This is a feature mapping function used to extract statistical, trend, and periodic features of time series data. w i For the firsti The weight vector corresponding to each activity level; exp(.) is the natural exponential function; the denominator is the sum of the exponential values ​​of the three levels, which is used to normalize the output into a probability distribution so that the sum of the probability values ​​of the three levels is 1.

[0030] In this embodiment, the three probability values ​​correspond to the probability that the vehicle belongs to the first active level, the second dormant level, or the third silent level, respectively. The length of the future time window is a preset value that can be adjusted according to business needs. The activity prediction model can be implemented using algorithms such as multi-class logistic regression, gradient boosting decision tree, or deep neural network. The model parameters are obtained by training with historical data.

[0031] S23, vehicles whose predicted first active level probability is greater than the first preset threshold are classified as first active level, vehicles whose predicted first active level probability is between the second preset threshold and the first preset threshold are classified as second dormant level, and vehicles whose predicted first active level probability is lower than the second preset threshold are classified as third silent level. It should be noted that the first level of active vehicles are highly active vehicles, which have the highest probability of being requested for data by consumers in the future, and should be given priority in pre-push; the second level of dormant vehicles are moderately active vehicles, which have a moderate probability of being requested for data in the future, and can be stored using differential archiving to reduce storage costs; the third level of silent vehicles are low-active vehicles, which have the lowest probability of being requested for data in the future, and can skip archiving processing at the storage level to save storage space. The division into three levels realizes the differentiated allocation of computing and storage resources, effectively avoiding the resource waste caused by fixed-period processing strategies.

[0032] S24. Count the number of times the vehicle identification number is requested by the consumer within a historical preset period, divide the number by the total number of times all vehicles are requested within the period, and obtain the historical request frequency of the vehicle. Specifically, the system counts the number of times each vehicle identification number (VIN) is requested by the consumer within a preset historical period, which is a number of past calendar days. Each time the consumer sends a data request to the vehicle manufacturer's data platform, the request message carries the target VIN. The system records the time of the request, the target VIN, and the request type. After the statistical period ends, the number of requests for each vehicle is divided by the total number of requests for all vehicles within that period to obtain the normalized historical request frequency.

[0033] S25, obtain the set of vehicles recently requested by the consumer, calculate the similarity between the current vehicle identification number and each vehicle in the vehicle set in three dimensions: vehicle type, usage scenario and geographical location, and take the average of the weighted sum of the similarity in the three dimensions to obtain the comprehensive similarity between the current vehicle and the recently requested vehicles. It should be noted that vehicle type similarity is calculated based on the hierarchical matching degree of vehicle model classification codes. The vehicle model classification codes adopt a hierarchical structure, with the first layer representing the vehicle category, the second layer representing the sub-level, and the third layer representing the specific model. The similarity is calculated by dividing the number of matching layers of the same level code by the total number of layers. Usage scenario similarity is calculated based on the semantic distance of vehicle usage scenario tags. Usage scenario tags include categories such as official vehicles, business receptions, logistics transportation, personal transportation, and rental vehicles. The semantic distance is pre-set based on the semantic association degree between tags, and the usage scenario similarity equals 1 minus the normalized semantic distance. Geographical location similarity is calculated based on the latitude and longitude distance of the vehicle's permanent location area. The closer the distance between the center points of the two vehicles' permanent location areas, the higher the geographic location similarity, which equals 1 minus the normalized latitude and longitude distance. After obtaining the similarity in the three dimensions, the three similarities are multiplied by the corresponding dimension weight coefficient, weighted and summed, and then the average value is taken.

[0034] S26. The probability value of the vehicle identification number belonging to the first active level in the future time window, the historical request frequency of the vehicle, and the comprehensive similarity between the current vehicle and the recently requested vehicle are weighted and summed to obtain the pre-push priority score of each vehicle identification number.

[0035] This embodiment extracts multi-dimensional time-series features from the original database, including the vehicle's last reported time, historical driving duration sequence, mileage sequence, data change frequency sequence, fault occurrence frequency sequence, vehicle type, and usage scenario tags. It then constructs a vehicle activity prediction model and outputs the precise probability that each vehicle belongs to the first active level within a future time window. Simultaneously, it integrates two auxiliary factors: the vehicle's historical request frequency and its comprehensive similarity to recently requested vehicles, and calculates a weighted pre-push priority score. This upgrades the model from a fixed-period, coarse-grained activity assessment to a data-driven, refined probability prediction. This allows cached resources to be accurately allocated in advance to vehicle data with high request probabilities, effectively avoiding the dual dilemma of untimely processing of active vehicles and invalid calculations for inactive vehicles caused by fixed-period processing strategies. This provides a precise grading basis and priority ranking for subsequent differentiated outbound processing and proactive pre-push.

[0036] S3, at the end of each natural day, performs the corresponding offline outbound processing according to the vehicle classification level, and encapsulates the processed standard data into a preset document format and writes it to the file server in segments.

[0037] Step S3 includes the following sub-steps: S31. At the end of each natural day, the offline outbound computing node extracts all the accumulated raw data up to and before the previous natural day from the original database, performs offline batch processing, and obtains standard data.

[0038] In this step, after the end of each natural day, the offline outbound computing node extracts all accumulated raw data up to and before the previous natural day from the original database in batches and performs offline batch processing.

[0039] Specifically, offline batch processing includes the following operations: data cleaning, which removes invalid data frames caused by sensor malfunctions or communication anomalies, corrects outliers, and fills in missing fields; deduplication, which thins out high-frequency trajectory points according to time windows, retaining only the first and last points for redundant trajectory points that are continuously reported within a short period of time and whose position changes are less than a preset threshold, in order to reduce the amount of data; association, which uses the vehicle identification number as the primary key to perform left association of multi-source data of the same vehicle according to timestamps, generating a wide table containing all fields for subsequent unified processing; and summarization, which calculates various aggregated indicators according to natural days, including the total mileage, average speed, maximum speed, number of fault codes and their type distribution, etc.

[0040] After processing, standard data is obtained; the standard data is standardized structured data after cleaning, deduplication, association and summarization. All data is organized according to vehicle identification number and date, with unified field definitions and consistent format, and can be directly used for subsequent archiving and encapsulation or differential encoding processing.

[0041] S32, for the first active level vehicle, output a complete archive package according to the standard data, encapsulate it into a preset document format using compression encoding, and divide it into multiple fragment files according to a preset threshold and write them to the file server. Specifically, the complete archive package is compressed using Snappy compression encoding to reduce storage space usage and transmission bandwidth consumption; the compressed data is encapsulated in a preset document format, which is either Apache Parquet or JSON Lines format; Parquet is a columnar storage format that supports efficient compression encoding and predicate pushdown, making it suitable for large-scale data analysis scenarios; JSON Lines is a line-based text format with one JSON object per line, offering good readability and cross-platform compatibility.

[0042] After encapsulation, the file is divided into multiple fragments according to a preset threshold and written to the file server. A typical preset threshold is 64MB, which balances the file server's I / O performance with the granularity of resuming interrupted downloads over the network. Each fragment has a unique identifier (UUID), an offset (relative to the starting byte position of the complete archive), and a checksum (MD5). The unique identifier is used for fragment management and indexing, the offset supports resuming interrupted downloads and range downloads, and the checksum is used for integrity verification after download completion.

[0043] S33, for the second hibernation level vehicle, the semantic differential encoder performs differential semantic differential encoding on the standard data of two consecutive days. By comparing the standard data of the current day with the standard data of the previous day, the difference is calculated to generate a differential packet. The semantic differential encoding includes trajectory point spatial hash differential encoding, controller area network bus signal numerical differential encoding, and fault code set differential encoding. The differential packet only contains the differential data and does not contain duplicate data, so as to significantly reduce storage and transmission overhead.

[0044] The semantic differential coding in step S33 includes trajectory point spatial hash differential coding, controller area network bus signal numerical differential coding, and fault code set differential coding, wherein, The spatial hash differential encoding of trajectory points is to align the GPS trajectory points of two consecutive days by time, calculate the spatial offset of each trajectory point with the corresponding trajectory point of the previous day, record only the offset code for trajectory points with spatial offset less than a preset distance threshold, and record the complete GPS coordinates for trajectory points with spatial offset greater than or equal to the preset distance threshold. Align the GPS track points for two consecutive days by time, calculate the spatial offset of each track point from the corresponding track point of the previous day, and if the timestamps of the track points of the two days are not aligned, use linear interpolation to align them and then calculate the difference.

[0045] For any trajectory point, the formula for calculating its spatial offset is: ; In the formula, For the tth day i GPS coordinates at each moment, ΔGPS i The spatial offset between the two is used. If the timestamps of the two trajectory points are not aligned, a linear interpolation method is used to interpolate the two trajectory points to a unified time series before calculating the difference.

[0046] For trajectory points with spatial offsets less than a preset distance threshold, only the offset code is recorded; for trajectory points with spatial offsets greater than or equal to the preset distance threshold, the complete GPS coordinates are recorded. This differential coding can reduce the storage space of trajectory point data.

[0047] The differential encoding of controller area network bus signals calculates the numerical deviation of each signal field for controller area network bus signal data over two consecutive days. For signals with deviation values ​​within the preset normal fluctuation range, the deviation code is recorded and represented by variable-length integer encoding. For signals with deviation values ​​exceeding the normal fluctuation range, the complete signal value and anomaly mark are recorded. For signals with consistent trends over multiple consecutive days, second-order differential encoding is used. It should be noted that for signals with deviation values ​​within the preset normal fluctuation range, the deviation code is recorded and represented using variable-length integer encoding. The smaller the deviation value, the fewer bits are used for encoding, in order to further compress storage space. For signals with deviation values ​​exceeding the normal fluctuation range, the complete signal value and anomaly marker are recorded so that abnormal changes can be identified during playback. For signals with consistent trends over multiple consecutive days, second-order differential encoding is used, that is, the rate of change of the first-order difference is recorded instead of the first-order difference itself, in order to further compress periodically changing data.

[0048] The fault code set differential encoding represents the fault code set as an ordered list. The differential result includes a list of newly added fault codes, a list of disappeared fault codes, and a list of persistent fault codes. The persistent fault codes only record the fault code identifier and the number of days they last.

[0049] It should be noted that the newly added fault code list records fault code identifiers that were added on the current day and did not exist on the previous day; the disappeared fault code list records fault code identifiers that existed on the previous day but disappeared on the current day; the persistent fault code list records fault codes that existed on both days, only recording the fault code identifier and the number of days of persistence. For newly added fault codes, the differential data records the complete fault code information; for persistent fault codes, only the fault code identifier and the number of days of persistence are recorded, and the complete fault description information is not recorded again.

[0050] S34, Write the differential packet to the file server, and associate the differential packet with the preceding complete packet or differential packet through the differential chain pointer in the index file. The differential chain pointer includes the most recent complete archive packet, a differential entry list, and the total length of the differential chain. Each entry in the differential entry list contains the date, differential type, reference packet identifier, and differential packet binary data. Specifically, the differential packets are written to the file server in the same way as the full archive packets, to ensure unified management of all data in the file server. At the same time, the differential packets are associated with the preceding full packets or differential packets through the differential chain pointers in the index file to form a chain data structure, which avoids the redundant overhead of daily full storage and ensures the integrity and recoverability of data on any date.

[0051] S35, for vehicles in the third silent level, skip the offline outbound processing and mark the data for that natural day as missing in the index file; Specifically, for vehicles in the third silent level, since the probability of them being requested within the future time window is extremely low and the data volume changes very little, the system skips offline outbound processing. That is, it does not generate an archive package or differential package for the vehicle within the current natural day's archiving cycle, nor does it perform any data cleaning or compression operations. At the same time, the system marks the data for the vehicle on that natural day as missing in the index file to clearly indicate that there is no available data on that date, distinguishing it from the state where the data exists but has not been archived. This marking uses a preset missing identifier in the index file, which makes it easy for consumers to quickly identify during queries.

[0052] S36, Generate an index file, which includes fragment metadata, vehicle identification number mapping, data start and end timestamps, and checksums.

[0053] This step generates an index file, which is a metadata file in JSON or binary format. Its purpose is to enable the consumer to locate the target data fragment, initiate fragment download, and perform integrity verification based on the index file.

[0054] The index file contains the following: fragment metadata to support fragment-level location and download; vehicle identification number (VIN) mapping records of all VINs covered by the current index file and their corresponding data date ranges and fragment lists, to support fast retrieval by VIN; data start and end timestamps, recording the time span of the currently archived data, including the start and end dates, for time range verification and cropping; and checksums, the integrity checksums of the index file itself and the MD5 or SHA-256 checksums of the fragment files, for data integrity verification.

[0055] The index file and the archive / differential package are stored together on the file server. Before downloading data, the consumer first obtains the index file, parses the fragment metadata and checksum, and then initiates fragment download and performs integrity verification.

[0056] This embodiment performs differentiated offline outbound processing on vehicles in the first active level, the second dormant level, and the third silent level. This enables active vehicles to obtain the immediate availability of complete archive packages, while dormant vehicles store only changed data through three semantic differential encoding methods: trajectory point spatial hash differential, CAN signal value differential, and fault code set differential. This reduces storage and transmission overhead while ensuring complete data restoration. Silent vehicles skip processing to avoid invalid calculations. At the same time, differential packets are associated with preceding packets in a traceable chain structure through differential chain pointers. Combined with the fragmented metadata and checksums of the index file, this allows the consumer to accurately locate and restore complete data from any date as needed, achieving a balance between storage efficiency and data availability.

[0057] S4, based on pre-push priority scoring, proactively pushes archived documents of high-priority vehicles to the edge cache node on the consumer side during periods of low load on the dedicated line. When the consumer initiates a request, it first queries the local edge cache, and if the cache is not hit, it initiates a data request to the vehicle manufacturer's data platform.

[0058] Step S4 includes the following sub-steps: S41, the vehicle manufacturer's data platform monitors the transmission load in real time, and triggers a pre-push window when the transmission bandwidth utilization rate is lower than a preset threshold. In this step, the vehicle manufacturer's data platform monitors the transmission load of the dedicated line link in real time. The dedicated line link is a dedicated encrypted transmission channel between the vehicle manufacturer's data platform and the consumer end. The transmission load monitoring collects uplink bandwidth utilization data in real time through the dedicated line gateway or network monitoring system. The collection granularity is usually at the minute level to capture the real-time trend of network load changes.

[0059] The pre-push window is triggered when the transmission bandwidth utilization rate is lower than a preset threshold. The system determines that the leased line is under low load and has the network conditions to execute the pre-push task. This threshold setting ensures that pre-push does not interfere with normal business traffic transmission while fully utilizing the bandwidth margin during low-load periods for data transmission preprocessing. The duration of the pre-push window is dynamically determined based on real-time changes in the leased line load. Once the bandwidth utilization rate rises above the preset threshold, the pre-push window closes and reopens when the load decreases again. This mechanism effectively solves the problem of leased line bandwidth being idle during request intervals in the passive on-demand request mode.

[0060] S42, within the pre-push window, push the archived documents of vehicles with a pre-push priority score higher than the preset push threshold from the file server to the edge cache node on the consumer side; Specifically, within the pre-push window, the pre-push scheduler reads the pre-push priority score of each vehicle, selects the archived documents of vehicles with scores higher than the preset push threshold, and actively pushes them from the file server to the edge cache node on the consumer side.

[0061] The pre-push priority score reflects the probability that the vehicle will be requested for data by the consumer in the future. Vehicles with scores higher than the preset push threshold have the highest pre-push value. During the push process, the system pushes data in order from high to low according to the pre-push priority score, ensuring that the limited bandwidth during low-load periods is allocated to the vehicle data most likely to be requested. After the push is completed, the edge cache node records the metadata of the cached items for subsequent cache hit judgment.

[0062] S43, the edge cache node records the last K access times of each cache item. When the cache space is insufficient and needs to be evicted, the cache item with the earliest last K access time is removed first. Specifically, the edge cache nodes use an LRU-K cache eviction policy to manage cache space in order to improve cache hit rate. K is 2, which means that the system records the last K access times of each cache item.

[0063] When a new cached item is added to the cache space or an existing cached item is accessed, the edge cache node updates the access history of that cached item. When the cache space reaches a preset limit and a cached item needs to be evicted, the system calculates the Kth-th time from the end of the cached item's access time and prioritizes removing the cached item with the earliest Kth-th time from the end of the cache. A value of 2 for K can better identify long-term hot data compared to the traditional LRU, avoiding the situation where a cached item is retained due to an accidental access while frequently accessed data is wrongly evicted.

[0064] S44, the cache window length is adaptively adjusted according to the vehicle activity level. The first active level is the first preset number of days, the second dormant level is the second preset number of days, and the third silent level does not perform pre-push. When the cache space reaches the preset limit, the cache items are sorted according to the vehicle activity level corresponding to each cache item. The cache items of the first active level vehicles have a higher retention priority than the second dormant level, and the second dormant level has a higher priority than the third silent level. The cache window length represents the effective duration for which archived documents are retained in the edge cache node. Cache items exceeding the cache window length will be marked as expired and prioritized for eviction. The window length is adaptively adjusted according to the vehicle activity level: for the first active level vehicles, the cache window length is the first preset number of days, which is 7 days, because the archived documents of this level of vehicles are most likely to be requested and need to be retained for a longer time; for the second dormant level vehicles, the cache window length is the second preset number of days, which is 3 days; for the third silent level vehicles, no pre-push is performed, so there are no corresponding cached items in the edge cache node.

[0065] When the cache space reaches the preset limit, in addition to eviction according to the LRU-K policy, the system also sorts the evictions based on the vehicle activity level corresponding to each cache item. The cache items of the first active vehicle have a higher retention priority than the second dormant vehicle, and the second dormant vehicle has a higher retention priority than the third silent vehicle. This priority strategy, together with the cache window length, achieves the differentiated allocation of cache resources. The more active the vehicle, the higher the retention priority and the longer the retention time of its data in the cache.

[0066] S45: When a consumer initiates a data request, it first queries the local edge cache. If the cache is found, it returns the cached data directly. If the cache is not found, it sends a data request to the car manufacturer's data platform.

[0067] S5, the car manufacturer's data platform performs permission verification on data requests. After the verification is successful, the request is written to the asynchronous task queue and a globally unique task identifier is generated. The automotive data platform performs multi-level authentication and verification on vehicle historical data requests initiated by consumers to ensure the security and legitimacy of data access. Specifically, the verification process includes three layers: The first layer is transport layer security certificate verification, which verifies the identity of the channel from which the request originates, confirming that the request comes from a legitimate consumer. The second layer is temporary access token verification, which verifies the signature validity of the JWT format token, whether it is within its validity period, and whether the declared vehicle identification number (VIN) level permission scope covers the target vehicle, preventing token forgery, expiration, or unauthorized access. The third layer is request signature verification, which uses a public key to verify the digital signature of the request, verifying that the request message has not been tampered with during transmission, and also verifies the request timestamp to prevent replay attacks, i.e., rejecting duplicate requests that exceed a preset time window. After all three layers of verification pass, the system determines that the request is legitimate and valid. Subsequently, the automotive data platform writes the verified request into an asynchronous task queue, generates a globally unique task identifier, initializes the task status to pending, and returns a response containing the task identifier and releases the long connection, thereby decoupling the real-time query request from the backend archiving and download process. This asynchronous processing method avoids the input and output impact on the car manufacturer's original database caused by large-scale data queries, protects the stability of the core system, and also provides an identification basis for subsequent differentiated task scheduling and state tracking.

[0068] S6, the vehicle enterprise data platform queries or triggers archiving tasks based on task identifiers. If the requested data date range contains differential packages, the platform uses the most recent complete package as the baseline to replay and restore the complete data of the target date by applying each differential package on the differential chain in sequence. After archiving is completed, an asynchronous notification message is pushed to the consumer. Step S6 includes the following sub-steps: S61, the vehicle enterprise data platform queries the status of the corresponding archive task based on the task identifier. If the archive task corresponding to the task identifier has not been completed, the archive task is triggered to execute. If the requested data date range contains differential packets, the most recent complete archive packet before that date is used as the baseline. The differential packets in the differential chain are applied sequentially in chronological order to perform inverse differential decoding on the trajectory points, controller area network bus signals and fault codes respectively, restore the differential data in the differential packets to complete data, and generate a complete data packet for the target date. Specifically, in this step, the vehicle manufacturer's data platform queries the corresponding archiving task status based on the generated task identifier. The task state machine includes four states: pending, processing, completed, and failed. If the archiving task corresponding to the task identifier has not yet been completed, the archiving task execution is triggered. The execution process of the archiving task is divided into two cases: In the first scenario, the data within the requested date range has already been archived through previous offline outbound processing. In this case, the system directly reads the existing archive package or differential package from the file server and proceeds to the subsequent notification process.

[0069] In the second scenario, if the requested data date range includes differential packets, then differential chain replay restoration needs to be performed. The system uses the most recent complete archive before that date as the baseline and applies each differential packet in the differential chain sequentially in chronological order.

[0070] The specific process of differential chain replay restoration is as follows: First, locate the most recent complete archive package before the target date. Second, apply each differential package in the differential chain sequentially in chronological order; for each differential package, perform inverse differential decoding on the track points, CAN signals, and fault codes respectively; Track point inverse differential decoding: superimpose the offset code recorded in the differential package with the complete GPS coordinates restored from the previous day to recover the complete GPS track point for the current day; if a track point records complete coordinates instead of offsets, use the coordinate value directly; CAN signal inverse differential decoding: algebraically add the numerical deviation code recorded in the differential package with the complete signal value restored from the previous day to recover the complete signal value for the current day; for signals using second-order differential encoding, the first-order differential value needs to be recovered first before recovering the complete signal value; Fault code inverse differential decoding: based on the complete fault code set of the baseline date, apply the newly added fault code list, the disappeared fault code list, and the persistent fault code list to recover the complete fault code set for the current day.

[0071] After the inverse differential decoding in this embodiment is completed, the decoded data is subjected to consistency verification, including timestamp continuity verification and numerical range rationality verification. If the verification passes, a complete data package for the target date is generated. If the consistency verification fails, a full outbound process is triggered to regenerate a complete archive package to ensure data accuracy.

[0072] S62, after the archiving task is completed, an asynchronous notification message is pushed to the consumer through the message queue. The notification message includes at least the task identifier, archiving completion status, index file download address and one-time download certificate. If the notification push fails, it is retried according to the exponential backoff strategy, and the backoff interval increases with the number of retries.

[0073] After the archiving task is completed in this step, the vehicle manufacturer's data platform pushes an asynchronous notification message to the consumer via a message queue, notifying the consumer that the data is ready for download.

[0074] The notification message should include at least the following: task identifier, archiving completion status, index file download address, and one-time download certificate.

[0075] The notification push adopts a reliable message mechanism. When the push fails, the system will automatically retry according to the exponential backoff strategy, and the backoff interval increases with the number of retries.

[0076] Specifically, the first retry waits 2 seconds, the second retrieval waits 4 seconds, the third retrieval waits 8 seconds, and so on, with the maximum backoff interval not exceeding a preset upper limit. This exponential backoff strategy avoids putting additional pressure on the message queue due to frequent retries, while ensuring that the notification eventually reaches the consumer. Upon receiving the notification, the consumer parses the download address and one-time download credential.

[0077] In this embodiment, the task status query and triggering mechanism avoids redundant archiving calculations. Differential chain replay restoration is only performed when the data has not yet been archived. That is, the trajectory point offset, CAN signal deviation value and fault code set differential are decoded in reverse differential order according to the most recent complete packet as the baseline. The differential data in the differential packet is restored to the complete data packet layer by layer and verified for the continuity of timestamp and the reasonableness of the numerical range. At the same time, after the archiving is completed, a notification message is pushed through the message queue. If the push fails, it will automatically retry according to the exponential backoff strategy until it is delivered. This realizes accurate data restoration on demand and closed-loop management of task status. The storage layer only needs to retain the differential packet to meet the restoration needs of complete data on any date, which takes into account both storage space efficiency and data availability.

[0078] S7: The consumer initiates segmented downloads to the file server based on a one-time download credential. It models network quality in real time based on historical leased line transmission logs, dynamically calculates the optimal segment size and the number of concurrent download threads, and performs breakpoint resume and integrity verification. Step S7 includes the following sub-steps: S71: The consumer initiates a segmented download request to the file server based on a one-time download credential. It should be noted that in this step, after receiving the asynchronous notification message pushed by the vehicle manufacturer's data platform, the consumer parses out the one-time download credential and the index file download address contained in the notification message. The one-time download credential is a temporary authorization token signed with a hash-based message authentication code. Its content includes at least the task identifier, vehicle identification number, and expiration time. It is marked as invalid after the first successful download to prevent the credential from being reused. The consumer first uses the credential to download the index file and parses the fragment metadata in the index file. Subsequently, based on the one-time download credential, the consumer initiates a fragment download request to the file server. The download request uses the GET method of the Hypertext Transfer Protocol, with the one-time download credential as an authorization identifier in the request header, and the storage path and fragment number of the target fragment specified in the URL. After receiving the request, the file server verifies the validity of the credential. If the verification is successful, it returns the binary data of the corresponding fragment.

[0079] S72, the network adaptive fragmentation scheduler constructs a network quality prediction model based on historical leased line transmission logs. The prediction model predicts the bandwidth value at future times based on the bandwidth value at historical times, so as to capture the daily and weekly cycle change patterns of network bandwidth and output the predicted network bandwidth value at future times. In this step, the network adaptive fragmentation scheduler constructs a network quality prediction model based on historical leased line transmission logs to dynamically optimize the fragmentation download strategy. The historical leased line transmission logs record information such as the start and end times, data volume, actual transmission duration, and number of retransmissions for each transmission task, from which the network bandwidth measurement sequence at each moment can be extracted. Leased line network bandwidth typically exhibits obvious daily and weekly cycle patterns. The prediction model uses an autoregressive approach to predict network bandwidth over time to capture the aforementioned periodic variation patterns and output the predicted network bandwidth value for future moments.

[0080] The specific mathematical form of the prediction model is: ; In the formula, BW pred ( t +Δt) represents the current time. t The predicted network bandwidth at a preset time interval Δt is then given. BW ( t The actual network bandwidth measurement at time t is extracted from the historical leased line transmission log; m ( t (time) t The trend component is used to capture the daily and weekly variation patterns of network bandwidth, which is obtained by averaging historical bandwidth data over time points. Let be the autoregressive coefficient, representing the th . k The contribution weights of bandwidth deviation at each historical moment to the predicted value are obtained by fitting historical data using the least squares method. p The model order is the number of historical moments used for prediction, and its value is [value missing]. p =7 to p =14, corresponding to historical windows of one to two weeks respectively; e t The random noise term follows a normal distribution with a mean of zero, representing random fluctuations that cannot be explained by the model.

[0081] The prediction model runs each time a fragmented download task starts, outputting the bandwidth change curve for the expected duration of the current transmission task, which is used to calculate the optimal fragment size and the number of concurrent download threads. The parameters of the prediction model are periodically refitted using historical leased line transmission logs to adapt to long-term changes in the network environment.

[0082] S73, based on the network predicted bandwidth value and the latency requirement of the current transmission task, calculate the optimal fragment size and the number of concurrent download threads. The optimal fragment size is equal to the quotient obtained by multiplying the network predicted bandwidth value by the latency requirement and then dividing by the baseline concurrency, and the quotient is limited between the preset minimum fragment size and the maximum fragment size. The optimal number of concurrent download threads is equal to the quotient obtained by dividing the predicted bandwidth by the bandwidth utilization threshold of a single thread and rounding down, and the rounded result is limited between the preset minimum number of concurrent threads and the maximum number of concurrent threads. The formula for calculating the optimal fragment size is: ; in, S opt The optimal fragment size represents the amount of data in a single fragment that is most efficient under the current network conditions. S min This is the preset minimum fragment size; fragments that are too small will increase the number of requests and protocol overhead. S max The maximum fragment size is preset. Fragments that are too large will increase the retransmission overhead if a single transmission fails. BW pred Predict the bandwidth value for the network; D req The latency requirement for the current transmission task represents the expected data readiness time at the consumer end; N base The baseline concurrency is used to convert the bandwidth-latency product into the fragment size. The formula for calculating the optimal number of concurrent download threads is: ; In the formula, N opt The optimal number of concurrent download threads represents the number of parallel download threads that are most efficient under the current network conditions. N min This is the preset minimum number of concurrent threads; too few threads will prevent full utilization of bandwidth. N max This is the preset maximum number of concurrent threads. Too many threads will increase context switching overhead and network congestion risk. BW threshold This is the bandwidth utilization threshold for a single thread, representing the maximum bandwidth that a single download thread can fully utilize. Exceeding this value and increasing the number of threads can improve the total throughput. This is for floor function.

[0083] Fragment size is positively correlated with network bandwidth: when bandwidth is ample, larger fragments are used to reduce the number of requests and protocol overhead, thus improving transmission efficiency; when bandwidth is limited, smaller fragments are used to reduce the retransmission overhead of a single transmission failure. The number of concurrent threads is also positively correlated with network bandwidth: when bandwidth is ample, the number of concurrent threads is increased to fully utilize bandwidth resources; when bandwidth is limited, the number of concurrent threads is reduced to decrease thread switching overhead and the risk of network congestion.

[0084] S74, multiple download requests enter a priority scheduling queue, and bandwidth resources are allocated sequentially after being weighted and sorted according to the urgency of the business and the waiting time of the request. The urgency of the business is divided into fault analysis taking priority over trajectory playback, and trajectory playback taking priority over statistical reports. In this step, when there are multiple concurrent fragment download requests, each request enters a priority scheduling queue, and the network adaptive fragment scheduler manages the allocation of bandwidth resources.

[0085] The priority scheduling queue's sorting rules comprehensively consider two dimensions: business urgency and request waiting time. Business urgency is divided into three levels: the first priority is fault analysis, involving vehicle fault code diagnosis and safety hazard investigation, which has the highest requirement for data timeliness and must complete data transmission in the shortest possible time; the second priority is trajectory playback, used for tracing and reconstructing vehicle driving trajectories, with medium timeliness requirements; and the third priority is statistical reports, used for operational indicator analysis and management report generation, with the lowest timeliness requirements. Under the same business urgency, tasks with longer request waiting times receive higher sorting weights.

[0086] The scheduler allocates bandwidth resources to each download request in order of priority. After being scheduled, each download request executes transmission according to the optimal chunk size and the number of concurrent download threads. When bandwidth resources are allocated among multiple tasks, a weighted fair queue algorithm is used to ensure that high-priority tasks receive a higher share of bandwidth while preventing low-priority tasks from being completely blocked.

[0087] S75: When the download is interrupted, a resume request is initiated based on the offset of the downloaded data, and only the unfinished segments are retransmitted. If a network interruption, timeout, or server-side abnormality occurs during the segmented download process in this step, causing the download to be interrupted, the consumer will automatically activate the breakpoint resume mechanism.

[0088] During the download process, the consumer continuously records the offset of successfully received data. When a download interruption is detected, the consumer re-initiates a Hypertext Transfer Protocol (HTTP) range request to the file server, carrying the offset of the downloaded data in the request header. The download resumes from the breakpoint, retransmitting only the incomplete fragments, without retransmitting the entire fragment or the entire archive. After receiving the range request, the file server verifies the validity of the one-time download credential. If the verification is successful, it returns the remaining data starting from the specified offset position.

[0089] The breakpoint resume mechanism can reduce the overhead of repeated transmissions caused by network jitter, especially in scenarios where the quality of dedicated network lines is unstable, avoiding the bandwidth waste and time consumption of re-downloading the entire large file due to a brief network interruption.

[0090] S76. After each segment is downloaded, a checksum comparison is performed. The checksum of each segment is calculated and compared with the checksum recorded in the index file. After all segments pass the checksum, decompression and data restoration are performed.

[0091] In this embodiment, an autoregressive prediction model based on historical leased line transmission logs is used to capture the daily and weekly variation patterns of network bandwidth to output bandwidth prediction values ​​for future moments. Based on this, the optimal fragment size and concurrent download thread count are dynamically calculated, enabling the transmission strategy to adapt to the time-varying characteristics of leased line network quality. When the network is congested, the fragment size and concurrency are reduced to lower retransmission overhead, while when the network is idle, the fragment size and concurrency are increased to fully utilize bandwidth resources. At the same time, bandwidth resources are allocated sequentially by weighting the multi-request priority scheduling queue according to the rule that fault analysis takes precedence over trajectory playback, and trajectory playback takes precedence over statistical reports. Combined with the breakpoint resume mechanism based on the downloaded offset when download is interrupted, only incomplete fragments are retransmitted, and after download, the verification value of each fragment is compared with the record in the index file. This achieves end-to-end transmission assurance from network awareness, parameter optimization, priority scheduling, breakpoint resume to integrity verification, significantly improving the reliability and bandwidth utilization of leased line transmission.

[0092] S8, on the consumer side, performs time-series analysis on the restored vehicle historical data, extracts the data subset of the latest natural day and displays it for operators to view on the terminal.

[0093] Secondly, the present invention also provides a vehicle historical data collaborative acquisition system, implemented using a vehicle historical data collaborative acquisition method and system, including: The data acquisition module is used by the vehicle terminal to push vehicle operation data to the raw database in real time at a preset period. The activity assessment module is used to extract multi-dimensional temporal features of each vehicle identification number from the original database before triggering outbound processing on each natural day. Based on the multi-dimensional temporal features, it predicts the probability distribution of the activity level of each vehicle identification number in the future time window. According to the probability distribution, the vehicles are divided into the first active level, the second dormant level, and the third silent level, and the pre-push priority score of each vehicle identification number is calculated. The outbound processing module is used to perform corresponding offline outbound processing according to the vehicle classification level at the end of each natural day, and to encapsulate the processed standard data into a preset document format and write it to the file server in segments. The edge caching module is used to proactively push archived documents of high-priority vehicles to the edge caching nodes on the consumer side during periods of low load on the dedicated line, based on pre-push priority scoring. When the consumer initiates a request, it first queries the local edge cache, and if the cache is not hit, it initiates a data request to the vehicle manufacturer's data platform. The request scheduling module is used by the car manufacturer's data platform to perform permission verification on data requests. After the verification is successful, the request is written to the asynchronous task queue and a globally unique task identifier is generated. The archiving and replay module is used by the car manufacturer's data platform to query or trigger archiving tasks based on task identifiers. If the requested data date range contains differential packets, the module replays the complete data of the target date by applying the differential packets on the differential chain in the order of the most recent complete packet as the baseline. After archiving is completed, an asynchronous notification message is pushed to the consumer. The adaptive download module is used by the consumer to initiate segmented downloads to the file server based on a one-time download credential. It models network quality in real time based on historical leased line transmission logs, dynamically calculates the optimal segment size and the number of concurrent download threads, and performs breakpoint resume and integrity verification. The data display module is used by the consumer to perform time-series analysis on the restored vehicle historical data, extract the data subset of the latest natural day for display on the terminal for operators to view.

[0094] It should be noted that this system corresponds to the above-mentioned method for collaborative acquisition of vehicle historical data. All implementation methods in the above method embodiments are applicable to the embodiments of this system and can achieve the same technical effect.

[0095] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0096] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the system and modules described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0097] In the embodiments provided by this invention, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0098] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0099] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0100] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0101] Furthermore, it should be noted that in the system and method of the present invention, it is obvious that the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent solutions of the present invention. Moreover, the steps performing the above series of processes can naturally be executed in the order described, but are not necessarily required to be executed in chronological order; some steps can be executed in parallel or independently of each other. Those skilled in the art will understand that all or any step or component of the method and apparatus of the present invention can be implemented in any computing device (including processors, storage media, etc.) or network of computing devices, in hardware, firmware, software, or a combination thereof. This is something that those skilled in the art can achieve by using their basic programming skills after reading the description of the present invention.

[0102] Therefore, the object of the present invention can also be achieved by running a program or a set of programs on any computing system. The computing system can be a known general-purpose system. Therefore, the object of the present invention can also be achieved simply by providing a program product containing program code implementing the method or apparatus. That is, such a program product also constitutes the present invention, and the storage medium storing such a program product also constitutes the present invention. Obviously, the storage medium can be any known storage medium or any storage medium developed in the future. It should also be noted that in the apparatus and method of the present invention, it is obvious that the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent to the present invention. Furthermore, the steps performing the above series of processes can naturally be performed in the order described, but are not necessarily required to be performed in chronological order. Some steps can be performed in parallel or independently of each other.

[0103] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for collaborative acquisition of vehicle historical data, characterized in that, Includes the following steps: S1, the vehicle terminal pushes vehicle operation data to the original database in real time at a preset cycle; S2, before triggering the outbound processing on each natural day, extract the multi-dimensional temporal features of each vehicle identification number from the original database, predict the probability distribution of the activity level of each vehicle identification number in the future time window based on the multi-dimensional temporal features, divide the vehicles into the first active level, the second dormant level and the third silent level according to the probability distribution, and calculate the pre-push priority score of each vehicle identification number. S3, at the end of each natural day, performs the corresponding offline outbound processing according to the vehicle classification level, and encapsulates the processed standard data into a preset document format and writes it to the file server in segments; S4, based on pre-push priority scoring, actively pushes the archived documents of high-priority vehicles to the edge cache node on the consumer side during the low load period of the dedicated line. When the consumer initiates a request, it first queries the local edge cache. If the cache is not hit, it initiates a data request to the vehicle manufacturer's data platform. S5, the car manufacturer's data platform performs permission verification on data requests. After the verification is successful, the request is written to the asynchronous task queue and a globally unique task identifier is generated. S6, the vehicle enterprise data platform queries or triggers archiving tasks based on task identifiers. If the requested data date range contains differential packages, the platform uses the most recent complete package as the baseline to replay and restore the complete data of the target date by applying each differential package on the differential chain in sequence. After archiving is completed, an asynchronous notification message is pushed to the consumer. S7: The consumer initiates segmented downloads to the file server based on a one-time download credential. It models network quality in real time based on historical leased line transmission logs, dynamically calculates the optimal segment size and the number of concurrent download threads, and performs breakpoint resume and integrity verification. S8, on the consumer side, performs time-series analysis on the restored vehicle historical data, extracts the data subset of the latest natural day and displays it for operators to view on the terminal.

2. The method for collaborative acquisition of vehicle historical data as described in claim 1, characterized in that, Step S1 includes the following steps: S11, the vehicle terminal collects vehicle operation data at fixed intervals, and the vehicle operation data includes at least global positioning system coordinates, controller area network bus signals, fault codes and sensor status; S12, the vehicle terminal reports the collected data to the vehicle manufacturer's original database. The original database uses a message bus to partition the data by vehicle identification number and writes it into a time-series data table, which is stored in the form of raw byte stream.

3. The method for collaborative acquisition of vehicle historical data as described in claim 1, characterized in that, Step S2 includes the following sub-steps: S21. Before triggering the outbound processing on each natural day, extract the multi-dimensional temporal features of each vehicle identification number from the original database. The multi-dimensional temporal features include at least the last reported time of the vehicle, the historical driving time sequence, the driving mileage sequence, the data change frequency sequence, the fault occurrence frequency sequence, the vehicle type and usage scenario label. S22, a vehicle activity prediction model is constructed based on multi-dimensional time-series features. The multi-dimensional time-series feature vector up to the current moment is used as input. After extracting the statistical features, trend features and periodic features of the time series through the feature mapping function, the probability value of each vehicle identification code belonging to the first active level, the second dormant level or the third silent level in the future time window is output. The sum of the three probability values ​​is 1. S23, vehicles whose predicted first active level probability is greater than the first preset threshold are classified as first active level, vehicles whose predicted first active level probability is between the second preset threshold and the first preset threshold are classified as second dormant level, and vehicles whose predicted first active level probability is lower than the second preset threshold are classified as third silent level. S24. Count the number of times the vehicle identification number is requested by the consumer within a historical preset period, divide the number by the total number of times all vehicles are requested within the period, and obtain the historical request frequency of the vehicle. S25, obtain the set of vehicles recently requested by the consumer, calculate the similarity between the current vehicle identification number and each vehicle in the vehicle set in three dimensions: vehicle type, usage scenario and geographical location, and take the average of the weighted sum of the similarity in the three dimensions to obtain the comprehensive similarity between the current vehicle and the recently requested vehicles. S26. The probability value of the vehicle identification number belonging to the first active level in the future time window, the historical request frequency of the vehicle, and the comprehensive similarity between the current vehicle and the recently requested vehicle are weighted and summed to obtain the pre-push priority score of each vehicle identification number.

4. The method for collaborative acquisition of vehicle historical data as described in claim 1, characterized in that, Step S3 includes the following sub-steps: S31, after the end of each natural day, the offline outbound computing node extracts all the cumulative raw data up to the previous natural day from the original database, performs offline batch processing, and obtains standard data; S32, for the first active level vehicle, output a complete archive package according to the standard data, encapsulate it into a preset document format using compression encoding, and divide it into multiple fragment files according to a preset threshold and write them to the file server. S33, for the second hibernation level vehicle, the semantic differential encoder performs differential semantic differential encoding on the standard data of two consecutive days. By comparing the standard data of the current day with the standard data of the previous day, the difference is calculated to generate a differential packet. The semantic differential encoding includes trajectory point spatial hash differential encoding, controller area network bus signal numerical differential encoding, and fault code set differential encoding. S34, Write the differential packet to the file server, and associate the differential packet with the preceding complete packet or differential packet through the differential chain pointer in the index file. The differential chain pointer includes the most recent complete archive packet, a differential entry list, and the total length of the differential chain. Each entry in the differential entry list contains the date, differential type, reference packet identifier, and differential packet binary data. S35, for vehicles in the third silent level, skip the offline outbound processing and mark the data for that natural day as missing in the index file; S36, Generate an index file, which includes fragment metadata, vehicle identification number mapping, data start and end timestamps, and checksums.

5. The method for collaborative acquisition of vehicle historical data as described in claim 4, characterized in that, The semantic differential coding in step S33 includes trajectory point spatial hash differential coding, controller area network bus signal numerical differential coding, and fault code set differential coding, wherein, The spatial hash differential encoding of trajectory points is to align the GPS trajectory points of two consecutive days by time, calculate the spatial offset of each trajectory point with the corresponding trajectory point of the previous day, record only the offset code for trajectory points with spatial offset less than a preset distance threshold, and record the complete GPS coordinates for trajectory points with spatial offset greater than or equal to the preset distance threshold. The differential encoding of controller area network bus signals calculates the numerical deviation of each signal field for controller area network bus signal data over two consecutive days. For signals with deviation values ​​within the preset normal fluctuation range, the deviation code is recorded and represented by variable-length integer encoding. For signals with deviation values ​​exceeding the normal fluctuation range, the complete signal value and anomaly mark are recorded. For signals with consistent trends over multiple consecutive days, second-order differential encoding is used. The fault code set differential encoding represents the fault code set as an ordered list. The differential result includes a list of newly added fault codes, a list of disappeared fault codes, and a list of persistent fault codes. The persistent fault codes only record the fault code identifier and the number of days they last.

6. The method for collaborative acquisition of vehicle historical data as described in claim 1, characterized in that, Step S4 includes the following sub-steps: S41, the vehicle manufacturer's data platform monitors the transmission load in real time, and triggers a pre-push window when the transmission bandwidth utilization rate is lower than a preset threshold. S42, within the pre-push window, push the archived documents of vehicles with a pre-push priority score higher than the preset push threshold from the file server to the edge cache node on the consumer side; S43, the edge cache node records the last K access times of each cache item. When the cache space is insufficient and needs to be evicted, the cache item with the earliest last K access time is removed first. S44, the cache window length is adaptively adjusted according to the vehicle activity level. The first active level is the first preset number of days, the second dormant level is the second preset number of days, and the third silent level does not perform pre-push. When the cache space reaches the preset limit, the cache items are sorted according to the vehicle activity level corresponding to each cache item. The cache items of the first active level vehicles have a higher retention priority than the second dormant level, and the second dormant level has a higher priority than the third silent level. S45: When a consumer initiates a data request, it first queries the local edge cache. If the cache is found, it returns the cached data directly. If the cache is not found, it sends a data request to the car manufacturer's data platform.

7. The method for collaborative acquisition of vehicle historical data as described in claim 1, characterized in that, Step S6 includes the following sub-steps: S61, the vehicle enterprise data platform queries the status of the corresponding archive task based on the task identifier. If the archive task corresponding to the task identifier has not been completed, the archive task is triggered to execute. If the requested data date range contains differential packets, the most recent complete archive packet before that date is used as the baseline. The differential packets in the differential chain are applied sequentially in chronological order to perform inverse differential decoding on the trajectory points, controller area network bus signals and fault codes respectively, restore the differential data in the differential packets to complete data, and generate a complete data packet for the target date. S62, after the archiving task is completed, an asynchronous notification message is pushed to the consumer through the message queue. The notification message includes at least the task identifier, archiving completion status, index file download address and one-time download certificate. If the notification push fails, it is retried according to the exponential backoff strategy, and the backoff interval increases with the number of retries.

8. The method for collaborative acquisition of vehicle historical data as described in claim 1, characterized in that, Step S7 includes the following sub-steps: S71: The consumer initiates a segmented download request to the file server based on a one-time download credential. S72, the network adaptive fragmentation scheduler constructs a network quality prediction model based on historical leased line transmission logs. The prediction model predicts the bandwidth value at future times based on the bandwidth value at historical times, so as to capture the daily and weekly cycle change patterns of network bandwidth and output the predicted network bandwidth value at future times. S73, based on the network predicted bandwidth value and the latency requirement of the current transmission task, calculate the optimal fragment size and the number of concurrent download threads. The optimal fragment size is equal to the quotient obtained by multiplying the network predicted bandwidth value by the latency requirement and then dividing by the baseline concurrency, and the quotient is limited between the preset minimum fragment size and the maximum fragment size. The optimal number of concurrent download threads is equal to the quotient obtained by dividing the predicted bandwidth by the bandwidth utilization threshold of a single thread and rounding down, and the rounded result is limited between the preset minimum number of concurrent threads and the maximum number of concurrent threads. S74, multiple download requests enter a priority scheduling queue, and bandwidth resources are allocated sequentially after being weighted and sorted according to the urgency of the business and the waiting time of the request. The urgency of the business is divided into fault analysis taking priority over trajectory playback, and trajectory playback taking priority over statistical reports. S75: When the download is interrupted, a resume request is initiated based on the offset of the downloaded data, and only the unfinished segments are retransmitted. S76. After each segment is downloaded, a checksum comparison is performed. The checksum of each segment is calculated and compared with the checksum recorded in the index file. After all segments pass the checksum, decompression and data restoration are performed.

9. A vehicle historical data collaborative acquisition system, implemented using the vehicle historical data collaborative acquisition method and system as described in any one of claims 1-8, characterized in that, include: The data acquisition module is used by the vehicle terminal to push vehicle operation data to the raw database in real time at a preset period. The activity assessment module is used to extract multi-dimensional temporal features of each vehicle identification number from the original database before triggering outbound processing on each natural day. Based on the multi-dimensional temporal features, it predicts the probability distribution of the activity level of each vehicle identification number in the future time window. According to the probability distribution, the vehicles are divided into the first active level, the second dormant level, and the third silent level, and the pre-push priority score of each vehicle identification number is calculated. The outbound processing module is used to perform corresponding offline outbound processing according to the vehicle classification level at the end of each natural day, and to encapsulate the processed standard data into a preset document format and write it to the file server in segments. The edge caching module is used to proactively push archived documents of high-priority vehicles to the edge caching nodes on the consumer side during periods of low load on the dedicated line, based on pre-push priority scoring. When the consumer initiates a request, it first queries the local edge cache, and if the cache is not hit, it initiates a data request to the vehicle manufacturer's data platform. The request scheduling module is used by the car manufacturer's data platform to perform permission verification on data requests. After the verification is successful, the request is written to the asynchronous task queue and a globally unique task identifier is generated. The archiving and replay module is used by the car manufacturer's data platform to query or trigger archiving tasks based on task identifiers. If the requested data date range contains differential packets, the module replays the complete data of the target date by applying the differential packets on the differential chain in the order of the most recent complete packet as the baseline. After archiving is completed, an asynchronous notification message is pushed to the consumer. The adaptive download module is used by the consumer to initiate segmented downloads to the file server based on a one-time download credential. It models network quality in real time based on historical leased line transmission logs, dynamically calculates the optimal segment size and the number of concurrent download threads, and performs breakpoint resume and integrity verification. The data display module is used by the consumer to perform time-series analysis on the restored vehicle historical data, extract the data subset of the latest natural day for display on the terminal for operators to view.

10. A computer-readable storage medium, characterized in that, The storage medium stores a method and system program for collaborative acquisition of vehicle historical data. When the program for collaborative acquisition of vehicle historical data is executed, it implements the method for collaborative acquisition of vehicle historical data as described in any one of claims 1-7.

Images