Airplane cross-domain guarantee data synchronization method and device based on dynamic policy mapping

Abstract

This application belongs to the field of aircraft maintenance and support technology, and specifically relates to a method and apparatus for synchronizing cross-domain support data for aircraft based on dynamic policy mapping. The method includes: Step S1, acquiring support data from field feedback, the support data including change record data, business type, and task phase context data; Step S2, when the support data conflicts with the record data of the central server, matching a set of candidate policies in a policy mapping table according to the business type and the current task phase context data; Step S3, when multiple candidate policies exist in the set, selecting the candidate policy with the highest weight as the final policy; Step S4, updating the data on the central server according to the final policy. This application achieves intelligent and highly reliable automatic adjudication of aviation support data conflicts, significantly improving the synchronization accuracy of data and the maintainability of the system.

Description

Technical Field

[0001] This application belongs to the field of aircraft maintenance and support technology, and specifically relates to a method and apparatus for synchronizing cross-domain support data for aircraft based on dynamic strategy mapping. Background Technology

[0002] As the operational mode of aviation equipment evolves towards full-domain response and cross-domain deployment, its support system presents a distributed architecture from the center to the edge. Core support data needs to be synchronized bidirectionally between fixed support centers and field sites such as forward mission points / mobile platforms to support uninterrupted equipment health management and maintenance decisions. That is, after the aircraft performs maintenance in the field, it feeds back support data, and the fixed support center needs to merge and process the feedback support data with its own recorded data.

[0003] Currently, the mainstream technical approaches for distributed data synchronization and their inherent limitations are as follows:

[0004] (1) General synchronization technologies based on Operation Transformation (OT) or eventual consistency protocols, such as algorithms applied to collaborative editing, can ensure that all nodes see the same final data state. However, their merging logic is entirely based on mathematical transformations of data structures, such as the insertion and deletion positions of text characters, completely ignoring the business semantics of the data. In aviation support scenarios, this may lead to serious disruption of business logic. For example, when the planned replacement instruction issued by the center is concurrent with the actual replacement record executed in the field, the OT algorithm may produce a merging result that is neither planned nor actual because it does not understand the difference in authority between the plan and the fact in business.

[0005] (2) Conflict resolution frameworks based on static business rules: Some domains have attempted to introduce rule engines to configure static processing rules (such as prioritizing field data) for specific types of data (such as replacement records). However, aviation support decisions are highly context-dependent. The same component inspection data may be based on airborne sensor data as a temporary basis during the mission execution phase, but must be based on laboratory calibration data during the post-reconstruction analysis phase. Existing static rule frameworks cannot adapt to the dynamically changing adjudication strategy that evolves with the mission phase and lack spatiotemporal context awareness.

[0006] (3) The post-conflict handling model that relies on manual arbitration: When automatic merging fails or disputes arise, the existing system generally hands over the list of conflicting data to the assurance personnel, who then decide on the final handling strategy. This approach is not only inefficient, but more importantly, in the absence of structured decision support, manual decision-making relies heavily on personal experience, which can easily lead to inconsistent or even erroneous decisions. It fails to form a standardized and traceable assurance data governance process, becoming a potential weakness in assurance reliability.

[0007] Therefore, the bottleneck of existing technologies lies in the difficulty of building a data synchronization system that can deeply understand business semantics and adapt to changes in business context, thereby achieving highly reliable automated adjudication. This results in cross-domain assurance operations still facing prominent problems such as high data consistency risks, lagging decision support, and heavy personnel burden. Summary of the Invention

[0008] To address the aforementioned issues, this application provides a method and apparatus for cross-domain data synchronization of aircraft based on dynamic policy mapping, which adaptively selects or adjusts the adjudication strategy to ensure that the merging results comply with the business specifications under specific spatiotemporal scenarios.

[0009] The first aspect of this application provides a method for cross-domain support data synchronization of aircraft based on dynamic policy mapping, mainly including:

[0010] Step S1: Obtain the support data from the field feedback, including change record data, business type, and task stage context data;

