A Testability Design Method for Scenario-Based Airborne Electronic Systems

Abstract

The present invention belongs to the technical field of airborne electronic system design and test, and particularly relates to a testability design method for an airborne electronic system based on scenarios. By analyzing the context data of the working scenarios, a test data classification model is defined, and then the transfer path of the test data, the deployment structure of the test data control software, and the test data transfer method are defined. The generated test data can be used for testing, data monitoring, analysis, display, and playback on airborne or ground test platforms. On the one hand, it improves the test accessibility, thereby increasing the test coverage rate; on the other hand, it improves the fault recurrence rate, reduces the workload and difficulty of troubleshooting.

Description

Technical Field

[0001] The present invention belongs to the technical field of airborne electronic system design and test, and particularly relates to a testability design method for an airborne electronic system based on scenarios. Background Art

[0002] With the extensive application of information technology on aircraft, airborne electronic systems have become increasingly complex, with rapid growth in functions and scale, and the difficulty of their tests has also been continuously increasing. On the one hand, the functions of airborne electronic systems do not generate enough test data, resulting in the inaccessibility of the tested components during flight or ground tests, or low test coverage; on the other hand, although some faults generated by airborne electronic systems are discovered, they are intermittent faults and are difficult to reproduce in the later stage, making it difficult to solve the faults.

[0003] The main method for testability design of airborne electronic systems at home and abroad is the health management method based on BIT (Built-In Test). First, run the internal test program of the device to detect hardware and software faults, and then report the test results to the health management software. The health management software determines whether there are faults through logical equations and displays and records the fault information.

[0004] The advantage of the above testability design method is that it can quickly detect faults, but the disadvantage is that it cannot reproduce faults, and there is also a lack of sufficient scenario information when analyzing the causes of faults, resulting in a large amount of troubleshooting work and difficulty, and often leading to operation problems of the aircraft, which is a major pain point of airborne electronic systems. Summary of the Invention

[0005] In view of this, the present invention provides a testability design method for an airborne electronic system based on scenarios. By analyzing the context data of the working scenario, defining a test data classification model, and then defining the transfer path of test data, the deployment structure of test data control software, and the test data transfer method. The generated test data can be used for testing, data monitoring, analysis, display, and playback on airborne or ground test platforms. On the one hand, it improves the accessibility of the test, thereby increasing the test coverage; on the other hand, it increases the fault reproduction rate and reduces the amount of troubleshooting work and difficulty.

[0006] In order to achieve the above technical objectives, the specific technical solutions adopted by the present invention are as follows:

[0007] A testability design method for an airborne electronic system based on scenarios:

[0008] The testability is realized based on a test data classification model, the transfer path of test data, the deployment of test data control software, and the test data control method, wherein:

[0009] The test data data model is used to classify test data into three levels according to three working scenarios: aircraft operation, flight test, and ground test: level 1 data, level 2 data, and level 3 data;

[0010] The transfer path of the test data is configured as: different transfer paths are selected for the test data according to the available data bandwidth;

[0011] The test data control software is deployed as: a test data master software resides in the test platform, and a data control agent resides in each device under test;

[0012] The test data control method is: each data control agent first controls the test data according to the static configuration; then sends a communication request to the test data master software, and after obtaining communication authorization, reads the data control command in real time and controls the transmission of test data at different levels.

[0013] Further, the level 1 data faces the aircraft operation scenario and the data is generated in real time; the data content of the level 1 data includes: software entrance and exit, important code branch status, and important data structures;

[0014] The level 2 data faces the flight test and ground test, and the data is generated as needed; the content of the level 2 data includes: device-level input and output, software-level input and output, code branch status, and data structures;

[0015] The level 3 data faces the ground test and the data is generated as needed; the content of the level 3 data is all the data detected by the code execution probe.

[0016] Further, the transfer path of the test data is specifically as follows:

[0017] There are two transfer paths for the level 1 data. One is transferred to the airborne or ground test platform through the test network, and the other is transferred to the airborne data storage device through the airborne network;

[0018] There is one transfer path for the level 2 and level 3 data, which is: transferred to the airborne or ground test platform through the test network.

[0019] Adopting the above technical solution, the present invention can bring the following beneficial effects:

[0020] The present invention adopts a dedicated high-speed test interface and does not occupy valuable airborne network resources. The context data model of the scenario is defined hierarchically, which can be flexibly configured and obtained. It is convenient to select different levels of data for testing according to the test situation during flight tests and ground tests, and it is also convenient to save the working scenario. A certain amount of important scenario data is also saved during aircraft operation, which is convenient for fault analysis and location. Description of the Drawings

