ACAS X software standard compliance verification method based on DO385 test case set

Abstract

The present invention discloses a method for verifying the standard compliance of ACAS X software based on the DO385 test case set, and the steps include: generating a test sequence table according to 7 groups of 422 test cases specified by DO385 through software programming, and supporting implementation in multiple programming languages; running ACAS X software, and generating TRM, STM and COST result files with the test sequence table case as input; comparing the result file with the standard result file provided by DO385 through computer software programming, recording the variables and errors that do not meet the tolerance requirements, and updating the test sequence table according to the comparison results; correcting the ACAS X software for the failed case, and iterating the test until all 422 test cases pass; the standard compliance can also be compared in batches and intuitively using automatic folder comparison software. The present invention provides a systematic and optimized test process by setting and updating the test sequence table, which is iterative, and the implementation method has both flexibility and versatility, and provides an effective method for verifying the standard compliance of ACAS X software.

Description

Technical Field

[0001] The present invention relates to the technical field of a new generation collision avoidance system ACAS X, and more specifically, to a method for verifying the compliance of ACAS X software standards based on a DO385 test case set. Background Art

[0002] Aviation flight safety has always been the core topic of concern in the aviation industry. With the continuous increase in military and civil aviation traffic around the world, the number and density of aircraft in the airspace are increasing, and the potential risk of mid-air collision accidents is also increasing accordingly. In this context, it is urgent to improve the situational awareness and collision avoidance capabilities of aircraft in the air.

[0003] Air traffic alert and collision avoidance systems have been mandatory worldwide, and long-term practice has proven that they are a key means of preventing mid-air aircraft collisions. However, the widely used TCAS II collision avoidance system has many limitations. Its collision avoidance logic unit is based on complex heuristic rules and a series of processes, which makes system upgrades and design improvements extremely difficult. The verification cycle is long and costly, and it is difficult to adapt to the challenges brought about by the ever-changing modern flight environment. For example, it has poor applicability in specific flight scenarios, cannot be effectively adapted to diverse aircraft such as drones, and there are also false alarm problems frequently reported by pilots.

[0004] In order to effectively overcome these drawbacks and shortcomings of the TCAS II system, the International Civil Aviation Organization (ICAO) and the Federal Aviation Administration (FAA) of the United States jointly promoted the development of a new generation of airborne collision avoidance system ACAS X. The collision avoidance unit of ACAS X adopts an innovative design concept, which models the scenario of aircraft mid-air collision encounters as a Markov decision process, and uses a dynamic programming-based method to solve the model, thereby generating a series of collision avoidance logic tables. Based on these logic tables, the collision avoidance logic based on rule heuristics of TCASII is transformed into a digital lookup table logic based on probability and cost value, and the cost value is used to screen and determine the optimal collision avoidance decision suggestion.

[0005] As the international general technical standard for ACAS X, the new generation of collision avoidance system minimum operating performance standard DO385 clearly stipulates that the collision avoidance processing logic covers two core functions: surveillance and tracking module (hereinafter referred to as STM) and traffic decision module (hereinafter referred to as TRM). Among them, STM is responsible for realizing accurate monitoring and tracking of target aircraft and the aircraft in the airspace; TRM is based on the data output by the former, combined with the table lookup method and the substitution value to complete the collision threat detection and collision avoidance warning functions. At the same time, the standard emphasizes that after the collision avoidance logic design is implemented, the test verification work must be carried out strictly in accordance with the prescribed test case set.

[0006] Specifically, this test case set covers 7 groups with a total of 422 test cases, and each test case contains 4 types of JSON files. JSON (JavaScriptObjectNotation) is a commonly used data exchange format file with the suffix .json. It has the characteristics of clearly representing objects and arrays in concise text form, which is not only convenient for humans to read and write, but also easy for machines to parse and generate operations, providing a convenient basis for the organization and transmission of test data.

