Logistics transportation traceability management method based on big data analysis

CN122948384APending Publication Date: 2026-10-20FUJIAN MINCHI NEW ENERGY CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611448227.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-09-17
Publication Date
2026-10-20

AI Technical Summary

Technical Problem

[0003]本发明提供一种基于大数据分析的物流运输溯源管理方法,目的在于解决分布式物流节点时钟不一致导致的溯源时序错乱,以及缺乏可信第三方时难以对分段运输数据进行完整性校验的问题,实现跨节点的货物运输链路精准还原和可靠溯源

Benefits of technology

[0016]通过获取物流运输网络的节点分布数据和各节点的历史货物吞吐时序数据,计算相邻节点间的货物流转时延区间。该货物流转时延区间反映了货物从一个节点离开至到达下一节点所经历的客观时间跨度范围,由大量历史样本统计分析得到,剔除了极值干扰,能够表征相邻节点间流转耗时的正常边界。利用货物流转时延区间对各节点进行初始时间基准标定,得到各节点的初始时间基准偏移量。在标定过程中,选取一个基准节点并将其初始偏移量置零,然后沿物流路径依次将当前节点与上一已标定节点的本地时钟读数之差减去两节点间货物流转时延区间的中值,所得值作为当前节点的初始时间基准偏移量。这一操作将各节点本地时钟读数映射到统一的时间基准上,使得原本因时钟不同步而不可比的记录时间经偏移修正后变得可比。根据各节点的初始时间基准偏移量对实时货物运单数据中各途经节点的实际记录时间进行偏移修正,得到每个途经节点的修正记录时间,并基于修正记录时间与货物状态信息生成分段数据包。由于修正记录时间消除了节点间的时钟差异,分段数据包中所携带的时间信息能够真实反映货物在物理世界中的流转先后顺序,为后续的时序校验提供准确的时间锚点。对每个分段数据包赋予其对应节点的哈希时间戳,并基于相邻分段数据包的哈希时间戳差异值构建链式验证索引表。哈希时间戳由修正记录时间转换为统一格式的时间字符串后,混入节点唯一标识符作为盐值进行哈希运算得到,使得哈希时间戳既蕴含时间信息又与该节点绑定。相邻分段数据包的哈希时间戳差异值通过按位异或运算产生,差异值的大小与相邻节点之间的货物流转时延区间存在内在关联。在溯源查询时,从链式验证索引表中提取目标分段数据包序列,依次计算相邻节点的哈希时间戳差异值,并校验该差异值是否落入对应相邻节点间的货物流转时延区间内。当差异值处于区间内时,表明当前分段的记录时间与前序分段的记录时间之间的偏差符合物理流转规律,从而无需中心化校验方即可判定该分段数据包与前序分段数据包在时间和内容上保持关联一致。任何对分段数据包中的时间或状态信息的篡改都会导致重算的哈希时间戳发生改变,进而在异或运算下产生偏离正常流转时延区间的差异值,被校验环节检出并标记为异常节点。这种基于哈希时间戳差异值与物理流转时延区间比对的检验机制,使得溯源链路中的每个数据片段都可被独立验证,实现去中心化的完整性保护,并能够精确定位发生异常的物流节点。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure FT_1
    Figure FT_1
  • Figure FT_2
    Figure FT_2
  • Figure FT_3
    Figure FT_3
Patent Text Reader

Abstract

This invention discloses a logistics transportation traceability management method based on big data analysis, belonging to the field of logistics transportation traceability management technology. The method acquires node distribution data and historical cargo throughput time-series data of the logistics transportation network, calculates the cargo flow delay interval between adjacent nodes, and performs initial time base calibration for nodes to obtain the initial time base offset. Real-time cargo waybill data is split into segmented data packets ordered by nodes, each segmented data packet is assigned a hash timestamp, and a chain-based verification index table is constructed. When a cargo traceability query request is received, the difference between the hash timestamp of each node's segmented data packet and the hash timestamp of the preceding node is checked sequentially according to the chain-based verification index table to see if it falls within the cargo flow delay interval. If all differences are within the interval, the complete traceability link data is concatenated and output. This method can eliminate the impact of multi-node clock differences on traceability timing and achieve decentralized traceability data integrity verification.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of logistics and transportation traceability management technology, specifically a logistics and transportation traceability management method based on big data analysis. Background Technology

[0002] In logistics and transportation traceability management, it is necessary to record and trace the arrival and departure times and status information of goods at each node along their route in a chain. Existing solutions typically use the timestamps recorded by the local clocks of each logistics node to construct the cargo waybill flow data, and rely on centralized databases or third-party notary platforms to store and verify the authenticity of the records. Because the clocks of different logistics nodes operate independently and lack a unified benchmark, there are systematic deviations in the arrival and departure times recorded by each node. This makes it difficult for the cargo transportation chain reconstructed based on the original timestamps to accurately reflect the actual flow process in terms of time sequence. When tracing changes in cargo status, time deviations can cause breakpoints or overlaps in the status connection between adjacent nodes, reducing the credibility of traceability information. At the same time, under centralized storage, once the storage terminal is attacked or internally tampered with, segmented transportation data can be completely replaced or modified, and there is a lack of means to independently verify at the data segment level, making it very difficult to locate abnormal links. In a distributed logistics network where the clocks of different nodes are not synchronized, how to incorporate the local recorded times of different nodes into a comparable time series benchmark and eliminate the interference of clock asynchrony on the verification of the time series of goods flow is a problem that current technology has not yet solved. Furthermore, how to utilize the inherent characteristics of segmented data to determine the integrity of recorded data between adjacent nodes under the constraint of a decentralized trusted verification party, and thereby construct a traceability link with tamper-proof capabilities, is also a key challenge that needs to be addressed. Summary of the Invention

[0003] This invention provides a logistics transportation traceability management method based on big data analysis. The purpose is to solve the problem of traceability timing disorder caused by inconsistent clocks of distributed logistics nodes, and the difficulty in verifying the integrity of segmented transportation data when there is no trusted third party, so as to realize accurate restoration and reliable traceability of cargo transportation links across nodes.

[0004] To achieve the above objectives, the present invention provides the following technical solution: The present invention provides a logistics transportation traceability management method based on big data analysis, the method comprising: acquiring node distribution data of the logistics transportation network and historical cargo throughput time series data of each node; calculating the cargo flow delay interval between adjacent nodes based on the historical cargo throughput time series data of each node, and using the cargo flow delay interval to perform initial time base calibration on each node to obtain the initial time base offset of each node; and, based on the initial time base offset of each node, splitting the real-time cargo waybill data of the logistics transportation network into sub-data items sorted by node. The system generates segmented data packets. Each segmented data packet is assigned a hash timestamp corresponding to its corresponding node. Based on the differences in hash timestamps between adjacent segmented data packets, a chain-like verification index table for the logistics and transportation network is constructed. When a cargo traceability query request is received, the system uses the chain-like verification index table to sequentially verify whether the differences between the hash timestamps of the segmented data packets at each node along the query path and the hash timestamps of the preceding node's segmented data packets are within the cargo flow delay interval. If all differences are within the cargo flow delay interval, the segmented data packets at each node along the query path are concatenated in chronological order to form complete traceability link data and output.

