A blockchain-based aircraft data storage method and system

Abstract

The blockchain-based aircraft data notarization method and system provided by the present invention defines node types and edge types based on multiple aircraft, mission instructions, decision events, data summaries, collaborative actions, and preset relationships between each other that collaborate to perform a mission, constructs a collaborative mission event graph on the main blockchain, constructs a local collaborative processing network based on the collaborative information between multiple aircraft, and creates specific node associations in the anchor node association graph through the local collaborative processing network when preset conditions are met. Through smart contracts, the creation and update of all nodes and edges in the graph are managed. Compared to the existing technology, the present invention solves the challenges of data notarization in complex emergency collaboration scenarios through a dynamic collaborative mission event graph and a hierarchical consensus anchoring mechanism, achieving structured, reliable, and efficient recording of information throughout the mission life cycle to improve data credibility and auditability.

Description

Technical Field

[0001] The present invention relates to the fields of blockchain and aircraft technology, and in particular to a blockchain-based aircraft data notarization method and system. Background Art

[0002] When multiple heterogeneous aircraft collaborate to perform dynamically reconfigured missions, such as transitioning from routine inspections to emergency response, existing blockchain-based aircraft data archiving methods, while ensuring the basic credibility of data collected independently by each aircraft, face challenges in efficiently and reliably recording and managing the dynamic mission reconfiguration process itself, including discovery and warning, decision-making instructions, data handover, mission parameter adjustments, and collaborative strategy updates. Furthermore, they face challenges in clearly defining and tracing the contributions of each aircraft, which may belong to different stakeholders, to the final data output. Furthermore, they face challenges in accurately restoring the timing and logic of collaborative operations despite communication asynchrony and data dependencies. Furthermore, they face challenges in cost-effectively archiving high-frequency, minute collaborative state information between aircraft without sacrificing the integrity of key nodes. Furthermore, they face challenges in establishing a complete, auditable data lineage and equity distribution mechanism, extending from the top-level mission objectives to the underlying raw data of each participating aircraft. These challenges make it difficult to obtain a comprehensive, coherent, and mutually recognized chain of evidence during post-audits of complex collaborative missions, multi-party contribution assessments, data equity distribution, and emergency response process review.

[0003] Therefore, providing a blockchain-based aircraft data storage method and system to solve the above problems is an urgent problem to be solved by those skilled in the art. Summary of the Invention

[0004] The purpose of the present invention is to provide a blockchain-based aircraft data notarization method, which has clear logic, is safe, effective, reliable and easy to operate. By constructing a structured and traceable blockchain-based aircraft data notarization system, the credibility and auditability of the data are improved.

[0005] Based on the above objectives, the technical solutions provided by the present invention are as follows:

[0006] A blockchain-based aircraft data notarization method, applied to emergency scenarios involving collaborative aircraft mission execution and deployment, includes the following steps:

[0007] Define node and edge types based on the multiple aircraft, mission instructions, decision events, data summaries, collaborative actions, and pre-set relationships between them to build a collaborative mission event graph on the main blockchain.

[0008] A local collaborative processing network is constructed based on collaborative information between multiple aircraft that collaboratively perform a mission. When a preset condition is met, the local collaborative processing network creates an anchor node in the collaborative mission event graph based on the collaborative information, and associates the anchor node with a specific node in the collaborative mission event graph.

[0009] According to the smart contract deployed on the main blockchain, manage the creation and update of all nodes and edges in the collaborative task event graph.

[0010] Preferably, the process of defining node types and edge types based on multiple aircraft, mission instructions, decision events, data summaries, collaborative actions, and preset relationships among the collaborative missions to construct a collaborative mission event graph on the main blockchain includes the following steps:

[0011] Based on the multiple aircraft, mission instructions, decision events, data summaries and collaborative actions that collaborate to perform a mission and the preset relationships between them, the node types are defined to include: aircraft node, mission instruction node, decision event node, data summary node and collaborative action node; the edge types are defined to include: trigger edge, execution edge, generation edge, dependency edge and belonging to edge;

[0012] On the main blockchain, the aircraft node, the mission instruction node, the decision event node, the data summary node, the coordinated action node, and the trigger edge, the execution edge, the generation edge, the dependency edge, and the belonging edge are respectively created according to the smart contract;

[0013] Connect the decision event node to the task instruction node, or connect the task instruction node to the collaborative action node, connect the execution edge to the aircraft node to the collaborative action node, connect the generation edge to the collaborative action node to the data summary node, connect the depend edge between two data summary nodes, or connect two collaborative action nodes, and connect the data summary node or the collaborative action node to the aircraft node with the belong edge to construct the collaborative task event graph.

[0014] Preferably, the local collaborative processing network is constructed based on the collaborative information between multiple aircraft that collaboratively perform a mission. When a preset condition is met, the local collaborative processing network creates an anchor node in the collaborative mission event graph based on the collaborative information, and associates the anchor node with a specific node in the collaborative mission event graph, including the following steps:

[0015] Acquiring the collaborative information according to the communication between the multiple aircrafts in the collaborative flight mission, and constructing the local collaborative processing network to record the collaborative information;

[0016] When the local collaborative processing network meets the preset conditions, a collaborative event log and summary information are generated according to the collaborative information and encapsulated into a collaborative anchor transaction;

[0017] Verifying the collaborative anchoring transaction according to the smart contract, and upon passing the verification, creating an anchor node in the collaborative task event graph;

[0018] An association edge is defined and created, and the association edge connects the anchor node to the aircraft node or the association edge connects the anchor node to the parent collaborative action node.

[0019] Preferably, the node types further include: contribution mark nodes;

