Avionics application configuration method based on message driving and dynamic loading mechanism

Abstract

The invention relates to an avionics application configuration method based on message driving and a dynamic loading mechanism, which comprises the following steps of: generating a hierarchical binary configuration file containing port configuration information and mapping configuration information based on an avionics system interface control file in a construction stage, and analyzing and loading the binary configuration file to a global structure body in an operation stage, according to the method and the system, the mapping configuration information is automatically matched according to the message type of the to-be-processed message, and after parameter configuration is carried out on the corresponding equipment port according to the port configuration information, data reading and writing are carried out by utilizing the information in the equipment resident index, so that message driving and dynamic loading of application configuration are realized. According to the method, manual configuration errors can be avoided, multi-protocol adaptation is supported, only binary configuration files need to be updated when protocols are modified, the operation can be carried out offline, port mapping and related settings are automatically matched by the system according to message types, and therefore the configuration management efficiency and reliability of the avionics system are improved, and the integrity of configuration data is guaranteed.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of configuration management of avionics system, and particularly relates to an avionics application configuration method based on a message driving and dynamic loading mechanism. BACKGROUND

[0002] Traditional avionics system adopts a hard coding mode to manage configuration data, and has poor scalability, complex maintenance and lacks integrity guarantee. With the progress of avionics technology, the communication data volume between airborne systems significantly increases, and the complexity and scale of configuration data also expand. The avionics system needs to support multi-protocol data interaction (such as ARINC 429, A664, A825, etc.), but the hard coding solidifies the protocol processing logic in the code. When a new protocol is added or the mapping relationship is modified, the entire system needs to be recompiled and deployed, which leads to a prolonged development cycle. This static configuration mode cannot realize the driving of the routing behavior of the system by the data flow itself (i.e. message). The port configuration (such as sampling rate, queue length, port direction, refresh frequency) and the mapping rule (such as message ID association, such as the association of message and port) are dispersed in different modules of the code, and the modification of a single parameter needs to search the related code globally. When the version is iterated, configuration inconsistency is prone to occur, and the troubleshooting efficiency is low, and unified management is lacking. The configuration data is directly embedded in the executable file, and there is no runtime checking mechanism. Once the configuration file is tampered with or damaged during transmission, it may lead to data parsing failure, or trigger an unmanageable behavior. The traditional scheme relies on manual code review and test coverage, and cannot completely exclude configuration risks. These defects of static configuration are particularly prominent in the integrated modular avionics (IMA) platform requiring dynamic reconstruction, and cannot meet the dynamic loading and flexible configuration requirements when multiple applications reside on the same hardware platform. SUMMARY

[0003] The technical problem to be solved by the present application is to provide an avionics application configuration method based on a message driving and dynamic loading mechanism, so as to solve the problems of lack of flexibility, inability to dynamically adapt and difficult maintenance of the traditional hard coding configuration mode.

[0004] The technical scheme adopted by the present application to solve the technical problem is: providing an avionics application configuration method based on a message driving and dynamic loading mechanism, comprising:

[0005] The construction stage: based on the avionics system interface control file, a hierarchical binary configuration file is generated, which includes port configuration information, mapping configuration information and device residence index, the port configuration information is used to define port parameters, the mapping configuration information is used to define the mapping relationship between messages and port types driven by message types of different protocols, and the device residence index is used to encode the physical position of the device and record the byte offset of the corresponding configuration data of the device in the port configuration and mapping configuration;

[0006] The running stage: when the avionics system is running, the binary configuration file is parsed and loaded into a global structure, the mapping configuration information is automatically matched according to the message type of the message to be processed, and the device port is configured according to the port configuration information, then the information in the device residence index is used for data reading and writing, so as to realize message-driven and dynamic loading of application configuration.

[0007] Further, the physical position of the device is achieved by splitting the physical position of the device into a high field and a low field, using the high field to represent the left device or the right device, and using the low field to represent the device number, in a way of compressing the coding length.

[0008] Further, the type of the device port includes a sample receiving port, a queue receiving port, a sample sending port and a queue sending port.

