Electronic Flight Package Heterogeneous Data Fusion and Intent Mapping Collaborative Method and Apparatus

Abstract

This invention discloses a method and apparatus for heterogeneous data fusion and intent mapping collaboration in electronic flight packages. The method includes: establishing a local collaboration domain based on handshake authentication derived from task identifiers and role credential keys; collecting airborne and external business data, converting the format, and embedding state snapshots into synchronized data units; performing one-way hash calculation on the integrity check code of the previous operation log node in the local memory, the current synchronized data unit, and the operator's digital signature to obtain a sequence fingerprint, and encapsulating the synchronized data unit, the sequence fingerprint, and the operator's digital signature to obtain a chained operation log node, updating the local state after multi-level verification; responding to critical operations, encapsulating shadow instruction data packets and synchronizing them to the decision-making end, executing the write operation after state verification and authorization; and calculating the root digest upon flight completion and storing it in a non-erasable medium. This invention solves the problems of heterogeneous data fusion, cross-terminal intent collaboration, and offline auditing in airborne environments.

Description

Technical Field

[0001] This invention relates to the field of avionics information processing and airborne terminal collaborative computing technology, specifically to a collaborative method and apparatus for heterogeneous data fusion and intent mapping of electronic flight packages for airborne decentralized network environments. Background Technology

[0002] With the continuous development of aviation digitalization, electronic flight bags have become key equipment for flight crews to perform flight missions. In the cockpit, the captain and first officer are typically each equipped with an electronic flight bag to undertake different collaborative tasks. Currently, data interaction between multiple electronic flight bags mainly relies on two methods: one is network synchronization based on cloud or ground-based central nodes; the other is local direct communication using simple point-to-point technologies such as Bluetooth and Wi-Fi Direct.

[0003] However, the aforementioned technologies have significant drawbacks in airborne constrained environments. Synchronization schemes relying on a central node are highly susceptible to link interruptions during transoceanic or polar flights due to the lack of a public network, failing to meet the low-latency interaction requirements of critical flight phases. Existing point-to-point technologies only address network connectivity, lacking a collaborative mechanism at the business logic layer: the real-time bus data acquired by the captain and the external documents received by the co-pilot lack machine integration and automatic verification methods, heavily relying on manual verbal review, resulting in low fault tolerance; after completing business calculations, the co-pilot cannot directly map instructions to the captain for authorized execution, making concurrent operations prone to data conflicts; and the scattered storage of operation records from each terminal lacks a unified time-series binding and anti-tampering mechanism, failing to meet the high-reliability auditing requirements of civil aviation. Therefore, a collaborative method and device for electronic flight bags in airborne decentralized environments is urgently needed to address these technical bottlenecks. Summary of the Invention

[0004] To address the shortcomings of existing technologies in restricted airborne network environments, such as data synchronization being highly dependent on a central node, difficulties in verifying heterogeneous data sources, easy forks in concurrent operation states, and difficulty in tracing offline operation records, the present invention aims to provide a method and apparatus for electronic flight bag heterogeneous data fusion and intent mapping collaboration, thereby achieving heterogeneous data consistency verification and crew collaboration closed loop under conditions without a central node.

[0005] To achieve the above objectives, the first aspect of the present invention provides a method for heterogeneous data fusion and intent mapping collaboration of electronic flight bags, applied to multiple electronic flight bag terminals under the same flight mission, comprising:

[0006] Obtain the flight mission identifier and crew role credentials, perform key derivation and handshake authentication on the flight mission identifier and crew role credentials, and establish a local temporary trusted collaborative domain between the first terminal and the second terminal, wherein the first terminal is the decision-making end and the second terminal is the operation end;

[0007] The first terminal is used to collect airborne operation data, and the second terminal is used to collect external service operation data. The airborne operation data and the external service operation data are then converted in format and embedded with status snapshots to obtain a synchronized data unit.

[0008] A sequence fingerprint is obtained by performing a one-way hash calculation on the integrity check code of the previous operation log node in the local memory, the current synchronization data unit, and the operator's digital signature. The synchronization data unit, the sequence fingerprint, and the operator's digital signature are then encapsulated to obtain a chained operation log node.

[0009] The chained operation log nodes are broadcast to other terminals through the collaborative domain. The received chained operation log nodes are subjected to sequence fingerprint continuity verification, timing verification, and business logic verification to obtain the verification results. The local data status is updated based on the verification results.

[0010] In response to a critical control operation of the second terminal, the local execution of the critical control operation is intercepted, a shadow command data packet containing the parameters of the command to be executed and a snapshot of the aircraft status is encapsulated and synchronized to the first terminal. The first terminal performs a status consistency check on the shadow command data packet, and executes data writing after the check passes.

[0011] In response to the flight mission end signal, a root digest is calculated for the chained operation log node sequence to obtain a root digest value, and the root digest value is stored in a non-erasable storage medium.

[0012] According to one embodiment of the present invention, obtaining a flight mission identifier and crew role credentials, performing key derivation and handshake authentication on the flight mission identifier and crew role credentials, and establishing a local temporary trusted collaboration domain between a first terminal and a second terminal includes:

[0013] Obtain the flight mission identifier, the crew role credentials, and the pre-set crew shared key;

[0014] Using the flight mission identifier as the salt value and the crew shared key as input, a session key specific to this flight mission is obtained by using a cryptographic key derivation function.

[0015] Based on the session key, an encrypted transmission channel is established between the first terminal and the second terminal through a wireless communication protocol to determine the local temporary trusted cooperative domain; wherein, only terminals that complete handshake verification through the session key are allowed to join the cooperative domain.

[0016] According to one embodiment of the present invention, the synchronization data unit includes:

[0017] The data payload section is used to store operating parameter values ​​or operation instructions;

[0018] The data source identifier section is used to identify whether the data source is an airborne interface, an external business system, or manual input.

[0019] The status snapshot section is used to encapsulate a summary of the aircraft's operational status at the time the data was generated. The status summary includes at least the aircraft's air or ground status and timestamp information.

[0020] According to one embodiment of the present invention, a sequence fingerprint is obtained by performing a one-way hash calculation on the integrity check code of the previous operation log node in the local memory, the current synchronization data unit, and the operator's digital signature, and then encapsulating the synchronization data unit, the sequence fingerprint, and the operator's digital signature to obtain a chained operation log node, including:

[0021] Obtain the integrity check code of a valid operation log node in the local storage as a preceding fingerprint;

[0022] The preceding fingerprint, the current synchronization data unit, and the operator's digital signature are combined to output the data segment to be hashed.

[0023] The sequence fingerprint of the current operation log node is obtained by calculating the one-way hash algorithm on the data segment to be hashed.

[0024] The synchronization data unit, the sequence fingerprint, and the digital signature are encapsulated and finally output as the chained operation log node.

[0025] According to an embodiment of the present invention, updating the local data status based on the verification result includes:

[0026] Maintain the logical clock vector and unit role weight table for each terminal;

[0027] When multiple terminals are detected to be concurrently modifying the same data item, the weights of the crew roles in the concurrent operations are compared based on the crew role weight table to determine the weight comparison result.

[0028] Based on the weight comparison results, the operation results of the roles with weights higher than the preset weight threshold are retained, and a rollback instruction is sent to the terminals of the roles with weights lower than the preset weight threshold to update the local data status.

[0029] According to one embodiment of the present invention, the first terminal performs state consistency verification on the shadow instruction data packet, including:

[0030] Extract the aircraft status snapshot encapsulated in the shadow command data packet;

[0031] Obtain the current real-time aircraft status data of the first terminal;

[0032] The aircraft status snapshot is compared with the real-time aircraft status data to obtain the status difference value;

[0033] When the state difference value exceeds the preset state threshold or the state identifier does not match, it is determined that the shadow instruction data packet has expired and the data writing is refused.

[0034] When the state difference value does not exceed the preset state threshold and the state identifier matches, the data writing is performed in response to the physical authorization input signal of the first terminal.

[0035] According to one embodiment of the present invention, after obtaining the chained operation log nodes, the method further includes:

[0036] After generating each of the chained operation log nodes, the sequence fingerprint of the current node is extracted, and the sequence fingerprint is merged with the previous round of rolling aggregation tag value maintained in memory through message authentication code combination operation to obtain the updated rolling aggregation tag value.

[0037] Obtain the current operation density and flight phase identifier. When the operation density exceeds a preset density threshold or the flight phase identifier is a critical flight phase, encrypt the current scrolling aggregation tag value to obtain the segmented audit anchor value.

[0038] The segmented audit anchor point value is written to an independent storage partition isolated from the operation log storage area. The independent storage partition is access controlled with different write permissions than the operation log storage area, thus obtaining the segmented audit anchor point in isolated storage.

[0039] The segmented audit anchor points are reconstructed and verified segment by segment. The value of each segmented audit anchor point is used as a leaf node to calculate the root digest value, so as to store the root digest value in the non-erasable storage medium.

[0040] According to one embodiment of the present invention, the segmented audit anchor points are reconstructed and verified segment by segment, and the root digest value is calculated using each segmented audit anchor point value as a leaf node, including:

[0041] Read the segmented audit anchor value from the independent storage partition, reconstruct the rolling aggregate tag value segment by segment for the chained operation log node in each segment interval, compare the reconstructed rolling aggregate tag value with the corresponding stored segmented audit anchor value to obtain the segmented verification result;

[0042] When the segment-by-segment verification results do not match, the tampering range is located to the corresponding segment interval to obtain the tampering location result;

[0043] Each segmented audit anchor value is used as a leaf node, and a Merkle tree root summary is calculated for all leaf nodes to obtain the root summary value.

[0044] According to one embodiment of the present invention, after broadcasting the chained operation log node through the collaborative domain and before updating the local data status based on the verification result, the method further includes:

[0045] Each terminal maintains a local state summary, which includes a vector version number of the current state of the local operation log chain and a Bloom filter encoding of the set of confirmed operation log node identifiers.

[0046] When the terminal reconnects to the collaborative domain, the state digests of each terminal are exchanged, the log fork point is determined by comparing the vector version numbers of each terminal, and the set of operation log node identifiers that the peer has held but the local terminal does not have is identified by the Bloom filter encoding to obtain the minimum synchronization difference set.

[0047] Based on the minimum synchronization difference set, the missing incremental operation log nodes are requested and transmitted from the peer to obtain the incremental synchronization result, and the local data status is updated based on the incremental synchronization result.

[0048] For concurrent operation nodes in the incremental operation log node, extract the aircraft status identifier from the status snapshot of each node for semantic classification. When the aircraft status identifier of concurrent nodes is the same, retain the operation results with a weight higher than the preset weight threshold and append the operation nodes with a weight lower than the preset weight threshold to the operation log chain.

[0049] When the aircraft status identifiers of concurrent nodes are different, the operation results of roles with weights higher than the preset weight threshold are retained, and a rollback command is sent to the terminal of a role with a weight lower than the preset weight threshold.

[0050] For operation log segments that have completed digest handshake alignment, broadcast the segmentation acknowledgment signal of the log segment to the cooperative domain, mark the operation log segments that have received segmentation acknowledgment signals from all online terminals as cross-terminal acknowledgment states, and update the local vector version number of each terminal with the state digest of the cross-terminal acknowledgment state log segments.

[0051] According to one embodiment of the present invention, for concurrent operation nodes in the incremental operation log nodes, semantic classification is performed on the aircraft status identifier extracted from the status snapshots of each node, including:

[0052] Extract the state snapshots of each concurrent operation node in the minimum synchronization difference set, and obtain the aircraft state identifier in the state snapshots;

[0053] The aircraft status identifiers of each concurrent operation node are compared one by one. When the aircraft status identifiers of two concurrent nodes correspond to the same aircraft physical state, they are classified as semantically compatible concurrency, and semantic preservation merging is performed: the operation result of the higher-weight role is retained as the final data state, and the operation node of the lower-weight role is appended to the operation log chain as an audited historical operation record to obtain the merged operation log chain; when the aircraft status identifiers of two concurrent nodes correspond to different aircraft physical states, they are classified as semantically conflicting concurrency, the operation result of the higher-weight role is retained, and a rollback instruction is sent to the terminal of the lower-weight role to obtain the local data state after the conflict is resolved.

[0054] According to one embodiment of the present invention, in response to a critical control operation of the second terminal, after intercepting the local execution of the critical control operation, encapsulating a shadow command data packet containing parameters of the command to be executed and an aircraft status snapshot, and synchronizing it to the first terminal, the method further includes:

[0055] During the user operation process on the second terminal, the current flight phase identifier, recent operation type sequence, current interface focus data field and user input completion are continuously collected and fused to obtain the operation context vector;

[0056] The operation context vector is input to a preset operation intent classification model to infer the confidence prediction distribution of each key control operation intent;

[0057] When the confidence level of a certain operation intention exceeds the preset activation threshold, a pre-filled shadow instruction draft is generated in advance based on the currently input parameters and the aircraft status snapshot.

[0058] The pre-filled shadow command draft and its confidence value are synchronized to the first terminal in advance. The first terminal performs a state consistency pre-verification on the aircraft state snapshot in the pre-filled shadow command draft, places the pre-filled shadow command draft that passes the pre-verification in the activation queue, and sends a warning signal to the first terminal user.

[0059] When the second terminal user actually triggers the key control operation, the pre-filled shadow instruction draft in the queue to be activated is matched with the type and parameter key name of this operation. When the match is found, the pre-filled shadow instruction draft that has been pre-verified in the queue to be activated is directly activated to obtain the shadow instruction data packet. The first terminal responds to the physical authorization input signal to execute the data writing.

