A multi-modal transport document digitization circulation processing system

Abstract

This invention discloses a digital document processing system for multimodal transport, relating to the field of logistics information technology. The system utilizes a shadow copy management module and an offline operation module in the edge agent client to automatically create a shadow copy of the document carrying a baseline version vector during network interruptions. It provides an independent offline operating environment based on a local lightweight module, solving the problem of document processing being impossible during network interruptions. The offline operation module records local operations item by item to the shadow operation chain, while simultaneously updating the local version vector, which only increments in the dimension of the edge node itself. This completely preserves the offline operation trajectory and accurately marks the local status of the document, preventing offline operation data loss. After network recovery, no manual input of operation information is required; edge nodes can initiate synchronization autonomously. Document processing operations in port and yard network instability scenarios will not be interrupted due to network fluctuations, ensuring the continuity of multimodal transport operations throughout the entire process.

Description

Technical Field

[0001] This invention relates to the field of logistics information technology, specifically to a multimodal transport document digital circulation and processing system. Background Technology

[0002] With the development of the logistics supply chain, multimodal transport has become the mainstream transportation mode due to its efficiency and flexibility. Its core lies in the smooth flow of documents among various modes of transport such as sea, rail, and road. Digitizing paper documents and enabling online processing and status synchronization is a key foundation for improving efficiency, reducing errors, and achieving a "single document" system. Currently, related systems mainly rely on a cloud-based centralized architecture, requiring all operations to be completed online in real time.

[0003] However, existing centralized systems face fundamental challenges in the complex physical environment of multimodal transport. Key nodes such as terminals, ports, and cross-border border crossings often experience network instability or even outages. During these situations, operators cannot access the cloud system, forcing the interruption of document processing and causing stagnation in loading, unloading, and container handling. More seriously, after the network is restored, locally recorded operational data from the offline period may conflict with other operational data that the cloud may receive simultaneously. Existing solutions rely entirely on manual comparison and merging, lacking consideration for complex business logic, which easily leads to data inconsistencies, unclear responsibilities, and even business logic errors, severely damaging the reliability, timeliness, and legal validity of digital documents.

[0004] In summary, existing technologies cannot effectively solve the problems of business continuity and data consistency in unreliable network environments, which has become a major bottleneck restricting the comprehensive digitization and real-time processing of multimodal transport documents. Therefore, there is an urgent need for a new solution that can ensure uninterrupted document flow and eventual data consistency in a hybrid offline and online environment. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a multimodal transport document digital circulation processing system. This system can automatically create document shadow copies carrying baseline version vectors during network interruptions through the shadow copy management module and offline operation module of the edge agent client. It relies on a local lightweight module to provide an independent offline operating environment, solving the problem of document processing being impossible during network interruptions. The offline operation module records local operations one by one to the shadow operation chain, while simultaneously updating the local version vector, which only increments in the dimension of the edge node itself. This completely preserves the offline operation trajectory and accurately marks the local status of the documents, preventing offline operation data loss. After network recovery, there is no need for manual re-entry of operation information; edge nodes can initiate synchronization autonomously. Document processing operations in port and yard network instability scenarios will not be interrupted due to network fluctuations, ensuring the continuity of multimodal transport operations throughout the entire process.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: a multimodal transport document digital circulation and processing system, which includes a cloud service center and multiple edge agent clients; The cloud service center includes: The master document database is used to store authoritative data on multimodal transport documents, where each document data record is associated with a version vector; The main blockchain ledger is used to record all verified operation log entries that change the status of a document in sequence. Each operation log entry is associated with a new version vector of the corresponding document after the operation is executed. The synchronization coordination module is used to receive synchronization requests and execute the difference merging algorithm; The edge proxy client is deployed on a job node with an unstable network, including: A local lightweight module used to provide an independent runtime environment in offline settings; The shadow copy management module is used to create a shadow copy of the target document in a local lightweight module when a network interruption is detected. The shadow copy includes the document status and baseline version vector obtained from the master document database. The baseline version vector is a version vector copy of the snapshot of the master document database when the shadow copy is created at the edge. The offline operation module is used to perform local operations on the shadow copy during network interruption, record each local operation to the shadow operation chain, and update the local state of the shadow copy and the local version vector generated based on the baseline version vector. The synchronization agent module is used to package the baseline version vector, shadow operation chain, and the current state of the shadow replica into a synchronization data packet and send it to the synchronization coordination module when the network recovers.

