Credible traceability method and device for cross-border logistics

Abstract

The invention relates to the technical field of data processing, and discloses a credible traceability method and device for cross-border logistics, and the method comprises the steps: obtaining multi-modal logistics data in a cross-border logistics process, carrying out the data processing, and generating standardized structural feature information; performing comparison verification on the structured feature information and a preset compliance rule to generate a comparison verification result, and storing the comparison verification result and the corresponding structured feature information to a block chain network; and when a data conflict or rule violation is detected based on a comparison verification result, automatically triggering an intelligent contract deployed on the block chain network to execute a predefined risk handling action. According to the method and the device, standardized structured processing and credible evidence storage of the cross-border logistics multi-modal data can be realized, and the intelligent contract is automatically triggered to execute risk disposal when the data conflicts or violates the compliance rule, so that the reliability and the high efficiency of cross-border logistics traceability are guaranteed.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a reliable traceability method and apparatus for cross-border logistics. Background Technology

[0002] With the advancement of global trade integration, cross-border logistics involves multiple participants such as cargo owners, carriers, and customs, and covers multiple links such as warehousing, transportation, and customs declaration. The resulting logistics data exhibits multimodal characteristics, and reliable traceability throughout the entire process has become a key requirement to ensure trade efficiency and security.

[0003] Current cross-border logistics traceability technologies largely rely on manual processing of multimodal and heterogeneous data such as bills of lading and quality inspection reports. This makes it difficult to uniformly transform this heterogeneous data into standardized, structured feature information, leading to difficulties in data interoperability and mutual recognition, and low efficiency in subsequent verification. Furthermore, the storage methods for data and verification results lack sufficient reliability, and when data conflicts or rule violations are detected, manual intervention is required, generally resulting in response delays. Therefore, existing technologies suffer from inefficiencies due to reliance on manual multimodal data processing, and response delays due to the lack of reliable evidence storage and automated processing mechanisms, failing to meet the high efficiency and reliability requirements of reliable traceability in cross-border logistics.

[0004] The preceding description is intended to provide general background information and does not necessarily constitute prior art. Summary of the Invention

[0005] This application provides a reliable traceability method and apparatus for cross-border logistics, which can realize standardized and structured processing and reliable storage of multimodal data in cross-border logistics, and automatically trigger smart contract execution risk disposal when data conflicts or violations of compliance rules occur, thereby ensuring the reliability and efficiency of cross-border logistics traceability.

[0006] In a first aspect, embodiments of this application provide a reliable traceability method for cross-border logistics, including: Acquire multimodal logistics data from cross-border logistics processes and process the data to generate standardized structured feature information; The structured feature information is compared and verified with preset compliance rules to generate a comparison and verification result, and the comparison and verification result and the corresponding structured feature information are stored in the blockchain network. When a data conflict or rule violation is detected based on the comparison and verification results, a smart contract deployed on the blockchain network is automatically triggered to execute a predefined risk management action.

[0007] Furthermore, in some embodiments of this application, the step of acquiring multimodal logistics data in the cross-border logistics process and processing the data to generate standardized structured feature information includes: By parsing text-based logistics documents from different data sources using a multimodal large language model, key entity information related to logistics elements can be extracted from unstructured text. Based on the federated learning framework, the key entity information is spatiotemporally aligned with the sensing data from IoT sensors to construct spatiotemporally correlated data that characterizes the state changes of logistics objects. Based on the key entity information and the spatiotemporal correlation data, a consistency check is performed using a multimodal cross-validation engine to generate a unified feature vector that serves as the structured feature information.

[0008] Furthermore, in some embodiments of this application, the step of performing spatiotemporal alignment processing on the key entity information and sensor data from IoT sensors based on the federated learning framework to construct spatiotemporal correlation data for characterizing changes in the state of logistics objects includes: The key entity information and the sensor data are time-stamped and mapped to geographic locations to generate initial alignment data. The initial aligned data is fused using a collaborative training algorithm within the federated learning framework to eliminate biases between different data sources and generate corresponding spatiotemporal correlation data.

[0009] Furthermore, in some embodiments of this application, the step of comparing and verifying the structured feature information with preset compliance rules, generating a comparison and verification result, and storing the comparison and verification result and the corresponding structured feature information in a blockchain network includes: Customs regulations are dynamically parsed in natural language form based on a large language model, and converted into executable, machine-readable verification rules through rule dynamic mapping technology, which serve as the preset compliance rules. The structured feature information and the machine-readable verification rules are matched and verified to generate the verification result, which includes pass, conflict, or anomaly. The structured feature information, the verification result, and its digital fingerprint are packaged together into a block and persistently stored in the blockchain network.

[0010] Furthermore, in some embodiments of this application, the step of converting the customs regulations into executable machine-readable verification rules using rule dynamic mapping technology includes: Using a large language model, semantic parsing and logical structure analysis are performed on customs regulations in natural language form to generate an intermediate representation logic tree; The intermediate representation logic tree is compiled into script code that can be executed in the verification engine, forming the machine-readable verification rules.

[0011] Furthermore, in some embodiments of this application, the automatic triggering of a smart contract deployed on the blockchain network to execute predefined risk management actions when a data conflict or rule violation is detected based on the comparison verification result includes: The smart contract listens to the verification results. When a verification result indicating a conflict or anomaly is detected, the risk calculation model is automatically invoked to calculate a risk index based on the type, frequency, and severity of the conflict data. Based on the different levels of the risk index, different levels of alarm strategies are triggered through the smart contract alarm module, and alarm information is sent to at least one predefined relevant party node; Based on the alarm information, at least one emergency response plan is generated and recommended.

[0012] Furthermore, in some embodiments of this application, the step of triggering different levels of alarm strategies through the smart contract alarm module according to the different levels to which the risk index belongs includes: Multiple risk level thresholds are preset, and the risk index is mapped to the corresponding risk level; Based on the risk level, the alarm channel and alarm content format are adaptively selected, and alarm actions are executed.

[0013] Furthermore, in some embodiments of this application, the step of generating and recommending at least one emergency response plan based on the alarm information includes: The alarm information is analyzed to extract the corresponding conflict event type, risk level, and associated logistics object identifier, which are used as initialization parameters for the digital twin model. Based on the initialization parameters, drive the digital twin model of the logistics scenario, simulate at least two different emergency response paths, and deduce the consequences of each emergency response path. Based on the simulated consequences, the key performance indicators of each emergency response path are evaluated to obtain the evaluation results. Based on the evaluation results, an optimal treatment path and a corresponding multilingual treatment report are generated.

[0014] Furthermore, in some embodiments of this application, the method further includes: In response to a traceability request from an authorized node, determine the logistics event to be traced and the associated data range; Based on the data range, all evidence-based data related to the logistics event are obtained from the blockchain network and at least one associated blockchain; The stored evidence data is processed using zero-knowledge proof technology to extract verification data and generate a judicial-grade source tracing evidence report that includes data integrity proof without exposing sensitive details.

[0015] Secondly, embodiments of this application provide a reliable traceability device for cross-border logistics, comprising: The data processing module is used to acquire and process multimodal logistics data in the cross-border logistics process, and generate standardized structured feature information. The comparison and verification module is used to compare and verify the structured feature information with preset compliance rules, generate comparison and verification results, and store the comparison and verification results and the corresponding structured feature information in the blockchain network. The risk handling module is used to automatically trigger a smart contract deployed on the blockchain network to execute predefined risk handling actions when a data conflict or rule violation is detected based on the comparison and verification results.

