A flight control system whole-process autonomous testing device and method

Abstract

This invention discloses a fully autonomous testing device and method for a flight control system, belonging to the field of software information security analysis technology. The device and method integrate a main control unit, mode power supply management, dual-mode communication, process monitoring, anomaly self-healing, and data management modules, forming an independently operable intelligent testing terminal. The method achieves fully autonomous closed-loop testing of flight control software from task preparation to result archiving through intelligent parameter matching, minimal hardware intervention startup, multi-dimensional real-time health monitoring, multi-level intelligent anomaly self-healing, and test data fusion, archiving, and security cleanup mechanisms. This invention solves the problems of fragmented testing processes, high hardware consumption, opaque processes, weak anomaly handling, and easy data loss in existing technologies, greatly improving the automation level, reliability, defect discovery depth, and data value of testing.

Description

Technical Field

[0001] This invention relates to the field of software information security analysis technology, and more specifically, to a device and method for autonomous testing of the entire process of a flight control system. Background Technology

[0002] As flight control system software becomes increasingly complex and its scale expands, the difficulty and workload of software testing are increasing exponentially. Traditional flight control software testing methods mostly rely on manual operation or semi-automatic testing devices, which suffer from problems such as low testing efficiency, excessive human intervention, high hardware wear and tear, lack of transparency in the testing process, and weak anomaly handling capabilities.

[0003] In the prior art, such as the solution described in published patent CN115757113B, although some operations in the testing process are automated, the following significant drawbacks still exist:

[0004] 1. The testing process is not truly autonomous: The automated adaptation device only serves as the execution terminal of the host computer. The control and decision-making of the testing process still rely on the host computer software, resulting in high system coupling, large communication delays, and interruption of the testing process when the host computer fails.

[0005] 2. Damage caused by frequent power-on and power-off of hardware: Each test requires a complete power cycle of "power-on-load-power-off-power-on-execution" for the target machine. Frequent power switching will cause electrical stress on the flight control hardware (especially storage devices, processors and power management chips), which will affect the lifespan of the equipment and the stability of the test in the long run.

[0006] 3. Lack of in-depth monitoring during the testing process: Existing solutions only perform simple timeout checks on "whether the mode has been started successfully", which cannot monitor the internal state of the target machine during the test execution process in real time (such as CPU load, memory usage, task scheduling, communication traffic, etc.), making it difficult to detect deep defects such as infinite loops, memory leaks, and timing anomalies.

[0007] 4. Weak exception handling mechanism: When encountering test exceptions, it can usually only perform simple "reload" or "end test", lacking a multi-level, intelligent exception self-healing strategy, and cannot realize the automatic recovery and continuation of the test process.

[0008] 5. Insecure test data management: Target files are deleted immediately after testing. If the results fail to be saved or uploaded, it is impossible to trace and reproduce the problem, which is not conducive to test quality management and regression testing.

[0009] 6. Poor system scalability and adaptability: Communication protocols, mode parameters, etc. are usually fixed in the device or host computer. When facing target machines of different models and different interfaces, software or even hardware needs to be modified, resulting in high upgrade and maintenance costs. Summary of the Invention

[0010] To address the problems existing in the prior art, the purpose of this invention is to provide a fully autonomous testing device and method for a flight control system, achieving closed-loop autonomy throughout the entire process from test preparation, loading, execution, monitoring to result processing.

[0011] To solve the above problems, the present invention adopts the following technical solution.

[0012] A fully autonomous testing device and method for a flight control system includes: a main control module for executing test process control and decision-making logic; a mode and power supply management module connected to the main control module for generating programmable power control signals and mode control level signals according to instructions to control the power-on, power-off, and working mode switching of the target aircraft; a dual-mode communication module connected to the main control module for enabling data communication with a host computer, the target aircraft, and a remote server; a test execution monitoring module connected to the main control module and the dual-mode communication module for real-time acquisition of internal runtime status indicators during target aircraft testing; an anomaly self-healing and logging module connected to the main control module for anomaly detection based on the runtime status indicators, triggering predefined self-healing strategies, and recording system operation logs; and a test data intelligent management module connected to the main control module for secure storage, version management, and lifecycle management of test target files, test result data, and process logs.