[0007] Furthermore, the shadow operation chain is a time-linked data structure stored in a local lightweight module, used to record all operations performed on the shadow copy in an offline environment; Each entry in the shadow operation chain includes an operation type, operation content, operator digital signature, local timestamp, and a local version vector of the shadow copy after the operation is executed.

[0008] Furthermore, the version vector, baseline version vector, and local version vector all adopt a unified multi-dimensional version vector format to uniquely identify a document's specific state version in the global operation history. Each version vector is represented as follows: ,in The total number of nodes involved in the modification in the system, the th Each component Indicates from the The cumulative number of operations on each node, when the edge proxy client is offline, the local version vector updated by the operation on the shadow copy, only increments on the dimension component representing the edge proxy client itself.

[0009] Furthermore, the difference merging algorithm is used to logically merge and resolve conflicts between the shadow operation chain and the operation log entries recorded after the baseline version vector in the main blockchain ledger, thereby achieving data synchronization. The steps of the synchronization coordination module executing the difference merging algorithm include: Receive the synchronization data packet from the edge agent client and parse out the target document identifier, baseline version vector and shadow operation chain from it; Based on the target document identifier, a version determination is performed, and all cloud operation log entries with version vectors greater than the baseline version vector are retrieved from the main blockchain ledger and used as a concurrent cloud operation set. The shadow operation chain and the concurrent cloud operation set are logically merged and conflict resolution is performed.

[0010] Furthermore, the determination logic for the version is as follows: For the baseline version vector: The version vector associated with each entry in the cloud operation log of the main blockchain ledger is: , If and only if for all All have It is established, and at least one exists. Make If it is established, then it is determined that... Greater than , recorded as At this point, cloud operation log entries are included in concurrent cloud operations.

[0011] Furthermore, the difference merging algorithm performs the logical merge and conflict resolution steps as follows: Based on the baseline version vector contained in the synchronization data packet The latest version vector associated with the target document in the master document database is... ; All data fields modified by shadow operations are parsed from the shadow operation chain to form an offline modified field set. ; All data fields modified by cloud operations are parsed from the concurrent cloud operation set to form a set of cloud modified fields. ; The synchronization coordination module resolves conflicts: when If so, it is determined that there were no other concurrent modifications in the cloud during the offline period and no version conflict. when Then calculate the set of offline modified fields. With the cloud-modified field set The intersection; when If so, it is determined that there is no field conflict; when If a field conflict is found, a conflict resolution process is triggered for the fields within the intersection.

[0012] Furthermore, the conflict resolution process is executed by the synchronization coordination module, including: For each field determined to have a conflict, a decision is made according to a predefined set of conflict resolution rules, which includes: Priority rules: Predefined priorities are set for different types of data sources, including: the result of the last device scanning operation, the operation performed by a node with higher privileges, or the operation with a later timestamp, and the merging result is determined according to the predefined priorities; Manual intervention rule: When conflicting modifications have the same priority, or when a conflicting field is marked as a critical business field, the synchronization coordination module terminates automatic merging, generates an early warning report containing conflict details, and sends it to the administrator terminal, awaiting manual arbitration instructions; After the conflict resolution is completed, the synchronization coordination module generates a merge decision record, which includes the conflict field, the operation values ​​of both parties, the resolution result, the rule identifier applied, and the timestamp, and writes the merge decision record as an operation log entry into the main blockchain ledger.

[0013] Furthermore, after the synchronization and coordination module completes the logical merging and conflict resolution, it writes all adopted operations, including merged shadow operations, cloud operations that were not resolved, and conflict resolution logs, into the main blockchain ledger in global chronological order. Based on the latest operation history after writing, calculate and generate a new final version vector for the target document; Update the master document database using the final version vector and the synchronized document status; The synchronization results, including the final version vector and the updated document status, will be sent to the edge agent client that initiated the synchronization and other relevant online clients. After receiving the synchronization result from the cloud service center, the synchronization proxy module of the edge proxy client updates the local cache with the synchronization result and clears the synchronized shadow copy and the corresponding shadow operation chain, thus completing the consistency between the local state and the cloud state.