[0005] Through the above steps, a unified time base is established for each node using the historical cargo flow delay interval, eliminating the interference of asynchronous clocks among multiple nodes in the logistics network on the traceability link. This makes cargo records from different nodes comparable under a unified time coordinate. By splitting the waybill data based on the initial time base offset and assigning hash timestamps, a verifiable expression of the flow time between nodes can be achieved without exposing the original time information. Combined with the construction of a chain-based verification index table, a tamper-proof and segment-by-segment verifiable traceability chain is established for each batch of goods. When a traceability query is received, it is only necessary to compare the hash timestamp difference value with the flow delay interval according to the index table to quickly and accurately determine the compliance of the cargo flow between each node. After all verifications are passed, the complete traceability link is automatically spliced ​​and output. This significantly reduces the computation and communication overhead of centralized data verification while ensuring the integrity and authenticity of traceability data.

[0006] As a preferred technical solution of the present invention, when calculating the cargo flow delay interval between adjacent nodes, the arrival and departure timestamps of the same cargo identifier at each node are extracted from the historical cargo throughput time-series data of each node; the difference between the departure and arrival timestamps of the same cargo identifier at two adjacent nodes is used as a single flow delay sample; all single flow delay samples of cargo identifiers between two adjacent nodes are summarized to form a flow delay sample set; after removing the maximum and minimum values ​​from the flow delay sample set, the minimum value of the remaining flow delay samples is used as the lower limit of the flow delay interval, and the maximum value of the remaining flow delay samples is used as the upper limit of the flow delay interval. Thus, by determining the flow delay interval through the sample boundaries after removing extreme values, the disturbance of occasional anomalies to the interval estimation can be effectively suppressed, making the normal flow delay range more robust.

[0007] As another preferred technical solution of the present invention, when calibrating the initial time base of each node, any node in the logistics transportation network is selected as the reference node, and the initial time base offset of the reference node is set to zero. Starting from the reference node, each uncalibrated node is traversed sequentially along the path direction of the logistics transportation network. The difference between the local clock reading of the currently traversed uncalibrated node and the local clock reading of the previous calibrated node is subtracted from the median value of the cargo flow delay interval between the previous calibrated node and the currently traversed uncalibrated node to obtain the initial time base offset of the currently traversed uncalibrated node. The calculated initial time base offset is assigned to the currently traversed uncalibrated node, and the process continues to traverse the next uncalibrated node until all nodes are assigned an initial time base offset. This calibration method uses the actual physical duration of cargo flow as a medium to unify the clocks of each node to a time scale consistent with the logistics flow process, so that the time correction of subsequent segmented data packets has a clear logistics business basis.

[0008] As a further preferred technical solution of the present invention, when splitting real-time freight waybill data into segmented data packets sorted by nodes, the sequence of passing nodes and the actual recording time of each passing node recorded in the real-time freight waybill data are obtained; the actual recording time of the corresponding passing node is offset and corrected according to the initial time base offset of each passing node to obtain the corrected recording time of each passing node; the cargo status information corresponding to each passing node is extracted from the real-time freight waybill data according to the order of passing nodes; the corrected recording time of each passing node and the cargo status information corresponding to that node are encapsulated to generate segmented data packets corresponding to each passing node; all segmented data packets are sorted according to the order of passing nodes to obtain a segmented data packet sequence sorted by nodes. Through offset correction, the original time recorded by each node is uniformly converted into a logical time consistent with the base node, avoiding the timing logic disorder caused by time zone, clock drift and other factors, and ensuring the time consistency of the segmented data packet sequence.

[0009] As another preferred technical solution of the present invention, when constructing the chained verification index table, the correction record time in each segmented data packet is converted into a time string of a unified format, and a hash operation is performed on the time string to obtain the hash timestamp of each segmented data packet; the hash timestamp of the previous segmented data packet of the current segmented data packet is read, and a bitwise XOR operation is performed between the hash timestamp of the previous segmented data packet and the hash timestamp of the current segmented data packet to obtain the hash timestamp difference value of adjacent segmented data packets; the node identifier, hash timestamp, and hash timestamp difference value of the current segmented data packet are stored as an index record in the chained verification index table; the reading and operation steps are repeated until all segmented data packets have been processed to obtain a complete chained verification index table. This index table solidifies the time association between adjacent nodes in the form of chained XOR difference values. Any tampering with the time information of the segmented data packets will cause a drastic change in the difference value, thereby giving the traceability link a high degree of tamper detection capability.

[0010] Furthermore, when performing hash operations on the time string, the SHA-256 hash algorithm is used, and the unique node identifier of the node is mixed into the time string as a hash salt. Adding the node identifier as a salt effectively prevents different nodes from generating the same hash value under the same time string, avoids hash collisions, and enhances the uniqueness and collision resistance of the hash timestamp.

[0011] When implementing traceability verification, the preferred technical solution involves parsing the cargo identifier and query time range from the cargo traceability query request; selecting target segmented data packet sequences that match the cargo identifier from the segmented data packets based on the cargo identifier; extracting the node identifier and hash timestamp corresponding to each target segmented data packet from the target segmented data packet sequence; performing a bitwise XOR operation between the hash timestamp of the current node and the hash timestamp of the previous node according to the order of nodes in the target segmented data packet sequence to obtain the verification difference value; comparing the verification difference value with the cargo flow delay interval between the current node and the previous node to determine whether the verification difference value falls within the cargo flow delay interval. By recalculating the difference value and comparing it with the pre-established delay interval, the compliance determination of the flow can be completed without restoring the original time data, thus balancing data privacy protection and traceability verification requirements.

[0012] Preferably, when comparing the difference value with the cargo flow delay interval, if the verified difference value falls within the range after the upper and lower limits of the cargo flow delay interval are each extended by a preset tolerance threshold, then the verified difference value is determined to be within the cargo flow delay interval. Introducing a preset tolerance threshold can absorb minor deviations caused by hash operation precision truncation or system timing jitter, improving the robustness of the verification method and preventing normal nodes from being misjudged as abnormal due to non-substantial differences.

[0013] When all discrepancies pass verification, the preferred output scheme uses the determination that all discrepancies fall within the cargo flow delay range as the link integrity identifier, which is written into the header field of the traceability result data packet. The segmented data packets corresponding to each node on the query path are read from the chain verification index table and sorted in ascending order according to the chronological order of the correction record time of each node. The cargo status information in the ascending-ordered segmented data packets is extracted sequentially and concatenated into a cargo status evolution sequence according to the sorting order. The cargo status evolution sequence and the header field of the traceability result data packet are combined to form complete traceability link data, which is then output to the terminal that issued the cargo traceability query request. The output traceability link data thus contains both a time-evolving record of the cargo's full status and a link integrity identifier, allowing the querying party to clearly confirm whether the traceability result has been fully verified.

[0014] If, during the verification process, a difference value exists that is not within the cargo flow delay interval, the method of this invention also includes an anomaly handling mechanism. Specifically, this involves: traversing the hash timestamp difference values ​​of all adjacent nodes on the query path, recording nodes whose hash timestamp difference values ​​do not fall within the corresponding cargo flow delay interval as abnormal nodes; using the abnormal node as a dividing point, extracting the node preceding the abnormal node from the query path as the preceding normal node, and extracting the node following the abnormal node as the following normal node; extracting the cargo status information from the segmented data packets corresponding to the preceding normal node as preceding status reference data; extracting the cargo status information from the segmented data packets corresponding to the following normal node as following status reference data; and associating and storing the preceding status reference data, following status reference data, and the node identifier of the abnormal node in an anomaly record table. This segmented extraction and reference data storage method enables rapid location of abnormal nodes when a flow anomaly is detected, and retains the normal status information of the preceding and following stages as a basis for auditing or traceability analysis. This ensures the continuity of the traceability process and provides data support for the accurate handling of abnormal events.

