Method and system for checking unmanned aerial vehicle radar data simulation, terminal and storage medium

Abstract

The application discloses a UAV radar data simulation verification method and system, a terminal and a storage medium. The verification method comprises the following steps: loading a pre-stored machine-readable use case, obtaining an effective data packet set according to the machine-readable use case; inputting the effective data packet set into a measured processing path and simultaneously performing test processing, performing first parameter collection processing on a first test process corresponding to the measured processing path, obtaining a first parameter group and a first parameter set; performing second parameter collection processing on the first test process, obtaining a second parameter set; performing field comparison processing according to the first parameter set, the second parameter set and an expected field sequence, obtaining a trace report and a test report; performing hash calculation to obtain an evidence association list, and outputting the trace report, the test report and the evidence association list. The application can effectively realize test reproduction and accurately analyze and process abnormal events.

Description

Technical Field

[0001] This application relates to the field of UAV obstacle avoidance radar data processing technology, and in particular to a verification method, system, terminal and storage medium for UAV radar data simulation. Background Technology

[0002] With the continuous development of technology, drones are playing an increasingly important role in people's daily lives and work. Drones are often equipped with obstacle avoidance functions, which can identify obstacles in their flight path and avoid them in advance. Furthermore, developers of drone obstacle avoidance functions typically need to verify them in a software-in-the-loop simulation environment first.

[0003] In existing simulation verification technologies, the simulation verification of flight obstacle avoidance functions usually relies on radar data input from physical radar, artificial obstruction, or occasional abnormal faults. This radar data is difficult to accurately repeat to achieve test reproducibility. Furthermore, existing technologies only record the final verification results during verification, lacking version binding and evidence association, making it difficult to determine at which stage the interruption of scanning message transmission occurred. This makes it difficult to review and trace the verification results, resulting in a lack of reproducibility and traceability in the simulation verification of flight obstacle avoidance functions, and failing to meet the requirements of software-in-the-loop simulation verification.

[0004] Therefore, existing technologies still need to be improved and developed. Summary of the Invention

[0005] The main purpose of this application is to provide a verification method, system, terminal and storage medium for UAV radar data simulation, aiming to solve the technical problem that in the prior art, it is difficult to repeat radar data to reproduce the test, and the final test results are difficult to verify and trace, resulting in a lack of reproducibility and traceability in the simulation verification of flight obstacle avoidance function, which makes it difficult to meet the requirements of software-in-the-loop simulation verification.

[0006] To achieve the above objectives, this application provides a verification method for UAV radar data simulation, the verification method comprising: Load pre-stored machine-readable use cases, obtain corresponding event sequences and expected field sequences based on the machine-readable use cases, obtain multiple different types of events based on the event sequences, and obtain a set of valid data packets based on all the events; The set of valid data packets is simultaneously input into the preset baseline processing path and the processing path under test, and the test processing is performed simultaneously. The first parameter acquisition processing is performed on the first test process corresponding to the processing path under test to obtain the first parameter group and the first parameter set corresponding to each valid data packet in the set of valid data packets. Each valid data packet is processed into a message to obtain several scan messages. All scan messages are encapsulated into corresponding specific distance messages and sent to the flight control software platform. The first test process is then processed to obtain a second parameter set, wherein each scan message is matched one-to-one with the corresponding valid data packet. Based on the first parameter set, the second parameter set, and the expected field sequence, a field comparison process is performed to obtain a trace report and a test report. Hash calculations are performed based on the machine-readable use cases, the trace report, and the test report to obtain an evidence association list, and the trace report, the test report, and the evidence association list are output.

[0007] Optionally, the step of loading pre-stored machine-readable use cases, obtaining corresponding event sequences and expected field sequences based on the machine-readable use cases, obtaining multiple different types of events based on the event sequences, and obtaining a set of valid data packets based on all the events specifically includes: Load pre-stored machine-readable use cases from a preset storage unit, and perform reading processing on the machine-readable use cases to obtain an event sequence and an expected field sequence. The event sequence contains several events of different types, and the expected field sequence contains the expected fields corresponding to each event. The event sequence is processed for type identification to obtain multiple different types of events, including: data packet type, original frame type, and transport reset type. Perform corresponding preprocessing on different types of events, and treat data packet events directly as valid data packets; Perform validation and segmentation / reassembly processing on the original frame class events, and output a valid data packet when the validation and segmentation / reassembly processing is successful; After preprocessing all data packet type events and all original frame type events is completed, a set of valid data packets is obtained, wherein each valid data packet in the set of valid data packets has a preset execution order.

[0008] Optionally, the first test process corresponding to the path under test includes: an input layer, a parsing layer, and a scanning layer; The process involves simultaneously inputting the set of valid data packets into a preset baseline processing path and a processing path under test, and simultaneously performing test processing. During the test processing, a first parameter acquisition process is performed on the first test flow corresponding to the processing path under test to obtain a first parameter set corresponding to each valid data packet in the set of valid data packets. Specifically, this includes: Each valid data packet in the set of valid data packets is sequentially input into the preset benchmark processing path and the processing path under test with the same execution order and data parameters, and the test processing is executed synchronously. The first test process corresponding to the tested processing path is subjected to first parameter acquisition processing, and all parameters in the input layer, parsing layer and scanning layer of the first test process are acquired to obtain the first parameter group corresponding to each valid data packet in the valid data packet set. Integrate all the first parameter groups to obtain the first parameter set.

[0009] Optionally, the first test process further includes: a transmission layer and a flight control platform layer; Each valid data packet is processed into several scan messages. All scan messages are then encapsulated into corresponding distance-specific messages and sent to the flight control software platform. The first test process is then processed to acquire second parameters, resulting in a second parameter set, which specifically includes: Each valid data packet is processed into a message, and valid data packets that meet preset conditions are converted into scan messages. After completing the message processing of all valid data packets in the set of valid data packets, several scan messages are obtained. All scan messages are encapsulated into corresponding specific distance messages and sent to the flight control software platform. The valid data packets converted into scanning messages are processed for second parameter acquisition. The parameters corresponding to the transport layer and flight control platform layer in the first test process are collected to obtain the second parameter group corresponding to each valid data packet converted into a scanning message. Integrate the second parameter group to obtain the second parameter set.

