An airport regulation data processing method and system based on flight training equipment

Abstract

The application belongs to the field of data processing, and particularly relates to an airport regulation data processing method and system based on flight training equipment, aiming to solve the problem of insufficient real-time performance, safety, accuracy and efficiency caused by the dependence of existing airport regulation data processing on manual operation. The application comprises: identifying a target business scenario in a to-be-processed document through a scene recognition model; matching a data processing rule corresponding to the target business scenario based on a dynamic mapping table; executing the data processing rule to extract, convert and generate structured target data from a data area positioned by the business scenario; performing multi-dimensional quality assessment and verification on the target data to generate structured aviation data meeting preset accuracy requirements. The application realizes intelligent end-to-end processing of unstructured documents, improves efficiency and accuracy, endows the system with excellent flexibility and maintainability, ensures high reliability of output data, and provides strong technical support for key data management in the aviation field.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, and specifically relates to a method and system for processing airport regulations data based on flight training equipment. Background Technology

[0002] Flight simulators are crucial equipment for training pilots and ensuring aviation safety, and their operation heavily relies on accurate, real-time airport operational data. This data typically originates from Airport Information Publications (AIPs) published by civil aviation authorities in various countries, covering a vast amount of information such as airport geographical location, runway physical characteristics, navigation facility parameters, and communication frequencies. However, airport information publications are usually unstructured or semi-structured documents such as PDFs, with complex formats, varying layouts, and frequent updates.

[0003] Currently, extracting data from airport regulations for use in flight simulators primarily relies on manual reading, understanding, summarizing, and formatting. In implementing the solution disclosed in this application, the inventors identified at least the following previously unresolved problems in the existing technology: low efficiency, high cost, and difficulty in handling batch processing and frequent updates of multiple airports; when adapting to new airports or processing batches of documents, the workload is enormous, project cycles are long, and costs are difficult to control. Furthermore, data accuracy cannot be guaranteed; complex cross-section relationships (such as the relationship between runway length and available takeoff distance) can easily lead to errors or omissions in the extraction of key coordinates, frequencies, and other information, directly affecting the realism and safety of simulation training. In addition, the severe lag in manual processes prevents the simulator database from synchronizing with the current situation, introducing security risks. Finally, the entire process lacks systematization and security guarantees; the processing logic relies on personal experience, making standardization, reuse, and traceability difficult, and there is a lack of necessary security controls for sensitive aviation data.

[0004] Furthermore, there is a lack of systematic management and traceability mechanisms. Data extraction rules and verification logic often rely on the experience of processing personnel, making them difficult to standardize and reuse. Once data problems occur, it is difficult to trace its source, extraction rules, and processing procedures, posing a significant challenge to problem investigation and quality control. At the same time, the processing of sensitive aeronautical data such as coordinates and frequencies also lacks necessary security measures.

[0005] Therefore, how to automate and intelligently process airport regulations documents to generate structured aviation data efficiently and accurately, while ensuring high quality, timeliness, and security of the data, is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] To address the aforementioned problems in the existing technology, namely the insufficient real-time performance, security, accuracy, and efficiency due to the reliance on manual processing of airport regulations data, the first aspect of this invention proposes a method for processing airport regulations data based on flight training equipment. This method includes the following steps:

[0007] Receive and parse the airport rules document of the target airport;

[0008] Based on the airport rules document, at least one target business scenario is identified and located using a pre-set scene recognition model; the target business scenario is a data area in the airport rules document that has independent business meaning.

[0009] Based on the identification result of the business scenario, a matching is performed in a preset dynamic mapping table to obtain the data processing rules corresponding to the target business scenario; the dynamic mapping table is used to store the mapping relationship between business scenario identifiers and data processing rules;

[0010] Based on the data processing rules, structured target data is extracted, transformed, and generated from the data area located in the business scenario;

[0011] The target data is subjected to multi-dimensional quality assessment and verification to generate structured aeronautical data that meets preset accuracy requirements.

[0012] In some preferred embodiments, at least one business scenario in a document is identified and located using a pre-set scene recognition model. The method is as follows:

[0013] A pre-trained aviation terminology language model is used to identify preset aviation keywords in the airport regulations document in order to extract text features;

[0014] Regular expressions are used to identify table boundary symbols, spatial relationship descriptions, and page number anchors in the airport rules document in order to extract format features; wherein, the extraction of format features supports location in cross-page scenarios;

[0015] Based on text features and / or format features, locate the physical location of the target business scenario in the document and output the location result containing the scenario's unique identifier.

[0016] In some preferred embodiments, the data processing rules corresponding to the target business scenario are obtained by means of:

[0017] Parse the dynamic mapping table to obtain the rule metadata corresponding to the unique identifier of the target business scenario. The rule metadata includes rule priority, extracted rule list, conflict rule set and conflict resolution strategy.

[0018] If multiple data processing rules applicable to the business scenario are matched in the extraction rule list, scheduling is performed according to the priority defined in the dynamic mapping table;

[0019] During the scheduling process, if the data processing rule to be executed exists in the conflict rule set, it will be automatically adjudicated according to the conflict resolution strategy.

[0020] In some preferred embodiments, the target data undergoes multi-dimensional quality assessment and verification, including the following:

[0021] A three-layer verification mechanism is implemented, which includes, in a fixed order, an internal verification to check the existence and redundancy of the fields in the target data, a format verification to check the format standardization and unit consistency of the target data, and a logical verification to check whether the target data conforms to aviation business logic.

[0022] Based on preset evaluation dimensions and weights, the target data is scored in multiple dimensions to calculate a comprehensive quality score.

[0023] In some preferred embodiments, the multi-dimensional quality assessment and verification further includes performing a cross-chapter global comparison. Based on a pre-set cross-chapter association rule base, consistency verification is performed on target data extracted from different business scenarios in the airport rules document. The method is as follows:

[0024] Based on the structure or textual characteristics of the airport rules document, establish a chapter index and generate a page number mapping table that records the page number range of each chapter;

[0025] Based on the mapping table, extract key values ​​from at least two different chapters;

[0026] Based on preset cross-chapter association rules, the association of the key values ​​extracted from different chapters is verified.

[0027] In some preferred embodiments, the association rules in the cross-chapter association rule base are divided into multiple priorities; the step of performing a cross-chapter global comparison further includes:

[0028] Based on the results of the correlation verification and the priority of the correlation rules that caused the verification failure, the data that failed the verification is processed in a hierarchical manner.

[0029] The tiered processing includes blocking data output, triggering manual review, or simply generating a prompt message;

[0030] Specifically, when the validation of a core priority rule fails, the output of structured aeronautical data is blocked; when the validation of a non-core priority rule fails, output is allowed but a warning or prompt message is generated.

[0031] In some preferred embodiments, the method further includes:

[0032] The system periodically polls the official data release platform and monitors data updates by comparing the MD5 value or chapter revision date of the airport regulations document.

[0033] If a data update is detected, an incremental automated processing flow for the updated chapter is triggered.

[0034] In some preferred embodiments, the method further includes:

[0035] Version management is performed on the data processing rules in the dynamic mapping table, recording the version number, modification time, and modification content of each rule;

[0036] Provides a version rollback function, allowing rules to be restored to a specified historical stable version.

[0037] In some preferred embodiments, the method further includes:

[0038] At each stage of quality assessment and verification, record data traceability information, including data source, rule ID and version used, conversion algorithm and verification results;

[0039] Data security management is implemented for sensitive data in the airport rules document throughout the entire process of extraction, storage, and transmission; the sensitive data includes airport coordinates and navigation frequencies.

[0040] In another aspect, the present invention proposes an airport regulations data processing system based on flight training equipment, the system comprising:

[0041] The scene recognition module is used to identify and locate at least one target business scene based on the received and parsed airport rules document and using a pre-set scene recognition model; the target business scene is a data area in the airport rules document that has independent business meaning.

[0042] The rule matching module is used to match the business scenario identification result in a preset dynamic mapping table to obtain at least one data processing rule corresponding to the target business scenario; the dynamic mapping table is used to store the mapping relationship between business scenario identifiers and data processing rules.

[0043] The data processing module is used to extract, transform, and generate structured target data from the data area located in the business scenario based on the data processing rules.

[0044] The data quality verification module is used to perform data quality verification on the target data to output the final data that meets the preset quality standards.

[0045] The beneficial effects of this invention are:

[0046] 1. The scene recognition module intelligently locates the target business scenario in the document, and the rule matching module dynamically schedules the corresponding data processing rules. It can accurately adapt to airport rules documents with different formats and chapter structures, thus effectively solving the problem of dependence on fixed templates in traditional methods. While achieving full-process automation, it ensures the accuracy and completeness of data extraction.

[0047] 2. An internal-to-external data quality verification process is adopted, which sequentially performs internal consistency verification, format standardization verification, and logical correlation verification. Through multi-level quality control measures, deep-seated logical contradictions can be discovered, such as key issues like mismatch between runway length and navigation facility requirements, thereby ensuring the accuracy and reliability of output data and providing a solid guarantee for flight safety.

[0048] 3. Decouple business rules from the core code and manage them uniformly through dynamic mapping tables, making the system highly flexible. Combined with the rule version management function, when civil aviation regulations are updated, only the rule configuration needs to be modified to quickly adapt without redeploying the system, thereby significantly reducing maintenance costs and improving the system's response speed to business changes.

[0049] 4. Establish a complete lineage record for each piece of data to achieve full-process traceability; at the same time, by monitoring changes in the data source and triggering incremental processing, the waste of resources in full-process processing is avoided, so that the system can maintain high efficiency and stability in long-term operation and meet the high standards of data traceability requirements in the aviation industry. Attached Figure Description

[0050] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0051] Figure 1 This is a flowchart of an airport rules data processing method based on flight training equipment in an embodiment of the present invention;

[0052] Figure 2 This is a structural block diagram of an airport rules data processing system based on flight training equipment, as described in an embodiment of the present invention.

[0053] Figure 3 This is a schematic diagram of the structure of a computer system used to implement the methods, systems, and electronic devices of this application. Detailed Implementation

[0054] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0055] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0056] This application provides a method for processing airport regulations data based on flight training equipment. This method constructs a closed-loop process of scene recognition, dynamic rule mapping, automated processing, and multi-level verification, achieving end-to-end intelligent processing of unstructured documents. It accurately adapts to airport regulations documents of different formats and chapter structures, solving the technical challenge of heterogeneous data conversion between unstructured data sources and structured databases, and realizing full-link automation and intelligence in the processing flow. Through dynamic rule mapping and modular design, the system is endowed with excellent flexibility and maintainability. A rigorous multi-level quality verification system is constructed to ensure the extremely high reliability and credibility of the output data.

[0057] To more clearly explain the airport regulations data processing method based on flight training equipment of the present invention, the following is in conjunction with... Figure 1 The steps in the embodiments of the present invention will be described in detail below.

[0058] The airport regulations data processing method based on flight training equipment according to the first embodiment of the present invention includes steps S1-S5, each step of which is described in detail below:

[0059] S1. Receive and parse the airport details document of the target airport;

[0060] Receive airport rules documents from data sources (such as the Civil Aviation Administration's official database or electronic document library), and preprocess the documents, including but not limited to: using optical character recognition technology to recognize text in scanned documents and parsing the physical and logical structure of the documents (such as chapters, page numbers, tables, and paragraphs).

[0061] S2. Based on the preprocessed airport rules document, identify and locate at least one target business scenario (such as airport basic data, runway parameters, navigation facilities, and integrated equipment) through a pre-set scene recognition model; the target business scenario is a data area in the airport rules document that has independent business meaning.

[0062] Preferably, at least one business scenario in the document is identified and located using a pre-set scene recognition model, the method being as follows:

[0063] A pre-trained aviation terminology language model is used to identify preset aviation keywords in the airport regulations document in order to extract text features;

[0064] Regular expressions are used to identify table boundary symbols, spatial relationship descriptions, and page number anchors in the airport rules document in order to extract format features; wherein, the extraction of format features supports location in cross-page scenarios;

[0065] Based on text features and / or format features, locate the physical location of the target business scenario in the document (e.g., start line number, end line number, and page number), and output the location result containing a unique scene identifier (sceneID).

[0066] By combining the analysis results of text features and format features, an internal decision fusion unit accurately determines the physical boundary of the target business scenario in the document and outputs a location result containing a unique scenario identifier. It can not only handle well-structured documents, but also has excellent recognition robustness and location accuracy for complex documents such as airport rules documents containing a large amount of unstructured text and cross-page tables. At the same time, through dynamic rule mapping, the computational load of the processor when parsing complex documents is reduced.

[0067] In this embodiment, the pre-set scene recognition model is a pre-trained aviation terminology language model. This model is based on the BERT architecture and has been fine-tuned on large-scale aviation-related texts (such as aeronautical data compilations, technical manuals, and technical dictionaries). This model can accurately identify and understand the contextual semantics of professional terms such as "ICAO", "IATA", "ARP coordinates", "VOR / DME", "ILS", "runway true bearing", "elevation", and "entrance inward movement", thereby initially determining the business domain to which the document content belongs.

[0068] In some embodiments, the method for pre-training an aviation terminology language model is as follows:

[0069] 1) Obtain fine-tuning data; the data types include:

[0070] Airborne Information Processing (AIP): Contains core data such as airport geographic information, runway parameters, and arrival and departure procedures;

[0071] Airport Operations Manual (OM): Covers ground operations, emergency procedures, and equipment usage guidelines;

[0072] Aviation technical dictionaries: ICAO terminology database, FAA aviation glossary, etc.;

[0073] Historical flight training data: simulator training logs, airport regulations assessment question bank.

[0074] The training data sources mentioned above include:

[0075] Official institutions: ICAO (International Civil Aviation Organization) database, public documents from national civil aviation authorities (such as FAA, CAAC);

[0076] Airport operator: Detailed updated documents and engineering drawings provided by the airport management company;

[0077] Training institutions: Scenario data accumulated by flight simulation equipment manufacturers (such as training manuals for L3Harris and CAE).

[0078] In terms of data scale, preferably, the total amount of text should be no less than 500,000 sentences of professional text in the aviation field (approximately 10GB of raw data); the scenarios should cover detailed documents of at least 200 airports, including 10+ core business scenarios such as runways, navigation facilities, and weather conditions; and 50,000 to 100,000 sentences of samples should be manually annotated (annotating business scenario categories and key entities) for fine-tuning and supervised training.

[0079] 2) Taking the BERT derivative model as an example, as an aviation terminology language model, its key features include:

[0080] Input layer extension: Add layout features (such as paragraph numbering and font size encoding) to the text token to adapt to the layout format of airport rules;

[0081] Domain-specific glossary: ​​Add 500-1000 aviation-specific terms (such as "approach lighting system" and "runway visual range") to the existing glossary to improve the accuracy of term embedding;

[0082] Attention mechanism optimization: Fine-tuning allows the model to assign higher attention weights to key information such as "ICAO code" and "coordinate values";

[0083] Output layer design: adopts a multi-label classification header (each business scenario corresponds to one label), and supports complex situations where a single text segment belongs to multiple scenarios (such as a text segment involving both runway parameters and navigation facilities).

[0084] 3) Set key fine-tuning parameters and training strategies, including learning rate, batch size, and number of training epochs; preferably, the parameters are set as follows:

[0085] Learning rate: initially set to (BERT-base) or (Small model), employing a linear decay strategy;

[0086] Batch size: Set to 8-32 based on hardware configuration (32 is recommended for GPU memory ≥16GB);

[0087] Training epochs: 5-10 epochs, dynamically adjusted based on validation set accuracy (to avoid overfitting); weight decay: 0.01 (to suppress parameter overfitting).

[0088] The training strategy employs domain-adaptive pre-training. Based on the general BERT, it first performs secondary pre-training using unlabeled aviation text (Masked Language Model task) to learn the distribution of domain terms. Then, it performs multi-task fine-tuning, simultaneously training "scene classification" and "entity recognition" tasks (such as using ARP coordinates, runway orientation, etc. as entity labels) to improve the model's sensitivity to technical terms. At the same time, it performs operations such as synonym replacement (e.g., swapping "ILS" and "Instrument Landing System") and sentence restructuring on scarce scene texts to expand the training samples.

[0089] Through the above design, the pre-trained aviation terminology language model can accurately adapt to the professional scenario division requirements of airport regulations while maintaining the original semantic understanding ability, thus meeting the requirements of this application.

[0090] More preferably, format features are extracted using regular expressions combined with layout analysis algorithms, specifically including:

[0091] Table boundary character matching: Use patterns such as "|" and "---" to identify the start and end positions of the table;

[0092] Spatial relationship description matching: Using patterns such as "distance(.{2,10}runway).{1,10}MAG.{1,10}m", the relative orientation and distance information between navigation facilities and runways are extracted;

[0093] Page number anchor matching: Use the pattern "[AZ]{4}AD2-\d+" (such as "ZSSSAD2-25") to accurately locate the physical page number of the chapter;

[0094] Chapter title recognition: Quickly locate chapter titles using regular expressions with a fixed format, such as "AD2\.\d+\s+.+".

[0095] S3. Based on the identification result of the business scenario, match it in a preset dynamic mapping table to obtain the data processing rules corresponding to the target business scenario; the dynamic mapping table is used to store the mapping relationship between business scenario identifiers and data processing rules.

[0096] Preferably, the method for obtaining the data processing rules corresponding to the target business scenario is as follows:

[0097] Parse the dynamic mapping table to obtain the rule metadata corresponding to the unique identifier of the target business scenario. The rule metadata includes rule priority, extracted rule list, conflict rule set and conflict resolution strategy.

[0098] If multiple data processing rules applicable to the business scenario are matched in the extraction rule list, scheduling is performed according to the priority defined in the dynamic mapping table;

[0099] During the scheduling process, if the data processing rule to be executed exists in the conflict rule set, it will be automatically adjudicated according to the conflict resolution strategy.

[0100] More preferably, the dynamic mapping table is a structured configuration file (such as JSON, XML, or a database table), as shown in Table 1, whose standard structure includes, but is not limited to, the fields in the table.

[0101] In Table 1, the English terms used correspond one-to-one with the Chinese terms used in the claims and other parts of the specification of this application. For example, as shown in "Meaning and Examples", sceneID corresponds to the unique identifier of the scene; priority corresponds to the rule priority; condition corresponds to the triggering condition; extractRules corresponds to the set of data extraction rules; conflictSet corresponds to the set of conflict rules; and resolution corresponds to the conflict resolution strategy.

[0102] Table 1

[0103]