[0016] This application provides a trusted traceability method and apparatus for cross-border logistics. First, by acquiring multimodal cross-border logistics data and processing it to generate standardized structured feature information, the originally heterogeneous and difficult-to-interoperable multimodal logistics data is transformed into unified standard structured information, breaking down barriers to the collaborative use of multi-source data and providing a unified data foundation for subsequent compliance verification, thus solving the problem of inefficient utilization of multimodal data. Second, by comparing and verifying the structured feature information with preset compliance rules and storing the results and structured information on a blockchain network, the immutability of the blockchain ensures the integrity and authenticity of the verification results and core logistics data, avoiding the risk of data tampering or loss, and achieving trusted evidence storage of traceability data. Finally, by automatically triggering the execution of smart contracts on the blockchain to handle risks when data conflicts or rule violations are detected, abnormal situations can be automatically responded to without human intervention, reducing the delay of manual processing and improving the timeliness of risk handling. Therefore, the trusted traceability solution for cross-border logistics provided in this application can achieve standardized and structured processing and trusted storage of multimodal data in cross-border logistics, and automatically trigger smart contract execution risk disposal when data conflicts or violations of compliance rules occur, thereby ensuring the reliability and efficiency of cross-border logistics traceability. Attached Figure Description

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

[0018] Figure 1 This is an application environment diagram of the trusted traceability method for cross-border logistics provided in the embodiments of this application; Figure 2This is a flowchart illustrating the trusted traceability method for cross-border logistics provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the trusted traceability device for cross-border logistics provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0019] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of systems and methods consistent with those detailed in the appended claims or with some aspects of this application.

[0020] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover descriptions such as non-exclusive inclusion, so that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, components, features, and elements with the same names in different embodiments of this application may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

[0021] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0022] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no specific meaning in itself. Therefore, "module," "part," or "unit" may be used interchangeably.

[0023] To address the aforementioned technical problems and overcome the shortcomings of existing technologies, this application provides a reliable traceability method and apparatus for cross-border logistics. This method enables standardized and structured processing and reliable storage of multimodal data in cross-border logistics, and automatically triggers smart contract execution risk management when data conflicts or violations of compliance rules occur, thereby ensuring the reliability and efficiency of cross-border logistics traceability.

[0024] Figure 1This is a diagram illustrating the application environment of a trusted traceability method for cross-border logistics in one embodiment. (Refer to...) Figure 1 This trusted traceability method for cross-border logistics is applied to a trusted traceability system for cross-border logistics. The trusted traceability system for cross-border logistics includes a terminal 110 and a server 120. The terminal 110 and server 120 are connected via a network. The terminal 110 can be a desktop terminal or a mobile terminal, and the mobile terminal can be at least one of a mobile phone, tablet, or laptop. The server 120 can be a standalone server or a server cluster consisting of multiple servers. The server 120 is configured to execute the aforementioned trusted traceability method for cross-border logistics, including: acquiring multimodal logistics data in the cross-border logistics process and processing the data to generate standardized structured feature information; comparing and verifying the structured feature information with preset compliance rules, generating comparison and verification results, and storing the comparison and verification results and the corresponding structured feature information in a blockchain network; when data conflicts or rule violations are detected based on the comparison and verification results, automatically triggering a smart contract deployed on the blockchain network to execute predefined risk handling actions.

[0025] Please see Figure 2 , Figure 2 This is a flowchart illustrating a trusted traceability method for cross-border logistics provided in an embodiment of this application. This embodiment primarily uses the application of this trusted traceability method for cross-border logistics to computer equipment as an example for illustration. Specifically, the trusted traceability method for cross-border logistics provided in an embodiment of this application may include the following steps: S1. Acquire multimodal logistics data in the cross-border logistics process and process the data to generate standardized structured feature information; Specifically, for step S1, the first step is to collect various types of data generated throughout the entire cross-border logistics process. This data includes text data, sensor data, and image data. Text data includes bills of lading, customs declarations, quality inspection reports, etc., containing cargo information descriptions in different languages. Sensor data includes temperature and humidity records during cargo transportation, GPS positioning trajectory data, and container door opening and closing status data. Image data includes photos of container seals and scanned images of the cargo's appearance. For example, obtaining the Chinese bill of lading for a batch of cross-border cold chain fruit, the Chinese bill of lading records: "Goods name (cherries), quantity (1000 boxes), destination (Hamburg, Germany), real-time temperature and humidity sensor data (2024-10-05 08:00: temperature 2℃, humidity 75%; 2024-10-05 08:30: temperature 3℃, humidity 73%), and a photo of the container seal (showing seal number "C89765").

[0026] Then, the acquired multimodal heterogeneous data is organized, parsed, and integrated to eliminate data format differences and information redundancy. Information related to core logistics elements is extracted, including cargo category, quantity, transportation status, and key identifiers. This information is then transformed into structured data in a unified format. For example, the bill of lading information, temperature and humidity data, and seal number information of the aforementioned cold chain fruit are integrated into standardized structured feature information containing "Cargo Name - Cherries, Quantity - 1000 boxes, Destination - Hamburg, Germany, Temperature and Humidity Record (Time - Temperature - Humidity), Seal Number - C89765," ensuring that different types of data can be uniformly identified and used subsequently.

[0027] S2. Compare and verify the structured feature information with the preset compliance rules, generate the comparison and verification results, and store the comparison and verification results and the corresponding structured feature information in the blockchain network; Specifically, for step S2, the compliance requirements involved in cross-border logistics are determined in advance. These rules can come from customs regulations and trade agreement requirements of different countries and regions. For example, Germany requires that the temperature be maintained between 0-4℃ throughout the cold chain transportation of imported fresh fruit, and that the error between the quantity recorded on the bill of lading and the actual quantity of goods be ≤1%. The generated standardized structured feature information is matched and checked against the above-mentioned preset compliance rules one by one to determine whether the structured information meets the rule requirements, and a comparison and verification result of pass, conflict, or anomaly is generated. For example, the temperature and humidity records (both within the range of 0-4℃) and quantity (1000 boxes, no error) in the structured feature information of the above-mentioned cold chain cherries are compared with the German customs compliance rules. If it is confirmed to meet the requirements, a verification pass result is generated; if the temperature and humidity data shows a temperature of 5℃ at a certain moment, a temperature exceeding the standard result is generated, and a conflict verification result is generated. The verification results, along with the corresponding standardized structured feature information, are uploaded to the blockchain network. Leveraging the immutability and traceability of blockchain, this data is persistently stored, ensuring its integrity and authenticity. Furthermore, all cross-border logistics participants (such as cargo owners, carriers, and customs) can view the data within their authorized scope, but cannot arbitrarily modify it. For example, the verified results and the corresponding structured feature information of cherries can be packaged into a data block and uploaded to a dedicated cross-border logistics blockchain network to achieve trusted data storage.