[0013] Furthermore, the mode and power management module includes a programmable multi-channel power output unit and a digital I / O control unit, which supports soft-start and soft-shutdown control of the power supply to the target machine, and can monitor the output voltage and current.

[0014] Furthermore, the test execution monitoring module collects at least two of the following indicators through the target machine's hardware debugging interface or software monitoring agent interface: CPU utilization, memory usage, task status timing, interrupt statistics, and communication error rate.

[0015] Furthermore, the anomaly self-healing and logging module has a built-in rule engine that can define multi-level anomaly thresholds and corresponding self-healing action sequences. The self-healing action sequences include sending diagnostic or reset commands to the target machine, controlling the target machine to partially power down and then power on again, and skipping the current test case and recording the anomaly context.

[0016] Furthermore, the intelligent test data management module uses copy-on-write and incremental backup technology to manage test files, and is configured to only transfer or clean up the original test target files after confirming that the test result data has been successfully archived to local and remote storage.

[0017] Among them, a method for autonomous testing of the entire flight control system is also disclosed, including the following steps: S1: Device initialization, self-test and loading of test task list;

[0018] S2: Intelligently matches the best historical mode and power supply configuration parameters for the current test task;

[0019] S3: Based on the current state of the target machine, select to execute a cold start, hot reset, or direct mode switching strategy to guide the target machine into loading mode with minimal hardware intervention;

[0020] S4: Load the test target file onto the target machine and perform an environment integrity check after loading;

[0021] S5: Start test execution and monitor the target machine's operating status in real time across all dimensions, and calculate system health;

[0022] S6: Perform multi-level anomaly detection based on monitoring results and execute corresponding intelligent self-healing processes;

[0023] S7: Collect test results, perform multi-level verification, and integrate and package the result data with process monitoring logs, securely archive them to local and remote storage, and update the status of the original test files only after successful archiving;

[0024] S8: Repeat steps S2 through S7 until all test tasks are completed.

[0025] Furthermore, the intelligent matching in step S2 specifically involves: extracting the feature information of the current test target file, querying the historical execution database, selecting the task record that is similar to the current file in features and has the highest historical execution success rate and shortest execution time, and adopting the mode and power supply configuration parameters used by that task.

[0026] Furthermore, the hot reset strategy in step S3 is as follows: when the target machine is powered on and in an idle state, a software reset command is first sent to it through the communication interface, and then the control level required for the loading mode is immediately applied to guide it into the loading mode and avoid performing a power-down operation.

[0027] Furthermore, the full-dimensional real-time monitoring in step S5 includes establishing a dynamic health baseline at the beginning of the test, and continuously comparing the real-time collected indicators with the baseline, and outputting a comprehensive system health score through a weighted algorithm.

[0028] Furthermore, the secure archiving in step S7 specifically includes: generating an encrypted data packet for each test case containing the original test results, process monitoring logs, exception records, and loading reports, and assigning a unique ID; first storing it in local non-volatile memory, and then attempting to synchronously upload it to a remote server; only after receiving confirmation of successful remote storage will the corresponding original test target file be marked as archived.

[0029] Compared with the prior art, the advantages of this invention are:

[0030] 1. Achieves true full-process autonomy in testing: Intelligent decision-making and control logic is embedded in the hardware device, significantly reducing the real-time dependence on the host computer and improving the independence, robustness and offline operation capability of the testing system, making it especially suitable for testing in field or high-security isolation environments.

[0031] 2. Significantly extends the lifespan of test hardware: Through the strategies of "intelligent parameter matching" and "minimizing hardware intervention", the number of unnecessary target machine power cycles and mode switching is greatly reduced, thereby reducing the risk of hardware wear and failure from the root.

[0032] 3. Significantly enhances the depth of testing and defect discovery capabilities: Through full-dimensional, high-frequency process monitoring, it can capture dynamic runtime defects (such as timing races, intermittent deadlocks, and slow resource leaks) that traditional methods cannot detect, deepening the testing from "functional correctness verification" to "runtime robustness verification".