[0104] Specifically, in this embodiment, obtaining the data processing rules corresponding to the target business scenario involves:

[0105] The system receives the unique scene identifier "sceneID" of the target business scenario, and then queries the dynamic mapping table to find all matching rule metadata, including rule priority, extracted rule list, conflict rule set and conflict resolution strategy.

[0106] The "extractRules" field of the matching rule metadata is parsed. These rules include: regular expressions for extracting coordinates, mathematical formulas for unit conversion, mapping dictionaries for data normalization, etc.; scheduling is performed according to the priority defined in the dynamic mapping table to ensure that high-priority rules process core data first.

[0107] At the same time, the "conflictSet" field of the rule metadata is checked. If there is a potential conflict between the rule of the current scenario and other scenario rules that are being executed or about to be executed, an automatic decision is made based on the priority and resolution fields.

[0108] In some embodiments, when adding or modifying rules, the system scans the "conflictSet" field of the dynamic mapping table in real time. If the new rule has potential conflicts with the existing rules, such as overlapping scenario conditions or contradictory extraction targets, an alert will be immediately displayed, showing the conflicting rule ID and type (such as "scenario condition conflict"), and providing adjustment suggestions (such as narrowing the regular expression matching range).

[0109] The adjudication strategy includes:

[0110] PRIORITY: Compare the priorities of conflicting rules. The rule with higher priority takes effect (e.g., the rule with priority 100 takes precedence over the rule with priority 80), and the basis for the decision and the invalidated rule are recorded.

[0111] MERGE: Merging is not the result of mutually exclusive rules. It retains unique fields, and for overlapping fields, it takes the value with the higher priority of the data source (e.g., CAACOfficial source takes precedence). It marks the merged fields and sources; for example, when the same facility is partially updated in different chapters.

[0112] EXCEPTION: When a conflict cannot be automatically resolved (e.g., when priorities are the same and objectives are contradictory), manual intervention is triggered, a conflict exception report is generated and sent to the auditor, and processing continues after confirmation.

[0113] Preferably, in this embodiment, a conflict log is recorded, which records the conflict rule ID, processing time, adjudication strategy, and scope of impact (involving airports, chapters, and data types). It supports filtering by conflict type, time, and airport, providing data support for rule optimization.

[0114] The rule management approach based on dynamic mapping tables decouples the system's data processing logic from the code itself. When civil aviation regulations change or data standards are updated, only this mapping table needs to be modified for rapid adaptation, greatly improving the system's maintainability and flexibility. For example:

[0115] A new scene for the AD2.19 combined equipment at ZYHB Airport has been added, with the sceneID set to "ZYHB_AD2.19_IDME".

[0116] Adjust the regex expression of the condition to match the airport's packaging identifier (e.g., "packaged with GP05L").

[0117] The associated extractRules are ["rule_id_101","rule_id_102"], which reuse the extraction rules for the combined equipment.

[0118] S4. Based on the data processing rules, extract, transform, and generate structured target data from the data area located in the business scenario;

[0119] Data extraction: Extract raw data fragments from the located scene area according to the extraction rules defined in the rules;

[0120] Data cleaning and standardization: Perform unit conversion, value range normalization, and outlier handling on the extracted data to eliminate inconsistencies in the source data;

[0121] Structured assembly: Encapsulating processed data into structured data objects with predefined patterns (such as JSON).

[0122] Furthermore, the extraction rules include, but are not limited to:

[0123] Regular expression matching: used to precisely extract data with fixed patterns, such as runway number ("RWY 01 / 19"), elevation ("ELEV 123.4FT"), frequency ("ATIS 123.675");

[0124] Natural Language Processing (NLP) parsing: used to understand and extract unstructured text information. For example, using Named Entity Recognition (NER) technology to extract key entities such as "pavement materials" and "maintenance units" from descriptive paragraphs;

[0125] Table parser: Specifically designed to parse table structures, it locates and extracts data from specific cells by recognizing table headers and row / column coordinates. For example, it can extract the "length," "width," and other row data corresponding to the "runway number" column in the "Runway Physical Characteristics Table."

[0126] S5. Perform multi-dimensional quality assessment and verification on the target data to generate structured aeronautical data that meets preset accuracy requirements, including at least one of the following:

[0127] A three-layer verification mechanism is implemented, which includes the following steps in a fixed order:

[0128] The system includes internal checks to verify the existence and redundancy of fields in the target data, format checks to verify the format standardization and unit consistency of the target data, and logical checks to verify whether the target data conforms to aviation business logic.

[0129] Perform cross-chapter global comparison, and based on the pre-set cross-chapter association rule library, perform consistency verification on the target data extracted from different business scenarios of the airport rules document;

[0130] Based on preset evaluation dimensions and weights, the target data is scored in multiple dimensions to calculate a comprehensive quality score.

[0131] More preferably, in this embodiment, the three-layer verification mechanism is specifically as follows:

[0132] 1) Internal validation: Check whether data extracted from the same scenario is self-consistent, verify the validity of the data source, the existence of fields, and the consistency of basic logic to ensure that the data source has no fundamental errors. Specifically, this includes:

[0133] Are the physical properties of the runway, such as "length," "strength," and "surface," reasonable? Does the range of values ​​in a table conform to common sense? Check if key fields such as LOCID, DME frequency, and GP glide slope exist.

[0134] Check for duplicate or invalid data. If found, mark the data as "data redundancy" or "invalid data" and record the page number and line number of the redundant / invalid data.

[0135] Basic logic consistency is required. For example, the deviation between the runway length in AD2.12 and the TORA in AD2.13 (due to the inward shift of the entrance) must be within ±2% tolerance (e.g., the length of runway ZSSS18L is 3400m, while the TORA in AD2.13 is 3300m, the deviation is (3400-3300) / 3400≈2.94%. If the preset tolerance is ±3%, it is compliant; if the tolerance is exceeded, it will be marked as "basic logic abnormal"); the runway number of the same airport must be unique (e.g., there should be no duplicate "18L" runway records).

[0136] 2) Format Verification: Based on the target data format specifications, verify the data format conformity, unit consistency, and frequency band validity to ensure that the data can be parsed by the simulator tools. Specifically, this includes:

[0137] The coordinate format must be correct; the coordinate values ​​must conform to a specific latitude and longitude format.

