A compilation engine and method for the original QAR data frame structure of the A320 aircraft.

Abstract

This invention provides a compilation engine and method for the raw QAR data frame structure of the A320 aircraft, belonging to the field of civil aviation. The engine adopts a multi-node horizontal deployment and distributed computing architecture, including four modules: a raw file reader, a raw data normalizer, a data converter, and an engineering value data writer. The raw file reader reads raw RawData files sent by external aviation software; the raw data normalizer converts the raw RawData files into new normalized RawData files; the data converter decodes the new normalized RawData files according to decoding rules to obtain plaintext engineering value data; and the engineering value data writer writes the plaintext engineering value data into different storage media. This invention is applicable to large-scale, multi-source, and heterogeneous flight data processing scenarios, and can significantly improve data processing efficiency and system performance.

Description

Technical Field

[0001] This invention relates to the field of civil aviation, specifically to a compilation engine and method for the original QAR data frame structure of the A320 aircraft. Background Technology

[0002] Engineering value data is the most important data form in QAR data. Flight quality data and risk measurement data are derived from it. Compiling and parsing the original QAR data frame structure is fundamental to building a flight big data platform. Parsing the original QAR data into plaintext engineering value data that can be used for monitoring and analysis has wide applications in civil aviation safety, operations, maintenance, flight control, and air traffic control.

[0003] Regarding the parsing of raw QAR data, mainstream decoding software includes AGS, AirFASE, and EMS. In 2022, SAFRAN launched ALPHA, an upgraded version of AGS. These decoding software programs are all foreign products, and their core technologies, such as decoding logic, are strictly confidential and encapsulated within the software, making them inaccessible. In my country, the vast majority of airlines use AGS and AirFASE for decoding, while a few use EMS. The hundreds of thousands of yuan in annual service fees for system upgrades, maintenance, and personnel training incurred by these decoding software programs place a significant financial burden on airlines and greatly hinders their use of QAR data. Furthermore, the traditional architectures used by these software programs are ill-suited to handle terabyte-level data growth. A test by one airline showed that EMS takes 6 hours to process 10GB of QAR data, indicating lagging data processing capabilities. Additionally, there is insufficient technological autonomy and controllability, fault diagnosis relies on foreign experience databases, and the data security system is weak. Summary of the Invention

[0004] The purpose of this invention is to solve the problems existing in the prior art and, in response to the shortcomings of the prior art, to provide an A320 raw QAR data frame structure compilation engine and method. It transforms standard decoding rules into compilation calculation formulas, and in parallel compiles and parses the raw QAR data (i.e., RawData files) into plaintext engineered value data according to the frame structure. The plaintext engineered value data with all parameters and timeframes is automatically included in the database for convenient retrieval during various business tasks.

[0005] This invention is achieved through the following technical solution:

[0006] The first aspect of the present invention provides a raw QAR data frame structure compilation engine for the A320 model, which adopts a multi-node horizontal deployment and distributed computing architecture, including four modules: raw file reader, raw data normalizer, data converter, and engineering value data writer;

[0007] The raw file reader reads raw data files sent by external aviation software;

[0008] The raw data normalizer converts the original RawData file into a new normalized RawData file;

[0009] The data converter decodes the new standardized RawData file according to the decoding rules to obtain plaintext engineered value data;

[0010] The engineering value data writer writes plaintext engineering value data into different storage media.

[0011] Furthermore, the raw file reader has a built-in RawData file adapter for automatically identifying and adapting to different formats of RawData files; the raw file reader adopts a non-blocking input / output method, allowing each node to perform other tasks while waiting for data transmission; the raw file reader uses the MD5 algorithm to mark RawData files, using the MD5 value as the file's unique identifier.

[0012] Furthermore, the raw data normalizer performs the following operations:

[0013] Step 31: Preprocess the raw RawData file: Read the data in the file in byte form and convert it to binary;

[0014] Step 32: Process the binary RawData file to convert it into a standardized RawData file;

[0015] Step 33: Split the standardized RawData file into subframes, and then combine multiple subframes into a complete frame according to the decoding rules. Finally, each complete frame forms a new standardized RawData file.

[0016] Furthermore, step 32 includes: the raw data standardizer abstracts a standardization model, which contains standardization conversion rules to define different processing methods for different types of binary RawData files; the raw data standardizer obtains the model, serial number, and time information from the header information of the binary RawData file, finds the standardization conversion rules for the corresponding type of binary RawData file, and performs standardization conversion processing.

[0017] Furthermore, the data converter includes three tools: a raw data packet segmentation tool for engineering values, a raw data packet combination tool for engineering values, and a raw data decoding calculation tool for engineering values, with a built-in decoding rule base. The data converter employs distributed parallel processing, calling multiple decoding nodes to process the new standardized RawData file simultaneously. The processing steps include:

[0018] Step 51: The engineering value raw data packet segmentation tool splits the binary data of the new standardized RawData file into data packets. If the new standardized RawData file is split into a complete frame structure data packet, proceed to step 53; if the new standardized RawData file is split into multiple frame structure data packets, proceed to step 52.

[0019] Step 52: The engineering value raw data packet combination tool reassembles the disassembled frame structure data packets into complete frame structure data packets;

[0020] Step 53: The raw data decoding and calculation tool for engineering values ​​divides the complete frame structure data packet into multiple fixed-size data blocks and pushes the data blocks to different decoding nodes;

[0021] Step 54: Each decoding node converts the decoding rules into analytical formulas, performs decoding through the analytical formulas, and transmits the decoded data blocks to the aggregation node via the network;

[0022] Step 55: At the aggregation node, the raw engineering value decoding calculation tool sorts the frame data of all data blocks according to the first letter of the parameter name, and finally outputs the complete plaintext engineering value data.

[0023] Furthermore, the operation in step 52 includes: the engineering value raw data packet combination tool maps the parameters in the sub-frame to a dictionary, and directly retrieves the values ​​according to the dictionary; sorts the disassembled data packets according to the parameter names, and reassembles them into complete frame structure data packets.

[0024] Furthermore, in the decoding rules, different decimal numbers represent different data types: 1 represents the BNR number type, 2 represents the BCD combination type, 3 represents the DIS mapping type, and 4 represents the ISO#5 character type. The decoding includes: for the binary data fields of the new standardized RawData file, first querying the corresponding decimal number, and then translating it into the corresponding data type according to the decoding rules.

[0025] Furthermore, the engineering value data writer sets up a data storage engine for different storage media. During the writing of plaintext engineering value data, an independent data pipeline queue is abstracted. In the data pipeline queue, independent data pipeline pointers are specified for different storage media, enabling independent writing.

[0026] A second aspect of the present invention provides a method for compiling the raw QAR data frame structure of an A320 aircraft, implemented using the aforementioned raw QAR data frame structure compilation engine for the A320 aircraft, comprising the following steps:

[0027] Step 1, file reading and standardization, including:

[0028] Read the raw RawData file;

[0029] The original RawData file is standardized to generate a new standardized RawData file;

[0030] Step 2, data parsing and writing, includes:

[0031] Obtain the decoding rules applicable to the current new standardized RawData files;

[0032] Calculate the index bits of the engineering values ​​in the new standardized RawData file;

[0033] According to the decoding rules, the new standardized RawData file is broken down into data packets;

[0034] According to the decoding rules, the disassembled data packets are reassembled into complete frame structure data packets;

[0035] The decoding rules are transformed into analytical formulas, and the complete frame structure data packets are converted into plaintext engineered value data through analytical formulas.

[0036] The engineering value data writer stores plaintext engineering value data to different storage media.

[0037] Furthermore, the operation of converting the complete frame structure data packet into plaintext engineered value data includes: single data packet decoding and multi-data packet decoding;

[0038] The single data packet decoding is to decode the complete frame structure data packet according to the decoding rules and convert it into decimal plaintext engineered value data.

[0039] The multi-data packet decoding is based on the LCP_SAMPLE_NUMBER and LCP_PART_NUMBER parameters to obtain the decoding rules for each complete frame structure data packet. Each complete frame structure data packet is converted into binary data and then concatenated in a specific order to finally calculate the decimal plaintext engineering value data.

[0040] Compared with the prior art, the beneficial effects of the present invention are:

[0041] The compilation engine of this invention achieves efficient, stable, flexible, and highly compatible data parsing capabilities through technologies such as multi-node parallel computing, block processing and aggregation, automatic identification and adaptation, incremental standardization, intelligent error handling, efficient data writing and storage optimization, and custom data sources and storage formats. For different storage media, the compilation engine can automatically convert data protocols to ensure compatibility between data formats and target storage structures, avoiding performance bottlenecks or data conflicts caused by differences in storage platforms. For cases involving multiple coefficient calculations in standard decoding rules, it can reduce the risk of miscompilation, making it particularly suitable for large-scale, multi-source, and heterogeneous flight data processing scenarios. Attached Figure Description

[0042] Figure 1 This is a diagram of the compiler engine architecture of this invention;

[0043] Figure 2 This is a flowchart of the decoding and parsing process of this invention;

[0044] Figure 3 This is a schematic diagram of reference information for DIS type data parsing in this invention. Detailed Implementation

[0045] The compilation engine of this invention has the ability to flexibly and efficiently decode aircraft flight data (RawData) files. The compilation engine supports horizontal deployment across multiple nodes based on data size and load requirements, realizing a distributed computing architecture capable of efficiently processing large-scale RawData files. Through multi-node block decoding analysis and aggregation mechanisms, the compilation engine can process different data segments in parallel, greatly improving data processing speed and system throughput, ensuring efficiency and stability when processing massive amounts of data.

[0046] The present invention will now be described in further detail with reference to the accompanying drawings:

[0047] Example 1

[0048] The architecture of the A320 model's original QAR data frame structure compilation engine of this invention is as follows: Figure 1 As shown, the compilation engine consists of four modules: raw file reader, raw data normalizer, data converter, and engineering value data writer. The functions of each module are as follows:

[0049] 1. Raw File Reader: Responsible for reading raw RawData files generated by aviation software such as AirFase or AGS from temporary storage devices. It supports reading files with different data structures and writing to multiple data sources.

[0050] The raw file reader incorporates a scalable RawData file adapter for multiple formats. It automatically recognizes and adapts to different RawData file formats, ensuring its versatility and flexibility in various environments. This adaptation mechanism reduces the need for manual intervention and enhances the automation of decoding.

[0051] Furthermore, in the reading process of a distributed computing architecture, nodes need to frequently exchange data. To further improve efficiency, this invention employs non-blocking input / output (NIO) technology, which makes data reading and writing more efficient. Especially when transmitting large amounts of decoded data between multiple nodes, this technology can significantly improve data transmission performance; specifically, through non-blocking I / O, nodes can perform other tasks while waiting for data transmission, maximizing network bandwidth utilization and reducing latency and jitter in network transmission, thereby optimizing the data transmission speed between multiple nodes. This design not only improves data processing efficiency but also enhances system scalability and stability, making it particularly suitable for large-scale data processing environments.

[0052] Furthermore, this invention improves the speed at which the compilation engine filters unparsed raw files by optimizing MD5 digests, reducing the number of I / O operations the compilation engine performs on the operating system. This improves reading efficiency, optimizes space usage, and facilitates data comparison, ensuring data integrity and accuracy. Specifically, during file processing, the RawData file is marked using the MD5 algorithm. The MD5 value serves as a unique identifier for the file, ensuring not only the integrity of the file content but also accurately tracking the file's processing status within the system. With MD5 marking, the system avoids repeatedly processing the same files, thereby improving efficiency and avoiding unnecessary work.

[0053] Preferably, to improve the reading efficiency of raw RawData files, this invention employs a distributed and multi-threaded approach for file reading. Horizontal scaling can be flexibly implemented based on the number of files and their growth rate. Each node reads data in parallel using multi-threading, thereby improving processing power and throughput.

[0054] 2. Raw Data Normalizer: Converts raw RawData file data into a standardized format for the compilation engine.

[0055] The raw data standardizer can automatically identify different interfaces based on the type and header information of raw Raw Data files from various sources and versions, and then perform different standardization transformations on raw Raw Data files from different sources.

[0056] Specifically, the raw data standardizer abstracts a standardization model, which is an abstract framework for defining how to convert raw RawData files from different sources and versions into a unified standardized format. This model contains a series of decoding rules that determine how to process different types of raw RawData files to ensure that they can be processed consistently in subsequent parsing processes and that different processing methods can be adopted based on the source of the raw RawData file.

[0057] The specific implementation process of the raw data standardizer's standardization model includes: automatically obtaining information such as the machine model, serial number, and time from the file header when reading the raw data file, and executing the corresponding standardization conversion rules for the raw data file. Preferably, the raw data standardizer has built-in version management of decoding rules, allowing for arbitrary switching between different versions of decoding rules for standardization conversion.

[0058] Furthermore, according to the decoding rules, the complete original RawData file is physically split into frames and subframes, and then reassembled into a new standardized RawData file after conversion. For example... Figure 1 As shown, since the data organization of RawData files is in binary form, to extract the complete data of each frame, the complete raw RawData file must be read in byte form, each byte must be converted into binary, and then operations must be performed, i.e., "base conversion"; further, the file after "base conversion" is divided into subframes, and multiple subframes are combined into a complete frame according to decoding rules, i.e., "data preprocessing" operation. Specifically, to combine the segmented binary data subframes together, the complete binary segment of each subframe must be assembled and encapsulated into a complete frame data structure, which is predefined in the engine.

[0059] Preferably, to ensure data security, the new standardized RawData file can undergo binary obfuscation during this process to generate a file with encrypted information; ultimately, the original RawData file data, after standardization processing, can output a new standardized RawData file with encrypted information. This measure not only effectively protects data security but also prevents unauthorized access and tampering, ensuring the consistency and reliability of all data in subsequent processing.