[0010] Optionally, the step of performing field comparison processing based on the first parameter set, the second parameter set, and the expected field sequence to obtain a trace report and a test report specifically includes: Each valid data packet is analyzed and judged. If the valid data packet is converted into a scan message in the first test process, the corresponding first parameter group and second parameter group are obtained from the first parameter set and the second parameter set, respectively. According to the first parameter group and the second parameter group, the corresponding expected field is obtained in the expected field sequence, and the corresponding field comparison processing is performed according to the first parameter group, the second parameter group and the expected field; If a valid data packet is not converted into a scan message in the first test process, the corresponding first parameter group is obtained from the first parameter set. The corresponding expected field is obtained from the expected field sequence according to the first parameter group, and the corresponding field comparison processing is performed according to the first parameter group and the expected field. During the field comparison process, the complete execution trajectory corresponding to each valid data packet is written into a preset trace report, and the processing result obtained from the field comparison process is written into a preset test report. After the field comparison processing of all the valid data packets is completed, the final trace report and test report are obtained.

[0011] Optionally, the step of performing hash calculations based on the machine-readable use case, the trace report, and the test report to obtain an evidence association list, and then outputting the trace report, the test report, and the evidence association list, specifically includes: Obtain the verification source code, and perform SHA256 hash calculations on the machine-readable test case, the trace report, the test report, and the verification source code respectively; After all SHA256 hash calculations are completed, record the file path, number of bytes, and hash value corresponding to the machine-readable use case, the trace report, the test report, and the verification source code. By integrating all the stated file paths, all the stated byte counts, and all the stated hash values, a list of evidence associations is obtained. Output the trace report, the test report, and the evidence association list.

[0012] Optionally, the step of performing field comparison processing based on the first parameter set, the second parameter set, and the expected field sequence to obtain a trace report and a test report further includes: Receive a minimum anomaly sequence reproduction request sent by a user, and analyze the trace report based on the minimum anomaly sequence reproduction request; When a target abnormal signature appears in the trace report, the event sequence is deleted to obtain a candidate sequence; Based on the candidate sequence, a corresponding set of candidate valid data packets is obtained, and the set of candidate valid data packets is input into the test processing path to perform test processing and field comparison processing in sequence, thereby obtaining a candidate trace report; The candidate trace report is queried. If the candidate trace report contains the target abnormal signature, the candidate sequence is retained. The deletion process, testing process, field comparison process, and query process are repeatedly performed on the candidate sequence until the shortest candidate sequence is obtained, which is then used as the smallest abnormal sequence.

[0013] Furthermore, to achieve the above objectives, this application also provides a verification system for UAV radar data simulation, wherein the verification system is used to implement the verification method described in any one of the above claims, and the verification system includes: The data packet acquisition module is used to load pre-stored machine-readable use cases, obtain corresponding event sequences and expected field sequences based on the machine-readable use cases, obtain multiple different types of events based on the event sequences, and obtain a set of valid data packets based on all the events; The parameter acquisition module is used to simultaneously input the set of valid data packets into the preset benchmark processing path and the processing path under test, and simultaneously perform test processing. The first parameter acquisition processing is performed on the first test process corresponding to the processing path under test to obtain the first parameter group and the first parameter set corresponding to each valid data packet in the set of valid data packets. The message processing module is used to process each of the valid data packets into messages to obtain several scan messages, encapsulate all the scan messages into corresponding specific distance messages and send them to the flight control software platform, and perform second parameter acquisition processing on the first test process to obtain a second parameter set, wherein each scan message is matched one by one with the corresponding valid data packet; The field comparison module is used to perform field comparison processing based on the first parameter set, the second parameter set, and the expected field sequence to obtain a trace report and a test report. The hash calculation module is used to perform hash calculations based on the machine-readable use case, the trace report, and the test report to obtain the evidence association list, and output the trace report, the test report, and the evidence association list.

[0014] In addition, to achieve the above objectives, this application also provides a terminal, wherein the terminal includes: a memory, a processor, and a verification program stored in the memory and executable on the processor, wherein when the verification program is executed by the processor, it implements the steps of the verification method as described in any of the preceding claims.

[0015] In addition, to achieve the above objectives, this application also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a verification program, which, when executed by a processor, implements the steps of the verification method as described in any of the preceding claims.

[0016] In this application, the verification method includes: loading pre-stored machine-readable test cases; obtaining corresponding event sequences and expected field sequences based on the machine-readable test cases; obtaining multiple different types of events based on the event sequences; obtaining a set of valid data packets based on all the events; simultaneously inputting the set of valid data packets into a preset baseline processing path and a test processing path, and simultaneously performing test processing; performing first parameter acquisition processing on a first test process corresponding to the test processing path to obtain a first parameter group and a first parameter set corresponding to each valid data packet in the set of valid data packets; performing message processing on each valid data packet to obtain several scan messages; encapsulating all the scan messages into corresponding specific distance messages and sending them to the flight control software platform; and performing second parameter acquisition processing on the first test process to obtain a second parameter set, wherein each scan message is matched one-to-one with the corresponding valid data packet; performing field comparison processing based on the first parameter set, the second parameter set, and the expected field sequence to obtain a trace report and a test report; performing hash calculation based on the machine-readable test cases, the trace report, and the test report to obtain an evidence association list, and outputting the trace report, the test report, and the evidence association list. In this application, pre-loaded machine-readable test cases can accurately and repeatedly output radar data with anomalies, thereby effectively reproducing the test. Furthermore, the resulting evidence association list can verify and trace the test results, thereby enabling accurate and effective analysis and processing of events with anomalies, and improving the efficiency of UAV obstacle avoidance radar data simulation. Attached Figure Description

[0017] Figure 1 This is a flowchart of a preferred embodiment of the verification method for UAV radar data simulation provided in this application; Figure 2 This is a schematic diagram of a preferred embodiment of the verification system for simulating UAV radar data provided in this application.

[0018] Figure 3 This is a schematic diagram of the operating environment of a preferred embodiment of the terminal of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer and more explicit, the following detailed description of this application is provided with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0020] The verification method for UAV radar data simulation described in the preferred embodiment of this application, such as... Figure 1 As shown, the verification method for the simulation of UAV radar data includes the following steps: Step S10: Load the pre-stored machine-readable use cases, obtain the corresponding event sequence and expected field sequence based on the machine-readable use cases, obtain multiple different types of events based on the event sequence, and obtain a set of valid data packets based on all the events.