[0011] Step S2: When the protection data conflicts with the recorded data of the central server, a set of candidate strategies is matched in the strategy mapping table according to the business type and the context data of the current task stage.

[0012] Step S3: When there are multiple candidate strategies in the candidate strategy set, the candidate strategy with the highest weight is taken as the final strategy.

[0013] Step S4: Update the data on the central server according to the final strategy.

[0014] Preferably, in step S1, the service type of the field feedback is pre-selected by the operator from a preset service type dictionary, which is maintained by the central server.

[0015] Preferably, in step S1, the field includes a mobile platform and / or a support terminal.

[0016] Preferably, step S2 further includes:

[0017] For the change record data of the current protection data, determine whether there is a parent data item based on the preset association chain rules. If there is a parent data item, replace the candidate strategy of the current protection data with the candidate strategy of the parent data item.

[0018] Preferably, step S3 further includes:

[0019] Step S31: Obtain the basic priority weights assigned to each candidate strategy during definition;

[0020] Step S32: Based on the triggering conditions in the weight adjustment rule table, adjust the weights of candidate strategies that meet the triggering conditions based on the basic priority weights to determine the final weights of each candidate strategy.

[0021] The second aspect of this application provides an aircraft cross-domain support data synchronization device based on dynamic policy mapping, mainly comprising:

[0022] The data acquisition module is used to acquire the support data fed back from the field. The support data includes change record data, business type, and task stage context data.

[0023] The candidate strategy set determination module is used to match candidate strategy sets in the strategy mapping table according to the business type and the current task stage context data when there is a conflict between the protection data and the recorded data of the central server.

[0024] The final strategy determination module is used to select the candidate strategy with the highest weight as the final strategy when there are multiple candidate strategies in the candidate strategy set.

[0025] The data update module is used to update the data on the central server according to the final policy.

[0026] Preferably, in the data acquisition module, the service type of the field feedback is pre-selected by the operator from a preset service type dictionary, which is maintained by the central server.

[0027] Preferably, in the data acquisition module, the field includes a mobile platform and / or a support terminal.

[0028] Preferably, the candidate strategy set determination module includes:

[0029] The candidate strategy adjustment unit based on the data chain is used to determine the change record data for the current protection data, and to determine whether there is a parent data item based on the preset association chain rules. If there is a parent data item, the candidate strategy of the parent data item is used to replace the candidate strategy of the current protection data.

[0030] Preferably, the final strategy determination module includes:

[0031] The basic priority weight acquisition unit is used to acquire the basic priority weight assigned to each candidate strategy when it is defined.

[0032] The weight adjustment unit is used to adjust the weights of candidate strategies that meet the trigger conditions based on the trigger conditions in the weight adjustment rule table, and to determine the final weights of each candidate strategy.

[0033] This application combines business type, task phase context data and dynamic strategy mapping to achieve intelligent and highly reliable automatic adjudication of aviation support data conflicts. It solves the core problems of existing technologies, such as the disconnect between business logic and merging logic, lack of context awareness in static rules, and low efficiency and unreliability of manual decision-making, and greatly improves the synchronization accuracy of data and the maintainability of the system. Attached Figure Description

[0034] Figure 1 This is a flowchart of a preferred embodiment of the aircraft cross-domain data synchronization method based on dynamic policy mapping in this application. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be described in more detail below with reference to the accompanying drawings. In the drawings, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The described embodiments are only some, not all, of the embodiments of this application. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0036] The first aspect of this application provides a method for cross-domain assurance data synchronization of aircraft based on dynamic policy mapping, such as... Figure 1 As shown, it mainly includes:

[0037] Step S1: Obtain the support data from the field feedback, including change record data, business type, and task stage context data;

[0038] Step S2: When the protection data conflicts with the recorded data of the central server, a set of candidate strategies is matched in the strategy mapping table according to the business type and the context data of the current task stage.

[0039] Step S3: When there are multiple candidate strategies in the candidate strategy set, the candidate strategy with the highest weight is taken as the final strategy.

[0040] Step S4: Update the data on the central server according to the final strategy.