[0028] S3. When a data conflict or rule violation is detected based on the comparison and verification results, the smart contract deployed on the blockchain network is automatically triggered to execute predefined risk disposal actions; Specifically, for step S3, the generated comparison and verification results are continuously monitored. When a conflict or anomaly is detected, indicating a data conflict (e.g., temperature and humidity data conflicting with compliance requirements) or a rule violation (e.g., bill of lading commodity code not matching customs requirements), it is determined to be an anomaly requiring handling. For example, if the comparison and verification result for the aforementioned cold chain cherries shows a temperature of 5℃, violating the German customs requirement of 0-4℃, a verification conflict is detected, indicating a rule violation. When a data conflict or rule violation is detected, the system automatically invokes a smart contract pre-deployed on the blockchain network. The smart contract is pre-written and deployed, automatically executable code logic containing rules for handling anomalies. For example, regarding the case of excessive cold chain temperature, the smart contract deployed on the blockchain is pre-set to automatically trigger alarms and handling logic when a temperature exceeding 0-4℃ is detected. The smart contract is then automatically invoked. The smart contract executes risk handling operations according to the pre-set logic, including sending alarm information to relevant participants and generating emergency handling prompts. For example, the smart contract triggered above automatically sends an alarm message to the cargo owner's management system and the carrier's dispatch platform: "The temperature of the cherries exceeds the standard (currently 5℃). Please check the refrigeration equipment immediately." At the same time, the alarm and handling actions are recorded on the blockchain to ensure that the handling process is traceable.

[0029] This embodiment solves the problem of data heterogeneity and difficulty in reuse by transforming multimodal logistics data into standardized structured information; it ensures the credibility of data and verification results by comparing and verifying structured information with compliance rules and storing evidence on the blockchain; and it reduces the delay of manual intervention by automatically triggering smart contracts to handle anomalies. Thus, the overall cross-border logistics traceability achieves data availability, credible evidence storage, and efficient anomaly handling, ensuring the reliability and efficiency of cross-border logistics credible traceability.

[0030] Furthermore, in some embodiments, step S1, "acquiring multimodal logistics data in the cross-border logistics process and processing the data to generate standardized structured feature information," may specifically include: S11. Use a multimodal large language model to parse text-based logistics documents from different data sources and extract key entity information related to logistics elements from unstructured text; Specifically, for step S11, collect text documents provided by different participants in cross-border logistics. These documents may come from data sources such as cargo owners (packing lists), carriers (bills of lading), and quality inspection agencies (inspection reports), and include multiple languages ​​such as Russian bills of lading, Spanish quality inspection certificates, and German customs declarations. The text formats are mostly unstructured, such as freely formatted PDF documents and scanned text recognition. For example, obtain a Russian bill of lading with the text content including (goods: Gala apples, quantity: 800 boxes, temperature control threshold: 0-5℃, destination: Moscow, Russia); and obtain a Spanish quality inspection report stating "quality inspection qualified, inspection date: 2024-10-01, humidity limit: ≤85%". The unstructured text documents mentioned above are input into a multimodal large language model. Through semantic understanding, language adaptation, and entity recognition capabilities, the model automatically filters out information related to core logistics elements, including cargo type, quantity, temperature control threshold, humidity limit, destination, and inspection date, while excluding irrelevant text (such as document format instructions, signatures, and remarks). For example, the model extracts key entity information from a Russian bill of lading: "Cargo type - Gala apples, Quantity - 800 boxes, Temperature control threshold - 0-5℃, Destination - Moscow, Russia"; and from a Spanish quality inspection report, it extracts "Inspection result - Qualified, Inspection date - 2024-10-01, Humidity limit - ≤85%".

[0031] S12. Based on the federated learning framework, key entity information and sensor data from IoT sensors are spatiotemporally aligned to construct spatiotemporally correlated data to characterize changes in the state of logistics objects. Specifically, for step S12, IoT sensor data bound to the logistics object is collected. This data includes GPS trajectory data (recording the real-time geographical location and time of the goods) and temperature and humidity sensor data (recording the temperature and humidity of the environment where the goods are located at fixed intervals). Based on the federated learning framework, the key entity information and sensor data are first timestamped to ensure that the time dimension of the data is consistent. Geographical location mapping is then performed to associate the geographical location of the GPS data with the transportation route and destination in the key entity information, generating initial aligned data. Through the collaborative training algorithm under the federated learning framework, feature fusion is performed on the initial aligned data. Since different sensors (such as GPS modules and temperature and humidity sensors) may have hardware errors, or the recording standards of key entity information and sensor data may be different (such as unifying the temperature unit), the collaborative training algorithm will correct data deviations without disclosing the privacy of each data source, such as calibrating the small errors of the temperature and humidity sensors, and finally generate spatiotemporal correlated data.

[0032] S13. Based on key entity information and spatiotemporal correlation data, a consistency check is performed through a multimodal cross-validation engine to generate a unified feature vector as structured feature information; Specifically, for step S13, the extracted key entity information and the generated spatiotemporal correlation data are input into the multimodal cross-validation engine. The engine performs verification from two dimensions: data logical consistency and parameter matching. For example, it verifies whether the "temperature control threshold -0-5℃" in the key entity information matches the "temperature 3.1℃ / 4.0℃" in the spatiotemporal correlation data; it also verifies whether the "goods category - Gala apples" in the key entity information is consistent with the "corresponding goods - Gala apples" in the spatiotemporal correlation data. If the verification results show that the key entity information and the spatiotemporal correlation data are completely consistent, the multimodal cross-validation engine integrates the two types of data into a structured feature vector in a unified format. The vector dimensions include core elements such as goods category, quantity, temperature control threshold, humidity limit, inspection date, and transportation spatiotemporal information (time-geographical location-temperature and humidity), serving as the standardized data foundation for subsequent compliance verification.

[0033] This embodiment uses a multimodal large language model to accurately parse multilingual unstructured text documents, and uses a federated learning framework to align multi-source data and eliminate biases. A multimodal cross-validation engine verifies consistency and efficiently generates accurate and unified standardized structured feature information, providing a reliable data foundation for subsequent compliance comparison and verification of cross-border logistics data, and solving the problem of difficult collaborative utilization of multi-source heterogeneous data.

[0034] Furthermore, in some embodiments, step S12, "based on a federated learning framework, performing spatiotemporal alignment processing on key entity information and sensing data from IoT sensors to construct spatiotemporal correlation data for characterizing changes in the state of logistics objects," may specifically include: S121. Perform timestamp synchronization and geolocation mapping on key entity information and sensor data to generate initial alignment data; Specifically, for step S121, the two types of core data to be processed include key entity information and sensor data. Key entity information originates from logistics documents and includes information directly related to the logistics object, such as cargo category, transportation time period, target route, and temperature control requirements. Sensor data originates from IoT devices and includes real-time collected status data such as GPS positioning data, temperature and humidity records, and cargo vibration data. A unified calibration is performed on the time dimension of both types of data. The transportation time period in the key entity information is extracted as a time benchmark. The collection timestamps of the sensor data are matched with this benchmark time period, and invalid sensor data exceeding the transportation time period (such as test data before transportation begins) is eliminated. The time format of the sensor data is standardized (e.g., uniformly set to "YYYY-MM-DDHH:MM") to ensure that the two types of data correspond in the time dimension. The GPS positioning information in the sensor data is spatially correlated with the target route in the key entity information. First, the geographical path corresponding to the target route in the key entity information is parsed, and then the latitude and longitude coordinates of the GPS data are matched to this geographical path to determine the transportation segment corresponding to each set of sensor data. Simultaneously, the logistics node information for this segment is supplemented. By integrating the results of timestamp synchronization and geolocation mapping, the core content of key entity information (goods category, temperature control requirements) is bound with the corresponding time and geolocation sensor data (temperature, GPS coordinates), forming initial aligned data containing "time-geographic location-goods category-temperature control requirements-sensor data".

