Loose coupling automatic test system for avionics equipment

Abstract

The invention discloses an avionics equipment-oriented loose coupling automatic test system. The innovative architecture of the avionics equipment-oriented loose coupling automatic test system is mainly composed of three core parts, namely a virtual resource warehouse, a unified communication base and an application unit. The virtual resource warehouse is used for abstracting physical test resources and mapping the physical test resources into uniform logic resources to realize resource decoupling; the unified communication base is formed by fusing a data network, a control network and a storage network, provides a unified interaction channel for all elements of the system, and realizes interaction decoupling; and the application unit is constructed on the base and calls virtual resources to realize service functions of test control, execution, management and the like. According to the system, through the triple decoupling architecture, a test program can be developed independently, system functions can be recombined flexibly, different avionics devices and test environments can be adapted at small cost, and the development complexity and life cycle cost of the test system are reduced fundamentally.

Description

Technical Field

[0001] This invention belongs to the field of avionics testing technology, specifically relating to the architecture design of an automated testing system. More particularly, it relates to an automated testing system that achieves loose coupling through resource virtualization and communication unification, suitable for efficient and low-cost testing of various airborne avionics equipment. Background Technology

[0002] Modern aircraft avionics systems are complex and highly integrated, making the adequacy and cost-effectiveness of their testing and support crucial for ensuring flight safety and controlling R&D costs. Currently, dedicated automated test equipment (ATE) is widely used in the avionics testing field. These systems typically employ a "tightly coupled" design, with their test procedures, system software, and specific physical test hardware deeply integrated.

[0003] This tightly coupled architecture leads to several serious problems:

[0004] 1. Poor reusability: Test programs and systems developed for specific avionics equipment cannot be directly applied to other equipment, and even after upgrading the same equipment, a lot of modifications are required, resulting in duplicate investment.

[0005] 2. Long development cycle and high cost: Any change in physical resources or adjustment of testing requirements requires underlying modifications, recompilation and comprehensive verification of the system software and test programs, which consumes a lot of manpower and time.

[0006] 3. Difficult to maintain and upgrade: The system is rigid, and upgrading or expanding hardware requires high adaptation costs, and the technology iteration is slow.

[0007] To address these issues, domestic and international researchers have begun exploring loosely coupled design. For example, they have attempted to abstract hardware using standardized interfaces (such as IVIs). However, existing explorations are mostly limited to localized improvements and fail to provide a complete solution at the system architecture level to achieve comprehensive and systematic decoupling between test procedures, system functions, and physical resources. Domestically, there is a particular lack of mature, feasible, and practically applicable loosely coupled automated test system design methods.

[0008] Therefore, there is an urgent need in this field for an innovative system architecture that can fundamentally solve the many drawbacks of tight coupling. Summary of the Invention

[0009] The purpose of this invention is to overcome the shortcomings of the prior art and provide a loosely coupled automatic test system for avionics equipment. It aims to achieve dual decoupling between test procedures and test system, as well as between system functions and physical resources, through architectural innovation, thereby significantly improving the openness, reusability and maintainability of the test system and greatly reducing the total life cycle cost.

[0010] To achieve the above objectives, the present invention adopts the following technical solution:

[0011] A loosely coupled automatic test system for avionics equipment has an innovative architecture based on three core elements: a virtual resource repository, a unified communication platform, and application units.

[0012] The virtual resource repository, serving as the system's resource management center, is responsible for abstracting and mapping diverse physical testing resources (such as instruments and matrix switches) into unified logical resources through a configuration model (such as based on the ATML standard). It isolates the specific implementation details of physical resources, providing transparent and consistent resource access services to upper-layer application units.

[0013] The unified communication platform, serving as the nerve center of the system, is composed of a data network, a control network, and a storage network. It provides unified, reliable, and efficient communication and data sharing capabilities for the virtual resource repository and various application units, forming the foundation for loosely coupled interaction between elements within the system.

[0014] The application units are collections of functional modules (such as control units and test units) oriented towards testing services. They are built on a unified communication platform and execute specific testing tasks by calling logical resources in a virtual resource repository, thereby decoupling themselves from physical resources and enabling independent development and deployment.

