A general design method for airborne data bus monitoring and testing software framework

Abstract

The invention discloses a universal airborne data bus monitoring and testing software framework design method in the field of avionics technology. The universal airborne data bus monitoring and testing software framework design method comprises the following steps: airborne bus testing system domain analysis: by analyzing the test processes of various airborne bus systems, the common operations and universal tests of all airborne bus testing systems are obtained; airborne bus testing system domain framework design: under the guidance of universal design principles, domain engineering methods and software product line methods are adopted. The invention solves the problem of poor universality and reusability of current airborne data bus monitoring and testing systems, adopts domain engineering methods and software product line methods for universal design, and can meet the development requirements of various types of airborne data bus monitoring and testing systems.

Description

Technical Field

[0001] The invention relates to the field of avionics technology, and in particular to a general airborne data bus monitoring and testing software framework design method. Background Art

[0002] Airborne data bus technology plays a very important role in avionics systems. In avionics simulation system tests, data transmitted on the bus must be strictly tested and monitored in real time, so that researchers can locate faults, conduct statistical analysis, and systematically evaluate and verify whether the performance indicators and functions of the avionics simulation system and related avionics sub-systems meet the design requirements, providing a basis for the evaluation and improvement of design solutions.

[0003] There are many types of existing airborne data buses, which are very different in terms of electrical characteristics, topology, data transmission format, etc. At the same time, the same type of airborne data buses are often developed by different units. Although they comply with the corresponding bus communication specifications, the specific communication process is different, and each bus has a different hardware interface. This requires the design of a dedicated bus monitoring and test system for each bus, resulting in repeated development. Furthermore, in the interactive joint debugging test of the hybrid airborne bus system, it is difficult to coordinate various dedicated test systems, so that the fault cannot be accurately located. For example, the domestic patents "Mil-std-1553b Bus Monitoring and Data Analysis System" and "A Arinc429 Data Bus Simulation Test System" are both simulation test systems developed for dedicated buses, which cannot meet the simulation test requirements of various types of buses. Therefore, it is urgent to study a universal airborne data bus monitoring and testing technology to cope with the complexity of the current avionics integrated test system, improve the accuracy of aviation bus testing, improve the reliability of airborne data buses, reduce testing costs, and shorten project cycles. Summary of the invention

[0004] The purpose of the present invention is to provide a universal airborne data bus monitoring and testing software framework design method to solve the urgent need to study a universal airborne data bus monitoring and testing technology proposed in the above background technology to cope with the complexity of the current avionics integrated test system, while improving the accuracy of aviation bus testing, enhancing the reliability of the airborne data bus, reducing testing costs, and shortening project cycles.

[0005] To achieve the above object, the present invention provides the following technical solution: a general airborne data bus monitoring and testing software framework design method, the general airborne data bus monitoring and testing software framework design method comprising the following steps:

[0006] S1: Field analysis of airborne bus test systems: By analyzing the test processes of various airborne bus systems, the common operations and general tests of all airborne bus test systems are obtained;

[0007] S2: Design of domain framework of airborne bus test system: Under the guidance of universal design principles, a domain framework of airborne data bus test system that can be expanded and reused is designed by adopting domain engineering method and software product line method. This framework can be expanded and reused according to different user needs, and airborne bus monitoring and test systems of different types and purposes can be quickly built;

[0008] S3: Design of domain components of airborne bus test system: Extract various common domain components according to the common operations of airborne bus test system;

[0009] S4: Application verification of universal airborne bus monitoring and testing system: In order to verify the universality of the universal airborne bus testing system and monitoring system proposed in the present invention, a prototype software of a universal airborne data bus testing and monitoring system is built. The prototype system consists of a core part and an extended part: the core part is the universal bus interface monitoring software, data parsing software and universal testing system framework software; the extended part includes adapter interface software for various typical airborne data buses. The prototype system is used to test and monitor the ARINC429 bus, 1553B bus and AFDX bus data respectively, completing the functional verification of the prototype system.

[0010] Preferably, the common operation and general test method of the airborne bus test system in step S1 include the following steps:

[0011] A1: Data acquisition: Obtain the data required for transmission from the aircraft and flight environment simulation software;

[0012] A2: Data processing: The actuator processes the acquired data to obtain the data to be sent. This data is in the computer representation format.

[0013] A3: Data packaging: The airborne bus ICD packaging and parsing program packages the computer format data into ICD format data;

[0014] A4: Data transmission: The data in ICD format is sent to the onboard data bus. At this time, the monitoring module can also be used to monitor the data before transmission so as to compare it with the data received by the receiver and perform delay analysis.

[0015] A5: Data reception: The receiving end receives data in ICD format from the bus. At this time, the monitoring module can also be used to monitor the received data for comparison;

[0016] A6: Data unpacking: The onboard bus ICD packing and parsing program parses the bus data in ICD format into computer format data;

[0017] A7: Data display: Various data are displayed on the monitoring interface.

[0018] Preferably, the general domain components in step S3 include: a general data source component, a general buffer data area component, a general exciter component, a general data packaging / parsing component and a general data monitoring and display component.

[0019] Compared with the prior art, the beneficial effects of the present invention are as follows: the present invention solves the problem of poor universality and reusability of the current airborne data bus monitoring and testing system, adopts the domain engineering method and the software product line method for universal design, and can meet the development requirements of various types of airborne data bus monitoring and testing systems. By using the domain framework and domain components designed by the present invention, users can conveniently perform customized component assembly and system construction when writing airborne bus monitoring and testing system software. The present invention first analyzes the domain of typical airborne data buses, summarizes the characteristics of various airborne data buses in structure and transmission mechanism, extracts the common characteristics of each data bus, and then studies the testing methods of various special bus testing systems, summarizes the common components and common processes of airborne bus testing systems, and proposes a universal airborne data bus monitoring and testing method. The method mainly achieves universality from two aspects: first, The data flow in the bus test system is abstracted to achieve unified management, unified storage and automatic parsing of data of different bus types and different ICD formats, thereby realizing the generalization of test data. Secondly, the system architecture for transmitting test data is generalized, and a universal bus test system domain framework is constructed using abstract components and abstract processes. Users can expand and reuse the framework according to different needs, and quickly build airborne bus monitoring and test systems of different types and purposes. Finally, this project uses the universal framework to build prototypes of two dedicated bus test systems and one hybrid bus test system. The verification results show that the ICD unified management technology and universal airborne bus test system architecture proposed in this project have good scalability, and can complete the construction of various dedicated and hybrid bus test systems at the lowest cost. At the same time, it can also be compatible with various new buses that will be launched on the market in the future. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 It is a schematic diagram of the structure of the present invention;

[0021] Figure 2 It is a general test flow diagram of the airborne bus test system of the present invention;

[0022] Figure 3 It is a schematic diagram of general field components of the airborne bus test system of the present invention;

[0023] Figure 4 A schematic diagram of the software architecture of the universal airborne data bus test system of the present invention;

[0024] Figure 5 This is a schematic diagram of the data source subsystem of the present invention;

[0025] Figure 6 It is a schematic diagram of the data distribution subsystem of the present invention;

[0026] Figure 7 This is a schematic diagram of the unified data storage subsystem of the present invention;

[0027] Figure 8 This is a schematic diagram of the internal structure of the unified data storage subsystem of the present invention;

[0028] Fig. 9 This is a schematic diagram of data organization of the system of the present invention;

[0029] Fig.10 A schematic diagram for maintaining consistency of system data of the present invention;

[0030] Fig.11 The interface and implementation diagram provided for the index layer of the present invention;

[0031] Fig.12 It is a schematic diagram of the actuator subsystem of the present invention;

[0032] Fig.13 This is a schematic diagram of the principle of the exciter scheduling framework of the present invention;

[0033] Fig.14 This is a schematic diagram of the data analysis subsystem of the present invention;

[0034] Fig.15 A schematic diagram of the registration process of the parsing rules of the present invention;

[0035] Fig.16 This is a schematic diagram of the ICD parsing / packaging process of the present invention;

[0036] Fig.17 It is a schematic diagram of the data display subsystem of the present invention;