[0021] Specifically, the system first organizes normal radar data and various abnormal situations into machine-readable test cases with definite data, execution order, event time, and expected results (in effect, it performs anomaly injection processing on normal radar data). These abnormal situations include, but are not limited to, CRC errors, half-frame input, protocol buffer reset, abnormal angles, and insufficient coverage angles. Then, these machine-readable test cases are stored in the storage unit.

[0022] When verification is required, machine-readable test cases are loaded from the storage unit. These machine-readable test cases are identified using the schema_version (a database version number) format. The machine-readable test cases are then read and processed to obtain the corresponding event sequence and expected field sequence. Subsequently, the event sequence undergoes type identification processing to obtain multiple different types of events. It should be noted that, in the embodiments of this application, the event types include: packet type, raw frame type, and transport reset type. Packet type events and raw frame type events correspond to different preprocessing steps. After preprocessing different types of events, multiple valid packets are obtained. Finally, all valid packets are integrated to obtain a set of valid packets.

[0023] In one embodiment, the process of loading pre-stored machine-readable use cases, obtaining corresponding event sequences and expected field sequences based on the machine-readable use cases, obtaining multiple different types of events based on the event sequences, and obtaining a valid data packet based on all the events specifically includes: The system loads pre-stored machine-readable use cases from a preset storage unit and performs reading processing on these use cases to obtain an event sequence and an expected field sequence. The event sequence contains several events of different types, and the expected field sequence contains expected fields corresponding to each event. The event sequence undergoes type identification processing to obtain multiple different types of events, including: data packet type, original frame type, and transport reset type. Preprocessing is performed on each type of event, with data packet type events directly treated as valid data packets. Original frame type events undergo verification and segmentation / reassembly processing; valid data packets are output when verification and segmentation / reassembly are successful. After preprocessing all data packet type events and all original frame type events, a set of valid data packets is obtained, where each valid data packet in the set has a preset execution order.

[0024] Specifically, the pre-configured storage unit contains multiple machine-readable test cases. First, any pre-stored machine-readable test case is loaded from the storage unit and read and processed to obtain the event sequence and expected field sequence corresponding to this machine-readable test case. The event sequence contains multiple events, which are normal radar data, i.e., radar scan data within a certain time period. Events can record: event time, start angle, end angle, sampling coverage set, distance, confidence level, injection method, and half-frame split position. The expected field sequence contains the expected fields corresponding to each event. The expected fields are the set of expected results pre-set for each event in the machine-readable test case. The expected fields include, but are not limited to: parser effective frame change, CRC failure count, protocol buffer bytes, tested status, published status, low_coverage, resets, reverse, sync, awaiting_sync, coverage, max_unknown_run, message_emitted, message fields, and PX4 (a flight control software platform) observation status.

[0025] It should be noted that event time can be used to control the execution order of events, calculate the interval between adjacent events, or determine the continuity of time.

[0026] Subsequently, the event sequence is processed for type identification, which can then identify several different types of events, including: packet, raw frame, and transport reset.

[0027] It should be noted that the three types of events do not undergo the same preprocessing. Each type of event has its own corresponding preprocessing. Therefore, it is necessary to perform the corresponding preprocessing for different events separately.

[0028] Preprocessing is performed on packet-type events, which enables the direct generation of valid packets based on these events.

[0029] The original frame-type events undergo verification and segmentation / reassembly processing. Verification processing includes frame header verification, length verification, and CRC verification. When all verification processes for the original frame-type event have been completed and all results are successful, the event is segmented and reassembled to form a corresponding valid data packet. In other words, when both verification and segmentation processing for the original frame-type event are successful, a valid data packet corresponding to that event is output. If either verification or segmentation / reassembly fails, no valid data packet is formed, and the failure status and count are recorded accordingly.

[0030] Transport reset events are not distributed as valid data packets, but are separate control events used to clear protocol cache bytes and wait for synchronization state settings during the testing process.

[0031] In other words, after preprocessing all data packet events and all raw frame events, multiple valid data packets can be obtained. Furthermore, since each event contains a corresponding event time, each valid data packet also has a preset execution order.

[0032] Finally, by integrating all valid data packets, we can obtain the set of valid data packets corresponding to this event sequence.

[0033] In this context, test cases used for radar data simulation are machine-readable test cases that users pre-set for abnormal situations. These test cases can precisely control the occurrence time and duration of abnormal faults in the radar data, thereby precisely controlling the abnormal scenarios and enabling the test to be reproduced.

[0034] Step S20: Simultaneously input the set of valid data packets into the preset baseline processing path and the processing path under test, and perform test processing at the same time. Perform first parameter acquisition processing on the first test process corresponding to the processing path under test to obtain the first parameter group and the first parameter set corresponding to each valid data packet in the set of valid data packets.

[0035] Specifically, after obtaining the set of valid data packets, the set of valid data packets is simultaneously input into the preset baseline processing path and the processing path under test, and test processing is performed simultaneously.

[0036] The baseline processing path is a test path set up with the starting angle backoff as the baseline for scanning message publication. Starting angle backoff refers to the change of the starting angle in adjacent valid data packets from a high angle to a low angle, which represents a full radar scan (360°). For example, suppose the starting angle of a valid data packet is 355°, and the starting angle of the next adjacent valid data packet is 5°. In this case, it can be determined that the starting angle of the adjacent valid data packet has changed from a high angle to a low angle. That is, this valid data packet represents the end of the previous radar scan cycle, and the next adjacent valid data packet represents the beginning of the next radar scan cycle. At this time, the starting angle backoff is satisfied, and the corresponding scanning message publication processing can be performed. After the test is completed, the scanning boundary, publication count, and scanning message corresponding to the baseline processing path are obtained.

[0037] The tested processing path is a test path configured with predetermined logic based on actual testing needs. This predetermined logic includes, but is not limited to: waiting for synchronization, determining the continuity of event time, identifying the scan boundary from the high-angle to the low-angle area, determining effective coverage, resetting and recovering after anomalies, and message generation or rejection. However, it should be noted that the specific judgment rules and parameters included in the predetermined logic can be set by the tester and are not restricted in this application. When one or more valid data packets in the valid data packet set meet the preset rules, the corresponding scan message publishing process is performed. After the test is completed, the scan boundary, number of publications, and scan messages corresponding to the tested processing path are obtained.