[0015] Compared with the prior art, the technical solution provided by the present invention has the following beneficial effects:

[0016] This system architecture achieves the following: Resource decoupling: Through a virtual resource repository, application units no longer directly manipulate physical resources, and the impact of hardware changes is confined within the repository. Interaction decoupling: Through a unified communication platform, application units do not need point-to-point communication; they only need to interact with the platform, achieving modularization and independent evolution of functions. Program decoupling: The testing unit can interpret and execute test programs (such as Python scripts) independent of system development, separating the development of test logic from the development of the test system platform.

[0017] Extreme flexibility: The system can quickly adapt to different avionics equipment and physical test platforms with minimal adaptation costs (mainly in updating the configuration model of the virtual resource repository). Significant cost reduction and efficiency improvement: Test programs can be developed independently, fully utilizing the open-source ecosystem and shortening the development cycle; system functional modules are reusable, avoiding redundant construction and significantly reducing development and maintenance costs. Excellent scalability and maintainability: New test functions or hardware resources can be added to the system in a modular form without affecting existing components, making system maintenance and upgrades simple and quick. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is the overall system architecture diagram;

[0020] Figure 2 This is a flowchart of the test task workflow;

[0021] Figure 3 This is a schematic diagram of the resource virtualization mapping principle. Detailed Implementation

[0022] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0023] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this invention, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0024] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. The drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0025] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that aspects can be practiced without these specific details. To enable those skilled in the art to better understand the invention, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, features defined as "first" and "second" may explicitly or implicitly include one or more of that feature. In the description of the invention, unless otherwise stated, "a plurality of" means two or more.

[0026] Overall, the loosely coupled automated testing system of the present invention, such as Figures 1 to 3 As shown, a testing platform with virtualizable resources, standardized interactions, and modular functions is constructed through the collaborative work of the "virtual resource repository," "unified communication platform," and "application units." The implementation methods of these three core components are described in detail below.

[0027] 1. Implementation methods of virtual resource repositories

[0028] The virtual resource repository is the core of this system's decoupling from physical hardware. Essentially, it is a resource modeling and runtime mapping engine.

[0029] Resource Abstraction and Modeling: The internationally recognized ATML standard is used to describe physical test resources. A corresponding XML description file is created for each physical resource (such as an oscilloscope, programmable power supply, and switch matrix). This file defines the resource type, model, interface (such as GPIB, PXI, LAN), all available channels, capability parameters (such as range, accuracy, and speed), and executable operations (such as measureDCVoltage, setOutput).

[0030] Logical resource generation: When the system starts, the resource management service (i.e., the running instance of the virtual resource repository) loads and parses these ATML files, building a logical resource pool in memory. Each logical resource in the pool has a unique identifier (e.g., DMM1, PowerSupply_Channel A), and its interface and behavior are fully defined by the model.

[0031] Instruction translation and driver mapping: When the upper-layer test program calls instructions for logical resources (such as DMM1.measureVoltage()), the virtual resource repository, through IVI driver technology or a specific vendor's SDK, translates this standardized call into low-level instructions that the specific physical device can recognize (such as calling specific functions in the NI-DMM driver library). This translation process is completely transparent to the test program.

[0032] Benefits: When physical devices need to be replaced or upgraded, test engineers only need to update or replace the corresponding ATML model files and drivers. All test programs that call this logical resource can run on the new device without any modifications, completely isolating the impact of hardware changes.

[0033] 2. Implementation methods of the unified communications platform

[0034] As the "information superhighway" of the system, the unified communications platform can be implemented using mature middleware technology for its three networks, and provides a unified API to the upper layer.

[0035] Data Network: Implemented using a high-bandwidth message subscription / publish / sub middleware, such as DDS or ZeroMQ. This network is responsible for transmitting large volumes of high-speed data generated during testing, such as bus data and sampled waveforms. The data network is typically configured in a star topology with a central node acting as a message broker to ensure efficient and reliable data distribution.