[0014] Furthermore, the system works as follows: When the edge agent client detects a network outage, it creates a shadow copy with a baseline version vector for the document to be processed. In offline mode, perform operations on the shadow copy and record them to the shadow operation chain; After the network is restored, the baseline version vector and shadow operation chain will be sent to the cloud service center; The cloud service center uses a difference merging algorithm to logically merge and resolve conflicts between the shadow operation chain and the main blockchain ledger operations that occur after the baseline version vector. Write the logical merge and conflict resolution sequence of operations into the main blockchain ledger, update the main document database, and broadcast the synchronization results. The edge proxy client updates its local state and cleans up shadow copies based on the synchronization results.

[0015] Compared with existing technologies, this multimodal transport document digital circulation and processing system has the following advantages: I. This invention utilizes the shadow copy management module and offline operation module of the edge proxy client to automatically create a document shadow copy carrying a baseline version vector when the network is interrupted. Relying on a local lightweight module to provide an independent offline operating environment, it solves the problem of being unable to carry out document operations during network interruptions. The offline operation module records local operations one by one to the shadow operation chain, and updates the local version vector that only increases in the dimension of the edge node itself. It completely preserves the offline operation trajectory and accurately marks the local status of the document, preventing the loss of offline operation data. After the network is restored, there is no need to manually re-enter operation information. The edge node can initiate synchronization autonomously. Document processing operations in port and yard network unstable scenarios will not be interrupted due to network fluctuations, ensuring the continuity of multimodal transport operations throughout the entire process.

[0016] Second, this invention adopts a two-layer conflict detection mechanism of version vector comparison and data field set intersection judgment. First, the version difference is determined by comparing the baseline version vector with the latest version vector in the cloud. Then, the intersection of the offline and cloud operation field sets is used to accurately locate field conflicts, solving the problems of coarse conflict detection, false judgment and missed judgment. The difference merging algorithm automatically adjudicates compliant conflicts according to preset rules. The generated merging decision record is written into the main blockchain ledger for evidence storage, realizing intelligent merging of cloud and offline operations. It can ensure the consistency of global data of documents without a lot of manual intervention. The main blockchain ledger retains operation logs and conflict resolution records immutably, realizing full traceability of document operations and replacing manual sorting through intelligent merging, which greatly improves the credibility and processing efficiency of multimodal transport document circulation.

[0017] Other advantages, objectives and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination or study, or may be learned from the practice of the invention. Attached Figure Description

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

[0019] Figure 1 A flowchart illustrating the working principle of a digital circulation and processing system for multimodal transport documents; Figure 2 This is a block diagram of a multimodal transport document digital circulation and processing system according to an embodiment of the present invention; Figure 3 This is a flowchart of the difference merging algorithm executed by the synchronization coordination module in an embodiment of the present invention; Figure 4 This is a flowchart illustrating the steps involved in performing the final synchronous write and state update in an embodiment of the present invention. Detailed Implementation

[0020] To better understand the above technical solutions, a detailed description of the solutions will be provided below in conjunction with the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0021] To address the shortcomings of existing centralized multimodal transport documentation systems, such as poor business continuity, difficulties in data synchronization, and inefficient manual conflict resolution under unstable network conditions, this invention provides a digital multimodal transport documentation processing system. This system addresses the technical bottlenecks of document flow stagnation due to network interruptions, data loss during offline operations, and the difficulty in automatically merging version conflicts between cloud and local data after network recovery. The invention aims to create shadow copies carrying version vectors in offline environments through edge proxy clients. After network recovery, it utilizes version vector comparison and field-level conflict detection mechanisms, combined with the immutable notarization of the main blockchain ledger, to achieve intelligent merging of offline and cloud operations, thereby ensuring the continuity of multimodal transport operations and the ultimate consistency of data status throughout the entire process.