[0041] In steps S1-S2 of this application, a dynamic strategy mapping model F is constructed, the static rule list is improved, and a three-dimensional decision model is introduced. The adjudication strategy S is jointly determined by the business type (BizType) and the task phase context (Phase), i.e., S=F(BizType,Phase). If necessary, the version type can be added to the input parameters, as shown in Table 1.

[0042] Table 1 Dynamic Strategy Mapping Table (Example 1)

[0043]

[0044] It should be noted that the dynamism of the dynamic strategy mapping model in this application is reflected in its being driven by the task phase. It defines phases such as "task preparation", "task execution", "return and synchronization", and "daily support". Data of the same business type can be mapped to different strategies under different task phases. For example, when BizType = "flight parameters" is in Phase = "task execution", as shown in the fourth row of Table 1, the strategy is "accumulate based on airborne source (STRAT_PLAT_ACCUM)"; when Phase = "return and synchronization", as shown in the fifth row of Table 1, the strategy changes to "weighted fusion calibration with ground records (STRAT_WEIGHT_MERGE)".

[0045] In some optional implementations, in step S1, the service type of the field feedback is pre-selected by the operator from a preset service type dictionary, which is maintained by the central server.

[0046] In this embodiment, a business type management module is pre-defined to uniformly maintain the business type dictionary and its association with the strategy mapping table. All data entering into the client (such as PMA or the central business system) must select a business type from this dictionary and be verified by the server. In online scenarios, the client performs real-time verification by calling the API of the business type management module. In offline scenarios, the PMA obtains the latest business type dictionary and caches it locally during task synchronization. All data entry interfaces integrate this local dictionary for mandatory selection (UI-level constraint). The generated incremental transaction log contains valid business types while temporarily stored locally. After synchronization, the central server will perform consistency verification on the business types again and record any verification anomalies as data quality problem alarms. The system periodically runs a tag consistency verification task to scan and report records with abnormal or missing business type assignments.

[0047] This embodiment ensures the accuracy and consistency of business semantic information from the data source by designing mandatory data protection fields and a centralized tag management process, providing reliable input for upper-level intelligent adjudication and realizing closed-loop trusted management from data production to consumption.

[0048] In some alternative implementations, in step S1, the field includes a mobile platform and / or a support terminal.

[0049] In this embodiment, the support data fed back from the field usually comes from the mobile platform. One of the purposes of this application is to solve the problem of data conflict between the support data generated after aircraft maintenance at the mobile platform and the data generated during the update at the central server. However, in actual operation, there are usually controlled abnormal revision data. This embodiment further provides version branch management and three-way merging logic to support controlled abnormal revisions.

[0050] Define an independent "assistance terminal" role. Data modification requests issued by this assurance terminal must be accompanied by a digital signature issued by the assurance center's CA. Upon receiving such a request, the synchronization system verifies the signature's validity and records the complete operation flow, including the signature, operator, timestamp, and modified content, in a separate, append-only security audit log. Only after successful verification can a new version branch be created on the frozen data (described in subsequent embodiments). For intermittent network environments, when issuing emergency revision instructions, the assurance command terminal generates a digitally signed data packet containing a timestamp, operation content, and the reviser's certificate. This data packet can be distributed via any available channel (such as a satellite link). Upon receiving this data packet, the mobile platform edge server or PMA performs offline signature verification using a pre-installed assurance center root certificate.

[0051] This embodiment transforms the administrative "high-privilege process" into a security control mechanism with clear technical features (digital signature, independent audit library). At the same time, it clarifies that the transformed data is used as security data, just like the security data generated by the mobile platform. The complex three-way merging problem is solved by selecting the maximum weight in the subsequent step S3, which demonstrates the completeness and robustness of the solution in handling abnormal paths.

[0052] In some alternative implementations, step S2 further includes:

[0053] For the change record data of the current protection data, determine whether there is a parent data item based on the preset association chain rules. If there is a parent data item, replace the candidate strategy of the current protection data with the candidate strategy of the parent data item.

[0054] In constructing the dynamic policy mapping model F, this embodiment further introduces an association chain for complex scenarios. For example, a "component replacement record" (which triggers the "field authority" policy) can be associated with the subsequent "fault code clearing record". The "fault code clearing record" inherits the "field authority" policy of the "component replacement record" due to its context association, thereby ensuring the integrity of the business chain.