[0035] S122. Through the collaborative training algorithm under the federated learning framework, feature fusion is performed on the initial aligned data to eliminate the bias between various data sources and generate corresponding spatiotemporal correlation data. Specifically, for step S122, section 2.1 analyzes the possible types of deviations that may exist in the initial alignment data from different data sources. These may include hardware errors in sensor data, differences in the representation of key entity information and sensor data, and GPS positioning drift errors. Under the federated learning framework, each data source (such as the cargo owner's document system and the carrier's sensor platform) uploads the feature parameters of the initial alignment data (such as temperature deviation coefficient, time matching threshold, and GPS drift range) to the collaborative training node without disclosing its local original data. The collaborative training algorithm constructs a unified deviation correction model based on multi-source feature parameters and optimizes the correction parameters through iterative training. For example, it calibrates the +0.2℃ fixed deviation of the temperature and humidity sensor and the -0.05° longitude correction value of GPS based on multiple sets of sensor data to ensure that the correction model can adapt to the deviation characteristics of different data sources. The correction parameters obtained from collaborative training are applied to the initial aligned data to correct fields with biases. For example, temperature and humidity data "-20℃" and "-19℃" are corrected to "-20.2℃" and "-19.2℃", and GPS latitude and longitude "122.3°E" is corrected to "122.25°E". The specific time range of "daily daytime" (08:00-18:00) is also clearly defined to eliminate discrepancies in representation. Feature fusion is then performed on the corrected initial aligned data, deeply binding "time-geographical location-goods category-temperature control requirements-corrected sensor data" to form structured spatiotemporal correlated data. This ensures that the data is unbiased in time, space, and content dimensions, accurately representing the real-time status changes of logistics objects.

[0036] This embodiment achieves initial alignment of key entity information and sensor data through timestamp synchronization and geolocation mapping. Then, it relies on federated learning and collaborative training to eliminate biases from multiple data sources, ultimately generating accurate and unified spatiotemporal correlation data. This effectively solves the mismatch problem of multi-source data in time, space, and content dimensions, providing precise spatiotemporal dimension data support for subsequent consistency verification and compliance verification of logistics data.

[0037] Furthermore, in some embodiments, step S2, "comparing and verifying the structured feature information with preset compliance rules, generating a comparison and verification result, and storing the comparison and verification result and the corresponding structured feature information in the blockchain network," may specifically include: S21. Based on a large language model, customs regulations in natural language form are dynamically parsed, and dynamic rule mapping technology is used to convert customs regulations into executable machine-readable verification rules as preset compliance rules. Specifically, for step S21, the latest customs regulations of various countries / regions involved in cross-border logistics are collected. These regulations are expressed in natural language and cover cargo transportation requirements, data recording standards, declaration standards, etc., and can be adjusted as policies are updated. The aforementioned natural language regulations are input into a large language model. The model, through semantic understanding and logical structure extraction capabilities, decomposes the core constraints, key parameters, and relationships in the regulations, eliminating the ambiguity and vagueness of natural language. Through rule dynamic mapping technology, the structured constraint logic parsed by the large language model is converted into machine-recognizable and executable coded verification rules (such as conditional statements, parameter matching formulas, etc.).

[0038] S22. Match and verify the structured feature information and machine-readable verification rules to generate verification results, including pass, conflict, or anomaly; Specifically, for step S22, standardized structured feature information in cross-border logistics is obtained. This information contains core data from the entire cargo transportation process and corresponds one-to-one with the constraint dimensions of machine-readable verification rules. Each field of the structured feature information is compared with the corresponding machine-readable verification rule to check whether the data meets the rule constraints. The final state is determined based on the verification results. If all rule constraints are met, a pass result is generated; if some constraints are not met (such as temperature exceeding the standard at certain time points), a conflict result is generated; if key constraints are seriously unmet (such as missing core fields or incorrect data format), an abnormal result is generated.

[0039] S23. Package the structured feature information, verification results and their digital fingerprints together into a block and persistently store it in the blockchain network; Specifically, in step S23, a hash calculation is performed on the structured feature information and verification results to generate a unique digital fingerprint (hash value). This fingerprint can be used to verify whether the data has been tampered with; if the data content changes, the digital fingerprint will change accordingly. The structured feature information, verification results, and digital fingerprint are integrated into a data block according to a preset format. The block also includes basic identification information such as a timestamp and block number to ensure data correlation and traceability. The packaged block is uploaded to the blockchain network, and the block confirmation is completed through the blockchain's distributed node consensus mechanism (such as proof-of-work or proof-of-stake). Subsequently, the block is permanently stored in all nodes. Due to the immutable nature of the blockchain, the stored structured feature information, verification results, and digital fingerprint cannot be unilaterally modified. Any participant can query the data within the authorized scope and can confirm the data integrity by comparing the digital fingerprint. For example, after the above two blocks are consensus-based among nodes, they are permanently stored in the cross-border logistics blockchain network. Cargo owners, carriers, customs, etc., can all query the corresponding cargo data and verification results and can verify that the data has not been tampered with through the digital fingerprint.

[0040] This embodiment ensures compliance rules adapt to policy changes by dynamically converting natural language customs regulations into machine-readable rules; generates reliable verification results through precise matching of structured information and rules; and combines digital fingerprints and blockchain storage to ensure data immutability and traceability, providing dynamic, accurate, and reliable support for cross-border logistics compliance verification.

[0041] Furthermore, in some embodiments, step S21, "converting customs regulations into executable machine-readable verification rules using rule dynamic mapping technology," may specifically include: S211. Use a large language model to perform semantic parsing and logical structure analysis on customs regulations in natural language form, and generate an intermediate representation logic tree; Specifically, for step S211, the text of customs regulations issued by the target country / region in the cross-border logistics scenario and expressed in natural language is collected. These clauses usually contain content such as goods access conditions, data recording requirements, and compliance judgment standards, and the expression can have multi-level and multi-condition association characteristics. The above natural language regulatory clauses are input into the big language model. The model uses semantic understanding capabilities to decompose the core elements, constraints, and violation judgment conditions in the clauses, while eliminating redundant expressions in the clauses and clarifying the specific boundaries of each compliance requirement. The model further sorts out the logical hierarchy and relationship of each parsing result, distinguishing the structure of "precondition-core constraint-violation consequence". For example, "imported dairy products" is a precondition, and constraints 1-4 are core compliance requirements. Violation is considered a consequence of not meeting the constraints. At the same time, the parallel relationship between constraints (constraints 1-4 must be met simultaneously) and the condition triggering relationship are clarified. Only when the temperature record exists is it judged whether the recording interval meets constraint 4; if the record is missing, a violation is directly triggered. Based on the above logical structure analysis results, the model transforms compliance requirements into a visual hierarchical logic tree. The root node of the tree is the regulatory topic, the first-level child nodes are the preconditions and core constraint categories, the second-level child nodes are the specific constraint content, and the leaf nodes are the violation judgment conditions.