[0020] On the main blockchain, after creating the aircraft node, the mission instruction node, the decision event node, the data summary node, the coordinated action node, and the trigger edge, the execution edge, the generation edge, the dependency edge, and the belonging edge according to the smart contract, the following steps are also included:

[0021] Creating the contribution mark node according to the smart contract;

[0022] According to the trigger edge, the execution edge, the generation edge and the contribution weight rule, a contribution evaluation message is recorded in the contribution marking node.

[0023] Preferably, the node types further include: deviation event nodes;

[0024] On the main blockchain, after creating the aircraft node, the mission instruction node, the decision event node, the data summary node, the coordinated action node, and the trigger edge, the execution edge, the generation edge, the dependency edge, and the belonging edge according to the smart contract, the following steps are also included:

[0025] Obtaining actual state parameters of the aircraft in the collaborative flight mission;

[0026] Determining whether a difference between the actual state parameter and the theoretical state parameter defined by the task instruction node or the collaborative action node exceeds a preset threshold;

[0027] If so, create the deviation event node according to the smart contract.

[0028] Preferably, the edge types further include: edges originating from plans, response action edges, and impact data record edges;

[0029] After creating the deviation event node according to the smart contract, the following steps are also included:

[0030] Creating the originating plan edge, the response action edge, and the impact data record edge according to the smart contract;

[0031] Connecting the planned edge to the coordinated action node of the original plan to the deviation event node;

[0032] When a deviation event results in the creation of a new collaborative action node, the response action edge connects the deviation event node to the new collaborative action node;

[0033] When a deviation event results in the creation of a new data summary node, the impact data record edge is connected to the deviation event node to the new data summary node.

[0034] Preferably, the node types further include: data quality nodes and evaluation subject nodes;

[0035] On the main blockchain, after creating the aircraft node, the mission instruction node, the decision event node, the data summary node, the coordinated action node, and the trigger edge, the execution edge, the generation edge, the dependency edge, and the belonging edge according to the smart contract, the following steps are also included:

[0036] When the collected data of any aircraft undergoes quality assessment by the assessment subject, the data quality node and the assessment subject node are created according to the smart contract.

[0037] Preferably, the edge types further include: declared quality edges and evaluation subject edges;

[0038] After the collected data of any aircraft has been evaluated by the evaluation subject, and the data quality node and the evaluation subject node are created according to the smart contract, the following steps are also included:

[0039] Creating the declared quality edge and the assessment subject edge according to the smart contract;

[0040] The statement quality edge connects the data quality node to the data summary node, and the assessment subject edge connects the data quality node to the assessment subject node.

[0041] Preferably, obtaining the contribution weight rule includes the following steps:

[0042] Classifying the collected data into different quality levels according to the data quality nodes;

[0043] Assigning different contribution weights to the collected data of different quality levels according to preset rules;

[0044] Contribution scores of the collected data of different quality levels are calculated.

[0045] A blockchain-based aircraft data notarization system, comprising:

[0046] A graph construction module is used to define node types and edge types based on multiple aircraft, mission instructions, decision events, data summaries, collaborative actions, and preset relationships between them to build a collaborative mission event graph on the main blockchain;

[0047] An anchor association module, configured to construct a local collaborative processing network based on collaborative information between multiple aircraft performing a collaborative mission. When a preset condition is met, the local collaborative processing network creates an anchor node in the collaborative mission event graph based on the collaborative information, and associates the collaborative information node with a specific node in the collaborative mission event graph.

[0048] A smart contract management module is used to manage the creation and update of all nodes and edges in the collaborative task event graph according to the smart contract deployed on the main blockchain.

[0049] The blockchain-based aircraft data notarization method provided by the present invention defines node types and edge types based on multiple aircraft, task instructions, decision events, data summaries, collaborative actions, and preset relationships between each other that collaborate to perform tasks, constructs a collaborative task event graph on the main blockchain, constructs a local collaborative processing network based on the collaborative information between multiple aircraft, and creates specific node associations in the anchor node association graph through the local collaborative processing network when preset conditions are met. Through smart contracts, the creation and update of all nodes and edges in the graph are managed.

[0050] Compared with the existing technology, the present invention solves the challenge of data storage in complex emergency collaboration scenarios through a dynamic collaborative task event graph and a hierarchical consensus anchoring mechanism, and realizes structured, reliable and efficient recording of information throughout the entire life cycle of the task, thereby improving data credibility and auditability.

[0051] The present invention also provides an aircraft data notarization system based on blockchain. Since it has the same technical concept as this method and solves the same technical problem, it should have the same beneficial effects and will not be described in detail here. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0053] Figure 1 A flowchart of a blockchain-based aircraft data storage method provided in an embodiment of the present invention;

[0054] Figure 2 A flowchart of step S1 provided in an embodiment of the present invention;

[0055] Figure 3 A flowchart of step S2 provided in an embodiment of the present invention;

[0056] Figure 4 A flowchart of a first implementation method after step A2 provided in an embodiment of the present invention;

[0057] Figure 5 A flowchart of a second implementation method after step A2 provided in an embodiment of the present invention;

[0058] Figure 6 A flowchart of a third implementation method after step A2 provided in an embodiment of the present invention;

[0059] Figure 7 A flowchart of the contribution weight rule in obtaining step C2 provided in an embodiment of the present invention;

[0060] Figure 8 A schematic structural diagram of a blockchain-based aircraft data notarization system provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0061] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0062] The embodiments of the present invention are written in a progressive manner.

