Intelligent traffic data processing method and system based on edge computing

Abstract

The application discloses an intelligent traffic data processing method and system based on edge computing and belongs to the technical field of traffic data processing. The method comprises the following steps: calculating an expected retention time window according to the driving state of a target vehicle and the boundary of a coverage area, and feeding back a preparation response containing a maximum push length and a recommended compression ratio value; extracting incremental change records of the target vehicle and compressing the same, receiving and temporarily storing a plurality of incremental data packets, and performing consistency comparison and ordered writing; feeding back a success instruction after the receiving end completes writing, and releasing the context data of the target vehicle stored locally. Through the mode of negotiation according to the retention time window of the target vehicle and the processing capacity of both sides before migration, extraction of only incremental change data during migration, and ordered writing based on time version comparison of the receiving end after migration, the technical problems of the prior art, such as disconnection between migration decision and actual load capacity of nodes and too large amount of full-state data, are solved.

Description

Technical Field

[0001] This invention relates to the field of traffic data processing technology, and in particular to a smart traffic data processing method and system based on edge computing. Background Technology

[0002] With the increasing density of urban road networks and the promotion of vehicle-road cooperative applications, edge computing technology has been gradually introduced into road traffic management systems to process motion data uploaded in real time by vehicle terminals at the roadside near end, in order to meet the requirements of low latency response and high concurrency computing. Existing systems typically deploy multiple edge processing nodes along the road, each responsible for tracking vehicle trajectories, predicting driving intentions, and providing signal interaction services within its signal coverage area. When a vehicle moves out of the coverage area of ​​the current node, the vehicle's relevant operational context needs to be completely transferred from the current service node to the next service node. In the current implementation, this transfer process is mainly triggered by the quality detection results of the wireless communication link (such as signal strength below a threshold), and the source node packages and transmits all historical trajectories, target-related features, and prediction intermediate variables of the vehicle to the target node.

[0003] However, the above migration method has the following shortcomings in actual deployment: First, the migration decision relies solely on changes in physical link signals, without considering the real-time fluctuations in the target node's current computing load and communication bandwidth. This leads to a disconnect between the timing of the migration action and the actual carrying capacity of the target node, which can easily cause data accumulation and processing timeouts during high-load periods. Second, due to the large volume of full-state data, it is usually impossible to complete the full transmission within the limited time window when a vehicle passes through the coverage overlap area at high speed, resulting in a service gap before the target node takes over, causing continuous loss of tracking and early warning services. Third, the source node releases local storage resources after the migration starts, while the target node has not yet fully loaded the received data. This results in a chaotic state where the vehicle status cannot be effectively managed by both ends at the moment of switching. After the migration is completed, due to the incomplete motion observation data during the gap period, anomalies such as duplicate identification numbers of the same target and incorrect splicing of trajectory segments often occur. Consequently, downstream applications such as collision risk assessment are calculated based on fragmented or inconsistent trajectory information, seriously affecting the reliability of traffic management decisions. The aforementioned contradictions are particularly prominent in scenarios with high traffic density and high movement speed, such as expressways and intersections, and have become one of the key obstacles restricting the actual operation of edge computing intelligent transportation systems. Summary of the Invention

[0004] This application provides a smart transportation data processing method and system based on edge computing, which solves the problems of service interruption caused by insufficient adaptation of triggering conditions and node load when the vehicle state context migrates between edge nodes in the prior art, as well as the problems of count fission and trajectory data loss after migration. It realizes the continuous availability of vehicle tracking service and the consistent integrity of state data during the migration process.

[0005] This application provides a smart transportation data processing method based on edge computing, including: the migration initiator calculates the expected retention time window based on the driving status of the target vehicle and the coverage area boundary, and sends a preparation request containing the window and its own processing capacity to the migration receiver;

[0006] After comparing its own processing capabilities with the preparation request, the migration receiver sends out a preparation response containing the maximum push length and the recommended compression ratio.

[0007] The migration initiator extracts the incremental change records of the target vehicle based on the prepared response, compresses them, divides them into multiple incremental data packets that meet the maximum push length, and sends them one by one.

[0008] The migration receiver receives and temporarily stores the multiple incremental data packets, and after confirming their completeness, performs a consistency comparison between the change time data in each data packet and the local current state time data, and writes them in an orderly manner.

[0009] After the migration receiver completes the write operation, it sends out a success command. The migration initiator then releases the locally stored context data of the target vehicle based on the success command and the local data call counter.

[0010] Furthermore, the steps of calculating the expected retention time window and sending a preparation request containing that window and its own processing capacity to the migration recipient include:

[0011] The system acquires the instantaneous speed and direction angle of the target vehicle and reads the network coverage overlap boundary data between the two processing nodes.

[0012] The vehicle's trajectory is intersected by a straight line projection of the network coverage overlap boundary data to determine the entry and exit points, and the expected retention time window is calculated by combining the instantaneous motion speed value.