[0015] The technical effects and advantages provided by the present invention in the above technical solution are as follows:

[0016] By acquiring node distribution data and historical cargo throughput time-series data of each node in the logistics transportation network, the cargo flow delay interval between adjacent nodes is calculated. This cargo flow delay interval reflects the objective time span from when cargo leaves one node to when it arrives at the next node. It is obtained through statistical analysis of a large number of historical samples, eliminating extreme value interference, and can characterize the normal boundary of the flow time between adjacent nodes. The cargo flow delay interval is used to calibrate the initial time base of each node, obtaining the initial time base offset of each node. During the calibration process, a reference node is selected and its initial offset is set to zero. Then, along the logistics path, the difference between the local clock readings of the current node and the previous calibrated node is subtracted from the median of the cargo flow delay interval between the two nodes. The resulting value is used as the initial time base offset of the current node. This operation maps the local clock readings of each node to a unified time base, making previously incomparable recorded times due to clock asynchrony comparable after offset correction. The actual recording time of each transit node in the real-time freight waybill data is offset and corrected based on the initial time base offset of each node, resulting in the corrected recording time for each transit node. Segmented data packets are then generated based on the corrected recording time and freight status information. Since the corrected recording time eliminates clock differences between nodes, the time information carried in the segmented data packets accurately reflects the flow sequence of goods in the physical world, providing an accurate time anchor for subsequent time sequence verification. Each segmented data packet is assigned a hash timestamp of its corresponding node, and a chained verification index table is constructed based on the difference in hash timestamps between adjacent segmented data packets. The hash timestamp is obtained by converting the corrected recording time into a unified format time string, mixing it with the node's unique identifier as a salt value, and performing a hash operation. This ensures that the hash timestamp contains time information and is bound to the node. The difference in hash timestamps between adjacent segmented data packets is generated through a bitwise XOR operation, and the magnitude of the difference is intrinsically related to the freight flow delay interval between adjacent nodes. During traceability queries, the target segment data packet sequence is extracted from the chained verification index table. The hash timestamp differences between adjacent nodes are calculated sequentially, and it is verified whether these differences fall within the cargo flow delay interval between the corresponding adjacent nodes. When the difference is within the interval, it indicates that the deviation between the current segment's recording time and the previous segment's recording time conforms to the physical flow pattern. Therefore, a centralized verification party can determine that the segment data packet is consistent with the previous segment data packet in terms of time and content. Any tampering with the time or status information in the segment data packet will cause the recalculated hash timestamp to change, resulting in a difference value deviating from the normal flow delay interval under XOR operation. This difference value is detected by the verification process and marked as an abnormal node. This verification mechanism, based on comparing hash timestamp differences with the physical flow delay interval, allows each data segment in the traceability chain to be independently verified, achieving decentralized integrity protection and enabling precise location of abnormal logistics nodes. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0018] Figure 1 This is a flowchart of a logistics transportation traceability management method based on big data analysis;

[0019] Figure 2 This is a schematic diagram showing the distribution of single-transfer delay samples and the transfer delay intervals between adjacent nodes;

[0020] Figure 3 It is a curve showing the change in the initial time base offset of each path node in the logistics transportation network;

[0021] Figure 4 It is a time change curve of the correction record of multiple cargo identification nodes;

[0022] Figure 5 This is a distribution chart of hash timestamp differences between adjacent data packets in the chained verification index table. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] See Figure 1This invention provides a logistics transportation traceability management method based on big data analysis, comprising: acquiring node distribution data of the logistics transportation network and historical cargo throughput time series data of each node; calculating the cargo flow delay interval between adjacent nodes based on the historical cargo throughput time series data of each node, and using the cargo flow delay interval to perform initial time base calibration on each node to obtain the initial time base offset of each node; dividing the real-time cargo waybill data of the logistics transportation network into segmented data packets sorted by node based on the initial time base offset of each node; and processing each segmented data packet... The system assigns a hash timestamp to the corresponding node for each data packet and constructs a chain-based verification index table for the logistics transportation network based on the hash timestamp differences between adjacent data packets. When a cargo traceability query request is received, the system checks, according to the chain-based verification index table, whether the difference between the hash timestamp of each data packet segment on the query path and the hash timestamp of the preceding data packet segment is within the cargo flow delay interval. If all differences are within the cargo flow delay interval, the data packets segmented from each node on the query path are concatenated into complete traceability link data in chronological order and output.

[0025] In practice, the arrival and departure timestamps of the same cargo identifier at each node are extracted from the historical cargo throughput time-series data of each node. The historical cargo throughput time-series data is stored in a distributed data warehouse, and each data record contains four fields: cargo identifier, node identifier, event type, and timestamp. The event type field takes the value "arrival" or "departure". The extraction process is completed using the MapReduce computing framework. In the Map phase, the cargo identifier is used as the key, and the combination of node identifier, event type, and timestamp is used as the value for output. In the Reduce phase, all event records corresponding to the same cargo identifier are sorted in ascending order of timestamp, forming a full-path event sequence for the cargo in the logistics transportation network. For any two adjacent nodes in the full-path event sequence, the departure timestamp of the preceding node and the arrival timestamp of the following node constitute a pair of time boundaries for calculating the single-transfer delay.

[0026] Optionally, if the same cargo identifier has multiple arrival or departure records at the same node, the arrival record with the earliest timestamp is used as the arrival timestamp, and the departure record with the latest timestamp is used as the departure timestamp. If a cargo identifier has only an arrival record at a node but lacks a departure record, the arrival record is removed from the full path event sequence and does not participate in subsequent calculations.

[0027] The difference between the departure and arrival timestamps of the same cargo identified at two adjacent nodes is used as the sample of single-transfer delay. Let the two adjacent nodes be denoted as nodes. and nodes ,node For upstream nodes, node For downstream nodes, the cargo is identified as Goods identification At the node The departure timestamp is At the node The arrival timestamp is Then the goods identification In two adjacent nodes and Single-transfer delay samples Calculated using the following formula:

[0028]

[0029] in, Goods identification At the node The arrival timestamp is a Unix timestamp, in seconds; Goods identification At the node The departure timestamp, which is a Unix timestamp and is in seconds; Goods identification At the node and nodes The single-transfer delay sample between them, in seconds.

[0030] The single-transfer delay samples of all cargo identifiers between two adjacent nodes are aggregated to form a transfer delay sample set. The transfer delay sample set is indexed by node pairs, and each node pair corresponds to a sample list, which stores the single-transfer delay samples generated by all cargo identifiers passing through that node pair.

[0031] After removing the maximum and minimum values ​​from the latency sample set, the minimum value of the remaining latency samples is taken as the lower limit of the latency interval, and the maximum value of the remaining latency samples is taken as the upper limit of the latency interval. In practice, the sample list in the latency sample set is sorted in ascending order of numerical value, and the first and last elements of the sorted sample list are deleted. After deletion, the value of the first element in the sample list is taken as the lower limit of the latency interval, and the value of the last element in the sample list is taken as the upper limit of the latency interval.

