Method and device for testing flight management system software
By parsing the interface data structure of the flight management system software, generating test environment configuration files, and developing test engines and agent software, decoupled testing of core computing and display control functions is achieved, improving test accuracy and reducing costs. This method is applicable to various flight management system software architectures.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-03
- Publication Date
- 2026-03-24
AI Technical Summary
Existing technologies cannot effectively decouple the core computing and display control functions in the test flight management system software, resulting in insufficient test sufficiency, difficulty in ensuring the accuracy of computing and display precision, and excessively high requirements for the professional background of test engineers.
By progressively expanding and enumerating the interface data structures of the flight management system software, test stimulus header files and configuration files are generated. Combined with an external ICD, a test engine and agent software are developed to achieve decoupled testing of core computing and display control functions.
It improves the accuracy of core computing function testing, reduces the difficulty and cost of display control function testing, reduces the professional background requirements for test engineers, supports testing environments for both simulation and real target machines, and saves testing costs.
Smart Images
Figure CN121722673A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of aviation flight management system software testing, and specifically relates to a testing method and apparatus for flight management system software. Background Technology
[0002] The Flight Management System (FMS) is a crucial avionics system for aircraft flight management. It typically includes functions such as flight plan management, navigation database management, integrated navigation, flight guidance, performance prediction and optimization, data link application management, and human-machine interface management. The FMS interconnects with the display system and works in conjunction with the automatic flight control system to ensure the aircraft flies along an optimized path; it supports performance-based navigation operations, improving aircraft operational efficiency and reducing pilot workload.
[0003] Compared to other avionics systems, its distinguishing feature is that the functions of the flight management system are primarily implemented in software. The main functions of the flight management system can be divided into: core computational functions that handle complex mathematical calculations and software functionalities, and display control functions that handle complex display page control logic and human-machine interface management.
[0004] After years of development, flight management systems have several typical hardware and software-resident architectures for their core computing and display control functions: a) The core computing functions and display control functions reside on the same product's hardware, but on different partitions of the partitioned operating system. They communicate with each other through partitions, which will be referred to as "Architecture 1" below. b) The core computing and display control functions reside on different products and communicate through a bus between the two products (typically, they reside on the Flight Control Computer (FMC) and the Multifunction Control and Display Unit (MCDU), which will be referred to as "Architecture 2" below). c) The core computing functions and display control functions are integrated on the same product's hardware and reside in the same partition. The two communicate directly through memory data, which will be referred to as "Architecture 3" below.
[0005] Regardless of the dwell mode, the tight coupling between core computing functions and display control functions creates significant challenges for testing flight management system software. The results of core computing functions are generally not directly displayed as output; rather, they participate in the calculation of the next algorithm. After undergoing multiple complex calculations, only the data that is ultimately needed for display is output to the display interface.
[0006] When testing core calculation functions, especially when there is a discrepancy between calculation precision and display precision, it is impossible to simply judge the accuracy of intermediate calculation results based on the data displayed on the interface. Errors in the final displayed data are often caused by the accumulation of errors in intermediate calculation results. If the accuracy of each step of the calculation cannot be ensured, it is difficult to guarantee the correctness of the final displayed result. When testing the functionality of the display page, if a piece of data requires extremely complex calculations to obtain the result, it is necessary to reverse-engineer the input values of the test cases based on the requirements and algorithms. This poses a significant challenge to constructing test inputs for boundary tests and robustness tests. Even if the corresponding data can be constructed, the professional background requirements for software test engineers far exceed those of general test engineers.
[0007] Currently, there is a lack of effective testing methods for flight management system software, which can decouple the core computing and display control functions of the flight management system for testing to meet the requirements for sufficiency. Summary of the Invention
[0008] This invention provides a testing method and apparatus for flight management system software, which solves the problem that existing technologies cannot decouple the core computing and display control functions of the flight management system for testing, thus failing to meet the requirements for testing sufficiency.
[0009] The first aspect of this invention provides a method for testing flight management system software, comprising: S1. The structure of the interface data between the core computing function and display control function of the flight management system software is expanded layer by layer, and the enumeration type and macro definition are replaced to obtain the test stimulus header file. Combined with the external ICD, the test stimulus C file and the test environment interface configuration file are obtained. S2. Based on the test stimulus header file, test stimulus C file, and test environment interface configuration file, perform software testing on the core computing function software and display control function software of FMS software.
[0010] Optionally, the structure of the interface data between the core computing functions and display control functions of the FMS software is expanded layer by layer, and its enumeration type and macro definition are replaced to obtain the test stimulus header file, including: S11. Construct a structure named "Test Data" as the top-level data structure. The top-level data structure includes two members, "Input Data" and "Output Data", as the second-level data structure. S12. Identify the members of the input data structure of the function under test and fill them into the "Input Data" structure as members one by one; identify the members of the output data structure and fill them into the "Output Data" structure as members one by one. S13. Traverse all header files of the software under test and read out all data types related to "input data" and "output data"; S14. Starting from the structure of "test data", expand each member variable layer by layer, replace the enumeration type and macro definition until the member variable is expanded into the basic data type. S15. Fill all the expanded data types into the test stimulus header file.
[0011] Optionally, by combining with an external ICD, test stimulus point C files and test environment interface configuration files are obtained, including: Fill all the expanded data members and external ICDs into the test stimulus point C file and the test environment interface configuration file.
[0012] Optionally, the test environment interface configuration file includes all expanded data members and external ICDs, as well as their basic data types and data sizes; The test stimulus point C file includes the names of all expanded data members and external ICDs, the number of data elements, input / output flags, and basic data types; The names of the data are concatenated by parsing the names layer by layer from the expanded "Test Data" structure.
[0013] Optionally, the core computing and display control functions do not communicate directly through memory. When conducting software testing, the simulation test environment includes: the software under test, the test software engine, test cases, and the test framework. The testing framework is used to execute test cases according to the test environment interface configuration file. It requires the test engine software to assemble and send the test cases to the software under test, receive the data fed back by the software under test and unpack it, and generate a test report based on the unpacked data.
[0014] Optionally, the core computing functions and display control functions communicate directly through memory. When performing software testing, the simulation test environment includes: the software under test, the test agent software, the test software engine, test cases, and the test framework. The testing framework is used to execute test cases according to the test environment interface configuration file, requiring the test engine software package to be sent to the software under test through the test agent software; The test engine software is used to receive and unpack data from the software under test through the test agent software. The testing framework is also used to generate test reports based on the unpacked data.
[0015] Optionally, when performing software testing, the target machine testing environment includes: the software under test, the test agent software, the test equipment, the test software engine, the test cases, and the test framework; The testing framework is used to execute test cases according to the test environment interface configuration file, requiring the test engine software to package and send them to the test device; The testing equipment is used to send packaged data to the software under test (DUT) through the test agent software, receive feedback data from the DUT through the test agent software, send external data stimuli directly to the DUT and receive the corresponding feedback data directly, and send the feedback data back to the test engine software. The testing framework is also used to receive data unpacked from the testing engine software and generate test reports based on the unpacked data.
[0016] A second aspect of the present invention provides a testing apparatus for flight management system software, used to perform the testing method for flight management system software as described in any one of the first aspects.
[0017] A third aspect of the present invention provides a computer-readable storage medium, comprising: a memory and a processor; The memory is configured to store executable instructions; The processor is configured to implement a test method for flight management system software as described in any one of the first aspects when executing the executable instructions stored in the memory.
[0018] A fourth aspect of the present invention provides a computer program product comprising instructions that, when executed by a computer, implement a test method for flight management system software as described in any one of the first aspects.
[0019] This invention provides a testing method and apparatus for flight management system software. By automating the parsing of interfaces for core computing and display control functions, automatically generating test environment configuration files, and developing a test engine and test agent software, it achieves the goal of separately testing core computing and display control functions. This improves the accuracy of core computing function testing, eliminates the need to deduce the input values of display control function test cases from requirements and algorithms, reduces the difficulty of constructing test inputs for boundary and robust tests, thereby lowering the professional background requirements for display control function test engineers, reducing software testing costs, and improving the quality of flight management system software.
[0020] The testing method for flight management system (FMS) software described in this invention parses the interface between the core calculation and display control functions of the FMS software and generates a test environment configuration file based on the parsing results. This exposes the previously internal interfaces, allowing the core calculation and display control software of the FMS to be tested separately. Testing the core calculation software separately enables precise testing of each core calculation function without interference from display accuracy or logic, thus improving the accuracy of core calculation function testing. Testing the display control software separately eliminates the need to deduce the input values of display control function test cases from requirements and algorithms, reducing the difficulty of constructing test inputs for boundary and robustness tests. This lowers the professional background requirements for display control function test engineers and reduces software testing costs.
[0021] This invention can support testing in both simulation testing environments and real target machine testing environments. It allows test engineers to debug test cases in a simulation environment first, and then obtain real test results in a real target machine environment, saving the number of real target machines required and reducing testing costs.
[0022] This invention supports three mainstream and common flight control software architectures and is applicable to the testing requirements of various flight control software. Attached Figure Description
[0023] 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. 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.
[0024] Figure 1 This is a schematic diagram illustrating the interface resolution process between flight control software functions in the scheme. Figure 2 This is a schematic diagram of the test engine software functionality in the solution. Figure 3 This is the typical FMS software architecture (Architecture 1) described in the solution. Figure 4 This is the typical FMS software architecture (Architecture 2) described in the solution. Figure 5 This is the typical FMS software architecture (Architecture 3) described in the solution. Figure 6 This is a schematic diagram of the simulation test environment for the core computing functions of the flight control system in "Architecture 1" and "Architecture 2" of the scheme. Figure 7This is a schematic diagram of the simulation test environment for the flight control display function software of "Architecture 1" and "Architecture 2" in the scheme; Figure 8 This is a schematic diagram of the target aircraft test environment for the core computing function software of the flight control system in "Architecture 1" of the scheme. Figure 9 This is a schematic diagram of the target aircraft test environment for the flight control display function software of "Architecture 1" in the scheme; Figure 10 This is a schematic diagram of the target aircraft test environment for the core computing function software of the flight control system in "Architecture 2" of the scheme. Figure 11 This is a schematic diagram of the target aircraft test environment for the flight control display function software of "Architecture 2" in the scheme; Figure 12 This is a schematic diagram of the simulation test environment for the core computing function software of the "Architecture 3" flight control system in the scheme. Figure 13 This is a schematic diagram of the simulation test environment for the flight control display function software of "Architecture 3" in the scheme; Figure 14 This is a schematic diagram of the target aircraft test environment for the core computing function software of the "Architecture 3" flight control system in the scheme. Figure 15 This is a schematic diagram of the target aircraft test environment for the flight control display function software of "Architecture 3" in the scheme. Detailed Implementation
[0025] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0026] The features and illustrative embodiments of various aspects of the present invention will now be described in detail. Numerous specific details are set forth in the following detailed description to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention may be practiced without requiring some of these specific details. The following description of embodiments is merely intended to provide a better understanding of the invention by illustrating examples of the invention. The invention is by no means limited to any specific setups and methods set forth below, but covers any improvements, substitutions, and modifications to structures, methods, and devices without departing from the spirit of the invention. Well-known structures and techniques are not shown in the drawings and the following description to avoid unnecessarily obscuring the invention.
[0027] In the description of this invention, it should be noted that the directions or positional relationships indicated by terms such as "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer" are based on the directions or positional relationships shown in the accompanying drawings and are only for the convenience of describing and simplifying the invention, and should not be construed as limiting the invention. Furthermore, the use of ordinal numbers (e.g., "first and second," etc.) is for distinguishing objects and is not limited to this order, and should not be construed as indicating or implying relative importance.
[0028] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly, encompassing both direct connection and indirect connection via an intermediate medium. Those skilled in the art can understand the specific meaning of these terms in this invention based on the specific circumstances.
[0029] It should be noted that, unless otherwise specified, the embodiments of the present invention and the features thereof can be combined with each other, and the various embodiments can be referenced and cited in each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.
[0030] The present invention will be further described in detail below with reference to the embodiments and accompanying drawings, but the embodiments of the present invention are not limited thereto.
[0031] The testing method for flight management system software described in this invention parses the interface between the core computing and display control functions of the FMS software, and generates a test environment configuration file based on the parsing results, so that the originally internal interfaces can be exposed to the outside. Then, by developing test engine software and test agent software for the characteristics of three typical FMS software architectures, the test stimulus and monitoring of the software under test are realized to obtain test output.
[0032] Includes the following processes: 1) Analysis of interfaces between functions in flight control software The interface data between the core computing and display control functions of FMS software, although generally defined in internal ICD files, is a document rather than code and cannot usually be directly used for setting up a test environment. Typically, interface data between functions in flight control software is defined through structures. These structures may contain one or more complex configurations, such as nested structures, unions containing structures, definitions of bit fields and alignment, structures containing arrays, enumerations, or macros. Software test input and output data are generally basic data types (integer, character, floating-point, etc.), therefore, each piece of data needs to be parsed individually. This involves parsing and expanding structures layer by layer, replacing enumerations and macros, to obtain a list of interfaces between software functions composed of basic data types.
[0033] 2) Generate test environment configuration file Both the core computing functions and display control functions of the FMS software have internal interfaces for sending and receiving data, as well as external interfaces. It is necessary to combine the list of interfaces between software functions with the external ICD and automatically generate the test environment configuration file based on the test environment configuration file template, including: test environment interface configuration file and test stimulus point file.
[0034] 3) Test engine software development The test engine software acts as a bridge connecting test cases and the software under test. Located on the test case side, its specific functions include receiving and sending external data according to the period specified by ICD, traversing the test stimulus points in the test stimulus point file, checking whether there are any changes in the test stimulus data, sending input data to the software under test side when the test stimulus data changes, and receiving output data from the software under test side at other times.
[0035] To ensure that test cases can be executed in both simulation testing environments and real target machine testing environments, the test engine software needs to be adapted for FMS software under different architectures.
[0036] 4) Test agent software development The test agent software also acts as a bridge connecting test cases and the software under test (DUT), residing on the DUT's side. In the simulation test environment, no test agent software needs to be developed for "Architecture 1" and "Architecture 2," while "Architecture 3" does. In the target machine test environment, the test agent software can reside in a separate partition of the operating system in "Architecture 1," reside in a separate product within "Architecture 2," or run integrated with the DUT in "Architecture 3." The test agent software receives and sends external data according to the software's cycle. When it receives test input data from the test engine software, it transmits the test input data to the DUT; otherwise, it sends output data to the test engine software.
[0037] For example, the interface parsing and file generation between flight control software functions includes the following steps: 1) The interface data between the core computing function and the display control function of the FMS software needs to be distinguished according to the function being tested. When testing the core computing function, the data sent by the display control function to the core computing function is the input data, and vice versa, it is the output data. 2) For external data of FMS software, it is necessary to distinguish them according to the function being tested. Input and output data directly used for core computing functions should be included in the test environment of core computing functions, and input and output data directly used for display and control functions should be included in the test environment of display and control functions. 3) Construct a structure named "Test Data" as the top-level data structure. This top-level structure contains only two members: "Input Data" and "Output Data". The "Input Data" member serves as the second-level data structure. The input data from step 1) is identified and populated into the "Input Data" structure as its members. The "Output Data" member is processed similarly. After completing this step, you will obtain the top-level structure of all the input and output data required for the test environment. 4) Traverse all header files of the software under test and read out all data types (including structure definitions, union definitions, macro definitions, etc.) related to "input data" and "output data"; 5) Starting from the "test data" structure, expand each member variable layer by layer until the member variable is expanded into the basic data type (i.e., integer, floating-point, character, etc.). 6) Combine all the expanded data types with the top-level "Test Data" structure definition and fill them into the test stimulus header file and test environment configuration file.
[0038] The test environment configuration file includes a test environment interface configuration file and test stimulus point C files. The test environment interface configuration file specifies the names, data types, and sizes of all input and output data that can be used in test cases. The test stimulus point C files correspond one-to-one with the data in the test environment interface configuration file and are used for the development and use of the test engine software. The test stimulus point C files include the names, number of data elements, input / output flags, and data types of all input and output data that can be used in test cases.
[0039] For the test environment configuration file, the data name is concatenated by the names parsed layer by layer from the "test data" structure obtained by the interface, for example: [test data].[input data].[flight plan data].[departure airport data].[departure airport name].
[0040] Based on the clearly defined rules and required format, the above test environment configuration file can be automatically generated according to the results of the interface parsing between flight control software functions.
[0041] In the test environment of the flight management system software, test cases are executed in the corresponding test framework tool. All allowed input data and checked output data in the test cases are defined in the test environment interface configuration file. The test framework tool sends the actual input and checked data in the test cases to the test engine software according to the test environment interface configuration file.
[0042] The test engine software requires compiling and building the program together with the test stimulus header files and data stimulus C files. The test engine software acts as a bridge connecting test cases and the software under test, located on the test case side. The workflow of the test engine software is as follows: 1) The test engine software cycle begins; 2) Processing input data: a) Iterate through the list of test stimuli and check each one to see if the input data has changed; b) If the input data changes, set the input data update flag to true and copy the changed data to the buffer; c) If the input data update flag is true, the input data in the buffer is packetized and sent out of the test engine software. The protocol used for packetization depends on the different FMS software architecture; no output data is processed in the current cycle. 3) Process the output data: If the input data update flag is not true, it means that the input data has not changed in this cycle. Then, the address and offset information of all output data in the test stimulus point list are filled into the request output data packet, and the request is sent to the software under test. Once the output data returned by the software under test is received, the software output data can be resolved at the corresponding address. 4) The test engine software cycle ends and the next cycle begins.
[0043] Test agent software development includes: 1) Test agent software in a simulation environment In both "Architecture 1" and "Architecture 2," both the flight control core computing software and the flight control display and control software reside in relatively independent areas. In "Architecture 1," the two software programs communicate through an area-specific communication interface, while in "Architecture 2," they communicate through a certain inter-product bus. In the simulation environment, by rewriting the communication interface, data can be sent directly from the test engine to the software under test, thus eliminating the need for test proxy software to relay input and output data.
[0044] For "Architecture 3," since the core computing software and display / control software of the flight control system are integrated and transmit data via memory, data cannot be directly transferred to the software under test (DUT) through the test engine. Therefore, test proxy software needs to be developed to relay the data. When testing the core computing software, the test proxy software replaces the display / control software; conversely, when testing the display / control software, the test proxy software replaces the core computing software. The test proxy software transmits data to the DUT via memory through data exchange with the test engine software.
[0045] 2) Test agent software in a real target machine environment In a real target aircraft environment, for both "Architecture 1" and "Architecture 2," the flight control core calculation software and the flight control display and control software need to communicate with each other via the target aircraft. Since the test engine software, running on a PC, cannot communicate directly with the target aircraft, test proxy software needs to be developed to relay data for both "Architecture 1" and "Architecture 2." For the target aircraft test environment of "Architecture 3," the test proxy software can reuse the test proxy software from the corresponding simulation environment.
[0046] Regardless of the architecture, the operating principle of the test proxy software is the same: when testing the core computing function software of the flight controller, the test proxy software replaces the display and control function software of the flight controller; when testing the display and control function software of the flight controller, the test proxy software replaces the core computing function software of the flight controller. The test proxy software transmits data to the software under test via memory through data exchange with the test engine software.
[0047] For example, in a specific embodiment, the interface parsing between flight control software functions includes: See the schematic diagram for the interface analysis between functions in the flight control software. Figure 1 .
[0048] 1) Construction of the "Test Data" structure typedef struct { Data_In_TypedataIn; Data_Out_Type dataOut; Data_Type; typedef struct { intDispatchMsgEmit; intoprDataIdx; intDB_DataID; DSPTCH_Msg_TypeDispatch_Message; Data_In_Type; typedef struct { OPR_IF_FlMonDataPoolFlMonDataPoolAll; DB_NAVDB_IF_SrchRstDataPoolTypeSrchRstDataPool; DB_LGT_MGR_SrchResultTypeLgtResultData; Data_Out_Type; 2) Test incentive header file template After traversing, expanding, and parsing the interfaces between functions of the flight control software, the results will be filled into the following template, and a test stimulus header file will be obtained.
[0049] DataTypestr = '''#pragma pack($pack) typedef struct { #for $I in range(len($TypeList)): #if $flag_array[$I]: #set $tempStr = '' #for $J in range(len($ArrayLength[$I])): #set $tempStr= $tempStr + '[' + str($ArrayLength[$I][$J]) + ']' #end for #if $basic_type[$I]: $TypeList[$I] ${NameList[$I]}${tempStr}; #else: ${TypeList[$I]}_ ${NameList[$I]}${tempStr}; #end if #else: #if $basic_type[$I]: $TypeList[$I] ${NameList[$I]}; #else: ${TypeList[$I]}_ ${NameList[$I]}; #end if #end if #end for } ${TypeName}; #pragma pack()''' The obtained test stimulus header file fragment is as follows: The top layer is Data_Type: #pragma pack(1) typedef struct { Data_In_Type dataIn; Data_Out_Type dataOut; } Data_Type; #pragma pack() The first layer is Data_In_Type: #pragma pack(1) typedef struct { int DispatchMsgEmit; int oprDataIdx; int DB_DataID; DSPTCH_Msg_Type Dispatch_Message; } Data_In_Type; #pragma pack() The second layer is DSPTCH_Msg_Type: #pragma pack(1) typedef struct { unsigned char Msg_Src; unsigned char spare; unsigned short int Msg_Length; DSPTCH_Msg_Payload_Type Msg_Payload; } DSPTCH_Msg_Type; [[ID=<<MASK>>]]#pragma pack() The third layer is DSPTCH_Msg_Payload_Type: #pragma pack(1) typedef struct { unsigned char UChar_Array
[2048] ; FMSPage_Request_To_FMS_Type FMS_Request_View; } DSPTCH_Msg_Payload_Type; #pragma pack() ... Follow the examples layer by layer until you can't expand any further.
[0050] For example, in one specific embodiment, generating the test environment configuration file includes: The test environment configuration file includes the test environment interface configuration file and the test stimulus point C file.
[0051] (1) Template for test environment interface configuration file FMS__config = '''#for $I in range(len($ElementList)): #if $ElementList[$I].ArrayLength==1: POINT $ElementList[$I].ElementName.replace('[','__').replace(']','__') = { ... DATATYPE = "$ElementList[$I].Config_EleType"; DATASIZE = "$ElementList[$I].Config_Datasize"; ELEMENTS = "$ElementList[$I].ArrayLength"; VARLENGTH = "$ElementList[$I].Config_Varlength"; ... } #else: POINT $ElementList[$I].ElementName.replace('[','__').replace(']','__') = { ... DATATYPE = "$ElementList[$I].Config_EleType"; DATASIZE = "$ElementList[$I].Config_Datasize"; ELEMENTS = "$ElementList[$I].ArrayLength"; VARLENGTH = "$ElementList[$I].Config_Varlength"; …… } #end if #end for (2)Test excitation point C file template struct pointlist points[]= { #for $I in range(len($ElementList)): #if $ElementList[$I].ArrayLength==1: #if $ElementList[$I].ElementName.find('.dataIn.')!=-1: {"$APPName::$ElementList[$I].ElementName.replace('[','__').replace(']','__')",&$ElementList[$I].ElementName, 1 * $ElementList[$I].Length, 0,{0,0}, {0,0}, $ElementList[$I].pointlistType}, #end if #if $ElementList[$I].ElementName.find('.dataOut.')!=-1: {"$APPName::$ElementList[$I].ElementName.replace('[','__').replace(']','__')",&$ElementList[$I].ElementName, 1 * $ElementList[$I].Length, 1,{0,0}, {0,0}, $ElementList[$I].pointlistType}, #end if #else: #if $ElementList[$I].ElementName.find('.dataIn.')!=-1: {"$APPName::$ElementList[$I].ElementName.replace('[','__').replace(']','__')",&$ElementList[$I].ElementName, $ElementList[$I].ArrayLength * $ElementList[$I].ArrayLength, 0, {0,0}, {0,0}, $ElementList[$I].pointlistType}, #end if #if $ElementList[$I].ElementName.find('.dataOut.')!=-1: {"$APPName::$ElementList[$I].ElementName.replace('[','__').replace(']','__')",&$ElementList[$I].ElementName, $ElementList[$I].ArrayLength * $ElementList[$I].ArrayLength, 1, {0,0}, {0,0}, $ElementList[$I].pointlistType}, #end if #end if #end for The test excitation point C file generated according to the template is as follows: struct pointlist points[] = { {"FMS::Data.dataIn.DispatchMsgEmit",&Data.dataIn.DispatchMsgEmit, 1 *4, 0, {0,0}, {0,0}, 256}, {"FMS::Data.dataIn.oprDataIdx",&Data.dataIn.oprDataIdx, 1 * 4, 0, {0,0}, {0,0}, 256}, {"FMS::Data.dataIn.DB_DataID",&Data.dataIn.DB_DataID, 1 * 4, 0, {0,0}, {0,0}, 256}, {"FMS::Data.dataIn.Dispatch_Message.Msg_Src",&Data.dataIn.Dispatch_Message.Msg_Src, 1 * 1, 0, {0,0}, {0,0}, 2}, {"FMS::Data.dataIn.Dispatch_Message.Msg_Payload.FMS_Request_View.Req_Msg_Num",&Data.dataIn.Dispatch_Message.Msg_Payload.FMS_Request_View.Req_Msg_Num, 1 * 1, 0, {0,0}, {0,0}, 2}, ... Each incentive point corresponds one-to-one with the test environment interface configuration file.
[0052] For example, test engine software development includes: See the functional principle diagram of the test engine software. Figure 2 For the three common FMS software architectures, see [link to relevant documentation]. Figures 3-5 For schematic diagrams of the simulation test environment and the real target machine test environment under each FMS software architecture, please refer to... Figures 6-15 .
[0053] The pseudocode for the main loop function of the test engine software is as follows: WHILE(1) { InputUpdateFlag = GetUpdateInputData(inputBuffer, length) if (InputUpdateFlag == TRUE) { SendInputData(inputBuffer, length) } else { AskOutputData() } Return_Value = ReceiveRespMessage(outputBuffer, length) if (Return_Value == TRUE) { GetOutputData(outputBuffer, length) } } For example, test agent software development includes: For schematic diagrams of the test agent software in the simulation test environment and the real target machine test environment under each FMS software architecture, please refer to... Figures 8-15 .
[0054] The test agent software operates as follows: when testing the core calculation function software of the flight controller, the test agent software replaces the flight controller display and control function software; conversely, when testing the flight controller display and control function software, the test agent software replaces the core calculation function software. The test agent software transmits data to the software under test via memory through data exchange with the test engine software. For details regarding the resident location of the test agent software under different FMS software architectures, its communication methods with the software under test, and its communication methods with the test engine software, please refer to [link to relevant documentation]. Figures 8-15 The explanation in the document.
[0055] The above detailed embodiments are a description of the present invention. It should not be considered that the specific embodiments of the present invention are limited to these descriptions. For those skilled in the art, several simple deductions and substitutions can be made without departing from the concept of the present invention, and all of these should be considered to fall within the protection scope of the present invention.
Claims
1. A testing method for flight management system software, characterized in that, include: S1. The structure of the interface data between the core computing function and display control function of the flight management system software is expanded layer by layer, and the enumeration type and macro definition are replaced to obtain the test stimulus header file. Combined with the external ICD, the test stimulus C file and the test environment interface configuration file are obtained. S2. Based on the test stimulus header file, test stimulus C file, and test environment interface configuration file, perform software testing on the core computing function software and display control function software of FMS software.
2. The testing method for flight management system software according to claim 1, characterized in that, The structure of the interface data between the core computing functions and display control functions of the FMS software is expanded layer by layer, and its enumeration type and macro definition are replaced to obtain the test stimulus header file, including: S11. Construct a structure named "Test Data" as the top-level data structure. The top-level data structure includes two members, "Input Data" and "Output Data", as the second-level data structure. S12. Identify the members of the input data structure of the function under test and fill them one by one into the "Input Data" structure as its members; identify the members of the output data structure and fill them one by one into the "Output Data" structure as its members. S13. Traverse all header files of the software under test and read out all data types related to "input data" and "output data"; S14. Starting from the "test data" structure, expand each member variable layer by layer, replace the enumeration type and macro definition until the member variable is expanded into the basic data type; S15. Fill all the expanded data types into the test stimulus header file.
3. The testing method for flight management system software according to claim 2, characterized in that, By combining with an external ICD, the test stimulus point C file and the test environment interface configuration file are obtained, including: Fill all the expanded data members and external ICDs into the test stimulus point C file and the test environment interface configuration file.
4. The testing method for flight management system software according to claim 3, characterized in that, The test environment interface configuration file includes all expanded data members and external ICDs, as well as their basic data types and data sizes; The test stimulus point C file includes the names of all expanded data members and external ICDs, the number of data elements, input / output flags, and basic data types; The data names are constructed by piecing together the names parsed layer by layer from the expanded "Test Data" structure.
5. The testing method for flight management system software according to claim 1, characterized in that, The core computing and display control functions do not communicate directly through memory. When conducting software testing, the simulation test environment includes: the software under test, the test software engine, test cases, and the test framework. The testing framework is used to execute test cases according to the test environment interface configuration file. It requires the test engine software to assemble and send the test cases to the software under test, receive the data fed back by the software under test and unpack it, and generate a test report based on the unpacked data.
6. The testing method for flight management system software according to claim 1, characterized in that, The core computing and display control functions communicate directly through memory. During software testing, the simulation test environment includes: the software under test, the test agent software, the test software engine, test cases, and the test framework. The testing framework is used to execute test cases according to the test environment interface configuration file, requiring the test engine software package to be sent to the software under test through the test agent software; The test engine software is used to receive and unpack data from the software under test through the test agent software. The testing framework is also used to generate test reports based on the unpacked data.
7. The testing method for flight management system software according to claim 1, characterized in that, When conducting software testing, the target machine testing environment includes: the software under test, the test agent software, the test equipment, the test software engine, the test cases, and the test framework; The testing framework is used to execute test cases according to the test environment interface configuration file, requiring the test engine software to package and send them to the test device; The testing equipment is used to send packaged data to the software under test (DUT) through the test agent software, receive feedback data from the DUT through the test agent software, send external data stimuli directly to the DUT and receive the corresponding feedback data directly, and send the feedback data back to the test engine software. The testing framework is also used to receive data unpacked from the testing engine software and generate test reports based on the unpacked data.
8. A testing device for flight management system software, characterized in that, Test method for performing flight management system software as described in any one of claims 1-7.
9. A computer-readable storage medium, characterized in that, include: Memory and processor; The memory is configured to store executable instructions; The processor is configured to implement the test method of the flight management system software as described in any one of claims 1-7 when executing the executable instructions stored in the memory.
10. A computer program product, characterized in that, The computer program product includes instructions that, when executed by a computer, implement the test method for the flight management system software as described in any one of claims 1-7.