[0038] During the testing process, the first parameter acquisition process is performed on the first test flow corresponding to the tested processing path. This allows the acquisition of the first parameter group corresponding to each valid data packet in the valid data packet set. Integrating all the first parameter groups yields the first parameter set corresponding to the valid data packet set. Each first parameter group contains multiple different parameters, which are used for field comparison processing with preset expected fields.

[0039] In one embodiment, the first test process corresponding to the path under test includes: an input layer, a parsing layer, and a scanning layer; the step of simultaneously inputting the set of valid data packets into a preset baseline processing path and the processing path under test, and simultaneously performing test processing, wherein during the test processing, the first test process corresponding to the processing path under test is subjected to first parameter acquisition processing to obtain the first parameter set corresponding to each valid data packet in the set of valid data packets, specifically includes: Each valid data packet in the set of valid data packets is sequentially input into the preset benchmark processing path and the processing path under test with the same execution order and data parameters, and the test processing is executed synchronously; the first test process corresponding to the processing path under test is subjected to the first parameter acquisition process, and all parameters in the input layer, parsing layer and scanning layer of the first test process are acquired to obtain the first parameter group corresponding to each valid data packet in the set of valid data packets; all the first parameter groups are integrated to obtain the first parameter set.

[0040] Specifically, the first test process corresponding to the path under test includes an input layer, a parsing layer, and a scanning layer, with each layer recording corresponding parameters. The input layer records the event sequence or entity input of the test; the parsing layer records protocol buffer changes, valid frame verification results, and CRC verification results; and the scanning layer records the status, coverage, scan message formation behavior, or message rejection behavior of the dual paths (baseline processing path and the processing path under test).

[0041] Before inputting valid data packets into the preset baseline processing path and the processing path under test, the execution order of each valid data packet is obtained according to the event time corresponding to each valid data packet. Then, the set of valid data packets is input into the baseline processing path and the processing path under test respectively with the same execution order and data parameters. That is, the two paths will receive the set of valid data packets with the same execution order and the same data parameters, and perform test processing synchronously. The test processing process is to execute each valid data packet in the set of valid data packets in the execution order. In addition, transport reset events will also be executed in the corresponding execution order.

[0042] During the testing process, the first parameter acquisition process is performed on the first test flow corresponding to the test processing path (the second test flow corresponds to the baseline processing path). In fact, all parameters in the input layer, parsing layer and scanning layer of the first test flow are acquired to obtain the first parameter group corresponding to each valid data packet.

[0043] It should be noted that the first parameter acquisition and processing can be performed either synchronously after each valid data packet is executed or after all valid data packets are executed. This application does not impose any restrictions, as long as the first parameter group corresponding to each valid data packet can be obtained.

[0044] After obtaining the first parameter group corresponding to each valid data packet, all the first parameter groups are integrated to obtain the first parameter set corresponding to the set of valid data packets.

[0045] Furthermore, after the test processing is completed, the results output by the baseline processing path and the results output by the tested processing path will be subjected to differential verification. In fact, this means comparing the scan boundaries, number of publications and scan messages of the two final outputs, and further determining whether the difference between the two is caused by the predetermined logic of the tested processing path, thereby obtaining the differential verification results.

[0046] After obtaining the differential verification results, technicians can adjust the established logic corresponding to the tested processing path based on these results, thereby ensuring the accuracy of the simulation. In this embodiment, setting a benchmark processing path is not for verifying the algorithm itself, but rather to display the behavioral differences between the two test paths under identical input conditions, making the processing results of the two paths objectively comparable. This eliminates the influence of input differences on subsequent field comparison processing, further ensuring the accuracy of the field comparison processing.

[0047] Step S30: Message-process each valid data packet to obtain several scan messages. Encapsulate all scan messages into corresponding specific distance messages and send them to the flight control software platform. Perform second parameter acquisition processing on the first test process to obtain a second parameter set, wherein each scan message is matched one-to-one with the corresponding valid data packet.

[0048] Specifically, each valid data packet in the valid data packet set is processed into a message. The message processing is actually converting the valid data packet into a scan message that can be sent to the flight control software platform. The scan message includes, but is not limited to, the nearest obstacle distance data group that conforms to preset rules.

[0049] Furthermore, not all valid data packets can form corresponding scan messages; only valid data packets that can successfully pass the message processing can form scan messages.

[0050] After completing the message processing of all valid data packets in the valid data packet set, all the obtained scan messages are encapsulated to obtain multiple specific distance messages, and all specific distance messages are sent to the flight control software platform. Among them, the specific distance messages are messages that conform to the preset specific data protocol.

[0051] The first test process is then processed to acquire the second parameter, which is the second parameter set corresponding to the valid data packet that can form the scan message. All the second parameter sets are then integrated to obtain the second parameter set.

[0052] In one embodiment, the first test process further includes: a transport layer and a flight control platform layer; each valid data packet is processed into messages to obtain several scan messages, all scan messages are encapsulated into corresponding specific distance messages and sent to the flight control software platform, and the first test process is processed to obtain a second parameter set, specifically including: Each valid data packet is processed into a message, and valid data packets that meet preset conditions are converted into scan messages. After the message processing of all valid data packets in the set of valid data packets is completed, several scan messages are obtained. All scan messages are encapsulated into corresponding specific distance messages and sent to the flight control software platform. The valid data packets converted into scan messages are processed into second parameters, and the parameters corresponding to the transport layer and flight control platform layer in the first test process are collected to obtain the second parameter group corresponding to each valid data packet converted into a scan message. The second parameter groups are integrated to obtain the second parameter set.

[0053] Specifically, the first test process also includes a transmission layer and a flight control platform layer. The transmission layer records the message encoding and transmission behavior at a specific distance, while the flight control platform layer records the MAVLink (a communication protocol) reception status and the flight control platform observation results. The flight control platform observation results include, but are not limited to, fields such as distance array, angle increment, minimum distance, maximum distance, coordinate system, update time, and update frequency.

[0054] First, each valid data packet in the set of valid data packets is processed into a message. Valid data packets that meet the preset conditions are converted into scan messages. The preset conditions are the preset conditions in the quality gating process of message processing, which can determine whether the scan message finally formed by this valid data packet meets the standard and whether it can be sent to the flight control software platform.