[0032] In some embodiments, if the number of samples in the sample list corresponding to a node pair in the flow delay sample set is less than or equal to two, then the operation of removing the maximum and minimum values ​​is not performed. Instead, the minimum value in the sample list is directly used as the lower limit of the flow delay interval, and the maximum value in the sample list is used as the upper limit of the flow delay interval. If the sample list contains only one sample, then both the lower limit and upper limit of the flow delay interval are set to the value of that sample. If the sample list is empty, then the lower limit of the flow delay interval is set to zero, and the upper limit of the flow delay interval is set to a preset maximum delay threshold. The preset maximum delay threshold is obtained by: statistically analyzing the flow delay samples of all node pairs globally from the logistics transportation network, taking the maximum value in the global flow delay samples, and multiplying it by an expansion coefficient, which is set to 1.2.

[0033] See Figure 2 The figure illustrates the numerical distribution of single-transfer delay samples between different adjacent node pairs calculated from historical cargo throughput time-series data in this embodiment. The horizontal axis represents different node pairs, in order: node A-node B, node B-node C, node C-node D, node D-node E, node E-node F, node F-node G, node G-node H, node H-node I, node I-node J, and node J-node K. The vertical axis represents the single-transfer delay in seconds, ranging from approximately 0 seconds to 8000 seconds.

[0034] The single-transfer delay samples of each node pair are distributed in a scattered manner within the corresponding interval of the vertical axis, reflecting the dispersion and distribution characteristics of the actual delay samples of goods transfer between the node pairs. The two horizontal dashed lines in the figure represent the lower limit (solid line) and upper limit (dotted line) of the transfer delay interval, respectively. These interval boundaries are calculated by removing the maximum and minimum values ​​and taking the extreme values ​​of the remaining samples, and are used for subsequent time benchmark calibration and traceability verification.

[0035] As can be seen from the figure, there are significant differences in the flow delay ranges between the node pairs. For example, the flow delay sample range for node E-node F is wide, with a dense scatter distribution and a maximum value approaching 8000 seconds, indicating a relatively high upper limit and reflecting large fluctuations in the flow delay between these nodes. In contrast, the flow delay sample for node G-node H is more concentrated and the overall value is lower, with the upper and lower limits of the range significantly lower than those for node E-node F, showing that the flow delay between these node pairs is more stable and shorter.

[0036] Furthermore, the flow delay intervals for node pairs such as node B-node C and node J-node K are relatively narrow, with the lower and upper limits being quite close, indicating that the flow delays between these node pairs are relatively fixed and have minimal fluctuations. The sample distributions for node D-node E and node F-node G exhibit moderate fluctuations, with the interval width falling in the middle of the node pairs in the figure.

[0037] In practical implementation, any node in the logistics transportation network is selected as the reference node, and the initial time base offset of the reference node is set to zero. The logistics transportation network is abstracted as a directed acyclic graph, where vertices represent logistics nodes, and directed edges represent the direction of cargo flow between nodes, with the direction of the directed edges consistent with the direction of the cargo transportation path. All node identifiers and their adjacency relationships are obtained from the node distribution data of the logistics transportation network, and an adjacency list structure is constructed. Each node in the adjacency list corresponds to a list of outgoing edge nodes, recording the set of downstream nodes that can be directly reached from that node.

[0038] The method for selecting the baseline node is as follows: obtain the historical total cargo throughput of each node in the logistics transportation network, and select the node with the largest historical total cargo throughput as the baseline node. The historical total cargo throughput is obtained by summarizing the historical cargo throughput time-series data of each node according to the node identifier.

[0039] Starting from the base node, traverse each unmarked node sequentially along the path of the logistics transportation network. The traversal process employs a breadth-first search strategy, maintaining a queue of nodes to be visited. Add the base node to the queue and mark it as a marked node. Retrieve a marked node from the head of the queue, and traverse its outgoing edge list. For each unmarked node in the outgoing edge list that has not yet been marked, designate the marked node as its direct predecessor. Perform initial time base offset calculation on the unmarked node, mark it as a marked node, and add it to the tail of the queue. Repeat the process of retrieving the head node and processing its outgoing edges until the queue is empty.

[0040] The initial time base offset of the currently traversed uncalibrated node is obtained by subtracting the median of the cargo flow delay interval between the previous calibrated node and the local clock reading of the currently traversed uncalibrated node from the difference between the local clock reading of the currently traversed uncalibrated node and the local clock reading of the previous calibrated node. Let the previous calibrated node be denoted as... The currently traversed unlabeled node is .node The local clock reading is ,node The local clock reading is ,node With nodes The median value of the cargo flow delay interval between them is ,node The initial time base offset is The initial time base offset The calculation formula is:

[0041]

[0042] in, Indicates the previously labeled node The local clock reading, in seconds, is generated by the node. The system clock provides this, in Unix timestamp format; This indicates the currently traversed unlabeled node. The local clock reading, in seconds, is generated by the node. The system clock provides this, in Unix timestamp format; Indicates the previously labeled node With the currently traversed unlabeled nodes The median of the cargo flow delay interval, in seconds, is obtained by reading nodes from the cargo flow delay interval data. and nodes Given the upper and lower limits of the transit time interval, calculate the arithmetic mean of the upper and lower limits, and use this arithmetic mean as the median of the transit time interval. ; This indicates the currently traversed unlabeled node. The initial time base offset, in seconds; a positive value indicates a node. The local clock is ahead of the reference time axis; a negative value indicates that the node is ahead. The local clock lags behind the reference time axis.

[0043] The calculated initial time base offset is assigned to the currently traversed uncalibrated node, and the process continues to traverse the next uncalibrated node until all nodes have been assigned the initial time base offset. The assignment process is as follows: [The process continues with the node assignment steps.] initial time base offset The value is written to the node offset mapping table, which uses the node identifier as the key and the initial time base offset as the value, and is stored in a distributed cache. This completes the node... After the assignment, the breadth-first search continues to retrieve the next labeled node from the queue, processes the unlabeled nodes in its outgoing edge node list, and repeats the above calculation and assignment steps until all nodes in the adjacency list are labeled. The node offset mapping table contains the initial time base offset of all nodes in the logistics transportation network.

[0044] In some embodiments, if an unlabeled node has multiple labeled direct predecessor nodes, the labeled node with the smallest median cargo flow delay interval among the unlabeled node is selected as the previous labeled node. If the median cargo flow delay intervals between the unlabeled node and multiple labeled nodes are equal, the labeled node with the smallest node identifier in lexicographical order is selected as the previous labeled node. If an unlabeled node has no labeled direct predecessor nodes, the initial time base offset of the unlabeled node is set to zero, and it is marked as a labeled node and added to the tail of the queue to ensure that the traversal process can cover all connected components in the logistics transportation network.

[0045] See Figure 3 In the figure, the vertical axis represents the "initial time base offset" in seconds, indicating the time base offset of each node in the logistics transportation network relative to the selected base node. The horizontal axis represents the "node traversal order (starting from the base node)," indicating the order in which the breadth-first search traverses the nodes in the logistics transportation network. This figure corresponds to the process of calibrating the initial time base offset of the logistics transportation network nodes based on the breadth-first search strategy in this embodiment.