[0060] When a match is not found, the shadow instruction data packet is repackaged and synchronized to the first terminal;

[0061] Record the prediction hit rate of the operation intent classification model in each flight mission, and dynamically adjust the preset activation threshold of each operation type based on the prediction hit rate to obtain the updated activation threshold.

[0062] A second aspect of the present invention provides an electronic flight bag heterogeneous data fusion and intent mapping collaborative device, comprising:

[0063] The trusted collaboration module is used to obtain the flight mission identifier and crew role credentials, perform key derivation and handshake authentication on the flight mission identifier and crew role credentials, and establish a local temporary trusted collaboration domain between the first terminal and the second terminal, wherein the first terminal is the decision-making end and the second terminal is the operation end;

[0064] The synchronization data module is used to collect airborne operation data using the first terminal and external business operation data using the second terminal, and to perform format conversion and status snapshot embedding on the airborne operation data and the external business operation data to obtain a synchronization data unit.

[0065] A one-way hash calculation module is used to perform one-way hash calculation on the integrity check code of the previous operation log node in the local memory, the current synchronization data unit and the operator's digital signature to obtain a sequence fingerprint, and encapsulate the synchronization data unit, the sequence fingerprint and the operator's digital signature to obtain a chained operation log node;

[0066] The verification module is used to broadcast the chained operation log nodes to other terminals through the collaborative domain, perform sequence fingerprint continuity verification, timing verification and business logic verification on the received chained operation log nodes, obtain verification results, and update the local data status based on the verification results.

[0067] The interception module is used to respond to the critical control operation of the second terminal, intercept the local execution of the critical control operation, encapsulate a shadow command data packet containing the parameters of the instruction to be executed and the aircraft status snapshot and synchronize it to the first terminal. The first terminal performs a status consistency check on the shadow command data packet, and executes data writing after the check passes.

[0068] The storage module is used to perform root digest calculation on the chained operation log node sequence in response to the flight mission end signal, obtain the root digest value, and store the root digest value in a non-erasable storage medium.

[0069] The present invention has the following beneficial effects: First, by using a two-factor key derivation mechanism based on flight mission identifiers and crew role credentials, a local temporary trusted collaborative domain is constructed that does not rely on the external public network, ensuring stable and continuous data synchronization during critical phases of transoceanic flights. Second, by using a data fusion engine and a strong binding mechanism with state snapshots, machine logic verification replaces traditional manual verbal verification, fundamentally ensuring the consistency of internal and external global data. Third, the cross-terminal intent mapping mechanism based on shadow commands realizes a business closed loop of operation terminal initiation, decision terminal review, and system atomic execution, breaking the physical separation between multiple electronic flight bag devices; Fourth, a log chain based on hash algorithm and a post-event root digest anchoring mechanism are adopted to ensure the absolute temporal order and immutability of concurrent operation records in the absence of a central node for time synchronization, fully meeting the highest level of compliance audit requirements of civil aviation. Attached Figure Description

[0070] Figure 1 A schematic diagram of the architecture of the implementation environment for the collaborative method provided in the embodiments of the present invention;

[0071] Figure 2 The main flowchart of the electronic flight bag coordination method provided in the embodiments of the present invention is shown below;

[0072] Figure 3 A schematic diagram of the chained operation log node generation and segmented audit anchor point mechanism provided in this embodiment of the invention;

[0073] Figure 4 A flowchart for shadow instruction state consistency verification provided in an embodiment of the present invention;

[0074] Figure 5 A schematic diagram of the module structure of the electronic flight bag heterogeneous data fusion and intent mapping collaborative device provided in an embodiment of the present invention. Detailed Implementation

[0075] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0076] The methods and systems provided in this invention are primarily deployed in the cockpit environment of an aircraft. For example... Figure 1 As shown, its underlying physical architecture includes:

[0077] The first terminal (101) is preferably an electronic flight bag (EFB) used by the captain, such as a high-performance tablet computer. The first terminal is connected to the aircraft's onboard interface device (AID, 103) via a physical data cable or encrypted Wi-Fi. The first terminal is configured as an "onboard data gateway node," possessing the authority to read bus data such as ARINC 429 / 717, and capable of acquiring real-time onboard operational parameters such as the aircraft's FMS flight plan, fuel level, GPS location, and air-to-ground status. In this invention, the first terminal is defined as a decision-making terminal.

[0078] The second terminal (102) is preferably an EFB used by the co-pilot. The second terminal is primarily used to receive ground-based external service data downloaded via an external network, and to receive manually input operation commands. In this invention, the second terminal is defined as an operating terminal.

[0079] Collaborative communication network (103): A local collaborative domain established between the first terminal and the second terminal that is completely independent of external public networks and based on a secure transmission protocol (such as TLS 1.3).

[0080] It should be noted that the role division between the "first terminal" and the "second terminal" is not fixed to a specific physical device, but is dynamically determined based on the crew role credentials during the initialization of each flight mission. The terminal with onboard data acquisition permissions is identified as the decision-making end, and the terminal that initiates business input is identified as the operation end, thereby enabling the collaborative mechanism of this invention to have flexible role adaptation capabilities. Example 1

[0081] This embodiment provides a collaborative method for heterogeneous data fusion and intent mapping of electronic flight bags, applicable to multiple electronic flight bag terminals under the same flight mission, such as... Figure 2 As shown, the specific steps include:

[0082] S1: Obtain the flight mission identifier and crew role credentials, perform key derivation and handshake authentication on the flight mission identifier and crew role credentials, and establish a local temporary trusted collaborative domain between the first terminal and the second terminal, wherein the first terminal is the decision-making end and the second terminal is the operation end.

[0083] In a restricted airborne network environment, multiple electronic flight bag terminals in the cockpit cannot rely on external public networks for communication. Therefore, a fully autonomous local trusted collaborative domain must be established among the terminals. The first terminal is preferably the electronic flight bag used by the captain, which connects to the aircraft's onboard interface equipment via a physical data cable or encrypted wireless connection. It has the authority to read bus data such as ARINC 429 / 717 and can obtain real-time airborne operational parameters such as flight plans, fuel levels, GPS location, and air-to-ground status from the aircraft's flight management system. In this invention, it is defined as the decision-making terminal. The second terminal is preferably the electronic flight bag used by the co-pilot, mainly used to receive ground external business data downloaded via an external network and to receive manually input operating commands. In this invention, it is defined as the operating terminal.

[0084] The specific process of key derivation and handshake authentication is as follows: Each electronic flight bag terminal uses a cryptographic key derivation function (such as the PBKDF2 algorithm) to generate a session key specific to this flight mission, using the flight mission identifier (e.g., a combination of flight number and departure date) as the salt and a pre-set crew shared key as input. The first terminal acts as the group master broadcast beacon, and the second terminal initiates a connection request. Both parties verify the consistency of the session key by exchanging encrypted random numbers. After a successful handshake, based on the crew configuration file, the first terminal is determined to be the decision-making terminal with high privileges, and the second terminal is the operation terminal. Only terminals that can complete the handshake authentication through the session key are allowed to join the collaborative domain, thereby effectively preventing unauthorized devices from accessing the network. Once the flight ends, the collaborative domain link becomes invalid, ensuring the mission binding characteristic of the collaborative domain.

[0085] Through the above steps, a secure local networking foundation is laid for subsequent heterogeneous data fusion and intent mapping collaborative operations without relying on any external public network, completely solving the problem of link interruption caused by the lack of public network during transoceanic or polar flights.

[0086] S2: Use the first terminal to collect airborne operation data and the second terminal to collect external business operation data. Then, convert the format of the airborne operation data and the external business operation data and embed a status snapshot to obtain a synchronized data unit.

[0087] Airborne operational data originates from aircraft onboard interface equipment, including flight plan data from the flight management system, fuel level sensor data, GPS location data, and air-to-ground status signals. This data is transmitted via bus protocols such as ARINC 429 / 717 and has a specific binary encoding format. External operational data originates from ground-based external operational systems, such as fuel document values ​​and performance calculation results entered by the co-pilot. This data exists in the form of forms or manual input, and its format differs fundamentally from that of the onboard bus data.

[0088] The core of format conversion and status snapshot embedding lies in this: when the second terminal inputs external business data, it requests the first terminal to provide a current airborne data snapshot via a collaborative network, merging the two to construct a synchronous data unit with a preset structured format. The data structure of the synchronous data unit comprises three core parts: a data payload, used to store specific operating parameter values ​​or operation commands, such as a fuel document value of 8000 kg; a data source identifier, used to distinguish whether the data source is an airborne interface, an external business system, or manual input, enabling the receiving end to identify the credible source of the data; and a status snapshot, used to encapsulate a summary of the aircraft's operational status at the time of data generation. This summary includes at least the aircraft's airborne or ground status and timestamp information, such as the aircraft being ground-based and the parking brakes being set. The status snapshot logically proves that the business data was generated under specific aircraft physical conditions, allowing the receiving end to replace manual verbal verification with machine verification, fundamentally eliminating the problem of heterogeneous data silos and ensuring the consistency and high fault tolerance of internal and external global data.

[0089] S3: Perform a one-way hash calculation on the integrity check code of the previous operation log node in the local memory, the current synchronization data unit, and the operator's digital signature to obtain a sequence fingerprint, and encapsulate the synchronization data unit, the sequence fingerprint, and the operator's digital signature to obtain a chained operation log node.

[0090] To achieve absolute temporal order and tamper-proof characteristics of operation logs in an airborne environment without a central time synchronization node, this invention introduces a chained operation log node mechanism. When the processor of each electronic flight bag terminal detects user input or data updates, it reads the integrity check code of the previous valid log node from the local storage medium as a preceding fingerprint. Using a one-way hash algorithm (such as SHA-256), it calculates the unique sequence fingerprint of the data segment containing the preceding fingerprint, the current synchronization data unit, and the user's digital signature. The synchronization data unit, sequence fingerprint, and digital signature are then encapsulated into the current operation log node and stored on disk. This chained structure ensures that any modification to the historical record will result in a hash avalanche verification failure, thus achieving a tamper-proof record with consecutive beginnings and end.

[0091] S4: Broadcast the chained operation log nodes to other terminals through the collaboration domain, perform sequence fingerprint continuity verification, timing verification, and business logic verification on the received chained operation log nodes, obtain the verification results, and update the local data status based on the verification results.

[0092] After the chained operation log nodes are broadcast to other terminals via the wireless link in the cooperative domain, the receiving processor performs multi-level verification: Sequence fingerprint continuity verification uses cryptographic means to verify whether the sequence fingerprint of the received log node forms a continuous hash chain with the fingerprint of the end node of the local log chain; Time sequence verification verifies the monotonically increasing timestamps in the log nodes to prevent replay attacks; Business logic verification verifies the logical consistency between the operation instructions and the physical state of the aircraft at that time, based on the aircraft operation status snapshot in the synchronization data unit. After all three levels of verification pass, the receiving end updates the data status in its local memory, thereby achieving data synchronization and consistency verification among multiple terminals.

[0093] When concurrent operation conflicts occur, the system maintains the logical clock vector of each terminal and the crew role weight table. When multiple terminals are detected to be concurrently modifying the same data item, the crew role weights of the concurrent operations are compared based on the crew role weight table to determine the weight comparison result. The operation results of the role with a weight higher than the preset weight threshold (i.e., the captain / decision-making end) are retained, and the rollback command or conflict prompt message is sent to the terminal of the role with a weight lower than the preset weight threshold. The local data status is updated to ensure data consistency in concurrent operation scenarios.

[0094] S5: In response to the critical control operation of the second terminal, intercept the local execution of the critical control operation, encapsulate a shadow command data packet containing the parameters of the instruction to be executed and the aircraft status snapshot, and synchronize it to the first terminal. The first terminal performs a status consistency check on the shadow command data packet, and executes data writing after the check passes.

[0095] In an airborne environment, if the co-pilot (operator) directly writes core data locally after completing business calculations, it bypasses the captain's (decision-making) review, posing a security risk. This invention achieves cross-terminal intent mapping through a shadow command mechanism: when the second terminal receives a critical control operation initiated by the user (e.g., clicking the "Apply" button to submit performance data), it intercepts the operation, directly modifying the local execution logic of the core data, and generates a shadow command data packet containing the parameters of the command to be executed and a snapshot of the aircraft's state at the time of initiation. This data packet is then synchronized to the first terminal via a collaborative domain. After receiving and parsing the shadow command data packet, the first terminal restores the operation request on its connected display interface using an independent overlay layer, while the underlying system is hovered and intercepted. The first terminal responds to the captain's physical authorization input signal (such as physical button confirmation) and re-verifies the parameters to be confirmed: it extracts the aircraft status snapshot encapsulated in the shadow command data packet, obtains the current real-time aircraft status data of the first terminal, and compares the two to obtain the status difference value; when the status difference value exceeds the preset status threshold or the status identifier does not match, it determines that the shadow command data packet has expired and refuses to execute the data writing; when the status difference value does not exceed the preset status threshold and the status identifier matches, it calls the airborne underlying interface to complete the actual atomic data writing, and broadcasts the successful execution result back to the second terminal, forming a business closed loop of operation terminal initiation, decision terminal review, and system atomic execution.

[0096] S6: In response to the flight mission end signal, perform root digest calculation on the chained operation log node sequence to obtain the root digest value, and store the root digest value in a non-erasable storage medium.