[0036] Control Network: Implemented using a decentralized data distribution service (DDS) or similar technology. This network is responsible for transmitting control commands with high real-time and reliability requirements, such as "start test," "pause," and "set parameters." Control commands are encapsulated into specific "topics." Employing a decentralized peer-to-peer (P2P) architecture, it achieves extremely low latency and high reliability in command transmission, avoiding single points of failure.

[0037] Storage Network: This utilizes distributed file systems or Network Attached Storage (NAS) technology, combined with database services. It stores all persistent data in the system, including but not limited to: ATML resource model files, test scripts, system configuration files, historical test data, and test logs. The storage network typically employs a central node architecture to provide a unified access point.

[0038] Unified API: The client functionalities of the three network types mentioned above are encapsulated into a unified software middleware package. This middleware provides API interfaces for languages ​​such as C, C++, and Python to upper-layer applications. Application units only need to call these APIs to complete all communication operations such as network registration, data publishing and subscription, command sending and receiving, and file storage and retrieval, without having to worry about the complex underlying network protocols and hardware adaptations.

[0039] 3. Implementation methods of the application unit

[0040] Application units are business function modules built on a unified communications platform and a virtual resource repository. They communicate and access resources by calling the platform's APIs.

[0041] Control Unit: Serving as the main human-machine interface, it can be implemented using PyQt or Web technologies. It sends commands to other units by calling the control network's API and receives test status and results in real-time via a subscribed data network.

[0042] The test unit, acting as the execution engine for the test program, integrates a script interpreter, such as a Python interpreter. It receives the test program (e.g., a .py file) from the control unit and executes it line by line using the interpreter. Resource operation instructions in the program (e.g., DMM1.measureVoltage()) are routed to the virtual resource repository for execution by calling the dedicated API library provided by this invention.

[0043] Resource Management Unit: This unit is the management interface for the virtual resource repository, and it is also an application unit itself. It provides a graphical interface for registering, verifying, and monitoring logical resources, and its backend service is the aforementioned "Resource Modeling and Runtime Mapping Engine".

[0044] Other auxiliary units:

[0045] Simulation Unit: Can integrate Matlab / Simulink models or dedicated simulators to simulate the crosslinking system of the test piece and exchange data with the test piece model through a data network.

[0046] Management Unit: SVN / Git is used for system configuration management, and a centralized log server (such as the ELK stack) is used for log management.

[0047] Development Unit: Based on the Eclipse or Visual Studio Code development environment, it integrates the system's API library and debugging tools, providing test engineers with a one-stop development experience.

[0048] 4. System Workflow Example

[0049] Combination Figure 1 The following example, "Airborne Communication Bus Interface Test," illustrates the workflow of this system in detail:

[0050] ●Test Startup and Program Selection

[0051] On the human-machine interface of the control unit, the user selects the test program named "Bus_Interface_Test.py" from the test project library and clicks the "Run" button.

[0052] The control unit issues a control command topic, such as TestCommand / Start, to the test unit through the control network of the unified communication base. The data packet of this topic contains the path information of the test program to be executed.

[0053] ●Test program interpretation and execution

[0054] Once the test unit subscribes to and receives the TestCommand / Start topic, it launches its embedded Python interpreter, loads and interprets the "Bus_Interface_Test.py" file from the unified communications platform's storage network.

[0055] The first instruction in the test program might be dmm = ResourceWarehouse.getResource("HighAccuracy_DMM"), which initiates a resource request to the virtual resource repository through the system's API library.

[0056] ●Logical resource invocation and mapping

[0057] The virtual resource repository receives a request and searches its logical resource pool for a resource model with the identifier HighAccuracy_DMM. This model points to a physical high-precision digital multimeter (e.g., Keysight Technologies 34470A) and defines all its capabilities.

[0058] The test program continues execution: voltage = dmm.measureVoltage(channel = 1). This call is translated by the API library into a standard service request to the virtual resource repository.

[0059] The virtual resource repository, based on the ATML model of HighAccuracy_DMM, calls the IVI driver bound to it (such as the ni DMM_Measure function) to generate the precise SCPI instruction "MEAS:VOLT:DC?10,0.001,(@1)", and sends it to the real multimeter hardware via a physical bus (such as PXI).

[0060] ●Test data collection and distribution

