Method, device and equipment for testing and verifying task management computer of unmanned aerial vehicle and medium

Abstract

This application discloses a method, apparatus, device, and medium for testing and verifying a mission management computer for unmanned aerial vehicles (UAVs), relating to the field of testing and verification technology. The method includes: loading an embedded binary program into the storage space of a first simulation node; after the testing and verification system is started and initialized based on the embedded binary program, acquiring simulation stimulus data through a physical entity node and transmitting it to the first simulation node via a target communication middleware; using the first simulation node to drive the embedded binary program to generate UAV control commands based on the simulation stimulus data, and sending them to a second simulation node via the target communication middleware, so that the second simulation node can feed back simulation status data of the target UAV to the first simulation node; processing the data through the first simulation node to obtain new simulation stimulus data, and then jumping to the step of driving the embedded binary program to generate UAV control commands, until the program execution is complete, thereby ending the testing and verification of the mission management computer.

Description

Technical Field

[0001] This invention relates to the field of testing and verification technology, and in particular to a method, apparatus, equipment, and medium for testing and verifying a mission management computer for unmanned aerial vehicles (UAVs). Background Technology

[0002] Unmanned aerial vehicle (UAV) mission management computers (MMCs) typically use dedicated processors (such as PowerPC, a reduced instruction set architecture central processing unit commonly used in aerospace and embedded systems) and real-time operating systems (RTOS, an operating system used for high-real-time requirements such as multi-task scheduling and interrupt management). Their embedded programs usually must run on specific hardware platforms. Besides the most time-consuming and labor-intensive final field verification, traditional system verification methods mainly rely on: Model-level simulation: Constructing the mission logic framework through high-level models, this can only be based on the logic layer model but cannot execute real embedded binary programs. The simulation results deviate from the actual hardware operating state and cannot discover low-level and boundary problems. Process simulation and interface data simulation: Only simulating input and output data flows, without involving instruction-level execution and peripheral behavior. Hardware-in-the-loop (HIL) simulation: Relying on physical MMC hardware, it is necessary to wait for the manufacturing and delivery of the physical MMC hardware. Other external modules provide relevant hardware signals and bus data through test equipment, resulting in delayed software system cascading and a long development cycle.

[0003] In summary, the urgent problem to be solved is how to address the issue that the software development and system integration of drone MMC heavily rely on physical hardware, resulting in long R&D cycles, difficult testing, and low verification efficiency. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a method, apparatus, equipment, and medium for testing and verifying the mission management computer (MMC) of unmanned aerial vehicles (UAVs), which can solve the problems of UAV MMC software development and system integration heavily relying on physical hardware, resulting in long R&D cycles, difficult testing, and low verification efficiency. The specific solution is as follows: Firstly, this application provides a method for testing and verifying a mission management computer for an unmanned aerial vehicle (UAV), applied to a test and verification system for a target UAV. The test and verification system includes physical entity nodes, a target communication middleware, and a target simulation node. The physical entity nodes include an excitation monitoring node, and the target simulation node includes a first simulation node corresponding to the mission management computer and second simulation nodes corresponding to other subsystems in the target UAV besides the mission management computer. The method includes: Load the embedded binary program to be verified from the task management computer into the storage space of the first simulation node; After the test and verification system is started and initialized based on the embedded binary program, it obtains simulation stimulus data through the physical entity node and transmits it to the first simulation node through the target communication middleware. The first simulation node drives the embedded binary program to generate UAV control commands based on the simulation stimulus data, and sends them to the second simulation node through the target communication middleware. The second simulation node then feeds back the simulation status data of the target UAV to the first simulation node based on the UAV control commands and through the target communication middleware. The simulation state data is processed by the first simulation node to obtain new simulation stimulus data, and then the process jumps to the step of driving the embedded binary program to generate UAV control commands based on the simulation stimulus data through the first simulation node, until the embedded binary program is completed, thereby ending the test and verification of the mission management computer for the target UAV.

[0005] Optionally, before loading the embedded binary program to be verified from the task management computer into the storage space of the first simulation node, the method further includes: The target communication middleware is deployed, and the first simulation node and the second simulation node are configured according to the drone system of the target drone.

[0006] Optionally, the startup and initialization based on the embedded binary program includes: The target simulation node is started so that the first simulation node executes the embedded binary program to perform RTOS boot, driver initialization and application task creation, and establishes data connections with the second simulation node and the physical entity node through the target communication middleware.

[0007] Optionally, the step of driving the embedded binary program to generate UAV control commands based on the simulation stimulus data through the first simulation node, and sending them to the second simulation node through the target communication middleware, so that the second simulation node, based on the UAV control commands and through the target communication middleware, feeds back the simulation status data of the target UAV to the first simulation node, includes: The processor of the first simulation node simulates the sub-node, and the embedded binary program is driven to generate UAV control commands through the virtual bus interface based on the simulation stimulus data. The UAV control commands are converted into structured data adapted by the target communication middleware through the middleware adaptation sub-node of the first simulation node, so as to publish the structured data to the second simulation node through the target communication middleware. The structured data is processed by the second simulation node to generate simulation state data of the target UAV, and the simulation state data is fed back to the first simulation node through the target communication middleware.

[0008] Optionally, the step of processing the simulation state data through the first simulation node to obtain new simulation stimulus data includes: The simulation state data is converted into new simulation stimulus data adapted to the embedded binary program through the virtual bus interface of the first simulation node.