[0060] Preferably, for raw RawData files that cannot be parsed or have incorrect formats, the compilation engine will record the error information generated by standardizing the file and skip the processing of that raw RawData file, proceeding to the processing of the next raw RawData file.

[0061] The above operations involve processing flight data according to a defined standard format. Through these processes, a unified new standardized RawData file is ultimately generated (i.e., Figure 2 The byte data standard file shown provides a unified file format for subsequent decoding, eliminating the need to concern the specific file format during decoding and allowing for direct decoding operations. Furthermore, since the preprocessed file is assembled in binary form, its size is significantly reduced, improving storage and transmission efficiency. This approach not only simplifies the decoding process but also optimizes data management efficiency.

[0062] 3. Data Converter: Based on the aircraft model's decoding rules, the newly standardized RawData file, processed by the raw data normalizer, is parsed into plaintext engineering values. Specifically, the built-in decoding rule library is bound to the aircraft number. During parsing, the decoding rules are automatically matched based on the header information of the new standardized RawData file, and then parsing is performed. The data converter includes three tool modules: a raw data packet segmentation tool for engineering values, a raw data packet combination tool for engineering values, and a raw data decoding calculation tool for engineering values.

[0063] The RawData files of an A320 aircraft may contain complex data structures. After the raw data is standardized, the data converter employs distributed parallel decoding, calling multiple decoding nodes to process the newly standardized RawData file simultaneously during the decoding phase. Specifically, a complete processing logic chain processes only one file, and the engine can execute multiple processing logic chains concurrently. This invention achieves the processing of a complete processing logic chain through distributed computing logic.

[0064] Through its built-in splitting and combining mechanism, the engineering value raw data packet segmentation tool breaks down the binary data of the new standardized RawData file into one or more data packets. That is, for situations where the new standardized RawData file contains excessively large amounts of data, data collection frequencies differ, the file contains data from multiple collections, or the data packet length varies, it needs to be segmented into multiple data packets according to specific decoding rules and data integration settings.

[0065] The raw data packet assembly tool then sorts the selected flight parameters (such as altitude, speed, temperature, pressure, etc.) alphabetically, and reassembles the fragmented data packets into complete frame structure data packets according to the sorted order. Specifically, each subframe in the binary data contains a complete data acquisition. For example, if an acquisition occurs once per second, the binary data generated within that second constitutes a complete data acquisition. When the compilation engine finishes parsing a subframe, it means that one acquisition by the aircraft has been completely translated, thus reassembling the fragmented data packets into complete frame structure data packets. To ensure that each subframe contains a complete data list, the data converter maps the parameter names in the subframe to a dictionary, directly retrieves values ​​from the dictionary, and then aligns the data packets according to the parameter names to form complete frame structure data packets.

[0066] This rule-based and standard-based segmentation and combination method ensures that each part of the binary data can be accurately and reliably converted into plaintext data, thereby ensuring the high quality and accuracy of the decoding results.

[0067] The engineering value raw data decoding and calculation tool divides the complete frame structure data packet into multiple fixed-size data blocks, the size of which is determined by the number of computing nodes; and pushes these data blocks to multiple decoding nodes for parallel processing. Each decoding node independently parses the data block assigned to it, that is, each decoding node calls the engineering value raw data decoding and calculation tool to perform decoding simultaneously, effectively improving parsing efficiency.

[0068] In the decoding process, data blocks are first identified, and then decoded according to the decoding rules in the decoding rule base. Specifically, decoding is performed according to the analytical formulas for decoding rule conversion. In this invention, decoding rules are generated based on industry-standard decoding files, forming a decoding rule base. At this point, the data types of all parameters are completely determined. In the decoding rules, data types are typically represented by the numbers 1, 2, 3, and 4. These decimal numbers represent different data types: 1 represents BNR numeric type, 2 represents BCD combination type, 3 represents DIS mapping type, and 4 represents ISO#5 character type. During the decoding process, the decimal numbers corresponding to the binary fields are directly determined by querying the decoding rules, and then translated into the corresponding data types according to the rules (i.e., 1 represents BNR numeric type, 2 represents BCD combination type, 3 represents DIS mapping type, and 4 represents ISO#5 character type). Therefore, no additional data conversion steps are required, simplifying the processing.

[0069] After all decoding nodes have completed parsing, the decoded data is transmitted to the aggregation node via the network. This invention supports custom network transmission protocols and dynamically adjusts cache and transmission parameters to cope with different network conditions and system resources, ensuring efficient execution in various environments. This not only ensures efficient access to data during large-scale processing but also significantly reduces system latency. Since the decoding process involves multiple nodes and multiple threads, the order of the main frame, sub-frames, and frame parameters is disordered when the overall decoding is complete. Therefore, at the aggregation node, all data blocks need to be sorted: sorting begins by sorting the data within each sub-frame in ascending order of the first letter of each parameter's name (all data belongs to a single parameter type). Next, the four subframes are integrated as a whole, and then the subframes are sequentially assigned to the correct main frames. Finally, they are sorted according to the main frame sequence number. Specifically, in A320, every four subframes are described as one frame. Here, integration involves marking each of the four subframes with its corresponding main frame and subframe number. Subframes within the same main frame are then sorted by their sequence number from 1 to 4. Finally, they are sorted in ascending order according to the main frame sequence number, ultimately outputting the complete plaintext engineered data. This design not only optimizes processing time but also improves the system's scalability and load balancing capabilities, enabling the system to efficiently process large-scale data.

[0070] Preferably, for changed data, the compilation engine will re-decode the corresponding historical data according to the latest decoding rules. For example, if new data adds a field, the historical data that needs to be reused will not have this field. In order to complete this field, re-decoding is required. To speed up the decoding efficiency, the data to be decoded only re-decodes the historical data with modified or newly added fields, rather than re-decoding all historical data. Historical data that has not been modified will still use the already completed decoding results.

[0071] 4. Engineering Value Data Writer: The parsed plaintext engineering value data is transmitted to the engineering value data writer. The engineering value data writer also includes a data storage engine (different data storage engines are available for different storage media). For different storage media, different data storage engines are called to write the plaintext engineering value data to different storage media, including relational databases, distributed storage systems, cloud storage, Excel spreadsheets, etc.

[0072] The engineering value data writer supports custom storage media, such as databases capable of storing data like HBase, Redis, and MongoDB. This flexible data storage configuration allows users to efficiently transfer data between different storage media according to their needs. Specifically, the data storage engine of this invention provides an open interface design through abstract interface definitions. The main advantage of this design is that it can be optimized for different types of databases without affecting the storage of other types of data.

[0073] Furthermore, considering the write performance of downstream databases during the data writing process, this invention abstracts an independent data pipeline queue. In this pipeline queue, independent data pipeline pointers are specified for different output storage media selected by the user. Taking Redis and HBase databases as examples, when data is written, the data pointer index for Redis is 1, while the data pointer index for HBase is 0. These two data pointers are independent of each other and can be written and managed independently. When the user selects multiple storage media for output, the data in the pipeline queue must wait for the processing of all storage media to be completed and for an end signal to be received before the data can be cleared. That is, the data in the queue will only be cleared after all the data in this batch has been written to the corresponding database and an end signal has been received. If the user selects only one storage medium, the data will be read and released in the form of a queue. The next data item will only be released after one data item has been read. That is, once a data item is written to the database, the data item in the queue will be cleared. This mechanism ensures the system's efficiency while also ensuring flexibility and scalability in a multi-database environment.

[0074] Furthermore, the engineering value data writer incorporates a unified data protocol. For data decoded by the data converter, it automatically converts the data into the corresponding data format based on the storage engine type, storing it as different table models or structures. Preferably, only some fields can be written as needed to meet data storage requirements in different scenarios.

[0075] Example 2

[0076] like Figure 2 As shown, the execution steps of the process for parsing aircraft flight data RawData files using a compilation engine in this invention are as follows:

[0077] Step 1, Data Reading and Standardization:

[0078] Step 1-1: Data Reading

[0079] The raw file reader first reads the raw RawData file into the compilation engine's memory. To improve file reading efficiency, this invention employs a distributed and multi-threaded approach. The system can flexibly scale horizontally based on the number of files and their growth rate.

[0080] During file processing, the system uses the MD5 algorithm to tag the original RawData file to improve reading efficiency. The MD5 value, as a unique identifier for the file, not only ensures the integrity of the file content but also accurately tracks the file's processing status within the system. By using MD5 tagging, duplicate processing of the same file can be avoided, thus improving efficiency and preventing unnecessary work.

[0081] Because distributed processing is employed, frequent data exchange is required between nodes. To further improve efficiency, this invention utilizes non-blocking input / output (NIO) technology, which makes data reading and writing more efficient. Especially when transmitting large amounts of decoded data between multiple nodes, NIO technology significantly improves data transmission performance. Through non-blocking I / O, nodes can perform other tasks while waiting for data transmission, maximizing network bandwidth utilization and reducing latency and jitter in network transmission, thereby optimizing data transmission speed between multiple nodes.

[0082] Preferably, since there may be cases where the original RawData file has already been standardized and stored in the engine's memory, and is then retrieved by the parsing engine again, in order to avoid errors caused by data duplication, the raw file reader first verifies whether the read raw RawData file has been standardized. If the file has been standardized, the file identifier is changed to "standardization completed", and the processing of that raw RawData file is skipped, and the processing of the next raw RawData file is performed.

[0083] Steps 1-2: Data Standardization Processing

[0084] The raw data normalizer performs standardization processing to address the inconsistency in file formats between raw RawData files from different sources. To this end, the compilation engine abstracts a standardization model that can employ different processing methods based on the source of the raw RawData file. According to decoding rules, the raw RawData file is segmented into subframes, and multiple subframes are combined into a complete frame. Specifically, according to the decoding rules, the decimal values ​​64, 65, 66, and 67 are first used as synchronization words to determine the starting position of the subframe, thus accurately segmenting the raw RawData file into multiple subframes. Then, by orderly combining these subframes, a complete frame is successfully constructed. For example, taking the A320 aircraft as an example, the frame length is 1024, meaning each data frame contains 1024 bytes of data, with each frame lasting four seconds, or 0.25 frames per second. Assuming a flight data segment lasts 100 seconds, the total number of frames is 25. Each frame contains four subframes, each with a synchronization word in decimal: 64, 65, 66, and 67. To find the first subframe, the search begins with the binary representation of the decimal value 64. Calculating backwards, we select two bytes: (wordNum × 2 – 1, wordNum × 2). These two bytes are then reversed (e.g., 05 43 reversed to 43 05) and converted to binary. This is the first subframe. The search for subsequent subframes follows the same rule until the frame segment starting with 67 is found, indicating that all four subframe segments have been searched. This completes the process of creating the new standardized RawData file (i.e.,...). Figure 2 The standard file for medium-byte data is generated, and the file status label is modified to indicate "standardization complete" and stored in the compilation engine's memory.

[0085] Preferably, to ensure data security, binary obfuscation can also be performed during this process to generate a new standardized RawData file with encrypted information (i.e., Figure 2 (Medium-byte data standard file). This measure effectively protects data security and prevents unauthorized access and tampering. Ultimately, this standardized process unifies the data format of RawData files from different sources, ensuring consistency and reliability of all data in subsequent processing. This approach greatly simplifies data format conversion and improves system compatibility.

[0086] Step 2, Data Analysis and Writing:

[0087] Retrieve the newly standardized RawData file that has already undergone standardization processing and decode it.

[0088] Step 2-1: Obtain the decoding rules

[0089] The compilation engine has a pre-defined decoding rule library, from which decoding rules applicable to the current new standardized RawData files are obtained. Preferably, it is necessary to check whether the decoding rules in the decoding rule library accurately describe the important parameters in text form according to the latest industry-standard decoding files, that is, to check whether the decoding rules are "standardized" so that the compilation engine can correctly identify the decoding rules.

[0090] Step 2-2: Calculate the index bit of the engineering value

[0091] The calculation method involves identifying the LCP_SAMPLE_NUMBER and LCP_PART_NUMBER parameter files, where the wordNum field represents the position index of the complete frame containing the data in that column within the new standardized RawData file.

[0092] Steps 2-3: Decomposition of Engineering Values

[0093] According to the decoding rules, the engineering value raw data packet segmentation tool breaks down the newly standardized RawData file into one or more data packets. Situations where the new standardized RawData file is broken down into multiple data packets typically include situations such as excessively large data volume, complex data structure, different data collection frequencies, variable data packet lengths, and distributed processing requirements. These situations require a comprehensive approach to determining how to break down the file into multiple data packets based on the specific decoding rules and data characteristics.

[0094] Steps 2-4: Frame Structure Reassembly

[0095] If an engineering value requires multiple data packets to represent it, these data packets are combined into a complete frame structure data packet. Specifically, the raw engineering value data packet combination tool reassembles the disassembled data packets into a complete frame structure data packet based on the decoding rules in the decoding rule base (for example, a flight information rule in the decoding rule base might have fields such as longitude, latitude, origin airport, landing airport, elevation angle, depression angle, bank angle, airspeed, ground speed, and radio altitude). Specifically, each subframe in the raw data contains a complete data acquisition. When the compilation engine finishes parsing a subframe, it means that one acquisition of the aircraft has been completely decoded. Reassembling the subframes is equivalent to reassembling the disassembled data packets into a complete frame structure data packet. This step requires a deep understanding of the data frame structure to ensure that the various engineering values ​​can be combined in the correct order and format to form a complete data frame, that is, to ensure that the data frame contains one or more data frame packets.

[0096] To ensure correct alignment of data in the reassembled frames, each subframe in this invention contains a complete data list. The compilation engine maps the plaintext data of the subframes to a dictionary, then directly assigns values ​​to the parameters according to the decoding rules, and aligns the data packets by sorting them according to the parameter names.

[0097] Steps 2-5: Convert the new standardized RawData file into plaintext data.

[0098] The raw data decoding calculation tool converts complete frame structure data packets into plaintext engineering value data according to the decoding rules in the decoding rule base. During the decoding process, binary segments in individual data packets are first identified, and pre-established decoding rules are converted into analytical formulas (the specific application of these decoding rules is explained in Example 3) for decoding. In this invention, industry-standard decoding files form the decoding rules, at which point the data types of all parameters are completely determined. In the decoding file, data types are typically represented by the numbers 1, 2, 3, and 4, which correspond to different data types in RawData: 1 represents the BNR numeric type, 2 represents the BCD combination type, 3 represents the DIS mapping type, and 4 represents the ISO#5 character type. During the decoding process, the compilation engine directly determines the field type by querying the decoding rules and then translates the data into the corresponding data type according to the rules. This design ensures that data types are consistently defined throughout the system and directly applied during decoding without dynamic conversion or additional calculations, guaranteeing data processing speed and accuracy.

[0099] In this step, it is necessary to accurately identify and locate the position of each engineering value in the data frame. The location is determined based on wordNum, as explained in the three embodiments.

[0100] Furthermore, the raw data decoding and calculation tool reads the binary data, pads the high-order bits with 0s to make 12 bits, and then parses it according to the decoding rules. This involves specific parsing methods for different data types (such as DIS, BCD, ISO#5, BNR, etc.) (see Example 3 for details), as well as the processing of parameters such as the sign bit, coefficients, and exponent terms of the data.

[0101] Specifically, the analytical formula used to calculate the final engineering value for data containing individual coefficients is as follows:

[0102] Y = A0 × 10 B0 ×X

[0103] in,

[0104] Y: Output value in engineering units after conversion;

[0105] X: Raw value, which appears only as a multiplier in the last term of the formula;

[0106] A0 corresponds to the parameter EUC_COEFF_0;

[0107] B0 corresponds to the parameter EUC_COEFF_EXP_0.

[0108] The analytical formula used to calculate the final engineering value for data containing multiple coefficients is:

[0109]

[0110] in,

[0111] Y: Output value in engineering units after conversion;

[0112] X: Raw value, which appears only as a multiplier in the last term of the formula;

[0113] Ai (i = 0, 1, ..., n): A linear coefficient sequence, corresponding to parameters EUC_COEFF_0 to ...

[0114] EUC_COEFF_n;

[0115] Bi(i = 0, 1, ..., n): The sequence of exponential coefficients, corresponding to parameters EUC_COEFF_EXP_0 to ...

[0116] EUC_COEFF_EXP_n;

[0117] n: The order of the polynomial, determined by the maximum index value of the parameter sequence.

[0118] The final plaintext engineering value data is calculated using the above formula. This formula can be used to optimize the decoding of data containing multiple coefficients, obtain more accurate calculations, and avoid possible errors in decoding data containing multiple coefficients and exponents.

[0119] Steps 2-6: Write out the data

[0120] The plaintext engineering value data is stored on different storage media using an engineering value data writer to complete the parsing process. This step requires ensuring that the data can be correctly written to the specified storage media for subsequent data analysis and application. Storage media types include relational databases, distributed storage systems, cloud storage, etc.

[0121] The engineering value data writer of this invention provides an open interface design through the data storage engine abstraction interface definition, enabling optimization for different types of databases without affecting the storage of other data types. Specifically, during the data writing process, the engineering value data writer abstracts an independent data pipeline queue, taking into account the write performance of downstream databases; within this pipeline queue, independent data pipeline pointers are specified for different storage media selected by the user.

[0122] Example 3: Application of Data Decoding Rules

[0123] 1. Understanding the overall decoding rules

[0124] In step 2 of Example 2, since the standardized new standard RawData file uses binary out-of-order encoding, the decoding rules specify the methods for disassembling, compiling, and combining binary files. Specifically, the decoding rules are multiple hash files without any processing. The overall decoding rule understanding involves describing important parameters in text form so that the compilation engine can recognize these hash files and convert the data within the files into engine-readable, rule-based data.

[0125] Specifically, before performing specific data parsing, it is necessary to have a comprehensive understanding of the basic format and presentation of the decoding rule file. This includes determining key indicators such as the frame length, data acquisition rate, synchronization word, and data packet length of the device to be decoded, as these indicators are the foundation for parsing the data frame structure.

[0126] In RawData files, data is typically represented in binary form because it allows for more compact data display and a more easily defined format. Before decoding, it's necessary to determine several key parameters for the device being decoded, including frame length, data acquisition rate, synchronization word, and data packet length. This allows the compilation engine to automatically obtain these parameters based on preset decoding rules.

[0127] Taking the A320 model as an example, this model has a length of 1024 bytes, with each frame lasting four seconds. Each frame contains four subframes, and the synchronization word of each subframe is 64, 65, 66, 67 in decimal. The data packet consists of 12 bits of binary data. When decoding the data, the compilation engine searches for the subframe corresponding to the engineering value according to the decoding rules. Starting from the synchronization word, it selects two bytes of data (wordNum×2–1, wordNum×2). After reversing the high and low bits of the two bytes of data (e.g., 05 43 reversed to 43 05), it is converted into binary data. If the data is less than 12 bits, the high bits are padded with 0s until it reaches 12 bits.

[0128] 2. Data packet decoding

[0129] In a complete aircraft data RawData file, flight parameters exist in single-data packet format and multi-data packet format. When the parameter value is too large and a single data packet cannot completely store the data, the RawData file will use multiple data packets to store the data. In step 2 of Example 2, the compilation engine performs the decoding process. The decoding methods for single-data packets and multi-data packets are different. The following explains the decoding methods for the two types of data packets.

[0130] (1) Single data packet decoding

[0131] Single-data packet decoding simply requires segmenting the standardized binary data of the new standard RawData file according to decoding rules. Specific rules include:

[0132] 1.1 Binary Data Segmentation

[0133] Binary data is precisely truncated according to the start and length parameters in the decoding rules, extracting a specific number of bits. For example, for the binary data 000101101110, with start=1, length=7, and signBit=1, 7 bits are truncated from right to left, resulting in 1101110.

[0134] 1.2 Sign Bit Processing

[0135] Sign bit identification: The sign of the data is identified based on the signBit parameter. If signBit = 1, it indicates that the data is a signed number and requires sign bit processing. For example, the sign bit of 1101110 is 1, indicating that it is a negative number.

[0136] Sign bit conversion: For signed numbers, the binary data needs to be converted to two's complement form. For example, when converting 1101110, the high bits are padded with 1s to reach 32 bits, which is the maximum number of bits in JVM Integer. The two's complement is 11111111111111111111111111101110.

[0137] 1.3 Data Conversion

[0138] In the calculation rules of the original file, there are no floating-point numbers in the binary conversion; only integers are included. These integers can be calculated based on the divisor parameter, which is the coefficient factor. The block of binary data is converted to decimal numbers. Standard binary-to-decimal algorithms can be used; for example, 1101110 is converted to decimal 118, but considering the sign bit, it becomes -18.

[0139] 1.4. Processing of coefficients and exponents

[0140] The raw data RawValue obtained from decoding needs to be calculated according to the calculation formula in the decoding specification before the result can be used as the final value.

[0141] Specifically, the analytical formula used to calculate the final engineering value for data containing individual coefficients is as follows:

[0142] Y = A0 × 10 B0 ×X

[0143] in,

[0144] Y: Output value in engineering units after conversion;

[0145] X: Raw value, which appears only as a multiplier in the last term of the formula;

[0146] A0 corresponds to the parameter EUC_COEFF_0;

[0147] B0 corresponds to the parameter EUC_COEFF_EXP_0.

[0148] The analytical formula used to calculate the final engineering value for data containing multiple coefficients is:

[0149]

[0150] in,

[0151] Y: Output value in engineering units after conversion;

[0152] X: Raw value, which appears only as a multiplier in the last term of the formula;

[0153] Ai (i = 0, 1, ..., n): A linear coefficient sequence, corresponding to parameters EUC_COEFF_0 to ...

[0154] EUC_COEFF_n;

[0155] Bi(i = 0, 1, ..., n): The sequence of exponential coefficients, corresponding to parameters EUC_COEFF_EXP_0 to ...

[0156] EUC_COEFF_EXP_n;

[0157] n: The order of the polynomial, determined by the maximum index value of the parameter sequence.

[0158] For example, during the decoding process, X(RawValue) is obtained as -18, and the parameter is defined as follows in the decoding specification file:

[0159] EUC_COEFF_0 = "0"

[0160] EUC_COEFF_1 = "1"

[0161] EUC_COEFF_EXP_0 = "0"

[0162] EUC_COEFF_EXP_1 = "0"

[0163] In the above case, there are multiple coefficients, which are polynomial coefficients with n = 1. Substituting the above data into the formula, the result is -18:

[0164] Y = 0 × 10 0×-18 0 +1×10 0 ×-18 1 =-18

[0165] Preferably, the decoding rules set a maximum value (MAX) and a minimum value (MIN) for numeric data. The maximum decoded value must not be greater than MAX; otherwise, MAX is used as the final result. The minimum decoded value must not be less than MIN; otherwise, MIN is used as the final result. For character data, the decoding rules provide a detailed explanation of this parameter, such as 0 representing NO and 1 representing OFF. When the calculated value is outside this interpretation range, the binary calculated value is directly recorded as the final value.

[0166] (2) Multi-data packet decoding

[0167] Multiple data packets typically occur when a single packet structure cannot carry complete data, so multiple data packets are used to store the data together, and each subframe may be sampled multiple times. When an engineering value needs to be stored using multiple data packets, the decoding rules for each data packet need to be obtained based on parameters such as LCP_SAMPLE_NUMBER and LCP_PART_NUMBER. Each data packet is then converted into binary data, concatenated in a specific order, and the final decimal data result is calculated.

[0168] For example, the A320's radio altitude engineering value is collected four times per second, with each collection represented by two data packets. The data packets corresponding to the number of collections need to be located first, then converted and concatenated according to their respective decoding rules to finally obtain the complete plaintext engineering value data.

[0169] The specific decoding rules are as follows:

[0170] 2.1 Data Packet Identification and Sorting

[0171] Identify LCP_SAMPLE_NUMBER and LCP_PART_NUMBER: Identify and sort multiple data packets based on the LCP_SAMPLE_NUMBER (sample number) and LCP_PART_NUMBER (partial number) parameters.

[0172] For example, the engineered radio altitude value for the A320 is collected four times per second, with each collection represented by two data packets. The decoding rules are as follows:

[0173] ●EUC_COEFF_0=0.125, EUC_COEFF_EXP_0=0, signBit=1;

[0174] ●The first data packet is represented as: wordNum=86, start=1, Length=12;

[0175] Here, wordNum represents the index of the complete frame containing the data in this column within the original file.

[0176] `start` indicates the starting index of the data in this column within the complete frame, and `Length` indicates the length of the binary representation of this column within the complete frame.

[0177] ●The second data packet is represented as: wordNum=85, start=9, Length=4;

[0178] First, the data packet corresponding to the sampling number needs to be found, and then sorted according to the partial number. Specifically, LCP_SAMPLE_NUMBER indicates the sampling number, and LCP_PART_NUMBER indicates the order of multiple data packets. Taking the first sampling as an example, the process of finding the data packet with LCP_SAMPLE_NUMBER = 1 is as follows:

[0179] Identify LCP_SAMPLE_NUMBER and LCP_PART_NUMBER:

[0180] ●Sampling number 1: LCP_SAMPLE_NUMBER = 1

[0181] ●Partial Number 1: LCP_PART_NUMBER = 1

[0182] ●Partial number 2: LCP_PART_NUMBER = 2

[0183] Get data packets:

[0184] ● First data packet (LCP_PART_NUMBER=1): wordNum=86

[0185] • Second data packet (LCP_PART_NUMBER=2): wordNum=85

[0186] For abnormal data, the compilation engine will record the error message, error file, parameters, etc., and wait for manual review before re-decoding the parameters.

[0187] 2.2 Data packet conversion and splicing

[0188] Based on the single data packet decoding method, the first and second data packets are converted into binary data respectively, and then the binary data of multiple data packets are concatenated in a specific order (usually according to the order of partial numbers).

[0189] Specifically, the binary conversion process is as follows: each data packet is converted into binary data. Based on its respective decoding rules (such as parameters like start, length, and signBit), the binary data in each data packet is extracted and processed.

[0190] For example, the engineered radio altitude value for the A320 is collected four times per second, with each collection represented by two data packets.

[0191] • First data packet conversion:

[0192] Binary data: 000101101110 (assuming this is the binary form read from a RawData file)

[0193] Decoding rules: start = 1, length = 12

[0194] Truncation result: Truncate 12 bits from right to left to get 101101110 (if less than 12 bits, pad with zeros at the higher bits to get 000101101110)

[0195] • Second data packet conversion:

[0196] Binary data: 001100110011 (assuming this is the binary form read from a RawData file)

[0197] Decoding rules: start = 9, length = 4

[0198] Truncation result: Extracting the 9th to 12th digits from right to left yields 0011.

[0199] Furthermore, the binary data concatenation process is as follows:

[0200] Specifically, the two binary data packets are concatenated in reverse order (the binary data of the second data packet comes first, and the binary data of the first data packet comes last).

[0201] For example, if the binary data of the first data packet is 1101110 and the binary data of the second data packet is 0011001, then the concatenated binary data is 00110011101110.

[0202] 2.3 Sign Bit and Data Type Handling

[0203] Sign bit processing: If the concatenated binary data contains a sign bit, sign bit processing is required. For example, if the sign bit is 1, indicating a negative number, the binary data is represented in two's complement form.

[0204] Sign bit: 1 (indicates a negative number)

[0205] Binary data: 101001

[0206] Two's complement conversion: 1111111111111111111111111101001 (two's complement form)

[0207] Decimal result: -23 (converted to decimal)

[0208] 2.4. Processing of Coefficients and Exponent Terms

[0209] The individual coefficients are calculated using the following formula to determine the final project value:

[0210] Y = A0 × 10 B0 ×X

[0211] in,

[0212] Y: Output value in engineering units after conversion;

[0213] X: Raw value, which appears only as a multiplier in the last term of the formula;

[0214] A0 corresponds to the parameter EUC_COEFF_0;

[0215] B0 corresponds to the parameter EUC_COEFF_EXP_0.

[0216] Multiple coefficients are used to calculate the final engineering value using the following formula:

[0217]

[0218] in,

[0219] Y: Output value in engineering units after conversion;

[0220] X: Raw value, which appears only as a multiplier in the last term of the formula;

[0221] Ai (i = 0, 1, ..., n): A linear coefficient sequence, corresponding to parameters EUC_COEFF_0 to ...

[0222] EUC_COEFF_n;

[0223] Bi(i = 0, 1, ..., n): The sequence of exponential coefficients, corresponding to parameters EUC_COEFF_EXP_0 to ...

[0224] EUC_COEFF_EXP_n;

[0225] n: The order of the polynomial, determined by the maximum index value of the parameter sequence.

[0226] Application of coefficient and exponent parameters: Perform operations on the converted decimal number based on the EUC_COEFF_0 and EUC_COEFF_EXP_0 parameters.

[0227] In this example, EUC_COEFF_0 = 0.125, EUC_COEFF_EXP_0 = 0. This coefficient is the result of a single-term coefficient calculation: 0.125 * 10^15. 0 *-23=-2.875.

[0228] In this example, the final result is: -2.875

[0229] Similar to single-data packet decoding, the decoding rules set a maximum value (MAX) and a minimum value (MIN) for numeric data types. The maximum decoded value must not exceed MAX; otherwise, MAX is used as the final result. The minimum decoded value must not be less than MIN; otherwise, MIN is used as the final result. For character data types, the decoding rules provide a detailed explanation of this parameter, such as 0 representing NO and 1 representing OFF. When the calculated value is outside this interpretation range, the binary calculated value is directly recorded as the final value.

[0230] (3) Engineering value decoding standard

[0231] The decoding rules in the decoding rule base refer to the AcquiredParameters file for the corresponding device model. The file contains the following decoding information:

[0232] PRM_NAME: Project value parameter name (i.e., the name of this data column);

[0233] PRM_NEGATIVE_SIGN = "-": Negative sign representation;

[0234] PRM_PARAMETER_SIGNED = "1": Sign bit stuffing representation;

[0235] PRM_POSITIVE_SIGN="": Positive number representation;

[0236] EUC_COEFF_0: Coefficient 0, i.e. A0 in the formula;

[0237] EUC_COEFF_EXP_0: Exponent term 0, i.e. B0 in the formula;

[0238] EUC_COEFF_1: Coefficient 1, i.e., A1 in the formula;

[0239] EUC_COEFF_EXP_1: Exponent term 1, i.e. B1 in the formula;

[0240] EUC_COEFF_n: Coefficient n, i.e., A in the formula. n ;

[0241] EUC_COEFF_EXP_n: The exponent term n, which is B in the formula. n ;

[0242] LCP_SAMPLE_NUMBER: The order in which multiple data packets are collected per second (i.e., during flight data collection, there may be data collected once per second and data collected multiple times per second. When multiple collections occur, this field describes the order in which the data is collected).

[0243] LCP_PART_NUMBER: The order of sub-packets in a scenario where multiple data packets represent a single data item (when a data item is too large to fit in 12 bits, it will be stored in two separate data packets; this field describes the order of a complete data item in multiple data packets).

[0244] LCP_WORD_NB: The index position of the data packet in hexadecimal representation (LCP_WORD_NB*2-1, LCP_WORD_NB*2), representing the hexadecimal data of the target data (i.e., wordNum, the position of the data packet);

[0245] LCP_BIT_SOURCE_LSB: The start bit of the binary data in the data packet (that is, the starting bit of this column of data in the complete frame);

[0246] LCP_BIT_LENGTH: The length of the binary data in the data packet (i.e., the length of the binary data represented by this column within the complete frame);

[0247] LCP_SUBFRAME: Indicates which subframe the project value exists in. ALL means it exists in all subframes. (The A320 aircraft defines a complete frame as 4 subframes, with each subframe acquisition time being 1 second. LCP_SUBFRAME marks which subframe the data exists in. ALL means the data exists in all four subframes; 1 means the data exists only in the first subframe; 2 means the data exists only in the second subframe; 1 4 means the data exists in the first and fourth subframes, and so on.)

[0248] (4) Data parsing rules for different types of data

[0249] Different data types require different parsing methods, and the parsing method needs to be changed according to the different types. The specific data type parsing rules are as follows:

[0250] 4.1 DIS type data parsing

[0251] Discrete data is decoded using a single data packet method. After converting the data into decimal data, it is then processed according to a mapping relationship (such as...). Figure 3 (As shown) Returns the corresponding data. For example, if the calculation result is 1, it returns "IR / GPS".

[0252] It should be noted that when TXD does not exist, A can be used directly as the final result; in addition, when TXD exists, but the value of A cannot match TXD, then when A>0, it is used as 1, and when A<=0, it is used as A=0.

[0253] 4.2 BCD type data parsing

[0254] This type of data is typically used to represent data such as years and months. According to section 1.1 of the single data packet decoding section above, the segmented binary data is divided and decoded separately to obtain the final result. For example, the decoding specification for the DAY field is as follows:

[0255] PRA_CONV_CONF: 24 indicates that the final result is 6 bits, which need to be split into the first 2 bits and the last 4 bits and converted separately.

[0256] PRM_MIN_OP_RANGE: 1, indicating that the minimum value of this data is 1;

[0257] PRM_MAX_OP_RANGE: 31, indicating that the maximum value of this data is 31;

[0258] LCP_BIT_LENGTH: 6, indicating that the data length is 6 bits;

[0259] LCP_BIT_SOURCE_LSB: 1, indicating the start bit of the data packet;

[0260] LCP_BIT_SOURCE_LSB: 715, indicating the location of the data packet;

[0261] The calculation of BCD requires converting the decoded data into a weighted sum and then performing the calculation according to the BNR method. The formula for the weighted sum is:

[0262]

[0263] in:

[0264] Y: Output value in engineering units after conversion;

[0265] X: The calculated value of RawValue, as shown in the example below, X = [3,1]

[0266] n: The length in PRA_CONV_CONF. In the current case, PRA_CONV_CONF = 24, and its data length is 2, then n = 2.

[0267] i: a natural sequence, 0, 1, ..., n-1

[0268] According to the above decoding specification, the corresponding data is 00 31, which is converted to binary as 110001. Padding it to 12 bits gives: 000000110001. Based on the segmentation rule with a starting bit of 1 and a length of 6, we can obtain 110001. According to the segmentation rule PRA_CONV_CONF: 24, we can obtain two binary numbers, 11 and 0001. After converting them to decimal, X = [3,1], we calculate their weight sum (3 × 10^3). 1 +1×10 0 The final result is 31.

[0269] It is important to note that when EUC_COEFF_X or EUC_COEFF_EXP_X elements appear in BCD, the result of the weight sum needs to be calculated according to the BNR calculation method.

[0270] 4.3 ISO#5 type data parsing

[0271] ISO#5 data is generally used to represent the assembly of alphabetic data. Its calculation method is highly consistent with BCD data, requiring binary conversion, segmentation, and division according to PRA_CONV_CONF before use. However, unlike BCD data, ISO#5 data typically converts the segmented binary data to decimal, then matches it against the ASCII code table to obtain individual English letters before concatenation. ISO#5 data is commonly used to represent information such as abbreviations for departure and arrival airports.

[0272] 4.4 BNR Type Data Parsing

[0273] Both single-data packet and multi-data packet parsing examples use BNR type engineering values ​​as examples. The parsing process involves operations such as truncation, conversion, concatenation of binary data, and calculation based on specific parameters to obtain the final engineering value result.

[0274] The above technical solution is only one embodiment of the present invention. For those skilled in the art, based on the principles disclosed in the present invention, it is easy to make various types of improvements or modifications, and not limited to the technical solutions described in the specific embodiments of the present invention. Therefore, the foregoing description is only a preferred option and is not restrictive.

Claims

1. A compilation engine for the raw QAR data frame structure of the A320 aircraft, characterized in that, The A320 model's original QAR data frame structure compilation engine adopts a multi-node horizontal deployment and distributed computing architecture, including four modules: original file reader, original data normalizer, data converter, and engineering value data writer; The raw file reader reads raw data files sent by external aviation software; The raw file reader has a built-in RawData file adapter for automatically recognizing and adapting to different formats of RawData files; the raw file reader uses a non-blocking input / output method, allowing each node to perform other tasks while waiting for data transmission; the raw file reader uses the MD5 algorithm to tag RawData files, using the MD5 value as the file's unique identifier. The raw data normalizer converts the original RawData file into a new normalized RawData file; The raw data standardizer can automatically identify different interfaces based on raw Raw Data files from various sources and versions, and then perform different standardization transformations on raw Raw Data files from different sources. The data converter decodes the new standardized RawData file according to the decoding rules to obtain plaintext engineered value data; The data converter includes three tools: a raw data packet segmentation tool for engineering values, a raw data packet combination tool for engineering values, and a raw data decoding and calculation tool for engineering values, and has a built-in decoding rule library; The data converter employs distributed parallel processing, calling multiple decoding nodes to process the new standardized RawData file simultaneously. The processing steps include: Step 51: The engineering value raw data packet segmentation tool splits the binary data of the new standardized RawData file into data packets. If the new standardized RawData file is split into a complete frame structure data packet, proceed to step 53; if the new standardized RawData file is split into multiple frame structure data packets, proceed to step 52. Step 52: The engineering value raw data packet combination tool reassembles the disassembled frame structure data packets into complete frame structure data packets; Step 53: The raw data decoding and calculation tool for engineering values ​​divides the complete frame structure data packet into multiple fixed-size data blocks and pushes the data blocks to different decoding nodes; Step 54: Each decoding node converts the decoding rules into analytical formulas, performs decoding using the analytical formulas, and transmits the decoded data blocks to the aggregation node via the network. Step 55: At the aggregation node, the raw engineering value decoding calculation tool sorts the frame data of all data blocks according to the first letter of the parameter name, and finally outputs the complete plaintext engineering value data; The engineering value data writer writes plaintext engineering value data into different storage media.

2. The A320 model original QAR data frame structure compilation engine according to claim 1, characterized in that, The raw data normalizer performs the following operations: Step 31: Preprocess the raw RawData file: Read the data in the file in byte form and convert it to binary; Step 32: Process the binary RawData file to convert it into a standardized RawData file; Step 33: Split the standardized RawData file into subframes, and then combine multiple subframes into a complete frame according to the decoding rules. Finally, each complete frame forms a new standardized RawData file.

3. The A320 model original QAR data frame structure compilation engine according to claim 2, characterized in that, Step 32 includes: the raw data standardizer abstracts a standardization model, which contains standardization conversion rules to define different processing methods for different types of binary RawData files; the raw data standardizer obtains the model, serial number, and time information from the header information of the binary RawData file, finds the standardization conversion rules for the corresponding type of binary RawData file, and performs standardization conversion processing.

4. The A320 model original QAR data frame structure compilation engine according to claim 1, characterized in that, The operation of step 52 includes: the engineering value raw data packet combination tool maps the parameters in the sub-frame to a dictionary, and directly retrieves the values ​​according to the dictionary; sorts the disassembled data packets according to the parameter names, and reassembles them into complete frame structure data packets.

5. The A320 model original QAR data frame structure compilation engine according to claim 4, characterized in that, In the decoding rules, different decimal numbers represent different data types: 1 represents the BNR number type, 2 represents the BCD combination type, 3 represents the DIS mapping type, and 4 represents the ISO#5 character type. The decoding includes: for the binary data fields of the new standardized RawData file, first querying the corresponding decimal number, and then translating it into the corresponding data type according to the decoding rules.

6. The A320 model original QAR data frame structure compilation engine according to claim 1, characterized in that, The engineering value data writer sets up a data storage engine for different storage media. During the writing of plaintext engineering value data, an independent data pipeline queue is abstracted. In the data pipeline queue, independent data pipeline pointers are specified for different storage media, and writing can be performed independently.

7. A method for compiling the original QAR data frame structure of an A320 aircraft, characterized in that, The method is implemented using the A320 model's original QAR data frame structure compilation engine as described in any one of claims 1-6, and includes: Step 1, file reading and standardization, including: Read the raw RawData file; The original RawData file is standardized to generate a new standardized RawData file. Step 2, data parsing and writing, includes: Obtain the decoding rules applicable to the current new standardized RawData files; Calculate the index bits of the engineering values ​​in the new standardized RawData file; According to the decoding rules, the new standardized RawData file is broken down into data packets; According to the decoding rules, the disassembled data packets are reassembled into complete frame structure data packets; The decoding rules are transformed into analytical formulas, and the complete frame structure data packet is converted into plaintext engineered value data using the analytical formulas. The analytical formulas are as follows: Where Y is the converted engineering unit output value, X is the original input value, Ai is the linear coefficient sequence, Bi is the exponential coefficient sequence, and n is the polynomial order; The engineering value data writer stores plaintext engineering value data on different storage media; The operation of converting a complete frame structure data packet into plaintext engineered value data includes: single data packet decoding and multi-data packet decoding. The single data packet decoding is to decode the complete frame structure data packet according to the decoding rules and convert it into decimal plaintext engineered value data. The multi-data packet decoding is based on the LCP_SAMPLE_NUMBER and LCP_PART_NUMBER parameters to obtain the decoding rules for each complete frame structure data packet. Each complete frame structure data packet is converted into binary data and then concatenated in a specific order to finally calculate the decimal plaintext engineering value data.

Images