[0037] Fig.18 This is a schematic diagram of the prototype of the AFDX bus test system of the present invention;

[0038] Fig.19 A schematic diagram of the prototype of the ARINC429 bus test system of the present invention;

[0039] Fig. 20This is a schematic diagram of the prototype construction of the hybrid bus test system of the present invention. DETAILED DESCRIPTION

[0040] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0041] The present invention provides a universal airborne data bus monitoring and testing software framework design method, which solves the problem of poor universality and reusability of current airborne data bus monitoring and testing systems. The universal design is carried out by adopting the domain engineering method and the software product line method, which can meet the development requirements of various types of airborne data bus monitoring and testing systems. Please refer to Figure 1 , the general airborne data bus monitoring and testing software framework design method comprises the following steps:

[0042] S1: Field analysis of airborne bus test systems: By analyzing the test processes of various airborne bus systems, the common operations and general test processes of all airborne bus test systems are obtained:

[0043] A1: Data acquisition: Obtain the data required for transmission from the aircraft and flight environment simulation software;

[0044] A2: Data processing: The actuator processes the acquired data to obtain the data to be sent. This data is in the computer representation format.

[0045] A3: Data packaging: The airborne bus ICD packaging and parsing program packages the computer format data into ICD format data;

[0046] A4: Data transmission: The data in ICD format is sent to the onboard data bus. At this time, the monitoring module can also be used to monitor the data before transmission so as to compare it with the data received by the receiver and perform delay analysis.

[0047] A5: Data reception: The receiving end receives data in ICD format from the bus. At this time, the monitoring module can also be used to monitor the received data for comparison;

[0048] A6: Data unpacking: The onboard bus ICD packing and parsing program parses the bus data in ICD format into computer format data;

[0049] A7: Data display: various data are displayed on the monitoring interface;

[0050] S2: Design of domain framework of airborne bus test system: Under the guidance of universal design principles, a domain framework of airborne data bus test system that can be expanded and reused is designed by adopting domain engineering method and software product line method. This framework can be expanded and reused according to different user needs, and airborne bus monitoring and test systems of different types and purposes can be quickly built;

[0051] S3: Design of domain components of airborne bus test system: Extract various common domain components according to the common operations of airborne bus test system. Common domain components include: common data source component, common buffer data area component, common exciter component, common data packaging / parsing component and common data monitoring and display component.

[0052] S4: Application verification of universal airborne bus monitoring and testing system: In order to verify the universality of the universal airborne bus testing system and monitoring system proposed in the present invention, a prototype software of a universal airborne data bus testing and monitoring system is built. The prototype system consists of a core part and an extended part: the core part is the universal bus interface monitoring software, data parsing software and universal testing system framework software; the extended part includes adapter interface software for various typical airborne data buses. The prototype system is used to test and monitor the ARINC429 bus, 1553B bus and AFDX bus data respectively, completing the functional verification of the prototype system.

[0053] Example

[0054] (1) Design of the framework of the airborne bus monitoring and testing system

[0055] The domain framework of the airborne bus monitoring and test system is a software architecture designed in C++ language for the entire system. This architecture can be expanded and reused according to different user needs to quickly build airborne bus monitoring and test systems of different types and purposes. The software architecture of the general airborne bus test system is as follows: Figure 4 As shown;

[0056] The system consists of a core abstraction layer and six subsystems. The core abstraction layer extracts the common components of various airborne bus test systems and implements a common test process. The six subsystems are extensions of the domain components to adapt to various data sources, bus types, actuator types, parsing requirements, and display requirements.

[0057] ① Core abstract layer: The core abstract layer includes five abstract classes: bus model class Model, stimulator model class Exciter, abstract data writing class DBWriter, abstract data source class DataSource, and abstract display class View. These classes are a collection of abstract components of the general airborne data bus test system. The interaction between the instances of these classes completes the actual test process of various airborne bus systems.

[0058] ② Data source subsystem: The data source subsystem uses the abstract data source class DataSource as the base class and constructs a factory class for a specific data source. The factory class can load and initialize specific data sources according to user configuration files, such as FlightSim, FlightGear, or Prepar3D, aircraft and flight environment simulation software, which encapsulates the data sources required by various airborne bus test systems.

