A320 model original QAR data frame structure compiling engine and method

Abstract

The invention provides an A320 model original QAR data frame structure compiling engine and method, and belongs to the field of civil aviation. The engine adopts a multi-node transverse deployment and distributed computing architecture, and comprises four modules: an original file reader, an original data standardizing device, a data converter and an engineering value data writing device, the original file reader is used for reading an original RawData file sent by external aviation software; the original data standardizing device is used for converting an original RawData file into a new standardized RawData file; the data converter decodes the new standardized RawData file according to a decoding rule to obtain plaintext engineering value data; and the engineering value data writer writes the plaintext engineering value data into different storage media. The method is suitable for large-scale, multi-source and heterogeneous flight data processing scenes, and the data processing efficiency and the system performance can be remarkably improved.

Description

Technical Field

[0001] The present invention relates to the field of civil aviation, and specifically, to an A320 aircraft model original QAR data frame structure compilation engine and method. Background Art

[0002] Engineering value data is the most important form of 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 raw QAR data into plaintext engineering value data for monitoring and analysis is widely used in civil aviation safety, operations, maintenance, traffic control, and air traffic control.

[0003] When it comes to parsing raw QAR data, mainstream decoding software includes AGS, AirFASE, and EMS. In 2022, SAFRAN launched ALPHA, an upgraded version of AGS. These decoding software products are all foreign products, and core technologies such as decoding logic are strictly confidential, encapsulated within the software, and inaccessible. In my country, the vast majority of airlines use AGS and AirFASE for decoding, with a few using EMS. The hundreds of thousands of yuan in annual service fees for system upgrades, maintenance, and personnel training generated by these decoding software impose a significant financial burden on airlines and significantly hinder their use of QAR data. Furthermore, the traditional architecture employed by these software cannot cope with terabyte-level data growth. One airline's actual tests showed that EMS required six hours to process 10GB of QAR data, resulting in lagging data processing capabilities. Furthermore, the company lacks technological autonomy and controllability, relies on foreign experience databases for fault diagnosis, and has a weak data security system. Summary of the Invention

[0004] The present invention aims to address the above-mentioned challenges in the prior art and, in response to the shortcomings of the prior art, provides an A320 raw QAR data frame structure compilation engine and method. This engine converts standard decoding rules into a compilation formula, compiles and parses the raw QAR data (i.e., RawData files) into plaintext engineering value data in parallel according to the frame structure, and automatically incorporates all plaintext engineering value data for all time periods and parameters into a database, making it easy to retrieve and call during various business tasks.

[0005] The present invention is achieved through the following technical solutions:

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

[0007] The raw file reader reads the raw RawData file sent by the external aviation software;

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

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

[0010] The engineering value data writer writes the 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 RawData files of different formats; the raw file reader adopts a non-blocking input and output method, and each node can perform other tasks while waiting for data transmission; the raw file reader marks the RawData file through the MD5 algorithm, and uses the MD5 value as the unique identifier of the file.

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

[0013] Step 31, pre-processing the original RawData file: reading the data in the file in the form of bytes and converting it into binary;

[0014] Step 32, processing the binary RawData file and converting it into a standardized RawData file;

[0015] In step 33, the standardized RawData file is split into sub-frames, and then multiple sub-frames are combined into a complete frame according to a decoding rule. Finally, each complete frame forms a new standardized RawData file.

[0016] Furthermore, step 32 includes: the raw data normalizer abstracts a normalization model, which contains normalization conversion rules for defining different processing methods for different types of binary RawData files; the raw data normalizer obtains the machine model, machine number, and time information in the header information of the binary RawData file, finds the normalization conversion rules for the corresponding type of binary RawData file, and performs normalization conversion processing.

[0017] Furthermore, the data converter includes three tools: an engineering value raw data packet segmentation tool, an engineering value raw data packet combination tool, and an engineering value raw data decoding calculation tool, and a built-in decoding rule library; the data converter adopts distributed parallel processing, calling multiple decoding nodes to simultaneously process the new standardized RawData file, and the processing steps include:

[0018] In step 51, the engineering value raw data packet splitting tool disassembles the binary data of the new standardized RawData file into data packets. If the new standardized RawData file is disassembled into a complete frame structure data packet, the process proceeds to step 53; if the new standardized RawData file is disassembled into multiple frame structure data packets, the process proceeds to step 52;

[0019] Step 52, the engineering value original data packet assembly tool reassembles the disassembled frame structure data packets into a complete frame structure data packet;

[0020] Step 53: the engineering value raw number decoding calculation tool 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 rule into an analytical formula, performs decoding based on the analysis, and transmits the decoded data block to the aggregation node via the network;

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

[0023] Furthermore, the operation of step 52 includes: the engineering value original data packet combination tool maps the parameters in the sub-frame into a dictionary and directly takes 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 digital 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 field of the newly standardized RawData file, first query its corresponding decimal number, and then translate it into the corresponding data type according to the decoding rules.

[0025] Furthermore, the engineering value data writer sets up data storage engines for different storage media respectively. In the process of writing 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, so that writing can be performed independently.

[0026] A second aspect of the present invention provides a method for compiling the original QAR data frame structure of an A320 aircraft, which is implemented using the above-mentioned A320 original QAR data frame structure compilation engine, and includes the following steps:

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