[0097] In response to a trigger signal indicating the end of the flight mission (such as a combination of an air-to-ground switch and wheel chock signals), each electronic flight bag terminal ceases real-time synchronization services. Each terminal processor traverses the locally stored chain of operation log nodes, calculating the root digest value (e.g., a Merkle tree root hash) of the global operation log sequence to extract a digital fingerprint representing the operational trajectory of this flight. After multi-terminal verification confirms consistency, the root digest value is stored in the terminal's non-erasable storage medium, serving as a high-reliability offline audit anchor for the integrity of the flight mission's operation records, fully meeting the highest level of post-flight compliance audit requirements of civil aviation.

[0098] In another embodiment, specifically, the above process includes the following steps:

[0099] Step S1': Construct a temporary collaboration domain based on task binding.

[0100] In airborne restricted network environments, traditional authentication methods relying on external public networks or central nodes become completely ineffective in scenarios without public network coverage, such as transoceanic or polar regions. To address this, this invention proposes a local two-factor authentication mechanism based on flight mission identifiers and crew role credentials, constructing a temporary trusted collaborative domain between terminals without requiring any external network infrastructure.

[0101] The principle behind constructing the local temporary trusted collaborative domain is as follows: It utilizes the inherent unique identifier of the flight mission itself (such as a combination of flight number and departure date) as the salt value for key derivation. Combined with the crew-shared key pre-installed in each EFB terminal, a session key specific to this flight mission is generated through a cryptographic key derivation function. Since the salt value is unique for each flight mission, even if an attacker obtains historical session keys, they cannot deduce the session key for the current mission, thus achieving mission-level isolation of the session key.

[0102] Specifically, step S1' includes the following sub-steps:

[0103] Step S1-1': Obtain the mission identifier and the pre-set crew shared key for the current flight mission. The mission identifier is preferably a string concatenated with the flight number and departure date, such as "CA1234-20240115". This identifier is globally unique within the same airline's operating system. The crew shared key is pre-set in the secure storage area of ​​each EFB terminal by the airline's operating system before flight and is not transmitted over the network.

[0104] Step S1-2': Using a cryptographic key derivation function (PBKDF2), with the task identifier as the salt and the shared key as input, generate a session key specific to this flight mission. In this embodiment of the invention, it is recommended that the number of iterations of PBKDF2 be no less than 100,000, and the output key length be 256 bits to meet current cryptographic security strength requirements. This set number of iterations significantly increases the computational cost of brute-force attacks, making it difficult for an attacker to recover the shared key within a reasonable timeframe even if they obtain the salt.

[0105] Steps S1-3': Based on the session key, establish an encrypted transmission channel between terminals using a short-range wireless communication protocol (such as Wi-Fi Direct). The encrypted transmission channel adopts the TLS 1.3 protocol and uses the session key to complete two-way handshake authentication, ensuring the confidentiality and integrity of the communication content.

[0106] Steps S1-4': Only terminals capable of completing handshake verification using the session key are allowed to join the collaborative domain. The handshake verification process is as follows: each terminal exchanges encrypted random numbers (nonces), encrypts these random numbers using the session key, and then sends them to each other. The receiving terminal decrypts the nonces and verifies their correctness. Only terminals holding the correct session key can pass the verification; unauthorized devices are denied access because they cannot generate the correct encrypted random number.

[0107] It is worth noting that the validity period of the cooperative domain is strictly bound to the lifecycle of the flight mission. Once the flight mission ends (such as a combination of an air-to-ground switch and a wheel chock signal), the session key is destroyed, and the cooperative domain link becomes invalid, thereby preventing historical session keys from being reused in subsequent flight missions.

[0108] Through the above mechanism, this invention achieves secure networking of multiple terminals in an airborne environment without relying on external public networks, laying a secure and reliable network foundation for subsequent data fusion and collaborative operations.

[0109] Step S2': Fusion and normalization of heterogeneous data sources.

[0110] In cockpit collaboration scenarios, the captain acquires aircraft bus data (internal data) in real time through onboard interface devices, while the co-pilot receives operational data (external data) from ground operations systems via an external network. These two types of data differ significantly in format, source, and semantics. Without a unified fusion and alignment mechanism, automatic machine verification is impossible, and manual verbal verification is the only option, resulting in extremely low error tolerance.

[0111] This invention introduces a Synchronization Data Unit (SDU) as a unified data encapsulation format, shielding the differences between heterogeneous data sources behind a standardized interface. The core design concept of the SDU is that it not only encapsulates the business data itself, but also synchronously encapsulates a summary of the aircraft's operational status (state snapshot) at the time of data generation, thereby logically binding the business data to the specific physical state of the aircraft, providing a foundation for subsequent machine business logic verification.

[0112] The data structure of the synchronization data unit specifically includes the following three parts:

[0113] The data payload stores specific operational parameter values ​​or operating instructions. The content of the data payload varies depending on the business type, such as fuel refueling quantities, flight plan revision parameters, and performance calculation results.

[0114] The data source identifier (source_type) is used to distinguish whether the data originates from the aircraft's onboard interface (AIRCRAFT_BUS), external business system (EXTERNAL_SYSTEM), or manual input (USER_INPUT). This source identifier enables the receiving end to employ differentiated verification strategies for data from different sources; for example, performing bus protocol compliance verification on onboard interface data and business rule scope verification on manually input data.

[0115] The context snapshot section encapsulates a summary of the aircraft's operational status at the time the data was generated. This summary includes at least the aircraft's air / ground status (aircraft_on_ground), parking and braking status (parking_brake), and timestamp information. It may further include key onboard parameters from the decision-making end, such as FMS fuel level and GPS location (master_terminal_data).

[0116] The specific data structure of the SDU is shown in the following example: { "uuid": "evt_001", "timestamp": 1735689000, "source_type": "USER_INPUT", "payload": { "fuel_slip_value": 8000 }, "context_snapshot": { "aircraft_on_ground": true, "parking_brake": "SET", "master_terminal_data": { "fms_fuel": 7950 } } }

[0117] In the above structure, the context snapshot logically proves that the business data was generated under specific aircraft physical conditions. Taking fuel data as an example: when the co-pilot enters the fuel slip value (fuel_slip_value: 8000), the system simultaneously encapsulates the real-time FMS fuel quantity read by the decision-making end (fms_fuel: 7950). During verification, the receiving end can automatically compare whether the difference between the two is within a reasonable error range (e.g., ±200kg). If the difference exceeds the threshold, an alarm is triggered. Replacing traditional manual verbal verification with machine verification fundamentally improves the data consistency assurance capability.

[0118] When the second terminal inputs external business data, it requests the current airborne data snapshot from the first terminal through the collaborative network and merges the two to construct the SDU. The fusion process is executed by the data fusion engine and specifically includes: parsing the field format of the external business data, extracting core business parameters and filling them into the data payload; initiating a status snapshot request to the first terminal and filling the status snapshot part with the returned airborne status data; assigning a globally unique identifier (UUID) to the SDU and recording the generation timestamp.

[0119] Step S3': Generate chained, tamper-proof operation log nodes.

[0120] In airborne environments without a central node, traditional centralized log management solutions are not applicable. This invention draws on the chained hash structure of blockchain to build tamper-proof chained operation logs locally on each EFB terminal, ensuring the integrity and non-repudiation of operation records.

[0121] The anti-tampering principle of the chained operation log is based on the avalanche effect of one-way hash functions: the sequence fingerprint of each log node is determined not only by the data content of the current node, but also by the sequence fingerprint of the preceding node as input. Therefore, if an attacker attempts to tamper with any record in the historical log, the sequence fingerprint of that node will change, leading to a chain reaction of changes in the sequence fingerprints of all subsequent nodes, making the tampering attempt impossible to detect.

[0122] Specifically, step S3' includes the following sub-steps:

[0123] Step S3-1': Obtain the integrity check code of the previous valid log node in the local storage as the preceding fingerprint. For the first node in the log chain, the preceding fingerprint uses a preset genesis hash, which is determined during system initialization and stored in the terminal's secure storage area.

[0124] Step S3-2': Combine the preceding fingerprint, the current synchronized data unit, and the operator's digital signature to form a data segment to be hashed. The operator's digital signature is generated by signing the digest of the current synchronized data unit based on the operator's private key, and is used to prove the non-repudiation of the operator's identity.

[0125] Step S3-3': Calculate the unique sequence fingerprint of the current log node using the one-way hash algorithm (SHA-256). The one-way nature of the SHA-256 algorithm ensures that the original data cannot be deduced from the sequence fingerprint, and its 256-bit output length provides sufficient collision resistance under current computing power.

[0126] Step S3-4': Encapsulate the synchronization data unit, sequence fingerprint, and digital signature into a current operation log node and persistently store it in the local storage medium.

[0127] The chain structure ensures that any modification to the historical records will result in a hash avalanche verification failure. In practical auditing scenarios, the auditor only needs to recalculate the sequence fingerprint node by node from the head of the chain and compare it with the stored value to complete the integrity verification of the entire log in O(n) time complexity.

[0128] Step S4': Broadcast synchronization and multi-level validity verification.

[0129] The aforementioned log nodes are broadcast via a collaborative network. Upon receiving the broadcast chain of operation log nodes, the receiving terminal processor performs multi-level verification to ensure the legality and consistency of the data, specifically including:

[0130] Firstly, cryptographic verification of the continuity of the sequence fingerprint: The receiving end recalculates the sequence fingerprint of the received node and verifies whether it forms a correct chain relationship with the sequence fingerprint of the end node of the local log chain, so as to detect whether the data has been tampered with or lost during transmission.

[0131] Secondly, timestamp sequence verification: This verifies whether the timestamp of the received node is later than the timestamp of the latest local node, preventing replay attacks. It's important to note that in an airborne environment without centralized time synchronization, this sequence verification is based on the logical clock vector maintained by each terminal, rather than the physical clock. A logical clock vector is a data structure used in a distributed system to track causal relationships between events. Essentially, it's a vector with terminal identifiers as keys and local event counts as values. Whenever a terminal generates a new event, its corresponding count is incremented; whenever a terminal receives a message from another terminal, it merges its local vector with the vector carried in the message, taking the maximum value element by element. By comparing the logical clock vectors of two events, a causal relationship can be determined, thus achieving reliable event sequence determination even without physical clock synchronization.

[0132] Third, machine business logic verification based on aircraft operational status snapshots in the synchronous data unit: The receiving end extracts the status snapshot from the SDU and, combined with locally known aircraft status information, automatically verifies the rationality of the business data. For example, if the status snapshot shows the aircraft is in flight, but the business data is a ground refueling operation, it is determined to be a business logic anomaly and is rejected.

[0133] In terms of concurrent conflict handling, the system maintains logical clock vectors and crew role weight tables for each terminal. These crew role weight tables are pre-installed on each terminal, defining the operational priorities of different crew roles; for example, the captain (decision-making end) has a higher weight than the first officer (operation end). When the captain and first officer concurrently modify the same data item, the system automatically retains the operation result of the higher-weight role (captain / decision-making end) based on the weight table and sends a rollback command or conflict warning message to the terminal of the lower-weight role, forcibly rolling back the lower-weight operation. The rollback command is also broadcast in the form of chained log nodes, ensuring that the rollback operation itself is included in the tamper-proof audit log.

[0134] Step S5': Cross-end intent mapping collaborative execution based on "shadow instructions".

[0135] In traditional EFB (Electronic Flight Base) collaboration scenarios, after the co-pilot completes the business calculation, he needs to verbally inform the captain, who then repeats the input and confirmation on his own EFB. This process is redundant and prone to human error. This invention proposes a cross-terminal intent mapping mechanism based on "shadow instructions," which directly maps the co-pilot's operational intent to the captain's end in the form of structured data packets, achieving a closed-loop business process of "operator initiation—decision-making review—system atomic execution."

[0136] The core design concept of the "shadow command" is that the key control operations of the operator (co-pilot) do not directly modify the underlying data. Instead, they are intercepted and encapsulated into a shadow command data packet containing the complete operational intent and a snapshot of the aircraft's status, which is then synchronized to the decision-making end (captain) for review. The decision-making end recreates the operational request on a visual interface and performs a secondary verification based on the real-time aircraft status. Only after confirming that the aircraft's status has not undergone significant changes can the atomic writing of the underlying data be performed.

[0137] Taking the co-pilot's performance data calculation as an example, the specific execution process of step S5' is as follows:

[0138] Step S5-1': When the processor of the second terminal receives a critical control operation initiated by the user (such as clicking the "Application Performance Data" button), it intercepts the operation and directly modifies the local execution logic of the core data, generating a shadow instruction data packet containing the parameters of the instruction to be executed and a snapshot of the aircraft state at the time of initiation. The aircraft state snapshot encapsulated in the shadow instruction data packet has the same structure as the SDU state snapshot in step S2, ensuring the uniformity of the data format.

[0139] Step S5-2': Synchronize the shadow instruction data packet to the first terminal through the encrypted transmission channel of the cooperative domain.

[0140] Step S5-3': The processor of the first terminal receives and parses the shadow instruction data packet, and restores the operation request on its connected display interface as an independent overlay. The overlay is superimposed on the current interface as a semi-transparent overlay, clearly displaying the operation type to be confirmed, key parameter values, and a summary of the aircraft status at the time of operation initiation, enabling the captain to complete the review without switching interfaces. At this time, the data writing interface of the underlying system is in a hovering interception state to prevent any substantial data changes from occurring before the captain's confirmation.