[0009] Optionally, the execution of the embedded binary program includes: The target data is monitored and recorded in real time by the excitation monitoring node so that after the embedded binary program is executed, playback, performance analysis and fault diagnosis can be performed based on the target data; the target data is a number of data generated during the execution of the embedded binary program.

[0010] Optionally, the execution of the embedded binary program further includes: The excitation monitoring node performs read and write control on the virtual bus interface of the first simulation node to inject communication anomalies into the processor simulation sub-node of the first simulation node, and propagates the anomalies through the middleware adapter sub-node of the first simulation node and the target communication middleware to perform robustness verification of the embedded binary program under real runtime conditions.

[0011] Secondly, this application provides a test and verification device for a mission management computer of an unmanned aerial vehicle (UAV), applied to a test and verification system for a target UAV. The test and verification system includes physical entity nodes, a target communication middleware, and a target simulation node. The physical entity nodes include an excitation monitoring node, and the target simulation node includes a first simulation node corresponding to the mission management computer and second simulation nodes corresponding to other subsystems of the target UAV besides the mission management computer. The device includes: The program loading module is used to load the embedded binary program to be verified from the task management computer into the storage space of the first simulation node. The data transmission module is used to acquire simulation stimulus data through the physical entity node after the test and verification system is started and initialized based on the embedded binary program, and transmit it to the first simulation node through the target communication middleware. The instruction sending module is used to drive the embedded binary program to generate UAV control instructions based on the simulation stimulus data through the first simulation node, and send them to the second simulation node through the target communication middleware, so that the second simulation node can feed back the simulation status data of the target UAV to the first simulation node based on the UAV control instructions and through the target communication middleware; The step jump module is used to process the simulation state data through the first simulation node to obtain new simulation stimulus data, and jump to the step of driving the embedded binary program to generate UAV control instructions based on the simulation stimulus data through the first simulation node, until the embedded binary program is completed, so as to end the test and verification of the mission management computer for the target UAV.

[0012] Thirdly, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor is used to execute the computer program to implement the aforementioned computer test and verification method for the task management of unmanned aerial vehicles.

[0013] Fourthly, this application provides a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned computer test and verification method for the task management of unmanned aerial vehicles.

[0014] In this application, the embedded binary program to be verified from the task management computer is loaded into the storage space of the first simulation node; after the test verification system starts and initializes based on the embedded binary program, simulation stimulus data is obtained through the physical entity node and transmitted to the first simulation node through the target communication middleware; through the first simulation node, the embedded binary program is driven to generate UAV control commands based on the simulation stimulus data, and sent to the second simulation node through the target communication middleware, so that the second simulation node, based on the UAV control commands and through the target communication middleware, feeds back the simulation status data of the target UAV to the first simulation node; the simulation status data is processed by the first simulation node to obtain new simulation stimulus data, and then the process jumps to the step of driving the embedded binary program to generate UAV control commands based on the simulation stimulus data through the first simulation node, until the embedded binary program is completed, thereby ending the MMC test verification of the target UAV. As can be seen from the above, this application loads the embedded binary program to be verified on the task management computer into the storage space of the first simulation node. After the test and verification system is started and initialized, the physical entity node obtains the simulation stimulus data and transmits it to the first simulation node through the target communication middleware. The node uses the simulation stimulus data to drive the embedded binary program to generate UAV control commands, which are then sent to the second simulation node through the target communication middleware, so that the node can provide feedback on the simulation status data. The first simulation node processes the simulation status data to obtain new simulation stimulus data and executes it in a loop until the program finishes running, thus completing the UAV MMC test and verification. In this way, by directly loading the embedded binary program onto the first simulation node corresponding to the task management computer through the process described in this application, the real operating environment can be reproduced to the greatest extent, improving the authenticity and credibility of the test verification. By obtaining stimuli through physical nodes and relying on the target communication middleware to realize multi-node data interaction, the simulation data transmission can be ensured to be stable and the interaction is efficient. The closed-loop iterative driver operation and continuous updating of stimulus data can fully cover the program execution process, comprehensively verify the control logic and operational reliability of the embedded program in the dynamic simulation scenario, and thus solve the problem that the software development and system integration of UAV MMC heavily rely on physical hardware, resulting in long R&D cycles, difficult testing, and low verification efficiency. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0016] Figure 1 This application discloses a flowchart of a computer test and verification method for the mission management of an unmanned aerial vehicle (UAV). Figure 2 This is a flowchart illustrating a computer testing and verification method for the mission management of an unmanned aerial vehicle (UAV) disclosed in this application. Figure 3 This is an architectural block diagram of a test and verification system disclosed in this application; Figure 4 This is a block diagram of the architecture of a target simulation node disclosed in this application; Figure 5 This is a schematic diagram of the structure of a mission management computer test and verification device for an unmanned aerial vehicle (UAV) disclosed in this application; Figure 6 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Besides the most time-consuming and labor-intensive final field verification, traditional system verification methods mainly rely on: Model-level simulation: Constructing the task logic framework through high-level models, this method can only be based on the logic layer model but cannot execute real embedded binary programs. The simulation results deviate from the actual hardware operating state and cannot discover underlying and boundary problems. Process simulation and interface data simulation: Only simulating input and output data flows, without involving instruction-level execution and peripheral behavior. Hardware-in-the-loop simulation: Relying on physical MMC hardware, it is necessary to wait for the manufacturing and delivery of the physical MMC hardware. Other external modules provide relevant hardware signals and bus data through test equipment, resulting in delayed software system cascading and debugging progress and long development cycles.