[0046] The diagram contains three curves representing the changing trends of the initial time base offset of nodes on the main path and two branch paths A and B in the logistics transportation network. The curves connect the corresponding time offset values ​​of each node in a broken line format. The main path curve generally shows a decreasing trend followed by a gradual increase. The initial node's base offset is set to zero. Subsequently, the offset fluctuates slightly negatively between nodes 0 and 50. Between nodes 50 and 150, the offset gradually increases and exceeds zero, reaching a maximum of approximately 130 seconds, before slightly decreasing again. The branch path A curve shows a clear decreasing trend. Starting near the zero point around node traversal number 0, the offset gradually decreases, with a significant decrease, eventually reaching approximately -350 seconds, indicating that the local clock of this branch path node is significantly lagging behind the system clock of the base node. The branch path B curve generally shows a gradual increasing trend. Initially, the offset is slightly negative, then it continuously increases, eventually exceeding 200 seconds, indicating that the local clock of this path node is significantly ahead of the system clock of the base node.

[0047] In practice, the system acquires the sequence of transit nodes and the actual recording time of each node from the real-time freight waybill data. The real-time freight waybill data originates from the waybill status change message stream pushed by the logistics transportation scheduling system. This message stream is transmitted using a message queue built with Apache Kafka, and each message corresponds to a freight waybill's status update event at a specific logistics node. The message body contains four core fields: freight waybill identifier, node identifier, actual recording time, and freight status information. The actual recording time is a Unix timestamp recorded by the local system clock of the logistics node, in seconds. The message processing component consumes messages one by one, aggregating multiple node events for the same waybill based on its identifier to form the sequence of transit nodes for that waybill. The nodes in the sequence are arranged in chronological order of their actual recording times. The sequence of transit nodes is an ordered list, and each element in the list contains a node identifier, actual recording time, and freight status information.

[0048] Based on the initial time base offset of each passing node, the actual recorded time of the corresponding passing node is offset-corrected to obtain the corrected recorded time of each passing node. The offset correction process reads the initial time base offset corresponding to the node identifier of the passing node from the node offset mapping table, which is a mapping structure stored in a distributed cache. Let the first node in the passing node sequence be... Each passing node is identified by its node identifier. Node identifier The corresponding actual recording time is Node identifier The corresponding initial time base offset is Correct the record time to The corrected recording time is calculated using the following formula:

[0049]

[0050] in, Indicates the first node in the sequence of nodes traversed. The node identifier of each node along the route. This represents the position number of the node passed through in the sequence. It is a positive integer, and its value ranges from 1 to the length of the sequence of nodes passed through; Indicates node identifier The corresponding actual recorded time, in seconds, is in Unix timestamp format and is identified by the node. Local system clock records; Indicates node identifier The corresponding initial time base offset, in seconds, is obtained from the node offset mapping table; a positive value indicates the node identifier. The local clock is ahead of the reference time axis, and a negative value indicates lag; Indicates node identifier The corresponding correction record time, in seconds, is in Unix timestamp format and is the time value obtained after unifying the actual record time to the base time axis.

[0051] Following the order of transit nodes, cargo status information corresponding to each transit node is extracted from real-time freight waybill data. Cargo status information includes cargo identifier, waybill status code, temperature sensor reading, humidity sensor reading, packaging integrity identifier, operator identifier, and remarks field. Waybill status codes include enumerated values ​​such as "collected," "in transit," "arrived at transit," "departed from transit," "delivered," and "signed for." When extracting cargo status information, the corresponding values ​​are read by field name from the status data block of each element in the transit node sequence. For some transit nodes where some sensor readings may be missing, the missing fields are filled with null values.

[0052] The correction record time and corresponding cargo status information of each transit node are encapsulated to generate segmented data packets for each transit node. Data encapsulation uses the Protocol Buffers serialization protocol, defining a SegmentPacket message structure. The SegmentPacket structure contains three fields: node_id (a string) storing the node identifier; adjusted_timestamp (an int64) storing the Unix timestamp value of the correction record time; and state_payload (bytes) storing the serialized binary data of the cargo status information. For each transit node, a SegmentPacket instance is created, assigning the node identifier to the node_id field, the correction record time to the adjusted_timestamp field, and the cargo status information, serialized according to the agreed message structure, to the state_payload field, thus completing the generation of the segmented data packet.

[0053] All segmented data packets are sorted according to the order in which they passed through the nodes, resulting in a node-sorted sequence of segmented data packets. The sorting is based on the value of the `adjusted_timestamp` field in the segmented data packets, arranged in ascending order of the `adjusted_timestamp` field value. If multiple segmented data packets have the same `adjusted_timestamp` field value, the original order in the node sequence is used as a secondary sorting criterion. The sorted sequence of segmented data packets is then written to a distributed file system, persistently stored using the waybill identifier as the directory name and the sequence number of the segmented data packets in the sequence as the filename.

[0054] In some embodiments, the sequence of transit nodes can also be obtained by extracting it from the segmented reporting records of waybills directly uploaded by edge computing nodes in the logistics transportation network. Each edge computing node reports one record when goods arrive and depart, and the central end concatenates these records into a sequence of transit nodes according to the chronological order of waybill identifier and reporting time. During the offset correction process, if the node identifier of a transit node does not have a corresponding initial time base offset in the node offset mapping table, the initial time base offset of the transit node is considered to be zero, and the node identifier of the transit node and its zero offset are added to the node offset mapping table to ensure that subsequent nodes of the same type can use it directly.

[0055] See Figure 4 In the figure, the horizontal axis represents the sequence number of the transit nodes, which is sorted according to the correction record time of the transit nodes in the waybill described in this embodiment, with a value range of 1 to 100. The vertical axis represents the correction record time of the corresponding transit node, in hours. The legend identifies five curves representing different cargo identifiers (G001 to G005), each curve is distinguished by different colors and markings, reflecting the cumulative change trend of the correction record time of each cargo when passing through the transit nodes.

[0056] Observing the curve trend, the correction record time of each cargo identifier shows an approximately linear increasing relationship, indicating that the time record of the cargo at the nodes it passes through in the logistics transportation network, after offset correction, conforms to the characteristic of increasing time sequence. This reflects the effect of the unified time axis correction of the actual record time based on the initial time base offset of the node in this embodiment. Specifically, as the horizontal axis increases from 1 to 100, the vertical axis corresponding to the correction record time gradually increases from 0 hours to approximately 130 to 145 hours, indicating that when the cargo passes through as many as 100 sorting nodes, its cumulative correction time span is approximately more than 5 days.

[0057] Of the five curves, the correction recording time for cargo identifier G005 is generally higher than that of other cargoes, indicating a larger time span and suggesting a longer actual transportation or recording time for this cargo. The curve for cargo identifier G004 is further back, with a generally lower correction recording time, indicating a relatively shorter transportation or recording time. The curves for the remaining cargo identifiers G001, G002, and G003 are relatively similar, evenly distributed in the middle region, reflecting a general trend of stable consistency despite some differences in the time characteristics of different cargoes passing through nodes within the same logistics network.

[0058] In practice, the correction record time in each segmented data packet is converted into a time string in a unified format, and a hash operation is performed on the time string to obtain the hash timestamp of each segmented data packet. The SHA-256 hash algorithm is used when performing the hash operation on the time string, and the unique node identifier of the node is mixed into the time string as a hash salt value. The correction record time is obtained by reading the Unix timestamp value from the adjusted_timestamp field of the segmented data packet, formatting the Unix timestamp value into a Coordinated Universal Time (UTC) time string according to the ISO8601 standard, with the formatted time string accurate to the second, in the form of a 24-character fixed-length string like "YYYY-MM-DDThh:mm:ssZ". The unique node identifier of the node is taken from the node_id field of the segmented data packet. The node identifier is a unique code assigned to each node during the construction phase of the logistics transportation network. The encoding rule is the administrative division code of the node plus a two-digit serial number, with a total length of 8 characters.