[0141] Step S5-4': In response to the physical authorization input signal from the first terminal user (captain) (such as pressing a dedicated confirmation button), the first terminal processor re-verifies the parameter to be confirmed, specifically including:

[0142] Step S5-4-1': Extract the snapshot of the aircraft state when the operation terminal generates the instruction, which is encapsulated in the shadow instruction data packet.

[0143] Step S5-4-2': Obtain the current real-time aircraft status data of the first terminal. This data is directly read from the real-time bus of the airborne interface device to ensure the timeliness of the status data.

[0144] Step S5-4-3': Compare the aircraft status snapshot with the real-time aircraft status data to see if they are consistent. The comparison dimensions include, but are not limited to: aircraft air-to-ground status identifier, flight phase identifier, and the magnitude of change of key flight parameters (such as altitude and speed).

[0145] Step S5-4-4': If the difference between the two exceeds a preset threshold or the status identifiers do not match, the shadow instruction is determined to have expired, execution is refused, and an expiration notification is sent to the operator, prompting the operator to re-initiate the operation. If the verification passes, the first terminal calls the onboard underlying interface to complete the actual data writing in an atomic operation manner.

[0146] The term "atomic write" refers to a data write operation that either executes completely or not at all, without any intermediate state. In an EFB scenario, the implementation of atomic writes relies on the underlying database's transaction mechanism: the write operation is executed within a transaction, and if any exception occurs during the write process (such as storage failure or network interruption), the transaction automatically rolls back to the state before the write, ensuring data consistency. After a successful write, the first terminal broadcasts the execution result back to the second terminal and generates a corresponding chained operation log node, incorporating this authorized execution operation into the tamper-proof audit record.

[0147] Step S6': Post-flight anchoring procedures.

[0148] In response to the trigger signal indicating the end of the flight mission (such as a combination of air-to-ground switch and wheel chock signal), each EFB terminal ceases real-time synchronization service and enters the post-mission anchoring process.

[0149] Each terminal traverses its local log chain, using the sequence fingerprint of each chained operation log node as a leaf node to construct a Merkle Tree and calculate the root hash of the global operation log sequence. The Merkle Tree is constructed as follows: all leaf nodes are paired up, and the sequence fingerprints of each pair of leaf nodes are concatenated to calculate the SHA-256 hash, yielding the hash value of the parent node; this process is repeated layer by layer upwards until a unique root hash value is obtained. If the number of leaf nodes is odd, the last leaf node is paired with itself.

[0150] The Merkle root hash has the following characteristics: any change in the content of any log node will cause the root hash value to change; when the auditor verifies a specific log node, he only needs to provide the hash path (Merkle Proof) from that node to the root node to complete the verification in O(log n) time complexity, without having to traverse the entire log.

[0151] After multiple endpoints confirm the consistency, the root hash value is stored in a non-erasable storage medium (such as a dedicated write-only partition on the terminal or an onboard flight data recorder interface) as an anchor point for subsequent offline high-reliability auditing. The write operation to the non-erasable storage medium is controlled by the terminal hardware security module (HSM) to ensure that once the root hash value is written, it cannot be overwritten or deleted by software-level operations. Example 2

[0152] This embodiment is a further refinement of step S1 in embodiment 1, specifically illustrating the detailed process of establishing a local temporary trusted cooperative domain, including the following sub-steps:

[0153] S1.1: Obtain the flight mission identifier, crew role credentials, and pre-set crew shared key.

[0154] The flight mission identifier is a unique string that identifies this flight mission. For example, it is a combined identifier composed of the flight number and departure date (e.g., "CA1234-20240101"). This identifier is pre-installed in the configuration files of each terminal by the airline's operating system before the flight mission begins. The crew role credentials contain the identity identifiers of the captain and first officer and their corresponding crew role permission levels, used to determine the role assignments of each terminal after the collaborative domain is established. The crew shared key is a symmetric key pre-installed in all terminals for the same flight mission. It is only valid during the flight mission and automatically expires after the mission ends. Obtaining these three pieces of information is a prerequisite for establishing a mission-bound collaborative domain, ensuring the uniqueness of the collaborative domain and its mission-bound characteristics.

[0155] S1.2: Using the flight mission identifier as the salt value and the crew shared key as input, calculate using a cryptographic key derivation function to obtain the session key specific to this flight mission.

[0156] Cryptographic key derivation functions (such as PBKDF2) introduce the flight mission identifier as a salt value into the key derivation process. This ensures that even if two flight missions use the same crew-shared key, the derived session keys will be completely different, thus achieving task isolation of the session keys. The number of iterations of the derivation function can be configured according to the terminal processor performance, controlling computational overhead while ensuring key strength. The derived session key is only valid within the cooperative domain lifetime of the current flight mission and is automatically destroyed after the mission ends, preventing the reuse or leakage of historical keys.

[0157] S1.3: Based on the session key, an encrypted transmission channel is established between the first terminal and the second terminal through a wireless communication protocol to determine a local temporary trusted cooperative domain; among them, terminals that complete handshake verification only through the session key are allowed to join the cooperative domain.

[0158] The first terminal acts as the group master broadcast beacon, and the second terminal initiates a connection request. Both parties verify the consistency of their session keys by exchanging encrypted random numbers (nonces). The handshake protocol is implemented based on a secure transport protocol (such as TLS 1.3) and establishes an encrypted transmission channel between terminals through a short-range wireless communication protocol (such as Wi-Fi Direct). After a successful handshake, the first terminal is identified as the decision-making terminal with high privileges, and the second terminal as the operation terminal, based on the crew role credentials in the crew configuration file. Only terminals that can complete the handshake verification through the session key are allowed to join the collaborative domain, effectively preventing the access of unauthorized devices. This collaborative domain is completely independent of external public networks, ensuring stable operation in scenarios without public networks, such as transoceanic or polar flights. Example 3

[0159] This embodiment is a further explanation of the data structure of the synchronization data unit involved in step S2 of embodiment 1.

[0160] The synchronization data unit is the core data carrier for heterogeneous data fusion in this invention. Its standardized structural design enables heterogeneous data from different sources and with different formats to undergo machine verification and comparison within a unified framework. The synchronization data unit comprises the following three core components:

[0161] The data payload section stores operating parameter values ​​or operational commands. It is the core business content of the synchronous data unit and can contain real-time sensor values ​​acquired via the onboard bus (e.g., a fuel level sensor reading of 7950 kg), document values ​​issued by external business systems (e.g., a fuel level document reading of 8000 kg), or operational command parameters manually entered by the crew. The data payload section uses a key-value pair structured format for storage, facilitating parameter extraction and comparison at the receiving end.

[0162] The data source identification section identifies whether the data originates from an airborne interface, an external business system, or manual input. This section enables the receiving end to employ different verification strategies based on the trust level of the data source: data from the airborne interface has the highest trust level and can be directly used as the benchmark for business logic verification; data from external business systems needs to be cross-checked with airborne interface data; and data from manual input undergoes the most stringent multi-level verification. Through the data source identification section, the system can automatically identify the data source and apply corresponding verification rules, replacing the traditional manual verbal review process.

[0163] The state snapshot section encapsulates a summary of the aircraft's operational status at the time of data generation. This summary includes at least the aircraft's in-flight or ground status and a timestamp. The state snapshot section is a key mechanism for business logic verification in this invention: by binding and encapsulating the aircraft's physical state at the time of data generation (e.g., the aircraft is ground-based and parked, the stop brake is set, the flight management system fuel reading is 7950 kg, etc.) with the business data, the receiving end can verify whether the business data was generated under reasonable aircraft physical conditions. This logically proves the background of the business data's generation and effectively prevents the risk of executing erroneous operational commands during inappropriate flight phases. The timestamp information is used to support timing verification and prevent replay attacks. Example 4

[0164] This embodiment is a further refinement of step S3 in embodiment 1, specifically illustrating the generation process of the chained operation log node, such as... Figure 3 As shown, it includes the following sub-steps:

[0165] S3.1: Obtain the integrity check code of a valid operation log node in the local storage as a preceding fingerprint.

[0166] Before generating a new operation log node, the processor of each electronic flight bag terminal first reads the integrity check code of the most recent valid operation log node from the local storage medium and uses it as the pre-order fingerprint. The pre-order fingerprint is the core link of the chain structure. By embedding the hash value of the pre-order node into the computation input of the current node, any modification to any historical node in the chain will cause an avalanche change in the hash values ​​of all subsequent nodes starting from that node, thus making tampering impossible to conceal. For the first node in the chain, the pre-order fingerprint uses the pre-set genesis block hash value as the initial value.

[0167] S3.2: Combine the preceding fingerprint, the current synchronization data unit, and the operator's digital signature to output the data segment to be hashed.

[0168] The preceding fingerprint, the current synchronized data unit (including the data payload, data source identifier, and state snapshot), and the operator's digital signature are concatenated in a predetermined byte order to form a data segment to be hashed. The operator's digital signature is generated by signing the digest of the current synchronized data unit with the operator's private key, used to prove the operator's identity and prevent the operator from denying it afterward. The introduction of digital signatures makes the log chain not only tamper-proof but also non-repudiable, meeting the requirements of civil aviation audits for operational accountability.

[0169] S3.3: Calculate the sequence fingerprint of the current operation log node by using a one-way hash algorithm on the data segment to be hashed.

[0170] A one-way hash algorithm (such as SHA-256) is used to calculate the hash segment, generating a unique sequence fingerprint of the current operation log node with a fixed length (256 bits). The irreversibility of the one-way hash algorithm ensures that the original data content cannot be deduced from the sequence fingerprint, while its determinism ensures that the same input will always produce the same sequence fingerprint, allowing any receiving end to independently verify the correctness of the sequence fingerprint.

[0171] S3.4: Encapsulate the synchronization data unit, sequence fingerprint, and digital signature, and finally output them as chained operation log nodes.

[0172] The current synchronized data unit, the calculated sequence fingerprint, and the operator's digital signature are encapsulated into a complete chained operation log node according to a predetermined data structure and written to local storage media. The encapsulated chained operation log node contains complete business data, operator identity verification, and cryptographic association with the preceding node, serving as the basic data unit for subsequent broadcast synchronization, multi-level verification, and post-event auditing.

[0173] In another embodiment, based on Embodiment 1, an extended optimization scheme for generating chained operation logs is provided to address the cryptographic computation overhead problem and the security risks of an excessively large audit window in high-frequency operation scenarios.

[0174] In the scheme of Example 1, each operation log node needs to independently calculate and store the sequence fingerprint. During high-frequency operation phases of flight (such as takeoff, landing, and go-around), a large amount of cryptographic computation overhead is generated, putting continuous pressure on the processor resources of the EFB terminal. More importantly, if the global root digest is only written at the end of the flight, there is a large audit blind window throughout the entire flight: attackers can delete recent log records before the task ends and then forge the root digest to evade auditing. This embodiment fundamentally solves the above problems by introducing a memory rolling aggregate tag (RAT) mechanism and a flight phase-aware adaptive segmented checkpoint strategy.

[0175] Building and maintaining Scrolling Aggregator Tags (RATs):

[0176] After generating each chained operation log node, the log chain construction module of each terminal not only calculates the sequence fingerprint (Hash_Curr) of the current node, but also maintains a rolling aggregate label (RAT) in memory. The update rule of the RAT is as follows: the sequence fingerprint of the current node is merged with the RAT value of the previous round through the message authentication code (MAC) combinatorial operation to obtain a new RAT value.

[0177] The physical meaning of the RAT is that it is a cryptographic cumulative digest of all operation log nodes up to the current moment, which can reflect the current overall state of the log chain with a space complexity of O(1). Since the RAT is continuously maintained in memory instead of being written to disk one by one, the write amplification overhead during high-frequency operations is eliminated, and a persistent write operation is only performed when a checkpoint is triggered.

[0178] Adaptive segmented checkpoint strategy for flight phase perception:

[0179] The system adaptively triggers a checkpoint write strategy based on the operational density of each flight phase. The flight phase identifier is derived from the aircraft operational status information in the SDU status snapshot, and the system uses this information to divide the flight process into critical phases (takeoff taxiing, final approach, go-around, etc.) and non-critical phases (cruise, etc.).

[0180] When the system detects that the operation density exceeds a preset threshold (e.g., N operations occur within T consecutive seconds, where T and N can be configured according to aircraft characteristics, typically T=30 seconds and N=10 operations), or when the flight phase indicator switches to a critical phase, a checkpoint write operation is triggered: the current RAT value is encrypted using a dedicated key held by the Terminal Hardware Security Module (HSM) to obtain a Segmented Audit Anchor (SAA), and the SAA is written to an independent storage partition physically isolated from the operation log storage area. During non-critical flight phases, the system triggers checkpoint writes at a lower fixed frequency (e.g., once every 5 minutes) to achieve a balance between performance and security.

[0181] Protection against isolated partition storage and truncation attacks:

[0182] The SAA value is not stored in plaintext in the same storage partition as the log, but is written to an isolated partition with independent write permission control. The write permissions of the log storage area and the anchor storage area are forcibly isolated by the access control mechanism of the terminal operating system: the log storage area allows read and write access by the application layer, while the anchor storage area only allows writing through the HSM interface, and the application layer can only read.