[0063] The present invention provides a blockchain-based aircraft data archiving method and system. This method addresses the existing technical challenges of obtaining a comprehensive, coherent, and mutually accepted chain of evidence during post-audits of complex collaborative tasks, multi-party contribution assessments, data equity allocation, and emergency response process review.

[0064] like Figure 1 As shown, a blockchain-based aircraft data notarization method is applied to emergency scenarios where aircraft collaborate on mission execution and deployment, including the following steps:

[0065] S1. Define node and edge types based on the multiple aircraft, mission instructions, decision events, data summaries, collaborative actions, and pre-set relationships involved in the collaborative mission, to build a collaborative mission event graph on the main blockchain.

[0066] S2. Construct a local collaborative processing network based on the collaborative information between multiple aircraft performing collaborative tasks. When the local collaborative processing network meets the preset conditions, it creates an anchor node in the collaborative task event graph based on the collaborative information and associates the anchor node with a specific node in the collaborative task event graph;

[0067] S3. Manage the creation and update of all nodes and edges in the collaborative task event graph based on the smart contract deployed on the main blockchain.

[0068] In step S1, the key entities and events in the mission and their complex causal, temporal, and attribution relationships are captured by defining node types (such as aircraft nodes, mission instruction nodes, decision event nodes, data summary nodes, and collaborative action nodes) and edge types among multiple aircraft, mission instructions, decision events, data summaries, collaborative actions, and preset relationships among them.

[0069] In step S2, for high-frequency, low-value, but crucial collaborative information within the aircraft cluster (e.g., sensor parameter fine-tuning and avoidance path negotiation), this information is rapidly exchanged and recorded between aircraft via a local collaborative processing network built with dedicated communication links. When preset conditions are met, this local collaborative processing network creates an anchor node in the collaborative task event graph and associates the anchor node with a specific node in the graph.

[0070] In step S3, the smart contracts deployed on the main chain are the hub of this solution. The graph management contract is responsible for defining the graph's schema, providing interfaces for creating and updating graph elements, and managing access rights. The anchor processing contract is responsible for receiving and verifying anchor transactions from the local network and integrating them into the main graph.

[0071] By constructing a dynamic collaborative task event graph and combining it with a hierarchical consensus anchoring mechanism, this technical solution can achieve the following significant technical effects in emergency response task scenarios where multiple heterogeneous aircraft are performing dynamic reorganization: Achieve complete traceability of the decision-making chain for dynamic task reorganization: Through dedicated decision event nodes, task instruction nodes (including task reorganization types) and the triggering relationships between them, the complete decision-making chain from early warning discovery to the issuance and adjustment of new tasks is clearly and tamper-proof recorded, providing a solid decision-making basis for post-audit; Accurately express the complex collaboration and strong data correlation between heterogeneous multiple aircraft: The nodes and edges of the event graph can flexibly and accurately depict the actions performed by different aircraft in different time and space, the data generated, and the complex temporal and logical dependencies between them (such as analytical dependencies between data, and the order or conditional relationships between behaviors), thereby accurately restoring the full picture of collaborative operations; Provide a data basis for contribution definition and trusted incentives under the participation of multiple stakeholders: Aircraft nodes can record information about the affiliated institutions, and data and actions are clearly attributed to specific aircraft through the graph. Combined with optional contribution marking nodes and smart contract rules, it can provide a transparent and verifiable quantitative basis for the contribution evaluation of different stakeholders based on the discovery, execution, data generation and other behaviors recorded in the graph; efficiently realize the layered evidence of high-frequency micro-collaboration and key events: process high-frequency micro-collaboration information through a local collaborative processing network, and anchor its summary to the main chain event graph, which not only avoids the problems of main chain congestion and high cost, but also retains the traceability and integrity proof of these micro-collaboration processes, and realizes the layered, differentiated and efficient recording of key and auxiliary information; build a comprehensive, coherent and auditable end-to-end trusted data genealogy: based on the event graph, it can trace back from the final results to all relevant original data collection records, task instructions and decision-making processes step by step, and combine the secure and verifiable association between on-chain summaries and off-chain original data to form a complete trusted data genealogy covering the entire life cycle of the task, greatly improving the efficiency, accuracy and credibility of emergency response task audits, multi-party contribution assessments, data rights and interests division and process review.

[0072] like Figure 2 As shown, preferably, step S1 includes the following steps:

[0073] A1. Based on the multiple aircraft, mission instructions, decision events, data summaries, and coordinated actions involved in the collaborative mission, as well as their pre-defined relationships, we define node types including aircraft nodes, mission instruction nodes, decision event nodes, data summary nodes, and coordinated action nodes. We also define edge types including triggering edges, executing edges, generating edges, depending on edges, and belonging to edges.

[0074] A2. On the main blockchain, create a vehicle node, a mission instruction node, a decision event node, a data summary node, a coordinated action node, and trigger, execute, generate, depend on, and belong to edges based on the smart contract.

[0075] A3. Connect the trigger edge from the decision event node to the task instruction node, or connect the task instruction node to the collaborative action node; connect the execution edge from the aircraft node to the collaborative action node; connect the generate edge from the collaborative action node to the data summary node; connect the depend edge between two data summary nodes, or between two collaborative action nodes; and connect the data summary node or collaborative action node to the aircraft node with the belong edge to construct a collaborative task event graph.

[0076] In step A1, the aircraft node (AircraftNode): records the aircraft's unique identifier (such as DID), type, and affiliated organization.

[0077] InstructionNode: This node records the instruction ID, issuer, recipient, instruction content (e.g., new route, sensor parameters, coordination strategy), and timestamp. In particular, it includes the "Mission Reorganization Instruction" subtype.