[0055] In essence, message processing involves converting valid data packets into scan messages that can be received and analyzed by the flight control platform software. These messages contain specific nearest obstacle distance data sets. For example, valid data packets can be processed sequentially as follows: lightweight filtering (removing invalid sampling points with low confidence or zero distance), sector compression (partitioning the sampling points in the valid data packets into fixed sectors, with each fixed sector retaining only the nearest obstacle distance), scan boundary judgment (confirming the scan boundary), and quality gating (determining whether the data contained within a fixed sector meets preset conditions). This completes the message processing of the valid data packets, resulting in the corresponding scan messages. The above steps are merely examples and do not imply that the message processing of valid data packets in this application is limited to these steps; any method that converts valid data packets into corresponding scan messages is acceptable.

[0056] After message processing of all valid data packets in the valid data packet set is completed, several scan messages are obtained. Each scan message is matched one-to-one with a valid data packet. It should be noted that while each scan message has a matching valid data packet, not every valid data packet can be converted into a scan message. Each scan message is then encapsulated to obtain a specific distance message corresponding to each scan message. Finally, all specific distance messages are sent to the flight control platform.

[0057] Next, the valid data packets converted into scan messages undergo a second parameter acquisition process. This essentially involves acquiring parameters from the transport layer and flight control platform layer in the first test procedure. The second parameter acquisition process only collects parameters corresponding to valid data packets that can be converted into scan messages, thus obtaining a second parameter set for each valid data packet that can be converted into a scan message. In other words, after completing the second parameter acquisition process, the valid data packets in the valid data packet set fall into two categories: those that cannot be converted into scan messages and correspond only to the first parameter set, and those that can be converted into scan messages and correspond to both the first and second parameter sets.

[0058] After completing the second parameter acquisition and processing, several second parameter groups are obtained. By integrating all the second parameter groups, the second parameter set corresponding to the valid data packet set can be obtained.

[0059] Furthermore, it should be noted that, regardless of whether it is the first parameter acquisition and processing or the second parameter acquisition and processing, the acquired parameters can be associated through a preset identifier code, thereby realizing the association between events, valid data packets, the first parameter group, the second parameter group, and scan messages.

[0060] Step S40: Perform field comparison processing based on the first parameter set, the second parameter set, and the expected field sequence to obtain a trace report and a test report.

[0061] Specifically, after obtaining the first parameter set consisting of the first parameter group corresponding to all valid data packets in the valid data packet set, and the second parameter set consisting of the second parameter group corresponding to all valid data packets converted into scan messages, field comparison processing is performed based on the first parameter set, the second parameter set, and the expected field sequence.

[0062] In fact, the field comparison process involves comparing each parameter in the first and second parameter sets with the corresponding field in the expected field sequence. It should be noted that the smallest unit in the comparison process is each valid data packet. That is, each valid data packet is processed separately for field comparison, and the generated comparison judgment is also one-to-one with each valid data packet (event).

[0063] After completing the field comparison processing for each valid data packet, a trace report and a test report are obtained, which are displayed in the system as trace.json (the file corresponding to the trace report) and report.json (the file corresponding to the test report). The trace report records the complete trajectory corresponding to each event. The complete trajectory includes the input parameters, parsing results, scan status, and observation results from the flight control platform for each event. It also records the event number, association number, event time, expected fields, actual fields (i.e., the first parameter group and the second parameter group), and comparison judgment conclusion. The test report records the test summary, test failure items, and failure count statistics.

[0064] In one embodiment, the step of performing field comparison processing based on the first parameter set, the second parameter set, and the expected field sequence to obtain a trace report and a test report specifically includes: Each valid data packet is analyzed and judged. If the valid data packet is converted into a scan message in the first test process, the corresponding first parameter group and second parameter group are obtained from the first parameter set and the second parameter set, respectively. The corresponding expected field is obtained from the expected field sequence according to the first parameter group and the second parameter group, and the corresponding field comparison processing is performed according to the first parameter group, the second parameter group and the expected field. If the valid data packet is not converted into a scan message in the first test process, the corresponding first parameter group is obtained from the first parameter set. The corresponding expected field is obtained from the expected field sequence according to the first parameter group, and the corresponding field comparison processing is performed according to the first parameter group and the expected field. During the field comparison processing, the complete execution trajectory corresponding to each valid data packet is written into a preset trace report, and the processing result obtained from the field comparison processing is written into a preset test report. After the field comparison processing of all valid data packets is completed, the final trace report and test report are obtained.

[0065] Specifically, when performing field comparison processing, it is necessary to analyze and judge each valid data packet separately to determine whether the valid data packet is converted into a scan message during the testing process of the tested processing path.

[0066] If a valid data packet is converted into a scan message in the first test process, the first parameter group corresponding to this valid data packet is obtained from the first parameter set, and the second parameter group corresponding to this valid data packet is obtained from the second parameter set. Subsequently, the corresponding expected fields are obtained from the expected field sequence based on this valid data packet and the first and second parameter groups corresponding to this valid data packet. It should be noted that the expected field sequence already stores the corresponding expected fields for each valid data packet (event), and the expected fields are matched one-to-one with the first parameter group and / or the second parameter group.

[0067] Then, all parameters in the first parameter group and all parameters in the second parameter group are compared with the corresponding parts in the expected fields. When all parameters match the corresponding fields, a comparison judgment conclusion of event pass is formed; when any parameter does not match the corresponding field, a comparison judgment conclusion of event failure is formed, and the event number, expected field, actual field and abnormal signature corresponding to this valid data packet are recorded in the comparison judgment conclusion.

[0068] If a valid data packet is not converted into a scan message in the first test process, the first parameter group corresponding to the valid data packet is obtained from the first parameter set; then, the corresponding expected field is obtained from the expected field sequence based on the valid data packet and the first parameter group corresponding to the valid data packet.

[0069] Then, each parameter in the first parameter group is compared with the corresponding part of the expected field. When all parameters match the corresponding field, a comparison judgment conclusion of event failure is formed, and message rejection verification is performed to obtain the message rejection verification result. When any parameter does not match the corresponding field, a comparison judgment conclusion of event failure is directly formed.