[0055] When multiple candidate strategies are given in step S2, the strategy weights are simultaneously provided, as shown in the "Static Priority" column of Table 1. In step S3, the strategy with the highest weight is selected as the final strategy, and finally, in step S4, this final strategy is executed to update the data on the central server.

[0056] In some alternative implementations, step S3 further includes:

[0057] Step S31: Obtain the basic priority weights assigned to each candidate strategy during definition;

[0058] Step S32: Based on the triggering conditions in the weight adjustment rule table, adjust the weights of candidate strategies that meet the triggering conditions based on the basic priority weights to determine the final weights of each candidate strategy.

[0059] The basic priority weight in step S31, also known as static priority, assigns a basic priority value to each policy when it is defined. For example, the priority of a security-related policy is 100, the priority of a business authority policy is 80, and the priority of a timeliness policy is 60. Step S32 is used to adjust the weight / priority based on the basic priority weight. Specifically, according to the current business type and the specific attributes of the conflicting data, such as the source version type, a predefined set of adjustment rules is applied to fine-tune the priority of the candidate policies. As shown in Table 2, the RW_01 adjustment rule is as follows: if the current task stage is "task execution" and the business type includes "sensor", then the priority of the policy "accumulate based on airborne source (STRAT_PLAT_ACCUM)" is increased by 20.

[0060] Table 2 Weight Adjustment Rules (Example 1)

[0061]

[0062] This embodiment designs the deterministic decision-making logic of the adjudication engine in complex matching situations through this mechanism, especially the priority model of "static baseline + dynamic weighting rules", which solves the selection problem when multiple rules conflict and ensures the stability and predictability of the engine output results.

[0063] The following detailed examples illustrate this.

[0064] Example 1:

[0065] S101: Task initialization and data preparation.

[0066] The fixed support center receives the task instruction. The business type management module provides a business type dictionary for use. Based on the business type, it dynamically queries and encapsulates data from the database. For example, it executes SQL to filter relevant resumes and generates a task package with version V_M001_1.

[0067] S102: Exit synchronization.

[0068] Synchronize the mission package to the mobile platform and PMA.

[0069] S103: Task execution and field recording.

[0070] Field personnel use PMA to select "physical operation" from the dictionary based on the operation (such as "replace engine oil") in the software interface, and generate a log, which is the assurance data. In this assurance data, the change record data is "replace engine oil", the business type is "physical operation", the task version is "V_M001_1", and the task stage is "task execution".

[0071] S104: Synchronization and Intelligent Merging.

[0072] The mobile platform sends incremental logs, the fixed support center compares the data, finds conflicts, and makes dynamic decisions. The following are some common processing scenarios.

[0073] Scenario A: Routine Conflict. For example, a mobile platform reports "Radar module replaced (SN:456)," while the central record shows SN:123. The data's service type is "Physical Operation," and the current task phase is "Return and Synchronization." Querying the mapping table shown in Table 1 matches the policy "Based on Field Physical Operations (STRAT_OP_FIELD_AUTHORITY)." Since there are no other candidate policies, the fixed support center directly executes the overwrite operation.

[0074] Scenario B: Three-way merging with emergency revisions. During the mission, the fixed support center urgently revised the maintenance interval of the radar through the support terminal, generating a new version V_M001_2. At this time, the mobile platform increment is based on version V_M001_1. Using version V_M001_1 as the baseline, the fixed support center calculates the difference set ∆C of the mobile platform = {maintenance interval changed from 150h to 120h, version type "emergency"}, and simultaneously calculates the difference set ∆P of the support terminal = {radar serial number changed from SN123 to SN456}.