[0019] To overcome the aforementioned technical problems, this application provides a test and verification method for a UAV's mission management computer, which can solve the problem that the software development and system integration of UAV MMC heavily rely on physical hardware, resulting in long R&D cycles, difficult testing, and low verification efficiency.

[0020] See Figure 1As shown, this invention discloses a method for testing and verifying a mission management computer for a UAV, applied to a test and verification system for a target UAV. The test and verification system includes physical entity nodes, a target communication middleware, and a target simulation node. The physical entity nodes include an excitation monitoring node, and the target simulation node includes a first simulation node corresponding to the mission management computer and second simulation nodes corresponding to other subsystems in the target UAV besides the mission management computer. The method includes: Step S11: Load the embedded binary program to be verified from the task management computer into the storage space of the first simulation node.

[0021] In this embodiment, the final version of the RTOS to be verified, along with embedded binary programs (such as xx.elf, xx.bin, xx.hex) on the task management computer, is loaded into the storage space of the first simulation node. The task management computer is the core computing unit of the UAV mission system, responsible for mission planning, route control, payload scheduling, and other tasks. The embedded binary programs are machine code files (such as executable files for PPC (PowerPC) architecture) generated by compiling and linking source code.

[0022] It should be noted that, in order to address the problem that the software development and system integration of core controllers (such as mission management computers) in complex embedded systems like UAVs heavily rely on physical hardware, leading to long R&D cycles, difficulties in testing in high-risk scenarios, and high costs for field verification, this application proposes a testing and verification method for the mission management computer of UAVs, such as... Figure 2 The diagram shows a flowchart of a test and verification method for a UAV mission management computer provided in this application. This method enables the final version of the embedded binary program of the mission management computer to run in a purely digital environment without physical onboard hardware, exhibiting zero modifications and full realism. It possesses instruction execution, peripheral behavior, system scheduling, and interface timing characteristics consistent with real hardware, achieving high-fidelity, fully closed-loop system-level verification. Specifically, it proposes a fully digital closed-loop test and verification system for unmodified embedded software based on instruction set-level simulation. This system constructs a virtual environment on a general-purpose computing platform that is functionally and temporally equivalent to the real hardware environment. It directly loads and runs the final binary program of the target embedded system, forming a closed loop with a high-precision simulation model to achieve system-level verification. Figure 3The diagram shows the architecture of a test and verification system provided in this application. The system uses a real-time data distribution middleware (DDS, Data Distribution Service, a data-centric communication middleware for real-time systems, used for data synchronization between simulation nodes), i.e., the target communication middleware, as its core hub, connecting virtual nodes (the UAV system simulation layer), i.e., the target simulation node, and physical nodes (the external interface and monitoring layer), i.e., the physical entity nodes. The external interface and monitoring layer includes an excitation and monitoring terminal: used for scene editing, fault injection, full data excitation, recording, and real-time analysis, corresponding to the excitation and monitoring node; and a real ground station and visual system: accessing the real ground station, joystick, display screen, and 3D visual system, ensuring that the flight control / payload / mission interfaces are all consistent with reality, and constructing an immersive mission environment in conjunction with the real 3D visual system. Real operation signals (such as joystick pull-up control) or data excitation and monitoring signals are converted into DDS messages. The core hub layer includes the real-time data distribution middleware (the target communication middleware): serving as the system's communication middleware, providing unified clock, data subscription / publishing, and service discovery functions. The data format, frequency, and protocol of all interactions between nodes are consistent with those of a real UAV system. The UAV system simulation layer includes a mission management computer system simulation (core): this is the first simulation node, which interacts with DDS through its internal virtual bus simulation module. Its core consists of a processor core simulation module, a peripheral simulation module, and a bus simulation module, used to directly execute the final binary program of the MMC (including the operating system and applications). Other subsystem simulations: these are the second simulation nodes, including flight control systems, navigation systems, radar systems, etc., which are equivalently replaced by high-precision source code-level or functional-level mathematical models and accessed through DDS. It is understood that, in addition to DDS, the target communication middleware can also use other middleware conforming to a similar real-time publish-subscribe model, such as certain customized communication frameworks based on shared memory or reflected memory, as long as they can provide a defined low latency and data space. For other subsystem simulation nodes (such as flight control and dynamics models), the accuracy of their internal simulation models can be adjusted according to the requirements of the testing phase, provided that the consistency with the MMC interaction interface is not affected. For example, a simplified model can be used to improve simulation speed during early logic testing. In addition, the physical interface adapter layer can be completely replaced by a virtual control interface in addition to connecting to a real ground station. The control commands generated by the interface are also injected into the system through DDS, which is suitable for testing in a pure software environment.