[0078] Decision event node (DecisionNode): records key decision points, such as "emergency mission launch" and "collaborative target confirmation", including the decision basis (such as the early warning data summary pointing to aircraft A), the decision-making parties involved, and the decision results.

[0079] Data Digest Node: records data hash, metadata (type, collection time, sensor parameters, aircraft status), off-chain storage pointer, and aircraft node ID.

[0080] ActionNode: records key aircraft behaviors, such as "command reception confirmation", "arrival at designated area", "data sharing initiation / reception", and "sensor adjustment completion". It contains the executing aircraft ID, associated command ID, timestamp, and status parameters.

[0081] In step A3, the trigger edge connects the decision event node to the task instruction node, or the task instruction node to the collaborative action node.

[0082] Executes edge: connects the aircraft node to the collaborative action node. Generates edge: connects the collaborative action node (such as data collection action) to the data summary node.

[0083] DependsOn edge: connects one data summary node to another data summary node (indicating data analysis dependency), or one collaborative action to another collaborative action (indicating a sequential or conditional relationship between actions).

[0084] BelongsTo edge: connects the data summary node or collaborative action node to the aircraft node, indicating ownership.

[0085] In this embodiment, it is assumed that in a geological disaster emergency response mission, aircraft A (discoverer), aircraft B (video monitoring), aircraft C (3D modeling), and aircraft D (lidar scanning) participate in the collaboration.

[0086] Aircraft A generates preliminary data about the potential danger point. This summary is encapsulated in a Data Summary node (DA_A_Warning) and linked to the Aircraft Node (FN_A) via a BelongsTo edge. After receiving the warning, the ground control center makes an emergency response decision, generating a Decision Event node (DE_Initiate Emergency). This node is linked to a Task Instruction node (IN_Restructuring_B, C, and D) of the "Task Reorganization" type via a Triggers edge. This instruction node details the new task assignments for B, C, and D (e.g., B is responsible for video, C for 3D modeling, and D for LiDAR), and is linked to FN_B, FN_C, and FN_D, respectively, via RelatesTo edges. Aircraft B receives and confirms the new instruction, generating a Collaborative Action node (AN_Confirm_B), linked to FN_B via an Executes edge, and reversely linked to IN_Restructuring_B, C, and D via a Triggers edge (representing the response instruction). Aircraft C and D perform similar operations. Aircraft B conducts video surveillance of the target area, periodically uploading its video stream summary and keyframe metadata as new Data Summary Nodes (DA_B_VideoFrame1, DA_B_VideoFrame2, ...). Each Data Summary Node is linked to a Collaborative Action Node (AN_AcquireVideo_B) via a Generates edge. This Action Node in turn BelongsTo FN_B and may DependsOn IN_Recombined_B, C, and D. If Aircraft D's LiDAR scan focuses on a specific crack region observed in Aircraft B's video, the Data Summary Node (DA_D_PointCloud) generated by D will explicitly point to the associated DA_B_VideoFrameX via a DependsOn edge.

[0087] In this way, the event graph clearly records the entire process, from early warning discovery to task reorganization decision-making, to the issuance, confirmation, execution, and data collection of specific instructions. It also clearly expresses the logical dependencies between data (such as D's reliance on B's data). Post-audits can trace the cause and effect from any node.

[0088] like Figure 3 As shown, preferably, step S2 includes the following steps:

[0089] B1. Multiple aircraft in a collaborative flight mission communicate with each other, acquire collaborative information, and build a local collaborative processing network to record the collaborative information;

[0090] B2. When the local collaborative processing network meets the preset conditions, a collaborative event log and summary information are generated based on the collaborative information and encapsulated into a collaborative anchor transaction;

[0091] B3. Verify the collaborative anchor transaction based on the smart contract. Once verified, create an anchor node in the collaborative task event graph.

[0092] B4. Define and create an association edge, connecting the anchor node to the aircraft node or connecting the anchor node to the parent collaborative action node.

[0093] In step B1, high-frequency, small collaborative messages within the aircraft cluster (for example, aircraft A sends a message to aircraft B, "We are approaching to your left, please maintain current altitude," and aircraft B replies, "Received, maintain altitude") are exchanged and recorded in a temporary network composed of dedicated communication links between aircraft. This network can use lightweight consensus, such as simple leader-based confirmation or multi-signature. The record includes the two parties interacting, a timestamp, and a summary of the message content.

[0094] In step B2, after meeting preset conditions such as a certain time window, a certain number of micro-collaborative events, or completing a key collaborative phase (e.g., a group of aircraft completing a collaborative scan of a specific sub-area), the local collaborative processing network will encapsulate the Merkle tree root of all micro-collaborative event logs within that time period, along with summary information about the batch of collaborations (e.g., participating aircraft, start and end times, and primary collaboration types), into a "collaborative anchor transaction."

[0095] In step B3, the anchor transaction is submitted to the main chain's graph management smart contract. After verifying the signature and format of the anchor transaction, the contract creates a special anchor node (MicroCoordinationAnchorNode) in the event graph, recording the Merkle tree root and summary information;

[0096] In step B4, define and create an associated edge in the time graph, and connect the associated edge to the aircraft node from the anchor node, or connect the associated edge to the parent collaborative action node from the anchor node. In this way, the main chain graph does not store all the minute details, but retains a verifiable index for these details.

[0097] The edge types in the graph also include: associated (RelatesTo) edge: a general association relationship, such as connecting a task reorganization instruction to the original task.