[0028] Read the original RawData file;

[0029] Standardize the original RawData file to generate a new standardized RawData file;

[0030] Step 2: Data analysis and writing, including:

[0031] Get the decoding rules applicable to the current new standardized RawData file;

[0032] Calculating the engineering value index bit in the new standardized RawData file;

[0033] Decompose the new standardized RawData file into data packets according to the decoding rules;

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

[0035] Convert the decoding rules into analytical formulas, and convert the complete frame structure data packet into plain text engineering value data through the analytical formulas;

[0036] The engineering value data writer stores the plain text engineering value data to different storage media.

[0037] Furthermore, the operation of converting the complete frame structure data packet into plain text engineering value data includes: a single data packet decoding mode and a multi-data packet decoding mode;

[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 plain text engineering value data;

[0039] The multi-data packet decoding is based on the LCP_SAMPLE_NUMBER parameter and the LCP_PART_NUMBER parameter to obtain the decoding rules for each complete frame structure data packet, convert each complete frame structure data packet into binary data, splice them in a specific order, and finally calculate the decimal plaintext engineering value data.

[0040] Compared with the prior art, the present invention has the following beneficial effects:

[0041] The compilation engine of this invention utilizes 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 customized data sources and storage formats to achieve efficient, stable, flexible, and highly compatible data parsing capabilities. For different storage media, the compilation engine automatically converts data protocols to ensure compatibility between the data format and the target storage structure, avoiding performance bottlenecks or data conflicts caused by differences in storage platforms. It also reduces the risk of miscompilation for multi-coefficient calculations within standard decoding rules, making it particularly suitable for large-scale, multi-source, and heterogeneous flight data processing scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 is a diagram of the compilation engine architecture of the present invention;

[0043] Figure 2 It is a decoding and parsing flow chart of the present invention;

[0044] Figure 3 It is a reference information diagram for DIS type data analysis in the present invention. DETAILED DESCRIPTION

[0045] The compilation engine of this invention is capable of flexibly and efficiently decoding aircraft flight data RawData files. It supports multi-node horizontal deployment based on data size and load requirements, implementing a distributed computing architecture and 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, significantly improving data processing speed and system throughput, ensuring high efficiency and stability when processing massive amounts of data.

[0046] The present invention is described in further detail below with reference to the accompanying drawings:

[0047] Example 1

[0048] The architecture of the A320 aircraft original QAR data frame structure compilation engine of the present 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 the original RawData files generated by aviation software such as AirFase or AGS from the temporary storage device, supporting the reading of files with different data structures and the writing of multiple data sources.

[0050] The raw file reader includes built-in, scalable RawData file adapters for various formats. It automatically recognizes and adapts to various RawData file formats, ensuring versatility and flexibility in various environments. This adaptation mechanism reduces the need for manual intervention and increases the automation of decoding.

[0051] Furthermore, in the reading process of the distributed computing architecture, data needs to be frequently exchanged between nodes. In order to further improve efficiency, the present invention adopts non-blocking input and output (NIO) technology, which makes data reading and writing more efficient. Especially when transmitting a large amount 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 the utilization of network bandwidth and reducing delays and jitter in network transmission, thereby optimizing the data transmission speed between multiple nodes. This design not only improves the efficiency of data processing, but also enhances the scalability and stability of the system, and is particularly suitable for large-scale data processing environments.

[0052] Furthermore, the present invention improves the compilation engine's screening speed for unparsed raw files through MD5 digest optimization, reduces the compilation engine's I / O times for the operating system, thereby improving reading efficiency, optimizing space usage, and performing data comparison to ensure data integrity and accuracy. Specifically, during file processing, the RawData file is marked using the MD5 algorithm. The MD5 value serves as the file's unique identifier, not only ensuring the integrity of the file content but also accurately tracking the file's processing status within the system. With the help of the MD5 mark, the system can avoid repeatedly processing the same file, thereby improving efficiency and avoiding unnecessary work.

[0053] Preferably, in order to improve the reading efficiency of the original RawData file, the present invention adopts a distributed and multi-threaded approach to read the file. According to the number of files and the growth rate, it can be flexibly expanded horizontally. Each node reads data in parallel through multi-threading, thereby improving processing power and throughput.

[0054] 2. Raw data normalizer: converts the original RawData file data into the compilation engine standardized format data.

[0055] The raw data normalizer can automatically identify different interfaces based on the type and header information of original RawData files from multiple sources and different versions, and then perform different standardized conversion processing on original RawData files from different sources.

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

[0057] The specific implementation process of the standardization model of the raw data normalizer includes: when reading the raw RawData file, it automatically obtains information such as the machine model, machine number, and time from the file header information, and executes the corresponding standardization conversion rules of the raw RawData file. Preferably, the raw data normalizer has built-in version management of decoding rules, and can arbitrarily switch between different versions of decoding rules for standardization conversion.

[0058] Furthermore, the complete original RawData file is physically split into frames and sub-frames according to the decoding rules, and then converted and assembled into a new standardized RawData file. Figure 1 As shown, since the data organization form of the RawData file is in binary form, in order to split the complete data of each frame, it is necessary to read the complete original RawData file in the form of bytes, convert each byte into binary, and then perform the operation, which is "base conversion"; further, the file after "base conversion" is divided into sub-frames, and multiple sub-frames are combined into a complete frame according to the decoding rules, which is the "data preprocessing" operation. Specifically, in order to combine the divided binary data sub-frames into one piece, it is necessary to assemble the complete binary segments of each sub-frame and encapsulate them into a complete frame data structure. This frame data structure is pre-defined in the engine.

[0059] To ensure data security, the newly standardized RawData file can be binary-obfuscated during this process to generate a file with encrypted information. Ultimately, the original RawData file data can be standardized and output as 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 an original RawData file that cannot be parsed or is in an erroneous format, the compilation engine will record the error information generated by the standardization of the file, skip the processing of the original RawData file, and proceed to process the next original RawData file.

[0061] The above operations involve processing the flight data according to the defined standard format, and through these processes, a unified new standardized RawData file (i.e. Figure 2 byte data standard file shown in ), providing a unified file format for subsequent decoding, eliminating the need to worry about the specific file format during the decoding process, allowing direct decoding operations. Furthermore, since the preprocessed files are assembled in binary form, the file size can be significantly reduced, improving storage and transmission efficiency. This processing method not only simplifies the decoding process but also optimizes data management efficiency.

[0062] 3. Data Converter: This tool parses the newly standardized RawData file, processed by the Raw Data Normalizer, into plain text engineering values according to the aircraft model's decoding rules. Specifically, the built-in decoding rule library is bound to the aircraft by aircraft number. During parsing, the decoding rules are automatically matched to the newly standardized RawData file header information and parsed. The Data Converter includes three tool modules: an engineering value raw data packet splitting tool, an engineering value raw data packet assembly tool, and an engineering value raw data decoding calculation tool.

[0063] A320 aircraft RawData files may contain complex data structures. After the raw data is normalized, the data converter uses distributed parallel decoding, invoking multiple decoding nodes to simultaneously process the newly normalized RawData files during the decoding phase. Specifically, a complete processing logic chain processes only one file, while the engine can execute multiple processing logic chains simultaneously. This invention implements the processing of a complete processing logic chain through distributed computing logic.

[0064] The Engineering Value Raw Data Packet Splitting Tool uses built-in splitting and combining mechanisms to break down the binary data of newly standardized RawData files into one or more packets. Specifically, for newly standardized RawData files containing excessive data volume, varying data acquisition frequencies, files containing multiple acquisitions, and packet lengths, the tool needs to split the data into multiple packets based on specific decoding rules and data synthesis settings.

[0065] The engineering value original data packet combination tool is then used to sort the selected flight parameters (such as altitude, speed, temperature, pressure, etc.) according to the first letters of the names, and the disassembled data packets are reassembled into complete frame structure data packets in the sorted order. Specifically, each sub-frame in the binary data contains a complete data collection, for example, once a second, then the binary data generated within this second is a complete data collection. When the compilation engine parses a sub-frame, it means that a collection of the aircraft has been completely translated, so the disassembled data packets are reassembled into complete frame structure data packets. In order to ensure that each row of the sub-frame contains a complete data list, the data converter will map the parameter names in the sub-frame to a dictionary, directly take values according to the dictionary, and then sort the data packets according to the parameter names to align them to form a complete frame structure data packet.

[0066] This rule- and standard-based segmentation and combination method ensures that every 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 calculation tool divides the complete frame structure data packet into multiple fixed-size data blocks, whose size is determined by the number of computing nodes. These blocks are then pushed to multiple decoding nodes for parallel processing. Each decoding node independently parses its assigned data block, meaning that each decoding node calls the engineering value raw data decoding calculation tool to perform decoding simultaneously, effectively improving parsing efficiency.

[0068] During the decoding process, the data blocks are first identified and decoded according to the decoding rules in the decoding rule library. Specifically, the decoding is performed according to the analytical formula converted by the decoding rules. In the present invention, decoding rules are generated according to the decoding files of industry standards, and a decoding rule library is formed. At this time, the data types of all parameters have been completely determined. In the decoding rules, the data types are usually represented by the numbers 1, 2, 3, and 4. These decimal numbers represent different data types: 1 represents the BNR digital 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 decimal number corresponding to the binary field is determined directly by querying the decoding rules, and then translated into the corresponding data type according to the rules (that is, 1 represents the BNR digital type, 2 represents the BCD combination type, 3 represents the DIS mapping type, and 4 represents the ISO#5 character type). Therefore, there is no need to perform additional data conversion steps, which simplifies the processing process.

[0069] When all decoding nodes have completed the parsing, the decoded data is transmitted to the aggregation node through the network. The data transmission of the present invention supports customized network transmission protocols and dynamic adjustment of cache and transmission parameters to cope with different network conditions and system resources, ensuring efficient execution in various environments, not only ensuring efficient access to data during large-scale processing, but also significantly reducing the latency of the system. Since the decoding process is a multi-node multi-threaded work, the order of the main and sub-frames and frame parameters is chaotic when the overall decoding is completed, and all data blocks need to be sorted at the aggregation node: the sorting first sorts the data in each sub-frame in units of sub-frames, and the sorting method is to sort and integrate in ascending order of the first letter of the name of each parameter (all data belong to a single parameter). Afterwards, the four sub-frames are integrated as a whole, then sorted into the correct main frame in sequence, and finally sorted according to the main frame sequence number. Specifically, in the A320, every four sub-frames are described as one frame. Here, integration involves marking each of the four sub-frames with a sequence number indicating which main frame and sub-frame they belong to, and sorting the sub-frames of the same main frame from 1 to 4 according to the sequence number tags. The sub-frames are then sorted in ascending order based on the main frame sequence numbers, ultimately outputting the complete plaintext engineering value 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 amounts of 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 the new data adds a field, the historical data to be reused does not have this field, so re-decoding is required to complete the field. To speed up decoding efficiency, the secondary decoded data will only re-decode the historical data with modified or newly added fields, rather than re-translating all historical data. Historical data that has not been modified will continue to use the completed decoding results.

[0071] 4. Project value data writer: The parsed plaintext project value data is transferred to the project value data writer. The project value data writer also includes a data storage engine (different data storage engines are available for different storage media). Different data storage engines are called for different storage media to write the plaintext project value data into different storage media including relational databases, distributed storage systems, cloud storage, Excel tables, etc.

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

[0073] Furthermore, during the data writing process, the present invention abstracts an independent data pipeline queue to account for write performance issues in downstream databases. Within this pipeline queue, independent data pipeline pointers are assigned for each user-selected output storage medium. Taking the Redis and HBase databases as examples, when data is written, the corresponding data pointer index is 1 in Redis, while the corresponding data pointer index is 0 in HBase. These two data pointers are independent of each other and can be written and managed independently. If the user selects multiple storage media for output, the data in the pipeline queue must wait until all storage media are processed and a completion signal is received before it can be cleared. In other words, the queue is cleared only after all data in the batch has been written to the corresponding database and a completion signal has been received. If the user selects only one storage medium, data is read and released in a queue. Once a data item is read, the next data item is released. In other words, once a data item is written to the database, the queue is cleared. This mechanism ensures system efficiency while also ensuring flexibility and scalability in a multi-database environment.

[0074] Furthermore, the project value data writer has a built-in unified data protocol. Data decoded by the data converter is automatically converted to the corresponding data format based on the storage engine type and stored in different table models or structures. It can also be used to write only some fields as needed to meet data storage requirements in different scenarios.

[0075] Example 2

[0076] like Figure 2 As shown, the present invention uses the compilation engine to parse the aircraft flight data RawData file. The process execution steps are as follows:

[0077] Step 1: Data reading and standardization:

[0078] Step 1-1, data reading

[0079] The raw file reader first reads the original RawData file into the compilation engine memory. During the reading process, in order to improve the reading efficiency of the file, the present invention adopts a distributed and multi-threaded approach to read the file. Depending on the number of files and the growth rate, the system can be flexibly expanded horizontally.

[0080] During file processing, the system uses the MD5 algorithm to mark the original RawData file to improve reading efficiency. As a unique identifier for the file, the MD5 value not only ensures the integrity of the file content, but also accurately tracks the file processing status within the system. With the help of MD5 marking, you can avoid repeatedly processing the same file, thereby improving efficiency and avoiding unnecessary work.

[0081] Due to the use of distributed processing, data needs to be frequently exchanged between nodes. To further improve efficiency, the present invention adopts non-blocking input and output (NIO) technology, which makes data reading and writing more efficient. Especially when transmitting large amounts of decoded data between multiple nodes, non-blocking input and output technology can significantly improve data transmission performance. Through non-blocking I / O, nodes can perform other tasks while waiting for data transmission, maximizing the utilization of network bandwidth and reducing delays and jitter in network transmission, thereby optimizing the data transmission speed between multiple nodes.

[0082] Preferably, since there is a situation where the original RawData file has been standardized and stored in the engine's memory and is then acquired by the parsing engine again, in order to avoid errors caused by data duplication, the original file reader first verifies whether the read original RawData file is standardized. If the file has been standardized, the file identifier is modified to "standardization completed", and the processing of the original RawData file is skipped, and the next original RawData file is processed.

[0083] Step 1-2: Data standardization

[0084] The raw data normalizer performs standardization to address the issue of inconsistent file formats among raw RawData files from different sources. To this end, the compilation engine abstracts a standardization model that can process raw RawData files differently based on their source. Based on the decoding rules, the raw RawData file is segmented into subframes, and multiple subframes are combined to form a complete frame. Specifically, based on the decoding rules, the decimal 64, 65, 66, and 67 are first searched for as synchronization words to determine the starting position of the subframe, thereby accurately segmenting the raw RawData file into multiple subframes. Then, by combining these multiple subframes in an orderly manner, a complete frame is successfully constructed. For example, the A320 aircraft has a frame length of 1024, meaning each data frame contains 1024 bytes of data, with one frame every 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 has four sub-frames, and the synchronization words of each sub-frame are 64, 65, 66, and 67 in decimal. Assuming that we are looking for the first sub-frame, we will look for a binary with a starting bit of 64 in decimal. We will calculate backward and select two bytes of data (wordNum×2–1, wordNum×2). After reversing the high and low bits of the two bytes (for example, 05 43 is reversed to 43 05), we will convert it into binary data, which is the first sub-frame. The search rules for subsequent sub-frames are the same as this rule, until we find the frame segment with the starting bit of 67, which means that all four sub-frames have been found. At this point, a new standardized RawData file (i.e. Figure 2 At the same time, the file status tag is modified to mark it as "standardization completed" and stored in the memory of the compilation engine.

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

[0086] Step 2: Data analysis and writing:

[0087] Retrieve the new standardized RawData file that has completed the standardization process and perform decoding.

[0088] Step 2-1: Obtain decoding rules

[0089] A decoding rule library is pre-set in the compilation engine, and decoding rules applicable to the current newly standardized RawData file are obtained from the decoding rule library. Preferably, it is necessary to check whether the decoding rules in the decoding rule library accurately describe 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 engineering value index

[0091] The calculation method is to identify the LCP_SAMPLE_NUMBER and LCP_PART_NUMBER parameter files, where the wordNum field represents the position index of the complete frame where the column data is located in the new standardized RawData file.

[0092] Step 2-3: Engineering value decomposition

[0093] The Engineering Value Raw Data Packet Splitting Tool splits the newly standardized RawData file into one or more packets according to the decoding rules. Splitting a newly standardized RawData file into multiple packets is often necessary for reasons such as excessive data volume, complex data structure, varying data acquisition frequencies, variable packet lengths, and distributed processing requirements. These situations require comprehensive configuration of the splitting process based on the specific decoding rules and data requirements.

[0094] Step 2-4: Frame structure reassembly

[0095] If an engineering value requires multiple data packets to represent, these data packets are combined into a complete frame structure data packet. Specifically, the engineering value original 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 situation rule field in the decoding rule base is longitude, latitude, departure airport, landing airport, elevation angle, depression angle, bank angle, airspeed, ground speed, and radio altitude). Specifically, each sub-frame in the original data contains a complete data collection. When the compilation engine parses a sub-frame, it represents that a collection of the aircraft has been completely decoded. Reassembling the sub-frames is to reassemble the disassembled data packets into a complete frame structure data packet. This step requires an in-depth understanding of the structure of the data frame 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 has one or more data frame packets.

[0096] To ensure that the data in the reorganized frame is correctly aligned, each row of the sub-frame of the present invention contains a complete data list. The compilation engine maps the plaintext data of the sub-frame into a dictionary, and then directly takes the value of the parameter according to the decoding rules, and sorts the data packets according to the parameter name to align them.

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

[0098] The engineering value raw number decoding calculation tool converts the complete frame structure data packet into plaintext engineering value data according to the decoding rules in the decoding rule library. During the decoding process, the binary blocks in the individual data packets are first identified, and the pre-established decoding rules are converted into analytical formulas (the specific application of the decoding rules is described in Example 3) for decoding. In the present invention, the industry-standard decoding file forms the decoding rules, at which point the data types of all parameters are completely determined. In the decoding file, the data type is usually represented by the numbers 1, 2, 3, and 4, which correspond to different data types of RawData: 1 represents the bnr digital 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 the data type is consistently defined throughout the entire system and is directly applied during the decoding process without the need for dynamic conversion or additional calculations, ensuring 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 positioning is determined based on wordNum, which is specifically described in Example 3.

[0100] Furthermore, the engineering value raw number decoding calculation tool reads binary data, fills the high-order bits with 0 to make it 12 bits, and 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 processing parameters such as the sign bit, coefficient, and exponent term of the data.

[0101] Specifically, the analytical formula used to calculate the final engineering value for data containing a single coefficient is:

[0102] Y=A0×10 B0 ×X

[0103] in,

[0104] Y: The converted output value in engineering units;

[0105] X: Original input value (RawValue), which only appears as a multiplier in the last term of the formula;

[0106] A0 corresponds to parameter EUC_COEFF_0;

[0107] B0 corresponds to 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: The converted output value in engineering units;

[0112] X: Original input value (RawValue), which only appears as a multiplier in the last term of the formula;

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

[0114] EUC_COEFF_n;

[0115] Bi(i=0,1,…,n): exponential coefficient sequence, corresponding to parameters EUC_COEFF_EXP_0 to

[0116] EUC_COEFF_EXP_n;

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

[0118] The above formula is used to calculate the final plaintext engineering value data. The above 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] Step 2-6: Write data

[0120] The plaintext engineering value data is stored in different storage media through the engineering value data writer to complete the parsing work. This step requires ensuring that the data can be correctly written to the designated 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 uses an abstract interface definition based on the data storage engine, providing an open interface design that can be optimized for different database types 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 to consider the write performance of the downstream database. 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 of overall decoding rules

[0124] In step 2 of Example 2, since the standardized new standard RawData file uses binary random order encoding, the decoding rules specify how to disassemble, compile, and combine binary files. Specifically, the decoding rules, without any processing, are multiple hash files. The overall understanding of the decoding rules is to describe the important parameters in text form so that the compilation engine can recognize these hash files and convert the data in the files into regularized data that the engine can read.

[0125] Specifically, before performing specific data analysis, you need 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 model to be decoded. These indicators are the basis for analyzing the data frame structure.

[0126] In RawData files, data is typically presented in binary format because it's more compact and easier to determine. Before decoding, you need to determine the key parameters of the device being decoded, including the frame length, data acquisition rate, synchronization word, and data packet length. This allows the compilation engine to automatically determine these parameters based on pre-set decoding rules.

[0127] Taking the A320 as an example, its length is 1024, with a frame length of four seconds and four subframes per frame. The synchronization word for each subframe is 64, 65, 66, and 67 in decimal. The data packet consists of 12 binary bits. When decoding data, the compilation engine uses decoding rules to find the subframe corresponding to the engineering value. Starting with the synchronization word, it calculates backward and selects two bytes of data: (wordNum × 2 – 1, wordNum × 2). The two bytes are converted to binary data after flipping the high and low bits (for example, 05 43 is flipped to 43 05). Any high-order bits less than 12 bits are padded with 0s until the number 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 one data packet cannot store the data completely, multiple data packets will be used to store the data in the RawData file. In step 2 of Example 2, the compilation engine performs a decoding process. The decoding methods for single and multi-data packets are different. The decoding methods for the two data packets are described below.

[0130] (1) Single data packet decoding

[0131] Single data packet decoding only requires splitting the standardized new standard RawData file binary data according to the decoding rules. The specific rules include:

[0132] 1.1. Binary data segmentation

[0133] Binary data is decoded by accurately truncating specific bits from the binary data based on the start and length parameters in the decoding rules. For example, for the binary data 000101101110, with start = 1, length = 7, and signBit = 1, truncating 7 bits from right to left yields the truncated result 1101110.

[0134] 1.2 Sign bit processing

[0135] Sign bit identification: Identify the sign of the data based on the signBit parameter. If signBit = 1, it means the data is a signed number and needs to be processed. 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-order bit is padded with 1 to reach 32 bits, which is the maximum number of bits in the JVM Integer. The two's complement is 1111111111111111111111111101110.

[0137] 1.3 Data Conversion

[0138] The original file's calculation rules do not include floating-point types in binary conversions; only integers are included. These integers can be calculated based on the divisor parameter. Convert the divided binary data to decimal. Use the standard binary-to-decimal conversion algorithm. For example, 1101110 converts to decimal as 118, but after accounting for the sign bit, it is -18.

[0139] 1.4 Coefficient and exponential term processing

[0140] The original data RawValue obtained by decoding needs to be calculated according to the calculation formula in the decoding specification, and the result of the calculation can be used as the final value.

[0141] Specifically, the analytical formula used to calculate the final engineering value for data containing a single coefficient is:

[0142] Y=A0×10 B0 ×X

[0143] in,

[0144] Y: The converted output value in engineering units;

[0145] X: Original input value (RawValue), which only appears as a multiplier in the last term of the formula;

[0146] A0 corresponds to parameter EUC_COEFF_0;

[0147] B0 corresponds to 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: The converted output value in engineering units;

[0152] X: Original input value (RawValue), which only appears as a multiplier in the last term of the formula;

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

[0154] EUC_COEFF_n;

[0155] Bi(i=0,1,…,n): exponential coefficient sequence, corresponding to parameters EUC_COEFF_EXP_0 to

[0156] EUC_COEFF_EXP_n;

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

[0158] For example, during the decoding process, X(RawValue)=-18 is obtained, and in the decoding specification file, the definition parameters of this parameter are as follows:

[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. n is 1. After 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 value must not exceed MAX, otherwise MAX is used as the final result; the minimum value must not be less than MIN, otherwise MIN is used as the final result. For character data, the decoding rules provide detailed explanations of these parameters, such as 0 representing NO and 1 representing OFF. If the calculated value falls outside this interpretation range, the binary value will be directly recorded as the final value.

[0166] (2) Multi-packet decoding

[0167] Multiple data packets typically occur when a single packet structure cannot carry the complete data, so multiple packets are used to store the data, and each subframe may be captured multiple times. When a project value requires multiple packets to store, it is necessary to obtain the decoding rules for each packet based on parameters such as LCP_SAMPLE_NUMBER and LCP_PART_NUMBER. After converting each packet into binary data, the data is concatenated in a specific order to calculate the final decimal data result.

[0168] For example, the A320's radio altitude engineering data is collected four times per second, with each acquisition represented by two data packets. First, the data packets corresponding to the acquisition frequency must be found, then converted and concatenated according to their respective decoding rules to ultimately obtain the complete plaintext engineering value data.

[0169] The specific decoding rules are:

[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 (part number) parameters.

[0172] For example, the radio altitude engineering value of the A320 is collected four times per second, and each collection is 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] Among them, wordNum represents the position index of the complete frame where the column data is located in the original file.

[0176] Start indicates the starting index of the column data in the complete frame, and Length indicates the length of the binary represented by the column data in the complete frame.

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

[0178] You need to first find the data packet corresponding to the sampling number, and then sort it according to the part number. Specifically, LCP_SAMPLE_NUMBER represents the number of acquisitions, and LCP_PART_NUMBER represents the order of multiple data packets. Taking the first acquisition as an example, the process of finding the data packet with LCP_SAMPLE_NUMBER = 1 is:

[0179] Identify LCP_SAMPLE_NUMBER and LCP_PART_NUMBER:

[0180] ●Sampling number 1: LCP_SAMPLE_NUMBER = 1

[0181] ●Part number 1: LCP_PART_NUMBER = 1

[0182] ●Part number 2: LCP_PART_NUMBER = 2

[0183] Get the data packet:

[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 and other information and wait for manual review before re-decoding the parameters.

[0187] 2.2 Data Packet Conversion and Splicing

[0188] According to the single data packet decoding method, after the first data packet and the second data packet are converted into binary data respectively, the binary data of multiple data packets are spliced together in a specific order (usually in the order of part numbers).

[0189] Specifically, the binary conversion process is as follows: each data packet is converted into binary data, and the binary data in each data packet is intercepted and processed according to respective decoding rules (such as parameters such as start, length, signBit, etc.).

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

[0191] First packet conversion:

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

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

[0194] Interception result: Intercept 12 bits from right to left, and get 101101110 (if it is less than 12 bits, fill the high bit with zero to get 000101101110)

[0195] Second packet conversion:

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

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

[0198] Intercept result: Intercept the 9th to 12th bits from right to left, and get 0011

[0199] Furthermore, the binary data splicing process is:

[0200] Specifically, the two binaries are concatenated in reverse order (the binary of the second data packet is in front and the binary of the first data packet is in the back).

[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, the concatenated binary data is 00110011101110.

[0202] 2.3. Sign bit and data type processing

[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, it indicates a negative number, and 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 Coefficient and exponential term processing

[0209] The final engineering value is calculated using the formula for the single coefficient. The formula is as follows:

[0210] Y=A0×10 B0 ×X

[0211] in,

[0212] Y: The converted output value in engineering units;

[0213] X: Original input value (RawValue), which only appears as a multiplier in the last term of the formula;

[0214] A0 corresponds to parameter EUC_COEFF_0;

[0215] B0 corresponds to parameter EUC_COEFF_EXP_0.

[0216] Multiple coefficients, use the formula to calculate the final engineering value, the formula is as follows:

[0217]

[0218] in,

[0219] Y: The converted output value in engineering units;

[0220] X: Original input value (RawValue), which only appears as a multiplier in the last term of the formula;

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

[0222] EUC_COEFF_n;

[0223] Bi(i=0,1,…,n): exponential coefficient sequence, corresponding to parameters EUC_COEFF_EXP_0 to

[0224] EUC_COEFF_EXP_n;

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

[0226] Coefficient and exponent parameter application: According to the EUC_COEFF_0 and EUC_COEFF_EXP_0 parameters, the converted decimal number is operated.

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

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

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

[0230] (3) Engineering value decoding specifications

[0231] The decoding rules in the decoding rule library refer to the AcquiredParameters file of the corresponding model, which contains the following decoding information:

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

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

[0234] PRM_PARAMETER_SIGNED = "1": sign bit filled 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, that is, A in the formula n ;

[0241] EUC_COEFF_EXP_n: Exponent term n, that is, B in the formula n ;

[0242] LCP_SAMPLE_NUMBER: The order in which data packets are collected multiple times 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 multiple collections occur).

[0243] LCP_PART_NUMBER: The sub-packet sequence in scenarios where multiple data packets represent a single data item. (When a data item is too large to fit in 12-bit binary, it is split into two data packets. This field describes the order of the complete data item in multiple data packets.)

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

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

[0246] LCP_BIT_LENGTH: The length of the binary under the data packet (that is, the length of the binary represented by this column of data in the complete frame);

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

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

[0249] Different data types have different parsing methods. 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 analysis

[0251] Discrete data uses a single data packet decoding method to convert the data into decimal data and then use the mapping relationship (such as Figure 3 For example, if the calculation result is 1, "IR / GPS" is returned.

[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 does not 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 analysis

[0254] Usually used to represent data such as years and months. This type of data is decoded separately according to the description in 1.1 of the above single data packet decoding. The final result is the binary data segmented. For example, the decoding specification of the DAY field is as follows:

[0255] PRA_CONV_CONF: 24, indicating that the final result is 6 bits, which needs to be divided into the first 2 and the last 4 bits for conversion;

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

[0257] PRM_MAX_OP_RANGE: 31, indicating that the maximum value of the 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 weighted sum formula is:

[0262]

[0263] in:

[0264] Y: The converted output value in engineering units;

[0265] X: is the calculated value of RawValue, such as the following example, X = [3, 1]

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

[0267] i: 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, and supplemented to 12 bits as: 000000110001. According to the segmentation rule, the starting bit is 1 and the length is 6, so 110001 can be obtained. According to the segmentation rule PRA_CONV_CONF: 24, 11 and 0001 can be obtained. After converting them to decimal, X = [3, 1] and then calculating their weight sum (3×10 1 +1×10 0 ), the final result is 31.

[0269] It should be noted here that when EUC_COEFF_X or EUC_COEFF_EXP_X elements appear in BCD, the weighted sum result needs to be calculated according to the BNR calculation method.

[0270] 4.3. ISO#5 type data analysis

[0271] ISO#5 data is generally used to represent alphabetic data. Its calculation method is highly consistent with BCD data, requiring binary conversion, segmentation, and fragmentation using PRA_CONV_CONF before use. However, unlike BCD data, ISO#5 data is typically converted to decimal after segmentation, then matched against the ASCII code table to obtain an English letter before concatenation. ISO#5 data is generally used to represent information such as the English abbreviations of departure and arrival airports.

[0272] 4.4. BNR type data analysis

[0273] The parsing cases for single and multiple data packets are all based on BNR-type engineering values. The parsing process involves intercepting, converting, and concatenating binary data, as well as performing calculations based on specific parameters to obtain the final engineering value results.

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

Claims

1. An A320 aircraft model original QAR data frame structure compilation engine, characterized by: The A320 aircraft model 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 the raw RawData file sent by the external aviation software; The raw data normalizer converts the original RawData file into a new standardized RawData file; The data converter decodes the new standardized RawData file according to the decoding rules to obtain the plaintext engineering value data; The engineering value data writer writes the plaintext engineering value data into different storage media.

2. The A320 aircraft original QAR data frame structure compilation engine according to claim 1, characterized in that: The raw file reader has a built-in RawData file adapter for automatically identifying and adapting RawData files of different formats; the raw file reader adopts a non-blocking input and output method, and each node can perform other tasks while waiting for data transmission; the raw file reader marks the RawData file using the MD5 algorithm, and uses the MD5 value as the unique identifier of the file.

3. The A320 aircraft original QAR data frame structure compilation engine according to claim 1, characterized in that: The raw data normalizer performs the following operations: Step 31, pre-processing the original RawData file: reading the data in the file in the form of bytes and converting it into binary; Step 32, processing the binary RawData file and converting it into a standardized RawData file; In step 33, the standardized RawData file is split into sub-frames, and then multiple sub-frames are combined into a complete frame according to a decoding rule. Finally, each complete frame forms a new standardized RawData file.

4. The A320 aircraft original QAR data frame structure compilation engine according to claim 3, characterized in that: The step 32 includes: the raw data normalizer abstracts a normalization model, which includes normalization conversion rules for defining different processing methods for different types of binary RawData files; the raw data normalizer obtains the machine model, machine number, and time information in the header information of the binary RawData file, finds the normalization conversion rules for the corresponding type of binary RawData file, and performs normalization conversion processing.

5. The A320 aircraft original QAR data frame structure compilation engine according to claim 1, characterized in that: The data converter includes three tools: an engineering value original data packet segmentation tool, an engineering value original data packet combination tool, and an engineering value original data decoding calculation tool, and a built-in decoding rule library; The data converter uses distributed parallel processing, calling multiple decoding nodes to process the new standardized RawData file simultaneously. The processing steps include: In step 51, the engineering value raw data packet splitting tool disassembles the binary data of the new standardized RawData file into data packets. If the new standardized RawData file is disassembled into a complete frame structure data packet, the process proceeds to step 53; if the new standardized RawData file is disassembled into multiple frame structure data packets, the process proceeds to step 52; Step 52, the engineering value original data packet assembly tool reassembles the disassembled frame structure data packets into a complete frame structure data packet; Step 53: the engineering value raw number decoding calculation tool 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 rule into an analytical formula, performs decoding according to the analytical formula, and transmits the decoded data block to the aggregation node via the network; Step 55: At the aggregation node, the engineering value original number decoding calculation tool sorts the frame data of all data blocks according to the first letters of the parameter names, and finally outputs the complete plaintext engineering value data.

6. The A320 aircraft original QAR data frame structure compilation engine according to claim 5, characterized in that: The operations of step 52 include: the engineering value original data packet combination tool maps the parameters in the sub-frame into a dictionary and directly obtains values according to the dictionary; sorts the disassembled data packets according to the parameter names and reassembles them into a complete frame structure data packet.

7. The A320 aircraft original QAR data frame structure compilation engine according to claim 5 or 6, characterized in that: In the decoding rules, different decimal numbers represent different data types: 1 represents the bnr digital 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 field of the newly standardized RawData file, first querying its corresponding decimal number, and then translating it into the corresponding data type according to the decoding rules.

8. The A320 aircraft original QAR data frame structure compilation engine according to claim 1, characterized in that: The engineering value data writer sets up data storage engines for different storage media respectively. In the process of writing 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, so that writing can be performed independently.

9. A method for compiling the original QAR data frame structure of an A320 aircraft, characterized in that: The method is implemented using the A320 aircraft original QAR data frame structure compilation engine according to any one of claims 1 to 8, comprising: Step 1: File reading and standardization, including: Read the original RawData file; Standardize the original RawData file to generate a new standardized RawData file; Step 2: Data analysis and writing, including: Get the decoding rules applicable to the current new standardized RawData file; Calculating the engineering value index bit in the new standardized RawData file; Decompose the new standardized RawData file into data packets according to the decoding rules; According to the decoding rules, the disassembled data packets are reassembled into complete frame structure data packets; Convert the decoding rules into analytical formulas, and convert the complete frame structure data packet into plain text engineering value data through the analytical formulas; The engineering value data writer stores the plain text engineering value data to different storage media.

10. The A320 aircraft original QAR data frame structure compilation method according to claim 9, characterized in that: The operation of converting the complete frame structure data packet into plain text engineering value data includes: a single data packet decoding mode and a multi-data packet decoding mode; The single data packet decoding is to decode the complete frame structure data packet according to the decoding rules and convert it into decimal plain text engineering value data; The multi-data packet decoding is based on the LCP_SAMPLE_NUMBER parameter and the LCP_PART_NUMBER parameter to obtain the decoding rules for each complete frame structure data packet, convert each complete frame structure data packet into binary data, splice them in a specific order, and finally calculate the decimal plaintext engineering value data.

Images