[0138] The correctness of the regular expression format is checked, including the PCN code (e.g., "85 / R / B / W / T"), the runway number (e.g., "18L" "05"), etc., to ensure they conform to the preset regular expression. If they do not conform, they are marked as "format abnormal". The units of the same parameter are checked to ensure they are consistent.

[0139] Verify that the device frequency is within the standard frequency band;

[0140] Airport codes must be in uppercase English letters.

[0141] 3) Logical verification: This is achieved through a cross-chapter global comparison method. The verification data conforms to the operational logic of aviation, ensuring the simulator scenario is realistic and effective. Specifically, this includes:

[0142] Runway physical logic: Runway length > width (e.g., ZSSS18L runway length 3400m > width 45m, otherwise marked as "logic error");

[0143] Equipment parameter logic: The GP glide angle is within a reasonable range of 2.5°-4.0° (e.g., 3° ​​is compliant, 5° is marked as "abnormal"); the deviation between the DME elevation and the airport elevation is within a reasonable range (e.g., if the airport elevation is 10m and the DME elevation is 50m, the deviation is marked as abnormal).

[0144] Cross-component consistency: The runway number suffixes of LOC, GP, and DME within the same IDME must be consistent (e.g., LOC18L corresponds to GP18L and DME18L; if they are inconsistent, they will be marked as "runway number conflict").

[0145] Equipment parameter correlation: LOC frequency and DME channel must match (e.g., LOC frequency 111.3MHz corresponds to DME channel CH50X-CH55X, but if it is actually CH40X, then mark "parameter correlation abnormal"); GP glide angle and runway threshold elevation must be compatible (e.g., if the glide angle is too large and the landing height deviation exceeds the threshold, then mark it as abnormal).

[0146] More preferably, the multi-dimensional quality assessment and verification also includes performing a cross-chapter global comparison. Based on a pre-set cross-chapter association rule base, consistency verification is performed on target data extracted from different business scenarios in the airport rules document. The method is as follows:

[0147] Based on the structure or textual characteristics of the airport rules document, a chapter index is established, and a global page number mapping table is created for the entire document to record which chapters and page numbers each key data element (such as runway markings and navigation beacon markings) appears in.

[0148] Based on the mapping table, key values ​​that can be associated with data are extracted from different chapters, such as runway number ("RWY18L / 36R") and navigation facility name ("IZMIR VOR").

[0149] Based on preset cross-chapter association rules, the association of the key values ​​extracted from different chapters is verified.

[0150] Preferably, the process of creating a chapter index includes the following:

[0151] Parse the bookmarks in the airport regulations PDF and generate a page number mapping table M for the core chapters;

[0152] If the PDF has no bookmarks (such as a scanned document), the chapter position is located by matching text features (such as chapter titles), a temporary page number mapping table is generated, and "no bookmark index" is marked, prompting technical personnel to check the chapter integrity.

[0153] Specifically, the association rules of the cross-chapter association rule base are divided into multiple priorities, as shown in Table 2, including P1 priority (core mandatory verification), P2 priority (important verification) and P3 priority (auxiliary verification).

[0154] Table 2

[0155]

[0156] In this embodiment, performing a cross-chapter global comparison further includes:

[0157] Based on the results of the correlation verification and the priority of the correlation rules that caused the verification failure, the data that failed the verification is processed and fed back in a hierarchical manner, as shown in Table 3.

[0158] Table 3

[0159]

[0160] More preferably, the multi-dimensional scoring includes data completeness, data accuracy, data consistency, and data timeliness, which are weighted and scored to provide a quantitative basis for data credibility; in this embodiment, preferably:

[0161] Data integrity is measured by the missing rate of key fields, which is calculated as (total number of fields - number of missing fields) / total number of fields × 100. Missing fields include "null" or unlabeled content. Non-core fields (such as DME channels) have a lower weight than core fields (such as LOC frequencies).

[0162] Data accuracy is measured by the degree of deviation from official data, including:

[0163] Coordinate deviation = (1 - actual deviation / 10 meters) × 100 (deviation threshold 10 meters);

[0164] Numerical deviation = (1 - numerical deviation rate / allowable deviation threshold) × 100;

[0165] Data consistency is measured by the logical consistency of parameters, including: consistency of parameters within the same IDME, where all parameters are consistent and 100 points are awarded, with 20 points deducted for each inconsistency; consistency of data across chapters (such as the association between AD2.12 runway length and AD2.13 TORA), where consistency is awarded and 30 points are deducted for inconsistency.

[0166] Data timeliness is measured by the data update interval, which is calculated as (1 - update interval / 30 days) × 100 (time threshold of 30 days). 100 points are awarded for updates on the same day, and 0 points are awarded for updates that are more than 30 days old.

[0167] In some embodiments, when performing weighted scoring, the weights are pre-configured based on actual business needs, or obtained by training a machine learning regression model using historical data and expert scores.

[0168] In some embodiments, numerical deviation calculations target quantifiable key parameters in airport regulations, focusing on the following types (corresponding one-to-one with the chapter-specific processing rules):

[0169] Published distance categories: Available Takeoff Distance (TORA), Available Landing Distance (LDA);

[0170] Navigation equipment parameters: VOR / DME frequency, ILS glide slope angle, DME channel (numerical part), transmitting antenna elevation;

[0171] Runway physical parameters: runway length, width, entrance elevation, and touchdown zone elevation;

[0172] Geographic parameters: Airport reference point magnetic difference (decimal value), airport elevation.

[0173] In some embodiments, the multi-dimensional scoring division rule is as follows:

[0174] Overall score ≥ 80 points: Data quality is qualified and can be directly used for simulator adaptation;

[0175] 60 points ≤ Overall score < 80 points: Generate quality improvement suggestions (e.g., "Low integrity, DME channel needs to be added"), and technical personnel will review and correct them;

[0176] Overall score < 60 points: Trigger manual review process to re-examine the extraction and integration process until it meets the standard.

[0177] More preferably, the method further includes:

[0178] Full-chain information recording is carried out at every stage, including quality assessment and verification:

[0179] Matching and Extraction Stage: Record the source document name and version (e.g., CAACOfficial), the extracted original text fragment and chapter / page number (e.g., AD2.19ZSSSAD2-25), extraction time, processing rules and their versions used, processing timestamp, and operator; Conversion Stage: Record the conversion algorithm (e.g., "degrees, minutes, seconds to decimal V1.2"), calculation process (e.g., magnetic difference "5°46′W→-5.7667°"), original data, and result data; Verification Stage: Record the verification rule version, verification result (pass / abnormal), and abnormality handling method (automatic correction / manual review); Output Stage: Record the output format (e.g., CAE-GNDBS), recipient permissions, digital signature, and output time.

[0180] More preferably, the method further includes:

[0181] For sensitive data in the airport rules document, full-process encryption and access control are implemented throughout the extraction, storage, and transmission process; during access, identity authentication and permission verification are enforced to ensure that only authorized personnel or systems can access the decrypted data; the sensitive data includes airport coordinates and navigation frequencies (such as specific attributes of military airports, coordinates of undisclosed facilities, etc.).

[0182] In this embodiment, based on the RBAC (role-based access control) mechanism, roles such as "data extractor", "verification auditor" and "system administrator" are defined, and differentiated operation permissions are assigned (e.g., data extractors can only extract and view data, while administrators can configure rules and permissions).

[0183] Preferably, the method further includes:

[0184] The system periodically (e.g., every 24 hours) actively scans or polls the specified data source and monitors data updates by comparing the MD5 hash value, last revision date, or version number of the airport rules document. If a data update is detected, the system locates the changed chapters based on the document's update log or by comparing content differences. Then, it triggers an incremental processing flow from scene recognition to data verification only for these changed chapters.

[0185] The MD5 value of a rule is a 128-bit hash value calculated using the MD5 hash algorithm to represent the complete configuration content of a rule in a dynamic mapping table. Its core function is to "uniquely identify the rule content." Whenever any configuration field of a rule changes, its MD5 value will change accordingly. Therefore, it can be used as a "digital fingerprint" to determine whether a rule has been updated.

[0186] Preferably, the method further includes:

[0187] Version management is implemented for the data processing rules in the dynamic mapping table. A version number field is maintained for each rule in the dynamic mapping table. Any modification, addition, or deactivation of a rule will not directly overwrite the original rule. Instead, a new version record is created to record the version number, modification time, and modification content of each rule, as shown in Table 4. All historical versions are stored securely.

[0188] After a system upgrade, if new rules cause data processing anomalies or quality degradation, administrators can easily roll back specific rules or the entire rule set to any historical stable version through the management interface. This mechanism provides strong security for the stable operation and iterative optimization of the system.

[0189] Table 4

[0190]

[0191] Record all user actions (action time, type, content, and result) to form a complete audit log, supporting the tracing of abnormal operations; the log retention period is no less than 6 months, in accordance with the requirements of the "Civil Aviation Data Security Management Measures" (CCAR-244-R1).

[0192] Although the steps in the above embodiments are described in the above order, those skilled in the art will understand that in order to achieve the effect of this embodiment, different steps do not need to be executed in such order. They can be executed simultaneously (in parallel) or in reverse order. These simple changes are all within the protection scope of this application.

[0193] Preferably, in this embodiment, taking the processing of airport regulations documents of a domestic airport as an example, the implementation process of the airport regulations data processing method based on flight training equipment of this application will be described in detail:

[0194] 1) Receive and parse the airport rules document of the target airport;

[0195] The system receives instructions to process the airport regulations PDF document. Using the document page number "ZSSSAD2-25 / 2-26" as the anchor point, it first uses a natural language processing model (such as BERT model) based on a pre-trained aviation terminology database to quickly identify the title of the "Radio Navigation and Landing Facilities" section within that page range.

[0196] 2) Identify and locate at least one target business scenario;

[0197] Using the page number "ZSSSAD2-25 / 2-26" as an anchor, execute a first-match in the remarks column using the regular expression "^|. combined with GP\d+[LR]|$", and return the coordinate range [12, 15] in real-time (corresponding to the LOC18L, GP18L, DME18L data rows), accurately locate the combined equipment scenario. Scan the remarks column of the table using the previously defined text pattern, successfully match the text identifying the combined equipment, define it as the target business scenario, and output its coordinate range as the scenario location result. Determine it as the AD2.19 navigation facility scenario, and the sceneID is "AD2.19_IDME".

[0198] 3) Match the data processing rules corresponding to the target business scenario;

[0199] Based on "AD2.19_IDME", match the configuration entries in the dynamic mapping table. According to the settings of this entry, schedule the associated extraction rules "rule_id_101" (extract LOC / GP parameters) and "rule_id_102" (extract DME parameters) to prepare for processing the located data rows. If a conflict rule is triggered, according to the "PRIORITY" strategy, select the rule with a higher priority to take effect.

[0200] 4) Based on the data processing rules, extract, transform, and generate structured target data from the data area located by the business scenario, specifically including:

[0201] According to the rule rule_id_101, adopt a slicing strategy of "the upper 2 rows + the remarks row", and regard the three recognized data rows (LOC, GP, DME) as a complete processing unit. Through the "three-row verification" logic, confirm that the runway numbers of the three data rows are the same and meet their respective feature descriptions (such as the GP row remarks contain "glide slope angle", and the DME row remarks contain "combined with GPXX"), and reconfirm the accuracy of the extraction unit. Execute the transformation logic, such as converting the coordinate in degrees, minutes, and seconds format "N311047.6E1212014.2" to the decimal coordinate "N31.1799°E121.3373°", and extract the value "3°" from the GP row remarks "glide slope angle 3°".

[0202] According to the rule rule_id_102, the system extracts DME-related fields within the same extraction unit and executes the transformation logic. For example, unify the original ID "ipk" to uppercase "IPK", and synchronously convert the elevation "10m" to "10m / 32.8ft" including the imperial unit.

[0203] During the extraction and conversion process, key information is recorded throughout, including data source, chapter and page numbers, rules and versions used, and conversion algorithms. Simultaneously, sensitive data such as coordinates and frequencies are automatically encrypted and stored.

[0204] 5) After data integration, a three-layer verification mechanism and cross-chapter global comparison are performed;

[0205] Internal verification checks for missing LOCID and DME frequencies; format verification: coordinate conversion is correct, and units are uniformly "meters (feet)"; in logic verification, verify whether the GP glide angle "3°" is within a reasonable business range (e.g., 2.5°-4.0°).