[0098] In this embodiment, the above-mentioned minute collaborative information between aircraft B and aircraft D (such as B sending "crack expansion direction vector {X, Y, Z}, confidence 0.85", and D replying "Received, the scanning path has been adjusted to this direction") is recorded in the local collaborative processing network constructed between them through a dedicated communication link. The network adopts lightweight consensus (such as signature confirmation by both parties), and the recorded content includes the interaction timestamp, sender, receiver, information content summary, etc. For example, the record is: Record 1: {Time: T1, From: FN_B, To: FN_D, Type: ScanAssist, ContentDigest:Hash("direction vector {X, Y, Z}, confidence 0.85")}; Record 2: {Time: T2, From: FN_D, To: FN_B,Type: AckScanAdjust, ContentDigest: Hash("confirm adjustment")}; After aircraft B and D complete the collaborative scanning of this specific crack area, or reach a preset time window (such as every 5 minutes), the local collaborative processing network will calculate the Merkle root (MTR_BD_collaboration1) of this batch of micro-collaborative event logs (Record 1, Record 2,...). A "collaborative anchor transaction" is submitted to the graph management smart contract of the main chain. The transaction contains MTR_BD_collaboration1 and a summary of this batch of collaborations (such as participants: FN_B, FN_D; collaboration time period: T1 - Tn; collaboration purpose: crack detail scanning). After the smart contract verifies the anchor transaction, an `anchor node` (MCAN_BD_collaboration1) is created in the event graph of the main chain. This node records MTR_BD_collaboration1 and the summary information, and is connected to the `aircraft nodes` FN_B and FN_D, as well as their current relevant parent `collaborative action nodes` (such as AN_collaborative scan crack) through an `associated (RelatesTo)` edge.

[0099] Through this hierarchical anchoring mechanism, the main chain event graph does not store all the details of micro-collaborations, thus reducing the burden on the main chain. However, through the Merkle tree root in the anchor node, the overall verifiability and non-repudiation of the micro-collaborative behaviors recorded in these local networks are preserved. When necessary, verification can be combined with the detailed micro-collaboration log stored off-chain and the Merkle tree root anchored on-chain to ensure the complete traceability of the collaborative process.

[0100] like Figure 4 As shown, preferably, the node type also includes: contribution mark nodes;

[0101] After step A2, the method further includes the following steps:

[0102] C1. Create a contribution token node based on the smart contract;

[0103] C2. Record the contribution evaluation message in the contribution marking node according to the trigger edge, execution edge, generation edge and contribution weight rules.

[0104] In steps C1 to C2, a contribution marking node is created in the graph based on the contribution evaluation auxiliary contract in the smart contract. The contribution marking node is used to preliminarily mark the contribution type of specific data or behavior (such as "primary discovery" or "key evidence provision") and can be generated by the smart contract according to preset rules or multi-party confirmation; based on the "trigger", "execution" and "generation" relationships recorded in the graph (i.e., trigger edge, execution edge and generation edge), as well as the contribution weight rules or multi-party voting results, the preliminary contribution evaluation information is automatically or semi-automatically recorded in the contribution marking node.

[0105] like Figure 5 As shown, preferably, the node type further includes: a deviation event node;

[0106] After step A2, the method further includes the following steps:

[0107] D1. Obtain the actual status parameters of the aircraft in the collaborative flight mission;

[0108] D2. Determine whether the difference between the actual state parameter and the theoretical state parameter defined by the task instruction node or the collaborative action node exceeds a preset threshold;

[0109] D3. If yes, create a deviation event node based on the smart contract.

[0110] In steps D1 to D3, the actual state parameters of the aircraft are obtained through the aircraft's onboard system monitoring. When the aircraft's onboard system detects that the difference between its actual state parameters (such as position, attitude, sensor readings) and the theoretical state parameters defined by the currently effective "mission instruction node" or "collaborative action node" exceeds the preset threshold, a deviation event node is created in the graph according to the smart contract.

[0111] In this embodiment, the deviation event node records the following information:

[0112] Associated Planned Task Identifier: A reference to the "task instruction node" or "collaborative action node" originally planned for execution; Deviation Trigger Cause: Records the cause code for the deviation (e.g., weather conditions, obstacle avoidance, equipment failure, autonomous path optimization) and a supplementary text description. This information can originate from the fusion judgment results of onboard sensor data or ground control instructions; Aircraft Immediate Response Measures: Records the type of response measures taken by the aircraft in response to the deviation (e.g., route adjustment, sensor scanning mode change, operation suspension, backup system activation) and related key parameters (e.g., new waypoint coordinates, new scanning area definition); Deviation Event Spatiotemporal Characteristics: Records the start timestamp, end timestamp, or duration of the deviation event, as well as the geographical scope of the deviation or a quantitative deviation degree indicator; Responsible Aircraft Identifier: Records the identity of the aircraft that performed this deviation behavior.

[0113] Preferably, the edge types further include: edges originating from plans, response action edges, and impact data record edges;

[0114] like Figure 5 As shown, after step D3, the following steps are also included:

[0115] D4. Create plan edges, response action edges, and impact data record edges based on the smart contract;

[0116] D51. Connect the planned collaborative action node to the deviation event node from the planned edge;

[0117] D52. When a deviation event results in the creation of a new collaborative action node, a response action edge is connected from the deviation event node to the new collaborative action node;

[0118] D53. When a deviation event results in the creation of a new data summary node, the affected data record edge will connect the deviation event node to the new data summary node.

[0119] In step D4, the edge types related to the deviation event are defined, and the edges originating from the plan, the response action edges, and the impact data record edges are created in the graph through the smart contract;

[0120] Steps D51, D52, and D53 are executed in parallel. The "DerivedFromPlan" edge connects the "collaborative action node" of the original plan to the corresponding "plan deviation event node";