[0183] This isolation design blocks the path of truncation attacks at the architectural level: even if an attacker gains write access at the application layer, they cannot modify or forge the SAA value in the anchor storage area; if an attacker attempts to hide traces of tampering by deleting recent logs and rolling back old anchors, such attacks cannot be carried out because write access to the anchor area is protected by the HSM.

[0184] Fine-grained audit positioning:

[0185] During post-flight audits, the auditors first perform segmented verification of the log chain through each SAA checkpoint: reconstructing the RAT value segment by segment and comparing it with the stored SAA. If a segment fails verification, the scope of tampering can be quickly located within that checkpoint interval without traversing the entire log, significantly improving audit efficiency.

[0186] The final global root digest calculation at the end of the flight constructs a Merkle tree with each SAA value as the leaf node, instead of using the original log nodes as leaf nodes. Since the number of SAAs is much smaller than the number of original log nodes (usually dozens of SAAs corresponding to thousands of log nodes), the computational cost of the root digest is significantly reduced, while the granularity of audit verification can still be accurate to each checkpoint interval.

[0187] Through the above mechanism, this embodiment reduces the cryptographic computation overhead during high-frequency operations to close to O(1) while maintaining the anti-tampering characteristics of chained logs, compresses the audit blind window from the entire flight cycle to a short interval between adjacent checkpoints, and eliminates the feasible path of truncation attacks at the architectural level, significantly improving the security and practicality of the EFB operation log system. Example 5

[0188] This embodiment further illustrates the concurrent conflict resolution mechanism involved in step S4 of embodiment 1, and specifically includes the following sub-steps:

[0189] S4.1: Maintain the logical clock vector and unit role weight table for each terminal.

[0190] The logical clock vector (Vector Clock) is maintained for each terminal, containing the logical clock counters of all online terminals. Whenever a terminal generates a new operation log node, its corresponding logical clock counter increments, and the current vector value is carried during broadcast. Upon receiving the broadcast, the receiving end merges its local vector with the received vector, taking the maximum value element-wise, thus establishing a partial order of operation events without centralized time synchronization. The crew role weight table records the weight values ​​of each terminal corresponding to its crew role. The decision-making end (captain) has a higher weight than the operating end (co-pilot). This weight table is initialized based on the crew configuration file when the collaborative domain is established and remains unchanged throughout the collaborative domain's lifecycle.

[0191] S4.2: When multiple terminals are detected to be concurrently modifying the same data item, the weights of the crew roles in the concurrent operations are compared based on the crew role weight table to determine the weight comparison result.

[0192] When the receiving processor verifies the received chained operation log nodes, it detects concurrent modifications to the same data item (identified by the key name in the data payload) by multiple terminals by comparing logical clock vectors (i.e., the logical clock vectors of the two operation nodes are not in any order), triggering the conflict resolution process. The system extracts the crew role weight value of the operator corresponding to each concurrent operation node from the crew role weight table, compares the values, and determines the weight comparison result, i.e., which party's operation has higher authority.

[0193] S4.3: Based on the weight comparison results, retain the operation results of roles with weights higher than the preset weight threshold, send rollback instructions to the terminals of roles with weights lower than the preset weight threshold, and update the local data status.

[0194] Based on the weighted comparison results, the system automatically retains the operation results of roles with weights higher than the preset weight threshold (usually the captain / decision-maker) as the final data state. It then sends a rollback command to the terminals of roles with weights lower than the preset weight threshold (usually the co-pilot / operators), requiring them to roll back their local data state to the state before the conflict occurred. Simultaneously, it can send a conflict alert to inform the operators of the specific details of the conflict. Through this mechanism, the system automatically resolves concurrent operation conflicts without manual intervention, ensuring the eventual consistency of data states across multiple terminals and demonstrating the authority of the crew role hierarchy in data decision-making.

[0195] In another embodiment, based on embodiment 1, this embodiment provides an extended optimization scheme for broadcast synchronization and consistency verification to solve the synchronization storm problem and the loss of legitimate operation data of low-weight terminals in scenarios of intermittent disconnection of wireless links between terminals.

[0196] Technical Problem Analysis:

[0197] In actual flight, intermittent disconnections occur in the Wi-Fi Direct channel between terminals (e.g., obstruction due to crew movement, equipment switching tasks, etc.). This causes multiple log nodes accumulated during network partitioning to need to be fully retransmitted after reconnection, creating a synchronization storm and impacting the limited airborne wireless channel bandwidth. Furthermore, the conflict resolution strategy in Implementation Example 1 performs rollback based on role weights. Legitimate operation history generated by the low-weight terminal (co-pilot) during network partitioning will be completely discarded, posing a risk of data loss and compromising the integrity of post-flight auditing.

[0198] Continuous maintenance of the lightweight state digest (SD):

[0199] Each terminal maintains a compact state digest structure (SD) locally, serving as a lightweight fingerprint of the current state of its local log chain. The SD consists of two core components:

[0200] Firstly, the Vector Version Tag (VVT) is a vector with the terminal identifier as the key and the number of locally confirmed log nodes as the value. For example, {Terminal_A: 128, Terminal_B: 115} indicates that terminal A has locally confirmed 128 log nodes, and terminal B has locally confirmed 115 log nodes. The VVT ​​accurately reflects the logging progress of each terminal, and the log fork point can be quickly determined by comparing the VVTs of the two ends.

[0201] Secondly, the set of confirmed log node UUIDs encoded by a Bloom filter. A Bloom filter is a highly space-efficient probabilistic data structure that can represent the membership of a large set with minimal storage space (typically O(k), where k is a constant on the order of the number of terminals), supporting efficient member lookup operations. Through a Bloom filter, the receiving end can quickly determine whether the log node UUIDs held by the receiving end already exist locally, thereby identifying the set of missing nodes that need to be retransmitted.

[0202] The storage and transmission overhead of the entire SD is on the order of O(k), which is much smaller than the transmission overhead of the full log, making it possible to downgrade state awareness from "full broadcast" to "summary probe".

[0203] Summary handshake and minimum synchronization difference calculation during reconnection:

[0204] After reconnecting to the cooperative domain, the terminals prioritize exchanging their respective SDs rather than immediately broadcasting the entire backlog of log nodes. The receiving terminal determines the log fork point (i.e., the position where the log chains at both ends begin to differ) by comparing the VVTs at both ends, and quickly identifies the set of UUIDs of nodes that the other party already holds but are missing locally by using a Bloom filter, thereby accurately calculating the Minimum Divergence Set (MDS).

[0205] The MDS contains only the incremental log nodes that actually need to be retransmitted, eliminating the redundant overhead of full retransmission. In typical short-term disconnection scenarios (such as disconnection duration of 30 seconds to 2 minutes), the size of the MDS is usually only a few to dozens of log nodes, and the occupation of wireless channel bandwidth is extremely limited.

[0206] Semantic-aware merging of incremental nodes:

[0207] For concurrent operation nodes that need to be merged identified in the MDS, this embodiment extends the conflict resolution mechanism of Embodiment 1 by introducing an operation semantic classification based on aircraft state snapshots:

[0208] Concurrent operation nodes are semantically categorized based on the aircraft state identifier in their context snapshots. If two concurrent operation nodes' context snapshots correspond to the same aircraft physical state (e.g., both occurred during the "ground parking" phase, both have "aircraft_on_ground" true, and the flight phase identifier is the same), then their operations are considered semantically compatible, and a Semantic-Preserving Merge (SPM) is performed: the result of the high-weight operation is retained as the final data state, while the low-weight operation node is appended to the log chain as an "audited historical intent," without triggering a rollback. This design ensures that the legitimate operation history of the low-weight node during network partitioning is fully preserved, providing a more complete operation trajectory for post-event auditing.

[0209] If the state snapshots of two concurrent operation nodes correspond to different aircraft physical states (e.g., the partitioning period spans takeoff, the operation at one end occurs in the ground state, and the operation at the other end occurs in the air state), then it is determined that there is a state semantic conflict, and the rollback strategy of Implementation Example 1 is executed: retain the operation result of the high-weight role, and send a rollback instruction to the terminal of the low-weight role.

[0210] Anti-partition segmentation confirmation mechanism:

[0211] For log segments that have been aligned via digest handshake, each terminal broadcasts a segment confirmation (SC) signal for that segment to the collaboration domain. Log segments that receive SCs from all online terminals are marked as "cross-terminal confirmed," allowing them to skip duplicate checks in subsequent audits and serving as the basis for VVT advancement, forming a closed loop of confirmation-digest update.

[0212] The introduction of the "cross-end confirmation state" eliminates the need for repeated verification of converged historical log segments during subsequent reconnections, significantly reducing the cumulative verification overhead in long-term operation scenarios and providing a stable starting point for incremental synchronization.

[0213] Through the above mechanism, this embodiment upgrades the multi-terminal synchronization status awareness from "full broadcast" to a two-stage protocol of "summary probe + incremental retransmission", compressing the amount of synchronization data to the minimum necessary set in the weak network reconnection scenario; at the same time, through the semantic awareness merging mechanism, the legitimate historical operation records of low-weight terminals are preserved to the maximum extent while ensuring the priority of high-weight decisions, thus solving the problem of low-weight operation data loss during concurrent partitioning in Embodiment 1. Example 6

[0214] This embodiment is a further refinement of the shadow instruction state consistency verification involved in step S5 of embodiment 1, such as... Figure 4 As shown, the specific steps include the following:

[0215] S5.1: Extract the aircraft status snapshot encapsulated in the shadow command data packet.

[0216] After receiving the shadow command data packet synchronized from the second terminal, the first terminal processor first extracts the aircraft state snapshot encapsulated by the operator when generating the shadow command from the data packet. This state snapshot records the aircraft's physical state at the time the command was initiated, including the aircraft's airborne or ground status indicators, braking status, and key parameters of the flight management system. The extraction of the state snapshot is the data foundation for subsequent state consistency verification, ensuring that the decision-making end can understand under what aircraft state the command was initiated by the operator.

[0217] S5.2: Obtain the current real-time aircraft status data of the first terminal.

[0218] The first terminal collects real-time aircraft operational status data through its connected airborne interface equipment, including various aircraft physical status parameters corresponding to those in the shadow command status snapshot. The real-time aircraft status data is collected at the moment the first terminal processor performs a status consistency check, ensuring the timeliness of the real-time status data used for the check.

[0219] S5.3: Compare the aircraft status snapshot with the real-time aircraft status data to obtain the status difference value.

[0220] The aircraft status snapshot extracted from the shadow command data packet is compared item by item with the current real-time aircraft status data, and the difference value of each status parameter is calculated. For numerical parameters (such as fuel quantity), the difference value is the absolute difference between the two; for enumerated parameters (such as air or ground status indicators), the difference value is determined by whether the status indicators match. The overall status difference value is obtained by combining the difference values ​​of all parameters, which is used to determine the timeliness of the shadow command.

[0221] S5.4: When the state difference value exceeds the preset state threshold or the state identifier does not match, it is determined that the shadow instruction data packet has expired and the data writing is refused; when the state difference value does not exceed the preset state threshold and the state identifier matches, the data writing is performed in response to the physical authorization input signal of the first terminal.

[0222] The preset state thresholds are configured according to the business sensitivity of different parameters. For example, the threshold for the fuel quantity parameter can be set to 100 kg, and the threshold for the air-to-ground status identifier is strict matching. When the state difference value exceeds the preset state threshold or the status identifier does not match, it indicates that the aircraft status has changed significantly from the time the shadow command is initiated by the operator to the time the decision-making terminal executes the verification. The execution premise of the shadow command is no longer valid. The system determines that the shadow command data packet has expired, refuses to execute the data writing, and sends an expiration notification to the second terminal, requiring the operator to re-initiate the operation under the current aircraft status. When the state difference value does not exceed the preset state threshold and the status identifier matches, the system waits for the physical authorization input signal (such as physical button confirmation) from the first terminal user (captain). In response to the physical authorization input signal, the system calls the airborne low-level interface to execute the corresponding atomic data writing and broadcasts the successful execution result back to the second terminal, completing the business loop of cross-terminal intent mapping.

[0223] In another embodiment, based on embodiment 1, this embodiment provides an extended optimization scheme for shadow command encapsulation and cross-end authorization execution to solve the problems of excessive latency in the shadow command authorization process and excessive cognitive burden on the captain during critical flight phases.

[0224] In the scheme of Implementation Example 1, the generation of shadow commands relies entirely on passive interception triggered by the user clicking "submit." The latency of the entire authorization process is equal to the sum of the latency of the entire chain: user input → interception and generation of shadow commands → synchronization to the decision-making end → UI pop-up on the decision-making end → physical confirmation by the captain. During critical operation-intensive flight phases (such as go-arounds and approaches), the timing of the UI pop-up in this process is unpredictable. The captain needs to temporarily interrupt their attention under high workload conditions to respond to the overlay layer, increasing the cognitive burden. This implementation introduces an active intent prediction and pre-generation mechanism upstream of the shadow command mechanism, upgrading the authorization collaboration process from "passive interception - synchronization" to "active prediction - advance preparation."

[0225] Construction of the multi-attribute operation context vector (OCV):

[0226] During user operations, the terminal continuously constructs and updates an Operation Context Vector (OCV). The OCV integrates the following multi-dimensional information: the current flight phase identifier (from a state snapshot, such as takeoff / cruise / approach), the type sequence of the last N steps of operation (N typically ranges from 5 to 10 steps), the current focus data field of the interface (i.e., the identifier of the data field that the user is currently editing), and the partial completion rate of the user input (e.g., the proportion of fields that have been filled out out of the total number of fields).