[0021] To more clearly illustrate the technical solutions of the embodiments of the present disclosure, the following will briefly introduce the accompanying drawings required for the embodiments. Obviously, the accompanying drawings in the following description are only some embodiments of the present disclosure. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can also be obtained based on these drawings.

[0022] Figure 1 It is a schematic diagram of the hierarchical model of test data for the testability design method of the scenario-based airborne electronic system in the specific implementation manner of the present invention;

[0023] Figure 2 It is a schematic diagram of the test data transfer path for the testability design method of the scenario-based airborne electronic system in the specific implementation manner of the present invention;

[0024] Figure 3 It is a schematic diagram of the deployment of the test data control software for the testability design method of the scenario-based airborne electronic system in the specific implementation manner of the present invention;

[0025] Figure 4 It is a schematic diagram of the test data control method for the testability design method of the scenario-based airborne electronic system in the specific implementation manner of the present invention. Specific implementation manner

[0026] The following will describe the embodiments of the present disclosure in detail with reference to the accompanying drawings.

[0027] The following illustrates the embodiments of the present disclosure through specific specific examples. Those skilled in the art can easily understand other advantages and effects of the present disclosure from the content disclosed in this specification. Obviously, the described embodiments are only some embodiments of the present disclosure, rather than all embodiments. The present disclosure can also be implemented or applied through other different specific implementation manners. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present disclosure. It should be noted that, without conflict, the following embodiments and the features in the embodiments can be combined with each other. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present disclosure without creative efforts belong to the scope of protection of the present disclosure.

[0028] Note that the following description relates to various aspects of embodiments within the scope of the appended claims. It should be apparent that the aspects described herein can be embodied in a wide variety of forms, and any specific structure and / or function described herein is for illustrative purposes only. Based on this disclosure, those skilled in the art should 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 a device and / or practice a method. Additionally, this device can be implemented and this method can be practiced using other structures and / or functionality in addition to one or more of the aspects set forth herein.

[0029] It should also be noted that the diagrams provided in the following embodiments only illustrate the basic concept of the present disclosure schematically. The diagrams only show the components related to the present disclosure and are not drawn according to the number, shape, and size of the components in actual implementation. The type, quantity, and ratio of each component in actual implementation can be arbitrarily changed, and the component layout type may also be more complex.

[0030] In addition, in the following description, specific details are provided to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0031] In an embodiment of the present invention, a testability design method for a scenario-based airborne electronic system is proposed:

[0032] The testability is achieved based on a test data classification model, the transfer path of test data, the deployment of test data control software, and the test data control method, where:

[0033] The test data model is used to classify test data into three levels: level 1 data, level 2 data, and level 3 data according to three working scenarios: aircraft operation, flight test, and ground test;

[0034] The transfer path of the test data is configured to select different transfer paths for the test data according to the available data bandwidth;

[0035] The deployment of the test data control software is as follows: a test data master software resides in the test platform, and a data control agent resides in each device under test;

[0036] The test data control method is as follows: each data control agent first controls the test data according to the static configuration; then sends a communication request to the test data master software, and after obtaining communication authorization, reads the data control command in real time and controls the transmission of test data at different levels.

[0037] In this embodiment, the first-level data is oriented to the aircraft operation scenario and is generated in real time; the data content of the first-level data includes: software access points, important code branch status, and important data structures;

[0038] The second-level data is oriented to flight tests and ground tests and is generated as needed; the second-level data content includes: equipment-level input and output, software-level input and output, code branch status, and data structures;

[0039] The third-level data is oriented to ground tests and is generated as needed; the content of the third-level data is all the data detected by the code execution probes.

[0040] In this embodiment, the transfer path of the test data is specifically as follows:

[0041] There are two transfer paths for the first-level data. One is transferred to the airborne or ground test platform via the test network, and the other is transferred to the airborne data storage device via the airborne network;

[0042] There is one transfer path for the second-level and third-level data, which is: transferred to the airborne or ground test platform via the test network.

[0043] Taking an airborne electronic system - an airborne information system as an example, the testability design method based on scenarios is further described as follows:

[0044] 1. Define the three-level data model of the test data (as shown in Figure 1 )

[0045] According to the three working scenarios of ground tests, flight tests, and aircraft operations, the test data is divided into three levels: first-level, second-level, and third-level.

[0046] First-level data: Oriented to the aircraft operation scenario, data is generated in real time, and the data content includes software access points, important code branch status, important data structures, etc.