[0033] 4. A highly available exception handling system has been built: multi-level exception detection and intelligent self-healing mechanism ensure that the test process can recover and continue to execute to the maximum extent when encountering problems, which significantly improves the overall success rate and efficiency of the test suite.

[0034] 5. A secure, complete, and traceable test data chain has been established: By adopting a strategy of result fusion archiving and post-confirmation cleanup, the problem of test data loss due to communication or storage failures has been completely eliminated, providing complete data support for problem localization, regression testing, and test process auditing.

[0035] 6. Excellent system scalability and adaptability: Modular design, protocol self-adaptation, parameter self-learning and other features enable the device to quickly adapt to flight control systems with different architectures and interfaces through software configuration, reducing the maintenance and upgrade costs of the test system itself. Attached Figure Description

[0036] Figure 1 This is a hardware structure block diagram of the flight control system full-process autonomous testing device provided in the embodiments of the present invention;

[0037] Figure 2This is an overall flowchart of the autonomous testing method for the entire flight control system provided in this embodiment of the invention;

[0038] Figure 3 This is a detailed flowchart of the full-dimensional monitoring and intelligent self-healing process shown in steps S500 and S600 in the embodiments of the present invention.

[0039] Figure 4 This is a schematic diagram of the file and data management logic of the intelligent test data management module in this embodiment of the invention. Detailed Implementation

[0040] Example 1:

[0041] This invention provides an autonomous testing device for the entire process of a flight control system, including a main control module, a mode and power supply management module, a dual-mode communication module, a test execution monitoring module, an anomaly self-healing and black box log module, and a test data intelligent management module.

[0042] The main control module uses a high-performance embedded processor, runs a real-time operating system, and has an embedded test process control engine and decision logic. It is responsible for scheduling and managing all functional modules within the device and is the intelligent control core of the device.

[0043] The mode and power supply management module is connected to the main control module and includes a programmable multiple power output unit and a digital I / O control unit. This module receives instructions from the main control module and can generate power control signals and mode control level signals with arbitrary waveforms and timings. It can achieve precise control of soft start / soft shutdown and mode switching of the target machine's power supply, and can monitor parameters such as power supply current and voltage.

[0044] The dual-mode communication module integrates an Ethernet communication unit and at least one high-speed serial communication unit (such as UART, CAN, SPI, etc.). This module supports adaptive protocol parsing and encapsulation, possesses intelligent data packet routing and redundant transmission capabilities, and can maintain reliable connections with the host computer (test management station), the target machine, and a remote data center simultaneously.

[0045] The test execution monitoring module connects to the dual-mode communication module and the main control module to perform in-depth status monitoring of the target machine during the test execution phase. This module collects and analyzes runtime metrics of the target machine in real time, such as CPU utilization, memory usage (including heap and stack), task status and switching timing, interrupt frequency, bus load, and communication port error rate, through dedicated hardware monitoring interfaces (such as JTAG, ETM, SWD) or software monitoring interfaces provided by the target machine.

[0046] The anomaly self-healing and black box logging module is connected to the main control module and the test execution monitoring module. This module has a built-in rule engine that compares the metrics reported by the monitoring module with a preset health model in real time. Once an anomaly is detected, a predefined multi-level self-healing strategy is immediately triggered. Simultaneously, this module continuously records key operation logs, system status, and abnormal events of both the device itself and the target machine in a "black box" manner, supporting power-off data retention.

[0047] The intelligent test data management module includes a local high-speed solid-state storage unit and storage management logic. This module provides unified, versioned, and structured storage for test input files (target files), test output results, process monitoring data, and system logs. It employs technologies such as copy-on-write and incremental backup to ensure data security and traceability, and supports policy-based file lifecycle management (such as automatic archiving and local cleanup after encrypted upload).

[0048] The testing device of this invention adopts a compact and ruggedized chassis design. The main control module uses an AM5728 dual-core ARM Cortex-A15 processor and is equipped with a Xilinx Artix-7 series FPGA as a coprocessor. The processor runs a custom real-time operating system based on the Linux kernel, which is responsible for high-level control logic; the FPGA is responsible for implementing high-precision timing control, I / O expansion, and high-speed data acquisition.