[0009] Further, the definition of the mapping relationship between the messages and the device ports driven by the message types of different protocols includes:

[0010] According to the message type, the corresponding preset device port type in the mapping configuration information is found;

[0011] Based on the finding result, the corresponding sending device port and receiving device port are matched for the message type, and a bidirectional mapping channel is established;

[0012] A unique ID is set for the matching result to identify the mapping relationship between the message type and the device port.

[0013] Further, the finding of the corresponding preset device port type in the mapping configuration information according to the message type includes:

[0014] The a429msgrx message, the analogmsgrx message and the discretemsgrx message correspond to the sample receiving port;

[0015] The a664msgrx message and the a825msgrx message correspond to the queue receiving port;

[0016] The discrete msgtx message corresponds to a sampling sending port.

[0017] The a664 msgtx message corresponds to a queue sending port.

[0018] Further, the hierarchical binary configuration file further comprises:

[0019] Header information for storing file identification, version number, creation timestamp, compatibility information and part number.

[0020] Further, the system interface control file is used to generate a binary configuration file containing port configuration information and mapping configuration information, comprising:

[0021] The system interface control file is obtained, from which configuration information, data port settings and data mapping relationship are extracted, and then the port configuration information and mapping configuration information are converted and written into the corresponding level of the binary configuration file.

[0022] Further, it further comprises:

[0023] In the construction phase, a CRC check code is generated according to the generated configuration data and stored in the binary configuration file;

[0024] In the running phase, the CRC check code is recalculated according to the read configuration data, and compared with the check code stored in the file to ensure that the complete configuration data is correctly loaded.

[0025] Further, it further comprises:

[0026] The binary configuration file is parsed to extract the configuration data of port configuration, message configuration and mapping relationship configuration;

[0027] The extracted configuration data is exported as an interface control file to realize reverse conversion and traceability management of the configuration data.

[0028] Further, the system interface control file is an EoICD table.

[0029] Beneficial effects

[0030] Compared with the prior art, the application has the following advantages and positive effects: the application can automatically generate a binary configuration file based on an interface control file, replace a traditional hard coding mode, completely avoid errors in manually writing configuration codes, only need to update the interface control file when modifying the configuration, and can generate a binary file again without modifying avionics system codes or recompiling and deploying; the application associates messages and port types of different protocols through mapping configuration in a hierarchical structure, realizes correct flow of cross-protocol data, only needs to extend protocol configuration and mapping rules in the interface control file when adding a new protocol, can support seamless adaptation of multiple protocols without modifying the hierarchical structure of the binary file, and meets complex avionics environment requirements; the application adopts hierarchical storage to ensure structured configuration data, directly corresponds fields of a global structure body after data analysis, directly loads the global structure body after analysis, supports dynamic adjustment of configuration during running, meets core requirements of an integrated modular avionics (IMA) platform in which multiple applications reside in the same hardware and are dynamically reconstructed, and the like; in addition, the application calculates a CRC32 value of all data except a CRC field when generating a binary file, recalculates and compares the check value when loading, can completely prevent configuration files from being tampered with or damaged during transmission, guarantees high reliability of configuration data, and reduces running risks. BRIEF DESCRIPTION OF DRAWINGS

[0031] Figure 1 is a flowchart of an embodiment of the application;

[0032] Figure 2 is a flowchart of preferred embodiment 1 of the application;

[0033] Figure 3 is a schematic diagram of setting a resident position coding rule of preferred embodiment 1 of the application;

[0034] Figure 4 is a core data configuration structure diagram of preferred embodiment 1 of the application;

[0035] Figure 5 is a data port and mapping configuration index lookup flowchart of preferred embodiment 1 of the application. DETAILED DESCRIPTION

[0036] The application will be further described below in conjunction with specific embodiments. It should be understood that these embodiments are only used to illustrate the application and not used to limit the scope of the application. In addition, it should be understood that those skilled in the art can make various modifications or changes to the application after reading the content of the application, and these equivalent forms also fall within the scope defined by the appended claims of the application.

[0037] Embodiments of the application relate to an avionics application configuration method based on a binary configuration file, comprising:

[0038] An interface control file is acquired, and configuration items thereof are divided into port configuration, message configuration, and mapping relationship configuration;

[0039] According to preset output item content of the interface control file, necessary configuration parameters of the port configuration data, the message configuration data, and the mapping relationship configuration data are intelligently screened, and the necessary configuration parameters are saved to corresponding structure bodies to form a binary configuration file; the binary configuration file is stored based on a hierarchical structure, and each hierarchical structure body corresponds to a corresponding field of a global structure body of the avionics system, is loaded into the global structure body at runtime after being parsed by a set instruction, so that dynamic loading of application configuration is achieved.

[0040] More specifically, the binary configuration file includes the following parts:

[0041] Port configuration is used to define parameters of a device port;

[0042] Mapping configuration is used to define a mapping relationship between a message and a device port;

[0043] Device residence index is used to encode a physical position of a device and record byte offsets of corresponding configuration data of the device in the port configuration and the mapping configuration.

[0044] In addition, header information can be set to store file identification, a version number, a creation timestamp, compatibility information, and a part number. Meanwhile, in order to improve data reliability, a CRC32 check mechanism can also be used to ensure configuration integrity and prevent data tampering or damage.

[0045] As shown in FIG. 1, Figure 1 the binary configuration file can be generated by the following method:

[0046] (1) Configuration data screening

[0047] Based on an interface control file (EoICD table), a binary configuration file is generated, which includes port parameters, message types, and mapping relationships, and is screened based on data in the configuration table file. Port-related configuration, message-related configuration attribute parameters, and mapping message-related configuration attributes are extracted. The screened data is analyzed, integrated, and counted, and is used as relevant input of a binary configuration structure body.

[0048] (2) Structured configuration file generation and management

[0049] Hierarchical storage structure, based on an interface control file (such as an EoICD table), a binary configuration file is generated and organized according to the following levels:

[0050] Header information (BINHeader) stores file identification, a version number (VersionNum), a creation timestamp (CreateTime), and a part number (Partnum).

[0051] Device Residence Index: Encodes the physical location of the device and records the byte offset of the configuration data.

[0052] PortConfig defines the parameters of four types of ports. RxSampling: ID, Port_Name, Port_SIZE, Port_Refresh. RxQueue: additionally contains Port_QueueLength. TxSampling and TxQueue: parameters are the same as receiving.

[0053] MappingConfig: stores the mapping relationship between message types (such as A429MsgRx) and ports (Relationship structure).

[0054] Dynamic loading mechanism: read_from_file() parses binary files to load configuration into global structures (such as XMLdata), supporting runtime dynamic adjustment.

[0055] (3) Data mapping and port configuration:

[0056] Core data configuration PortConfig (input and output port configuration information data) and MappingConfig (all input and output port mapping configuration data) are filled according to configuration attributes. Data ports are mapped to message protocols for input and output, and the PortConfig structure lists the types of each port (sampling receiving and sending ports, queue receiving and sending ports). The MappingConfig structure defines the mapping rules between ports to ensure that data can flow correctly between modules. These configurations include port ID information, message attributes, data formats, and message protocols, ensuring that the system can correctly exchange and process data during runtime. According to the message ID of the receiving port and the message ID of the sending port, a one-to-one mapping relationship is generated, and each mapping relationship is assigned a unique configuration ID.

[0057] (4) Data integrity check

[0058] CRC32 check algorithm is used to ensure the integrity and security of the configuration file.

[0059] Check generation: Crc32_Data() calculates the CRC32 value of the configuration data (polynomial 0xEDB88320); Runtime verification: call Crc32_Check() after loading the configuration, compare the CRC32 stored in the file with the real-time calculation value, and refuse to load if it fails.

[0060] Among them, the bit compression encoding method of the device residence index (Index) includes:

[0061] The device position identification (left device 01 / right device 02) and the device number (01-06) are compressed into a single 32-bit integer;

[0062] Position decoding is achieved through bit operation: Position = ((Position >> 8) & 0xFF) - 1) * 6 + (Position & 0xFF);