[0047] In specific implementation, the data information of several key software related to flight operations in the airborne information system, including the data information of the avionics safety interface software, avionics data service software, and aircraft information security software, should be defined according to the requirements of the first-level data.

[0048] Second-level data: Oriented to flight tests and ground tests, data is generated as needed, and the data content includes equipment-level input and output, software-level input and output, code branch status, and data structures, etc.

[0049] In specific implementation, the input and output data of the airborne information system, the input and output, code branches, and data structures of each internal software, including software such as video surveillance, data loading, and flight parameter management, should be defined according to the requirements of the second-level data.

[0050] Tertiary data: For ground tests, data is generated as needed, and the data content is all the data detected by the code execution probes.

[0051] During specific implementation, software probes should be added to some software codes according to the test requirements, and the probe information should be defined according to the tertiary data.

[0052] 2. Transmission path of test data (as Figure 2 shown)

[0053] The DUT needs to provide a dedicated high-speed test interface for connecting the airborne or ground test network to facilitate the input and output of a large amount of test data.

[0054] The airborne information system should provide a 100-Mbps Ethernet interface for the dedicated high-speed test interface to connect to the test network.

[0055] There are two transmission paths for the primary data. One is transmitted to the airborne or ground test platform via the test network; the other is transmitted to the airborne data storage device via the airborne network. The transmission paths for the secondary and tertiary data are one, which are transmitted to the airborne or ground test platform via the test network.

[0056] On the one hand, the primary data of the airborne information system is transmitted to the airborne or ground test platform through a dedicated 100-Mbps Ethernet port; on the other hand, it is transmitted to the airborne mass storage device for storage through the airborne network (such as the AFDX network). The secondary and tertiary data of the airborne information system are transmitted to the airborne or ground test platform through a dedicated 100-Mbps Ethernet port.

[0057] 3. Deployment of test data control software (as Figure 3 shown)

[0058] A test data master control software resides in the test platform, and a data control agent resides in each device.

[0059] A test data master control software resides in the airborne or ground test platform, and a data control agent software resides in each electronic module of the airborne information system.

[0060] 4. Test data control method (as Figure 4 shown)

[0061] Each data control agent first controls the hierarchical data according to the static configuration, and then sends a communication request to the test data master control software. After obtaining communication authorization, it reads the data control command in real time and controls the transmission of different levels of data.

[0062] 1) When the numerical control control agents resident in each electronic module in the airborne information system are powered on and started, they read the internal configuration file to obtain the first, second, and third-level data model information, and then send a communication request to the test data master control software through a dedicated high-speed test interface.

[0063] 2) After receiving the request, if the test data master control software agrees, it will reply with authorization consent information.

[0064] 3) After receiving the authorization, each test data control agent requests a data control command from the test data master control software.

[0065] 4) The test data master control software issues a test data control command according to the test situation.

[0066] 5) Each test data control agent sends test data according to the received data control command.

[0067] 6) The test data master control software forwards the received test data to other applications for testing and storage.

[0068] As described above, it is only the specific implementation manner of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any changes or substitutions that can be easily thought of by those skilled in the art within the technical scope disclosed by the present disclosure should be covered by the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be subject to the protection scope of the claims.

Claims

1. A testability design method for scenario-based airborne electronic systems, characterized in that: The testability is realized based on a test data classification model, the transfer path of test data, the deployment of test data control software, and the test data control method, where: The test data classification model is used to classify test data into three levels according to three working scenarios of aircraft operation, flight test, and ground test: level 1 data, level 2 data, and level 3 data; The transfer path of the test data is configured as: different transfer paths are selected for the test data according to the available data bandwidth; the test data control software is deployed as: a test data master software resides in the test platform, and a data control agent resides in each device under test; The test data control method is: each data control agent first controls the test data according to the static configuration; then sends a communication request to the test data master software, and after obtaining communication authorization, reads the data control command in real time and controls the transmission of different levels of test data; Among them, the level 1 data faces the aircraft operation scenario, and the data is generated in real time; the data content of the level 1 data includes: software entrance and exit, important code branch status, and important data structures; The level 2 data faces flight tests and ground tests, and the data is generated as needed; the content of the level 2 data includes: device-level input and output, software-level input and output, code branch status, and data structures; The level 3 data faces ground tests, and the data is generated as needed; the content of the level 3 data is all the data detected by the code execution probe; The transfer path of the test data is specifically: There are two transfer paths for the level 1 data, one of which is transmitted to the airborne or ground test platform via the test network, and the other is transmitted to the airborne data storage device via the airborne network; There is one transfer path for the level 2 and level 3 data, which is: transmitted to the airborne or ground test platform via the test network.

Images