[0042] S212. Compile the intermediate representation logic tree into script code that can be executed in the verification engine to form machine-readable verification rules; Specifically, for step S212, based on the compatibility requirements of the cross-border logistics verification engine, a scripting language (such as Python, Lua, etc.) that can be directly parsed and executed by the engine is selected. This language must support basic logical operations such as conditional judgment, format matching, and numerical calculation to ensure accurate mapping of constraints and violation judgment rules in the logic tree. The nodes at each level representing the logic tree are converted into code statements in the corresponding scripting language. The root node and first-level child nodes are converted into code comments, constraints in second-level and lower-level nodes are converted into conditional judgment statements, format matching statements, or numerical calculation statements, and violation conditions in leaf nodes are converted into violation marker statements. The generated script code undergoes syntax validation to ensure no syntax errors (such as correct bracket matching, variable definitions, and function calls). Simultaneously, considering the verification engine's operating environment, the code format is adjusted (such as variable naming conventions and function parameter types) to ensure the code can be directly called and executed by the verification engine. The script code, after syntax validation and compatibility adjustments, becomes a machine-readable verification rule that can be executed in the verification engine. The verification engine can call this code function, input relevant data for specific goods, and automatically output compliance or violation results, achieving automated application of natural language regulations.

[0043] This embodiment uses a large language model to realize the semantic parsing and logical structuring of natural language customs regulations, generate an intermediate representation logic tree, and then compile the logic tree into script code that can be executed by the verification engine. This accurately realizes the conversion of natural language regulations into machine-readable rules, solves the problem that natural language regulations are difficult to use directly for automated compliance verification, and provides a precise and executable rule foundation for cross-border logistics compliance verification.

[0044] Furthermore, in some embodiments, step S3, "when a data conflict or rule violation is detected based on the comparison and verification results, automatically triggering a smart contract deployed on the blockchain network to execute a predefined risk handling action," may specifically include: S31. By monitoring the verification results through smart contracts, when a verification result indicating a conflict or anomaly is detected, the risk calculation model is automatically invoked to calculate the risk index based on the type, frequency, and severity of the conflict data. Specifically, for step S31, the smart contract deployed on the blockchain network continuously monitors the comparison and verification results of cross-border logistics data. This monitoring process is real-time and uninterrupted, ensuring that no verification results indicating data conflicts (such as mismatch between sensor data and compliance rules) or anomalies (such as missing core data) are missed. When the smart contract detects a verification result that clearly points to a conflict or anomaly, it immediately triggers the subsequent risk assessment process without waiting for manual confirmation. The smart contract automatically initiates a call to the preset risk calculation model, which is pre-loaded with risk assessment dimensions for cross-border logistics scenarios, including the type of conflicting data (such as temperature control violations, route deviations, inconsistent document information, etc.), frequency of occurrence (such as the number of times the same conflict occurs consecutively), and severity (such as the difference in temperature exceeding the standard, the distance of route deviation, and the criticality of document errors). The risk calculation model performs quantitative calculations based on the above dimensions, generating specific risk indices for conflicting or anomaly situations, typically values ​​from 0 to 100, with higher values ​​indicating higher risk.

[0045] S32. Based on the different levels of the risk index, trigger different levels of alarm strategies through the smart contract alarm module, and send alarm information to at least one predefined relevant party node; Specifically, for step S32, multiple risk level thresholds are pre-set, mapping the risk index to the corresponding risk level, such as low risk: 0-30, medium risk: 31-60, and high risk: 61-100. Different levels correspond to different levels of urgency and handling priorities. The calculated risk index is compared with the preset thresholds to determine its risk level. The smart contract alarm module adaptively matches the alarm channel according to the risk level, such as low risk: SMS notification, medium risk: email notification, and high risk: SMS + email + system pop-up + telephone voice notification; alarm content format: low risk only briefly describes the conflict; high risk must include conflict details, current cargo status, and emergency handling prompts. The smart contract synchronously sends alarm information to the corresponding node's system or terminal based on a predefined list of relevant parties, such as cargo owners, carriers, cold chain operation and maintenance teams, and destination port customs. For example, the above alarm information is sent to the mango cargo owner's management system, the carrier's scheduling platform, the cold chain operation and maintenance team's mobile SMS, and the customs supervision system.

[0046] S33. Based on the alarm information, generate and recommend at least one emergency response plan; Specifically, for step S33, 3.1, the alarm information is analyzed to extract the conflict event type (e.g., temperature control violation), risk level (e.g., high risk), and associated logistics object identifiers (e.g., cargo batch, current location, and transport vehicle number). This information serves as the initialization parameters for generating subsequent emergency plans. These initialization parameters are input into the digital twin model of the logistics scenario. Based on the current logistics status (e.g., refrigerated truck location, nearby available maintenance points, alternative transport routes, and destination port clearance time), the model simulates at least two different emergency response paths. The digital twin model quantitatively evaluates the key performance indicators (KPIs) for each simulated path. Core KPIs include cargo loss rate, handling time, additional costs, and whether it affects customs clearance timeliness. Based on the KPI evaluation results, the plan with the lowest cargo loss rate and the least impact on overall logistics timeliness is selected as the recommended plan. An emergency response document containing plan details, implementation steps, and expected results is generated, along with specific information such as the transfer contact person, warehouse address, and backup vehicle number.

[0047] This embodiment uses smart contracts to monitor and calculate risk indices in real time, enabling precise quantitative assessment of conflicts / anomalies; it matches differentiated alarm strategies based on risk levels to ensure that relevant parties can obtain key information in a timely manner; and it combines digital twin models to generate optimal emergency plans, providing feasible guidance for risk management and improving the timeliness, accuracy, and operability of cross-border logistics risk management as a whole.

[0048] Furthermore, in some embodiments, step S32, "triggering different levels of alarm strategies through the smart contract alarm module according to the different levels of the risk index," may specifically include: Multiple risk level thresholds are preset, and risk indices are mapped to corresponding risk levels; Specifically, for step S321, considering the risk sensitivity, compliance requirements, and potential losses of different types of goods in cross-border logistics scenarios (such as fresh cold chain goods, precision electronic components, and general bulk commodities), the dimensions for classifying risk levels are clarified. For example, fresh cold chain goods are prone to damage due to excessive temperature, and risk level classification needs to focus more on the frequency of data conflicts and the extent to which indicators exceed limits; for general bulk commodities, the consistency of document information and route compliance are more important. Based on the classification criteria, specific risk index threshold values ​​are preset, and the risk index is divided into multiple levels, such as low risk, medium risk, and high risk, with each level corresponding to a clear numerical range to ensure the operability of the threshold classification. The calculated specific risk index is matched with the preset threshold range to determine the risk level to which the risk index belongs, forming a correspondence between risk index and risk level.

[0049] Based on the risk level, adaptively select the alarm channel and alarm content format, and execute the alarm action; Specifically, for step S322, alarm channels matching different risk levels are pre-defined. Channel selection must balance urgency and information delivery efficiency. Low-risk cases use lightweight channels to avoid information redundancy, while high-risk cases use a combination of multiple channels to ensure rapid information delivery. The level of detail in the alarm content is adjusted according to the risk level. Low-risk cases only include core conflict information (for quick browsing), while high-risk cases require additional information such as "conflict impact, current status, and preliminary handling suggestions" (for quick decision-making by relevant parties). The matching alarm channel is automatically invoked based on the risk level, alarm information is generated according to the set format, and simultaneously sent to predefined relevant party nodes (such as cargo owners, carriers, and maintenance teams) to ensure that alarm information is delivered without omission or delay. For example, for a high-risk alarm for imported strawberries, a pop-up window is simultaneously sent to the cargo owner's system, an SMS and voice call are sent to the carrier's dispatcher, and an email is sent to the maintenance team. All channels complete the information push within 1 minute.