[0059] ③Data distribution subsystem: The active object of the data distribution subsystem is the DataDispathcer class object, which reads the data in the abstract data source and lets the subclass object of the DBWriter class, that is, the data writing object of a specific airborne subsystem, write the data read from the data source into the unified data storage subsystem. The data distribution subsystem also adopts the abstract factory mode, which can flexibly generate various data writing objects according to user needs. These data writing objects correspond to the data required by each airborne subsystem;

[0060] ④ Unified data storage subsystem: The data storage subsystem contains various data required by each onboard subsystem. The data is organized in the form of a B+ tree and stored in shared memory so that all subsystems can access it in real time. In essence, it implements a streamlined real-time database in memory, which can quickly complete the addition, deletion, modification and query of various data;

[0061] ⑤ Exciter subsystem: The exciter subsystem needs to simulate the behavior of various subsystems in the airborne system, such as the flight management system, display control system, navigation, radar, etc. The characteristics of these subsystems are to periodically read external data, perform certain calculations, and then output them to other subsystems. Therefore, the exciter subsystem not only includes various exciter objects, but also needs to design periodic work threads to schedule these objects and drive them to complete the periodic process of "reading data-processing data-outputting data". At the same time, for the needs of testing, it is sometimes necessary to freeze the current output data, so a master controller is also required to control the behavior of all exciters;

[0062] ⑥Data parsing subsystem: The data parsing subsystem completes the packaging and parsing of ICD. In order to achieve universality for various bus types and ICD formats, the abstract parsing components in the core subsystem will be replaced by specific bus class objects. At the same time, various ICD formats are encapsulated in Map class objects, which are parsed and loaded into memory during system initialization as rules for packaging and parsing specific ICDs.

[0063] ⑦ Data display subsystem: The data display subsystem meets the user's general requirements for various display components in terms of arrangement, appearance, data type, etc. The display component factory class object in the system can generate various display components according to the user's specific needs, such as progress bars, dashboards, text boxes, etc., and display monitoring data according to the user-defined arrangement and data type;

[0064] (2) Data source subsystem design

[0065] The class structure of the data source subsystem is as follows Figure 5 As shown in the figure, this subsystem has a dependency relationship with the data distribution subsystem. The DataDispatcher class object in the data distribution subsystem first references the object of the data source factory class DataSourceFactory and uses its GetSource method to obtain the actual data source. The data source to be obtained here is the one that the user manually configures in the configuration file before the system starts. Figure 5 In the , three data source subclasses are identified, but users can use other data sources by writing a specific data source class as a subclass of the abstract data source class and implementing the three methods specified in its abstract class, namely, the Init method, the SendData method, and the RecData method. At the same time, users should write a factory class for specific data source objects and let it inherit the abstract factory class DataSourceFactory and implement its abstract method GetSource. In this way, without changing the original test system source code, users only need to generate a dynamic library of the specific factory class and the specific data source class to complete the adaptation of the new data source.

[0066] (3) Data distribution subsystem design

[0067] The class structure of the data distribution subsystem is as follows Figure 6As shown, the data obtained from the data source subsystem is the data of each subsystem of the entire aircraft, such as the flight control system, autopilot system, hydraulic system, flight management system, etc. These data are usually encapsulated in some large structures and are not stored according to subsystem classification. Therefore, it is necessary to provide a data distribution service to classify the data required by each actuator and store it in a unified data storage subsystem. The data distribution subsystem provides an abstract factory class DBWriterFactory, which can be used to generate data writing objects for various airborne subsystems, such as the flight management system data writing class FMSWriter, the navigation system data writing class NAVWriter, the display system data writing class DispWriter, etc. These class objects are generated by their corresponding specific factory classes. Users must implement the GetData method in the subclass to obtain data, and implement the SyncDB method to write data into the unified data storage subsystem;

[0068] In terms of general design, users can add various new data writing objects to meet the specific needs of the airborne bus test system by writing a specific data writing class as a subclass of the abstract data writing class DBWriter class, and writing a specific factory class as a subclass of the abstract factory class DBWriterFactory;