[0049] The mode and power management module is implemented by FPGA controlling two TI UCD9090A digital power sequence controllers, providing eight independent programmable power outputs. The voltage (0-32V), current (0-10A), and power-on / power-off slope of each output can be finely configured via software. The digital I / O section uses optocoupler-isolated outputs, providing 16 mode control signals that can be configured as high level (e.g., 5V), low level (0V), or pulse.

[0050] The dual-mode communication module includes a Gigabit Ethernet interface (Marvell 88E1111 PHY chip) and a multi-protocol serial communication daughter card supporting CAN FD, UART, and RS-422 / 485. The communication protocol stack runs on the main processor and supports various communication methods such as Socket, DDS, and custom binary streams.

[0051] The key to test execution monitoring modules lies in their connection to the target machine. For target machines that support JTAG or ARM CoreSight ETM interfaces, the device connects via a dedicated JTAG / ETM adapter to directly collect trace data from the processor core and bus. For target machines that do not expose such interfaces, the target machine software is required to integrate a lightweight "monitoring agent" that periodically sends critical performance counters to the device's serial interface via shared memory or a dedicated message queue.

[0052] The functions of the anomaly self-healing and black box log module and the intelligent test data management module are mainly implemented by the main control module software, supplemented by a large-capacity, high-reliability industrial-grade eMMC storage chip (such as 128GB) for storing logs and test data. The storage management software adopts a log file system and implements AES-256 encryption.

[0053] The present invention also includes a method for autonomous testing of the entire flight control system based on the above-mentioned device, comprising the following steps:

[0054] Step S100: System Initialization and Task Preparation

[0055] After the device is powered on, the main control module initiates a self-test program, sequentially checking the output capabilities of the mode and power management module, the link status of the dual-mode communication module, local storage space, and the physical connection with the target machine. Upon successful self-test, the device loads a "test task list" from a preset network location or local storage. The task list is a structured file that defines the path to the target file under test, execution priority, test parameter configuration file, expected result template, and other information. The device parses the task list and initializes the context environment for each task item.

[0056] Step S200: Intelligent parameter matching and mode configuration

[0057] For the task to be executed, the main control module extracts the target file's characteristic information (such as filename, version number, size, and CRC32 checksum). It queries the local historical execution database to find historical task records with similar characteristics. If found, it prioritizes the mode configuration parameters (including loading mode level value, level hold time, power-on slope, etc.) corresponding to the historical task with the highest success rate and shortest execution time, replacing the default values ​​in the general configuration file. This intelligent matching mechanism can adapt to the characteristics of different software versions or different batches of hardware. Subsequently, the mode and power management module configures the corresponding output level according to the finally determined parameters. For new tasks without historical matches, the system will execute using preset general safety configuration parameters, and after successful execution, the configuration and results of this execution will be stored in the database as a reference for subsequent tasks.

[0058] Step S300: Startup process with minimal hardware intervention

[0059] The main control module first queries the target machine's current status (such as whether it is powered on and its current mode) through the communication module. Based on the query result, it executes one of the following three strategies:

[0060] 1. Strategy A (Cold Start): If the target machine is in a completely powered-off state, the control power module is powered on according to the "soft start curve". After power-on, the target machine is guided into loading mode according to the mode level configured in step S200.

[0061] 2. Strategy B (Hot Reset): If the target machine is powered on and in an idle state not under test, a software reset command is first sent to it through the communication interface. After the reset, the load mode level is immediately applied to guide it into the load mode, thus avoiding an unnecessary power-down-power-on cycle.

[0062] 3. Strategy C (Mode Switching): If the target machine is powered on and the current mode is compatible with the loading mode (e.g., switching from normal operation mode to loading mode), the mode control level is switched directly, completely omitting power operation. This "minimum intervention" strategy aims to minimize the electrical and mechanical stress on the target machine hardware.

[0063] Step S400: Target file loading and dynamic environment verification