[0070] It should be noted that the message rejection verification process is essentially a verification of valid data packets that have not been converted into scan messages. This confirms that the valid data packet does not have a corresponding successful message publication status, nor a corresponding observation result from the flight control platform. This prevents inconsistencies where the message is recorded as rejected (not converted into a scan message) during the first test, but a scan message is actually still sent. For example, when a valid data packet is not converted into a scan message, the scan layer in the first test process will record message_emitted=false (message publication status is failed), the reason for rejection (reason for not being converted into a scan message), and related counts. Furthermore, the transport layer will not record the corresponding message encoding and sending behavior for this valid data packet at a specific distance, and the flight control platform layer will not record the corresponding MAVLink receiving status or flight control platform observation result.

[0071] After completing the field comparison processing for each valid data packet, the complete trace corresponding to each valid data packet (event) is written to the pre-set trace.json to obtain the trace report; then the test summary, test failure items and failure count statistics are written to the pre-set report.json to obtain the test report.

[0072] Step S50: Perform hash calculation based on the machine-readable use case, the trace report, and the test report to obtain the evidence association list, and output the trace report, the test report, and the evidence association list.

[0073] Specifically, after processing all valid data packets in the valid data packet set, a trace report and a test report corresponding to the valid data packet set will be obtained. Finally, based on the machine-readable test cases, trace reports, and test reports, corresponding hash calculations will be performed to obtain the evidence association list corresponding to this valid data packet set.

[0074] Among them, the evidence association list can provide the results of evidence consistency and traceability verification, which can be used to confirm that a certain machine-readable test case, actuator, tested source code, test report, trace report and flight control platform log belong to the same test batch, and check whether the machine-readable test case, trace report and test report have been changed, missing or mixed versions.

[0075] Finally, the trace report, test report, and evidence association list are output to the preset receiving end to complete the verification of the UAV radar data simulation.

[0076] In one embodiment, the step of performing hash calculations based on the machine-readable use case, the trace report, and the test report to obtain an evidence association list, and then outputting the trace report, the test report, and the evidence association list, specifically includes: Obtain the verification source code, and perform SHA256 hash calculations on the machine-readable test case, the trace report, the test report, and the verification source code respectively; after all SHA256 hash calculations are completed, record the file path, number of bytes, and hash value corresponding to the machine-readable test case, the trace report, the test report, and the verification source code; integrate all the file paths, all the number of bytes, and all the hash values ​​to obtain the evidence association list; output the trace report, the test report, and the evidence association list.

[0077] Specifically, first obtain the verification source code. The verification source code refers to the source code file of the machine-readable test cases to be tested, which is dynamically specified by the user when testing machine-readable test cases.

[0078] Subsequently, SHA256 hash calculations were performed on the machine-readable test cases, trace reports, test reports, and verification source code. During the calculation, all bytes of the target file were read in binary mode, and a 256-bit digest was calculated using the SHA256 algorithm. This 256-bit digest was then encoded into 64 hexadecimal characters, which represent the corresponding 256-bit hash value. Finally, the file path, byte count, and hash value of the target file were recorded to obtain the corresponding evidence association list (represented in the system file as evidence.sha256.json). In other words, the evidence association list actually contains multiple different 256-bit hash values.

[0079] In this context, technicians can use this evidence association list to verify the simulation of UAV radar data. The evidence association list can review and trace the testing process, ensuring the reproducibility and traceability of the simulation verification. With the support of the evidence association list, the actual obstacle avoidance performance improvement brought about by each algorithm optimization can be accurately quantified, avoiding misjudgments caused by differences in the field testing environment, and improving the efficiency of flight obstacle avoidance function optimization.

[0080] For example, the evidence association list includes, but is not limited to: fault_sequence_runner.py, which is a hash value used to represent the test executor that performs event dispatch, trace collection, and automatic comparison of expected fields; and comprehensive_faults.json, which is a hash value used to determine the actual input events and corresponding expected fields.

[0081] The trace report, test report, and evidence association list are output as the verification results of the UAV radar data simulation. The receiving end is pre-set by the technicians. As long as the technicians can receive the above three reports, it is acceptable. This application does not impose any restrictions.

[0082] Furthermore, technicians can perform various advanced processing based on trace reports, test reports, and evidence association lists, such as document integrity verification, version consistency verification, reproducibility verification, and regression difference analysis, to obtain different processing results and further verify the simulation of UAV obstacle avoidance radar data.

[0083] In one embodiment, the step of performing field comparison processing based on the first parameter set, the second parameter set, and the expected field sequence to obtain a trace report and a test report further includes: The system receives a minimum anomaly sequence reproduction request sent by a user and analyzes the trace report based on the request. When a target anomaly signature appears in the trace report, the event sequence is deleted to obtain a candidate sequence. A set of corresponding candidate valid data packets is obtained based on the candidate sequence, and the set of candidate valid data packets is input into the tested processing path for sequential testing and field comparison to obtain a candidate trace report. A report comparison is performed between the trace report and the candidate trace report. If the candidate trace report contains the same anomaly signature as the trace report, the candidate sequence is retained. The deletion, testing, field comparison, and report comparison processes are repeated for the candidate sequence until the shortest candidate sequence is obtained, which is then used as the minimum anomaly sequence.

[0084] Specifically, users can also obtain the minimum anomaly sequence corresponding to the event sequence based on the actual renewal. The minimum anomaly sequence refers to the shortest event sequence that matches the target anomaly signature specified by the user. Deleting any event in this shortest event sequence will prevent the user from obtaining the target anomaly signature specified by the user in the corresponding trace report.

[0085] Users can send a minimum anomaly sequence reproduction request. When a minimum anomaly sequence reproduction request is received, the target anomaly signature required by the user is first obtained from the minimum anomaly sequence reproduction request, and this target anomaly signature is fixed.

[0086] Then, the trace report is analyzed based on the target's abnormal signature. When the trace report summary shows the target's abnormal signature, the original event sequence is deleted. It should be noted that the deletion here can be to delete one event in the event sequence or to delete a group of events in the event sequence. The choice can be made according to actual needs and is not limited here.