[0007] Furthermore, each test case in the test case set consists of a test scenario input file and three standardized test result files output by the anti-collision logic operation. In the actual verification process, the ACAS X software must first accurately read and parse the input data in the test scenario input file, and then the ACAS X software runs STM and TRM to generate the corresponding three types of output files; finally, the three types of output files are carefully compared with the result files provided as normative appendixes of the standard. Only when all variables in all output files meet the tolerance requirements specified in the DO385 standard can the test scenario be judged to have passed the test; otherwise, if any variable exceeds the tolerance range, the test scenario test is deemed to have failed. In addition, only when the ACAS X software runs the complete test case set and all test cases are verified, can the design implementation of the ACAS X software be judged to have passed the standard compliance verification; as long as any test case fails, it means that the ACASX software does not meet the standard requirements. For the grouping information of the test case set files and the detailed information of the four files of each test case, please refer to Tables 1 and 2.

[0008] Table 1 Test case set information table

[0009]

[0010] Table 2 Test case file information table

[0011]

[0012] The test case sets and the 1,688 JSON files corresponding to the specific test scenarios mentioned in Tables 1 and 2 are the normative annexes of the general technical standard DO385 specified by the International Civil Aviation Organization (ICAO) and the Federal Aviation Administration (FAA) of the United States. Equipment manufacturers must use these files in strict accordance with this requirement when performing standard compliance verification after the implementation of collision avoidance logic.

[0013] Deficiencies and defects of existing technology:

[0014] At present, from the perspective of publicly available technical data, there is no ACAS X software test verification method based on the DO385 test case set (including 1688 files). At the same time, various existing verification methods related to collision avoidance systems generally have deficiencies and disadvantages to varying degrees. Without innovative design, these existing technologies cannot meet the actual needs of conducting fast and efficient verification work based on the DO385 test case set, as shown below:

[0015] A method for verifying the standard compliance of a TCAS II collision avoidance algorithm (patent number: CN102736977B). This invention patent was disclosed earlier and is a verification method based on a traditional TCAS II system. Its operation process requires reading test files and running tests one by one. It has no systematic design and lacks a mechanism for overall optimization and iterative update of the overall test process. The method of reading and testing one by one will inevitably lead to a large amount of basic testing work having to be repeated after each software update. This method does not involve system processes and lacks automatic iterative design of test cases, and has significant defects.

[0016] Although a method and system for verifying and testing an aircraft collision avoidance algorithm (patent number: CN106997693B) involves the field of aircraft collision avoidance algorithm verification, the method is established and the test is completed for a cylindrical safety domain. The application scenarios and the problems to be solved are different. It does not involve the large-scale (422) test cases specified in the DO385 standard, and does not provide an effective batch processing method and supporting technical solutions based on this. The method relies on manually starting test cases one by one, which is not only time-consuming and labor-intensive, but also very likely to have an adverse effect on the accuracy of the test results due to human operational errors.

[0017] A method and system for generating, converting and verifying the standardization of standard use cases for actual flight scenarios of a TCAS II airborne collision avoidance system (patent number: CN109032950B) is also a traditional TCAS II system. It mainly solves the conversion problem of generating standard use cases based on actual flight scenarios, and does not involve the verification problem of the ACAS X software based on the DO385 test case set that the present invention is committed to solving. Furthermore, the test method after the use case conversion itself lacks the key function of dynamically adjusting the test case sequence table according to the test results, so it cannot effectively avoid a large amount of repeated work in the iterative test process. The manual maintenance of test cases may also cause misoperation, which has a negative impact on the accuracy and efficiency of the verification work.

[0018] In summary, after the design and development of the new generation collision avoidance system ACAS X software is completed and it enters the standard compliance verification stage, an ACAS X software test and verification method based on the DO385 test case set (422 test cases, 1688 files) is urgently needed. This method must first be designed according to the composition of the DO385 test case set. Then, it should overcome the shortcomings and defects of the existing technology in terms of process, efficiency, flexibility, iterative testing, etc., and provide a systematic and process-based method that can iteratively and batch process files, and can flexibly update test cases according to test results, so as to provide an efficient, flexible and convenient standard compliance method for ACAS X software design, development, maintenance and upgrade. Summary of the invention