[0023] It should be further pointed out that the target simulation node is key to achieving hardware equivalent simulation, as it reconstructs the hardware topology on the host machine upon which the processor of a real MMC depends for operation. For example... Figure 4The diagram shows an architecture block diagram of a target simulation node provided in this application. Based on the constructed virtual MMC hardware simulation, the real MMC program can be run directly without modification. Then, through the middleware adaptation layer, data interaction between multiple nodes within the system is realized, forming a fully digital closed-loop verification test. Among them, the processor core simulation layer includes a processor core simulation module: accurately simulating the core hardware of the target processor (such as PowerPC), such as the instruction set, general-purpose registers, memory management unit (MMU), cache, and timers, to ensure that the execution result and timing of each machine instruction are equivalent to the real hardware. The virtual hardware peripherals and bus interface layer includes a peripheral simulation module: This module simulates internal processor peripherals (such as serial ports, interrupts, timers, network cards, etc.) and external processor peripherals (storage peripherals, AD (Analog-to-Digital) acquisition peripherals, etc.) at the register level. It implements the register read / write logic and timing control for driving the peripheral simulation model. MMC software's register read / write operations directly drive this layer. The bus simulation module implements complete simulation of the protocol stack, communication mechanisms, and timing behavior of interfaces such as the register-level 1553B bus (MIL-STD-1553B, a data bus standard for communication between military avionics equipment, characterized by high reliability and real-time performance) and RS422 bus (a data transmission protocol). Inter-system buses exchange data via DDS. The MMC real program layer, based on the processor core simulation layer and the virtual hardware peripherals and bus interface layer, enables the direct booting and running of unmodified MMC real programs, including real-time operating system images and applications, on the fully digital real-time simulated virtual processor. System calls, interrupt handling, and task scheduling on the all-digital real-time simulation platform ensure that the scheduling behavior of the real-time operating system is consistent with the real hardware environment. The middleware adaptation layer, acting as a bridge between the virtual bus and the DDS middleware, performs the following functions: Protocol conversion: converting raw bus data frames (such as 1553B message words) received by the virtual bus interface layer into structured data topics recognizable by DDS according to a predefined mapping relationship for publication; Data injection: converting structured data subscribed from DDS (such as status information from the flight control model) into raw data frames conforming to the bus protocol and writing them into the corresponding receive buffer of the virtual bus interface layer, simulating external devices sending data to the MMC.

[0024] It should be noted that before loading the embedded binary program (i.e., S02), a fully digital simulation environment (i.e., S01) needs to be constructed first. The corresponding processing flow is as follows: the target communication middleware is deployed, and the first simulation node and the second simulation node are configured according to the UAV system of the target UAV. That is, the target communication middleware is deployed, and the first simulation node (processor, peripheral model) and the second simulation node (other subsystem simulation node models) are configured according to the system design of the target UAV. In this way, this embodiment directly loads the embedded binary program to be verified into the simulation node's storage space, allowing the program to run in a near-realistic simulation environment, laying the foundation for subsequent testing and verification. Deploying the target communication middleware enables stable and unified data interaction between simulation nodes. Combined with the separate configuration of each simulation node within the UAV system, the simulation environment is matched consistently with the real UAV system, ensuring the accuracy and compatibility of subsequent simulation tests. A virtual processor with instruction set-level precise simulation and a peripheral and bus environment with register-level behavioral simulation are constructed, enabling the final embedded binary program of MMC to achieve zero-modification, equivalent hardware-level, fully realistic operation without hardware limitations. Its execution process, task scheduling, and interrupt response are completely consistent with real hardware, making testing and verification work virtually identical to the hardware. Production is carried out in parallel, compressing the overall R&D cycle from design to verification. Simulation of peripherals such as processors, registers, clocks, and interrupts is implemented on the software platform, enabling the real software to run directly and test the bus logic function and data flow correctness. This provides comprehensive and reproducible testing capabilities for internal software logic, bus communication, and exception handling. A bus communication closed loop equivalent to the actual UAV system is constructed in a fully digital environment, achieving consistent data frame format, protocol, and timing with external systems. This not only provides high-fidelity simulation of the MMC itself but also seamlessly integrates high-precision flight control, navigation, and sensor models through real-time data distribution services. This constructs a complete digital twin with data flow, protocol, and timing completely consistent with the real UAV system, and can be connected to real ground station hardware, improving verification confidence and the effectiveness of practical training.

[0025] Step S12: After the test and verification system is started and initialized based on the embedded binary program, simulation stimulus data is obtained through the physical entity node and transmitted to the first simulation node through the target communication middleware.

[0026] In this embodiment, after the test verification system starts and initializes based on the loaded embedded binary program (i.e., S03), it executes the test scenario (S04). The physical entity node obtains the simulation stimulus data, that is, the tester injects stimulus (such as sending ground station commands and setting environmental parameters) and monitors (such as UAV altitude, speed, pitch angle, and GPS (Global Positioning System) position) through the stimulus and monitoring terminal, the real ground station and the visual system, and transmits it to the first simulation node through the target communication middleware.

[0027] It should be noted that the process of starting and initializing based on the embedded binary program is as follows: The target simulation node is started so that the first simulation node executes the embedded binary program, performs RTOS booting, driver initialization, and application task creation, and establishes a data connection with the second simulation node and the physical entity node through the target communication middleware. That is, starting the target simulation node allows the first simulation node to execute the embedded binary program from the entry address, complete RTOS booting, driver initialization, and application task creation, and establish a DDS data connection with the second simulation node and the physical entity node through the target communication middleware. In this way, this embodiment obtains simulation stimulus data through the physical entity node, ensuring that the stimulus data closely resembles the real operating scenario and improving the realism of the test; transmitting data through the target communication middleware enables stable and reliable data interaction, providing accurate input for subsequent program driving and simulation execution; the complete execution of RTOS booting, driver initialization, and task creation on the first simulation node realistically restores the embedded system startup process, improving the completeness of the test verification; and establishing multi-node data connections based on the target communication middleware enables data interoperability between simulation stages, ensuring the stable and collaborative operation of the entire test verification process.