[0121] "RespondedWithAction" edge: If the deviation event causes the aircraft to execute a new, specific "coordinated action node" that was not originally planned (for example, an emergency obstacle avoidance maneuver), this edge points from the "plan deviation event node" to the newly generated action node;

[0122] "Affected Data Record" edge: points from the "Plan Deviation Event Node" to the new "Data Summary Node" created during the deviation period. Alternatively, a specific tag is added to the metadata of the new "Data Summary Node" to indicate that its data was collected during the plan deviation state.

[0123] Through the above steps, the aircraft's deviations from the plan and their associated contextual information are structured and recorded in the event graph, coexisting with and clearly distinguishing from regular mission execution records. This mechanism enables users to not only trace the execution of the original plan during post-analysis, but also to understand the details of various deviations from the plan that occurred during mission execution, including their causes, the aircraft's response measures, and the specific impact on the data collection process. This provides data support for mission audits, data quality grading assessments, aircraft behavior pattern analysis, and iterative improvements to emergency coordination strategies.

[0124] Preferably, the node types further include: data quality nodes and evaluation subject nodes;

[0125] like Figure 6 As shown, after step A2, the following steps are also included:

[0126] E1. After the collected data of any aircraft has been evaluated by the evaluation subject, a data quality node and an evaluation subject node are created based on the smart contract.

[0127] During actual use, the quality of data collected by aircraft may vary. For example, images may be blurred due to smoke obstruction, sensor readings may be abnormal due to strong electromagnetic interference, low-quality data may be used improperly, or the contribution assessment of the aircraft that generated low-quality data may be biased, affecting the accuracy and fairness of the entire emergency response task assessment. Based on this, data quality nodes and evaluation subject nodes are defined in the graph. After the quality assessment of the collected data is completed according to the evaluation subject, data quality nodes and evaluation subject nodes are created in the graph according to the smart contract.

[0128] In this embodiment, the data quality node records the following information:

[0129] Linked Data Summary Identifier: clearly points to the existing "Data Summary Node" it evaluates;

[0130] Assessment entity identification: records the unit or system that performs the data quality assessment (for example, the ID of the aircraft's onboard quality assessment module, the specific assessment service ID of the ground data processing center, or the digital identity of a specific authorized expert);

[0131] Assessment timestamp: records the time when the quality assessment is completed;

[0132] Quality assessment parameter set: contains one or more sets of parameters that describe data quality, such as: quantitative quality score (such as 0-100 points), quality level (such as excellent, good, qualified, poor, unusable), quality feature labels (such as clear, complete, noisy, partially missing, out of valid range), specific quality problem description text or code, assessment method and basis: records the identification of the algorithm, standard or rule used in this quality assessment.

[0133] There are two types of quality assessments. If it is a preliminary airborne assessment, the assessment subject is the aircraft; if it is a detailed ground station assessment, the assessment subject is the ground assessment system.

[0134] like Figure 6 As shown, preferably, the edge type further includes: a declared quality edge and an evaluation subject edge;

[0135] After step E1, the following steps are further included:

[0136] E2. Create a declaration quality edge and an assessment subject edge based on the smart contract;

[0137] E3. Connect the data quality node to the data summary node with a statement quality edge, and connect the data quality node to the assessment subject node with an assessment subject edge.

[0138] In step E2, the quality assessment-related edge types are defined, and the declared quality edge and assessment subject edge are created in the graph through smart contracts;

[0139] In step E3, the "Statement Quality (StatesQualityOf)" edge: points from the "Data Quality Statement Node" to the "Data Summary Node" of its evaluation, indicating that the statement is a description of the quality of the target data summary; the "Assessment (AssessedBy) Subject" edge: points from the "Data Quality Statement Node" to the "Aircraft Node" that performs the evaluation (if it is an airborne evaluation) or an "Assessment Subject Node" representing a ground evaluation system.

[0140] In this embodiment, when a "data summary node" is created, the relevant quality assessment process can be triggered. After the quality assessment is completed, the authorized assessment entity interacts with the graph management smart contract to submit a request to create a "data quality node" and establish an edge between it, the corresponding "data summary node" and the assessment entity. The graph management smart contract is responsible for verifying the legitimacy of the request and recording the new quality node and associated edges in the event graph on the blockchain.

[0141] like Figure 7 As shown, preferably, obtaining the contribution weight rule in step C2 includes the following steps:

[0142] F1. Classify the collected data into different quality levels according to the data quality nodes;

[0143] F2. Assign different contribution weights to collected data of different quality levels according to preset rules;

[0144] F3. Calculate the contribution scores of collected data of different quality levels.

[0145] In steps F1 to F3, the various types of collected data from the aircraft are classified into different quality levels by querying the data quality node. Different contribution weights are assigned to the collected data of different quality levels according to preset rules, and the contribution scores of the collected data of different quality levels are calculated.

[0146] In the embodiment, the contribution score of a piece of collected data is obtained according to its quality. High-quality data obtains a higher contribution score, while data marked as "unavailable" is not counted as effective contribution. The correspondence between quality and contribution can be set according to actual scenarios.

[0147] When data fusion and analysis applications call atlas data, they can filter data that meets specific quality requirements based on the information of "data quality nodes" for processing, thereby improving the reliability of analysis results;

[0148] Through these steps, the quality information of aircraft-collected data can be independently, reliably, and structuredly recorded in the event graph and associated with specific data summaries. This allows data quality to be fully considered during mission audits, multi-source data fusion, contribution assessment, and decision support, thereby improving the accuracy and practicality of the entire emergency response collaborative mission evidence system.

[0149] like Figure 8 As shown, a blockchain-based aircraft data notarization system includes:

[0150] A graph construction module is used to define node types and edge types based on multiple aircraft, mission instructions, decision events, data summaries, collaborative actions, and preset relationships between them to build a collaborative mission event graph on the main blockchain;

[0151] An anchor association module is used to build a local collaborative processing network based on the collaborative information between multiple aircraft that perform collaborative tasks. When the local collaborative processing network meets the preset conditions, it creates an anchor node in the collaborative task event map based on the collaborative information and associates the collaborative information node with a specific node in the collaborative task event map.

[0152] The smart contract management module is used to manage the creation and update of all nodes and edges in the collaborative task event graph based on the smart contracts deployed on the main blockchain.

[0153] The present invention also provides a blockchain-based aircraft data archiving system, comprising a graph construction module, an anchoring and association module, and a smart contract management module. The graph construction module constructs a "dynamic collaborative task event graph" on the main chain, which is used to structuredly record key events and their interrelationships throughout the entire process of emergency response tasks, from triggering, reorganization, execution, to completion. Simultaneously, the anchoring and association module introduces one or more local processing networks (e.g., temporary sidechains or state channels built on inter-aircraft communication links) that serve high-frequency micro-collaborations within the aircraft cluster. These local networks utilize a lightweight consensus mechanism to rapidly process and record micro-collaboration information. The processing results of these local networks (such as status summaries or hashes of key micro-collaboration events) are periodically or on-demand anchored to the main chain's event graph, forming a verifiable association. The smart contract management module deploys smart contracts on the main chain, responsible for managing the event graph construction rules, verifying the validity of anchoring information, and preliminarily marking equity ownership based on the contribution information recorded in the graph.

[0154] In the embodiments provided in this application, it should be understood that the disclosed methods and systems can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of modules is merely a logical function division. In actual implementation, there may be other division methods, such as: multiple modules or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0155] In addition, all functional modules in the embodiments of the present invention may be integrated into one processor, or each module may be a separate device, or two or more modules may be integrated into one device; the functional modules in the embodiments of the present invention may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0156] Those skilled in the art will understand that all or part of the steps of the above-mentioned method embodiment can be completed by program instructions and related hardware. The aforementioned program instructions can be stored in a computer-readable storage medium. When the program instructions are executed, the steps of the above-mentioned method embodiment are executed; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM), magnetic disks or optical disks, and other media that can store program codes.