[0019] The purpose of the present invention is to overcome the above-mentioned shortcomings of the prior art, and to provide an ACAS X software standard compliance verification method based on the DO385 test case set. Through reasonable process design and software programming to implement relevant operations, the present invention can process test cases in batches, flexibly update the test case sequence table according to the test results, and realize efficient, accurate and iterative software standard compliance verification, thereby solving the problems of low efficiency, lack of process and flexibility, and inability to automatically iterate in the verification process of the prior art.

[0020] To achieve the above object, the present invention provides an ACAS X software standard compliance verification method based on the DO385 test case set, comprising the following steps:

[0021] S1: Test sequence table generation step: Generate a test sequence table by software programming, the test sequence table is a list of serial numbers of all test cases (7 groups of 422) specified by DO385. When the test sequence table is specifically implemented, it includes 7 groups, which is a two-dimensional table composed of 7 arrays of unequal lengths. When the two-dimensional table is implemented by programming in Julia language, it is implemented by defining a two-dimensional array; when the two-dimensional structure is implemented by Python language, a list of lists (listoflists) is used to represent a two-dimensional table composed of 7 arrays of unequal lengths, and each sublist can have a different length; when the two-dimensional structure is implemented by C language, a pointer array is used to represent a two-dimensional table composed of 7 arrays of unequal lengths. Constructing the test sequence table in this multi-language implementable way lays the foundation for the subsequent batch processing of test cases, so that test preparation work can be effectively carried out in different programming habits and development environments.

[0022] S2: Test case running and result file generation step: Run the test case corresponding to the test case number in the test sequence table at one time through software programming, and generate corresponding result files for the variables of TRM, STM and COST generated during the running process, respectively. The TRM, STM and COST are respectively the threat decision module, monitoring and tracking module and cost value specified in DO385, and the cost value is a series of cost values ​​related to collision avoidance maneuvering flight. Running multiple test cases at one time can significantly improve the test efficiency, avoid the time-consuming problem caused by running test cases one by one as in the prior art, and generate result files for the variables corresponding to the key modules, which is convenient for subsequent standard compliance comparison.

[0023] S3: Result file comparison step: Compare the TRM, STM and COST result files with the DO385 standard result files one by one by computer software programming, including the following sub-steps:

[0024] S31: TRM result file comparison sub-step: read the TRM result file and the standard TRM result file, and compare the data in the two files in turn according to the variable name to see if they meet the tolerance requirements. If there are variables that do not meet the tolerance requirements, record their variable names, variable values, and errors in detail and store them as TRM error files. In this way, the specific situations that do not meet the standards in the TRM module can be accurately located, which is convenient for subsequent analysis and correction;

[0025] S32: STM result file comparison sub-step: read the STM result file and the standard STM result file with the same logic, and compare the data one by one by variable name to see if they meet the tolerance requirements. For variables that do not meet the requirements, record the relevant information and store it as an STM error file, which helps to focus on the deviations in the STM module and provide a reference for STM update optimization;

[0026] S33: COST result file comparison sub-step: Read the COST result file and the standard COST result file, and check the data tolerance one by one according to the variable name. If the variable does not meet the requirements, record the corresponding information and store it as a COST error file to facilitate troubleshooting of cost value-related issues. Only when all variables in the result file meet the tolerance requirements, the corresponding test case is judged as passed; otherwise, it is judged as a test failure. This detailed comparison step enhances the accuracy and traceability of the comparison.

[0027] S4: Test sequence table update step: Update the test sequence table by deleting the serial number of the successfully tested test case from the test sequence table. Through such a dynamic update mechanism, the subsequent test iteration process can focus on the failed test cases, avoiding repeated operations on the test cases that have passed the verification, effectively optimizing the entire test process and improving the efficiency of iterative testing.

[0028] S5: Software correction and repeat test step: Correct the ACAS X software for the test cases that failed the test, and then repeat steps S2, S3 and S4 until the test sequence table is cleared. This step ensures that the software can be continuously optimized and improved according to the test feedback, so that the software gradually meets the standard requirements.

[0029] S6: Overall verification step: Repeat steps S1, S2, S3, S4 and S5 until all (422 in total) test cases in step S3 are passed, and the ACAS X software has passed the standard compliance verification. By iterating the above steps multiple times, it is ensured that the software fully and strictly complies with all test case requirements specified in the DO385 standard, achieving complete and reliable standard compliance verification.