[0063] Set the boundary detection mechanism, when Position<0 or Position>12 is judged as invalid position.

[0064] Port configuration (PortConfig) includes:

[0065] Sampling receiving port (RxSampling) and queue receiving port (RxQueue): configuration parameters at least include port ID (Port_ID), data length (Port_SIZE), refresh period (Port_Refresh);

[0066] Queue receiving port (RxQueue) additionally contains queue length (Port_QueueLength);

[0067] Sampling sending port (TxSampling) and queue sending port (TxQueue) parameters are consistent with the receiving end.

[0068] The Relationship structure in the mapping configuration (MappingConfig) includes the following fields:

[0069] Receiving end message ID (Rx_MsgID), receiving end message class identification (Rx_MsgClass), receiving end index (Rx_MsgIndex);

[0070] Sending end message ID (Tx_MsgID), sending end message class identification (Tx_MsgClass), sending end index (Tx_MsgIndex);

[0071] Message class identification (Rx_MsgClass / Tx_MsgClass) is associated with protocol type, including A429, A664, A825, analog (Analog) and discrete (Discrete).

[0072] Message protocol configuration is implemented by independent structure body:

[0073] For A664 sending message, A664MsgTxStructure structure body is adopted, including message ID (Msg_ID), data length (Msg_Length), FSB byte offset (Msg_FSB_ByteOffset), data block byte offset (Msg_ByteOffset), bit offset (Msg_BitOffset), bit length (Msg_BitSize), data type (Msg_Types) and associated port ID (Port_ID).

[0074] In the dynamic mapping process, the matching method of port and message includes:

[0075] According to the receiving end message ID (Rx_MsgID), the receiving port configuration index is inquired;

[0076] According to the sending end message ID (Tx_MsgID), the sending port configuration index is inquired;

[0077] For the matched receiving and sending port pair, a unique configuration ID is allocated, and a bidirectional mapping channel is established.

[0078] As shown in Figure 2 , it is one preferred embodiment 1 of the present embodiment, taking AFDX protocol as an example, to realize avionics application configuration based on binary configuration file.

[0079] Avionics Full-Duplex Switched Ethernet (AFDX) protocol specifies the data communication between airborne member systems. In this architecture, the airborne member systems supporting ARINC664 communicate directly through the AFDX network. For the airborne member systems without ARINC664 bus, the protocol conversion is completed by means of a remote data interface unit, and then the airborne member systems are connected to the AFDX network. In order to ensure accurate and reliable data interaction between the airborne member systems, the Interface Control Document (ICD) defines the communication configuration data required for data transmission in detail. The configuration items of the ICD are divided into port configuration, message configuration and mapping relationship configuration. Among them, the port configuration specifies the port name, port direction, refresh frequency and other information used by the airborne member system when communicating. The message configuration specifies the data content, format and transmission protocol and other information when the airborne member system communicates. The mapping relationship specifies the conversion rules between different protocols or data formats, such as data byte segment offset, byte segment length, mapping input and output items and other information.

[0080] According to the output item content preset by the ICD, the necessary configuration parameters of the port configuration data, the message configuration data and the mapping relationship configuration data are intelligently screened, and the necessary configuration parameters are saved to a structure. By modifying the preset content of the ICD, the configuration data can be dynamically reconstructed in this embodiment, and the dynamic processing and configurable functions of the configuration data are realized. In order to ensure the integrity and tamper-proofing of the configuration data when reading and loading, the method generates a unique CRC check code according to the necessary configuration parameters. In order to optimize the data storage efficiency and access performance, the necessary configuration data structure and the CRC check code are saved to a binary (BIN) file. When reading the configuration data, there is no need to frequently perform complex data matching operations in multiple configuration files, and only the configuration BIN file needs to be read. After reading the configuration BIN file, the corresponding CRC check code is calculated according to the configuration data, and the original CRC check code saved in the BIN file is compared. If the two are consistent, it indicates that the configuration data remains complete and has not been tampered with.