[0013] The target vehicle's identification number, current version number, expected retention time window, number of tasks waiting to be processed in its queue, and number of available idle data locations are combined to generate the preparation request, which is then sent to the migration recipient.

[0014] Furthermore, the steps for preparing a response that includes the maximum push length and recommended compression ratio include:

[0015] Obtain its own queuing task depth and the number of available computing positions, and compare them with the initiator's value in the preparation request;

[0016] Based on the comparison results, calculate the maximum data block length that can safely handle data and the recommended data compression ratio baseline value;

[0017] If it is determined that there are enough available locations, the response includes a migration permission flag, the maximum data block length limit, the recommended data compression ratio baseline value, and its own clock count, and is then sent.

[0018] If it is determined that there are not enough available locations, a migration rejection flag is included in the response so that the migration initiator puts the migration task into the waiting queue.

[0019] Furthermore, the steps of extracting and compressing the incremental change records of the target vehicle include:

[0020] Locate the historical full state data storage area belonging to the target vehicle in the local storage space, and extract the data version checkpoint timestamp marked when the last successful migration was completed;

[0021] The log entries for all data changes up to the current time are traversed using this timestamp. The log entries include rewritten records of vehicle position, speed vector, associated target tracking feature values, and intermediate variables for intention prediction.

[0022] Arrange the data change operation log entries in chronological order of their occurrence;

[0023] For each log entry, only the changed value and the address offset of that value in storage are extracted and combined to form the initial incremental data set.

[0024] Furthermore, the steps of extracting and compressing the incremental change records of the target vehicle, and dividing them into multiple incremental data packets that meet the maximum push length include:

[0025] Based on the recommended data compression ratio benchmark value in the prepared response, a data compression operation with dynamic feature dictionary matching is performed on the initial incremental data set;

[0026] In the data compression operation, the repeated field patterns in the data stream to be compressed are counted in real time and a temporary dictionary table is dynamically constructed to map the repeated patterns to shorter variable-length encoded words.

[0027] Based on the real-time compression ratio feedback of the transmitted data blocks, the encoding mapping strategy of subsequent data blocks is dynamically adjusted so that the overall compression ratio approaches the benchmark value.

[0028] After compression, the generated incremental data stream is divided into multiple incremental data packets, ensuring that the size of each incremental data packet does not exceed the maximum data block length limit.

[0029] Furthermore, the step of the migration receiver receiving and temporarily storing the plurality of incremental data packets includes:

[0030] Before transmission, the migration initiator does not perform deletion and write locking on the target vehicle state context stored locally, marks it as a read-only proxy state, and maintains a lightweight access count pointer in memory to record the number of local processes that depend on this data.

[0031] When the migration receiver receives the first incremental data packet, it does not immediately decompress it or merge it into the runtime main storage area, but instead opens an independent incremental data temporary storage area in its own storage space.

[0032] The incremental data temporary storage area maintains an ordered queue according to the receiving order, where each entry stores the original compressed data packet, the data version tracking clock value, and the sending timestamp.

[0033] Furthermore, the step of sending multiple incremental data packets that meet the maximum push length one by one includes:

[0034] The incremental data packets are sent one by one in the segmentation order. Each time the migration receiver receives an incremental data packet, it stores it completely at the end of the queue of the incremental data temporary storage area and sends back a reception confirmation signal to the migration initiator, carrying the total number of data packets received and the cumulative byte length.

[0035] During transmission, continuously monitor the remaining length of the current expected retention time window;

[0036] If the remaining length value is detected to be less than the preset safety margin limit, the dynamic dictionary data compression ratio of subsequent unsent data packets is actively increased to reduce the total number of bytes in subsequent data packets, and the sending rate is adjusted at the same time.

[0037] Furthermore, the steps of performing consistency comparison and orderly writing of the change time data in each data packet with the local current state time data include:

[0038] After detection, each data packet is decompressed and its version tracking clock is extracted, and then compared with the local clock component by component.

[0039] If each component is later than or equal to the local component, write the data directly to the main storage area.

[0040] If a component exists earlier than the local timestamp, compare it with the original global timestamp. If the timestamp of the decompressed data is larger, perform an overwrite write; otherwise, discard it if the local timestamp is larger.

[0041] If the timestamps are the same and there is a branch conflict, the decision to write or discard is made based on the sender number and the preset priority order table. If any data packet is processed abnormally, the processing is terminated and a submission failure signal is sent back.

[0042] This application provides an edge computing-based intelligent transportation data processing system for implementing an edge computing-based intelligent transportation data processing method, including: a time window calculation module, a preparation response feedback module, an incremental data packet segmentation module, a consistency comparison module, and a context data release module;

[0043] The time window calculation module is used by the migration initiator to calculate the expected retention time window based on the driving status of the target vehicle and the coverage area boundary, and send a preparation request containing the window and its own processing capacity to the migration receiver.