[0227] The OCV is maintained locally in real time on the operator side, without incurring cross-terminal communication overhead. Its physical significance lies in: by capturing the multi-dimensional contextual features of user operations, it provides sufficient input information for subsequent intent prediction, enabling the prediction model to comprehensively consider multiple dimensions such as flight phase, operation history, and current input state, rather than relying solely on a single feature for prediction.

[0228] Local inference for the lightweight intent prediction model (IPM):

[0229] The operator processor is based on OCV and runs a pre-built lightweight Intent Prediction Model (IPM). The IPM is constructed using a decision tree or shallow sequence model, with flight phase identifiers and operation sequence patterns as the main features, and outputs the confidence prediction distribution of various key control operations that the current user is about to initiate.

[0230] The IPM is designed with a lightweight principle: the number of model parameters is controlled within the range that the EFB terminal processor can infer in real time (inference latency not exceeding 50 milliseconds), ensuring that the intent prediction process does not affect the smoothness of user operation. The model is trained based on historical flight operation data, completed during the ground maintenance phase, and deployed to the terminal offline, requiring no network update.

[0231] When the prediction confidence of a certain operation intention exceeds the preset activation threshold (the default value is 0.85, which can be adjusted according to the aircraft type and route characteristics), IPM triggers the pre-generation process: the operator generates a pre-filled shadow draft (PSD) in advance based on the current interface state and the input parameters. Its parameter values ​​are completed based on the existing inputs and the current aircraft state snapshot is encapsulated.

[0232] Early synchronization of PSD and pre-decision preparation:

[0233] Before the user actually completes the "submit" operation, the operating terminal synchronizes the PSD to the decision-making terminal in advance, along with the confidence value and prediction trigger flag. After receiving the PSD, the decision-making terminal processor performs a pre-validation of the legality of the aircraft status snapshot in the background (i.e., the status comparison logic in step S5-4), but does not pop up the visual overlay layer. It only places the PSD that passes the pre-validation into the Pending Activation Queue (PAQ).

[0234] Simultaneously, the decision-making system sends a low-interference warning signal to the captain (such as a slight flicker at the edge of the screen or a change in the status bar icon), allowing the captain to anticipate the upcoming authorization request rather than be interrupted by a sudden pop-up. The low-interference warning signal is designed according to aviation ergonomic principles: the signal strength is sufficient to attract the captain's attention but not enough to interrupt their current primary operational tasks, thus reducing the cost of cognitive interruption while maintaining the timeliness of the authorization response.

[0235] Quick authorization path when a user submits an application:

[0236] When a user actually triggers a commit operation, the system checks if a PSD matching the current commit exists in the PAQ (by matching the operation type and parameter key name):

[0237] If the command is successful, the shadow command does not need to be regenerated and resynchronized. The decision-making end directly activates the pre-validated PSD in PAQ and pops up the overlay layer. The captain only needs to confirm the final parameter values ​​and complete the physical authorization. The overall process latency is compressed from the original four-stage "generation + synchronization + display + authorization" to the two-stage "display + authorization". Under typical network conditions, the total authorization latency can be reduced by 60% to 80%.

[0238] If the prediction is not accurate (intentional prediction deviation), the system reverts to the complete shadow instruction flow of Implementation Example 1 to ensure the completeness of the fallback mechanism in case of prediction inaccuracy and to ensure that the reliability of the authorization mechanism is not affected by the prediction accuracy.

[0239] Adaptive threshold adjustment for prediction confidence:

[0240] The system records the IPM's prediction hit rate (the proportion of PSDs that are actually hit and successfully activated) for each flight mission and stores this statistical data locally after the flight ends. On the next takeoff, the IPM dynamically adjusts the activation thresholds for each operation type based on historical hit rates: operation types with high hit rates (such as performance data application operations during the approach phase) have their activation thresholds lowered for more aggressive pre-generation; operation types with low hit rates have their thresholds raised to reduce invalid pre-generation and avoid unnecessary cross-end communication overhead.

[0241] The adaptive threshold adjustment mechanism enables the intent prediction system to continuously optimize over time, achieving personalized adaptation to crew operating habits. Since the adjustment is based on local historical data, no network training or external model updates are required, fully adapting to the constraints of an airborne, decentralized network environment.

[0242] Through the above mechanism, this embodiment significantly reduces the total authorization delay of critical control operations without changing the security of the shadow command authorization closed loop. It replaces sudden pop-ups with low-interference warning signals, reduces the captain's cognitive interruption cost during high-workload flight phases, and achieves continuous optimization of intent prediction capability through an adaptive learning mechanism, providing an important guarantee for the practicality of the airborne EFB cooperative system during critical flight phases. Example 7

[0243] This embodiment is an extension of embodiment 1. After obtaining the chained operation log nodes in step S3, it also includes step S7: introducing a segmented audit anchor mechanism to solve the problems of cryptographic computation overhead during high-frequency operations and the security blind spot problem of excessively large audit windows. S7 specifically includes the following sub-steps:

[0244] S7.1: After generating each chain operation log node, extract the sequence fingerprint of the current node, and merge the sequence fingerprint with the previous round of rolling aggregation tag value maintained in memory through message authentication code combination operation to obtain the updated rolling aggregation tag value.

[0245] During high-frequency flight operations (such as takeoff, landing, and go-around), performing independent encrypted write operations to disk for each operation log node would generate significant cryptographic computation overhead, impacting the terminal's real-time response performance. To address this, this invention introduces a rolling aggregate tag (RAT) mechanism in memory: after generating each chained operation log node, the sequence fingerprint of the current node is extracted and merged with the previous round's rolling aggregate tag value maintained in memory using a message authentication code (MAC) combinatorial operation. This continuously accumulates updated rolling aggregate tag values ​​in memory, without writing each node to disk individually. This aggregates the individual cryptographic computations during high-frequency operations into periodic operations, eliminating write amplification overhead.

[0246] S7.2: Obtain the current operation density and flight stage identifier. When the operation density exceeds the preset density threshold or the flight stage identifier is a critical flight stage, encrypt the current scrolling aggregation tag value to obtain the segmented audit anchor value.

[0247] The system continuously monitors the current operation density (the number of operation log nodes generated per unit time) and flight phase identifiers (flight phase information from status snapshots, such as takeoff taxiing, final approach, and other critical flight phase identifiers). When the operation density exceeds a preset density threshold (e.g., N operation log nodes are generated consecutively within T seconds) or the flight phase identifier indicates a critical flight phase, a checkpoint write-to-disk strategy is triggered. The rolling aggregated tag value in current memory is encrypted to obtain segmented audit anchor values. During non-critical flight phases and when the operation density does not exceed the threshold, encrypted write-to-disk operations are triggered at a lower predetermined frequency, balancing performance and security. Through a flight phase-aware adaptive segmented checkpoint strategy, the anchor density is automatically increased during critical flight phases, effectively reducing the tamper detection window.

[0248] The encryption process is performed by the terminal hardware security module (HSM). A dedicated key held by the hardware security module (stored internally and not directly readable by the software layer) is used to encrypt the current scrolling aggregation tag value, resulting in the encrypted segmented audit anchor value. The use of the hardware security module ensures the physical security of the encryption key. Even if the terminal software layer is compromised, attackers cannot obtain the dedicated key to forge the segmented audit anchor value, thus guaranteeing the unforgeability of the segmented audit anchor.

[0249] S7.3: Write the segmented audit anchor point value to an independent storage partition isolated from the operation log storage area. The independent storage partition uses different write permissions for access control than the operation log storage area, thus obtaining the segmented audit anchor point in isolated storage.

[0250] The segmented audit anchor values ​​are not stored in plaintext in the same storage partition as the logs. Instead, they are written to a separate storage partition (such as an endpoint hardware security module or a non-erasable partition) with independent write permissions, which is isolated from the operation log storage area. The log area and anchor area use different write permission isolations to prevent attackers from hiding tampering traces by deleting recent logs and rolling back old anchors. This blocks and cuts off attack paths at the architectural level, resolving the security blind spot of an excessively large audit window in the original solution.

[0251] S7.4: Perform segmented reconstruction and verification of the segmented audit anchor points, and use the value of each segmented audit anchor point as a leaf node to calculate the root digest value, so as to store the root digest value in a non-erasable storage medium.

[0252] During post-flight auditing, the auditors first read the audit anchor values ​​for each segment from the independent storage partition. They then reconstruct the rolling aggregate tag values ​​segment by segment for each chained operation log node within each segment interval. The reconstructed rolling aggregate tag values ​​are compared with the corresponding stored segment audit anchor values ​​to obtain segment-by-segment verification results. If a segment verification result does not match, the tampering range is quickly located within that checkpoint interval without traversing the entire log, significantly improving audit efficiency. Finally, each segment audit anchor value is used as a leaf node, and a Merkle tree root digest is calculated for all leaf nodes to obtain the root digest value, further reducing the computational load of the root digest. Example 8

[0253] This embodiment is a further refinement of step S7.4 in embodiment 7, specifically illustrating the implementation method of segment-by-segment reconstruction verification and Merkle root summary calculation, including the following sub-steps:

[0254] S7.4.1: Read the audit anchor value of each segment from the independent storage partition, reconstruct the rolling aggregation tag value segment by segment for the chained operation log nodes in each segment interval, compare the reconstructed rolling aggregation tag value with the corresponding segment audit anchor value of the storage, and obtain the segment verification result.

[0255] The auditor reads all segmented audit anchor values ​​from independent storage partitions. Following the chronological order of the segmented intervals, the auditor reconstructs the rolling aggregate tag value step-by-step for each segmented interval's chained operation log node using the same message authentication code combination sub-operation logic as when it was generated. The reconstructed rolling aggregate tag value is then compared with the corresponding stored segmented audit anchor value to obtain the segment-by-segment verification result (match or non-match) for each segmented interval. This segment-by-segment verification method allows for parallel processing of the audit process, significantly improving audit efficiency.

[0256] S7.4.2: When the segment-by-segment verification results do not match, the tampering range is located to the corresponding segment interval to obtain the tampering location result.

[0257] When the segment-by-segment verification results for a certain segment interval do not match, it indicates that a tampered operation log node exists within that segment interval. The system precisely locates the tampering range to that checkpoint interval, obtaining the tampering location result. The auditor can then further verify each operation log node within that interval using a hash chain-by-hash chain to accurately locate the specific tampered node, without needing to traverse the entire log, significantly improving auditing efficiency.

[0258] S7.4.3: Use the audit anchor value of each segment as a leaf node, and perform Merkle tree root summary calculation on all leaf nodes to obtain the root summary value.

[0259] All segmented audit anchor values ​​are used as leaf nodes of the Merkle tree. A root digest is calculated using the standard Merkle tree construction algorithm (which combines the hash values ​​of adjacent leaf nodes pairwise, calculating upwards layer by layer until the root node hash value is obtained). This yields the root digest value representing the integrity of the entire operation record for this flight mission. By using segmented audit anchor values ​​as leaf nodes instead of the original operation log nodes, the size of the Merkle tree and the computational cost of the root digest are significantly reduced, while maintaining the cryptographic connection to the full log chain. Example 9

[0260] This embodiment is an extension of embodiment 1. After broadcasting the chained operation log nodes through the cooperative domain in step S4 and before updating the local data status based on the verification result, it also includes step S8: introducing a weak network self-healing consistency protocol based on digest-driven incremental synchronization to solve the synchronization storm problem caused by intermittent disconnection of wireless links between terminals. S8 specifically includes the following sub-steps:

[0261] S8.1: Maintain a status summary locally on each terminal. The status summary includes a vector version number of the current status of the local operation log chain and a Bloom filter encoding of the set of confirmed operation log node identifiers.

[0262] Each terminal maintains a compact state digest structure locally. Its core components include: a Vector Version Tag (VVT), which maintains a logical clock counter for each online terminal, recording the latest confirmed operation log node sequence number for each terminal. The storage and transmission overhead of the entire vector version tag is O(k) (where k is the number of terminals), far less than the full log; and Bloom filter encoding, which encodes the unique identifier set of locally confirmed operation log nodes using a Bloom filter. This allows for rapid determination of whether an operation log node identifier is already held locally with extremely low storage overhead, and the false positive rate can be controlled within an acceptable range by configuring Bloom filter parameters. The lightweight nature of the state digest reduces the synchronization state awareness between terminals from full broadcast to digest probes, fundamentally eliminating synchronization storms during weak network reconnection.

[0263] S8.2: When a terminal reconnects to the cooperative domain, it exchanges its own state summary with each terminal, determines the log fork point by comparing the vector version numbers of each terminal, and identifies the set of operation log node identifiers that the peer has held but the local terminal lacks by using Bloom filter encoding, thus obtaining the minimum synchronization difference set.

[0264] After reconnecting to the collaborative domain, the terminals prioritize exchanging their respective state summaries rather than immediately broadcasting the full backlog of log nodes. The receiving terminal determines the log fork point (i.e., the location where the operation log chains at both ends begin to diverge) by comparing the components of the vector version numbers at both ends; through Bloom filter encoding, it quickly identifies the set of operation log node identifiers that the peer already holds but are missing locally, thereby accurately calculating the Minimum Divergence Set (MDS), requesting only the truly missing incremental nodes, eliminating the overhead of full retransmission, and effectively solving the synchronization storm problem in weak network reconnection scenarios.

[0265] S8.3: Based on the minimum synchronization difference set, request and transmit the missing incremental operation log nodes from the peer to obtain the incremental synchronization result, and update the local data status based on the incremental synchronization result.