[0081] The embodiment provides a configuration BIN file parsing function, which extracts the necessary configuration data of the port configuration, the message configuration and the mapping relationship configuration data by parsing the data structure of the configuration BIN file, and exports the parsing result as an ICD file, thereby realizing reverse conversion of the configuration data and providing an effective traceability method for configuration management of the airborne member system of the avionics.

[0082] The embodiment adopts a message-driven and dynamic loading mechanism, and the core workflow is as follows:

[0083] Configuration building (can be done offline): Based on the Interface Control Document (ICD), the necessary configuration parameters for ports, messages and mapping relationships are intelligently filtered out, and a structured binary configuration file is generated. The core of this file is to solidify the driving rules of "message type-port type-mapping relationship".

[0084] Configuration loading (runtime initialization): After the avionics system starts up, it parses the binary configuration file and loads it into the global structure in memory through instructions such as read_from_file(). This process lays the foundation for dynamic loading, and the system obtains the latest configuration information without restarting.

[0085] Message-driven processing:

[0086] Event triggering: When the system needs to process a piece of data (e.g., an A664 network message or a discrete input), the data and its protocol type (i.e., "message") are used as an input event.

[0087] Driver mapping: The system queries the dynamically loaded mapping configuration, driven by the message type, to find its preset port type (such as the queue port corresponding to message A664) and the specific mapping relationship.

[0088] Dynamic routing: Based on the mapping results, the system dynamically routes data to the correct target port, completing cross-protocol and cross-device data exchange.

[0089] Dynamic updates: When the configuration needs to be changed, simply repeat the configuration building steps to generate a new BIN file. The system can then re-execute the configuration loading in the next running cycle or through specific instructions to achieve dynamic updates of the configuration without interrupting system operation.

[0090] During the configuration build phase, the following method is used to generate the binary configuration file:

[0091] Fill the header with the compatibility code (device_PAA_XML), part number, creation time, etc. (BINHeader).

[0092] Set the device index, encode the device position (such as left / right identifier + device bit) and offset (device index).

[0093] Write port configuration, storing four types of port parameters according to the PortConfig structure;

[0094] Write mapping configuration: Store message types and mapping relationships according to the MappingConfig structure;

[0095] Calculate CRC32: Calculate the CRC32 value for all data except the check bit and write it to the end of the file;

[0096] Generate a file that writes the complete structure (TConfig) into a bin file.

[0097] Step 1: Design all configuration data structures in the configuration file.

[0098] The E0icd table, as the core data structure for storage and mapping, defines the system's data storage format, port type, message type, and input / output mapping rules to support efficient data processing and management. In practical applications, the system generates a binary configuration file based on the E0icd table to achieve unified data storage and parsing in different environments.

[0099] Based on the EoICD table, the required configuration information is loaded. Configuration information, data port settings, and data mapping relationships for each module are extracted. The parsed data is then mapped to data structures within the program. Specifically, the loaded configuration information includes, but is not limited to, the module type, functional description, input / output port details, data format, and interaction protocols with other modules. This data is stored in a structure called TConfig to ensure data organization and accessibility. The TConfig structure contains multiple fields covering all necessary information obtained from external configuration sources, providing a foundation for subsequent configuration processing.

[0100] struct TConfig

[0101] {

[0102] struct BINHeader binheader; / * Binary configuration file header * /

[0103] struct Index cpmindex; / * Index of the location of the resident device * /

[0104] struct ConfigData configdata; / * Public port parameter configuration * /

[0105] unsigned int CRC32; / * The CRC32 value of the binary file * /

[0106] };

[0107] / *-----------------------------------------------------------------------* /

[0108] / * Public port parameter configuration * /

[0109] void configdata()

[0110] {

[0111] portconfig(); / * Input / output port configuration information * /

[0112] mappingconfig(); / * Input / output port mapping configuration parameters * /

[0113] }

[0114] Step 2: Fill in the configuration file header information

[0115] The header information of the configuration file is stored in a structure named BINHeader, which is responsible for storing the basic information of the configuration file. This structure includes the following fields:

[0116] Version number (VersionNum): Indicates the version of the configuration file, facilitating tracking and management.