[0064] The dual-mode communication module selects the optimal communication channel (e.g., Ethernet for large files, CAN bus for small files or files requiring low latency) to transmit the target file to the target machine based on factors such as file size and network conditions. During the loading process, the device establishes a loading handshake protocol with the target machine, transmitting and confirming in chunks, and recording the transmission rate and stability. After loading is completed, success is not immediately assumed. Instead, the device verifies the integrity, readiness, and runtime dependencies (such as library versions) of the file in the target machine's memory by calling environment check functions provided by the target machine or reading specific memory areas, generating a "loading quality report."

[0065] Step S500: Execution of comprehensive tests and real-time health monitoring

[0066] The main control module sends a start command to the target machine. Simultaneously, the test execution monitoring module starts, collecting preset monitoring indicators from the target machine at a high sampling rate (e.g., 10Hz). The monitoring data flows in real-time into the main control module's health analysis engine. This engine maintains a "dynamic health baseline," which is established based on the actual collected data at the beginning of the test (e.g., the first 5 seconds), and subsequently continuously compares the real-time data with the baseline. The monitoring content includes:

[0067] Computing resources: Whether the load rate of each CPU core exceeds the threshold (e.g., 90%), and whether there is core deadlock;

[0068] Memory resources: Is heap memory allocation continuously increasing (potential memory leak)? Is stack usage approaching overflow limits?

[0069] Task behavior: Whether critical periodic tasks are triggered on time, and whether the maximum execution time of non-periodic tasks is exceeded;

[0070] Communication status: Whether the data stream of the test result output channel is continuous and whether the frame error rate is abnormally high;

[0071] The health analysis engine uses a weighted algorithm to comprehensively evaluate various indicators and outputs a "system health" score in real time.

[0072] Step S600: Multi-level anomaly detection and intelligent self-healing

[0073] The anomaly self-healing and black box logging modules continuously monitor system health and critical alarms. Anomalies are categorized into three levels:

[0074] Level 1 anomaly (mild): such as a single instantaneous spike in CPU load or a single-frame communication error. Typically, only a log entry is recorded, and the test is not interrupted.

[0075] Level 2 Anomaly (Moderate): Such as a certain indicator deviating from the baseline for a certain period of time (e.g., CPU load > 85% for 10 seconds), or a critical task failing to execute on time twice consecutively. Triggering Primary Self-Healing: Sending a diagnostic query command to the target machine, or requesting the target machine to clean up non-core tasks and release cache, attempting to recover without interrupting the test;

[0076] Level 3 Anomaly (Severe): Such as a system health score consistently below the threshold, monitoring connection interruption, or target machine unresponsiveness. This triggers an advanced self-healing process, a multi-step decision chain:

[0077] a) Attempt a soft recovery: Send a forced task reset or system soft reset command via the communication interface;

[0078] b) If soft recovery fails, attempt hard recovery: Control the power module to perform a power-down (soft shutdown) - short delay (e.g., 2 seconds) - power-on (soft start) operation on the target machine, and then try to restart the current test case from step S300;

[0079] c) If the same test case fails again after a hard recovery, the test case is marked as a "blocked item", detailed "black box" data (including all monitoring data in the tens of seconds before the anomaly) is recorded, the test case is skipped, and the next test task in the task list is executed to ensure the overall execution progress of the test suite; all self-healing actions, decision-making basis and results are fully recorded.

[0080] Step S700: Intelligent acquisition, fusion analysis and secure archiving of results

[0081] After the target machine test is completed, it outputs the raw result data through the communication interface. Upon receiving the data, the device performs multi-layer verification:

[0082] 1. Syntax check: Used to check whether the data frame format, length, CRC, etc., conform to the protocol specifications.

[0083] 2. Semantic validation is used to parse the result content and compare key fields with similar results from the "expected result template" or historical successful cases to calculate similarity. For performance test results, it determines whether they are within a reasonable theoretical range.

[0084] 3. Timing verification, which is used to analyze whether the timing and order of the output results are consistent with the logical timing of the test cases, by combining the monitoring logs recorded during test execution.