[0206] When performing a cross-chapter global comparison, the system applies a preset P1-level (core mandatory verification) association rule for validation. The validation logic of this rule can be expressed as the following formula:

[0207] The available takeoff distance (TORA) in AD2.13 is calculated as: runway length in AD2.12 - inward displacement distance. The system extracts the length of runway 18L from the corresponding chapter as 3400m, and the inward displacement distance is 100m. The calculated TORA should be 3300m, which is completely consistent with the TORA value extracted from AD2.13 and passes the verification.

[0208] 6) Calculate the overall score:

[0209] The data integrity score is 93.3 (missing one non-core field), accuracy score is 100 (no deviation from official coordinates), consistency score is 100 (no logical contradictions), and timeliness score is 83.3 (update interval 5 days). Therefore, the overall score is calculated as follows: 93.3 × 30% + 100 × 30% + 100 × 25% + 83.3 × 15% ≈ 95.3. The overall score calculated for this processing is approximately 95.3, far exceeding the passing score of 80, and the data is deemed high-quality and acceptable.

[0210] 7) Generate structured data output, which clearly lists various information: the equipment type is "IDME", the corresponding runway number is "18L", and detailed parameters of LOC, GP, and DME are recorded hierarchically, such as ID, frequency, coordinates, glide slope, and elevation. Additionally, the output includes metadata such as a comprehensive data quality score (97.5 points), data update time, data source, and the version of the rules used, for subsequent use and traceability. The output file also includes a digital signature based on the system's private key for the recipient to verify data integrity.

[0211] Preferably, before retrieving the document, initialization settings are performed, including the following:

[0212] Configure dynamic mapping tables, set encryption information, set differentiated permissions for different access levels, and set update monitoring cycles, etc. Among them, configuring dynamic mapping tables defines its various parameters through textual descriptions, including: scene identifier, rule priority, triggering conditions, associated extraction rules, potential conflict rule sets, conflict resolution strategies, and other metadata.

[0213] After configuration, the system begins executing the data processing flow; please refer to [link / reference] for details. Figure 1 The method flowchart.

[0214] A second embodiment of the present invention provides an airport regulations data processing system based on flight training equipment, used to execute the aforementioned airport regulations data processing method based on flight training equipment, with reference to... Figure 2 The system includes:

[0215] The scene recognition module is used to identify and locate at least one target business scene based on the received and parsed airport rules document and using a pre-set scene recognition model; the target business scene is a data area in the airport rules document that has independent business meaning.

[0216] The rule matching module is used to match the business scenario identification result in a preset dynamic mapping table to obtain at least one data processing rule corresponding to the target business scenario; the dynamic mapping table is used to store the mapping relationship between business scenario identifiers and data processing rules.

[0217] The data processing module is used to extract, transform, and generate structured target data from the data area located in the business scenario based on the data processing rules.

[0218] The data quality verification module is used to perform data quality verification on the structured target data to output the final data that meets the preset quality standards.

[0219] More preferably, the data processing module includes a security management unit and an update monitoring unit. Before starting the data processing task, the system first needs to be initialized and configured.

[0220] 1) Configure a security management unit; to ensure data security throughout its entire lifecycle, the system sets up strong encryption algorithms (such as AES-256) for sensitive information such as runway coordinates and navigation frequencies, and configures secure transmission protocols (such as SSL / TLS) to ensure secure data transmission. Simultaneously, a role-based access control mechanism has been implemented, creating roles such as "Data Extractor," "Verification Auditor," and "System Administrator" and assigning differentiated permissions to ensure clear responsibilities. All user actions are recorded, forming a complete audit log.

[0221] 2) Configure the update monitoring unit; to ensure data timeliness, the system establishes an interface connection with the official data publishing platform (such as a library platform). In this example, the polling interval is set to 1 month, and the trigger condition for incremental updates is set to a change in the document's checksum (such as MD5 value) or an update of the chapter revision date, ensuring that the system only initiates the update process when the content of the official document undergoes substantial changes.

[0222] 3) Configure a dynamic mapping table. This table serves as a bridge connecting scenarios and rules, giving the system high flexibility and scalability.

[0223] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process and related descriptions of the system described above can be found in the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0224] It should be noted that the airport regulations data processing method and system based on flight training equipment provided in the above embodiments are only illustrative examples of the above functional module division. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the modules or steps in the embodiments of the present invention can be further decomposed or combined. For example, the modules in the above embodiments can be merged into one module, or further divided into multiple sub-modules to complete all or part of the functions described above. The names of the modules and steps involved in the embodiments of the present invention are only for distinguishing the various modules or steps and are not considered as an improper limitation of the present invention.

[0225] A device according to a third embodiment of the present invention includes:

[0226] At least one processor;

[0227] and a memory communicatively connected to at least one of the processors;

[0228] The memory stores instructions that can be executed by the processor to implement the above-described airport rules data processing method based on flight training equipment.

[0229] A fourth embodiment of the present invention provides a computer-readable storage medium storing computer instructions, which are executed by the computer to implement the above-described airport rules data processing method based on flight training equipment.

[0230] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process and related descriptions of the storage device and processing device described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0231] The following is for reference. Figure 3 It shows a schematic diagram of the structure of a computer system for implementing embodiments of the systems, methods, and electronic devices of this application. Figure 3 The server shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0232] like Figure 3 As shown, the computer system includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes based on programs stored in Read Only Memory (ROM) 302 or programs loaded from storage section 308 into Random Access Memory (RAM) 303. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

[0233] The following components are connected to I / O interface 305: an input section 306 including a keyboard, mouse, etc.; an output section 307 including a cathode ray tube (CRT), liquid crystal display (LCD), and speakers, etc.; a storage section 308 including a hard disk, etc.; and a communication section 309 including a network interface card such as a LAN (Local Area Network) card and a modem, etc. The communication section 309 performs communication processing via a network such as the Internet. A drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0234] Specifically, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the functions defined in the methods of this application. It should be noted that the computer-readable medium described above in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on a computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0235] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0236] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0237] The terms “first”, “second”, etc., are used to distinguish similar objects, not to describe or indicate a specific order or sequence.

[0238] The term "comprising" or any other similar term is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus / device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent in such process, method, article, or apparatus / device.

[0239] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

Claims