[0061] The physical multimeter performs the measurement and returns the voltage reading (e.g., "5.125").

[0062] After receiving the data, the driver layer of the virtual resource repository encapsulates it into a standard format and returns it to the test program.

[0063] The test program determines whether the voltage value is within the expected range. At the same time, by calling the unified communication base's data network API, it publishes the raw data 5.125 and the judgment result PASS to a data topic named TestData / Voltage.

[0064] ●Real-time monitoring and results display

[0065] The control unit and the visual unit are constantly subscribed to TestData / related topics. They receive voltage data and test results in real time and immediately update the waveforms and result lists on the human-machine interface for user observation.

[0066] At the same time, the test unit sends the test progress status (such as 75% Complete) to the control unit through the control network.

[0067] ●Test completion and data archiving

[0068] The test program has completed execution. The test unit publishes the TestCommand / Finished topic via the control network, along with the final test summary report.

[0069] Upon receiving the message, the control unit updates the interface status to "Test Complete".

[0070] Throughout the entire testing process, all detailed logs, intermediate data, and final reports were automatically uploaded by each unit to the unified communication platform's storage network for permanent storage, for later querying and analysis.

[0071] The system employs three core components: a virtual resource repository, a unified communication platform, and application units. The virtual resource repository abstracts and maps physical test resources into unified logical resources, achieving resource decoupling. The unified communication platform, comprised of integrated data, control, and storage networks, provides a unified interaction channel for all system elements, achieving interaction decoupling. The application units, built upon the aforementioned platform, utilize virtual resources to implement test control, execution, and management functions. This triple-decoupling architecture allows for independent development of test programs, flexible reconfiguration of system functions, and adaptation to different avionics and test environments at minimal cost, fundamentally reducing the development complexity and lifecycle cost of the test system.

[0072] Process summary and architectural advantages:

[0073] As can be seen from the above process, the application units (control and testing units) only interact with the unified communication platform and call logical resources in the virtual resource repository through standard APIs. They never directly contact the physical hardware and do not need to know the internal implementation of other units. The test programs are written in an open language like Python and are completely independent of the system. When the multimeter hardware needs to be replaced, only the ATML model and driver of HighAccuracy_DMM in the virtual resource repository need to be updated, and the above test process and programs can continue to run without any modifications. This fully demonstrates the significant technical advantages brought about by the dual decoupling (resource decoupling and interaction decoupling) achieved by the architecture of this invention.

[0074] The product provided by this invention has been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are merely for the purpose of helping to understand the core ideas of this invention. It should be noted that those skilled in the art can make various improvements and modifications to the invention without departing from the principles of the invention, and these improvements and modifications also fall within the protection scope of the invention claims.

Claims

1. A loosely coupled automatic test system for avionics equipment, characterized in that, The system includes: a virtual resource repository, a unified communications platform, and a set of application units; The virtual resource repository is used to virtualize physical test resources into logical resources through a configuration model and manage them in a unified manner, so as to isolate the impact of changes in physical resources on other parts of the system. The unified communication base is interconnected with the virtual resource warehouse and application units. It is composed of a data network, a control network and a storage network, and is used to provide unified communication and data access services for all elements in the system. The application unit communicates by calling the interface of the unified communication base and calls the logical resources in the virtual resource warehouse to provide various business functions for avionics equipment testing.

2. The loosely coupled automatic testing system according to claim 1, characterized in that, The virtual resource repository describes and models physical resources based on the ATML standard, and uses IVI driver technology to convert logical resource instructions into specific physical resource instructions.

3. The loosely coupled automatic testing system according to claim 1, characterized in that, In the unified communication base: The data network employs a high-bandwidth message subscription / publishing mechanism. The control network adopts a data distribution service mechanism without a central node. The storage network adopts a distributed network storage mechanism.

4. The loosely coupled automatic testing system according to claim 1, characterized in that, The application unit includes at least: The control unit provides control of the testing process and a human-machine interface. The test unit provides the execution environment for the test program and provides feedback on the test status and results.

5. The loosely coupled automatic testing system according to claim 4, characterized in that, The test unit is configured to interpret and execute test programs developed by the user independently of the automated test system.

Images