[0087] After the deletion of the event sequence is completed, a candidate sequence is obtained. Then, the candidate sequence is processed according to steps S10 to S40. That is, firstly, the corresponding candidate valid data packet set is obtained according to the candidate sequence, and then the candidate valid data packet set is input into the test processing path for test processing. During the test processing, the first parameter acquisition processing and the second parameter acquisition processing are performed to obtain the first parameter set and the second parameter set corresponding to the candidate valid data packet. Then, the first parameter set, the second parameter set and the expected field sequence (since they are derived from the same event sequence, the expected field sequence corresponding to the candidate sequence and the event sequence are the same) are compared to obtain the candidate trace report corresponding to the candidate sequence.

[0088] Subsequently, the candidate trace reports are queried to check whether the target abnormal signature required by the user appears in the candidate trace reports. If it exists, it proves that the deletion of the event sequence is effective (that is, the event that will not produce the target abnormal signature has been deleted), and this candidate sequence is retained. If it does not exist, it proves that the deletion of the event sequence is ineffective (that is, the event that will produce the target abnormal signature has been deleted). At this time, the event sequence needs to be deleted again, and the corresponding processing of steps S10 to S40 is executed again. The corresponding trace reports are queried again to determine whether there is a target abnormal signature.

[0089] After retaining the candidate sequences, the deletion, testing, field comparison, and query processes are repeatedly performed on them. Essentially, this involves continuously deleting events from the candidate sequences to obtain new candidate sequences, then performing testing and field comparison on these new sequences to generate new candidate trace reports. Finally, these new candidate trace reports are queried to determine if they contain the target anomaly signature. This process is repeated until the deletion of any event in a new candidate sequence no longer yields a corresponding target anomaly signature in the new candidate trace report. The shortest candidate sequence is then selected as the minimum anomaly sequence.

[0090] Finally, the minimum anomaly sequence is output to the user, completing the response to the user's request to reproduce the minimum anomaly sequence.

[0091] Furthermore, such as Figure 2 As shown, based on the above-mentioned verification method for UAV radar data simulation, this application also provides a verification system for UAV radar data simulation, wherein the verification system for UAV radar data simulation includes: The data packet acquisition module 51 is used to load pre-stored machine-readable use cases, obtain corresponding event sequences and expected field sequences based on the machine-readable use cases, obtain multiple different types of events based on the event sequences, and obtain a set of valid data packets based on all the events; The parameter acquisition module 52 is used to simultaneously input the set of valid data packets into the preset benchmark processing path and the processing path under test, and simultaneously perform test processing. The first parameter acquisition processing is performed on the first test process corresponding to the processing path under test to obtain the first parameter group and the first parameter set corresponding to each valid data packet in the set of valid data packets. The message processing module 53 is used to process each of the valid data packets into messages to obtain a number of scan messages, encapsulate all the scan messages into corresponding specific distance messages and send them to the flight control software platform, and perform second parameter acquisition processing on the first test process to obtain a second parameter set, wherein each scan message is matched one by one with the corresponding valid data packet; The field comparison module 54 is used to perform field comparison processing based on the first parameter set, the second parameter set and the expected field sequence to obtain a trace report and a test report. The hash calculation module 55 is used to perform hash calculations based on the machine-readable use case, the trace report, and the test report to obtain an evidence association list, and output the trace report, the test report, and the evidence association list.

[0092] Furthermore, such as Figure 3As shown, based on the above verification method and system, this application also provides a terminal, which includes a processor 10, a memory 20 and a display 30. Figure 3 Only some of the terminal components are shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0093] In some embodiments, the memory 20 may be an internal storage unit of the terminal, such as a hard disk or memory. In other embodiments, the memory 20 may be an external storage device of the terminal, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc. Further, the memory 20 may include both internal and external storage devices. The memory 20 is used to store application software and various types of data installed on the terminal, such as the program code installed on the terminal. The memory 20 can also be used to temporarily store data that has been output or will be output. In one embodiment, the memory 20 stores a verification program 40, which can be executed by the processor 10 to implement the verification method of this application.

[0094] In some embodiments, the processor 10 may be a central processing unit (CPU), a microprocessor, or other data processing chip, used to run program code stored in the memory 20 or process data, such as executing the verification method.

[0095] In some embodiments, the display 30 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. The display 30 is used to display information on the terminal and to display a visual user interface. The terminal's processor 10, memory 20, and display 30 communicate with each other via a system bus.

[0096] In one embodiment, the processor 10 implements the steps of the verification method described above when executing the verification program 40 in the memory 20.

[0097] This application also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a verification program, which, when executed by a processor, implements the steps of the verification method described above.

[0098] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal that includes that element.

[0099] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0100] Of course, those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.). The program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The computer-readable storage medium can be a memory, magnetic disk, optical disk, etc.

[0101] It should be understood that the application of this application is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A verification method for unmanned aerial vehicle (UAV) radar data simulation, characterized in that, The verification method includes: Load pre-stored machine-readable use cases, obtain corresponding event sequences and expected field sequences based on the machine-readable use cases, obtain multiple different types of events based on the event sequences, and obtain a set of valid data packets based on all the events; The set of valid data packets is simultaneously input into the preset baseline processing path and the processing path under test, and the test processing is performed simultaneously. The first parameter acquisition processing is performed on the first test process corresponding to the processing path under test to obtain the first parameter group and the first parameter set corresponding to each valid data packet in the set of valid data packets. Each valid data packet is processed into a message to obtain several scan messages. All scan messages are encapsulated into corresponding specific distance messages and sent to the flight control software platform. The first test process is then processed to obtain a second parameter set, wherein each scan message is matched one-to-one with the corresponding valid data packet. Based on the first parameter set, the second parameter set, and the expected field sequence, a field comparison process is performed to obtain a trace report and a test report. Hash calculations are performed based on the machine-readable use cases, the trace report, and the test report to obtain an evidence association list, and the trace report, the test report, and the evidence association list are output.

2. The verification method according to claim 1, characterized in that, The process of loading pre-stored machine-readable use cases, obtaining corresponding event sequences and expected field sequences based on the machine-readable use cases, obtaining multiple different types of events based on the event sequences, and obtaining a set of valid data packets based on all the events specifically includes: Load pre-stored machine-readable use cases from a preset storage unit, and perform reading processing on the machine-readable use cases to obtain an event sequence and an expected field sequence. The event sequence contains several events of different types, and the expected field sequence contains the expected fields corresponding to each event. The event sequence is processed for type identification to obtain multiple different types of events, including: data packet type, original frame type, and transport reset type. Perform corresponding preprocessing on different types of events, and treat data packet events directly as valid data packets; Perform validation and segmentation / reassembly processing on the original frame class events, and output a valid data packet when the validation and segmentation / reassembly processing is successful; After preprocessing all data packet type events and all original frame type events is completed, a set of valid data packets is obtained, wherein each valid data packet in the set of valid data packets has a preset execution order.