[0075] For "Maintenance Interval," the specific policy "Emergency Plan Authority (STRAT_EMERGENCY_PLAN_AUTH)" can be matched according to Table 1; for "Radar Serial Number," since its business type belongs to "Physical Operation," the policy "Field Physical Operation Authority (STRAT_OP_FIELD_AUTHORITY)" can be matched according to Table 1. Because these are different data objects, they do not conflict with each other. The Fixed Support Center executes the "Emergency Plan Authority" policy for "Maintenance Interval" and the "Field Physical Operation Authority" policy for "Radar Serial Number," generating a merged version V_M001_3, which integrates emergency revision and actual replacement information.

[0076] Scenario C: Assume the mobile platform reports "sensor reading R=100", the service type is "SENSOR_READING", the fixed support center records R=105, and the current task stage is "task execution". Querying Table 1, candidate strategies are matched:

[0077] "Accumulate based on airborne source (STRAT_PLAT_ACCUM)", static priority 70;

[0078] “Sign a weighted fusion calibration with ground records (STRAT_WEIGHT_MERGE)”, static priority 75.

[0079] Subsequently, the weighting rule set is loaded, as shown in Table 2. Rule RW_01 is applied, and the priority of the strategy "Accumulation based on airborne source (STRAT_PLAT_ACCUM)" is increased by 20. After weighting, the overall priority of "Accumulation based on airborne source (STRAT_PLAT_ACCUM)" becomes 90, while the weighted fusion calibration with ground records remains at 75. Finally, conflict resolution is performed, selecting the strategy with the highest overall priority, "Accumulation based on airborne source (STRAT_PLAT_ACCUM)," and executing the "Accumulation based on airborne source" operation. If the priorities of the two strategies are the same after weighting, the engine marks this conflict item and sends it along with the candidate strategy information to the "waiting for manual arbitration queue" for confirmation by support personnel.

[0080] Scenario D: Linked Chain-Driven Decision. The platform reports a record "Engine Replacement E1 (SN:789)", with a business type of "Physical Operation". The Fixed Support Center does not have this operation. However, based on this operation, the platform automatically generates a record "Associated Fault Code F100 Cleared" with a business type of "Fault Clearance". The Fixed Support Center also has a record "Planned Inspection" with a business type of "Maintenance Plan". During the merging process, the Fixed Support Center identifies a linked chain between the "Fault Code Clearance Record" and the "Replacement Record". For the "Fault Code Clearance Record", although its business type is "Fault Clearance", because its associated parent operation uses the "External Authority" strategy under the "Reconstruction Synchronization" task phase, the Fixed Support Center, according to the linked chain inheritance rules, also uses the "External Authority" strategy to cover this "Fault Code Clearance Record", thus ensuring that the series of business status changes caused by the actual physical operation remain logically consistent.

[0081] S105: Unfreezing and Version Update.

[0082] After the merge is complete, update the maintenance status and update the version to V_M001_3.

[0083] Example 2:

[0084] To perform a long-duration patrol mission M002 on aircraft AC002, during mission initialization, the fixed support center synchronizes the relevant support data of AC002's engine E1 to the mobile platform, generating a mission branch branch_M002, version V_M002_1.

[0085] Key data items include:

[0086] Data item A (Engine E1 remaining life): Business type is "Lifetime", initial value is 500 hours.

[0087] Data item B (Engine E1 historical fault code): The business type is "historical fault" and contains the fault code F101 that has not been cleared.

[0088] Data item C (Repair plan for fault code F101): The business type is "Repair Plan" and the content is "Laboratory testing after return".

[0089] First, record the field operation data during the task execution phase, which is also the guarantee data.

[0090] Field Operation 1: During the mission, the Onboard Health Management System (HUMS) automatically calculated and updated the remaining lifespan of engine E1 based on real-time sensor data. Increment: ∆P1 = {Data Item A (Lifespan): 500 -> 450}. The version type of this record is "Automatically Generated by the Mobility Platform".

[0091] Field Operation 2 (PMA Record): During ground inspection, maintenance personnel actually replaced the sensor for engine E1 (related to fault code F101). Incremental data generated: ∆P2 = {Data Item D: Add a new record, business type "Physical Operation", content: Replace sensor S01 for engine E1}.