[0030] Furthermore, the TRM, STM and COST result files are compared with the DO385 standard result files in sequence, and the specific implementation method is to use automatic folder comparison software to compare the files stored in two folders, one of which stores the TRM, STM and COST result files, and the other stores the DO385 standard result files. The purpose of using automatic folder comparison software is to more intuitively confirm the consistency of the software operation results with the standards from a global and overall perspective, so as to facilitate unified management and viewing of comparison results.

[0031] Beneficial effects of the present invention: The ACAS X software standard compliance verification method based on the DO385 test case set of the present invention provides beneficial technical effects in many aspects. In terms of test efficiency, batch processing and automated comparison are used to greatly shorten the test time and improve the overall efficiency of each link; in terms of test accuracy, human errors are reduced with the help of software programming and automatic folder comparison, and compliance can be intuitively confirmed; in terms of test process and iteration, the test sequence table is dynamically updated to make the process more reasonable and efficient; it can adapt to multiple languages ​​and multiple development environments, and improve flexibility and versatility. In short, the method overcomes existing deficiencies, provides an efficient, accurate, iterative and flexible solution for ACAS X software verification, can support the entire process of ACAS X software design and development, and assist ACAS X engineering applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the implementation mode will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0033] Attached Figure 1 The figure is a flow chart of the ACAS X software standard compliance verification method based on the DO385 test case set of the present invention. DETAILED DESCRIPTION

[0034] The following is combined with the appended claims of the present invention Figure 1 The implementation method of the ACAS X software standard compliance verification method based on the DO385 test case set of the present invention is described in detail so that those skilled in the art can better understand and implement the present invention; it should be emphasized that the specific implementation method provided is only a feasible example given to facilitate the understanding of the present invention. In actual application scenarios, professionals in this field can obtain many other implementation methods without paying creative work, and these implementation methods should also be included in the scope of protection of the present invention.

[0035] Attached Figure 1 The following steps are included.

[0036] Generate test case sequence (S1): First, generate a test case sequence for testing the ACAS X software.

[0037] Run the software and generate result files (S2): Take each test case in the test case sequence as input, run the ACAS software, and generate corresponding result files for TRM, STM and COST variables respectively.

[0038] Compare result files (S3): Compare the generated result files with the standard result files by computer programming. If the tolerance requirements are met, the test case passes, otherwise it is considered a test failure.

[0039] Update the test sequence table (S4): delete the test case number of the successful test from the test sequence table, and update the test sequence table.

[0040] Correct the software and repeat the test (S5): For the test cases that failed, correct the ACAS X software and then repeat steps S2, S3 and S4 until the test sequence table is empty, that is, all failed cases are retested.

[0041] Loop test until all pass (S6): Repeat steps S1 to S5 until all 422 test cases pass. At this point, the ACAS X software passes the standard compliance verification.

[0042] Furthermore, in order to more clearly illustrate the details of the implementation of the technical solution of the present invention, a more specific and detailed embodiment including test environment preparation and implementation code is given below.

[0043] Example:

[0044] First, the test environment needs to be prepared, and the environment should have the ability to run ACAS X software and perform related test operations. The test environment should be configured with corresponding computer hardware resources, including but not limited to sufficient processor performance, memory capacity, and storage capacity to ensure that a large number of test cases can be run smoothly and related test files can be stored. In terms of software, a development environment that supports the selected programming language (such as Julia, Python, or C language, etc.) and a corresponding compilation tool chain need to be installed to implement the software programming operations involved in the method of the present invention. At the same time, a storage area for storing test case set files (including 1688 JSON files) and various result files generated subsequently needs to be prepared, and a special folder can be divided on the local hard disk.

[0045] Secondly, install the automatic folder comparison software to compare the result files with the DO385 standard result files in the subsequent steps, ensuring that the comparison software can accurately read and process the JSON format files and perform comparative analysis according to the set tolerance requirements.

[0046] According to the test case set specified in the DO385 standard (7 groups of 422 test cases), select an appropriate programming language to generate a test sequence table.