[0085] After successful verification, the device timestamps and merges the original test results, loading quality report, full-process monitoring logs, system health curves, and anomaly and self-healing records, packaging them into an immutable "test record package" and assigning it a globally unique ID. This record package is first encrypted and saved to the "archived" area of ​​local solid-state storage. Subsequently, the device attempts to synchronously upload it to a designated host computer or cloud test management platform. Only after receiving a "storage successful" confirmation from the remote storage system will the device move the original target file corresponding to this test from the "pending execution" directory to the "executed_archived" directory. If the upload fails, the file will remain in the "pending execution" directory, and the archived data package will be retransmitted during the next task scheduling, thus absolutely ensuring the reproducibility of the test process.

[0086] Step S800: Loop Scheduling and Dynamic Task Management

[0087] After completing the entire process of a test case, the main control module updates the task list status and determines:

[0088] If there are still tasks to be performed in the list, the device will seamlessly jump to step S200 to execute the next task. If all tasks are completed, the device will send a test summary report to the host computer and enter a low-power monitoring mode. Throughout the entire test cycle, the device's network service will always be enabled, and it can receive new task injections, configuration file updates, log extraction requests or remote diagnostic commands from the host computer at any time, so as to realize dynamic management of test tasks and remote operation and maintenance of the system.

[0089] Combination Figure 2-4 Let's take the execution process of a specific regression test suite as an example:

[0090] Task preparation (S100): After the device starts up and passes the self-test, it retrieves a task list named "Regression_Suite_V2.1.xml" from the internal FTP server. The list contains 50 test cases, each associated with a .elf object file.

[0091] Intelligent Matching (S200): Execute the first use case TC_001.elf. The main control module calculates its hash value and searches in the local history database. It finds that the same version of the file loaded a week ago was most stable when loaded with "load mode level = 3.3V, hold time = 800ms", so this parameter is adopted instead of the default value in the configuration file (3.3V, 500ms).

[0092] Minimal Startup (S300): Upon inspection, the target device is in an idle power-on state (applicable to Strategy B). The device sends a soft reset command to the target device via the CAN bus, and then immediately pulls the mode control line high to 3.3V and holds it for 800ms. The target device successfully enters the loading mode. This startup saves one complete power-down-power-on operation.

[0093] Loading and Verification (S400): The TC_001.elf file (15MB in size) is transmitted to the target machine in chunks via Gigabit Ethernet. After loading is complete, the device calls the target machine's proxy function to verify that all code segments are correctly verified and that the versions of dependent math libraries match. Loading took 1.8 seconds, with a stable rate, and was recorded as a high-quality load.

[0094] Execution and Monitoring (S500): Startup Test. The monitoring module reads the target machine's CPU load and task switching information at 10ms intervals via the JTAG interface. For the first 30 seconds, the system health score remains stable at 95 points (Excellent).

[0095] Anomaly Self-Healing (S600): At the 35th second, monitoring detected a sudden and continuous increase in stack usage for a low-priority background task, triggering a level 2 anomaly. Primary Self-Healing Initiation: The device sends a command to the target machine via the debug interface to suspend the suspicious task. Stack growth stops, health recovers, the main test process is unaffected, and self-healing is successfully logged.

[0096] Results Archiving (S700): The test ended normally after 120 seconds, and the result data was transmitted back via UART. After the device verification passed, the result data, along with the previously generated loading report, 35-second anomaly and self-healing monitoring records, etc., were packaged into a TestRecord_TC001_date_sequence.pkg file, which was then encrypted and saved to the local / archive / directory. Subsequently, an automatic upload to the cloud storage oss: / / test-bucket was initiated, and an HTTP 200 response indicating successful upload was received after 5 seconds. Only after receiving the response did the device rename the TC_001.elf file on the server to TC_001.elf.archived.

[0097] Cyclic Scheduling (S800): The device automatically processes TC_002.elf in the list, repeating the above process. All 50 test cases were completed unattended within 4 hours, during which 3 level 2 exceptions were handled, no level 3 exceptions occurred, and all test record packages were successfully archived locally and in the cloud.

Claims