[0069] (4) Unified data storage subsystem design

[0070] ①Unified data storage subsystem outline design

[0071] The unified data storage subsystem is the link between the data distribution subsystem, the exciter subsystem and the data analysis subsystem, and is the storage center of the test data of the airborne bus test system. The various airborne data read by the data distribution subsystem from the data source subsystem are classified and stored in the unified data storage subsystem according to a tree structure, so as to facilitate the reading of each exciter in the exciter subsystem. At the same time, the data in the unified data storage subsystem is mapped by the data analysis subsystem into ICD format data transmitted on the airborne bus according to the mapping rules specified by the user (called I / OMAP rules), and sent to the airborne bus by the exciter. The principle is as follows: Figure 7 As shown;

[0072] ② Unified data storage subsystem module division

[0073] The internal modules of the unified data storage subsystem are divided as follows: Figure 8As shown, the system is divided into two modules: configuration tool and runtime support. The configuration tool module includes mapping configuration module, parser configuration management module, shared memory operation module, shared memory queue management module and configuration file parsing module. These modules load various data from local configuration files into shared memory and initialize them according to user configuration, and convert the unified data storage format into various ICD formats according to the parsing rules and mapping rules specified by the user. The shared memory management module provides a way for each user process to interact;

[0074] The runtime support module is divided into four levels: the logic table operation layer provides a unified interface for data addition, deletion, modification and query for the data distribution subsystem, the exciter subsystem and the data analysis subsystem; the mapping operation module of the physical adaptation layer provides ICD packaging / analysis support for the data analysis subsystem; the data index layer stores the shared memory address of each data in the B-tree mode, thereby supporting fast retrieval and modification of data; the memory operation layer stores the actual data;

[0075] ③ Unified data storage subsystem data organization

[0076] In order to support the real-time data interaction of the airborne data bus test system, the test data of each airborne subsystem is stored in the shared memory in the form of B-tree, and an index is provided in the application process memory. There are three types of B-trees in the application process memory, namely, table index tree, variable index tree and mapping index tree, which are responsible for subsystem variable table addressing, variable addressing in the table and ICD mapping relationship table addressing respectively. It should be noted that each B-tree in the application process memory stores the address of the corresponding variable in the shared memory, rather than the actual variable, in order to save data storage time. In the shared memory, the table linked list, variable table and mapping table are stored in the form of linked lists, in order to facilitate the insertion and deletion of data. The data organization of the unified data storage subsystem is as follows: Fig. 9 As shown;

[0077] ④Maintaining the consistency of system data

[0078] In order to ensure that users of the unified data storage subsystem (i.e., the actuator subsystem, the data distribution subsystem, and the data parsing subsystem, collectively referred to as applications here) can access the data in the shared memory efficiently and in real time, two buffers are opened in the application memory space to store the various variables required by the application, namely, the input variable buffer and the output variable buffer. The input variables and output variables required by each application are loaded into the memory from the configuration file during the system initialization phase, and are periodically updated according to the data in the shared memory. In order to ensure the synchronization of the data in the application buffer with the data in the shared memory, a periodic synchronization process is used to refresh the data in real time, including refreshing the input data in the local memory to the shared memory, and updating the output data in the shared memory to the local buffer. The principle is as follows: Fig.10 As shown, it should be noted that the input and output here are relative to the shared memory;

[0079] ⑤Interface provided by the index layer

[0080] The index layer provides initialization interface, search interface, insertion interface, deletion interface and group search interface for external systems (such as data distribution subsystem). These interfaces are actually implemented by the underlying B-tree index. The B-tree index provides the implementation of B-tree-based initialization, search, insertion and deletion operations. The purpose of providing the interface layer is to facilitate the replacement of dynamic libraries when a better retrieval algorithm is needed, without making any changes to the main program code. The principle is as follows: Fig.11 As shown;

[0081] (5) Actuator subsystem design