[0050] This embodiment achieves accurate risk index classification by preset risk level thresholds, and then adaptively matches alarm channels and content formats according to the level. This avoids information overload in low-risk scenarios and ensures that information in high-risk scenarios reaches the public quickly and comprehensively, effectively improving the pertinence and response efficiency of cross-border logistics alarms.

[0051] Furthermore, in some embodiments, step S33, "based on alarm information, generating and recommending at least one emergency response plan," may specifically include: S331. Analyze the alarm information and extract the corresponding conflict event type, risk level, and associated logistics object identifier as initialization parameters for the digital twin model; Specifically, for step S331, the alarm information triggered in the cross-border logistics scenario is structurally decomposed, redundant expressions (such as formatted prompts) are filtered out, and the focus is on the core information dimensions directly related to emergency response, including the specific type of conflict event (clarifying the essence of the problem), risk level (defining the urgency), and unique identifier of the associated logistics object (identifying the target for handling). From the parsed alarm information, three types of initialization parameters are accurately extracted, including: the type of conflict event that clearly indicates the problem category causing the alarm; the risk level corresponding to the urgency of the alarm; and the identifier of the associated logistics object, including the unique batch number of the goods, current location, compliance standards, etc. The extracted initialization parameters are converted into a structured format (such as key-value pairs, tables) that the digital twin model can recognize, ensuring that the parameters can be directly used for model initialization and avoiding simulation errors due to format incompatibility.

[0052] S332. Based on the initialization parameters, drive the digital twin model of the logistics scenario, simulate at least two different emergency response paths, and deduce the consequences of each emergency response path; Specifically, for step S332, the standardized initialization parameters are input into the digital twin model of the logistics scenario. Based on these parameters, the model constructs a virtual scenario that matches the actual logistics status 1:1, including the current location of the transport vehicle (refrigerated truck), the refrigeration equipment malfunction status, available surrounding resources (such as nearby cold chain maintenance stations, spare refrigerated trucks, and temporary storage points), and the customs clearance schedule at the destination port. Based on the virtual scenario, at least two feasible emergency response paths are generated, and the path design must cover different handling logics such as fault repair and resource replacement. For example, for the case of Typhoon Mangkhut, the model simulates two paths: Route 1 (Fault Repair): "The refrigerated truck shall immediately proceed to the Yantian Cold Chain Repair Station, 3 kilometers away, to repair the refrigeration equipment (estimated time 1.5 hours). After repair, it shall continue to Yantian Port and clear customs as originally planned." Path 2 (Resource Replacement): "Use the backup refrigerated truck from the Shenzhen Cold Chain Temporary Warehouse (expected to arrive at the current location within 1 hour) to transfer the mangosteen to the backup vehicle (expected to take 0.5 hours), and then transport it to Yantian Port. The customs clearance time will be delayed until 14:00 the next day."

[0053] The entire process of each route is dynamically simulated, and the key status changes and final consequences during the handling process are output, including handling time, changes in cargo loss rate, impact on customs clearance timeliness, and additional costs.

[0054] For example: Path 1 consequence projection: "During the maintenance period, the temperature is maintained at 8-9℃. Within 1.5 hours, the cargo damage rate increases from 20% to 28%. The total handling time is 1.5 hours. There are no additional transfer costs. Customs clearance can be completed as originally planned at 09:00 the next day." Path 2 Consequences: "During the transfer, the temperature was controlled at 6-7℃ through temporary insulation measures. Within 1.5 hours, the damage rate increased from 20% to 23%. The total handling time was 2 hours, resulting in transfer and spare vehicle rental costs of 3,000 yuan and a customs clearance delay of 5 hours."

[0055] S333. Based on the simulated consequences, evaluate the key performance indicators of each emergency response path and obtain the evaluation results; Specifically, for step S333, the core indicators used to evaluate the merits of emergency routes must first be clearly defined, aligning with the core requirements of cross-border logistics, including cargo loss control, timeliness assurance, and cost control. Based on the consequences of route projection, the KPIs for each route are numerically calculated to generate comparable evaluation results. The quantified KPIs are then compiled into a structured evaluation report, clarifying the advantages and disadvantages of each route, providing data support for subsequent solution selection.

[0056] S334. Generate the optimal treatment path and corresponding multilingual treatment report based on the evaluation results; Specifically, for step S334, based on the priority requirements of the cross-border logistics scenario, the KPIs in the evaluation results are weighted and assigned, and the comprehensive score of each path is calculated. The path with the highest score is the optimal handling path. Based on the optimal path, a handling report is generated, including handling steps, responsible parties, time nodes, resource contact information, and risk warnings. This report is then translated into multiple languages ​​(such as Chinese, English, and Thai) required by cross-border logistics participants to ensure accurate understanding by participants from different countries / regions.

[0057] This embodiment initializes a digital twin model by parsing alarm parameters and simulating the consequences of multi-path handling. Finally, it quantifies and evaluates KPIs and generates multilingual reports. This can accurately select the optimal emergency solution that meets the needs of cross-border logistics, ensuring the scientific nature of emergency response and overcoming the barriers to multilingual communication in cross-border scenarios, thus effectively improving the feasibility and efficiency of risk management.

[0058] Furthermore, in some embodiments, the reliable traceability method for cross-border logistics may further include: S41. In response to a traceability request from an authorized node, determine the logistics event to be traced and the associated data range; Specifically, for step S41, traceability requests from cross-border logistics participants are received in real time. First, the requesting node is authenticated, such as through the blockchain node's digital certificate or a pre-defined authorized list. Only requests from authorized nodes (such as cargo owners, customs supervisors, trade arbitration institutions, and insurance companies) are responded to; access from unauthorized nodes is denied. The traceability requests submitted by authorized nodes are then structured and parsed to extract the specific logistics event information to be traced, including event type (such as cargo damage disputes, compliance checks, and claims evidence), associated cargo identifiers (such as unique batch numbers, bill of lading numbers, and container numbers), and key time nodes (such as transportation periods and the time of cargo damage). Based on the information of the logistics events to be traced, the data boundaries to be extracted are defined, specifying the data type (such as structured feature information, verification results, sensor data, and evidence records), time range (such as October 5th-10th, 2024), and process scope (such as sea transport, customs clearance, and land transport).

[0059] S42. Based on the data scope, obtain all evidence-based data related to the logistics event from the blockchain network and at least one associated blockchain; Specifically, for step S42, 2.1, the system pre-records the distributed storage rules for cross-border logistics data. Core data, such as structured feature information and verification results, are typically stored on the main blockchain network. Sub-segmented scenario data (real-time sensor data, image evidence) are stored on associated blockchains, such as the Hyperledger Fabric sub-chain focused on IoT data and the Quorum chain focused on trade documents. Based on the defined data range and storage location, the system initiates data retrieval requests to the main blockchain network and associated blockchains through preset cross-link interfaces (such as inter-blockchain communication protocols). The requests include search conditions such as batch number, time range, and data type, ensuring that only data directly related to the logistics event to be traced is retrieved, avoiding irrelevant data redundancy. After aggregating the evidence data obtained from each blockchain, the system verifies the data's completeness (no missing or tampered information) by comparing the data's digital fingerprint (such as hash value), timestamp continuity, and node signature information.