[0044] The preparation response feedback module is used to provide a preparation response containing the maximum push length and the recommended compression ratio after the migration receiver compares its own processing capabilities with the preparation request.

[0045] The incremental data packet segmentation module is used by the migration initiator to extract the incremental change records of the target vehicle according to the prepared response, compress them, segment them into multiple incremental data packets that meet the maximum push length, and send them one by one.

[0046] The consistency comparison module is used by the migration receiver to receive and temporarily store the multiple incremental data packets, and after confirming their completeness, to perform consistency comparison and orderly writing of the change time data in each data packet with the local current status time data.

[0047] The context data release module is used to send a success instruction after the migration receiver completes the writing process. The migration initiator then releases the locally stored context data of the target vehicle based on the success instruction and the local data call count.

[0048] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0049] By having the migration initiator calculate the expected retention time window based on the target vehicle's driving status and the coverage area boundary, and by negotiating the processing capacity with the migration receiver, the timing of the migration operation and the transmission parameters can be matched with the current road traffic conditions and the actual load of both parties. This avoids blindly initiating migration based solely on signal strength, and is conducive to performing data handover under conditions where both parties have sufficient resources, reducing the risk of service interruption due to node overload.

[0050] Furthermore, when determining the data to be migrated, only the incremental change records since the last successful migration are extracted and compressed. The compressed data is then divided into multiple small packets of the negotiated size and sent sequentially. At the same time, the remaining time window is continuously monitored and the compression ratio is dynamically adjusted to effectively control the amount of data transmitted at each moment. This ensures that the entire migration process can be completed before the vehicle leaves the overlapping area, avoiding service interruption windows caused by excessive data volume spanning multiple communication time slots. This ensures that the detection and tracking services for the vehicle are continuously available during the handover period.

[0051] Furthermore, after receiving all incremental packets, the receiver temporarily stores them in an independent interval and parses them sequentially. It compares the time version information in each packet with the existing local data and decides whether to write or discard them based on the order and source priority. Meanwhile, the initiator maintains the read-only proxy state of the local data before receiving successful confirmation and releases storage resources delayed according to the call count. This ensures that vehicle data has a unique and valid home node at any given time, avoiding count fission and trajectory loss caused by premature deletion or duplicate writing. This allows downstream collision risk assessment to be calculated based on complete, consistent, and continuous trajectory data, outputting reliable results without undergoing lengthy filtering corrections, thus ensuring the timeliness and reliability of the traffic warning function. Attached Figure Description

[0052] Figure 1 A flowchart of a smart transportation data processing method based on edge computing provided for embodiments of this application;

[0053] Figure 2 This is a schematic diagram of the structure of an edge computing-based intelligent transportation data processing system provided in an embodiment of this application. Detailed Implementation

[0054] This application provides a smart transportation data processing method and system based on edge computing, which solves the problems in the prior art where service interruption and inconsistency between count fission and trajectory data occur when the vehicle driving state context is migrated between edge nodes due to insufficient migration decision and node load adaptation. By negotiating migration parameters based on the vehicle retention time window and the processing capabilities of both parties before migration, extracting only incremental change data and dynamically compressing and transmitting it in blocks during migration, and performing ordered writing based on time version comparison at the receiving end after migration and delaying the release of local resources at the source end based on access count after migration, the continuous availability of the vehicle cross-node migration tracking service and the uniqueness and integrity of state data among multiple edge nodes are achieved.

[0055] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0056] like Figure 1The diagram shown is a flowchart of a smart transportation data processing method based on edge computing provided in this application embodiment. The method is applied to a smart transportation data processing system based on edge computing. The method includes the following steps: the migration initiator calculates the expected retention time window based on the driving status of the target vehicle and the boundary of the coverage area, and sends a preparation request containing the window and its own processing capacity to the migration receiver.

[0057] After comparing its own processing capabilities with the preparation request, the migration receiver sends out a preparation response containing the maximum push length and the recommended compression ratio.

[0058] The migration initiator extracts the incremental change records of the target vehicle based on the prepared response, compresses them, divides them into multiple incremental data packets that meet the maximum push length, and sends them one by one.

[0059] The migration receiver receives and temporarily stores the multiple incremental data packets, and after confirming their completeness, performs a consistency comparison between the change time data in each data packet and the local current state time data, and writes them in an orderly manner.

[0060] After the migration receiver completes the write operation, it sends out a success command. The migration initiator then releases the locally stored context data of the target vehicle based on the success command and the local data call counter.

[0061] Furthermore, the steps of calculating the expected retention time window and sending a preparation request containing that window and its own processing capacity to the migration recipient include:

[0062] The system acquires the instantaneous speed and direction angle of the target vehicle and reads the network coverage overlap boundary data between the two processing nodes.