[0047] Furthermore, examples of three programming languages, Julia, Python and C, are given below. It should be noted that Julia and Python have flexible syntax and are easy to use, which are suitable for PC simulation scenarios; C language is highly efficient and can efficiently operate memory through pointer operations, which is more suitable for engineering application scenarios such as embedded systems; developers can choose a suitable programming language according to their needs.

[0048] If the Julia language is used, a two-dimensional array is implemented to construct a test sequence table through the following code example (the following is only a schematic code, which can be adjusted according to specific needs in actual applications):

[0049] #Define a two-dimensional array to represent the test sequence table

[0050] test_sequence_table=Array{Int,2}(undef,7,length_of_each_group)

[0051] #Here length_of_each_group needs to be assigned values ​​according to the actual number of test cases in each group, corresponding to 7 arrays of unequal lengths

[0052] foriin1:7

[0053] #Fill the array according to the specific test case number

[0054] test_sequence_table[i,:]=get_test_case_numbers_in_group(i)

[0055] end

[0056] If Python is used, the list of lists (listoflists) structure is used for implementation. The sample code is as follows:

[0057] #Initialize an empty list to store the test sequence table

[0058] test_sequence_table=[]

[0059] foriinrange(7):

[0060] #Get the test case serial number list for each group and add it to the total test sequence list

[0061] test_sequence_table.append(get_test_case_numbers_in_group(i))

[0062] When using C language, the test sequence table is constructed with the help of pointer arrays. The sample code framework is as follows (some detailed codes are omitted here, such as error handling mechanisms such as memory allocation, which need to be improved in actual applications):

[0063] / / Define a pointer array to represent the test sequence table of the two-dimensional structure

[0064] int**test_sequence_table;

[0065] / / Allocate memory space for pointer array

[0066] test_sequence_table=(int**)malloc(7*sizeof(int*));

[0067] for(int i = 0; i < 7; i ++) {

[0068] / / Allocate sub-array memory space according to the actual number of test cases in each group, and fill in the test case serial number

[0069] test_sequence_table[i]=(int*)malloc(length_of_group[i]*sizeof(int));

[0070] / / Fill in the specific test case number, which can be obtained through the corresponding function

[0071] fill_test_case_numbers(test_sequence_table[i],i);

[0072] }

[0073] Through the corresponding implementation methods of the above different programming languages, the test sequence table is generated to prepare for the subsequent batch running of test cases.

[0074] Write a program with complete functions and rigorous logic to run all the corresponding test cases in the test sequence table at one time, and process and store various result data generated during the operation. Take Python language as an example (other programming languages ​​can follow similar implementation ideas and write corresponding codes and logic designs according to their own language characteristics). Through the nested loop structure, each test case number in the test sequence table is traversed, and the test interface provided by ACAS X software is called (here it is assumed that ACAS X software has developed and opened an interface specifically for external call test functions, and the interface definition is clear and the parameter transfer is standardized) to start the operation of each test case in order. The following is a more detailed sample code and description:

[0075] forgroupintest_sequence_table:

[0076] fortest_case_numberingroup:

[0077] #Call the test interface of ACAS X software, pass in the test case number and other necessary parameters (determined according to the interface definition)

[0078] run_test_case(test_case_number,other_necessary_params)

[0079] #Get and save the result files corresponding to the TRM, STM and COST variables generated during the run. Here you need to ensure that the file save path is correct and the file name is standardized

[0080] save_result_files(test_case_number,trm_value,stm_value,COST_value,save_path)

[0081] #You can add a logging function to record the startup time, running status and other information of each test case to facilitate subsequent troubleshooting

[0082] log_test_case_start(test_case_number,time.time())

[0083] In the process of running each test case, the result files corresponding to the Threat Decision Module (TRM), the Surveillance and Tracking Module (STM), and the Cost Value (COST) should be obtained in real time and accurately and generated in accordance with the pre-set standard format. For example, for each test case numbered n, the generated result files can be named "n_TRM.json", "n_STM.json", "n_COST.json", etc., to ensure that the file naming has clear logic and uniqueness, facilitate the establishment of an accurate correspondence with the specific test case, and facilitate subsequent result file comparison operations and problem tracing.