[0060] S43. Based on zero-knowledge proof technology, the stored evidence data is processed to extract verification data and generate a judicial-grade source tracing evidence report that includes data integrity proof without exposing sensitive details; Specifically, for step S43, zero-knowledge proof technology is used to perform verifiable extraction on the aggregated evidence data. Without exposing the complete original data to the report recipient (such as an arbitration institution), especially sensitive information such as cargo owner costs, trade pricing, and core technical parameters, only data fragments that can prove the key facts of the event to be traced are extracted, and a data integrity certificate is generated. For example, through hash value comparison logic, it is proven that the extracted data comes from the original evidence and that the original data has not been tampered with. Following the format requirements of judicial institutions (such as courts and arbitration commissions) for evidence materials, the structure of the traceability evidence report is constructed, including modules such as report number, requester information, overview of the event to be traced, data source description (name of the main blockchain and related chains), key factual data (with integrity certificate identifier), and conclusive opinions, ensuring the report has legal validity and admissibility. The key data processed by zero-knowledge proof, the integrity certificate, and the structured report content are integrated to generate a judicial-grade traceability evidence report in PDF format. The report can include a query link for the blockchain evidence, allowing the authorized party to verify the authenticity of the data.

[0061] This embodiment can accurately respond to the traceability requests of authorized nodes, obtain complete evidence data across chains, and generate traceability reports with integrity proof and judicial credibility by using zero-knowledge proofs while protecting sensitive data information. This not only meets the compliance requirements of cross-border logistics traceability, but also protects the commercial privacy of the participants.

[0062] In summary, compared with existing technologies, the trusted traceability method for cross-border logistics provided in this embodiment can achieve standardized and structured processing and trusted storage of multimodal data in cross-border logistics, and automatically trigger smart contract execution risk handling when data conflicts or violations of compliance rules occur, thereby ensuring the reliability and efficiency of cross-border logistics traceability.

[0063] To facilitate better implementation of the trusted traceability method for cross-border logistics according to the embodiments of this application, this application also provides a trusted traceability device for cross-border logistics based on the aforementioned trusted traceability method. The meanings of the terms used are the same as in the trusted traceability method for cross-border logistics described above, and specific implementation details can be found in the descriptions within the method embodiments.

[0064] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of a trusted traceability device for cross-border logistics provided in an embodiment of this application. Specifically, the trusted traceability device for cross-border logistics may include a data processing module 201, a comparison and verification module 202, and a risk handling module 203, as follows: Data processing module 201 is used to acquire multimodal logistics data in the cross-border logistics process and process the data to generate standardized structured feature information; The comparison and verification module 202 is used to compare and verify the structured feature information with the preset compliance rules, generate the comparison and verification results, and store the comparison and verification results and the corresponding structured feature information in the blockchain network. The risk handling module 203 is used to automatically trigger a smart contract deployed on the blockchain network to execute predefined risk handling actions when a data conflict or rule violation is detected based on the comparison and verification results.

[0065] Furthermore, in some embodiments, the data processing module 201 is specifically used for: By parsing text-based logistics documents from different data sources using a multimodal large language model, key entity information related to logistics elements can be extracted from unstructured text. Based on the federated learning framework, key entity information is spatiotemporally aligned with sensor data from IoT sensors to construct spatiotemporally correlated data that characterizes changes in the state of logistics objects. Based on key entity information and spatiotemporal correlation data, a consistency check is performed through a multimodal cross-validation engine to generate a unified feature vector as structured feature information.

[0066] Furthermore, in some embodiments, the data processing module 201 is specifically used for: Synchronize key entity information and sensor data with timestamps and map them to geographic locations to generate initial alignment data; By using a collaborative training algorithm within a federated learning framework, feature fusion is performed on the initial aligned data to eliminate biases between various data sources and generate corresponding spatiotemporal correlated data.

[0067] Furthermore, in some embodiments, the comparison and verification module 202 is specifically used for: Customs regulations are dynamically parsed in natural language form using a large language model, and converted into executable, machine-readable verification rules through dynamic rule mapping technology, which serve as preset compliance rules. The structured feature information and machine-readable verification rules are matched and verified to generate verification results, which include pass, conflict, or anomaly. The structured feature information, verification results, and their digital fingerprints are packaged together into a block and persistently stored in the blockchain network.

[0068] Furthermore, in some embodiments, the comparison and verification module 202 is specifically used for: Using a large language model, semantic parsing and logical structure analysis are performed on customs regulations in natural language form to generate an intermediate representation logic tree; The intermediate representation logic tree is compiled into script code that can be executed in the verification engine, forming machine-readable verification rules.

[0069] Furthermore, in some embodiments, the risk management module 203 is specifically used for: By monitoring verification results through smart contracts, when verification results indicating conflicts or anomalies are detected, the risk calculation model is automatically invoked to calculate a risk index based on the type, frequency, and severity of the conflicting data. Based on the different levels of the risk index, different levels of alarm strategies are triggered through the smart contract alarm module, and alarm information is sent to at least one predefined relevant party node; Based on the alarm information, generate and recommend at least one emergency response plan.

[0070] Furthermore, in some embodiments, the risk management module 203 is also specifically used for: Multiple risk level thresholds are preset, and risk indices are mapped to corresponding risk levels; Based on the risk level, the alarm channel and alarm content format are adaptively selected, and alarm actions are executed.

[0071] Furthermore, in some embodiments, the risk management module 203 is also specifically used for: The alarm information is analyzed to extract the corresponding conflict event type, risk level, and associated logistics object identifier, which are used as initialization parameters for the digital twin model. Based on the initialization parameters, drive the digital twin model of the logistics scenario to simulate at least two different emergency response paths and deduce the consequences of each emergency response path. Based on the simulated consequences, the key performance indicators of each emergency response path are evaluated to obtain the evaluation results. The optimal treatment path and corresponding multilingual treatment report are generated based on the evaluation results.

[0072] Furthermore, in some embodiments, the apparatus further includes a report generation module 204, specifically used for... In response to a traceability request from an authorized node, determine the logistics event to be traced and the associated data range; Based on the data scope, retrieve all evidence-based data related to the logistics event from the blockchain network and at least one associated blockchain; Based on zero-knowledge proof technology, the stored evidence data is processed for verification data extraction, generating a judicial-grade source tracing evidence report that includes data integrity proof without exposing sensitive details.

[0073] For specific limitations regarding trusted traceability devices used in cross-border logistics, please refer to the limitations on trusted traceability methods used in cross-border logistics mentioned above, which will not be repeated here. Each module in the aforementioned trusted traceability device for cross-border logistics can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0074] The trusted traceability device for cross-border logistics provided in this embodiment can realize standardized and structured processing and trusted storage of multimodal data in cross-border logistics, and automatically trigger smart contract execution risk disposal when data conflicts or violations of compliance rules occur, thereby ensuring the reliability and efficiency of cross-border logistics traceability.

[0075] Furthermore, embodiments of this application also provide an electronic device, such as... Figure 4 As shown, it illustrates a structural schematic diagram of the electronic device involved in the embodiments of this application, specifically: The electronic device may include components such as a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, a power supply 303, and an input unit 304. Those skilled in the art will understand that... Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 301 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines, and performs various functions and processes data by running or executing software programs and / or modules stored in the memory 302, and by calling data stored in the memory 302, thereby providing overall monitoring of the electronic device. Optionally, the processor 301 may include one or more processing cores; preferably, the processor 301 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 301.

[0076] The memory 302 can be used to store software programs and modules. The processor 301 executes various functional applications and reliable traceability methods for cross-border logistics by running the software programs and modules stored in the memory 302. The memory 302 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created based on the use of the electronic device, etc. In addition, the memory 302 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 302 may also include a memory controller to provide the processor 301 with access to the memory 302.