[0059] The hash salt is mixed in as follows: the node's unique identifier is used as a prefix string, and the formatted timestamp string is used as a suffix string. The prefix and suffix strings are concatenated directly into a mixed string. This mixed string is converted to a UTF-8 encoded byte sequence, which is then used as input to the SHA-256 hash algorithm. The SHA-256 hash algorithm calculates a 256-bit hash value from the input byte sequence. This 256-bit hash value is converted to a 64-character hexadecimal string, which is then used as the hash timestamp for the segmented data packet.

[0060] Optionally, the hash salt can also be mixed in by using the node's unique node identifier as a suffix string, using the formatted time string as a prefix string, and concatenating the prefix string and the suffix string into a mixed-in string.

[0061] In practice, the hash timestamp of the preceding segment data packet is read, and a bitwise XOR operation is performed between the hash timestamp of the preceding segment data packet and the hash timestamp of the current segment data packet to obtain the difference in hash timestamps between adjacent segment data packets. The preceding segment data packet refers to the segment data packet immediately preceding the current segment data packet in the node-sorted sequence of segment data packets. The reading method is as follows: the hash timestamp of the preceding segment data packet is obtained from the distributed file system by indexing the segment data packet's sequence number.

[0062] The bitwise XOR operation is performed as follows: The hash timestamps of the previous and current data segments are converted into 256-bit binary sequences. An XOR operation is then performed on each corresponding bit in both sequences. The rule for XOR is 0 if the corresponding bits are the same, and 1 if they are different. The resulting 256-bit binary sequence is then converted into a 64-character hexadecimal string. This 64-character hexadecimal string is used as the difference in hash timestamps between adjacent data segments. Let the hash timestamp of the previous data segment be denoted as... The hash timestamp of the current segmented data packet is The hash timestamp difference between adjacent data packets is 1. The bitwise XOR operation is then represented as:

[0063]

[0064] in, The hash timestamp of the previous segment data packet is a 64-character hexadecimal string, which is calculated by mixing the correction record time of the previous segment data packet with the node's unique identifier and then using the SHA-256 hash algorithm. The hash timestamp representing the current segment data packet is a 64-character hexadecimal string, calculated by mixing the correction record time of the current segment data packet with the node's unique identifier and then using the SHA-256 hash algorithm. This represents the bitwise XOR operator, which performs the operation by... and Each bit is converted into a 256-bit binary sequence and then XORed with each bit. The hash timestamp difference value representing the adjacent segment data packets is a 64-character hexadecimal string, which is converted from the result of a 256-bit binary XOR operation.

[0065] The node identifier, hash timestamp, and hash timestamp difference value of the current segment data packet are stored as an index record in the chained verification index table. The chained verification index table is a structured data table in the distributed database, containing four columns: record number, node identifier, hash timestamp, and difference value. The record number is an auto-incrementing integer used to identify the insertion order of the index record in the chained verification index table. The node identifier column stores the node identifier corresponding to the current segment data packet. The hash timestamp column stores the hash timestamp of the current segment data packet. The difference value column stores the hash timestamp difference between the current segment data packet and the previous segment data packet. When inserting an index record into the chained verification index table, a new record number is generated, the node identifier of the current segment data packet is written to the node identifier column, the hash timestamp of the current segment data packet is written to the hash timestamp column, the hash timestamp difference value is written to the difference value column, and the database insertion operation is performed to complete the storage.

[0066] Repeat the reading and processing steps until all segmented data packets have been processed, resulting in a complete chained verification index table. Traverse the segmented data packet sequence sorted by node. Since the first segmented data packet in the sequence does not have a preceding segmented data packet, its hash timestamp difference value column is set to a 64-character hexadecimal string of all zeros (i.e., the hexadecimal representation of all 256 binary bits being zero). Starting from the second segmented data packet, sequentially read the hash timestamps of the current segmented data packet and the previous segmented data packet, perform a bitwise XOR operation, and write the result, along with the node identifier and hash timestamp of the current segmented data packet, into the chained verification index table until the last segmented data packet in the sequence is processed.

[0067] In some embodiments, the chained verification index table also includes a waybill identifier column, which is associated with each index record for storage, so that the corresponding index record can be quickly filtered by waybill identifier when a cargo traceability query request is received. If the segmented data packet sequence contains only one segmented data packet, the chained verification index table contains only one index record, and the difference value column of the index record is all zeros.

[0068] See Figure 5 In the graph, the horizontal axis represents the sequence number of the record in the chained verification index table, ranging from 0 to 100, corresponding to the order of adjacent segment data packet pairs. The vertical axis represents the hash timestamp difference value, expressed in decimal, ranging from 0 to 1.0 × 10^10. The legend distinguishes the distribution of hash timestamp differences corresponding to five different waybill identifiers (WA, WB, WC, WD, WE), represented by different colors and marker shapes.

[0069] As can be seen from the figure, the hash timestamp differences corresponding to each waybill identifier are evenly distributed across the entire record sequence number range, without any obvious concentrated or regular fluctuation trend. The difference points are scattered and cover a wide range of values, indicating that the hash timestamp differences between adjacent data segments change relatively randomly, without any abnormal concentrated mutations.

[0070] In practice, the cargo identifier and query time range are parsed from the cargo traceability query request. The cargo traceability query request is submitted by the user through the client interface, sent to the traceability query service interface via HTTP POST. The request body is in JSON format and includes the `query_goods_id` and `query_time_range` fields. The value of the `query_goods_id` field is the cargo identifier, a globally unique string uniformly assigned by the logistics and transportation network, with a fixed length of 32 characters. The value of the `query_time_range` field is an object containing two subfields: `start_time` and `end_time`. Both `start_time` and `end_time` are Coordinated Universal Time (UTC) strings in ISO 8601 format, used to specify the time range boundaries for the traceability query. The traceability query service interface parses the request body, extracts the cargo identifier and query time range, stores the cargo identifier in a query context object, and converts the query time range to a Unix timestamp range.

[0071] Based on the cargo identifier to be queried, the target segmented data packet sequence matching the cargo identifier is filtered from the segmented data packets. The segmented data packets are stored in a distributed file system, with the cargo waybill identifier as the first-level directory name and the segmented data packet sequence number as the filename. The filtering process is as follows: The mapping relationship between cargo identifiers and cargo waybill identifiers is obtained. This mapping relationship is stored in a cargo waybill mapping table in a relational database. The cargo waybill mapping table contains cargo identifier and cargo waybill identifier columns. The cargo waybill mapping table is queried using the cargo identifier to be queried to obtain the corresponding cargo waybill identifier. The corresponding directory in the distributed file system is located based on the cargo waybill identifier, and all segmented data packet files in that directory, arranged by sequence number, are read to form the target segmented data packet sequence. If the query time range is not empty, a second filtering is performed on the target segmented data packet sequence, retaining only segmented data packets whose correction record time falls within the Unix timestamp range corresponding to the query time range.