[0022] The present invention will now be described in further detail with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0023] like Figure 2As shown, the multimodal transport document digital circulation processing system provided by this invention has a core architecture including a cloud service center deployed in the central cloud and multiple edge agent clients deployed at each operation node. The cloud service center, as the system's central hub, is responsible for the management and synchronization of global data, specifically including: The master document database stores authoritative data for all multimodal transport documents. Each document record in this database is associated with a globally unique version vector, which precisely identifies the global status of that document at a given moment.

[0024] The main blockchain ledger is used to record all verified operation log entries that change the status of documents in chronological order and immutably. When each operation log entry is written, it not only records the operation content, operator, and timestamp, but also associates it with the new version vector generated by the corresponding document after the operation is executed, thus forming a complete operation traceability chain.

[0025] The synchronization coordination module, as the core of the interaction between the cloud and the edge, is used to receive synchronization requests from the edge agent client and execute the difference merging algorithm proposed in this invention to handle the merging and conflict resolution of offline operations and concurrent cloud operations.

[0026] The edge proxy client is deployed on a work node in an unstable network environment. As an extension of the cloud, it has independent local processing capabilities, specifically including: A local lightweight module is used to provide an independent operating environment in offline mode, ensuring that the core business logic of the node can still be executed normally when the network is interrupted.

[0027] The shadow copy management module is used to detect network connection status. When a network interruption is detected, a shadow copy is created in the local lightweight module for the target document to be operated on. The shadow copy contains the latest document status data synchronized from the master document database, as well as a baseline version vector. This baseline version vector is a copy of the version vector representing the global state of the document at this time, which is obtained from the snapshot of the master document database by the edge agent client at the time of shadow copy creation, marking the starting point of offline operation.

[0028] The offline operation module is used to allow operators to perform local operations on the shadow copy during network interruption. Each local operation is recorded in a local shadow operation chain, and the local state and local version vector of the shadow copy are updated synchronously. The local version vector is generated based on the baseline version vector, only incrementing on the dimension component representing the edge agent client itself, thereby accurately recording the operation sequence of the node during offline periods.

[0029] The synchronization agent module continuously monitors the network status. When the network connection is restored, it packages the baseline version vector, the complete shadow operation chain, and the final current state of the shadow replica into a synchronization data packet and sends it to the synchronization coordination module in the cloud service center to initiate a synchronization request.

[0030] In a preferred embodiment, to ensure the integrity and traceability of offline operations, the shadow operation chain is designed as a time-sequentially linked data structure stored in a local lightweight module. This data structure records not only the operation itself but also the context of the operation. Specifically, each entry in the shadow operation chain includes fields such as: operation type (modify, submit, confirm), operation content (modify recipient name), operator digital signature (for authentication), local timestamp (records the time the operation occurred), and the local version vector of the shadow copy after the operation is executed. In this way, the entire process of offline operations is completely and orderly preserved, providing a basis for subsequent synchronization and merging.

[0031] In a preferred embodiment, to achieve accurate global state positioning and version comparison, the version vector, baseline version vector, and local version vector in this invention all adopt a unified multi-dimensional version vector format. This format is used to uniquely identify a specific state version of a document in the global operation history. Each version vector is represented as: ,in This represents the total number of nodes in the system involved in modifying documents, including logical nodes in the cloud service center and client nodes of each edge agent. Each component Indicates from the The cumulative number of operations on each node. Specifically, when any of the aforementioned edge proxy clients is offline, the local version vector updated by its operation on the shadow copy only increments on the dimension component corresponding to that client itself, while other dimension components remain unchanged, providing a clear basis for judging concurrent modifications in subsequent conflict detection.