[0063] The vehicle's trajectory is intersected by a straight line projection of the network coverage overlap boundary data to determine the entry and exit points, and the expected retention time window is calculated by combining the instantaneous motion speed value.

[0064] The target vehicle's identification number, current version number, expected retention time window, number of tasks waiting to be processed in its queue, and number of available idle data locations are combined to generate the preparation request, which is then sent to the migration recipient.

[0065] In this embodiment, in order to accurately determine the timing of the migration action and prevent service interruption caused by switching too early or too late, the migration initiator performs the following specific operations:

[0066] First, the instantaneous speed value of the target vehicle is obtained in real time through roadside sensor networks or on-board OBU. Angle value relative to the direction of travel (heading angle) Simultaneously, it retrieves the geographic geometric overlap boundary data of the wireless coverage areas of the two processing nodes (i.e., the initiator and the receiver) that are pre-stored in the configuration file.

[0067] When calculating the expected retention time window, in a two-dimensional geographic coordinate system, the vehicle's current driving trajectory is plotted according to the heading angle. Extend the line and calculate its intersection with the entry and exit edge lines of the network coverage overlap boundary by projecting the line. This accurately locates the coordinates of the intersection entry point. Coordinates of departure point .

[0068] The theoretical straight path length of a vehicle traveling within the overlapping area can be calculated using the distance formula between two points:

[0069] ;

[0070] Furthermore, combined with the instantaneous motion velocity value The calculated expected retention time window is obtained. The calculation formula is as follows:

[0071] ;

[0072] In practical applications or review responses, to cope with changing lane conditions or subtle swerving lane-changing behaviors of vehicles, the path length... You can also multiply it by an adjustment factor. (Its preferred value range) Alternatively, replacing the straight-line projection with a trajectory prediction algorithm based on higher-order Bézier curves is also within the scope of equivalent substitutions in this invention.

[0073] Finally, the target vehicle's identification number (ID), current status version number, and calculated... The number of tasks waiting to be processed in the local task queue and the number of available idle data positions (number of slots) are concatenated and binary encapsulated to generate a unified preparation request for sending.

[0074] Furthermore, the steps for preparing a response that includes the maximum push length and recommended compression ratio include:

[0075] Obtain its own queuing task depth and the number of available computing positions, and compare them with the initiator's value in the preparation request;

[0076] Based on the comparison results, calculate the maximum data block length that can safely handle data and the recommended data compression ratio baseline value;

[0077] If it is determined that there are enough available locations, the response includes a migration permission flag, the maximum data block length limit, the recommended data compression ratio baseline value, and its own clock count, and is then sent.

[0078] If it is determined that there are not enough available locations, a migration rejection flag is included in the response so that the migration initiator puts the migration task into the waiting queue.

[0079] In this embodiment, after receiving the preparation request, the migration receiver enters the load adaptation branch logic:

[0080] Read the task scheduler metrics of the operating system kernel to obtain the current queued task depth. Number of available free locations Then, these two values ​​are compared with the number of queued tasks from the initiator included in the preparation request. and the number of available slots Perform a horizontal alignment comparison.

[0081] Based on the comparison results, in order to prevent the receiving end from crashing due to computing power overload, the maximum data block limit length that can safely receive data is dynamically quantized and calculated. And the recommended data compression ratio benchmark. The specific calculation logic is as follows:

[0082] ;

[0083] ;

[0084] in, The maximum number of cache bytes allowed for a single computing slot (e.g., fixed at 64KB or 128KB).

[0085] Guided to different control branches based on the sufficiency of available positions. (If the number of available positions is determined...) If the value is greater than or equal to the preset disaster recovery threshold (e.g., security slots are set to greater than or equal to 2), it is determined that the failover is safe and the migration branch is entered. At this point, the "migration permission flag" is written into the response data packet, and the calculated value is... , And the receiver's current local clock count is filled into the corresponding field before being sent.

[0086] Conversely, if determining the number of available locations If the value is below the safety threshold, it indicates that the receiver is operating under high load, and the process proceeds to the migration rejection branch. In this case, the "migration rejection flag" is directly written into the response and the process returns. Upon receiving the rejection flag, the migration initiator automatically pauses the migration, marks the migration task for the target vehicle as suspended, and re-adds it to the waiting queue, waiting for a preset delay period (e.g., 500 milliseconds) before re-initiating the request.

[0087] Furthermore, the steps of extracting and compressing the incremental change records of the target vehicle include:

[0088] Locate the historical full state data storage area belonging to the target vehicle in the local storage space, and extract the data version checkpoint timestamp marked when the last successful migration was completed;

[0089] The log entries for all data changes up to the current time are traversed using this timestamp. The log entries include rewritten records of vehicle position, speed vector, associated target tracking feature values, and intermediate variables for intention prediction.

[0090] Arrange the data change operation log entries in chronological order of their occurrence;