[0072] Extract the node identifier and hash timestamp corresponding to each target segment data packet from the target segment data packet sequence. For each target segment data packet in the target segment data packet sequence, deserialize the SegmentPacket message structure, read the node identifier from the node_id field (an 8-bit fixed-length string), and read the adjusted record time from the adjusted record time field. Based on the adjusted record time and node identifier, recalculate the hash timestamp. The recalculation process involves converting the adjusted record time into a time string in the format "YYYY-MM-DDThh:mm:ssZ", concatenating the node identifier as a prefix with the time string, and performing a SHA-256 hash operation on the concatenated string to obtain a 64-character hexadecimal hash timestamp. Store the extracted node identifier and the recalculated hash timestamp in an ordered list according to the order of the target segment data packets in the sequence.

[0073] Following the sequential order of nodes in the target segmented data packet sequence, perform a bitwise XOR operation between the hash timestamp of the current node and the hash timestamp of the previous node to obtain the verification difference value. Let the nth node in the target segmented data packet sequence be... The current node is a node whose hash timestamp is [value]. The previous node of the current node is the first node. There are nodes, and the hash timestamp of the previous node is . The difference value is verified. The bitwise XOR operation is then represented as:

[0074]

[0075] in, Indicates the first segment of the target data packet sequence. The hash timestamp of the nth node is a 64-character hexadecimal string, generated by the nth node. The correction record time of each node is mixed with the node's unique identifier and then calculated using the SHA-256 hash algorithm. Indicates the first segment of the target data packet sequence. The hash timestamp of the nth node is a 64-character hexadecimal string, generated by the nth node. The correction record time of each node is mixed with the node's unique identifier and then calculated using the SHA-256 hash algorithm. This represents the bitwise XOR operator, which performs the operation by... and Each bit is converted into a 256-bit binary sequence and then XORed with each bit. This represents the check difference value, a 64-character hexadecimal string, obtained by converting the result of a 256-bit binary XOR operation; It is a positive integer, ranging from 2 to the length of the target segmented data packet sequence. When the value is 1, there is no previous node, and the check difference value is not calculated.

[0076] The verification difference value is compared with the cargo flow delay interval between the current node and the previous node to determine whether the verification difference value falls within the cargo flow delay interval. The cargo flow delay interval is obtained by querying the corresponding upper and lower limits of the cargo flow delay interval from the cargo flow delay interval data storage structure based on the node identifiers of the current node and the previous node. The cargo flow delay interval data storage structure is a key-value storage structure indexed by node pairs. The verification difference value is then compared with the cargo flow delay interval between the current node and the previous node. Convert to decimal value, and compare the decimal value with the upper limit and lower limit of the flow delay interval.

[0077] When comparing the verification difference value with the cargo flow delay interval between the current node and the previous node, if the verification difference value falls within the range after extending the upper and lower limits of the cargo flow delay interval outwards by a preset tolerance threshold, then the verification difference value is determined to be within the cargo flow delay interval. The preset tolerance threshold is obtained as follows: the preset tolerance threshold is set to a constant value of 300 seconds, based on the statistical upper limit of the maximum calibration residual of the system clock between adjacent nodes in the logistics transportation network. This statistical upper limit is determined by the distribution of the absolute values ​​of the residuals after all historical nodes have calibrated the initial time base offset, taking the 99th quantile of the absolute value distribution and rounding it up to 300 seconds. The lower limit of the cargo flow delay interval between the current node and the previous node is denoted as... The upper limit is The preset tolerance threshold is , The value is 300, and the difference will be checked. The first 8 characters of the hexadecimal string are converted to a decimal integer, resulting in a checksum value with the same dimensions as the time difference. (Unit: seconds), then With the expanded interval If a comparison is made, and If the value is within the time limit for goods circulation, it is determined that the difference is within the time limit for goods circulation; otherwise, it is determined that the difference is not within the time limit for goods circulation.

[0078] If all discrepancies fall within the cargo flow delay interval, the result of this determination is used as the link integrity identifier, which is written into the header field of the traceability result data packet. The traceability result data packet uses JSON format, with the header field named integrity_flag. The integrity_flag field is set to true when the link integrity identifier is valid. The segmented data packets corresponding to each node on the query path are read from the chain verification index table. Each index record in the chain verification index table contains a storage_path field, which stores the complete path of the segmented data packet in the distributed file system. The segmented data packet file is located and read based on this complete path. The segmented data packets are then sorted in ascending order according to the correction record time of each node, with the correction record time of each node read from the adjusted_timestamp field of the segmented data packet. The cargo status information is extracted sequentially from the state_pa of the segmented data packet. The yload field is deserialized, and the status information of each item is concatenated in the order of arrangement to form a status evolution sequence. The status evolution sequence is a JSON array, and each element in the array is an object containing the node identifier, correction record time, and the status information field obtained from the deserialization of state_payload. The status evolution sequence and the header fields of the traceability result data packet are combined to form complete traceability link data. The complete traceability link data is a JSON object containing the integrity_flag field and the state_sequence field. This JSON object is returned to the terminal that issued the item traceability query request via an HTTP response.

[0079] If a difference exists that is not within the cargo flow delay interval, iterate through the hash timestamp differences of all adjacent nodes on the query path. Nodes whose hash timestamp differences do not fall within the corresponding cargo flow delay interval are recorded as abnormal nodes. The iteration operation is as follows: for each node in the target segmented data packet sequence from the second node to the last node, calculate the verification difference value and compare it with the expanded cargo flow delay interval. Nodes whose comparison result is not within the interval are added to the abnormal node list. Using the abnormal node as a dividing point, extract the node preceding the abnormal node from the query path as the preceding normal node, and the node following the abnormal node as the following normal node. In the target segmented data packet sequence, the position number of the abnormal node is... The preceding normal node is the position number. The corresponding node, and the subsequent normal node is the position number. For the corresponding nodes, if the abnormal node is the first node in the sequence, then there is no preceding normal node, and the preceding normal node is set to null. If the abnormal node is the last node in the sequence, then there is no subsequent normal node, and the subsequent normal node is set to null. The cargo status information in the segmented data packets corresponding to the preceding normal node is extracted as the preceding status reference data; if the preceding normal node is null, the preceding status reference data is set to null. Similarly, the cargo status information in the segmented data packets corresponding to the subsequent normal node is extracted as the subsequent status reference data; if the subsequent normal node is null, the subsequent status reference data is set to null. The preceding state reference data, the following state reference data, and the node identifier of the abnormal node are associated and stored in the abnormal record table. The abnormal record table is a table in a relational database. The table structure includes an abnormal record identifier column, a waybill identifier column, an abnormal node identifier column, a preceding state reference data column, a following state reference data column, and a record time column. When an abnormal record is inserted, the database automatically generates an abnormal record identifier, writes the current waybill identifier to the waybill identifier column, writes the node identifier of the abnormal node to the abnormal node identifier column, serializes the preceding state reference data into a JSON string and writes it to the preceding state reference data column, serializes the following state reference data into a JSON string and writes it to the following state reference data column, and writes the current system time to the record time column, thus completing the persistent storage of abnormal records.

[0080] In some embodiments, the header field of the link integrity identifier also includes a verification timestamp field to record the baseline time of the verification operation completion. For handling abnormal nodes, while storing the node identifier of the abnormal node in the abnormal record table, the record identifier of the abnormal record table is also pushed to the logistics monitoring system via a message queue as part of an alarm notification. The notification content includes the waybill identifier, the abnormal node identifier, and the node identifiers of the preceding and following normal nodes, so that the logistics monitoring system can trigger a manual verification process.

[0081] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes 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.

Claims