3. The verification method according to claim 1, characterized in that, The first test process corresponding to the path under test includes: an input layer, a parsing layer, and a scanning layer; The process involves simultaneously inputting the set of valid data packets into a preset baseline processing path and a processing path under test, and simultaneously performing test processing. During the test processing, a first parameter acquisition process is performed on the first test flow corresponding to the processing path under test to obtain a first parameter set corresponding to each valid data packet in the set of valid data packets. Specifically, this includes: Each valid data packet in the set of valid data packets is sequentially input into the preset benchmark processing path and the processing path under test with the same execution order and data parameters, and the test processing is executed synchronously. The first test process corresponding to the tested processing path is subjected to first parameter acquisition processing, and all parameters in the input layer, parsing layer and scanning layer of the first test process are acquired to obtain the first parameter group corresponding to each valid data packet in the valid data packet set. Integrate all the first parameter groups to obtain the first parameter set.

4. The verification method according to claim 1, characterized in that, The first test process also includes: the transmission layer and the flight control platform layer; Each valid data packet is processed into several scan messages. All scan messages are then encapsulated into corresponding distance-specific messages and sent to the flight control software platform. The first test process is then processed to acquire second parameters, resulting in a second parameter set, which specifically includes: Each valid data packet is processed into a message, and valid data packets that meet preset conditions are converted into scan messages. After completing the message processing of all valid data packets in the set of valid data packets, several scan messages are obtained. All scan messages are encapsulated into corresponding specific distance messages and sent to the flight control software platform. The valid data packets converted into scanning messages are processed for second parameter acquisition. The parameters corresponding to the transport layer and flight control platform layer in the first test process are collected to obtain the second parameter group corresponding to each valid data packet converted into a scanning message. Integrate the second parameter group to obtain the second parameter set.

5. The verification method according to claim 1, characterized in that, The step of performing field comparison processing based on the first parameter set, the second parameter set, and the expected field sequence to obtain a trace report and a test report specifically includes: Each valid data packet is analyzed and judged. If the valid data packet is converted into a scan message in the first test process, the corresponding first parameter group and second parameter group are obtained from the first parameter set and the second parameter set, respectively. According to the first parameter group and the second parameter group, the corresponding expected field is obtained in the expected field sequence, and the corresponding field comparison processing is performed according to the first parameter group, the second parameter group and the expected field; If a valid data packet is not converted into a scan message in the first test process, the corresponding first parameter group is obtained from the first parameter set. The corresponding expected field is obtained from the expected field sequence according to the first parameter group, and the corresponding field comparison processing is performed according to the first parameter group and the expected field. During the field comparison process, the complete execution trajectory corresponding to each valid data packet is written into a preset trace report, and the processing result obtained from the field comparison process is written into a preset test report. After the field comparison processing of all the valid data packets is completed, the final trace report and test report are obtained.

6. The verification method according to claim 1, characterized in that, The step of performing hash calculations based on the machine-readable use cases, the trace report, and the test report to obtain an evidence association list, and then outputting the trace report, the test report, and the evidence association list, specifically includes: Obtain the verification source code, and perform SHA256 hash calculations on the machine-readable test case, the trace report, the test report, and the verification source code respectively; After all SHA256 hash calculations are completed, record the file path, number of bytes, and hash value corresponding to the machine-readable use case, the trace report, the test report, and the verification source code. By integrating all the stated file paths, all the stated byte counts, and all the stated hash values, a list of evidence associations is obtained. Output the trace report, the test report, and the evidence association list.

7. The verification method according to claim 1, characterized in that, The step of performing field comparison processing based on the first parameter set, the second parameter set, and the expected field sequence to obtain a trace report and a test report, further includes: Receive a minimum anomaly sequence reproduction request sent by a user, and analyze the trace report based on the minimum anomaly sequence reproduction request; When a target abnormal signature appears in the trace report, the event sequence is deleted to obtain a candidate sequence; Based on the candidate sequence, a corresponding set of candidate valid data packets is obtained, and the set of candidate valid data packets is input into the test processing path to perform test processing and field comparison processing in sequence, thereby obtaining a candidate trace report; The candidate trace report is queried. If the candidate trace report contains the target abnormal signature, the candidate sequence is retained. The deletion process, testing process, field comparison process, and query process are repeatedly performed on the candidate sequence until the shortest candidate sequence is obtained, which is then used as the smallest abnormal sequence.

8. A verification system for simulating UAV radar data, characterized in that, The verification system is used to implement the verification method as described in any one of claims 1-7, and the verification system includes: The data packet acquisition module is used to load pre-stored machine-readable use cases, obtain corresponding event sequences and expected field sequences based on the machine-readable use cases, obtain multiple different types of events based on the event sequences, and obtain a set of valid data packets based on all the events; The parameter acquisition module is used to simultaneously input the set of valid data packets into the preset benchmark processing path and the processing path under test, and simultaneously perform test processing. The first parameter acquisition processing is performed on the first test process corresponding to the processing path under test to obtain the first parameter group and the first parameter set corresponding to each valid data packet in the set of valid data packets. The message processing module is used to process each of the valid data packets into messages to obtain several scan messages, encapsulate all the scan messages into corresponding specific distance messages and send them to the flight control software platform, and perform second parameter acquisition processing on the first test process to obtain a second parameter set, wherein each scan message is matched one by one with the corresponding valid data packet; The field comparison module is used to perform field comparison processing based on the first parameter set, the second parameter set, and the expected field sequence to obtain a trace report and a test report. The hash calculation module is used to perform hash calculations based on the machine-readable use case, the trace report, and the test report to obtain the evidence association list, and output the trace report, the test report, and the evidence association list.

9. A terminal, characterized in that, The terminal includes: a memory, a processor, and a verification program stored in the memory and executable on the processor, wherein the verification program, when executed by the processor, implements the steps of the verification method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a verification program, which, when executed by a processor, implements the steps of the verification method as described in any one of claims 1-7.

Images