[0082] The exciter subsystem reads and calculates the test data and sends it to the airborne bus. In a real airborne bus test system, a large number of exciters must be equipped to simulate the behavior of various airborne systems. At the same time, the behavior of each exciter has a strict timing relationship and needs to collect and send data periodically. Therefore, designing a flexible and extensible universal exciter framework can improve the versatility of the airborne bus test system. At the same time, the software framework can save a lot of development time for exciter developers, focusing only on application logic without having to worry about the underlying communication and scheduling. This section designs a universal exciter framework that can adapt to the development needs of various exciters in the airborne bus test system. Its class diagram is shown below. Fig.12 As shown;

[0083] The exciter subsystem adopts the "component + framework" concept and designs a "white box framework" to allow developers of airborne bus test systems to customize various airborne system exciters according to their needs;

[0084] The exciter scheduling framework mainly includes two parts: component management and component scheduling. Component management is to load the configuration information of the component into the framework and manage the basic information of the component. Component scheduling is to drive the normal operation of the component. According to the periodic characteristics of the exciter, a scheduler model and a period group model are designed in the component scheduling. Exciters with the same period are added to the same period group, and then the period group is driven by the scheduler. The period group then drives each exciter member in the group to complete the scheduling of the exciter.

[0085] The scheduling framework principle is as follows Fig.13 As shown:

[0086] The top-level scheduler is responsible for starting, stopping, pausing and stepping control of the stimulators on all nodes in the entire airborne bus test system. It sends the above instructions to each node to control the scheduler on each node to schedule the stimulator components of this node. A scheduler resides on each test system node. All stimulator tasks are grouped according to cycles, with cycle groups as component containers. Each cycle group contains all stimulator components of a specific cycle. An stimulator may be composed of one or more stimulator components. For example, in Fig.13 In the test system node 1, components FMS1, FMS2, and FMS3 constitute the stimulator of the flight management system, indicating that the flight management system stimulator is composed of components of three different cycles. Each test node has a component manager to manage the registration and loading of all components on this node.

[0087] (6) Data analysis subsystem design

[0088] ①Main objects of the system

[0089] The class diagram of data analysis subsystem design is as follows Fig.14 As shown, the data parsing subsystem is the key technology to complete the coexistence of multiple types of bus adaptation and multiple types of ICD airborne network, and is also the actual implementation module of the airborne data bus ICD unified management technology. The system includes two types of objects, one is the bus class object (Model class object), which encapsulates the process of mutual conversion between the unified data storage subsystem data format and the bus test system data format (that is, ICD format). This type of object will convert the unified representation data format into the specified ICD format or perform reverse parsing operations according to given rules. The other type is the Map_combus class object that specifies the conversion rules, which specifies the packaging and parsing rules of a specific bus. Through this abstraction, users can flexibly select various ICD packaging / parsing programs and packaging / parsing rules to adapt to different types of buses and different ICD formats of the same type of buses;

[0090] ②Configuration and registration of parsing rules

[0091] The ICD packaging / parsing rules are specified by the user in the system configuration file before the system is initialized. During the system initialization phase, these configuration files are automatically parsed by the bus test system and loaded into the memory. For an stimulator that uses a specific type of bus and a specific type of ICD, it is necessary to register the ICD packaging / parsing rules (called Map rules) for its input data and output data in the memory. These mapping rules are stored in the local memory space of the stimulator subsystem during the system initialization phase. In order to provide support for multiple buses and multiple ICD formats for a certain stimulator, a local mapping collection is opened in the local memory of the stimulator subsystem, which can store mapping rules for multiple buses and ICDs at the same time. In this way, users can allow an stimulator subsystem to communicate with multiple buses at the same time, and parse and package data according to various ICD parsing rules. The registration process of the parsing rules is as follows: Fig.15 As shown;

[0092] ③ICD parsing / packaging process

[0093] Each stimulator in the stimulator subsystem (which is an application program for the parsing subsystem) calls the frame transfer operation of the data parsing subsystem, and converts the data in the unified data storage system into test data transmitted on the airborne bus test system, that is, ICD format data, according to the ICD packaging rules specified in the local mapping rules. In the opposite direction, the test data transmitted on the bus test system is decoded through the reverse process;

[0094] (7) Data display subsystem design