[0077] The electronic device also includes a power supply 303 that supplies power to various components. Preferably, the power supply 303 can be logically connected to the processor 301 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 303 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0078] The electronic device may also include an input unit 304, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0079] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 301 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 302 according to the following instructions, and the processor 301 runs the applications stored in the memory 302 to realize various functions, as follows: The system acquires and processes multimodal logistics data from cross-border logistics processes to generate standardized structured feature information. It then compares and verifies the structured feature information with preset compliance rules to generate comparison and verification results. The comparison and verification results and the corresponding structured feature information are stored in the blockchain network. When data conflicts or rule violations are detected based on the comparison and verification results, the system automatically triggers smart contracts deployed on the blockchain network to execute predefined risk management actions.

[0080] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0081] The embodiments of this application can realize standardized and structured processing and reliable storage of multimodal data in cross-border logistics, and automatically trigger smart contract execution risk disposal when data conflicts or violations of compliance rules occur, thereby ensuring the reliability and efficiency of cross-border logistics traceability.

[0082] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0083] To this end, embodiments of this application provide a storage medium storing multiple instructions that can be loaded by a processor to execute steps in any of the trusted traceability methods for cross-border logistics provided in embodiments of this application. For example, the instructions can execute the following steps: The system acquires and processes multimodal logistics data from cross-border logistics processes to generate standardized structured feature information. It then compares and verifies the structured feature information with preset compliance rules to generate comparison and verification results. The comparison and verification results and the corresponding structured feature information are stored in the blockchain network. When data conflicts or rule violations are detected based on the comparison and verification results, the system automatically triggers smart contracts deployed on the blockchain network to execute predefined risk management actions.

[0084] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0085] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0086] Since the instructions stored in the storage medium can execute the steps in any of the trusted traceability methods for cross-border logistics provided in the embodiments of this application, the beneficial effects that any of the trusted traceability methods for cross-border logistics provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0087] The foregoing has provided a detailed description of a reliable traceability method, apparatus, device, and medium for cross-border logistics provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A trusted provenance method for cross-border logistics, characterized in that, The method comprises: acquiring multi-modal logistics data in a cross-border logistics process and performing data processing to generate standardized structured feature information; comparing and verifying the structured feature information with preset compliance rules to generate comparison and verification results, and storing the comparison and verification results and corresponding structured feature information to a blockchain network; when detecting data conflicts or rule violations based on the comparison and verification results, automatically triggering a smart contract deployed on the blockchain network to perform predefined risk handling actions.

2. The method for trusted provenance for cross-border logistics of claim 1, wherein, The method of acquiring multi-modal logistics data in a cross-border logistics process and performing data processing to generate standardized structured feature information comprises: analyzing text logistics documents from different data sources through a multi-modal large language model to extract key entity information related to logistics elements from unstructured text; based on a federated learning framework, performing spatio-temporal alignment processing on the key entity information and sensor data from Internet of Things sensors to construct spatio-temporal correlation data for representing state changes of logistics objects; based on the key entity information and the spatio-temporal correlation data, performing consistency checking through a multi-modal cross-validation engine to generate a unified feature vector as the structured feature information. 3.The trusted provenance method for cross-border logistics of claim 2, wherein, The method of performing spatio-temporal alignment processing on the key entity information and sensor data from Internet of Things sensors based on a federated learning framework to construct spatio-temporal correlation data for representing state changes of logistics objects comprises: synchronizing timestamps and mapping geographical locations of the key entity information and the sensor data to generate initial alignment data; performing feature fusion on the initial alignment data through a collaborative training algorithm under the federated learning framework to eliminate biases between different data sources and generate corresponding spatio-temporal correlation data. 4.The trusted provenance method for cross-border logistics of claim 1, wherein, The method of comparing and verifying the structured feature information with preset compliance rules to generate comparison and verification results, and storing the comparison and verification results and corresponding structured feature information to a blockchain network comprises: dynamically analyzing customs regulations clauses in natural language form based on a large language model, and converting the customs regulations clauses into executable machine-readable verification rules through rule dynamic mapping technology to serve as the preset compliance rules; performing matching and checking on the structured feature information and the machine-readable verification rules to generate the verification results, which include pass, conflict, or exception; packaging the structured feature information, the verification results, and their digital fingerprints together into a block and persistently storing the block to the blockchain network.

5. The method for trusted provenance for cross-border logistics of claim 4, wherein, The method of converting the customs regulations clauses in natural language form into executable machine-readable verification rules through rule dynamic mapping technology comprises: using a large language model to perform semantic analysis and logical structure analysis on the customs regulations clauses in natural language form to generate an intermediate representation logical tree; compiling the intermediate representation logical tree into script code executable in a verification engine to form the machine-readable verification rules. 6.The trusted provenance method for cross-border logistics of claim 5, wherein, The method of automatically triggering a smart contract deployed on the blockchain network to perform predefined risk handling actions when detecting data conflicts or rule violations based on the comparison and verification results comprises: The smart contract listens to the verification result, and when a verification result representing a conflict or anomaly is detected, a risk calculation model is automatically called to calculate a risk index based on the type, frequency and severity of the conflict data; According to the different levels of the risk index, different levels of alarm strategies are triggered through the smart contract alarm module, and alarm information is sent to at least one related party node; Based on the alarm information, at least one emergency treatment scheme is generated and recommended. 7.The trusted provenance method for cross-border logistics of claim 6, wherein, According to the different levels of the risk index, different levels of alarm strategies are triggered through the smart contract alarm module, including: A plurality of risk level thresholds are preset, and the risk index is mapped to the corresponding risk level; According to the risk level, the alarm channel and alarm content format are adaptively selected, and the alarm action is executed. 8.The trusted provenance method for cross-border logistics of claim 6, wherein, Based on the alarm information, at least one emergency treatment scheme is generated and recommended, including: The alarm information is parsed to extract the corresponding conflict event type, risk level and associated logistics object identifier as initialization parameters for a digital twin model; According to the initialization parameters, the digital twin model of the logistics scene is driven to simulate at least two different emergency disposal paths and deduce the disposal consequences under each emergency disposal path; According to the deduced disposal consequences, the key performance indicators of each emergency disposal path are evaluated to obtain an evaluation result; Based on the evaluation result, the optimal disposal path and the corresponding multilingual disposal report are generated. 9.The trusted provenance method for cross-border logistics of claim 1, wherein, The method further includes: In response to a traceability request from an authorized node, determine the logistics event to be traced and the associated data range; According to the data range, all evidence data related to the logistics event is obtained from the blockchain network and at least one associated blockchain; Based on zero-knowledge proof technology, the evidence data is verified and data extraction processed to generate a judicial-level traceability evidence report including data integrity proof without exposing sensitive details.

10. A trusted provenance device for cross-border logistics, characterized in that, It includes: A data processing module for acquiring and processing multi-modal logistics data in cross-border logistics processes to generate standardized structured feature information; A comparison and verification module for comparing and verifying the structured feature information with pre-defined compliance rules to generate comparison and verification results, and storing the comparison and verification results and corresponding structured feature information to a blockchain network; A risk disposal module for automatically triggering a smart contract deployed on the blockchain network to perform predefined risk disposal actions when data conflicts or rule violations are detected based on the comparison and verification results.

Images