[0091] For each log entry, only the changed value and the address offset of that value in storage are extracted and combined to form the initial incremental data set.

[0092] In this embodiment, when entering the incremental generation stage, the migration initiator no longer fully packages the vehicle's perception context, but instead performs refined stripping:

[0093] Based on the target vehicle's identification number, precisely locate the historical full-state data storage area belonging to that vehicle in local memory or a structured database. Extract the data version checkpoint timestamp written during the last successful migration synchronization between the two ends from the metadata header of this area. .

[0094] With this Starting from the time frame, perform a depth-first traversal of the system log management module to retrieve data from... Then until the current moment Up to this point, the system has recorded all data change operations performed on the vehicle. These log entries are dynamic and fragmented, specifically including: vehicle position coordinate update records from vehicle-road cooperative perception, speed vector update records, target tracking feature value (feature vector) update records from the fusion association of roadside cameras and LiDAR, and intermediate variable rewriting records generated by the downstream intent prediction algorithm module.

[0095] To ensure the rigor of the timing logic, all extracted log entries are sorted in ascending order according to their respective timestamps. Then, a crucial slimming operation is performed: for each sorted log entry, redundant operators and non-critical metadata are discarded, and only the final value after data modification and its absolute offset in memory are extracted. These independent "position values" are combined to form the initial incremental data set, fundamentally reducing the amount of original data that needs to be transmitted.

[0096] Furthermore, the steps of extracting and compressing the incremental change records of the target vehicle, and dividing them into multiple incremental data packets that meet the maximum push length include:

[0097] Based on the recommended data compression ratio benchmark value in the prepared response, a data compression operation with dynamic feature dictionary matching is performed on the initial incremental data set;

[0098] In the data compression operation, the repeated field patterns in the data stream to be compressed are counted in real time and a temporary dictionary table is dynamically constructed to map the repeated patterns to shorter variable-length encoded words.

[0099] Based on the real-time compression ratio feedback of the transmitted data blocks, the encoding mapping strategy of subsequent data blocks is dynamically adjusted so that the overall compression ratio approaches the benchmark value.

[0100] After compression, the generated incremental data stream is divided into multiple incremental data packets, ensuring that the size of each incremental data packet does not exceed the maximum data block length limit.

[0101] In this embodiment, to ensure that the data volume matches the instantaneous bandwidth of the current vehicle-to-infrastructure communication link and the receiver's computing power, the migration initiator performs secondary processing on the initial incremental data set:

[0102] The benchmark value for the compression ratio of the recommended data obtained through negotiation. As the target control boundary, a data compression algorithm (such as the adaptive LZ series algorithm) is initiated based on dynamic feature dictionary matching. During the compression process, a sliding scanning window is opened in memory to count the frequently recurring specific fields or character patterns in the current binary data stream to be compressed in real time, and a temporary dictionary table is dynamically constructed in memory.

[0103] Once a repeating pattern is detected, it is replaced with a shorter, variable-length coded word pointing to that temporary dictionary entry. To prevent fading jitter in the wireless channel, the real-time actual compression ratio feedback transmitted back by the receiver via the reverse channel is read after each historical data block is transmitted.

[0104] By utilizing a feedback mechanism, the dictionary window size and matching depth of subsequent unprocessed data blocks are dynamically fine-tuned, allowing the overall stream compression ratio to approach the aforementioned baseline value infinitely. After the compression process is complete, the continuous compressed stream is hard-segmented according to byte boundaries and assembled into multiple independent incremental data packets. A counting check is added during segmentation to ensure that the total size of each incremental data packet is strictly less than or equal to the maximum data block length specified by the receiver. .

[0105] Furthermore, the step of the migration receiver receiving and temporarily storing the plurality of incremental data packets includes:

[0106] Before transmission, the migration initiator does not perform deletion and write locking on the target vehicle state context stored locally, marks it as a read-only proxy state, and maintains a lightweight access count pointer in memory to record the number of local processes that depend on this data.

[0107] When the migration receiver receives the first incremental data packet, it does not immediately decompress it or merge it into the runtime main storage area, but instead opens an independent incremental data temporary storage area in its own storage space.

[0108] The incremental data temporary storage area maintains an ordered queue according to the receiving order, where each entry stores the original compressed data packet, the data version tracking clock value, and the sending timestamp.

[0109] In this embodiment, to avoid the problem of vehicles being in a "dual non-homing" perception blind spot during the moment of dual-node switching caused by the "switch-then-delete" method in the prior art, the present invention establishes a proxy mechanism through collaboration between the two ends before formally sending data packets:

[0110] On the sending end, the migration initiator does not physically delete the target vehicle's state context data in the local main storage area, nor does it perform exclusive write locking. Instead, it modifies the vehicle's state field to "read-only proxy state." In this state, external local perception and prediction processes can still read the data. To track data dependencies, a lightweight access counter pointer for atomic operations is maintained in memory. The pointer is automatically incremented by 1 whenever a local real-time processing flow (such as local collision warning logic) calls the vehicle data; it is automatically decremented by 1 when the flow ends and releases the call.