[0095] The design goal of the data display subsystem is to provide users with a customizable, multi-format monitoring data display interface to facilitate users to observe, count, compare, and analyze bus data. To achieve this goal, the view class View and the display component factory class ControlFactory are designed, such as Fig.17 As shown in the figure, the View class is designed as an abstract class, which is responsible for displaying various types of bus data. In addition to some display component classes provided by the system itself, users can add more display components according to the system test requirements to display data in the specified form. The ControlFactory class is responsible for generating various specific display component factory classes, and these specific display component factories can generate various display component objects according to the system configuration. In order to uniformly manage various display components in the display subsystem, the UI class is designed to complete component management, registration and loading, etc.

[0096] (8) Construction of a prototype of a universal airborne data bus test and monitoring system

[0097] In order to verify the universality of the airborne bus test system and monitoring system proposed in the present invention, two dedicated bus test systems and a hybrid bus test system were built using the universal domain framework and domain components.

[0098] ①AFDX bus test system prototype construction

[0099] A prototype of the AFDX bus test system was built for the airborne network of a certain type of large aircraft. The data source uses the aircraft and flight environment simulation software Flightsim. The actuator subsystem uses the flight management system, display control system and electromechanical management system actuator. The data analysis subsystem uses the AFDX bus ICD analysis configuration. The display subsystem is built with display components such as compass, altimeter, flight attitude meter, etc. The system components and data flows are as follows: Fig.18 As shown;

[0100] ②ARINC429 bus test system prototype construction

[0101] An ARINC429 bus test system was built for the airborne network of a certain type of domestic passenger aircraft. The data source uses the flight environment simulation software FlightGear. The exciter subsystem uses the inertial navigation system exciter and the radar system exciter. The data analysis subsystem uses the ARINC429 bus ICD analysis configuration. The display subsystem uses various text display components. The system components and data flows are as follows: Fig.19 As shown;

[0102] ③ Construction of hybrid bus test system prototype

[0103] A bus test system that combines AFDX and ARINC429 buses was built for the airborne network of a certain type of hybrid bus. The data source subsystem uses Prepar3D as the data source. The exciter subsystem uses the electromechanical management system exciter, the flight management system exciter, and the display control system exciter as the AFDX bus data transceiver exciter. The atmospheric data computer exciter and the inertial navigation system exciter are used as the ARINC429 bus data transceiver exciter. The data analysis subsystem uses both ARINC429 and AFDX bus ICD analysis configurations. The display subsystem uses a mixture of various graphical display components and text display components. The system components and data flows are as follows: Fig. 20 As shown;

[0104] During the prototype construction of the three systems, the main framework program of the entire bus test system does not need to be modified. The user only needs to modify the configuration file and write the corresponding subclass program to complete the construction of different types of bus test systems. At the same time, the test data transmission, analysis, monitoring and display problems in the bus test system where multiple types of buses and ICDs coexist have also been well solved in the prototype of the hybrid bus test system. The results of prototype verification show that the universal airborne bus test system proposed in this paper has good scalability and good adaptability to new buses and new ICD formats.

[0105] Although the present invention has been described above with reference to the embodiments, various modifications may be made thereto and parts thereof may be replaced with equivalents without departing from the scope of the present invention. In particular, as long as there is no structural conflict, the various features in the embodiments disclosed by the present invention may be used in combination with each other in any manner, and the fact that these combinations are not exhaustively described in this specification is only for the sake of omitting space and saving resources. Therefore, the present invention is not limited to the specific embodiments disclosed herein, but includes all technical solutions falling within the scope of the claims.

Claims