[0117] Creation Time: Records the creation time of the configuration file, helping users identify the validity of the file.

[0118] Compatibility information (Config_Compati_Code): Specifies the compatibility of the configuration file with other versions or systems, ensuring that it can be used normally in different environments.

[0119] Partnum: A unique part number that identifies this configuration file for document management and tracking. Based on specific configuration requirements, the system will extract and populate the above fields from the loaded configuration information to ensure the integrity of the BINHeader structure.

[0120] Step 3: Set up the device resident index

[0121] Avionics systems require precise physical location of equipment, such as the left / right side of the equipment module and the equipment location number on each side. Traditional methods rely on multi-dimensional coordinates or conditional branches (such as switch-case), resulting in high storage overhead and slow positioning speed. This paper proposes a bit-compression encoding / decoding method to compress location information (left / right device, equipment number) into a single 32-bit integer. This preserves fields for future expansion, allows for primary / backup module differentiation via the equipment type field, and implements boundary detection (errors are reported for values ​​less than or greater than 12 bits), successfully supporting precise positioning of equipment modules. See [link to equipment dwell location encoding rules] for details. Figure 3 As shown. The location identifiers are: 01 for the left device, 02 for the right device. Device bits are defined as follows: e.g., 01-06 correspond to bits 1-6 in the left device / bits in the right device. The device location index has the following specific fields.

[0122] if (ret == 0)

[0123] {

[0124] Position = ((Position >> 8) & 0xFF) - 1) * 6 + (index.Position &0xFF);

[0125] }

[0126] if (Position<0 || Position>12)

[0127] {

[0128] ret = -1;

[0129] }

[0130] It is 3 times faster than the traditional switch-case (average measured speed is 0.2μs).

[0131] Step 4: Core Data Configuration

[0132] Figure 4 It shows the relationship between the various configuration modules, and displays the architecture of the two core configuration modules: PortConfig (input / output port configuration information data) and MappingConfig (all input / output port mapping configuration data).

[0133] The PortConfig structure details the type of each port (such as sampling port, queue port). The MappingConfig structure defines the mapping rules between ports (Relationship configuration information for sending and receiving data) to ensure correct data flow between modules. These configurations include port ID information, message attributes, data format, and message protocol, ensuring the system can correctly exchange and process data during runtime.

[0134] The core data configuration supports multi-protocol data configuration. Specifically, the received messages support a429msgrx, a664msgrx, a825msgrx, analogmsgrx (simulation), and discretemsgrx (discrete), while the sent messages support a664msgtx and discretemsgtx.

[0135] Step 4.1: Fill in the port configuration

[0136] Configure the receive sampling and queue port, and the send sampling and queue port. The port parameters include: unique port identifier (Port_ID), port name (Port_Name, such as A429_Rx_Port1), data length (bytes (Port_SIZE)), refresh period (milliseconds) (Port_Refresh), number of configurations, and data block size.

[0137] The specific fields for the four types of ports defined in the structure are as follows:

[0138] struct PortConfig {

[0139] struct RxSampling rxsampling; / / Sampling receiver port

[0140] struct RxQueue rxqueue; / / Queue receive port

[0141] struct TxSampling txsampling; / / Sampling and transmission port

[0142] struct TxQueue txqueue; / / Queue sending port

[0143] };

[0144] Step 4.2: Populate the configuration mapping (MappingConfig)

[0145] The MappingConfig structure defines the configuration information for sending and receiving messages of multiple protocol types, as well as the mapping rules between ports, ensuring that data can flow correctly between modules. The Relationship (data transmission and reception mapping configuration information) of the MappingConfig structure stores the port configuration and the mapping relationship between ports and message IDs. The relationship between ports and protocols is further configured through message IDs to ensure the exchange and processing of multi-protocol message data.

[0146] The mapping rules (Relationship structure) automatically establish the data transmission and reception mapping relationship between ports. The key fields of the mapping rule structure are shown below:

[0147] struct Relationship: Configuration information for sending and receiving data mapping.