[0084] At the same time, these generated result files should be properly stored in the designated folder. The path setting of the folder should be reasonable and easy to manage. For example, according to the overall file storage plan of the project, the folder structure can be further subdivided according to the date, version number and other information in the directory dedicated to storing test results to ensure that the entire file storage system is orderly and convenient for subsequent search, use and backup operations. In addition, in the process of saving result files, the integrity and accuracy of the files should be fully considered. Additional logic such as data verification and format verification can be added to ensure that the file content meets the expected requirements to avoid problems such as file damage or format errors that affect subsequent comparison and verification work.

[0085] Perform comparison operations programmatically to ensure the accuracy and comprehensiveness of the result file comparison. The following takes Python language and TRM result comparison as an example to illustrate the specific implementation process (other languages ​​and STM and COST results can be implemented with similar ideas). A comparison code example based on Python language is provided to compare whether the variables in the TRM result file (here, test_TRM.json) and the standard TRM result file (standard_TRM.json) meet the tolerance requirements.

[0086] importjson#Calling the JSON library

[0087] #Read the test result file and standard result file

[0088] withopen('test_TRM.json','r')asf_test:

[0089] test_data = json.load(f_test)

[0090] withopen('standard_TRM.json','r')asf_standard:

[0091] standard_data=json.load(f_standard)

[0092] #Used to store variable information that does not meet tolerance requirements

[0093] error_info=[]

[0094] #The tolerance range is set as a dictionary, the key is the variable name, and the value is the corresponding tolerance value. The DO385 standard has a specific and clear definition of the tolerance of all variables. The actual implementation should strictly follow DO385.

[0095] tolerance_dict={

[0096] "variable1": 0.05, # Example variables and tolerance values. For actual implementation, refer to the specific provisions of DO385.

[0097] "variable2":0.1# Example variables and tolerance values. For actual implementation, refer to the specific provisions of DO385.

[0098] }

[0099] #Traverse the variables for comparison

[0100] forvariable_nameinstandard_data:

[0101] test_value=test_data.get(variable_name,None)

[0102] standard_value=standard_data[variable_name]

[0103] tolerance=tolerance_dict.get(variable_name,0)#Get the corresponding tolerance, the default is 0

[0104] ifabs(test_value-standard_value)>tolerance:

[0105] error_info.append({

[0106] "variable_name":variable_name,

[0107] "test_value":test_value,

[0108] "standard_value":standard_value,

[0109] "error":test_value-standard_value

[0110] })

[0111] #Store the variable information that does not meet the tolerance requirements as an error file (this example is stored in json format)

[0112] withopen('TRM_error.json','w')asf_error:

[0113] json.dump(error_info,f_error)

[0114] The above code first reads the corresponding JSON format test result file and standard result file, and then compares the variables one by one according to the preset tolerance range, and collects the relevant information of the variables that do not meet the tolerance requirements and stores them in a new error file, which is convenient for subsequent review and analysis of non-compliance. In actual applications, it is necessary to make further precise adjustments and improvements to the variables, tolerance ranges, and other contents in the code according to the specific tolerance requirements for each TRM variable in the DO385 standard and other details.

[0115] Only when all variables in the result file meet the tolerance requirements, the corresponding test case is judged to have passed; otherwise, it is judged to have failed. Through this programming method of checking and comparing variables one by one, the specific situations that do not meet the standards in each module can be accurately located to avoid missing problems. At the same time, it is convenient to integrate error information, effectively improve comparison efficiency and accuracy, and provide reliable data support for the entire verification process.

[0116] In addition, you can also use the automatic folder comparison software to implement the overall comparison operation, accurately set the folder storing the TRM, STM and COSTT result files as the source folder for the comparison operation, and set the folder storing the DO385 standard result files as the target folder. When using the automatic folder comparison software, carefully and accurately configure the corresponding tolerance parameters in the software according to the allowable error range strictly specified in the DO385 standard for the comparison of each variable. The software will automatically perform a comprehensive and detailed comparative analysis of each corresponding file in the two folders according to the set logic, and generate a detailed and well-organized comparison report, which clearly lists the comparison results of each test case and the comparison details of each variable, so as to facilitate subsequent in-depth viewing, statistical analysis, and troubleshooting.