[0157] It should be understood that the use of "system," "device," "unit," and / or "module" in this application is merely a method for distinguishing different components, elements, parts, portions, or assemblies at different levels. However, if other terms can achieve the same purpose, the terms may be replaced by other expressions.

[0158] As used in this application and the claims, unless the context clearly indicates an exception, the terms "a," "an," "an," and / or "the" are not intended to refer to the singular and may include the plural, unless the context clearly indicates otherwise. Generally speaking, the terms "comprises" and "include" only indicate the inclusion of the steps and elements specifically identified, and these steps and elements do not constitute an exclusive list. A method or apparatus may also include other steps or elements. The phrase "comprises a..." does not preclude the presence of additional identical elements in the process, method, product, or apparatus that includes the elements.

[0159] In the following, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the quantity of the technical features indicated. Therefore, a feature specified as "first" or "second" may explicitly or implicitly include one or more of the features.

[0160] If a flow chart is used in this application, the flow chart is used to illustrate the operations performed by the system according to the embodiments of the application. It should be understood that the previous or subsequent operations are not necessarily performed in exact order. Instead, the steps can be processed in reverse order or simultaneously. At the same time, other operations can be added to these processes, or one or more operations can be removed from these processes.

[0161] The above describes in detail the blockchain-based aircraft data storage method and system provided by the present invention. The above description of the disclosed embodiments enables those skilled in the art to implement or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not limited to the embodiments shown herein but is intended to be embodied in the broadest possible manner consistent with the principles and novel features disclosed herein.

Claims

1. A blockchain-based aircraft data notarization method, applied to emergency scenarios of aircraft collaborative mission execution and deployment, characterized by: The steps include: Define node and edge types based on the multiple aircraft, mission instructions, decision events, data summaries, collaborative actions, and pre-set relationships between them to build a collaborative mission event graph on the main blockchain. A local collaborative processing network is constructed based on collaborative information between multiple aircraft that collaboratively perform a mission. When a preset condition is met, the local collaborative processing network creates an anchor node in the collaborative mission event graph based on the collaborative information, and associates the anchor node with a specific node in the collaborative mission event graph. Manage the creation and update of all nodes and edges in the collaborative task event graph according to the smart contract deployed on the main blockchain; The process of defining node types and edge types based on multiple aircraft, mission instructions, decision events, data summaries, collaborative actions, and preset relationships between them to build a collaborative mission event graph on the main blockchain includes the following steps: Based on the multiple aircraft, mission instructions, decision events, data summaries and collaborative actions that collaborate to perform a mission and the preset relationships between them, the node types are defined to include: aircraft node, mission instruction node, decision event node, data summary node and collaborative action node; the edge types are defined to include: trigger edge, execution edge, generation edge, dependency edge and belonging to edge; On the main blockchain, the aircraft node, the mission instruction node, the decision event node, the data summary node, the coordinated action node, and the trigger edge, the execution edge, the generation edge, the dependency edge, and the belonging edge are respectively created according to the smart contract; Connect the decision event node to the task instruction node, or connect the task instruction node to the collaborative action node, connect the execution edge to the aircraft node to the collaborative action node, connect the generation edge to the collaborative action node to the data summary node, connect the depend edge between two data summary nodes, or connect two collaborative action nodes, and connect the data summary node or the collaborative action node to the aircraft node with the belong edge to construct the collaborative task event graph.