[0148] {

[0149] unsigned int Rx_MsgID;

[0150] char Rx_MsgClass;

[0151] unsigned int Rx_MsgIndex;

[0152] unsigned int Tx_MsgID;

[0153] char Tx_MsgClass;

[0154] unsigned int Tx_MsgIndex;

[0155] };

[0156] Among the key fields, Rx_MsgID is the unique ID of the receiving port parameter, corresponding to the Msg_ID in the receiving parameter configuration information; Rx_MsgClass is the ID of the receiving port parameter, corresponding to the port structure category; Rx_MsgIndex is the ID of the receiving port parameter, corresponding to the subscript index in the port structure category; Tx_MsgID is the unique ID of the sending port parameter, corresponding to the Msg_ID in the sending parameter configuration information; Tx_MsgClass is the ID of the sending port parameter, corresponding to the port structure category; Tx_MsgIndex is the ID of the sending port parameter, corresponding to the subscript index in the port structure category.

[0157] Taking the storage of detailed information on the A664 sending port parameter configuration as an example, the following demonstrates how to populate key fields in the message configuration:

[0158] struct A664MsgTxStructure

[0159] {

[0160] unsigned int Msg_ID;

[0161] unsigned int Msg_Length;

[0162] unsigned int Msg_FSB_ByteOffset;

[0163] unsigned int Msg_ByteOffset;

[0164] unsigned int Msg_BitOffset;

[0165] unsigned int Msg_BitSize;

[0166] char Msg_Types[TYPES_NAME_MAX];

[0167] char Msg_SDI;

[0168] char Msg_SSM;

[0169] unsigned int Port_ID;

[0170] char Port_Class;

[0171] char Port_IDIndex;

[0172] };

[0173] Where Msg_ID is the unique parameter ID number, Msg_Length is the parameter truncation length, Msg_FSB_ByteOffset is the byte offset of the FSB parameter in the message, Msg_ByteOffset is the byte offset of the data block parameter in the port message, Msg_BitOffset is the bit offset of the data block parameter, Msg_BitSize is the number of data bits in the data block parameter, Msg_Types is the data block type, Port_ID is A664Port, which is the configuration ID in the port structure corresponding to the configuration ID number, Port_Class is A664Port, which is the port structure category corresponding to the configuration ID number (1--RxSampling; 2--RxQueue; 3--TxSampling; 4--TxQueue), and Port_IDIndex is A664Port, which is the index in the port structure category corresponding to the configuration ID number.

[0174] Step 4.3: Configure mapping relationship lookup

[0175] A one-to-one mapping relationship is generated based on the message ID of the receiving port and the message ID of the sending port, and a unique configuration ID is assigned to each pair of mapping relationships.

[0176] The functions `Find_Port_IDIndex` (finds the index of the port number `Port_ID`) and `Find_Msg_IDIndex` (finds the index of the message number `Msg_ID`) are used to quickly find and locate relevant configurations based on the port ID and message ID, respectively. A diagram illustrating the data port and message protocol input / output mapping configuration, the relationship between structures and functions, and the call flow is shown below. Figure 5 As shown.

[0177] Specifically, the message mapping relationship between each port is configured based on the input Rx_MsgID (receiver message ID) and Tx_MsgID (sender message ID). Each protocol type structure, such as the A664 protocol configuration structure a664msgrx, contains a list of messages. The system searches for the configuration that matches the message type based on the port ID (such as the sender port ID or receiver port ID). The message ID corresponds to a specific port ID, thus locating the index position of the message configuration. Specifically, the Find_Msg_IDIndex() function is used to find the configuration index of the message ID, ensuring correct matching of message transmission between ports.

[0178] Step 4. CRC Check Generation and Data Integrity

[0179] During the configuration file generation process, the entire file undergoes a CRC32 checksum verification, generating a checksum value which is stored in the file to ensure its integrity. CRC32 verification effectively identifies whether data has been tampered with during storage or transmission. By comparing the stored checksum with the recalculated value, the integrity of the file content can be verified, ensuring the consistency and reliability of the configuration file during use.

[0180] 1. Initialization parameters: Set the initial value (0xFFFFFFFF) and polynomial (0xEDB88320) required by the CRC32 algorithm.