1. A method for processing airport regulations data based on flight training equipment, characterized in that, The method includes the following steps: Receive and parse the airport rules document of the target airport; Based on the airport rules document, at least one target business scenario is identified and located using a pre-set scene recognition model; the target business scenario is a data area in the airport rules document that has independent business meaning. Based on the identification result of the business scenario, a matching is performed in a preset dynamic mapping table to obtain the data processing rules corresponding to the target business scenario; the dynamic mapping table is used to store the mapping relationship between business scenario identifiers and data processing rules; The method for obtaining the data processing rules corresponding to the target business scenario is as follows: Parse the dynamic mapping table to obtain the rule metadata corresponding to the unique identifier of the target business scenario. The rule metadata includes rule priority, extracted rule list, conflict rule set and conflict resolution strategy. If multiple data processing rules applicable to the business scenario are matched in the extraction rule list, scheduling is performed according to the priority defined in the dynamic mapping table; During the scheduling process, if the data processing rule to be executed exists in the conflict rule set, an automatic decision will be made according to the conflict resolution strategy. Based on the data processing rules, structured target data is extracted, transformed, and generated from the data area located in the business scenario; The target data is subjected to multi-dimensional quality assessment and verification to generate structured aeronautical data that meets preset accuracy requirements; The target data undergoes multi-dimensional quality assessment and verification, including the following: A three-layer verification mechanism is implemented, which includes, in a fixed order, an internal verification to check the existence and redundancy of the fields in the target data, a format verification to check the format standardization and unit consistency of the target data, and a logical verification to check whether the target data conforms to aviation business logic. Based on preset evaluation dimensions and weights, the target data is scored in multiple dimensions to calculate a comprehensive quality score. The multi-dimensional quality assessment and verification also includes performing cross-chapter global comparisons. Based on a pre-built cross-chapter association rule base, consistency verification is performed on target data extracted from different business scenarios in the airport rules document. The method is as follows: Based on the structure or textual characteristics of the airport rules document, establish a chapter index and generate a page number mapping table that records the page number range of each chapter; Based on the mapping table, extract key values ​​from at least two different chapters; Based on preset cross-chapter association rules, the association of the key values ​​extracted from different chapters is verified.

2. The airport regulations data processing method based on flight training equipment according to claim 1, characterized in that, The method for identifying and locating at least one business scenario in a document using a pre-defined scene recognition model is as follows: A pre-trained aviation terminology language model is used to identify preset aviation keywords in the airport regulations document in order to extract text features; Regular expressions are used to identify table boundary symbols, spatial relationship descriptions, and page number anchors in the airport rules document in order to extract format features; wherein, the extraction of format features supports location in cross-page scenarios; Based on text features and / or format features, locate the physical location of the target business scenario in the document and output the location result containing the scenario's unique identifier.

3. The airport regulations data processing method based on flight training equipment according to claim 1, characterized in that, The association rules in the cross-chapter association rule base are divided into multiple priorities; The cross-chapter global comparison also includes: Based on the results of the correlation verification and the priority of the correlation rules that caused the verification failure, the data that failed the verification is processed in a hierarchical manner. The tiered processing includes blocking data output, triggering manual review, or simply generating a prompt message; Specifically, when the validation of a core priority rule fails, the output of structured aeronautical data is blocked; when the validation of a non-core priority rule fails, output is allowed but a warning or prompt message is generated.

4. The airport regulations data processing method based on flight training equipment according to claim 1, characterized in that, The method further includes: The system periodically polls the official data release platform and monitors data updates by comparing the MD5 value or chapter revision date of the airport regulations document. If a data update is detected, an incremental automated processing flow for the updated chapter is triggered.

5. The airport regulations data processing method based on flight training equipment according to claim 1, characterized in that, The method further includes: Version management is performed on the data processing rules in the dynamic mapping table, recording the version number, modification time, and modification content of each rule; Provides a version rollback function, allowing rules to be restored to a specified historical stable version.

6. The airport regulations data processing method based on flight training equipment according to claim 1, characterized in that, The method further includes: At each stage of quality assessment and verification, record data traceability information, including data source, rule ID and version used, conversion algorithm and verification results; Data security management is implemented for sensitive data in the airport rules document throughout the entire process of extraction, storage, and transmission; the sensitive data includes airport coordinates and navigation frequencies.

7. An airport regulations data processing system based on flight training equipment, characterized in that, The system includes: The scene recognition module is used to identify and locate at least one target business scene based on the received and parsed airport rules document and using a pre-set scene recognition model; the target business scene is a data area in the airport rules document that has independent business meaning. The rule matching module is used to match the business scenario identification result in a preset dynamic mapping table to obtain at least one data processing rule corresponding to the target business scenario; the dynamic mapping table is used to store the mapping relationship between business scenario identifiers and data processing rules. The data processing module is used to extract, transform, and generate structured target data from the data area located in the business scenario based on the data processing rules. The data quality verification module is used to perform data quality verification on the target data in order to output the final data that meets the preset quality standards. The method for obtaining the data processing rules corresponding to the target business scenario is as follows: Parse the dynamic mapping table to obtain the rule metadata corresponding to the unique identifier of the target business scenario. The rule metadata includes rule priority, extracted rule list, conflict rule set and conflict resolution strategy. If multiple data processing rules applicable to the business scenario are matched in the extraction rule list, scheduling is performed according to the priority defined in the dynamic mapping table; During the scheduling process, if the data processing rule to be executed exists in the conflict rule set, an automatic decision will be made according to the conflict resolution strategy. The target data undergoes multi-dimensional quality assessment and verification, including the following: A three-layer verification mechanism is implemented, which includes, in a fixed order, an internal verification to check the existence and redundancy of the fields in the target data, a format verification to check the format standardization and unit consistency of the target data, and a logical verification to check whether the target data conforms to aviation business logic. Based on preset evaluation dimensions and weights, the target data is scored in multiple dimensions to calculate a comprehensive quality score. The multi-dimensional quality assessment and verification also includes performing cross-chapter global comparisons. Based on a pre-built cross-chapter association rule base, consistency verification is performed on target data extracted from different business scenarios in the airport rules document. The method is as follows: Based on the structure or textual characteristics of the airport rules document, establish a chapter index and generate a page number mapping table that records the page number range of each chapter; Based on the mapping table, extract key values ​​from at least two different chapters; Based on preset cross-chapter association rules, the association of the key values ​​extracted from different chapters is verified.

Images