[0111] At the receiving end, when the migrating receiver receives the first incremental data packet at the network port, its core processor does not immediately invoke the decompression algorithm, nor does it write or merge it into the current runtime main memory. Instead, a completely isolated, temporary incremental data buffer is allocated in local high-speed random access memory (RAM). This buffer logically functions as a first-in, first-out ordered queue. Each time a packet is received, it is sequentially added to the queue as an entry. Each entry fully preserves the original compressed data packet body, the version tracking clock value used to track version evolution, and the sending timestamp from the source end.

[0112] Furthermore, the step of sending multiple incremental data packets that meet the maximum push length one by one includes:

[0113] The incremental data packets are sent one by one in the segmentation order. Each time the migration receiver receives an incremental data packet, it stores it completely at the end of the queue of the incremental data temporary storage area and sends back a reception confirmation signal to the migration initiator, carrying the total number of data packets received and the cumulative byte length.

[0114] During transmission, continuously monitor the remaining length of the current expected retention time window;

[0115] If the remaining length value is detected to be less than the preset safety margin limit, the dynamic dictionary data compression ratio of subsequent unsent data packets is actively increased to reduce the total number of bytes in subsequent data packets, and the sending rate is adjusted at the same time.

[0116] In this embodiment, during the data transmission phase, the migration initiator and the migration receiver engage in rolling send-receive interactions:

[0117] The migration initiator sends out incremental data packets one by one according to the segment sequence number. Each time the migration receiver receives an incremental data packet, it appends it to the end of the queue in the incremental data temporary storage area, and simultaneously, the network layer immediately sends a reception acknowledgment (ACK) signal back to the initiator. This acknowledgment signal explicitly carries the total number of data packets successfully received and the cumulative length of bytes received.

[0118] During this period, a separate timer thread within the migration initiator continuously monitors and updates the remaining length of the current expected retention window. (Right now: ,in (Time elapsed since the start of the migration).

[0119] The transmission control logic adjusts in real time based on the relationship between the remaining time window and the safety margin. If If the value is greater than or equal to the preset safety margin limit (e.g., set to 1.5 seconds), the transmission will continue at the established compression ratio and rate. If detected... If the data is less than the safety margin limit, it indicates that the vehicle speed is increasing or the channel is congested, causing the time window to expire. At this point, the sending end immediately triggers emergency control: it actively increases the dynamic dictionary data compression ratio of subsequent unsent data packets (by reducing the dictionary code word length or expanding the matching range) to forcibly reduce the total number of bytes in subsequent unsent data packets; at the same time, it increases the underlying sending window and sending rate to ensure that all incremental data is delivered to the receiver before the vehicle completely leaves the overlap area.

[0120] Furthermore, the steps of performing consistency comparison and orderly writing of the change time data in each data packet with the local current state time data include:

[0121] After detection, each data packet is decompressed and its version tracking clock is extracted, and then compared with the local clock component by component.

[0122] If each component is later than or equal to the local component, write the data directly to the main storage area.

[0123] If a component exists earlier than the local timestamp, compare it with the original global timestamp. If the timestamp of the decompressed data is larger, perform an overwrite write; otherwise, discard it if the local timestamp is larger.

[0124] If the timestamps are the same and there is a branch conflict, the decision to write or discard is made based on the sender number and the preset priority order table. If any data packet is processed abnormally, the processing is terminated and a submission failure signal is sent back.

[0125] In this embodiment, once the migration receiver confirms that it has collected all the expected number of incremental data packets within its incremental data storage interval and that the cyclic redundancy check (CRC) has passed, it initiates the core atomic ordered commit operation:

[0126] Incremental data packets are retrieved sequentially from the head of the queue in the temporary storage area and decompressed to restore the original state change operation, value, storage offset address, and the data version tracking clock value (version vector clock used in this embodiment) added by the sender when maintaining the data. Using the target vehicle ID as an index, retrieve the corresponding local state record in the main runtime storage area and extract the local version tracking clock value. .

[0127] Then, the decompressed result With local Perform component-by-component (corresponding to each edge node dimension) numerical comparisons and divide the following three decision paths based on the clock evolution relationship:

[0128] Path 1 (Evolutionary Write): If All component clock values ​​are greater than or equal to Based on the corresponding component value, the incremental data is determined to be a newer version in terms of logical timing. The changed value is then written directly to the corresponding memory address in the main storage area according to its storage offset address.

[0129] Path Two (Conflicting Timestamp Arbitration): If a conflict is found during comparison There exists a component earlier than The corresponding component indicates that a version fork occurred due to multipath transmission or concurrent processing. At this point, the original global absolute timestamp carried in the decompressed data is further extracted. , compared with the original global absolute timestamp of the local record Perform a numerical comparison. If... This indicates that the decompressed data is updated in physical time, and an overwrite operation is performed to synchronously update the local tracking clock; if If the data is found to be outdated, it will be discarded.

[0130] Path 3 (Conflict Node Priority Arbitration): If a conflict occurs and In the extreme case where the version vector clocks are completely equal but have concurrent branch differences, the source edge node number carried in the data packet is read, and the locally stored priority order table is consulted. If the source node has a higher priority, the write operation is allowed to overwrite; otherwise, it is discarded.

[0131] Throughout the atomic commit process, this invention sets strict transaction consistency boundaries: if any data packet fails to decompress, fails to verify, or is written to memory abnormally, the receiver will immediately and unconditionally terminate the processing of all subsequent data packets, clear the entire temporary storage area and mark it as invalid, and simultaneously send a commit failure signal to the initiator. This ensures that the data in the main storage area is absolutely not contaminated and prevents the same target from being repeatedly counted by two edges and assigned different IDs or annihilated by the trajectory.

[0132] like Figure 2 The diagram shown is a structural schematic of an edge computing-based intelligent transportation data processing system provided in this application embodiment. The edge computing-based intelligent transportation data processing system provided in this application embodiment includes: a time window calculation module, a prepared response feedback module, an incremental data packet segmentation module, a consistency comparison module, and a context data release module.

[0133] The time window calculation module is used by the migration initiator to calculate the expected retention time window based on the driving status of the target vehicle and the coverage area boundary, and send a preparation request containing the window and its own processing capacity to the migration receiver.

[0134] The preparation response feedback module is used to provide a preparation response containing the maximum push length and the recommended compression ratio after the migration receiver compares its own processing capabilities with the preparation request.

[0135] The incremental data packet segmentation module is used by the migration initiator to extract the incremental change records of the target vehicle according to the prepared response, compress them, segment them into multiple incremental data packets that meet the maximum push length, and send them one by one.

[0136] The consistency comparison module is used by the migration receiver to receive and temporarily store the multiple incremental data packets, and after confirming their completeness, to perform consistency comparison and orderly writing of the change time data in each data packet with the local current status time data.

[0137] The context data release module is used to send a success instruction after the migration receiver completes the writing process. The migration initiator then releases the locally stored context data of the target vehicle based on the success instruction and the local data call count.

[0138] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0139] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0140] Those skilled in the art will recognize that the modules 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 implementation should not be considered beyond the scope of this application.