[0092] Related Data Generation: The PMA system automatically derives a new data record based on business logic. Incremental Generation: ∆P3 = {Data Item E: Add a new record, business type "Fault Clearing", content: Fault code F101 has been cleared due to sensor replacement, parent reference: ID of data item D}. This data item establishes a link with data item D (physical operation) through the parent reference field.

[0093] Based on the latest intelligence, the support terminal expert determined that fault code F101 may pose a significant risk and must be addressed immediately. Using the support command terminal, an emergency revision of data item C (Maintenance Plan) was made, and a valid digital signature was added. An increment was generated: ∆C1 = {Data item C (Maintenance Plan): "Post-return lab testing" -> "Immediate grounding, awaiting replacement", Version type: Emergency}. This operation created a new version V_M002_2 on the task branch_M002.

[0094] Afterwards, the fixed support center updates the data, performs data restoration and synchronization, detects conflicts, initiates the synchronization process, and switches the task phase to data restoration and synchronization.

[0095] The changes that need to be merged in the fixed support center are based on three version baselines: the common ancestor is version V_M002_1; version V_M002_2 generated by the emergency revision of the support terminal (based on version V_M002_1); and the incremental sets of mobile platforms ∆P1, ∆P2, ∆P3 (all based on version V_M002_1).

[0096] The fixed support center detected two sets of conflicts: Conflict group 1 (direct conflict): The value of data item A (service life) changed to 450 in ∆P1, but was still recorded as 500 in the fixed support center; Conflict group 2 (indirect conflict / semantic conflict): Regarding the status of fault code F101, the mobile platform side indicated that it had been cleared through ∆P3 (fault clearing), while the support terminal side indicated through ∆C1 (maintenance plan) that it needed to be grounded and replaced immediately, implying that the fault still existed and was serious.

[0097] Subsequently, conflict resolution will be carried out. The resolution process for conflict group 1 is as follows:

[0098] The support data for conflict item A is retrieved. The business type is "Lifetime," the task stage is "Reconstruction and Synchronization," and the version type is "Automatic Generation by Mobile Platform." Table 3 is queried, and two candidate strategies are matched: "Weighted Fusion Calibration with Ground Records (STRAT_WEIGHT_MERGE)" with a static priority of 75; and "Accumulation Based on Airborne Source (STRAT_PLAT_ACCUM)" with a static priority of 70. The fixed support center loads the weighting rule set from Table 4 and applies the relevant rule RW_03. This rule stipulates that for post-reconstruction lifetime data, a weighted fusion after ground calibration is preferred. The priority of the "Weighted Fusion Calibration with Ground Records (STRAT_WEIGHT_MERGE)" strategy is increased by 5, resulting in the following priorities: STRAT_WEIGHT_MERGE = 75 + 5 = 80; STRAT_PLAT_ACCUM = 70. The fixed support center compares the overall priorities after the weighting adjustment and ultimately selects the "Weighted Fusion Calibration with Ground Records (STRAT_WEIGHT_MERGE)" strategy. Then, a weighted merging algorithm is executed. For example, the weight of the mobile platform value is 0.7, and the weight of the historical value of the fixed support center is 0.3. The merged value of data item A is calculated to be 465 hours.

[0099] The procedure for handling conflict group 2 is as follows:

[0100] For data item E, the business type is "fault clearing," the task phase is "reconstruction and synchronization," and it has a "parent data item." For data item C, the business type is "maintenance plan," the task phase is "reconstruction and synchronization," and the version type is "emergency." Querying Table 3, for data item E, the direct matching strategy is "inherit parent operation strategy (STRAT_DERIVED_FROM_PARENT)," with a static priority of 65. The association chain logic is: this strategy is defined as "inheriting the strategy applied by its parent data item (physical operation) under the same task phase." Therefore, the fixed support center needs to recursively query the strategy of its parent data item D (physical operation), which is found to be "based on field physical operations (STRAT_OP_FIELD_AUTHORITY)," with a static priority of 90. For data item C: the matching strategy is "emergency plan authority (STRAT_EMERGENCY_PLAN_AUTH)," with a static priority of 100. The Fixed Support Center loads the weighting rule set from Table 4, applies the relevant rule RW_02, and increases the priority of the strategy "Emergency Plan Authority (STRAT_EMERGENCY_PLAN_AUTH)" by 10, making it 110. The strategy "External Field Physical Operations as the Basis (STRAT_OP_FIELD_AUTHORITY)" inherited by data item E remains at priority 90 as no other rules are triggered. The Fixed Support Center compares the overall priorities after the weighting adjustment and ultimately selects the "Emergency Plan Authority (STRAT_EMERGENCY_PLAN_AUTH)" strategy. This strategy is then executed.