[0181] 2. Extract file content: Extract data from the configuration file, excluding existing CRC32 check fields.

[0182] 3. Calculate CRC32 checksum: Calculate the CRC32 checksum of the file content byte by byte.

[0183] 4. Store CRC32 checksum: Write the calculated CRC32 checksum to the configuration file.

[0184] 5. File integrity verification: Verify file integrity by comparing the recalculated CRC32 checksum with the stored value in the file.

[0185] If the completed configuration structure is validated, the generated checksum is ox1951346B.

[0186] Step 5: Save the binary configuration file:

[0187] Finally, the completed configuration structure is written to disk or memory via a binary file write operation, generating a binary configuration file (bin). This operation ensures the persistence of configuration data so that it can be quickly loaded upon system startup or other needs. Simultaneously, the file storage format optimizes space utilization and improves read and write efficiency, making it suitable for the requirements of real-time systems.

Claims

1. A method for configuring avionics applications based on message-driven and dynamic loading mechanisms, characterized in that, include: Construction phase: Based on the avionics system interface control file, a hierarchical binary configuration file is generated. The binary configuration file includes port configuration information, mapping configuration information, and device residency index. The port configuration information is used to define port parameters. The mapping configuration information is used to define the mapping relationship between messages and port types driven by different protocol message types. The device residency index is used to encode the physical location of the device and record the byte offset of the device's corresponding configuration data in the port configuration and mapping configuration. Operational phase: During the operation of the avionics system, the binary configuration file is parsed and loaded into the global structure. The mapping configuration information is automatically matched according to the message type of the message to be processed. After configuring the parameters of the corresponding device ports according to the port configuration information, data is read and written using the information in the device resident index, realizing message-driven and dynamic loading of application configuration.

2. The method according to claim 1, characterized in that, The physical location of the encoding device is achieved by splitting the physical location of the device into a high-order field and a low-order field. The high-order field is used to represent the left or right device, and the low-order field is used to represent the device number, thereby compressing the encoding length.

3. The method according to claim 2, characterized in that, The types of device ports include sampling receiving port, queue receiving port, sampling sending port, and queue sending port.

4. The method according to claim 3, characterized in that, The definition defines the mapping relationship between messages and device ports, driven by message types of different protocols, including: Based on the message type, find its corresponding preset device port type in the mapping configuration information; Based on the search results, match the corresponding sending device port and receiving device port for the message type, and establish a bidirectional mapping channel; Set a unique ID for the matching result to identify the mapping relationship between the message type and the device port.

5. The method according to claim 4, characterized in that, The step of searching for the corresponding preset device port type in the mapping configuration information based on the message type includes: The sampling and receiving ports corresponding to the a429msgrx message, analogmsgrx message, and discretemsgrx message; The corresponding queue receiving ports for a664msgrx and a825msgrx messages; The discretemsgtx message corresponds to the sampling and sending port; The a664msgtx message corresponds to the queue sending port.

6. The method according to claim 1, characterized in that, The hierarchical binary configuration file also includes: The header information is used to store the file identifier, version number, creation timestamp, compatibility information, and part number.

7. The method according to claim 1, characterized in that, The system interface control file generates a binary configuration file containing port configuration information and mapping configuration information, including: The system interface control file is obtained, from which configuration information, data port settings, and data mapping relationships are extracted. After being converted into port configuration information and mapping configuration information, they are written into the corresponding level in the binary configuration file.

8. The method according to claim 1, characterized in that, Also includes: During the construction phase, a CRC checksum is generated based on the generated configuration data and stored in the binary configuration file; During the operation phase, the CRC checksum is recalculated based on the read configuration data and compared with the checksum stored in the file to ensure that the complete configuration data is loaded correctly.

9. The method according to claim 1, characterized in that, Also includes: Parse the binary configuration file to extract configuration data for port configuration, message configuration, and mapping relationship configuration; The extracted configuration data is exported as an interface control file to achieve reverse conversion and traceability management of the configuration data.

10. The method according to claim 1, characterized in that, The system interface control file is the EoICD table.

Images