1. A logistics transportation traceability management method based on big data analysis, characterized in that, include: Obtain node distribution data and historical cargo throughput time series data of each node in the logistics and transportation network; Based on the historical cargo throughput time series data of each node, the cargo flow delay interval between adjacent nodes is calculated, and the initial time base of each node is calibrated using the cargo flow delay interval to obtain the initial time base offset of each node. Based on the initial time base offset of each node, the real-time cargo waybill data of the logistics transportation network is split into segmented data packets sorted by node. Assign a hash timestamp to each segmented data packet and construct a chained verification index table for the logistics and transportation network based on the hash timestamp differences between adjacent segmented data packets. When a cargo traceability query request is received, the difference between the hash timestamp of the segmented data packet of each node on the query path and the hash timestamp of the segmented data packet of the preceding node is verified according to the chain verification index table to see if it is within the cargo flow delay interval. If all discrepancies are within the cargo flow delay range, the segmented data packets of each node on the query path will be concatenated into complete traceability link data in chronological order and output.

2. The logistics transportation traceability management method based on big data analysis according to claim 1, characterized in that, Based on the historical cargo throughput time series data of each node, the cargo flow delay interval between adjacent nodes is calculated, specifically including: Extract the arrival and departure timestamps of the same cargo identifier from the historical cargo throughput time series data of each node; The difference between the departure and arrival timestamps of the same goods identified at two adjacent nodes is used as a sample of single-transfer delay. Summarize all single-transfer delay samples of all goods identifiers between two adjacent nodes to form a transfer delay sample set; After removing the maximum and minimum values ​​from the set of flow delay samples, the minimum value of the remaining flow delay samples is taken as the lower limit of the flow delay interval, and the maximum value of the remaining flow delay samples is taken as the upper limit of the flow delay interval.

3. The logistics transportation traceability management method based on big data analysis according to claim 1, characterized in that, The initial time base of each node is calibrated using the cargo flow delay interval, resulting in the initial time base offset of each node, specifically including: Select any node in the logistics transportation network as the reference node, and set the initial time base offset of the reference node to zero. Starting from the base node, traverse each unmarked node sequentially along the path of the logistics transportation network; The difference between the local clock reading of the currently traversed uncalibrated node and the local clock reading of the previous calibrated node is subtracted from the median value of the cargo flow delay interval between the previous calibrated node and the currently traversed uncalibrated node to obtain the initial time base offset of the currently traversed uncalibrated node. The calculated initial time base offset is assigned to the currently traversed uncalibrated node, and the process continues to traverse the next uncalibrated node until all nodes have been assigned the initial time base offset.

4. The logistics transportation traceability management method based on big data analysis according to claim 1, characterized in that, Based on the initial time base offset of each node, the real-time freight waybill data of the logistics transportation network is split into segmented data packets ordered by node, specifically including: Obtain the sequence of transit nodes and the actual recording time of each transit node recorded in the real-time cargo waybill data; Based on the initial time base offset of each passing node, the actual recorded time of the corresponding passing node is offset and corrected to obtain the corrected recorded time of each passing node. According to the order of the transit nodes, extract the cargo status information corresponding to each transit node from the real-time cargo waybill data; The correction record time of each transit node and the cargo status information corresponding to that node are encapsulated to generate segmented data packets corresponding to each transit node; All segmented data packets are sorted according to the order in which they pass through the nodes, resulting in a segmented data packet sequence sorted by node.

5. The logistics transportation traceability management method based on big data analysis according to claim 1, characterized in that, Each segmented data packet is assigned a hash timestamp of its corresponding node, and a chained verification index table for the logistics transportation network is constructed based on the difference in hash timestamps between adjacent segmented data packets. Specifically, this includes: The correction record time in each segmented data packet is converted into a time string in a uniform format, and a hash operation is performed on the time string to obtain the hash timestamp of each segmented data packet; Read the hash timestamp of the previous segment data packet of the current segment data packet, and perform a bitwise XOR operation between the hash timestamp of the previous segment data packet and the hash timestamp of the current segment data packet to obtain the hash timestamp difference value between adjacent segment data packets. Store the node identifier, hash timestamp, and hash timestamp difference value of the current segmented data packet as an index record in the chained verification index table; Repeat the reading and processing steps until all segmented data packets have been processed, resulting in a complete chained verification index table.

6. The logistics transportation traceability management method based on big data analysis according to claim 1, characterized in that, When a cargo traceability query request is received, the chained verification index table is used to sequentially verify whether the difference between the hash timestamp of each segment data packet on the query path and the hash timestamp of the segment data packet of the preceding node is within the cargo flow delay interval. Specifically, this includes: Parse the cargo identifier and query time range from the cargo traceability query request; Based on the cargo identifier to be queried, filter out the target segment data packet sequence that matches the cargo identifier to be queried from the segment data packets; Extract the node identifier and hash timestamp corresponding to each target segment data packet from the target segment data packet sequence; According to the order of nodes in the target segmented data packet sequence, the hash timestamp of the current node is XORed with the hash timestamp of the previous node one by one to obtain the verification difference value. The verification difference value is compared with the cargo flow delay interval between the current node and the previous node to determine whether the verification difference value falls within the cargo flow delay interval.

7. The logistics transportation traceability management method based on big data analysis according to claim 1, characterized in that, If all discrepancies fall within the cargo flow delay range, the segmented data packets from each node along the query path will be concatenated in chronological order to form complete traceability chain data and output, specifically including: The determination result that all differences are within the cargo flow delay range is used as the link integrity identifier, and the link integrity identifier is written into the header field of the traceability result data packet; Read the segmented data packets corresponding to each node on the query path from the chained verification index table, and sort the segmented data packets in ascending order according to the order of the correction record time of each node. The cargo status information in the segmented data packets arranged in ascending order is extracted sequentially and then concatenated into a cargo status evolution sequence according to the arrangement order. The header fields of the cargo status evolution sequence and traceability result data packet are combined into complete traceability link data, and the complete traceability link data is output to the terminal that issued the cargo traceability query request.

8. The logistics transportation traceability management method based on big data analysis according to claim 1, characterized in that, If a discrepancy exists that is not within the cargo flow delay interval, the node whose discrepancy is not within the cargo flow delay interval is marked as an abnormal node, and the preceding and following normal nodes of the abnormal node are obtained, specifically including: Iterate through the hash timestamp differences of all adjacent nodes on the query path, and record nodes whose hash timestamp differences do not fall within the corresponding cargo flow delay interval as abnormal nodes. Using the abnormal node as the dividing point, extract the node before the abnormal node from the query path as the preceding normal node, and extract the node after the abnormal node as the following normal node. Extract the cargo status information from the segmented data packets corresponding to the preceding normal nodes as the preceding status reference data; Extract the cargo status information from the segmented data packets corresponding to subsequent normal nodes as subsequent status reference data; The preceding state reference data, the following state reference data, and the node identifier of the abnormal node are associated and stored in the abnormal record table.

9. The logistics transportation traceability management method based on big data analysis according to claim 5, characterized in that, When performing a hash operation on a time string, the SHA-256 hash algorithm is used, and the unique node identifier of the node is mixed into the time string as a hash salt value.

10. The logistics transportation traceability management method based on big data analysis according to claim 6, characterized in that, When comparing the verification difference value with the cargo flow delay interval between the current node and the previous node, if the verification difference value is within the range after the upper and lower limits of the cargo flow delay interval are each extended outward by a preset tolerance threshold, then the verification difference value is determined to be within the cargo flow delay interval.