[0032] The difference merging algorithm described in this invention is crucial for ensuring eventual data consistency. This algorithm logically merges and resolves conflicts between the shadow operation chain uploaded by the edge agent client and the operation log entries recorded after the baseline version vector in the main blockchain ledger. Figure 3 As shown, the specific steps of the synchronization coordination module in executing the difference merging algorithm are as follows: Receiving and parsing synchronization data packets: The synchronization coordination module receives synchronization data packets from the edge agent client and parses out: target document identifier and baseline version vector. and shadow operation chain ; Version determination and concurrent operation set extraction: Based on the target document identifier, the synchronization coordination module initiates a query to the main blockchain ledger to retrieve all concurrent operation sets. Subsequent cloud operation log entries. The specific version determination logic is as follows: for the baseline version vector... The version vector associated with any cloud operation log entry in the main blockchain ledger is If and only if for all dimensions ( All have It is valid, and at least one dimension exists. Make If it is established, then it is determined Greater than , recorded as All cloud operation log entries that meet this condition are included in the concurrent cloud operation set. This decision logic ensures that only operations that have a potential concurrent relationship with the local baseline state and are generated by other nodes (including the cloud's own logic or other online edge terminals) during offline periods are extracted; Logical merging and conflict resolution synchronization coordination module will link shadow operation chains Concurrent cloud operation set Merge them.

[0033] To achieve accurate conflict detection, this invention employs a two-layer detection mechanism: First, all data fields modified by shadow operations are parsed from the shadow operation chain, forming an offline modified field set. The data fields modified by all cloud operations are parsed from the concurrent cloud operation set, forming a set of cloud modified fields. Subsequently, the system executes the conflict resolution logic: Version consistency check: If the baseline version vector Equals the latest version vector of the target document associated with the master document database. If no other concurrent modifications were made in the cloud during the offline period and there were no version conflicts, the operations in the shadow operation chain can be merged directly.

[0034] Field conflict detection: If Then calculate and The intersection, when If the operation is concurrent, it means that although there are concurrent operations, the fields modified by the operations do not overlap, so it is determined that there is no field conflict, and the two sets of operations can be safely merged.

[0035] Conflict Triggered: When If an offline operation and a concurrent cloud operation modify the same field, a field conflict is identified. In this case, the system will trigger a conflict resolution process for each conflicting field within the intersection. In a preferred embodiment, this conflict resolution process is automatically executed by the synchronization coordination module based on a predefined set of conflict resolution rules. This set of rules is pre-configured by the system administrator according to business characteristics, aiming to achieve automated adjudication and reduce manual intervention. The rule set includes: Priority rules: Predefine priorities for different types of data sources or operation methods. For example, if the priority is set to take the result of the last device scan operation as the priority > the result of the operation performed by the node with higher privileges as the priority > the operation with the later timestamp as the priority, the system will select the operation result with the highest priority as the final value after merging according to the preset priority order.

[0036] Manual intervention rule: When conflicting modifications have the same priority, or when a conflicting field is marked as a critical business field by the business system, in order to avoid business risks that may be caused by automatic adjudication, the synchronization coordination module will terminate the automatic merging process. The system will generate an early warning report containing conflict details and send it in real time to the preset administrator terminal or the mobile device of the designated arbitrator, waiting for manual arbitration instructions.

[0037] Upon receiving a clear arbitration instruction, the system then completes the ruling according to the instruction. After the conflict ruling is completed, whether it is an automatic rule-based ruling or a manual arbitration, the synchronization and coordination module will generate a structured merge decision record. This record contains detailed information such as the conflict fields, the operation values ​​of both parties, the ruling result, the rule identifier (or arbitrator information) applied, and a timestamp. This merge decision record is written into the main blockchain ledger as an operation log entry, enabling the entire conflict resolution process to be auditable and traceable.

[0038] In a preferred embodiment, after completing logical merging and conflict resolution, the synchronization coordination module will perform final synchronization write and state update, such as... Figure 4 As shown, the specific process is as follows: Write to the main blockchain ledger: Sort all adopted operations globally in chronological order, including: shadow operations that have been merged and confirmed to be conflict-free, cloud operations that have not been rejected by the conflict resolution, and newly generated conflict resolution logs. Write these operation entries to the main blockchain ledger in chronological order to form new, tamper-proof blocks. Update the master document database: Based on the latest operation history written to the main blockchain ledger, the system recalculates the final state of the target document according to the order of operation execution, and generates a new, globally unique version vector based on this state. ,use Based on the calculated final status of the document, update the authoritative data record of that document in the master document database; Synchronization Result Distribution: The synchronization coordination module will distribute the synchronization results, including the final version vector. The updated and complete document status is sent to the edge agent client that initiated the synchronization through a secure channel. At the same time, in order to maintain data consistency among other online clients in the system that hold copies of the old status, the synchronization result is also broadcast to all other relevant online clients. Client state synchronization and cleanup: After receiving the synchronization result from the cloud service center, the synchronization agent module of the edge agent client that initiated the synchronization updates the local cached data with the received final version vector and document status. After successful synchronization, the client automatically clears the local synchronized shadow copy and the corresponding shadow operation chain, releases local storage resources, and ends the offline-online synchronization cycle.

[0039] To more clearly illustrate the overall workflow of this invention, the following is a summary... Figure 1 The working principle and flow of a multimodal transport document digital circulation processing system of the present invention are explained below: When the edge agent client detects a network outage, it creates a shadow copy with a baseline version vector for the document to be processed. In offline mode, perform operations on the shadow copy and record them to the shadow operation chain; After the network is restored, the baseline version vector and shadow operation chain will be sent to the cloud service center; The cloud service center uses a difference merging algorithm to logically merge and resolve conflicts between the shadow operation chain and the main blockchain ledger operations that occur after the baseline version vector. Write the logical merge and conflict resolution sequence of operations into the main blockchain ledger, update the main document database, and broadcast the synchronization results. The edge proxy client updates its local state and cleans up shadow copies based on the synchronization results.

[0040] In summary, this invention ensures the continuity of document processing during network interruptions and avoids data loss by using shadow copies and shadow operation chains in the edge agent client. Through version vector comparison and field-level conflict detection in the cloud service center, it achieves accurate and intelligent merging of offline and cloud operations. By storing operation logs and conflict resolution records in the main blockchain ledger, it guarantees the immutability and traceability of the entire document flow process. This effectively solves the problems of business interruption and data inconsistency caused by network unreliability in the multimodal transport field, providing reliable support for comprehensive digitalization and real-time processing.

[0041] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A multimodal transport document digital circulation and processing system, characterized in that, The system includes a cloud service center and multiple edge agent clients; The cloud service center includes: The master document database stores authoritative data on multimodal transport documents, with each document data record associated with a version vector; The main blockchain ledger is used to record all verified operation log entries that change the status of a document in sequence. Each operation log entry is associated with a new version vector of the corresponding document after the operation is executed. The synchronization coordination module is used to receive synchronization requests and execute the difference merging algorithm; The edge proxy client is deployed on a job node with an unstable network, including: A local lightweight module used to provide an independent runtime environment in offline settings; The shadow copy management module is used to create a shadow copy of the target document in a local lightweight module when a network interruption is detected. The shadow copy includes the document status and baseline version vector obtained from the master document database. The baseline version vector is a version vector copy of the snapshot of the master document database when the shadow copy is created at the edge. The offline operation module is used to perform local operations on the shadow copy during network interruption, record each local operation to the shadow operation chain, and update the local state of the shadow copy and the local version vector generated based on the baseline version vector. The synchronization agent module is used to package the baseline version vector, shadow operation chain, and the current state of the shadow replica into a synchronization data packet and send it to the synchronization coordination module when the network recovers.

2. The multimodal transport document digital circulation and processing system according to claim 1, characterized in that, The shadow operation chain is a time-sequentially linked data structure stored in a local lightweight module, used to record all operations performed on the shadow copy in an offline environment; Each entry in the shadow operation chain includes an operation type, operation content, operator digital signature, local timestamp, and a local version vector of the shadow copy after the operation is executed.

3. The multimodal transport document digital circulation and processing system according to claim 1, characterized in that, The version vector, baseline version vector, and local version vector all adopt a unified multi-dimensional version vector format to uniquely identify a document's specific state version in the global operation history. Each version vector is represented as follows: ,in The total number of nodes involved in the modification in the system, the th Each component Indicates from the The cumulative number of operations on each node, when the edge proxy client is offline, the local version vector updated by the operation on the shadow copy, only increments on the dimension component representing the edge proxy client itself.

4. The multimodal transport document digital circulation and processing system according to claim 1, characterized in that, The difference merging algorithm is used to logically merge and resolve conflicts between the shadow operation chain and the operation log entries recorded after the baseline version vector in the main blockchain ledger, so as to achieve data synchronization. The steps of the synchronization coordination module in executing the difference merging algorithm include: Receive the synchronization data packet from the edge agent client and parse out the target document identifier, baseline version vector and shadow operation chain from it; Based on the target document identifier, a version determination is performed, and all cloud operation log entries with version vectors greater than the baseline version vector are retrieved from the main blockchain ledger and used as a concurrent cloud operation set. The shadow operation chain and the concurrent cloud operation set are logically merged and conflict resolution is performed.

5. A multimodal transport document digital circulation and processing system according to claim 4, characterized in that, The determination logic for the version is as follows: For the baseline version vector: The version vector associated with each entry in the cloud operation log of the main blockchain ledger is: , If and only if for all All have It is established, and at least one exists. Make If it is established, then it is determined that... Greater than , recorded as At this point, cloud operation log entries are included in concurrent cloud operations.

6. The multimodal transport document digital circulation and processing system according to claim 4, characterized in that, The steps of the difference merging algorithm for performing logical merging and conflict resolution are as follows: Based on the baseline version vector contained in the synchronization data packet The latest version vector associated with the target document in the master document database is... ; All data fields modified by shadow operations are parsed from the shadow operation chain to form an offline modified field set. ; All data fields modified by cloud operations are parsed from the concurrent cloud operation set to form a set of cloud modified fields. ; The synchronization coordination module resolves conflicts: when If so, it is determined that there were no other concurrent modifications in the cloud during the offline period and no version conflict. when Then calculate the set of offline modified fields. With the cloud-modified field set The intersection; when If so, it is determined that there is no field conflict; when If a field conflict is found, a conflict resolution process is triggered for the fields within the intersection.

7. A multimodal transport document digital circulation and processing system according to claim 6, characterized in that, The conflict resolution process is executed by the synchronization coordination module, including: For each field determined to have a conflict, a decision is made according to a predefined set of conflict resolution rules, which includes: Priority rules: Predefine priorities for different types of data sources and determine the merging results according to the predefined priorities; Manual intervention rule: When conflicting modifications have the same priority, or when a conflicting field is marked as a critical business field, the synchronization coordination module terminates automatic merging, generates an early warning report containing conflict details, and sends it to the administrator terminal, awaiting manual arbitration instructions; After the conflict resolution is completed, the synchronization coordination module generates a merge decision record, which includes the conflict field, the operation values ​​of both parties, the resolution result, the rule identifier applied, and the timestamp, and writes the merge decision record as an operation log entry into the main blockchain ledger.

8. A multimodal transport document digital circulation and processing system according to claim 4, characterized in that, After the synchronization and coordination module completes the logical merging and conflict resolution, it writes all adopted operations, including merged shadow operations, cloud operations that were not resolved, and conflict resolution logs, into the main blockchain ledger in global chronological order. Based on the latest operation history after writing, calculate and generate a new final version vector for the target document; Update the master document database using the final version vector and the synchronized document status; The synchronization results, including the final version vector and the updated document status, will be sent to the edge agent client that initiated the synchronization and other relevant online clients. After receiving the synchronization result from the cloud service center, the synchronization proxy module of the edge proxy client updates the local cache with the synchronization result and clears the synchronized shadow copy and the corresponding shadow operation chain, thus completing the consistency between the local state and the cloud state.

9. A multimodal transport document digital circulation and processing system according to claim 1, characterized in that, The working principle of this system is as follows: When the edge agent client detects a network outage, it creates a shadow copy with a baseline version vector for the document to be processed. In offline mode, perform operations on the shadow copy and record them to the shadow operation chain; After the network is restored, the baseline version vector and shadow operation chain will be sent to the cloud service center; The cloud service center uses a difference merging algorithm to logically merge and resolve conflicts between the shadow operation chain and the main blockchain ledger operations that occur after the baseline version vector. Write the logical merge and conflict resolution sequence of operations into the main blockchain ledger, update the main document database, and broadcast the synchronization results. The edge proxy client updates its local state and cleans up shadow copies based on the synchronization results.

Images