[0028] Step S13: The first simulation node drives the embedded binary program to generate UAV control commands based on the simulation stimulus data, and sends them to the second simulation node through the target communication middleware, so that the second simulation node can feed back the simulation status data of the target UAV to the first simulation node based on the UAV control commands and through the target communication middleware.

[0029] In this embodiment, closed-loop operation and data interaction begin (i.e., S05). The first simulation node drives the embedded binary program to generate UAV control commands based on the simulation stimulus data, and sends them to the second simulation node via the target communication middleware. The second simulation node then feeds back the simulation status data of the target UAV to the first simulation node based on the commands and through the target communication middleware.

[0030] Specifically, the processor simulation sub-node of the first simulation node drives the embedded binary program to generate UAV control commands through a virtual bus interface based on the simulation stimulus data; the middleware adaptation sub-node of the first simulation node converts the UAV control commands into structured data adapted by the target communication middleware, so as to publish the structured data to the second simulation node through the target communication middleware; the second simulation node performs calculations on the structured data to generate simulation status data of the target UAV, and feeds back the simulation status data to the first simulation node through the target communication middleware. That is, the processor simulation sub-node of the first simulation node drives the embedded binary program according to the simulation stimulus data. The program software runs control logic in the instruction set simulation layer, that is, the processor core simulation layer, and generates UAV control commands through the virtual bus interface. Then, the middleware adaptation sub-node of the first simulation node, that is, the middleware adaptation layer, converts the commands into structured data adapted to the target communication middleware and publishes it to the second simulation node (flight control / power simulation node, etc.). After the flight control / power model of the second simulation node solves the data, it generates new aircraft state data (position, attitude), that is, the simulation state data of the target UAV, which is transmitted back to the first simulation node through the target communication middleware. In this way, this embodiment utilizes simulation-driven excitation data to generate control commands, realistically replicating the UAV control logic; communication middleware enables interaction between commands and status data, ensuring smooth collaboration between nodes and making simulation testing closer to actual operating scenarios; using processor simulation sub-nodes combined with virtual bus interfaces to generate control commands can highly replicate the real hardware operating logic; middleware adapts sub-nodes to complete data format conversion, ensuring data compatibility and interoperability between different nodes; and using a second simulation node to calculate and feed back status data forms a complete closed-loop interaction, improving the realism and accuracy of simulation testing.

[0031] Step S14: Process the simulation state data through the first simulation node to obtain new simulation stimulus data, and jump to the step of driving the embedded binary program to generate UAV control commands based on the simulation stimulus data through the first simulation node, until the embedded binary program is completed, so as to end the test and verification of the mission management computer for the target UAV.

[0032] In this embodiment, the first simulation node processes the received simulation state data to generate new simulation stimulus data, and repeatedly executes the step of the driver program generating control instructions. The driver program software continues to execute, forming a complete closed loop, until the embedded binary program finishes execution, thus completing the test and verification of the target UAV's mission management computer.

[0033] It should be noted that the processing flow for processing the simulation state data through the first simulation node to obtain new simulation stimulus data is as follows: the simulation state data is converted into new simulation stimulus data adapted to the embedded binary program through the virtual bus interface of the first simulation node. That is, the first simulation node converts the simulation state data in reverse into new simulation stimulus data that can be adapted to the embedded binary program through the virtual bus interface, which is the sensor or bus signal expected by the program software. It should be further noted that during the execution of the embedded binary program, monitoring, recording and analysis (i.e., S06) are also required, and the processing flow is as follows: the target data is monitored and recorded in real time through the stimulus monitoring node so that after the embedded binary program is completed, playback, performance analysis and fault diagnosis can be performed based on the target data; the target data is a number of data generated during the execution of the embedded binary program. That is, the incentive monitoring node monitors and records the target data during the operation of the embedded binary program in real time, and the incentive and monitoring terminal subscribes to and displays all key data in real time, including but not limited to all instruction execution, bus communication and system status data. After the program is executed and the test is completed, playback, performance analysis and fault diagnosis are performed based on the data.