[0141] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0142] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0143] In conclusion, 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 smart transportation data processing method based on edge computing, characterized in that, Includes the following steps: The migration initiator calculates the expected retention time window based on the target vehicle's driving status and the coverage area boundary, and sends a preparation request containing the window and its own processing capacity to the migration receiver. After comparing its own processing capabilities with the preparation request, the migration receiver sends out a preparation response containing the maximum push length and the recommended compression ratio. The migration initiator extracts the incremental change records of the target vehicle based on the prepared response, compresses them, divides them into multiple incremental data packets that meet the maximum push length, and sends them one by one. The migration receiver receives and temporarily stores the multiple incremental data packets, and after confirming their completeness, performs a consistency comparison between the change time data in each data packet and the local current state time data, and writes them in an orderly manner. After the migration receiver completes the write operation, it sends out a success command. The migration initiator then releases the locally stored context data of the target vehicle based on the success command and the local data call counter.

2. The intelligent transportation data processing method based on edge computing as described in claim 1, characterized in that, The steps for calculating the expected retention time window and sending a preparation request containing that window and the recipient's own processing capacity include: The system acquires the instantaneous speed and direction angle of the target vehicle and reads the network coverage overlap boundary data between the two processing nodes. The vehicle's trajectory is intersected by a straight line projection of the network coverage overlap boundary data to determine the entry and exit points, and the expected retention time window is calculated by combining the instantaneous motion speed value. The target vehicle's identification number, current version number, expected retention time window, number of tasks waiting to be processed in its queue, and number of available idle data locations are combined to generate the preparation request, which is then sent to the migration recipient.

3. The intelligent transportation data processing method based on edge computing as described in claim 1, characterized in that, The steps for preparing a response that includes the maximum push length and recommended compression ratio are as follows: Obtain its own queuing task depth and the number of available computing positions, and compare them with the initiator's value in the preparation request; Based on the comparison results, calculate the maximum data block length that can safely handle data and the recommended data compression ratio baseline value; If it is determined that there are enough available locations, the response includes a migration permission flag, the maximum data block length limit, the recommended data compression ratio baseline value, and its own clock count, and is then sent. If it is determined that there are not enough available locations, a migration rejection flag is included in the response so that the migration initiator puts the migration task into the waiting queue.