1. A general airborne data bus monitoring and testing software framework design method, characterized by: The general airborne data bus monitoring and testing software framework design method comprises the following steps: S1: Field analysis of airborne bus test systems: By analyzing the test processes of various airborne bus systems, the common operations and general tests of all airborne bus test systems are obtained; S2: Design of domain framework of airborne bus test system: Under the guidance of universal design principles, a domain framework of airborne data bus test system that can be expanded and reused is designed by adopting domain engineering method and software product line method. This framework can be expanded and reused according to different user needs, and airborne bus monitoring and test systems of different types and purposes can be quickly built. The system includes a core abstract layer and six subsystems. The core abstract layer extracts the common components of various airborne bus test systems and realizes a general test process. The six subsystems are the expansion of domain components to adapt to various data sources, bus types, stimulator types, parsing requirements and display requirements. S3: Design of domain components of airborne bus test system: Extract various common domain components according to the common operations of airborne bus test system; S4: Application verification of universal airborne bus monitoring and testing system: In order to verify the universality of the universal airborne bus testing system and monitoring system proposed in the present invention, a prototype software of a universal airborne data bus testing and monitoring system is built. The prototype system consists of a core part and an extension part: the core part is the universal bus interface monitoring software, the data parsing software and the universal testing system framework software; the extension part includes the adapter interface software for various typical airborne data buses. The prototype system is used to test and monitor the data of ARINC429 bus, 1553B bus and AFDX bus respectively, and the functional verification of the prototype system is completed; The six subsystems include: a data source subsystem, a data distribution subsystem, a unified data storage subsystem, an exciter subsystem, a data analysis subsystem, and a data display subsystem; The unified data storage subsystem design specifically includes: ①Unified data storage subsystem outline design The unified data storage subsystem is the link between the data distribution subsystem, the exciter subsystem and the data analysis subsystem, and is the storage center of the test data of the airborne bus test system. The various airborne data read by the data distribution subsystem from the data source subsystem are classified and stored in the unified data storage subsystem according to the tree structure, so as to facilitate the reading of each exciter in the exciter subsystem. At the same time, the data in the unified data storage subsystem is mapped into ICD format data transmitted on the airborne bus by the data analysis subsystem according to the mapping rules specified by the user, and sent to the airborne bus by the exciter; ② Unified data storage subsystem module division The system is divided into two modules: configuration tools and runtime support; ③ Unified data storage subsystem data organization In order to support the real-time data interaction of the airborne data bus test system, the test data of each airborne subsystem is stored in the shared memory in the form of B-tree, and an index is provided in the application process memory. There are three types of B-trees in the application process memory, namely, table index tree, variable index tree and mapping index tree, which are responsible for subsystem variable table addressing, variable addressing in table and ICD mapping relationship table addressing respectively. Each B-tree in the application process memory stores the address of the corresponding variable in the shared memory, not the actual variable. In the shared memory, the table linked list, variable table and mapping table are stored in the form of linked lists. ④Maintaining the consistency of system data Two buffers are opened in the application memory space to store various variables required by this application, namely the input variable buffer and the output variable buffer. The actuator subsystem, data distribution subsystem and data analysis subsystem are collectively referred to as the application; ⑤Interface provided by the index layer The index layer provides initialization interface, search interface, insertion interface, deletion interface and group search interface for external systems. These interfaces are implemented by the underlying B-tree index, which provides the implementation of B-tree-based initialization, search, insertion and deletion operations.

2. A general airborne data bus monitoring and testing software framework design method according to claim 1, characterized in that: The common operation and general test method of the airborne bus test system in step S1 include the following steps: A1: Data acquisition: Obtain the data required for transmission from the aircraft and flight environment simulation software; A2: Data processing: The actuator processes the acquired data to obtain the data to be sent. This data is in the computer representation format. A3: Data packaging: The airborne bus ICD packaging and parsing program packages the computer format data into ICD format data; A4: Data transmission: The data in ICD format is sent to the onboard data bus. At this time, the monitoring module can also be used to monitor the data before transmission so as to compare it with the data received by the receiver and perform delay analysis. A5: Data reception: The receiving end receives data in ICD format from the bus. At this time, the monitoring module can also be used to monitor the received data for comparison; A6: Data unpacking: The onboard bus ICD packing and parsing program parses the bus data in ICD format into computer format data; A7: Data display: Various data are displayed on the monitoring interface.

3. A general airborne data bus monitoring and testing software framework design method according to claim 2, characterized in that: The general domain components in step S3 include: a general data source component, a general buffer data area component, a general exciter component, a general data packaging / parsing component and a general data monitoring and display component.

Images