[0034] It should be noted that, to support system-level anomaly verification, this embodiment provides a controllable anomaly injection interface in the virtual hardware peripheral and bus interface layer to introduce an anomaly injection mechanism. In the register-level peripheral simulation model, the bus controller registers, communication buffers, and interface state machines are accurately modeled, allowing read / write control of relevant registers and data areas via excitation and monitoring terminals. This allows for the injection of communication anomalies, including message loss, data word errors, frame anomalies, communication timeouts, and protocol timing anomalies, into the virtual 1553B, RS422, or other interfaces without modifying the software program. Simultaneously, the processor core simulation layer provides controllable access interfaces to register files, memory space, and interrupt control logic, enabling testers to modify the contents of specific registers or memory units during software execution, or trigger abnormal interrupts and illegal accesses to simulate boundary or fault states in a real hardware environment. This anomaly injection mechanism can be dynamically triggered during system closed-loop operation and, through the middleware adaptation layer and real-time data interaction mechanism, allows anomaly states to propagate in real time between target simulation nodes, thereby achieving anomaly verification under complete closed-loop conditions. Therefore, during the execution of the embedded binary program, fault or boundary condition injection (i.e., S07) can also be performed, which can be embedded in the execution process of S04 or S05. The processing flow is as follows: the excitation monitoring node performs read and write control on the virtual bus interface of the first simulation node to inject communication exceptions into the processor simulation sub-node of the first simulation node, and the exceptions are propagated through the middleware adaptation sub-node of the first simulation node and the target communication middleware to verify the robustness of the embedded binary program under real runtime conditions. That is, the fault injection mechanism relies on the processor core simulation layer, the virtual hardware peripheral and bus interface layer, and the middleware adaptation layer to achieve collaborative implementation. It can implement exception injection in the running state where the program software is continuously executing and participating in the closed-loop data interaction of the system. Unlike the general simulation test method that only supports configuring exceptions or independently executing exception simulations before the test starts, the fault injection in this embodiment can be dynamically triggered according to test requirements during the closed-loop operation of the system, and can be embedded in the test scenario execution process of step S104 or the real-time data interaction process between nodes in step S105, thereby ensuring that the system is in a real runtime state when exception injection occurs. Specifically, the incentive monitoring node performs read and write control on the virtual bus interface of the first simulation node, injects communication anomalies into the processor simulation sub-node, and propagates the anomalies between the middleware adaptation sub-node and the target communication middleware, thereby performing robustness verification on the embedded binary program under real runtime conditions.In other words, the excitation and monitoring terminal controls the register-level bus model through the virtual bus interface layer. Without altering the binary program, it injects protocol-level faults such as message loss, data word errors, frame anomalies, communication timeouts, or timing anomalies into the virtual 1553B bus or other communication interfaces to simulate link anomalies that may occur in real airborne systems. Simultaneously, relying on the processor core simulation layer's precise simulation capabilities of the target processor's instruction set, registers, and memory space, it can directly modify the virtual processor's register values ​​or memory unit contents during software execution, or trigger abnormal interrupts, illegal accesses, and boundary states. This simulates abnormal conditions that are difficult to implement safely in a real hardware environment, thereby verifying the MMC software's anomaly handling logic and system stability. The aforementioned fault injection operations can be implemented on demand during system closed-loop operation and can propagate between simulation nodes through a real-time publish-subscribe data interaction mechanism, allowing abnormal states to participate in closed-loop feedback, thus achieving high-precision robustness verification of the MMC software under real runtime timing conditions. Since the fault injection in this embodiment relies on register-level simulation models and closed-loop operating environments, it can implement precise anomaly control during the actual execution of the software, rather than just performing general anomaly simulation. Therefore, it is significantly superior to existing all-digital simulation testing methods in terms of anomaly control accuracy, execution timing flexibility, and system-level verification depth.

[0035] It is understood that the method of this embodiment is not only applicable to MMCs based on PowerPC and VxWorks (an embedded real-time operating system), but also to embedded systems using other processor architectures (such as ARM and MIPS) and operating systems (such as FreeRTOS, µC / OS, Linux, etc.). It is not only applicable to UAV mission management computers, but can also be widely applied to any complex system requiring early and deep verification of highly reliable embedded software, such as satellites, missiles, avionics, and vehicle controllers. The high-fidelity digital twin environment built based on this embodiment can be directly used as a virtual flight training system, a mission process simulation platform, and a human-computer interaction evaluation system, achieving multiple uses from a single platform. In this embodiment, state data processing is used to generate new stimuli and run in a closed-loop iterative manner. This continuously simulates dynamic flight scenarios, covering the entire embedded program execution process and cyclically verifying until the program ends. This comprehensively verifies the logical correctness and operational stability of the task management computer under real-world conditions. The virtual bus interface is used to convert simulation state data to stimulus data, ensuring precise matching between feedback data and embedded program execution specifications. This guarantees a smooth connection in the closed-loop simulation process and improves the realism and consistency of testing and verification. Real-time recording of operational data by stimulus monitoring nodes, along with playback and analysis based on the full dataset, completely preserves information throughout the program execution process. This allows for precise problem localization and performance evaluation, improving the traceability and diagnostic efficiency of testing and verification. Injecting communication anomalies through the virtual bus interface and relying on real runtime sequences for anomaly propagation and verification enables controllable and reproducible boundary conditions and fault injection in pure digital simulation. This simulates communication faults in real-world scenarios and improves the handling of extreme situations. The system's ability to verify conditions accurately examines the stability and fault tolerance of programs under abnormal operating conditions, enhancing the authenticity and effectiveness of robustness testing. The testing environment allows for fine-grained control of registers, memory units, communication buffers, bus messages, and interface states without modifying the target software program. It also allows for real-time changes to the underlying hardware state during continuous software execution, providing the foundation for runtime exception injection. This enables the injection of faults or boundary conditions to be dynamically triggered as needed during the system's closed-loop operation, based on the actual execution state of the software. It features controllable execution timing, deeper operational levels, and a strong correlation with the actual operating state of the software. This allows for high-precision verification of embedded control software under complex interactive conditions. Furthermore, it allows for the repeated construction of high-risk and extreme operating scenarios in a safe laboratory environment to fully verify the software's behavior under abnormal conditions, identify potential defects in advance, and correct them, thereby significantly improving the reliability of the final system and reducing reliance on physical prototypes and field testing conditions.