1. A fully autonomous testing device for a flight control system, characterized in that, include: The main control module is used to execute test process control and decision-making logic; The mode and power management module is connected to the main control module and is used to generate programmable power control signals and mode control level signals according to instructions, so as to control the power-on, power-off and working mode switching of the target machine. A dual-mode communication module, connected to the main control module, is used to realize data communication with the host computer, the target machine, and the remote server; The test execution monitoring module is connected to the main control module and the dual-mode communication module, and is used to collect the internal runtime status indicators in real time when the target machine is performing tests. An anomaly self-healing and logging module, connected to the main control module, is used to detect anomalies based on the runtime status indicators, trigger predefined self-healing strategies, and record system operation logs. as well as The intelligent test data management module, connected to the main control module, is used for secure storage, version management, and lifecycle management of test target files, test result data, and process logs.

2. The autonomous testing device for the entire flight control system according to claim 1, characterized in that: The mode and power management module includes a programmable multi-channel power output unit and a digital I / O control unit, which supports soft-start and soft-shutdown control of the power supply to the target machine, and can monitor the output voltage and current.

3. The autonomous testing device for the entire flight control system according to claim 1, characterized in that: The test execution monitoring module collects at least two of the following indicators through the target machine's hardware debugging interface or software monitoring agent interface: CPU utilization, memory usage, task status timing, interrupt statistics, and communication error rate.

4. The autonomous testing device for the entire flight control system according to claim 1, characterized in that: The anomaly self-healing and logging module has a built-in rule engine that can define multi-level anomaly thresholds and corresponding self-healing action sequences. The self-healing action sequences include sending diagnostic or reset commands to the target machine, controlling the target machine to partially power down and then power on again, and skipping the current test case and recording the anomaly context.

5. The autonomous testing device for the entire flight control system according to claim 1, characterized in that: The intelligent test data management module uses copy-on-write and incremental backup technology to manage test files, and is configured to only transfer or clean up the original test target files after confirming that the test result data has been successfully archived to local and remote storage.

6. A method for autonomous testing of the entire flight control system based on the device described in any one of claims 1-5, characterized in that, Including the following steps: S1: Device initialization, self-test and loading of test task list; S2: Intelligently matches the best historical mode and power supply configuration parameters for the current test task; S3: Based on the current state of the target machine, select to execute a cold start, hot reset, or direct mode switching strategy to guide the target machine into loading mode with minimal hardware intervention; S4: Load the test target file onto the target machine and perform an environment integrity check after loading; S5: Start test execution and monitor the target machine's operating status in real time across all dimensions, and calculate system health; S6: Perform multi-level anomaly detection based on monitoring results and execute corresponding intelligent self-healing processes; S7: Collect test results, perform multi-level verification, and integrate and package the result data with process monitoring logs, securely archive them to local and remote storage, and update the status of the original test files only after successful archiving; S8: Repeat steps S2 through S7 until all test tasks are completed.

7. The method for autonomous testing of the entire flight control system according to claim 6, characterized in that, The intelligent matching in step S2 specifically involves: extracting the feature information of the current test target file, querying the historical execution database, selecting the task record that is similar to the current file in features and has the highest historical execution success rate and shortest execution time, and adopting the mode and power supply configuration parameters used by that task.

8. The method for autonomous testing of the entire flight control system according to claim 6, characterized in that, The hot reset strategy in step S3 is as follows: when the target machine is powered on and in an idle state, a software reset command is first sent to it through the communication interface, and then the control level required for the loading mode is immediately applied to guide it into the loading mode and avoid performing a power-down operation.

9. The method for autonomous testing of the entire flight control system according to claim 6, characterized in that, The full-dimensional real-time monitoring in step S5 includes establishing a dynamic health baseline at the beginning of the test, and continuously comparing the real-time collected indicators with the baseline, and outputting a comprehensive system health score through a weighted algorithm.

10. The method for autonomous testing of the entire flight control system according to claim 6, characterized in that, The secure archiving in step S7 specifically includes: generating an encrypted data packet for each test case containing the original test results, process monitoring logs, exception records, and loading reports, and assigning a unique ID; first storing it in local non-volatile memory, and then attempting to synchronously upload it to a remote server; only after receiving confirmation of successful remote storage will the corresponding original test target file be marked as archived.

Images