[0117] Update the test case sequence table, find and delete the test case numbers that have passed the test in the test sequence table. Through this operation, the test sequence table only retains the test case numbers that have not passed, preparing for the next round of iterative testing, realizing dynamic optimization of the test process, and avoiding unnecessary repetition of passed test cases.

[0118] Before re-testing the loop, the R&D personnel must analyze the failed test cases, combine the professional knowledge in this field and a thorough understanding of the internal logic structure of the ACAS X software, and make targeted corrections and optimizations to the ACAS X software; specifically, they must review and modify the anti-collision logic code, reasonably adjust the relevant parameters, and re-evaluate and improve some algorithm implementations. The specific correction method depends on the analysis of the reasons for the test failure. For example, if some variables in the traffic decision module (TRM) related test cases do not meet the standards, it is necessary to focus on analyzing the rationality of the decision logic, check whether the cost value calculation, application, and threshold judgment are strictly in accordance with the design expectations, and whether the wrong results are caused by inaccurate simulation of external environmental factors or internal logic conflicts, and then make targeted improvements.

[0119] After completing the software correction, repeat steps S2, S3 and S4 again, re-run the remaining test cases, compare the result files and update the test sequence table according to the corresponding implementation methods mentioned above, and repeat this cycle until all test case numbers in the test sequence table are cleared, that is, all test cases have passed the verification.

[0120] In order to verify and ensure that the software modification has no adverse effects on other test cases, steps S1, S2, S3, S4 and S5 need to be repeated. When executing step S3, the number of passed test cases is counted. When the number of passed test cases reaches all 422 test cases specified in the DO385 standard, the ACAS X software is judged to have passed the standard compliance verification.

[0121] During the process, detailed test records should be kept, including the results of each round of tests, software corrections and other information, so as to facilitate subsequent tracing and summary.

[0122] Finally, after the test is passed, you can use folder comparison software to visually check and confirm all test results again as needed.

Claims

1. ACAS X software standard compliance verification method based on DO385 test case set, characterized by: The following steps are involved: S1: Generate a test sequence table by software programming. The test sequence table is a list of serial numbers of all test cases specified by DO385. When implemented, it includes a two-dimensional table consisting of 7 groups of arrays of unequal lengths. When the two-dimensional table is implemented by programming in Julia language, it is implemented by defining a two-dimensional array. When implemented in Python language, a list of lists is used to represent the two-dimensional table consisting of 7 arrays of unequal lengths, and each sublist can have a different length. When implemented in C language, a pointer array is used to represent the two-dimensional table consisting of 7 arrays of unequal lengths. S2: Run the ACAS X software, use the test case corresponding to the test case number in the test sequence table as the input of the ACASX software, and generate corresponding result files for the variables of TRM, STM and COST generated during the operation, wherein TRM, STM and COST are respectively the threat decision module, monitoring and tracking module and cost value specified in DO385; S3: Compare the TRM, STM and COST result files with the DO385 standard result files in sequence, specifically including: for each test case in the test sequence table, read its TRM result file and the standard TRM result file respectively, compare the data one by one according to the variable name to see if they meet the tolerance requirements, if not, record the variable name, value and error and store them as a TRM error file, and in the same way, compare the STM result file with the standard STM result file, and the COST result file with the standard COST result file in sequence and store the corresponding error files, when all variables in the TRM, STM and COST result files meet the tolerance requirements, the test case passes the test, otherwise it fails the test; complete the result file comparison of all test cases in the test sequence table in the same way; S4: updating the test sequence table by deleting the serial number of the test case that has been successfully tested from the test sequence table; S5: correcting the ACAS X software for the test cases that failed the test, and then repeating steps S2, S3 and S4 until the test sequence table is cleared; S6: Repeat steps S1, S2, S3, S4 and S5 until all test cases in step S3 are passed, and the ACAS X software passes the standard compliance verification.

2. The method according to claim 1, characterized in that The TRM, STM and COST result files are compared with the DO385 standard result files in sequence. The specific implementation method is to compare the files stored in two folders through automatic folder comparison software, one of the two folders stores the TRM, STM and COST result files, and the other stores the DO385 standard result file.

Images