[0036] As can be seen from the above, in this embodiment of the application, the embedded binary program to be verified by the task management computer is loaded into the storage space of the first simulation node. After the test and verification system is started and initialized, the physical entity node obtains the simulation stimulus data and transmits it to the first simulation node through the target communication middleware. The node uses the simulation stimulus data to drive the embedded binary program to generate UAV control commands, and then sends them to the second simulation node through the target communication middleware so that the node can feed back simulation status data. The first simulation node processes the simulation status data to obtain new simulation stimulus data and executes it in a loop until the program finishes running, thus completing the UAV MMC test and verification. In this way, through the above-described process of this application embodiment, the embedded binary program is directly loaded into the first simulation node corresponding to the task management computer, which can maximize the restoration of the real operating environment and improve the authenticity and credibility of the test verification; by obtaining stimuli through physical physical nodes and relying on the target communication middleware to realize multi-node data interaction, the simulation data transmission can be guaranteed to be stable and the interaction is efficient; the closed-loop iterative driver operation and continuous update of stimulus data can fully cover the program execution flow and comprehensively verify the control logic and operational reliability of the embedded program in the dynamic simulation scenario; a large amount of verification work that would otherwise need to be carried out in the field is moved to the laboratory, reducing the dependence on physical prototypes and field resources, improving R&D efficiency and safety, and thus solving the problem that the software development and system integration of UAV MMC heavily rely on physical hardware, resulting in long R&D cycles, difficult testing, and low verification efficiency.

[0037] Accordingly, see Figure 5 As shown, this application embodiment also provides a test and verification device for a mission management computer of a UAV, applied to a test and verification system of a target UAV. The test and verification system includes physical entity nodes, target communication middleware, and target simulation nodes. The physical entity nodes include excitation monitoring nodes, and the target simulation nodes include a first simulation node corresponding to the mission management computer and a second simulation node corresponding to other subsystems of the target UAV besides the mission management computer. The device includes: The program loading module 11 is used to load the embedded binary program to be verified from the task management computer into the storage space of the first simulation node. Data transmission module 12 is used to acquire simulation stimulus data through the physical entity node after the test and verification system is started and initialized based on the embedded binary program, and transmit it to the first simulation node through the target communication middleware; The instruction sending module 13 is used to drive the embedded binary program to generate UAV control instructions based on the simulation stimulus data through the first simulation node, and send them to the second simulation node through the target communication middleware, so that the second simulation node can feed back the simulation status data of the target UAV to the first simulation node based on the UAV control instructions and through the target communication middleware; The step jump module 14 is used to process the simulation state data through the first simulation node to obtain new simulation stimulus data, and jump to the step of driving the embedded binary program to generate UAV control instructions based on the simulation stimulus data through the first simulation node, until the embedded binary program is completed, so as to end the test and verification of the task management computer for the target UAV.

[0038] In some specific embodiments, the UAV mission management computer testing and verification device may further include: The node configuration unit is used to deploy the target communication middleware and configure the first simulation node and the second simulation node according to the unmanned aerial vehicle system of the target UAV.

[0039] In some specific embodiments, the data transmission module 12 may specifically include: The node startup unit is used to start the target simulation node so that the first simulation node executes the embedded binary program, performs RTOS boot, driver initialization and application task creation, and establishes a data connection with the second simulation node and the physical entity node through the target communication middleware.

[0040] In some specific embodiments, the instruction sending module 13 may specifically include: The instruction generation unit is used to simulate a sub-node through the processor of the first simulation node, and drive the embedded binary program to generate UAV control instructions through a virtual bus interface based on the simulation stimulus data. The instruction conversion unit is used to convert the UAV control instructions into structured data adapted by the target communication middleware through the middleware adaptation sub-node of the first simulation node, so as to publish the structured data to the second simulation node through the target communication middleware; The data feedback unit is used to solve the structured data through the second simulation node to generate simulation state data of the target UAV, and to feed back the simulation state data to the first simulation node through the target communication middleware.

[0041] In some specific embodiments, the step jump module 14 may specifically include: The data conversion unit is used to convert the simulation state data into new simulation stimulus data adapted to the embedded binary program through the virtual bus interface of the first simulation node.

[0042] In some specific embodiments, the UAV mission management computer testing and verification device may specifically include: The data recording unit is used to monitor and record target data in real time through the excitation monitoring node, so that after the embedded binary program is executed, playback, performance analysis and fault diagnosis can be performed based on the target data; the target data is a number of data generated during the execution of the embedded binary program.

[0043] In some specific embodiments, the UAV mission management computer testing and verification device may further include: The read / write control unit is used to perform read / write control on the virtual bus interface of the first simulation node through the excitation monitoring node, so as to inject communication exceptions into the processor simulation sub-node of the first simulation node, and to propagate the exceptions through the middleware adapter sub-node of the first simulation node and the target communication middleware, so as to perform robustness verification of the embedded binary program under real runtime conditions.