2. The blockchain-based aircraft data storage method according to claim 1, characterized in that: The method of constructing a local collaborative processing network based on collaborative information between multiple aircraft that collaboratively perform a mission, creating an anchor node in the collaborative mission event graph based on the collaborative information when a preset condition is met, and associating the anchor node with a specific node in the collaborative mission event graph, includes the following steps: Acquiring the collaborative information according to the communication between the multiple aircrafts in the collaborative flight mission, and constructing the local collaborative processing network to record the collaborative information; When the local collaborative processing network meets the preset conditions, a collaborative event log and summary information are generated according to the collaborative information and encapsulated into a collaborative anchor transaction; Verifying the collaborative anchoring transaction according to the smart contract, and upon passing the verification, creating an anchor node in the collaborative task event graph; An association edge is defined and created, and the association edge connects the anchor node to the aircraft node or the association edge connects the anchor node to the parent collaborative action node.

3. The blockchain-based aircraft data storage method according to claim 2, characterized in that: The node types also include: contribution mark nodes; On the main blockchain, after creating the aircraft node, the mission instruction node, the decision event node, the data summary node, the coordinated action node, and the trigger edge, the execution edge, the generation edge, the dependency edge, and the belonging edge according to the smart contract, the following steps are also included: Creating the contribution mark node according to the smart contract; According to the trigger edge, the execution edge, the generation edge and the contribution weight rule, a contribution evaluation message is recorded in the contribution marking node.

4. The blockchain-based aircraft data storage method according to claim 2, characterized in that: The node types also include: deviation event nodes; On the main blockchain, after creating the aircraft node, the mission instruction node, the decision event node, the data summary node, the coordinated action node, and the trigger edge, the execution edge, the generation edge, the dependency edge, and the belonging edge according to the smart contract, the following steps are also included: Obtaining actual state parameters of the aircraft in the collaborative flight mission; Determining whether a difference between the actual state parameter and the theoretical state parameter defined by the task instruction node or the collaborative action node exceeds a preset threshold; If so, create the deviation event node according to the smart contract.

5. The blockchain-based aircraft data storage method according to claim 4, characterized in that: The edge types also include: edges originating from plans, response action edges, and impact data record edges; After creating the deviation event node according to the smart contract, the following steps are also included: Creating the originating plan edge, the response action edge, and the impact data record edge according to the smart contract; Connecting the planned edge to the coordinated action node of the original plan to the deviation event node; When a deviation event results in the creation of a new collaborative action node, the response action edge connects the deviation event node to the new collaborative action node; When a deviation event results in the creation of a new data summary node, the impact data record edge is connected to the deviation event node to the new data summary node.

6. The blockchain-based aircraft data storage method according to claim 3, characterized in that: The node types also include: data quality nodes and evaluation subject nodes; On the main blockchain, after creating the aircraft node, the mission instruction node, the decision event node, the data summary node, the coordinated action node, and the trigger edge, the execution edge, the generation edge, the dependency edge, and the belonging edge according to the smart contract, the following steps are also included: When the collected data of any aircraft undergoes quality assessment by the assessment subject, the data quality node and the assessment subject node are created according to the smart contract.

7. The blockchain-based aircraft data storage method according to claim 6, characterized in that: The edge types also include: declared quality edges and assessment subject edges; After the collected data of any aircraft has been evaluated by the evaluation subject, and the data quality node and the evaluation subject node are created according to the smart contract, the following steps are also included: Creating the declared quality edge and the assessment subject edge according to the smart contract; The statement quality edge connects the data quality node to the data summary node, and the assessment subject edge connects the data quality node to the assessment subject node.

8. The blockchain-based aircraft data storage method according to claim 7, characterized in that: Obtaining the contribution weight rule includes the following steps: Classifying the collected data into different quality levels according to the data quality nodes; Assigning different contribution weights to the collected data of different quality levels according to preset rules; Contribution scores of the collected data of different quality levels are calculated.

9. A blockchain-based aircraft data evidence storage system, characterized by: include: A graph construction module is used to define node types and edge types based on multiple aircraft, mission instructions, decision events, data summaries, collaborative actions, and preset relationships between them to build a collaborative mission event graph on the main blockchain; An anchor association module, configured to construct a local collaborative processing network based on collaborative information between multiple aircraft performing a collaborative mission. When a preset condition is met, the local collaborative processing network creates an anchor node in the collaborative mission event graph based on the collaborative information, and associates the collaborative information node with a specific node in the collaborative mission event graph. A smart contract management module, configured to manage the creation and update of all nodes and edges in the collaborative task event graph based on the smart contracts deployed on the main blockchain; The graph construction module is further used to define node types including aircraft nodes, task instruction nodes, decision event nodes, data summary nodes and collaborative action nodes according to multiple aircraft, task instructions, decision events, data summaries and collaborative actions that collaborate to perform a task and preset relationships between them, and to define edge types including trigger edges, execution edges, generation edges, dependent edges and belonging edges; On the main blockchain, the aircraft node, the mission instruction node, the decision event node, the data summary node, the coordinated action node, and the trigger edge, the execution edge, the generation edge, the dependency edge, and the belonging edge are respectively created according to the smart contract; Connect the decision event node to the task instruction node, or connect the task instruction node to the collaborative action node, connect the execution edge to the aircraft node to the collaborative action node, connect the generation edge to the collaborative action node to the data summary node, connect the depend edge between two data summary nodes, or connect two collaborative action nodes, and connect the data summary node or the collaborative action node to the aircraft node with the belong edge to construct the collaborative task event graph.

Images