A method and device for converting avionics multi-protocols based on DDS, and a readable storage medium
By adopting a DDS-based avionics multi-protocol conversion method, combined with XML schema and data distribution services, the problems of universality and reusability in heterogeneous system interconnection are solved, achieving efficient data interaction and flexible system expansion, which is suitable for military combat training in the context of LVC.
Patent Information
- Application Number
- CN202310947348.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-07-29
- Publication Date
- 2026-08-25
- Estimated Expiration
- 2043-07-29
AI Technical Summary
Existing technologies for interconnecting heterogeneous systems suffer from high costs, low reusability, and poor versatility, making it difficult to meet the real-time and scalability requirements of military combat training in the context of LVC.
By adopting a DDS-based avionics multi-protocol conversion method, combined with XML-based metadata mapping and data distribution services, and through an efficient subscription organization mode with fuzzy matching and full segmentation coverage, efficient data interaction between heterogeneous systems is achieved.
It improves the versatility and reusability between heterogeneous systems, ensures the efficiency and flexibility of data interaction, and adapts to the data interaction needs of simulation members.
Smart Images

Figure CN117033291B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of airborne communication technology and relates to a method, device, and readable storage medium for avionics multi-protocol conversion based on DDS (Data Distribution Service). It is an avionics multi-protocol conversion method based on Data Distribution Service (DDS) and XML intermediate language. It mainly completes the acquisition of data from the airborne bus (ARINC429, 1553B, AFDX, RS422, and fiber optic bus), and realizes the automatic conversion of the above five protocol data to DDS protocol standard data. It can be used for military combat training in an LVC (Low Voltage Control) context. Background Technology
[0002] In recent years, with the transformation of global military capabilities and the updating of operational concepts, countries have increasingly emphasized operational experimentation as a means of verifying weapon platforms and operational concepts. By combining heterogeneous domain systems, conducting training experiments, and performing system simulation training, a unified and relatively realistic simulation environment is provided for military personnel. Real-Virtual-Constructed (LVC) training combines live-fire systems and simulated systems from different regions. However, heterogeneous domains and systems cannot directly interact, thus requiring solutions to several problems: first, data interoperability between heterogeneous systems; second, real-time system interaction; and third, good scalability and flexibility. Therefore, research on avionics multi-protocol conversion methods is of great significance.
[0003] The existing methods for interconnecting different systems mainly include gateway technology, middleware technology, and web technology. The basic idea of gateway technology is that different agents within the gateway join different systems. As a member of the system, the agent can interact with other applications within the system, and agents can exchange information with each other through converters.
[0004] The basic idea of middleware technology is that middleware is a software layer located between the application and the operating system. It isolates the application from the details of the underlying computer architecture and operating system. The application is developed directly on the basis of the middleware without using the underlying programming structure, thus simplifying the application development.
[0005] The basic idea of web technology is to separate services from their implementation, hiding the details of service implementation. This makes it possible to separate the use of services from their implementation, making the process of using services independent and not dependent on the hardware and software platform or programming language on which the service is implemented. Kumari N et al., in their paper "Expermetal validation of CAN to Bluetooth gateway for invehicle wireless networks [C]. Proc of 2013 international conference on emerging trends in communication; control; signal processing computing applications; 2013:1-5," proposed the design of multi-protocol conversion hardware devices and network device drivers.
[0006] In the process of interconnecting different systems, some of the above methods focus on hardware design, but hardware design has its own disadvantages, namely high cost and low reusability. Others only consider the conversion between the two protocols and cannot achieve high universality. Summary of the Invention
[0007] Technical problems to be solved
[0008] To overcome the shortcomings of existing technologies, this invention proposes a DDS-based avionics multi-protocol conversion method, device, and readable storage medium. By employing an XML-based metadata mapping method and the DDS data distribution service to enable communication between different bus devices, it exhibits higher versatility and reusability than existing methods and also possesses excellent interactivity. Furthermore, during data distribution, to improve the efficiency of data interaction among simulation members, fuzzy theory is introduced and a segmented, fully covered, efficient subscription organization mode is adopted, in conjunction with the content logic coverage of subscribers.
[0009] Technical solution
[0010] A DDS-based avionics multi-protocol conversion method, characterized by the following steps:
[0011] Step 1: Perform multi-protocol heterogeneous data acquisition: Use a thread pool to acquire protocol data from the ARINC429, 1553B, AFDX, RS422, and fiber optic bus on the airborne bus, and use topic subscription and publishing to effectively transfer and interact data between heterogeneous systems.
[0012] Step 2: Extraction of heterogeneous implementation data from the general system:
[0013] Before extracting data, a trigger template needs to be established: First, an intermediate database table is created to store the target data to be output after transformation and processing. A primary key is designed for the intermediate table to uniquely identify each piece of data. Next, a database exchange table is created to temporarily store the data extracted from the original data table that needs to be transformed. A foreign key is defined in the exchange table pointing to the intermediate table. When the data in the exchange table changes, a trigger is activated, and the data from the exchange table is inserted into the intermediate table. Finally, according to the XML Schema structure file, the data in the intermediate table is transformed and stored in an XML document. The above data processing flow mainly completes the transformation between the database file storing the original data and the XML document in step one.
[0014] Step 3, Mapping between the general protocol and DDS: Using DOM technology, the sending end Schema file, the receiving end Schema file, and the mapping rule document are parsed, and the final output is a file containing the mapping relationship between the sending end and the receiving end;
[0015] Step 4: Generate DDS-based target numerical file: Based on the mapping file generated in Step 3, parse the sending data file using SAX technology and use DOM to parse the mapping file, converting the sending data file into the target data file required by the receiving end;
[0016] Step 5: Distribute information based on the mapping file using fuzzy matching: Based on the target data file generated in Step 4 that the receiver needs, use a fuzzy matching algorithm to approximate the matching of the data file; distribute the matched data to the corresponding receiver according to the fuzzy matching results.
[0017] When there is data transmission in the system, repeat step 5 to distribute it and complete the conversion of heterogeneous live-fire equipment data to the simulation system.
[0018] The thread pool approach is as follows: a corresponding thread is started according to the communication protocol of the added device system; the interface methods of ThreadPool are called, and data reception and transmission of the specific protocol are implemented inside the thread, and the collected data is temporarily stored in a data table; when the system starts, corresponding threads are started for each connected device system to complete initialization and data transmission and reception functions; for each avionics system, a corresponding thread is started at startup, and the system subscribes to the topics of the data it needs; when new data is published to a topic, subscribers to that topic will receive the subscribed data, and different systems only receive the information they need.
[0019] The general system refers to an intermediate layer system that connects various heterogeneous device systems and subsequent simulation training systems. It serves to access and convert data formats.
[0020] Step 2 specifically involves:
[0021] The design uses an XML schema structure file to define the format of the data. Then, by parsing the schema file, the data from the original data tables in the database is extracted and saved into an XML document in the data format specified in the structure file. Finally, the receiving end needs the same schema structure file to extract data in the same format from the XML document and save it to the local database.
[0022] Design a ParseXSD class to complete the conversion between structures, and design an XSDNode class to store the name, path and attributes of each node; multiple XSDNodes are stored in a List; use SAX to parse the Schema structure file to generate a list of XSDNode objects, and finally the ParseXSD class uses this list of objects to perform bidirectional conversion;
[0023] The XSD node information of the sending end is read, and then the FileInputStream interface function in the XML language is used to read the actual data file that the sending end is preparing to send. After verifying that it is correct, the DataLoader is used to read the converted data to ensure that the structure file of the receiving end matches the structure file of the sending end. After the reception is completed, the converted data is stored in the local database table, thus completing the conversion between the XML file and the original data table content in the database.
[0024] Step 3 specifically involves: traversing and parsing each element in the receiving end's schema file; when an unmarked element is found, recording its fields and attributes; querying the mapping rules in the mapping rule file, determining that it is a sending end element, and processing and transforming it according to the mapping rules; processing all elements in the receiving end's schema file in sequence, and finally outputting a file containing the mapping relationship between the sending end and the receiving end.
[0025] Step 4: First, an output stream is established based on the mapping file. Then, the sending data file is parsed to read the element names and values. Next, according to the mapping relationship, the elements and values are written into the output stream to generate the receiving data file, i.e., the target numerical file, thus completing the data format conversion work according to the mapping rules.
[0026] A computer device includes a memory and a processor, wherein the memory stores a computer program that can run on the processor, characterized in that the processor executes the computer program to implement the steps of the above-described method.
[0027] A computer-readable storage medium having a computer program stored thereon, characterized in that the computer program, when executed by a processor, implements the steps of the above-described method.
[0028] Beneficial effects
[0029] This invention proposes a DDS-based avionics multi-protocol conversion method, device, and readable storage medium. It introduces mapping processing rules and integrates them with the DDS data distribution service, achieving efficient information subscription through fuzzy matching. It also improves idle thread management in multi-threaded multi-protocol implementation data acquisition. Because this invention uses an XML-based metadata mapping method and the DDS data distribution service to achieve communication between different bus devices, it exhibits higher versatility and reusability than existing methods, and also possesses excellent interactivity. Furthermore, to improve the efficiency of data interaction among simulation members during data distribution, fuzzy theory is introduced, and a segmented, fully covered, efficient subscription organization mode is adopted, combined with the content logic coverage of subscribed users. Attached Figure Description
[0030] Figure 1 Distribution Model
[0031] Figure 2 Data processing
[0032] Figure 3 Data sent by the ARINC429 installed equipment
[0033] Figure 4 Data sent by the 1553B installed equipment
[0034] Figure 5 Data received by the training system in the example Detailed Implementation
[0035] The present invention will now be further described in conjunction with the embodiments and accompanying drawings:
[0036] This embodiment relates to a computer device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, characterized in that the processor executes the computer program to implement the steps of the above-described method.
[0037] A computer-readable storage medium having a computer program stored thereon, characterized in that the computer program, when executed by a processor, implements the steps of the above-described method.
[0038] The computer's central processing unit is an 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz CPU, an NVIDIA GeForce RTX 4060Ti Laptop GPU, and a Windows 11 operating system.
[0039] This technical solution requires data collection from different equipment systems, each using its own communication protocols, such as the common avionics communication protocols ARICN429 and 1553B. To achieve data collection from each system, we adopted a thread pool approach.
[0040] A thread pool class, ThreadPool, is used to manage all threads. This class provides interface methods for creating and destroying threads, while internally implementing the specific management of the threads. This ensures the safety of thread management.
[0041] When each device system joins the simulation training system, we start a corresponding thread based on its communication protocol. This involves calling the ThreadPool interface methods and implementing data reception and transmission within the thread, specific to the protocol. This allows for data acquisition from heterogeneous device systems through calls to a unified interface from various threads. The acquired data is then stored in a raw data table within the database.
[0042] When the system starts, it will start corresponding threads for each connected device system to complete initialization and data transmission and reception functions.
[0043] For each avionics system, we start a corresponding thread upon startup and enable the system to subscribe to the topics of the data it needs.
[0044] When new data is published to a topic, subscribers to that topic will receive that data. This allows different systems to receive only the information they need.
[0045] This topic subscription and publishing method enables the efficient transfer and interaction of data between heterogeneous systems.
[0046] Step 2: Extract heterogeneous implementation data from the general system.
[0047] A general-purpose system refers to an intermediate layer system that connects various heterogeneous device systems and subsequent simulation training systems. It serves to access and convert data formats.
[0048] (2a) Before extracting data, a trigger template needs to be created. The creation process is as follows:
[0049] First, an intermediate database table is created to store the final output data after transformation and processing. A primary key is designed for the intermediate table to uniquely identify each piece of data. Next, a database exchange table is created to temporarily store the data extracted from the original data table that needs transformation. A foreign key is defined in the exchange table pointing to the intermediate table. When the data in the exchange table changes, a trigger is established, and the data from the exchange table is inserted into the intermediate table. Finally, according to the XML Schema structure file, the data in the intermediate table is transformed and stored in an XML document. The above data processing flow mainly completes the transformation between the database file storing the original data and the XML document in step one. The specific steps are as follows:
[0050] (2a1) First, design an XML schema file to define the data format. Then, by parsing the schema file, extract the data from the original data tables in the database and save it into an XML document in the format specified in the schema file. Finally, the receiving end requires the same schema file to extract data of the same format from the XML document and save it to the local database.
[0051] (2a2) To increase scalability, a ParseXSD class is designed to handle the conversion between structures. The designed XSDNode class stores the name, path, and attributes of each node. Multiple XSDNodes are stored using a List. The SAX parsing method is used to parse the Schema structure file, generating a list of XSDNode objects. Finally, the ParseXSD class uses this list of objects for bidirectional conversion.
[0052] (2a3) To ensure accurate numerical reception, the structure files of the receiving end and the sending end must be consistent. Therefore, structure file verification is required. First, the XSD node information of the sending end is read. Then, the FileInputStream interface function in XML is used to read the actual data file that the sending end is preparing to send for verification. After confirming that it is correct, DataLoader is used to read the converted data. The reason for this is to ensure that the structure files of the receiving end and the sending end match. Therefore, after the reception is completed, the converted data is stored in the local database table. This completes the conversion between the XML file and the original data table content in the database.
[0053] Step 3, Mapping between the general protocol and DDS
[0054] Using DOM technology, a pre-designed sender schema file, receiver schema file, and mapping rule document are used for parsing. Only the structure is processed; specific data design is not involved. Each element in the receiver schema file is traversed and parsed. When an untagged element is found, its fields and attributes are recorded. The mapping rule document is queried to determine if a corresponding sender element exists. If found, it is processed and transformed according to the mapping rule. All elements in the receiver schema file are processed sequentially.
[0055] The final output is a file containing the mapping relationship between the sender and receiver.
[0056] Step 4: Generate target numerical files based on DDS
[0057] Based on the mapping file generated in step 3, the data file of the sending end is converted into the file required by the receiving end.
[0058] The sending data file is parsed using SAX technology, still employing DOM parsing of the mapping file. First, an output stream is established based on the mapping file. Then, the sending data file is parsed, reading element names and values. Next, according to the mapping relationship, the elements and values are written to the output stream to generate the receiving data file, i.e., the target numerical file. This completes the data format conversion based on the mapping rules. Different programs can also be designed as needed to process the data for easier use by the receiving end.
[0059] Step 5: Distribute information using fuzzy matching based on the mapping file.
[0060] In step 4, the target data file required by the receiving end has been generated according to the mapping rules. Based on this, a fuzzy matching algorithm can be used to process the data file. Fuzzy matching can tolerate a certain degree of data difference, performing approximate matching. Based on the fuzzy matching results, information distribution within the system can be implemented. The matched data is distributed and sent to the corresponding receivers. This improves the flexibility and fault tolerance of information distribution. The distribution model is as follows: Figure 1 :
[0061] Step 6: Complete the conversion of heterogeneous live-fire equipment data to the simulation system and test it.
[0062] Repeat step 5; when there is data transmission in the system, distribute it. The entire data processing flow is as follows: Figure 2 .
[0063] According to the specific embodiments of the present invention, a comparison with existing methods is made, and the results are as follows: Figures 3-5 As shown.
[0064] Figure 3 Data sent by ARINC429 installed equipment
[0065] Figure 4 Data sent by the 1553B installed equipment
[0066] Figure 5 Data received by the training system in the example
[0067] This invention employs an XML-based metadata mapping method and a Data Distribution Service (DDS) for communication between different bus devices, resulting in higher versatility and reusability compared to existing methods, as well as superior interactivity. Furthermore, this invention utilizes fuzzy matching for data distribution verification, which adapts to changes in the scale of subscribed data, thereby improving feasibility and efficiency.
Claims
1. A DDS-based avionics multi-protocol conversion method, characterized in that... The steps are as follows: Step 1: Perform multi-protocol heterogeneous data acquisition: Use a thread pool to acquire protocol data from the ARINC429, 1553B, AFDX, RS422, and fiber optic bus on the airborne bus, and use topic subscription and publishing to effectively transfer and interact data between heterogeneous systems. Step 2: Extraction of heterogeneous implementation data from the general system: Before extracting data, a trigger template needs to be established: First, an intermediate database table is created to store the target data to be output after transformation and processing. A primary key is designed for the intermediate table to uniquely identify each piece of data. Second, a database exchange table is created to temporarily store the data to be transformed extracted from the original data table. A foreign key is defined in the exchange table pointing to the intermediate table. When the data in the exchange table changes, a trigger is activated, and the data in the exchange table is inserted into the intermediate table. Finally, according to the XML Schema structure file, the data in the intermediate table is transformed and stored in an XML document. The above data processing flow mainly completes the transformation between the database file storing the original data and the XML document in step one. Step 3, Mapping between the general protocol and DDS: Using DOM technology, the sending end Schema file, the receiving end Schema file, and the mapping rule document are parsed, and the final output is a file containing the mapping relationship between the sending end and the receiving end; Step 4: Generate DDS-based target numerical file: Based on the mapping file generated in Step 3, parse the sending data file using SAX technology and use DOM to parse the mapping file, converting the sending data file into the target data file required by the receiving end; Step 5: Distribute information based on the mapping file using fuzzy matching: Based on the target data file generated in Step 4 that the receiver needs, use a fuzzy matching algorithm to approximate the matching of the data file; distribute the matched data to the corresponding receiver according to the fuzzy matching results. When there is data transmission in the system, repeat step 5 to distribute it and complete the conversion of heterogeneous live-fire equipment data to the simulation system.
2. The avionics multi-protocol conversion method based on DDS according to claim 1, characterized in that: The thread pool approach is as follows: a corresponding thread is started according to the communication protocol of the added device system; the interface methods of ThreadPool are called, and data reception and transmission of the specific protocol are implemented inside the thread, and the collected data is temporarily stored in a data table; when the system starts, corresponding threads are started for each connected device system to complete initialization and data transmission and reception functions; for each avionics system, a corresponding thread is started at startup, and the system subscribes to the topics of the data it needs; when new data is published to a topic, subscribers to that topic will receive the subscribed data, and different systems only receive the information they need.
3. The avionics multi-protocol conversion method based on DDS according to claim 1, characterized in that: The general system refers to an intermediate layer system that connects various heterogeneous device systems and subsequent simulation training systems, and it plays the role of accessing and converting data formats.
4. The avionics multi-protocol conversion method based on DDS according to claim 1, characterized in that: Step 2 specifically involves: The design uses an XML schema structure file to define the format of the data. Then, by parsing the schema file, the data from the original data tables in the database is extracted and saved into an XML document in the data format specified in the structure file. Finally, the receiving end needs the same schema structure file to extract data in the same format from the XML document and save it to the local database. Design a ParseXSD class to complete the conversion between structures, and design an XSDNode class to store the name, path and attributes of each node; multiple XSDNodes are stored in a List; use SAX to parse the Schema structure file to generate a list of XSDNode objects, and finally the ParseXSD class uses this list of objects to perform bidirectional conversion; The XSD node information of the sending end is read, and then the FileInputStream interface function in the XML language is used to read the actual data file that the sending end is preparing to send. After verifying that it is correct, the DataLoader is used to read the converted data to ensure that the structure file of the receiving end matches the structure file of the sending end. After the reception is completed, the converted data is stored in the local database table, thus completing the conversion between the XML file and the original data table content in the database.
5. The avionics multi-protocol conversion method based on DDS according to claim 1, characterized in that: Step 3 specifically involves: traversing and parsing each element in the receiving end's schema file; when an unmarked element is found, recording its fields and attributes; querying the mapping rules in the mapping rule file, determining that it is a sending end element, and processing and transforming it according to the mapping rules; processing all elements in the receiving end's schema file in sequence, and finally outputting a file containing the mapping relationship between the sending end and the receiving end.
6. The avionics multi-protocol conversion method based on DDS according to claim 1, characterized in that: Step 4: First, establish the output stream based on the mapping file, then parse the sending end data file and read the element name and element value; Then, based on the mapping relationship, the elements and values are written to the output stream to generate the receiving end data file, i.e., the target value file, thus completing the work of converting the data format according to the mapping rules.
7. A computer device, comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.
8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.