[0101] Assuming that after weighting, the priorities of the two items are exactly the same, the Fixed Support Center cannot make an automatic decision. At this point, the Fixed Support Center packages the data items C and E involved in Conflict Group 2, along with their complete adjudication context information (including their respective business types, sources, all matching strategies and their calculated priorities, and related chain information), and sends them to the "Pending Manual Arbitration Queue." A prompt is generated stating, "The adjudication strategies are of the same level; manual confirmation is required to determine whether fault clearing or the emergency grounding plan should prevail." The synchronization process can pause or continue processing other non-conflicting items at this node. After the support personnel make a selection on the arbitration interface, the system executes the final decision based on the manual adjudication result.

[0102] The Fixed Assurance Center merges all automatically adjudicable items, generating the final version V_M002_3. All processes (including digital signature verification, each policy matching, weight adjustment calculation, and final decision instructions) are recorded in a separate log of the security audit service.

[0103] Table 3 Dynamic Strategy Mapping Table (Example 2)

[0104]

[0105] Table 4. Weight Adjustment Rules (Example 2)

[0106]

[0107] The application tested 5,000 conflict test cases covering 5 task phases and 8 categories of core business data. Using the dynamic policy mapping method of this application, the automatic adjudication rate for correct business logic reached 99.8%, while the static rule base method achieved an accuracy of 89.5%. This result fully demonstrates the decisive role of the dynamic context-aware mechanism in improving adjudication accuracy. This application significantly reduces system complexity and operational burden. The "policy mapping table" and "adjustment rule set" centralize and visualize the previously scattered and implicit business rules. When business logic changes, only the mapping table or rule set needs to be updated; no modification to the engine code is required.

[0108] This application provides highly reliable automated data synchronization and adjudication, enabling the support center to implement precise decision support and resource scheduling for frontline support units based on trusted and consistent support data. This achieves efficient collaboration between the "center" for intelligent analysis and decision-making and the "edge" for focused execution, driving the optimization of the support system architecture. This application transforms the experiential knowledge of domain experts into configurable and dynamically adjustable policy mapping tables and weighting rule sets. This process not only solves the semantic conflict problem in data synchronization but also structures implicit knowledge, forming a continuously updated and optimized support knowledge base, providing a core knowledge carrier for the long-term evolution of the support system. The dynamic mapping model proposed in this application has good scalability in its methodology and technical framework. This model is applicable to other complex systems such as spacecraft, ships, and complex ground equipment that require combining strong domain business logic with distributed data synchronization, providing a systematic technical path for solving a wide range of semantic conflict problems.

[0109] A second aspect of this application provides an aircraft cross-domain support data synchronization device based on dynamic policy mapping, corresponding to the above method, mainly comprising:

[0110] The data acquisition module is used to acquire the support data fed back from the field. The support data includes change record data, business type, and task stage context data.

[0111] The candidate strategy set determination module is used to match candidate strategy sets in the strategy mapping table according to the business type and the current task stage context data when there is a conflict between the protection data and the recorded data of the central server.

[0112] The final strategy determination module is used to select the candidate strategy with the highest weight as the final strategy when there are multiple candidate strategies in the candidate strategy set.

[0113] The data update module is used to update the data on the central server according to the final policy.

[0114] In some optional implementations, in the data acquisition module, the service type of the field feedback is pre-selected by the operator from a preset service type dictionary, which is maintained by the central server.

[0115] In some alternative implementations, the field includes a mobile platform and / or a support terminal in the support data acquisition module.

[0116] In some optional implementations, the candidate strategy set determination module includes:

[0117] The candidate strategy adjustment unit based on the data chain is used to determine the change record data for the current protection data, and to determine whether there is a parent data item based on the preset association chain rules. If there is a parent data item, the candidate strategy of the parent data item is used to replace the candidate strategy of the current protection data.

[0118] In some alternative implementations, the final strategy determination module includes:

[0119] The basic priority weight acquisition unit is used to acquire the basic priority weight assigned to each candidate strategy when it is defined.

[0120] The weight adjustment unit is used to adjust the weights of candidate strategies that meet the trigger conditions based on the trigger conditions in the weight adjustment rule table, and to determine the final weights of each candidate strategy.

[0121] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for cross-domain data synchronization of aircraft based on dynamic policy mapping, characterized in that, include: Step S1: Obtain the support data from the field feedback, including change record data, business type, and task stage context data; Step S2: When the protection data conflicts with the recorded data of the central server, a set of candidate strategies is matched in the strategy mapping table according to the business type and the context data of the current task stage. Step S3: When there are multiple candidate strategies in the candidate strategy set, the candidate strategy with the highest weight is taken as the final strategy. Step S4: Update the data on the central server according to the final strategy.

2. The aircraft cross-domain data synchronization method based on dynamic policy mapping according to claim 1, characterized in that, In step S1, the service type of the field feedback is forcibly selected by the operator in advance from a preset service type dictionary, which is maintained by the central server.

3. The aircraft cross-domain assurance data synchronization method based on dynamic policy mapping according to claim 1, characterized in that, In step S1, the field includes a mobile platform and / or a support terminal.

4. The aircraft cross-domain assurance data synchronization method based on dynamic policy mapping according to claim 1, characterized in that, Step S2 further includes: For the change record data of the current protection data, determine whether there is a parent data item based on the preset association chain rules. If there is a parent data item, replace the candidate strategy of the current protection data with the candidate strategy of the parent data item.

5. The aircraft cross-domain assurance data synchronization method based on dynamic policy mapping according to claim 1, characterized in that, Step S3 further includes: Step S31: Obtain the basic priority weights assigned to each candidate strategy during definition; Step S32: Based on the triggering conditions in the weight adjustment rule table, adjust the weights of candidate strategies that meet the triggering conditions based on the basic priority weights to determine the final weights of each candidate strategy.

6. An aircraft cross-domain support data synchronization device based on dynamic strategy mapping, characterized in that, include: The data acquisition module is used to acquire the support data fed back from the field. The support data includes change record data, business type, and task stage context data. The candidate strategy set determination module is used to match candidate strategy sets in the strategy mapping table according to the business type and the current task stage context data when there is a conflict between the protection data and the recorded data of the central server. The final strategy determination module is used to select the candidate strategy with the highest weight as the final strategy when there are multiple candidate strategies in the candidate strategy set. The data update module is used to update the data on the central server according to the final policy.

7. The aircraft cross-domain support data synchronization device based on dynamic strategy mapping according to claim 6, characterized in that, In the data acquisition module, the service type of the field feedback is pre-selected by the operator from a preset service type dictionary, which is maintained by the central server.

8. The aircraft cross-domain support data synchronization device based on dynamic strategy mapping according to claim 6, characterized in that, In the data acquisition module, the field includes a mobile platform and / or a support terminal.

9. The aircraft cross-domain support data synchronization device based on dynamic strategy mapping according to claim 6, characterized in that, The candidate strategy set determination module includes: The candidate strategy adjustment unit based on the data chain is used to determine the change record data for the current protection data, and to determine whether there is a parent data item based on the preset association chain rules. If there is a parent data item, the candidate strategy of the parent data item is used to replace the candidate strategy of the current protection data.

10. The aircraft cross-domain support data synchronization device based on dynamic strategy mapping according to claim 6, characterized in that, The final strategy determination module includes: The basic priority weight acquisition unit is used to acquire the basic priority weight assigned to each candidate strategy when it is defined. The weight adjustment unit is used to adjust the weights of candidate strategies that meet the trigger conditions based on the trigger conditions in the weight adjustment rule table, and to determine the final weights of each candidate strategy.

Images