[0266] Based on the missing operation log nodes identified by the minimum synchronization difference set, a precise incremental node request is initiated to the peer. The peer only transmits the truly missing incremental operation log nodes, thus obtaining the incremental synchronization result. The receiving end performs the same multi-level verification (sequence fingerprint continuity verification, timing verification, and business logic verification) on the incremental operation log nodes as in normal broadcast reception. After the verification passes, the incremental node is appended to the local operation log chain, and the local data status is updated based on the incremental synchronization result, completing the efficient completion of backlog operations during weak network disconnection.

[0267] S8.4: For concurrent operation nodes in the incremental operation log node, extract the aircraft status identifier from the status snapshot of each node for semantic classification. When the aircraft status identifiers of concurrent nodes are the same, retain the operation results with a weight higher than the preset weight threshold and append the operation node with a weight lower than the preset weight threshold to the operation log chain. When the aircraft status identifiers of concurrent nodes are different, retain the operation results of the role with a weight higher than the preset weight threshold and send a rollback instruction to the terminal of the role with a weight lower than the preset weight threshold.

[0268] For concurrent operation nodes identified as needing to be merged based on the minimum synchronization difference set, the aircraft status identifier in the state snapshot of each node is extracted for semantic classification: If the state snapshots of two concurrent operation nodes correspond to the same aircraft physical state (e.g., both occurred during the ground parking phase), then the operation semantics of the two nodes are considered compatible, and semantic preservation merging is performed. The operation result of the higher-weight role is retained as the final data state, and the operation node of the lower-weight role is appended to the operation log chain as an audited historical intent without triggering rollback, thus preserving the legitimate historical operation records of the lower-weight end to the maximum extent; If the state snapshots correspond to different aircraft physical states (e.g., the partition spans takeoff), then a state semantic conflict is determined, the operation result of the higher-weight role is retained, a rollback instruction is sent to the terminal of the lower-weight role, and the original rollback strategy is executed.

[0269] S8.5: For operation log segments that have completed digest handshake alignment, broadcast the segmentation acknowledgment signal of the log segment to the cooperative domain, mark the operation log segments that have received segmentation acknowledgment signals from all online terminals as cross-end acknowledgment states, and update the local vector version number of each terminal with the state digest of the cross-end acknowledgment state log segment.

[0270] For operation log segments that have been aligned via digest handshake, each terminal broadcasts a segment acknowledgment signal for that segment to the collaboration domain. Operation log segments receiving segment acknowledgment signals from all online terminals are marked as cross-terminal acknowledgment segments, allowing them to skip duplicate checks during subsequent audits. The state digest of the cross-terminal acknowledgment segment is used to update the local vector version number of each terminal, forming a closed loop of acknowledgment and digest updates. This provides a stable base point for subsequent incremental synchronization and avoids recalculating historically converged regions after reconnection. Example 10

[0271] This embodiment is a further refinement of step S8.4 in embodiment 9, specifically illustrating the implementation method of semantic classification and merging of concurrent operation nodes, including the following sub-steps:

[0272] S8.4.1: Extract the state snapshots of each concurrent operation node in the minimum synchronization difference set, and obtain the aircraft state identifier in the state snapshots.

[0273] From the concurrent operation nodes identified in the minimum synchronization difference set, the state snapshot portion of the synchronization data unit of each node is extracted one by one to obtain the aircraft state identifier. The aircraft state identifier is an enumerated field containing the aircraft's airborne or ground state (such as ground parking, takeoff taxiing, air cruise, final approach, etc.). This identifier is collected in real time by the airborne interface device of the first terminal and embedded in the state snapshot when generating the synchronization data unit. The accuracy of the aircraft state identifier is the basis for subsequent semantic classification, ensuring that the semantic judgment of concurrent operations is based on the objective physical state of the aircraft rather than subjective inference.

[0274] S8.4.2: Compare the aircraft status identifiers of each concurrent operation node one by one. When the aircraft status identifiers of two concurrent nodes correspond to the same aircraft physical state, they are classified as semantically compatible concurrency and semantically preserved merging is performed: the operation result of the role with higher weight is retained as the final data state, and the operation node of the role with lower weight is added to the operation log chain as an audited historical operation record to obtain the merged operation log chain.

[0275] The aircraft status identifiers of each concurrent operation node are compared one by one: when the aircraft status identifiers of two concurrent nodes correspond to the same aircraft physical state, it means that the two operations occurred in the same aircraft operation phase, and their operation semantics are physically compatible, thus classifying them as semantically compatible concurrency. For semantically compatible concurrency, a semantic preservation and merging strategy is implemented: the operation results of the higher-weight role (such as the captain) are retained as the final data state, and the operation nodes of the lower-weight role (such as the co-pilot) are appended to the operation log chain in read-only mode, marked as audited historical operation records, without triggering rollback instructions. This maximizes the retention of legitimate historical operation records of the lower-weight end while ensuring the priority of high-weight decisions, solving the problem of low-weight operation data loss during concurrent partitioning in the original solution, and obtaining the merged operation log chain.

[0276] S8.4.3: When the aircraft status identifiers of two concurrent nodes correspond to different aircraft physical states, they are classified as semantic conflict concurrency. The operation result of the higher-weight role is retained, and a rollback instruction is sent to the terminal of the lower-weight role to obtain the local data state after the conflict is resolved.

[0277] When the aircraft state identifiers of two concurrent nodes correspond to different aircraft physical states (e.g., one operation occurs during the ground parking phase, and the other occurs during the air phase after takeoff, indicating that the network partition spans flight phase transitions), the semantic premises of the two operations are fundamentally different, and this is classified as semantic conflict concurrency. For semantic conflict concurrency, the original rollback strategy is executed: the operation result of the higher-weighted role is retained as the final data state, and a rollback instruction is sent to the terminal of the lower-weighted role, requiring it to roll back its local data state to the state before the conflict occurred, obtaining the local data state after the conflict is resolved. This ensures that cross-flight phase operation conflicts do not lead to semantic errors in the data state. Example 11

[0278] This embodiment is an extension of Embodiment 1. After encapsulating the shadow command data packet and synchronizing it to the first terminal in step S5, it also includes step S9: introducing an active shadow command pre-generation mechanism based on multi-attribute intent prediction to solve the problems of excessive delay in the authorization process and excessive cognitive burden on the captain during critical operation-intensive flight phases. S9 specifically includes the following sub-steps:

[0279] S9.1: During user operation on the second terminal, continuously collect the current flight phase identifier, recent operation type sequence, current interface focus data field, and user input completion rate, and fuse them to obtain the operation context vector.

[0280] During user operations, the terminal continuously constructs and updates the Operation Context Vector (OCV). This vector integrates the following multi-dimensional information: the current flight phase identifier (takeoff, cruise, approach, etc., from a state snapshot), reflecting the current flight mission phase, with different high-frequency operation types corresponding to different flight phases; the type sequence of the most recent N steps of operations (e.g., the type identifier sequence of the most recent 5 steps of operations), capturing the operator's operating habits and workflow patterns; the current focus data field of the interface (the identifier of the data field currently being edited or viewed by the user), reflecting the operator's current focus; and the user input completion rate (the proportion of filled fields to the total number of fields), reflecting the operator's progress towards submitting the operation. The Operation Context Vector is maintained locally in real time, without incurring cross-terminal communication overhead, providing multi-dimensional contextual information for subsequent intent prediction.

[0281] S9.2: Infer the pre-set operation intent classification model based on the operation context vector input to obtain the confidence prediction distribution of each key control operation intent; when the confidence of an operation intent exceeds the preset activation threshold, pre-filled shadow instruction drafts are generated based on the currently input parameters and the aircraft status snapshot.

[0282] The operator processor runs a pre-built lightweight Intent Prediction Model (IPM) based on the operation context vector. The IPM is constructed using a decision tree or shallow sequence model, with flight phases and operation sequence patterns as the main features, outputting a confidence prediction distribution of various key control operations that the current user is about to initiate. When the predicted confidence of a certain operation intent exceeds a preset activation threshold (e.g., 0.85), a pre-generation process is triggered: the operator generates a pre-filled shadow draft (PSD) based on the current interface state and input parameters. The parameter values ​​are completed based on existing inputs, and a snapshot of the current aircraft state is encapsulated. The pre-generation of the pre-filled shadow draft upgrades the authorization coordination process from passive interception and synchronization to proactive prediction and advance preparation, reducing the total authorization delay for key control operations at the system architecture level.

[0283] S9.3: The pre-filled shadow command draft and its confidence value are synchronized to the first terminal in advance. The first terminal performs a state consistency pre-verification on the aircraft state snapshot in the pre-filled shadow command draft, places the pre-filled shadow command draft that passes the pre-verification in the activation queue, and sends a warning signal to the first terminal user.

[0284] Before the user actually submits the command, the operating system synchronizes the pre-filled shadow command draft and its confidence value to the decision-making system, along with a prediction trigger flag. Upon receiving the pre-filled shadow command draft, the decision-making processor performs a pre-validation of the aircraft status snapshot's legality in the background (i.e., executes the same status comparison logic as steps S5.1 to S5.3), but does not display a visual overlay layer; instead, it places the pre-validated shadow command draft in the PendingActivation Queue (PAQ). Simultaneously, the decision-making system sends a low-interference warning signal to the captain (e.g., a slight flicker at the screen edge), allowing the captain to anticipate the upcoming authorization request rather than be suddenly interrupted, effectively reducing the captain's cognitive interruption cost during high-workload flight phases.

[0285] S9.4: When the second terminal user actually triggers a key control operation, the pre-filled shadow instruction draft in the queue to be activated is matched with the type and parameter key name of this operation. When a match is found, the pre-filled shadow instruction draft that has completed pre-verification in the queue to be activated is directly activated to obtain the shadow instruction data packet. The first terminal responds to the physical authorization input signal to perform data writing. When a match is not found, the shadow instruction data packet is re-encapsulated and synchronized to the first terminal.

[0286] When a user actually triggers a submission, the system checks if there is a pre-filled shadow instruction draft that matches the current submission in the queue to be activated (by comparing the operation type with the parameter key name): If a match is found, the shadow instruction does not need to be regenerated and resynchronized. The decision-maker directly activates the pre-filled shadow instruction draft that has completed pre-verification in the queue to be activated as the shadow instruction data packet, and a visual overlay layer pops up. The captain only needs to confirm the final parameter value and complete the physical authorization. The overall process latency is shortened to only the physical authorization stage. If a match is not found (intent prediction deviation), the system reverts to the complete shadow instruction process of the original plan to ensure the integrity of the backup and ensure that the system can still work normally when intent prediction fails.

[0287] S9.5: Record the prediction hit rate of the operation intent classification model in each flight mission, and dynamically adjust the preset activation threshold of each operation type based on the prediction hit rate to obtain the updated activation threshold.

[0288] The system records the prediction hit rate (the proportion of pre-filled shadow command drafts that are actually hit and successfully activated) of the operation intent classification model in each flight mission, and stores this statistical data locally after the flight ends. On the next takeoff, the operation intent classification model dynamically adjusts the activation threshold for each operation type based on the historical hit rate: operation types with high hit rates have their activation thresholds lowered to encourage more aggressive pre-generation, while operation types with low hit rates have their thresholds raised to reduce invalid pre-generation, forming an adaptive learning loop. This allows the intent prediction system to continuously optimize with usage, achieving personalized adaptation to crew operating habits without requiring network training or external model updates. Example 12

[0289] This embodiment provides a collaborative device for heterogeneous data fusion and intent mapping of electronic flight bags, such as... Figure 5 As shown, the various software functional modules within the device are implemented by the processor executing preset computer program instructions stored in the memory, specifically including:

[0290] The Trusted Collaboration Module is used to obtain the flight mission identifier and crew role credentials, perform key derivation and handshake authentication on the flight mission identifier and crew role credentials, and establish a local temporary trusted collaboration domain between the first terminal and the second terminal. The first terminal is the decision-making end, and the second terminal is the operation end. The Trusted Collaboration Module is configured in the underlying communication services of each terminal, executing a cryptographic key derivation function and handshake protocol. Based on the flight mission identifier, it establishes a temporary trusted collaboration domain encrypted with a secure transmission protocol between multiple terminals, ensuring that the collaboration domain is completely independent of external public networks, thus achieving stable communication during critical phases of flights such as transoceanic flights.

[0291] The synchronization data module is used to collect airborne operational data using a first terminal and external business operational data using a second terminal. It then performs format conversion and embeds status snapshots into the airborne and external operational data to obtain synchronization data units. As a data processing middleware, the synchronization data module collects real-time data from the airborne interface and externally entered business data, embeds current airborne status snapshots into the business data, and encapsulates and outputs standardized synchronization data units. This eliminates heterogeneous data silos by replacing traditional manual verbal verification with machine logic verification.

[0292] The one-way hash calculation module performs a one-way hash calculation on the integrity check code of the previous operation log node in the local memory, the current synchronization data unit, and the operator's digital signature to obtain a sequence fingerprint. It then encapsulates the synchronization data unit, the sequence fingerprint, and the operator's digital signature to obtain a chained operation log node. Coupled with the local database, the one-way hash calculation module invokes a one-way hash algorithm (such as SHA-256) each time a data update event is triggered. This algorithm binds the previous fingerprint with the current data signature to generate a tamper-proof chained log node, ensuring the absolute temporal order and immutability of the operation records.