4. The intelligent transportation data processing method based on edge computing as described in claim 1, characterized in that, The steps for extracting and compressing the incremental change records of the target vehicle include: Locate the historical full state data storage area belonging to the target vehicle in the local storage space, and extract the data version checkpoint timestamp marked when the last successful migration was completed; The log entries for all data changes up to the current time are traversed using this timestamp. The log entries include rewritten records of vehicle position, speed vector, associated target tracking feature values, and intermediate variables for intention prediction. Arrange the data change operation log entries in chronological order of their occurrence; For each log entry, only the changed value and the address offset of that value in storage are extracted and combined to form the initial incremental data set.

5. The intelligent transportation data processing method based on edge computing as described in claim 1, characterized in that, The steps of extracting and compressing the incremental change records of the target vehicle, and dividing them into multiple incremental data packets that meet the maximum push length include: Based on the recommended data compression ratio benchmark value in the prepared response, a data compression operation with dynamic feature dictionary matching is performed on the initial incremental data set; In the data compression operation, the repeated field patterns in the data stream to be compressed are counted in real time and a temporary dictionary table is dynamically constructed to map the repeated patterns to shorter variable-length encoded words. Based on the real-time compression ratio feedback of the transmitted data blocks, the encoding mapping strategy of subsequent data blocks is dynamically adjusted so that the overall compression ratio approaches the benchmark value. After compression, the generated incremental data stream is divided into multiple incremental data packets, ensuring that the size of each incremental data packet does not exceed the maximum data block length limit.

6. The intelligent transportation data processing method based on edge computing as described in claim 1, characterized in that, The steps for the migration receiver to receive and temporarily store the multiple incremental data packets include: Before transmission, the migration initiator does not perform deletion and write locking on the target vehicle state context stored locally, marks it as a read-only proxy state, and maintains a lightweight access count pointer in memory to record the number of local processes that depend on this data. When the migration receiver receives the first incremental data packet, it does not immediately decompress it or merge it into the runtime main storage area, but instead opens an independent incremental data temporary storage area in its own storage space. The incremental data temporary storage area maintains an ordered queue according to the receiving order, where each entry stores the original compressed data packet, the data version tracking clock value, and the sending timestamp.

7. The intelligent transportation data processing method based on edge computing as described in claim 1, characterized in that, The steps of sending multiple incremental data packets that meet the maximum push length one by one include: The incremental data packets are sent one by one in the segmentation order. Each time the migration receiver receives an incremental data packet, it stores it completely at the end of the queue of the incremental data temporary storage area and sends back a reception confirmation signal to the migration initiator, carrying the total number of data packets received and the cumulative byte length. During transmission, continuously monitor the remaining length of the current expected retention time window; If the remaining length value is detected to be less than the preset safety margin limit, the dynamic dictionary data compression ratio of subsequent unsent data packets is actively increased to reduce the total number of bytes in subsequent data packets, and the sending rate is adjusted at the same time.

8. The intelligent transportation data processing method based on edge computing as described in claim 1, characterized in that, The steps for performing consistency comparison and ordered writing of the changed time data in each data packet with the local current state time data include: After detection, each data packet is decompressed and its version tracking clock is extracted, and then compared with the local clock component by component. If each component is later than or equal to the local component, write the data directly to the main storage area. If a component exists earlier than the local timestamp, compare it with the original global timestamp. If the timestamp of the decompressed data is larger, perform an overwrite write; otherwise, discard it if the local timestamp is larger. If the timestamps are the same and there is a branch conflict, the decision to write or discard is made based on the sender number and the preset priority order table. If any data packet is processed abnormally, the processing is terminated and a submission failure signal is sent back.

9. An edge computing-based intelligent transportation data processing system, used to implement the edge computing-based intelligent transportation data processing method according to any one of claims 1-8, characterized in that, include: The module includes a time window calculation module, a response preparation and feedback module, an incremental data packet segmentation module, a consistency comparison module, and a context data release module. The time window calculation module is used by the migration initiator to calculate the expected retention time window based on the driving status of the target vehicle and the coverage area boundary, and send a preparation request containing the window and its own processing capacity to the migration receiver. The preparation response feedback module is used to provide a preparation response containing the maximum push length and the recommended compression ratio after the migration receiver compares its own processing capabilities with the preparation request. The incremental data packet segmentation module is used by the migration initiator to extract the incremental change records of the target vehicle according to the prepared response, compress them, segment them into multiple incremental data packets that meet the maximum push length, and send them one by one. The consistency comparison module is used by the migration receiver to receive and temporarily store the multiple incremental data packets, and after confirming their completeness, to perform consistency comparison and orderly writing of the change time data in each data packet with the local current status time data. The context data release module is used to send a success instruction after the migration receiver completes the writing process. The migration initiator then releases the locally stored context data of the target vehicle based on the success instruction and the local data call count.

Images