[0044] Furthermore, embodiments of this application also disclose an electronic device, Figure 6 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the UAV mission management computer testing and verification method disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0045] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0046] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0047] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the UAV mission management computer test and verification method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0048] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed computer test and verification method for the task management of unmanned aerial vehicles. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0049] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0050] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0051] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0052] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus 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 apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0053] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for testing and verifying a mission management computer for unmanned aerial vehicles (UAVs), characterized in that, A test and verification system for a target unmanned aerial vehicle (UAV) includes physical entity nodes, a target communication middleware, and a target simulation node. The physical entity nodes include an excitation monitoring node, and the target simulation node includes a first simulation node corresponding to a task management computer and second simulation nodes corresponding to other subsystems of the target UAV besides the task management computer. The method includes: Load the embedded binary program to be verified from the task management computer into the storage space of the first simulation node; After the test and verification system is started and initialized based on the embedded binary program, it obtains simulation stimulus data through the physical entity node and transmits it to the first simulation node through the target communication middleware. The first simulation node drives the embedded binary program to generate UAV control commands based on the simulation stimulus data, and sends them to the second simulation node through the target communication middleware. The second simulation node then feeds back the simulation status data of the target UAV to the first simulation node based on the UAV control commands and through the target communication middleware. The simulation state data is processed by the first simulation node to obtain new simulation stimulus data, and then the process jumps to the step of driving the embedded binary program to generate UAV control commands based on the simulation stimulus data through the first simulation node, until the embedded binary program is completed, thereby ending the test and verification of the mission management computer for the target UAV.

2. The test and verification method for the mission management computer of an unmanned aerial vehicle (UAV) according to claim 1, characterized in that, Before loading the embedded binary program to be verified from the task management computer into the storage space of the first simulation node, the method further includes: The target communication middleware is deployed, and the first simulation node and the second simulation node are configured according to the drone system of the target drone.

3. The test and verification method for the mission management computer of an unmanned aerial vehicle (UAV) according to claim 1, characterized in that, The startup and initialization based on the embedded binary program includes: The target simulation node is started so that the first simulation node executes the embedded binary program to perform RTOS boot, driver initialization and application task creation, and establishes data connections with the second simulation node and the physical entity node through the target communication middleware.

4. The test and verification method for the mission management computer of an unmanned aerial vehicle (UAV) according to claim 1, characterized in that, The step of driving the embedded binary program to generate UAV control commands based on the simulation stimulus data through the first simulation node, and sending them to the second simulation node through the target communication middleware, so that the second simulation node can feed back the simulation status data of the target UAV to the first simulation node based on the UAV control commands and through the target communication middleware, includes: The processor of the first simulation node simulates the sub-node, and the embedded binary program is driven to generate UAV control commands through the virtual bus interface based on the simulation stimulus data. The UAV control commands are converted into structured data adapted by the target communication middleware through the middleware adaptation sub-node of the first simulation node, so as to publish the structured data to the second simulation node through the target communication middleware. The structured data is processed by the second simulation node to generate simulation state data of the target UAV, and the simulation state data is fed back to the first simulation node through the target communication middleware.

5. The test and verification method for the mission management computer of an unmanned aerial vehicle (UAV) according to claim 1, characterized in that, The step of processing the simulation state data through the first simulation node to obtain new simulation stimulus data includes: The simulation state data is converted into new simulation stimulus data adapted to the embedded binary program through the virtual bus interface of the first simulation node.

6. The test and verification method for the mission management computer of an unmanned aerial vehicle (UAV) according to claim 1, characterized in that, The execution of the embedded binary program includes: The target data is monitored and recorded in real time by the excitation monitoring node so that after the embedded binary program is executed, playback, performance analysis and fault diagnosis can be performed based on the target data; the target data is a number of data generated during the execution of the embedded binary program.

7. The test and verification method for the mission management computer of an unmanned aerial vehicle (UAV) according to any one of claims 1 to 6, characterized in that, The execution of the embedded binary program also includes: The excitation monitoring node performs read and write control on the virtual bus interface of the first simulation node to inject communication anomalies into the processor simulation sub-node of the first simulation node, and propagates the anomalies through the middleware adapter sub-node of the first simulation node and the target communication middleware to perform robustness verification of the embedded binary program under real runtime conditions.

8. A test and verification device for a mission management computer of an unmanned aerial vehicle (UAV), characterized in that, A test and verification system for a target unmanned aerial vehicle (UAV), comprising physical entity nodes, target communication middleware, and target simulation nodes; the physical entity nodes include excitation and monitoring nodes, and the target simulation nodes include a first simulation node corresponding to the task management computer and second simulation nodes corresponding to other subsystems of the target UAV besides the task management computer; wherein, the device includes: The program loading module is used to load the embedded binary program to be verified from the task management computer into the storage space of the first simulation node. The data transmission module is used to acquire simulation stimulus data through the physical entity node after the test and verification system is started and initialized based on the embedded binary program, and transmit it to the first simulation node through the target communication middleware. The instruction sending module is used to drive the embedded binary program to generate UAV control instructions based on the simulation stimulus data through the first simulation node, and send them to the second simulation node through the target communication middleware, so that the second simulation node can feed back the simulation status data of the target UAV to the first simulation node based on the UAV control instructions and through the target communication middleware; The step jump module is used to process the simulation state data through the first simulation node to obtain new simulation stimulus data, and jump to the step of driving the embedded binary program to generate UAV control instructions based on the simulation stimulus data through the first simulation node, until the embedded binary program is completed, so as to end the test and verification of the mission management computer for the target UAV.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the UAV mission management computer test and verification method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer programs are executed by a processor, they implement the UAV mission management computer test and verification method as described in any one of claims 1 to 7.

Images