[0293] The verification module broadcasts chained operation log nodes to other terminals through the collaborative domain. It performs sequence fingerprint continuity verification, timing verification, and business logic verification on the received chained operation log nodes, obtains the verification results, and updates the local data status based on these results. The verification module is responsible for network broadcasting and message listening within the collaborative domain. It has a built-in concurrent conflict arbitrator. After verifying the log sequence continuity and unit role weights, it performs a secure update or rollback of the local data status to ensure data consistency among multiple terminals.

[0294] The interception module responds to critical control operations from the second terminal by intercepting the local execution of these operations. It encapsulates a shadow command data packet containing parameters of the instruction to be executed and a snapshot of the aircraft's status, and synchronizes it to the first terminal. The first terminal performs a status consistency check on the shadow command data packet; if the check passes, the data is written. Deployed between the human-machine interface and the underlying data interface, the interception module intercepts click actions and packages shadow commands at the operator's end. At the decision-making end, it generates an independent overlay layer and performs a status snapshot comparison. After successful verification, it drives the underlying system interface to perform atomic data writing, thus achieving a closed-loop business process: operator initiation, decision-making review, and system atomic execution.

[0295] The storage module, in response to the flight mission end signal, calculates the root digest value of the chained operation log node sequence and stores it in a non-erasable storage medium. Upon triggering the flight mission end signal, each terminal stops real-time synchronization, traverses the local log chain to calculate the root digest value of the global operation log sequence, and stores it in a non-erasable storage medium. This serves as an anchor point for post-event offline high-reliability auditing, fully meeting the highest level of compliance auditing requirements of civil aviation.

[0296] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A collaborative method for heterogeneous data fusion and intent mapping of electronic flight bags, characterized in that, The method is applied to multiple electronic flight bag terminals under the same flight mission, including: Obtain the flight mission identifier and crew role credentials, perform key derivation and handshake authentication on the flight mission identifier and crew role credentials, and establish a local temporary trusted collaborative domain between the first terminal and the second terminal, wherein the first terminal is the decision-making end and the second terminal is the operation end; The first terminal is used to collect airborne operation data, and the second terminal is used to collect external service operation data. The airborne operation data and the external service operation data are then converted in format and embedded with status snapshots to obtain a synchronized data unit. A sequence fingerprint is obtained by performing a one-way hash calculation on the integrity check code of the previous operation log node in the local memory, the current synchronization data unit, and the operator's digital signature. The synchronization data unit, the sequence fingerprint, and the operator's digital signature are then encapsulated to obtain a chained operation log node. The chained operation log nodes are broadcast to other terminals through the local temporary trusted collaboration domain. The received chained operation log nodes are subjected to sequence fingerprint continuity verification, time sequence verification, and business logic verification to obtain the verification results. The local data status is updated based on the verification results. In response to a critical control operation of the second terminal, the local execution of the critical control operation is intercepted, a shadow command data packet containing the parameters of the command to be executed and a snapshot of the aircraft status is encapsulated and synchronized to the first terminal. The first terminal performs a status consistency check on the shadow command data packet, and executes data writing after the check passes. In response to the flight mission end signal, a root digest is calculated for the chained operation log node sequence to obtain a root digest value, and the root digest value is stored in a non-erasable storage medium.

2. The method according to claim 1, characterized in that, Obtain the flight mission identifier and crew role credentials, perform key derivation and handshake authentication on the flight mission identifier and crew role credentials, and establish a local temporary trusted collaboration domain between the first terminal and the second terminal, including: Obtain the flight mission identifier, the crew role credentials, and the pre-set crew shared key; Using the flight mission identifier as the salt value and the crew shared key as input, a session key specific to this flight mission is obtained by using a cryptographic key derivation function. Based on the session key, an encrypted transmission channel is established between the first terminal and the second terminal through a wireless communication protocol to determine the local temporary trusted cooperative domain; wherein, only terminals that complete handshake verification through the session key are allowed to join the cooperative domain.

3. The method according to claim 1, characterized in that, The synchronization data unit includes: The data payload section is used to store operating parameter values ​​or operation instructions; The data source identifier section is used to identify whether the data source is an airborne interface, an external business system, or manual input. The status snapshot section is used to encapsulate a summary of the aircraft's operational status at the time the data was generated. The status summary includes at least the aircraft's air or ground status and timestamp information.

4. The method according to claim 1, characterized in that, A sequence fingerprint is obtained by performing a one-way hash calculation on the integrity check code of the previous operation log node in the local memory, the current synchronization data unit, and the operator's digital signature. The synchronization data unit, the sequence fingerprint, and the operator's digital signature are then encapsulated to obtain a chained operation log node, including: Obtain the integrity check code of a valid operation log node in the local storage as a preceding fingerprint; The preceding fingerprint, the current synchronization data unit, and the operator's digital signature are combined to output a data segment to be hashed. The sequence fingerprint of the current operation log node is obtained by calculating the sequence fingerprint of the data segment to be hashed using a one-way hash algorithm. The synchronization data unit, the sequence fingerprint, and the operator's digital signature are encapsulated and finally output as the chained operation log node.

5. The method according to claim 1, characterized in that, The step of updating the local data status based on the verification result includes: Maintain the logical clock vector and unit role weight table for each terminal; When multiple terminals are detected to be concurrently modifying the same data item, the weights of the crew roles in the concurrent operations are compared based on the crew role weight table to determine the weight comparison result. Based on the weight comparison results, the operation results of the roles with weights higher than the preset weight threshold are retained, and a rollback instruction is sent to the terminals of the roles with weights lower than the preset weight threshold to update the local data status.

6. The method according to claim 1, characterized in that, The first terminal performs state consistency verification on the shadow instruction data packet, including: Extract the aircraft status snapshot encapsulated in the shadow command data packet; Obtain real-time aircraft status data from the first terminal; The aircraft status snapshot is compared with the real-time aircraft status data to obtain the status difference value; When the state difference value exceeds the preset state threshold or the state identifier does not match, it is determined that the shadow instruction data packet has expired and the data writing is refused. When the state difference value does not exceed the preset state threshold and the state identifier matches, the data writing is performed in response to the physical authorization input signal of the first terminal.

7. The method according to claim 1, characterized in that, After obtaining the chained operation log node, the method further includes: After generating each of the chained operation log nodes, the sequence fingerprint of the current node is extracted, and the sequence fingerprint is merged with the previous round of rolling aggregation tag value maintained in memory through message authentication code combination operation to obtain the updated rolling aggregation tag value. Obtain the current operation density and flight phase identifier. When the operation density exceeds a preset density threshold or the flight phase identifier is a critical flight phase, encrypt the current scrolling aggregation tag value to obtain the segmented audit anchor value. The segmented audit anchor point value is written to an independent storage partition isolated from the operation log storage area. The independent storage partition is access controlled with different write permissions than the operation log storage area, thus obtaining the segmented audit anchor point in isolated storage. The segmented audit anchor points are reconstructed and verified segment by segment. The value of each segmented audit anchor point is used as a leaf node to calculate the root digest value. The root digest value is then stored in the non-erasable storage medium.

8. The method according to claim 7, characterized in that, The segmented audit anchor points are reconstructed and verified segment by segment. The value of each segmented audit anchor point is used as a leaf node for root digest calculation to obtain the root digest value, including: Read the segmented audit anchor value from the independent storage partition, reconstruct the rolling aggregate tag value segment by segment for the chained operation log node in each segment interval, compare the reconstructed rolling aggregate tag value with the corresponding stored segmented audit anchor value to obtain the segmented verification result; When the segment-by-segment verification results do not match, the tampering range is located to the corresponding segment interval to obtain the tampering location result; Each segmented audit anchor value is used as a leaf node, and a Merkle tree root summary is calculated for all leaf nodes to obtain the root summary value.

9. The method according to claim 1, characterized in that, After broadcasting the chained operation log node through the collaborative domain, and before updating the local data status based on the verification result, the method further includes: Each terminal maintains a local state summary, which includes a vector version number of the current state of the local operation log chain and a Bloom filter encoding of the set of confirmed operation log node identifiers. When the terminal reconnects to the collaborative domain, the state digests of each terminal are exchanged, the log fork point is determined by comparing the vector version numbers of each terminal, and the set of operation log node identifiers that the peer has held but the local terminal does not have is identified by the Bloom filter encoding to obtain the minimum synchronization difference set. Based on the minimum synchronization difference set, the missing incremental operation log nodes are requested and transmitted from the peer to obtain the incremental synchronization result, and the local data status is updated based on the incremental synchronization result. For concurrent operation nodes in the incremental operation log node, extract the aircraft status identifier from the status snapshot of each node for semantic classification. When the aircraft status identifiers of concurrent nodes are the same, retain the operation results with a weight higher than the preset weight threshold and append the operation node with a weight lower than the preset weight threshold to the operation log chain. When the aircraft status identifiers of concurrent nodes are different, retain the operation results of the role with a weight higher than the preset weight threshold and send a rollback instruction to the terminal of the role with a weight lower than the preset weight threshold. For operation log segments that have completed digest handshake alignment, broadcast the segmentation acknowledgment signal of the log segment to the cooperative domain, mark the operation log segments that have received segmentation acknowledgment signals from all online terminals as cross-terminal acknowledgment states, and update the local vector version number of each terminal with the state digest of the cross-terminal acknowledgment state log segments.

10. The method according to claim 9, characterized in that, For concurrent operation nodes in the incremental operation log nodes, extract the aircraft status identifier from the status snapshot of each node and perform semantic classification, including: Extract the state snapshots of each concurrent operation node in the minimum synchronization difference set, and obtain the aircraft state identifier in the state snapshots; The aircraft status identifiers of each concurrent operation node are compared one by one. When the aircraft status identifiers of two concurrent nodes correspond to the same aircraft physical state, they are classified as semantically compatible concurrency and semantic preservation merging is performed: the operation result of the role with higher weight is retained as the final data state, and the operation node of the role with lower weight is added to the operation log chain as an audited historical operation record to obtain the merged operation log chain. When the aircraft status identifiers of two concurrent nodes correspond to different aircraft physical states, they are classified as semantic conflict concurrency. The operation result of the higher-weight role is retained, and a rollback instruction is sent to the terminal of the lower-weight role to obtain the local data state after the conflict is resolved.

11. The method according to claim 1, characterized in that, In response to a critical control operation of the second terminal, after intercepting the local execution of the critical control operation, encapsulating a shadow command data packet containing parameters of the command to be executed and a snapshot of the aircraft status, and synchronizing it to the first terminal, the method further includes: During the user operation process on the second terminal, the current flight phase identifier, recent operation type sequence, current interface focus data field and user input completion are continuously collected and fused to obtain the operation context vector; The operation context vector input is used to infer the preset operation intent classification model to obtain the confidence prediction distribution of each key control operation intent; when the confidence of an operation intent exceeds the preset activation threshold, a pre-filled shadow instruction draft is generated in advance based on the currently input parameters and the aircraft status snapshot. The pre-filled shadow command draft and its confidence value are synchronized to the first terminal in advance. The first terminal performs a state consistency pre-verification on the aircraft state snapshot in the pre-filled shadow command draft, places the pre-filled shadow command draft that passes the pre-verification in the activation queue, and sends a warning signal to the first terminal user. When the second terminal user actually triggers the key control operation, the pre-filled shadow instruction draft in the queue to be activated is matched with the type and parameter key name of the current operation. When a match is found, the pre-filled shadow instruction draft that has completed pre-verification in the queue to be activated is directly activated to obtain the shadow instruction data packet. The first terminal responds to the physical authorization input signal to execute the data writing. When a match is not found, the shadow instruction data packet is repackaged and synchronized to the first terminal. Record the prediction hit rate of the operation intent classification model in each flight mission, and dynamically adjust the preset activation threshold of each operation type based on the prediction hit rate to obtain the updated activation threshold.

12. A collaborative device for heterogeneous data fusion and intent mapping of an electronic flight bag, characterized in that, The device includes: The trusted collaboration module is used to obtain the flight mission identifier and crew role credentials, perform key derivation and handshake authentication on the flight mission identifier and crew role credentials, and establish a local temporary trusted collaboration domain between the first terminal and the second terminal, wherein the first terminal is the decision-making end and the second terminal is the operation end; The synchronization data module is used to collect airborne operation data using the first terminal and external business operation data using the second terminal, and to perform format conversion and status snapshot embedding on the airborne operation data and the external business operation data to obtain a synchronization data unit. A one-way hash calculation module is used to perform one-way hash calculation on the integrity check code of the previous operation log node in the local memory, the current synchronization data unit and the operator's digital signature to obtain a sequence fingerprint, and encapsulate the synchronization data unit, the sequence fingerprint and the operator's digital signature to obtain a chained operation log node; The verification module is used to broadcast the chained operation log nodes to other terminals through the collaborative domain, perform sequence fingerprint continuity verification, timing verification and business logic verification on the received chained operation log nodes, obtain verification results, and update the local data status based on the verification results. The interception module is used to respond to the critical control operation of the second terminal, intercept the local execution of the critical control operation, encapsulate a shadow command data packet containing the parameters of the instruction to be executed and the aircraft status snapshot and synchronize it to the first terminal. The first terminal performs a status consistency check on the shadow command data packet, and executes data writing after the check passes. The storage module is used to perform root digest calculation on the chained operation log node sequence in response to the flight mission end signal, obtain the root digest value, and store the root digest value in a non-erasable storage medium.

Images