An abnormality testing method and device for a low-altitude flight simulation system

Abstract

The application provides a kind of low-altitude flight simulation system-oriented abnormal test method and device, belong to computer simulation technical field.The method comprises: in the low-altitude flight simulation process of at least one simulation entity, whenever triggering abnormal injection condition, determine injection instruction, injection instruction carries target abnormal event to be injected;Based on injection instruction, target abnormal event is injected into target engine, target engine is task flow engine, behavior rule engine or physical calculation engine;Based on target abnormal event, carry out collaborative simulation processing between task flow engine, behavior rule engine and physical calculation engine, so that the abnormal effect corresponding to target abnormal event is propagated between each engine, to obtain the causal chain data corresponding to target abnormal event;Based on causal chain data, the abnormal response result of system is quantitatively evaluated.Using the application, the fidelity of abnormal test can be improved.

Description

Technical Field

[0001] This invention relates to the field of computer simulation technology, and in particular to an anomaly testing method and apparatus for low-altitude flight simulation systems. Background Technology

[0002] The large-scale operation of drones, eVTOL aircraft, and other similar vehicles in low-altitude airspace exposes them to complex operating environments and various potential anomalies and risks. Digital twin technology is an important tool for simulation verification and safety testing.

[0003] Currently, most mainstream anomaly injection methods adopt a static preset mode, that is, defining faults by modifying scripts or configuration files before the simulation system runs. This method cannot simulate the suddenness and uncertainty of anomalies in the real world, and usually can only cause single, superficial fault phenomena, failing to test the real response capability of the simulated aircraft entity when encountering deep, cascading anomalies. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide an anomaly testing method and apparatus for low-altitude flight simulation systems, which can improve the fidelity of anomaly testing.

[0005] According to one aspect of the present invention, an anomaly testing method for a low-altitude flight simulation system is provided, the system comprising a task flow engine, a behavior rule engine, and a physics calculation engine; The method includes: During the low-altitude flight simulation of at least one simulated entity, whenever an abnormal injection condition is triggered, an injection command is determined, which carries the target abnormal event to be injected. Based on the injection instruction, the target abnormal event is injected into the target engine, which is the task flow engine, the behavior rule engine, or the physical calculation engine; Based on the target abnormal event, collaborative simulation processing is performed between the task flow engine, the behavior rule engine, and the physical calculation engine, so that the abnormal effect corresponding to the target abnormal event propagates between the engines to obtain the causal chain data corresponding to the target abnormal event. Based on the causal chain data, the abnormal response results of the system are quantitatively evaluated.

[0006] According to another aspect of the present invention, an anomaly testing device for a low-altitude flight simulation system is provided, the system comprising a task flow engine, a behavior rule engine, and a physics calculation engine; The device includes: The instruction generation unit is used to determine an injection instruction whenever an abnormal injection condition is triggered during the low-altitude flight simulation of at least one simulation entity. The injection instruction carries the target abnormal event to be injected. An exception injection unit is used to inject the target exception event into the target engine based on the injection instruction, wherein the target engine is the task flow engine, the behavior rule engine, or the physical calculation engine; The simulation unit is used to perform collaborative simulation processing between the task flow engine, the behavior rule engine and the physical calculation engine based on the target abnormal event, so that the abnormal effect corresponding to the target abnormal event propagates between the engines to obtain the causal chain data corresponding to the target abnormal event. The quantitative evaluation unit is used to quantitatively evaluate the abnormal response results of the system based on the causal chain data.

[0007] According to another aspect of the present invention, an electronic device is provided, comprising: Processor; and Stored program memory, The program includes instructions that, when executed by the processor, cause the processor to perform the aforementioned anomaly test for the low-altitude flight simulation system.

[0008] According to another aspect of the present invention, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause a computer to perform the above-described anomaly test for a low-altitude flight simulation system.

[0009] In this invention, during low-altitude flight simulation, whenever an abnormal injection condition is triggered, an injection command carrying a target abnormal event is determined, and the target abnormal event is injected into the target engine in the task flow engine, behavior rule engine, or physics calculation engine. Based on the target abnormal event, collaborative simulation processing is performed between the engines, so that the abnormal effect propagates between the engines and the corresponding causal chain data is obtained. Then, based on the causal chain data, the abnormal response result of the system is quantitatively evaluated.

[0010] By injecting target anomalous events into the mission flow engine, behavior rule engine, or physics calculation engine during low-altitude flight simulation, the anomalous effects can be realistically and chain-propagated between engines, generating causal chain data. This not only accurately covers dynamic risk scenarios through conditional triggering and reduces repetitive work, thus improving testing efficiency and coverage, but also avoids the distortion of surface injection by injecting at the starting point of the causal chain, significantly improving test fidelity. Attached Figure Description

[0011] Further details, features, and advantages of the invention are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1 A flowchart of an anomaly testing method for a low-altitude flight simulation system according to an exemplary embodiment of the present invention is shown. Figure 2 A schematic diagram of a low-altitude flight simulation system according to an exemplary embodiment of the present invention is shown; Figure 3 A schematic diagram of an anomaly classification tree provided according to an exemplary embodiment of the present invention is shown; Figure 4 A schematic diagram of an anomaly injection controller according to an exemplary embodiment of the present invention is shown; Figure 5 This diagram illustrates an anomaly testing phase according to an exemplary embodiment of the present invention. Figure 6 A schematic block diagram of an anomaly testing apparatus for a low-altitude flight simulation system provided according to an exemplary embodiment of the present invention is shown. Figure 7 A structural block diagram of an exemplary electronic device that can be used to implement embodiments of the present invention is shown. Detailed Implementation

[0012] Embodiments of the present invention will now be described in more detail with reference to the accompanying drawings. While some embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the invention. It should be understood that the accompanying drawings and embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the invention.

[0013] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0014] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this invention are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0015] It should be noted that the terms "a" and "a plurality of" used in this invention are illustrative rather than restrictive. Those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0016] The names of the messages or information exchanged between the multiple devices in the embodiments of the present invention are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0017] This invention provides an anomaly testing method for low-altitude flight simulation systems. This method can be performed by a terminal, server, and / or other devices with processing capabilities. The method provided in this embodiment can be performed by any of the aforementioned devices, or by multiple devices working together; this invention does not limit this.

[0018] In this invention, a flowchart of an anomaly testing method for a low-altitude flight simulation system is shown below. Figure 1 As shown, the low-altitude flight simulation system is as follows: Figure 2 As shown.

[0019] This low-altitude flight simulation system comprises a user interaction layer, an anomaly injection service layer, a multimodal anomaly library, an operation control module (including an anomaly injection controller), a deep injection interface, a monitoring and evaluation module, and a multi-level simulation engine: a task flow engine, a behavior rule engine, a physics calculation engine, and a spatial grid engine. It can perform low-altitude flight simulation based on digital twin technology. Under the unified scheduling of the operation control center, each engine works collaboratively according to the principle of "top-down driving and bottom-up feedback": the task flow engine drives the decision-making of the behavior rule engine, the behavior rule engine controls the execution of the physics calculation engine, and the physics calculation engine provides feedback on the physical state of the simulated entities, influencing the decision-making of the behavior rule engine. The spatial grid engine is used to establish grid indexes for entities and environmental elements in the simulation space, providing basic spatial analysis capabilities for conflict detection, path planning, and airspace management.

[0020] The user interaction layer can include a visual exception orchestration interface, providing a graphical interface that supports drag-and-drop orchestration of exception scenarios, parameter configuration, trigger condition setting, injection strategy selection, and viewing and exporting test reports. Users can initiate configuration requests through this interface to drive the exception injection service layer to generate an injection plan.

[0021] The Multimodal Anomaly Library is a structured and scalable knowledge base organized using a hierarchical and categorized data model. Its core structure includes an anomaly meta-model, an anomaly classification tree, and an anomaly instance pool.

[0022] The anomaly metamodel defines common attributes for all anomaly models, such as unique ID (Identification), name, description, impact level (corresponding to the task flow engine, behavior rule engine, and physical calculation engine), default parameters, severity level, etc.

[0023] The anomaly classification tree categorizes each anomaly model into a tree structure based on its root cause and affected area. For example... Figure 3 The diagram of the anomaly classification tree shown shows that the root node of the multimodal anomaly library can be divided into physical equipment anomaly model library, environmental anomaly model library, communication link anomaly model library, human operation anomaly model library, and infrastructure anomaly model library. Each model library stores the corresponding anomaly model as a leaf node. For example, the physical equipment anomaly model library can store sensor failures (GPS (Global Positioning System) positioning failure, IMU (Inertial Measurement Unit) drift, excessive visual sensor noise, radar ranging errors), power system anomalies (sudden drop in battery power, loss of propulsion efficiency), actuator failures (controller surface jamming), navigation system failures, etc.; the environmental anomaly model library can store meteorological anomalies (sudden wind shear, atmospheric turbulence, precipitation leading to decreased visibility), electromagnetic interference causing deterioration of communication signal-to-noise ratio, geographical environmental impacts, etc.; the communication link anomaly model library can store data link interruptions, increased communication latency, increased data packet loss rate, navigation signal spoofing / denial, etc.; the human operation anomaly model library can store sending incorrect commands, violating safety intervals, unreasonable mission planning, etc.; the infrastructure anomaly model library can store sudden closure of take-off and landing fields, charging pile failures, interruption of airspace management services, etc.

[0024] The exception instance pool stores parameterized exception instances that can be directly invoked or combined. For example, a "GPS failure" exception instance can have its parameters set to failure type = complete loss and activation delay = 0ms.

[0025] Before conducting anomaly testing, users can select one or more basic anomaly models (such as "GPS positioning failure", "communication interruption", "thrust loss" etc.) from the multimodal anomaly library through the visual anomaly orchestration interface, and select injection strategy templates (such as single injection, periodic injection, incremental injection, random injection, adaptive injection), configure the trigger conditions (such as manual trigger, timed trigger, conditional trigger) for each anomaly model (or combination of anomalies), and orchestrate anomaly scenarios.

[0026] After receiving the user's configuration of the abnormal scenarios, the abnormal scenario orchestrator in the abnormal injection service layer selects basic abnormalities from the multimodal abnormality library, combines them into composite abnormal scenarios according to temporal relationships (such as serial, parallel, and conditional branching) and logical relationships (such as AND and OR), and outputs a structured abnormal scenario description. For example, "Inject GPS drift first, and if the aircraft altitude is <100 meters after a 5-second delay, inject communication interruption."

[0027] Furthermore, the injection strategy manager of the exception injection service layer can bind the injection strategy selected by the user with the exception scenario to generate a complete injection plan, which includes exception definition, triggering conditions and strategy parameters.

[0028] In this context, "single injection" refers to injecting once after being triggered once, and then ending the process. Periodic injection refers to repeatedly injecting the same exception at fixed time intervals starting from the triggering time, with the number of repetitions specified or allowed to repeat indefinitely; Incremental injection refers to gradually increasing the anomaly strength parameter with each injection (e.g., increasing the GPS offset by 5 meters each time) to detect the fault tolerance threshold of the system. Random injection refers to randomly selecting the injection time within a specified time window after triggering, simulating uncertainty; Adaptive injection refers to dynamically adjusting the parameters or frequency of subsequent injections based on real-time feedback from the monitoring and evaluation module.

[0029] Manual triggering means: not setting automatic conditions and waiting for testers to trigger the injection command in the test interface; Timed triggering refers to setting an absolute simulation time (e.g., T=10.0s) or a relative time (e.g., 5s after the aircraft takes off). Conditional triggering refers to: editing a Boolean expression and binding it to a simulation state variable (e.g., aircraft A. altitude < 50m && aircraft A. speed > 10m / s).

[0030] The triggering method can be executed in conjunction with the injection strategy: the trigger condition judge is only responsible for initiating the first injection; after initiation, subsequent injection behaviors (such as whether to repeat, the interval, and how parameters change) are determined by the injection strategy. For example, when using "timed triggering + periodic injection", the trigger condition judge triggers the first injection at the scheduled time, and the periodic injection strategy takes over the scheduling of subsequent repeated injections; if using "conditional triggering + single injection", an injection is triggered each time the condition is met, with no subsequent repetition.

[0031] User-configured abnormal scenarios can be injected into the low-altitude flight simulation process through an exception injection controller. For example... Figure 4The diagram shown illustrates the exception injection controller, which serves as the system's "command center." The exception injection controller is an independent service module comprising four sub-modules: a policy resolver, a status monitor, a trigger condition judge, and an instruction router. The policy resolver receives injection plans (such as complex exception scenarios) from the exception injection service layer and parses them into an executable sequence of injection instructions, including multiple exception events and their corresponding target engine, injection time, modified parameter values, trigger conditions, execution count, and execution interval.

[0032] Subsequently, during the low-altitude flight simulation process, through Figure 1 The exception testing method shown injects exception events into the target engine.

[0033] The following will refer to Figure 1 A flowchart of an anomaly testing method for a low-altitude flight simulation system is shown, and Figure 5 The diagram shown illustrates the anomaly testing phase, and the method is explained below.

[0034] like Figure 1 As shown, the anomaly testing method provided by the present invention includes the following steps 101-104.

[0035] Step 101: During the low-altitude flight simulation of at least one simulated entity, whenever an abnormal injection condition is triggered, an injection command is determined, which carries the target abnormal event to be injected.

[0036] In one possible implementation, during the simulation initialization phase, the runtime control module starts the basic simulation engine and establishes data exchange channels between the engines. The trigger condition judge of the anomaly injection controller registers the timed trigger conditions with the simulation clock manager and informs the data acquisition unit of the list of state variables to be monitored for condition triggering. At the beginning of each simulation step, the state monitor calls the data acquisition unit of the runtime control module to obtain the latest status of all engines, including the current simulation time, the real-time position / velocity / attitude of each aircraft, the current mission execution stage, and airspace conflict status. At the end of each simulation step, the data acquisition unit actively pushes the changed values ​​of these variables. Furthermore, when each engine experiences a critical state change (such as "aircraft entering a specific grid" or "rule-triggered decision"), it can also call the "state change notification" interface of the runtime control module to push the event information of the critical state change to the data acquisition unit, thereby allowing the state monitor to retrieve the aforementioned callback event information through the "acquire event queue" interface. This enables anomaly injection to be performed based on real-time situational awareness (such as "injection when an aircraft enters a certain airspace").

[0037] During the simulation, the trigger condition judge continuously monitors the abnormal injection conditions, which specifically include at least one of the following conditions: Manual trigger: Wait for a signal from the user interface, and trigger the injection process upon receiving the signal; Timed triggering: When the simulation time reaches the registered time, the simulation clock manager directly calls back the trigger condition checker to trigger the injection process; Conditional triggering: The data acquisition unit pushes relevant variable values ​​at the end of each simulation step, triggering the condition judge to evaluate the Boolean expression. If the expression changes from "false" to "true", the injection process is triggered. To avoid repeated triggering, the trigger edge mode (rising edge / falling edge) or minimum trigger interval can be set.

[0038] When any exception injection condition is triggered, the strategy parser parses the injection instruction sequence to be executed according to the exception definition and injection strategy in the preset injection plan. The injection instruction sequence carries information about at least one target exception event to be injected, including the target engine type, modified parameters, number of executions, execution interval, etc., to determine the specific content and execution method of this exception injection.

[0039] Step 102: Based on the injection instruction, inject the target abnormal event into the target engine, which is a task flow engine, behavior rule engine, or physical calculation engine.

[0040] In one possible implementation, when the exception injection condition is triggered, the injection instruction parsed by the policy parser carries information such as the target engine type, modified parameters, execution count, and interval. Based on the target engine type in the injection instruction, the instruction router calls the deep injection interface function provided by the corresponding engine API (Application Programming Interface) layer to achieve targeted injection of the exception event. If the target engine is a physics calculation engine, call the physics engine injection interface, and directly affect the calculation process of the dynamic model by modifying the sensor data in the shared memory through the debugging functions provided by the engine or by directly modifying the sensor data in the shared memory. If the target engine is a behavior rule engine, call the behavior engine injection interface, send fake perception events to a specific agent through the message queue, or temporarily activate / disable a rule in its rule base to change its behavior decision logic. If the target engine is a task flow engine, call the task engine injection interface to modify the task scheduling process or task parameters and intervene in the task execution logic.

[0041] The aforementioned interfaces are directly embedded into the internal data bus and event loop of the multi-level simulation engine via function calls or shared memory writes, ensuring that injected commands can affect simulation calculations with minimal latency and maximum fidelity. The physics calculation engine injection interface allows direct modification of dynamic model parameters, sensor output data, or environmental model states within the physics engine. The behavior rule engine injection interface allows injecting erroneous perception information (such as virtual obstacles) into simulated entities (such as drones) or dynamically modifying rules in their rule base (such as temporarily disabling an obstacle avoidance rule). The task flow engine injection interface allows injecting high-level task events, such as emergency task insertion, current task cancellation, or dynamic changes to task objectives.

[0042] For non-single injection strategies such as periodic or incremental ones, the internal startup scheduler of the exception injection controller repeatedly calls the injection interface of the corresponding engine according to the execution interval and parameter change rules defined in the injection instruction until the termination condition is met (such as the number of repetitions is exhausted or the parameters reach the upper limit).

[0043] Step 103: Based on the target abnormal event, perform collaborative simulation processing among the task flow engine, behavior rule engine and physical calculation engine, so that the abnormal effect corresponding to the target abnormal event propagates among the engines, in order to obtain the causal chain data corresponding to the target abnormal event.

[0044] In one possible implementation, upon receiving a target anomaly event, each engine, relying on the inherent data flow and feedback mechanism of the multi-level simulation architecture, allows the anomaly effect to propagate naturally along the data exchange channels between engines, forming a cross-level chain reaction. This process requires no additional programming intervention and can be achieved entirely based on the engine's own high-fidelity model and inter-level data flow. During this process, using the target anomaly event as the starting point of the causal chain, related events triggered during the simulation and their temporal relationships are collected and analyzed to construct a causal chain data consisting of event sequences that reflects the anomaly propagation path.

[0045] Specifically, the collaborative simulation processing between the task flow engine, behavior rule engine, and physics calculation engine can be as follows: The task flow engine is used to determine the task instructions for each simulation step; or, when a task adjustment request triggered by the behavior rule engine is received, it determines another task instruction based on the task adjustment request. The behavior rule engine is used to determine the decision results based on task instructions and / or the current physical state data of each simulation entity, as well as the target rules corresponding to the current target facts matched in the rule base. The decision results include task adjustment requests and / or control instructions. The physics calculation engine is used to determine new physical state data for each simulated entity based on the control commands triggered by the behavior rule engine.

[0046] In one possible implementation, the task flow engine first acquires and parses the current simulation task to form a task execution logic sequence consisting of multiple sub-tasks. This sequence is used to characterize the task execution route of at least one simulation entity in the target low-altitude flight domain (such as from takeoff, cruise to landing).

[0047] During the simulation process, the task flow engine traverses and executes the task execution logic sequence step by step according to a unified simulation step rhythm. Based on the task stage, execution conditions and preset logic corresponding to the current simulation step, it automatically generates and outputs the task instructions required for the current step to drive subsequent simulation stages to carry out decision-making and physical execution.

[0048] Furthermore, after receiving the task instructions from the task flow engine, the behavior rule engine obtains the physical state data of each simulation entity in real time, and combines it with the simulation situation under the current low-altitude flight scenario to match and call the corresponding target rules.

[0049] During the simulation process, the behavior rule engine follows a unified simulation pace, using the current mission instructions as macro-constraints and real-time physical state data as the basis for execution. It calls the matched target rules to conduct logical reasoning, comprehensively judges the flight operation risks and execution feasibility, and generates decision results that include mission adjustment requests and / or control instructions. It can both feed back mission change requirements to the upper-level mission process engine and issue control instructions to the lower-level physical calculation engine, realizing the connection and control of macro-level missions and physical execution at the tactical level.

[0050] The behavior rule engine's working memory continuously maintains and updates the fact base, which stores multiple fact objects. These fact objects are various events that trigger rules, including task instructions triggered by the task flow engine, physical state data of each simulation entity fed back by the physics calculation engine, and fact objects corresponding to simulation scene data (such as meteorological data, radar trajectories, airspace status, etc.). Fact objects can serve as real-time input for rule matching, providing dynamic and effective factual support for rule reasoning.

[0051] In response to fact updates in the fact base, the behavioral rule engine can perform rule matching. During rule matching, the inference engine of the behavioral rule engine can perform pattern matching based on the RETE algorithm (Network Pattern Matching Algorithm), using the current target fact as input to quickly filter target rules that match the target fact.

[0052] Whenever a target rule is selected that matches the target fact, the behavior rule engine can execute the matched target rule based on a decision context that includes task instructions, the physical state data of each simulated entity, and simulation scene data. It then performs decision reasoning by comprehensively considering task intent, the physical state of the simulated entities, and scene constraints to generate the corresponding decision result. Because the decision-making process is based on task instructions and the physical state data of the simulated entities, while also incorporating factual information from the entire scene, such as the environment, airspace, and the operating status of the simulation system, the decision logic can fully align with the operational logic and constraints of real low-altitude flight, thereby effectively improving the scene adaptability and simulation accuracy of the decision results.

[0053] When the behavior rule engine generates a decision result that requires task adjustment, this decision result will be fed back to the task flow engine as a task adjustment request. Upon receiving the request, the task flow engine will update the task objective according to the adjustment logic and generate new task instructions, triggering the update of the objective facts. After the new objective facts are injected into the fact base, a new round of decision processing will be triggered, realizing closed-loop iteration of the simulation task and dynamic adaptation of rules.

[0054] When the behavior rule engine generates decision results representing the physical control of the simulated entity, these decision results are sent to the physics calculation engine as control commands. The physics calculation engine receives the control commands issued by the behavior rule engine, which are used to constrain the actions and behaviors of the simulated entity during the low-altitude flight simulation process.

[0055] During the simulation process, the physics calculation engine follows a unified simulation step rhythm, combines the flight behavior constraints corresponding to the control commands, and relies on the six-degree-of-freedom dynamic model to calculate the six-degree-of-freedom attitude, flight position, and sensor data (such as GPS data, IMU data, etc.) of each simulated entity. It quantifies and updates the motion state and sensor output information of the simulated entity, determines the new physical state data of each simulated entity under the current simulation step, and feeds the updated physical state data upward to provide state support for the upper-level behavior rule engine to carry out subsequent decisions.

[0056] After injecting the target exception event into the target engine: If the target engine is a task flow engine, then the corresponding task instructions are determined based on the target exception event within the task flow engine; If the target engine is a behavior rule engine, then in the behavior rule engine, the corresponding task adjustment request and / or control instruction is determined based on the target abnormal event; If the target engine is a physics calculation engine, then the corresponding physical state data is determined based on the target abnormal event in the physics calculation engine.

[0057] In one possible implementation, when a target anomalous event is injected into the task flow engine, the task flow engine can generate anomalous task instructions that deviate from the original plan based on the target anomalous event. These anomalous task instructions are then passed down to the behavior rule engine, which may cause the behavior layer to make decisions that violate normal execution logic.

[0058] When a target anomalous event is injected into the behavior rule engine, the behavior rule engine can generate anomaly task adjustment requests and / or anomalous control instructions based on the target anomalous event. The anomalous task adjustment request is fed back to the task flow engine, which may lead to changes in task status or replanning; the anomalous control instructions are sent down to the physics calculation engine, which may interfere with normal flight dynamics calculations and introduce unexpected physical state deviations.

[0059] When anomaly events are injected into the physics calculation engine, the engine may generate biased sensor data based on these events, affecting navigation and flight dynamics calculations and outputting incorrect physical state data. This erroneous physical state data, once uploaded to the behavior rule engine, may trigger abnormal behavior-level decisions.

[0060] Subsequently, relying on the inherent data flow and feedback mechanism of the multi-level simulation engine architecture, the abnormal effect autonomously spreads and propagates, and the simulation process can generate at least one causal chain. The length, propagation path, and scope of influence of different causal chains can vary, conforming to the chain evolution law of multiple paths and branches of abnormal events in real-world scenarios. Compared with the traditional method of pre-setting fixed causal relationships, this can effectively improve the realism and accuracy of abnormality inference results.

[0061] Optionally, the processing for obtaining the causal chain data corresponding to the target anomalous event can be as follows: Multiple simulation events within a preset time window are extracted, starting from the trigger time of the target abnormal event; Based on the temporal proximity, simulation entity correlation, and type relevance between the target abnormal event and the simulation event, the correlation score of each simulation event is determined, and simulation events with correlation scores exceeding a preset correlation threshold are identified as correlated events. Starting with the target anomalous event, causal chain data is constructed based on the target anomalous event and each related event in chronological order of their triggering times.

[0062] Among them, temporal proximity is used to indicate that the time interval between the target anomalous event and the simulated event is close; Simulation entity association is used to indicate that a target anomalous event and a simulation event belong to the same simulation entity; Type correlation is used to indicate that the target anomalous event and the simulated event conform to the associated response type.

[0063] In one possible implementation, the anomaly propagation tracker can call the data collector's "Get Event Log" interface to obtain a sequence of event logs containing the target anomaly event, where each simulation event contains information such as the trigger time, event type, engine level to which it belongs, and its associated simulation entity.

[0064] Starting from the trigger time of the target abnormal event, extract all simulation events within the set time window (e.g., 30 seconds, the window size can be dynamically adjusted according to the abnormality type).

[0065] Next, based on the temporal proximity, simulation entity correlation, and type correlation between the target abnormal event and each simulation event within the window, a multidimensional causal association score for each simulation event can be calculated.

[0066] As a concrete example, for temporal proximity, the exponential decay model exp(-|t - t0| / τ) can be used to calculate the temporal correlation between events, where t represents the triggering time of any simulated event, t0 represents the triggering time of the target anomalous event, and τ is a configurable time decay constant. The closer the time interval, the higher the calculated temporal correlation.

[0067] For simulation entity association, matching can be performed based on the simulation entity ID associated with the simulation event. If the simulation entity ID is the same as the simulation entity ID associated with the target abnormal event, a corresponding score is assigned (e.g., score +1).

[0068] For type correlation, the response relationship between the target abnormal event and the simulation event can be matched and assigned a corresponding score based on the "anomaly-response type mapping table" (e.g., GPS anomaly → sensor alarm → mode switching → task degradation). The associated response types in the anomaly-response type mapping table support incremental updates. The initial associated response types can be constructed based on domain expert knowledge, or, in scenarios lacking prior knowledge, can be automatically generated from historical simulation event logs by association rule mining algorithms such as Apriori and FP-Growth, reducing reliance on human experience. After each subsequent anomaly test, the test data is first analyzed to determine new anomaly-response patterns and updated associated response types. Then, the anomaly-response type mapping table is expanded based on the updated associated response types to achieve dynamic optimization.

[0069] The scores for temporal proximity, simulated entity correlation, and type correlation are accumulated or weighted to calculate the multidimensional causal correlation score for each simulated event. The weights for each item are configurable (e.g., 0.5, 0.3, 0.2 respectively) and can be dynamically adjusted based on the anomaly type.

[0070] For example, assuming a time decay constant τ = 5 seconds, a target abnormal event trigger time t0 = 10.0 seconds, and simulation event A occurs at t = 10.2 seconds, then the time proximity score = exp(-0.2 / 5) ≈ 0.96; simulation event B occurs at t = 15.0 seconds, and the time proximity score = exp(-5 / 5) ≈ 0.37. If both the simulation entity correlation and type correlation scores are 1, then simulation event A has a higher overall score than simulation event B and is more likely to be classified as a correlated event.

[0071] The anomaly propagation tracker identifies simulation events with multidimensional causal correlation scores exceeding a preset correlation threshold as correlated events. Starting from the target anomaly, it uses a time-series graph algorithm to arrange all correlated events in ascending order of trigger time and connects them sequentially, constructing a directed acyclic graph (DAG). If the time interval between two simulation events is less than the minimum causal interval (e.g., 1ms), they are considered concurrent events and no edge is added; otherwise, directed edges are added from earliest to latest. Each node is labeled with its engine level information based on the simulation event's engine level, and isolated nodes (events with no incoming or outgoing edges) are removed. The final causal chain data is then output.

[0072] Step 104: Quantitatively evaluate the abnormal response results of the system based on causal chain data.

[0073] In one possible implementation, after obtaining the causal chain data corresponding to the target abnormal event, the response evaluation analyzer can use the causal chain data as a basis to compare the system operating state under the abnormal scenario with the baseline state under the normal scenario. Through multi-dimensional quantitative evaluation, a closed-loop verification of the system's abnormal response capability can be achieved.

[0074] Specific processing may include: Obtain the benchmark data for the evaluation dimensions corresponding to the target abnormal event. The benchmark data for the evaluation dimensions refers to the normal data corresponding to each preset evaluation dimension when there is no target abnormal event. Based on causal chain data, determine the actual data corresponding to each preset evaluation dimension after the system responds to the target abnormal event; For each preset evaluation dimension, determine the deviation value between the actual data and the normal data; Based on the deviation value corresponding to each preset evaluation dimension, the abnormal response result of the evaluation system to the target abnormal event is quantified.

[0075] The preset evaluation dimensions include any one or more of the following: Anomaly detection capability, used to quantify detection latency and detection rate; Response timeliness is used to quantify decision delays and control effectiveness delays; Decision effectiveness is used to quantify task completion rate and security incident incidence rate; The scope of the chain reaction is used to quantify the number of affected engines and the number of state variable changes.

[0076] In one possible implementation, the system can construct and store benchmark data for evaluation dimensions corresponding to the target anomaly event. This benchmark data consists of normal operating data corresponding to each of the preset evaluation dimensions when the target anomaly event does not exist. Its sources include two scenarios: first, the system's stable operating state data before anomaly injection; and second, the normal simulation operating state data without anomaly injection, thereby providing a reliable baseline reference for subsequent quantitative evaluation.

[0077] Accordingly, the processing of benchmark data for the evaluation dimensions corresponding to the target abnormal events in the above two scenarios includes: The first scenario: Obtain the first system runtime status data stored before injecting the target abnormal event into the target engine, and determine the benchmark data for the evaluation dimension corresponding to the target abnormal event based on the first system runtime status data; or... The second scenario involves simultaneously running a first simulation instance injected with the target abnormal event and a second simulation instance without the target abnormal event injected, obtaining the second system operation status data corresponding to the second simulation instance, and determining the evaluation dimension benchmark data corresponding to the target abnormal event based on the second system operation status data.

[0078] In the implementation corresponding to the first scenario described above, the simulation pause, step-by-step, and state snapshot recovery capabilities provided by the operation control module can be used to obtain benchmark data for the evaluation dimensions. When the triggering condition for anomaly injection is met, the anomaly injection controller requests to pause the computation of all engines through the task scheduler. At this time, the simulation clock stops, the state of each engine freezes, and the injection controller obtains a safe time window to perform the injection operation, avoiding injection timing errors or data races caused by the simulation continuing. Before injection, the resource manager can save a complete state snapshot of all current engines to generate the first system running state data.

[0079] After injection, the injection controller can request the task scheduler to perform single-step execution (e.g., advance the simulation by one step) to observe the immediate effects after injection and then decide whether to continue injection or resume operation. This is similar to "single-step execution" when debugging a program. If the system enters an unexpected state after injection, or if it is necessary to repeat the same injection scenario, it can be directly restored to the snapshot state and restarted without re-initializing the entire simulation.

[0080] In the implementation of the second scenario described above, a dual-instance parallel operation method can be adopted, simultaneously starting a first simulation instance that injects the target abnormal event and a second simulation instance that is not affected by the abnormal disturbance and maintains normal operation, and obtaining the second system operation status data corresponding to the second simulation instance.

[0081] The aforementioned operational status data of either the first or second system are analyzed according to the preset evaluation dimensions to determine the corresponding benchmark data for each evaluation dimension, serving as the normal data for each preset evaluation dimension under scenarios without abnormal interference. Specifically, for the anomaly detection capability dimension, benchmark thresholds for detection latency and detection rate are determined based on the response characteristics of the system alarm mechanism under anomaly-free scenarios; for the response timeliness dimension, the normal range of decision latency and control effectiveness latency is determined based on the temporal relationship between alarms, decision commands, and physical state changes under anomaly-free scenarios; for the decision effectiveness dimension, a normal level benchmark is established with the task completion rate and security event occurrence rate under anomaly-free scenarios as references; for the cascading impact scope dimension, the changes in engine levels and state variables involved in the causal chain under anomaly-free scenarios are statistically analyzed to form benchmark values. Finally, the benchmark data of each dimension are integrated to provide a unified reference standard for subsequent indicator comparison, deviation analysis, and robustness comprehensive scoring under anomaly scenarios, ensuring the objectivity and comparability of the evaluation results.

[0082] After obtaining the benchmark data for the evaluation dimensions corresponding to the target anomaly, the abnormal response results of the system to the target anomaly can be quantified based on the deviation value corresponding to each preset evaluation dimension. Specifically, the response evaluation analyzer calculates the quantitative indicators for each preset evaluation dimension based on the causal chain diagram and time series data: For the anomaly detection capability dimension, it calculates the time difference from anomaly injection to the system's first alarm (i.e., detection latency) and the ratio of successful detections to total injections (i.e., detection rate); for the response timeliness dimension, it calculates the time from alarm to decision command issuance (i.e., decision latency) and the time from command issuance to physical state change (i.e., control effectiveness latency); for the decision effectiveness dimension, it calculates the proportion of successful task completion (i.e., task completion rate) and the proportion of conflict / crash after anomaly (i.e., security incident occurrence rate); for the cascading impact scope dimension, it counts the number of engine levels involved in the causal chain (i.e., the number of affected engines) and the number of changed state variables (i.e., the number of state variable changes). Subsequently, each quantitative indicator is compared with the benchmark data of the evaluation dimensions to calculate the deviation value corresponding to each dimension. Finally, the deviation values ​​of each dimension are weighted and combined to generate the corresponding robustness comprehensive score, thereby completing the quantitative evaluation of the abnormal response results of the system.

[0083] After completing the quantitative assessment, the test report generator can automatically convert the deviation values ​​of each assessment dimension, the comprehensive robustness score, and the causal chain diagram into a structured report. The report includes: a test summary, recording the anomaly type, injection parameters, triggering conditions, and test time; a key event timeline, displaying each node and edge in the causal chain diagram and annotating the timestamp and level; a quantitative scoring table, presenting the scores for each assessment dimension and the comprehensive score; vulnerability information obtained based on the causal chain and assessment indicators, clearly indicating the weakest engine level and specific link; and optimization suggestions automatically generated based on the assessment results. The report supports multiple output formats such as SON, PDF / HTML, etc., and can be read by the program for subsequent analysis or viewed manually. It can also generate a visual causal network diagram, intuitively presenting the anomaly propagation path and system response process, thus providing a comprehensive and traceable basis for system optimization.

[0084] Further optionally, when the user selects adaptive injection as the injection strategy, the subsequent injection plan for the target abnormal event can be adjusted based on the above abnormal response results. The subsequent injection plan includes abnormal parameters, injection timing, and / or injection strength.

[0085] In one possible implementation, when the user selects adaptive injection as the injection strategy, the evaluation results of the response evaluation analyzer are fed back to the injection strategy manager via a callback interface. The injection strategy manager then automatically adjusts the injection plan for subsequent target anomalies based on the evaluation results. This injection plan may include adjustments to anomaly parameters, injection timing, and / or injection strength. For example, it may involve encrypted sampling near vulnerable points identified in the causal chain, increasing injection density, adjusting the step size or maximum value of incremental injection, or modifying the conditional trigger threshold to focus on high-risk areas. Subsequently, the process of anomaly injection, causal chain generation, benchmark data acquisition, quantitative evaluation, and report generation is repeated, forming an adaptive closed loop of "test-evaluation-optimization" until the preset test budget or model convergence condition is reached.

[0086] This embodiment can achieve the following beneficial effects: During low-altitude flight simulation, whenever an anomaly injection condition is triggered, an injection command carrying a target anomaly event is determined and injected into the target engine in the task flow engine, behavior rule engine, or physics calculation engine. Based on the target anomaly event, collaborative simulation processing is performed between the engines to allow the anomaly effect to propagate between the engines and obtain the corresponding causal chain data. Then, based on the causal chain data, the anomaly response result of the system is quantitatively evaluated.

[0087] By injecting target anomalous events into the mission flow engine, behavior rule engine, or physics calculation engine during low-altitude flight simulation, the anomalous effects can be realistically and chain-propagated between engines, generating causal chain data. This not only accurately covers dynamic risk scenarios through conditional triggering and reduces repetitive work, thus improving testing efficiency and coverage, but also avoids the distortion of surface injection by injecting at the starting point of the causal chain, significantly improving test fidelity.

[0088] Based on the same inventive concept, embodiments of the present invention provide an anomaly testing device for a low-altitude flight simulation system. The system includes a task flow engine, a behavior rule engine, and a physics calculation engine. This device is used to implement the aforementioned anomaly testing for the low-altitude flight simulation system. Figure 6 As shown, the anomaly testing device 600 includes: an instruction generation unit 601, an anomaly injection unit 602, a simulation unit 603, and a quantitative evaluation unit 604.

[0089] The instruction generation unit 601 is used to determine an injection instruction whenever an abnormal injection condition is triggered during the low-altitude flight simulation of at least one simulation entity, wherein the injection instruction carries the target abnormal event to be injected. An exception injection unit 602 is used to inject the target exception event into the target engine based on the injection instruction, wherein the target engine is the task flow engine, the behavior rule engine, or the physical calculation engine. Simulation unit 603 is used to perform collaborative simulation processing between the task flow engine, the behavior rule engine and the physical calculation engine based on the target abnormal event, so that the abnormal effect corresponding to the target abnormal event propagates between the engines to obtain the causal chain data corresponding to the target abnormal event. The quantitative evaluation unit 604 is used to quantitatively evaluate the abnormal response results of the system based on the causal chain data.

[0090] Optionally, the simulation unit 603 is used for: Multiple simulation events within a preset time window are extracted, starting from the trigger time of the target abnormal event; Based on the temporal proximity, simulation entity correlation, and type correlation between the target abnormal event and the simulation event, the correlation score of each simulation event is determined, and the simulation event with a correlation score exceeding a preset correlation threshold is regarded as a correlated event. Starting with the target abnormal event, causal chain data is constructed based on the target abnormal event and each of the related events in chronological order of their triggering times.

[0091] Optionally, the temporal proximity is used to indicate that the time interval between the target anomalous event and the simulated event is similar; The simulation entity association is used to indicate that the target abnormal event and the simulation event belong to the same simulation entity; The type correlation is used to indicate that the target anomalous event and the simulated event conform to the associated response type.

[0092] Optionally, the quantification evaluation unit 604 is used for: Obtain the evaluation dimension benchmark data corresponding to the target abnormal event. The evaluation dimension benchmark data refers to the normal data corresponding to each preset evaluation dimension when the target abnormal event does not exist. Based on the causal chain data, the actual data corresponding to each preset evaluation dimension is determined after the system responds to the target abnormal event; For each of the preset evaluation dimensions, determine the deviation value between the actual data and the normal data; Based on the deviation value corresponding to each of the preset evaluation dimensions, the abnormal response results of the system to the target abnormal event are quantitatively evaluated.

[0093] Optionally, the quantification evaluation unit 604 is used for: Obtain the first system operating status data stored before injecting the target anomaly event into the target engine, and determine the evaluation dimension benchmark data corresponding to the target anomaly event based on the first system operating status data; or, Simultaneously run a first simulation instance injected with the target abnormal event and a second simulation instance without the target abnormal event injected, obtain the second system operation status data corresponding to the second simulation instance, and determine the evaluation dimension benchmark data corresponding to the target abnormal event based on the second system operation status data.

[0094] Optionally, the preset evaluation dimensions include any one or more of the following: Anomaly detection capability, used to quantify detection latency and detection rate; Response timeliness is used to quantify decision delays and control effectiveness delays; Decision effectiveness is used to quantify task completion rate and security incident incidence rate; The scope of the chain reaction is used to quantify the number of affected engines and the number of state variable changes.

[0095] Optionally, the apparatus further includes an injection plan adjustment unit, the injection plan adjustment unit being used for: Based on the abnormal response results, the subsequent injection plan for the target abnormal event is adjusted, and the subsequent injection plan includes abnormal parameters, injection timing and / or injection intensity.

[0096] Optionally, the task flow engine is used to determine the task instruction for each simulation step; or, upon receiving a task adjustment request triggered by the behavior rule engine, to determine another task instruction based on the task adjustment request. The behavior rule engine is used to determine a decision result based on the task instructions and / or the current physical state data of each of the simulation entities, as well as the target rules corresponding to the current target facts matched in the rule base, wherein the decision result includes task adjustment requests and / or control instructions; The physical calculation engine is used to determine new physical state data for each simulation entity based on the control command triggered by the behavior rule engine when it receives the control command. The simulation unit 603 is used for: After injecting the target abnormal event into the target engine: If the target engine is the task flow engine, then in the task flow engine, the corresponding task instruction is determined based on the target abnormal event; If the target engine is the behavior rule engine, then in the behavior rule engine, the corresponding task adjustment request and / or control instruction are determined based on the target abnormal event; If the target engine is the physical computing engine, then in the physical computing engine, the corresponding physical state data is determined based on the target abnormal event.

[0097] This embodiment can achieve the following beneficial effects: During low-altitude flight simulation, whenever an anomaly injection condition is triggered, an injection command carrying a target anomaly event is determined and injected into the target engine in the task flow engine, behavior rule engine, or physics calculation engine. Based on the target anomaly event, collaborative simulation processing is performed between the engines to allow the anomaly effect to propagate between the engines and obtain the corresponding causal chain data. Then, based on the causal chain data, the anomaly response result of the system is quantitatively evaluated.

[0098] By injecting target anomalous events into the mission flow engine, behavior rule engine, or physics calculation engine during low-altitude flight simulation, the anomalous effects can be realistically and chain-propagated between engines, generating causal chain data. This not only accurately covers dynamic risk scenarios through conditional triggering and reduces repetitive work, thus improving testing efficiency and coverage, but also avoids the distortion of surface injection by injecting at the starting point of the causal chain, significantly improving test fidelity.

[0099] An exemplary embodiment of the present invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the electronic device to perform a method according to an embodiment of the present invention.

[0100] An exemplary embodiment of the present invention also provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of the present invention.

[0101] An exemplary embodiment of the present invention also provides a computer program product, including a computer program, wherein, when executed by a computer's processor, the computer program is used to cause the computer to perform a method according to an embodiment of the present invention.

[0102] refer to Figure 7 The present invention will now be described in the form of a structural block diagram of an electronic device 700 that can serve as a server or client of the present invention, which is an example of a hardware device that can be applied to various aspects of the present invention. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0103] like Figure 7 As shown, the electronic device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 702 or a computer program loaded from a storage unit 708 into a random access memory (RAM) 703. The RAM 703 may also store various programs and data required for the operation of the electronic device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0104] Multiple components in electronic device 700 are connected to I / O interface 705, including: input unit 706, output unit 707, storage unit 708, and communication unit 709. Input unit 706 can be any type of device capable of inputting information to electronic device 700. Input unit 706 can receive input digital or text information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 707 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 708 may include, but is not limited to, disk and optical disk. Communication unit 709 allows electronic device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth devices, Wi-Fi devices, WiMax devices, cellular communication devices, and / or the like.

[0105] The computing unit 701 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above. For example, in some embodiments, the above-described anomaly testing method for low-altitude flight simulation systems can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 700 via ROM 702 and / or communication unit 709. In some embodiments, the computing unit 701 can be configured to perform the above-described anomaly testing method for low-altitude flight simulation systems by any other suitable means (e.g., by means of firmware).

[0106] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0107] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0108] As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0109] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0110] The systems and technologies described herein can be implemented in computing systems that include back-end components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0111] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

Claims

1. An anomaly testing method for a low-altitude flight simulation system, characterized in that, The system includes a task flow engine, a behavior rule engine, and a physical calculation engine; The method includes: During the low-altitude flight simulation of at least one simulated entity, whenever an abnormal injection condition is triggered, an injection command is determined, which carries the target abnormal event to be injected. Based on the injection instruction, the target abnormal event is injected into the target engine, which is the task flow engine, the behavior rule engine, or the physical calculation engine; Based on the target abnormal event, collaborative simulation processing is performed between the task flow engine, the behavior rule engine, and the physical calculation engine, so that the abnormal effect corresponding to the target abnormal event propagates between the engines to obtain the causal chain data corresponding to the target abnormal event. Based on the causal chain data, the abnormal response results of the system are quantitatively evaluated; The step of obtaining the causal chain data corresponding to the target abnormal event includes: Multiple simulation events within a preset time window are extracted, starting from the trigger time of the target abnormal event; Based on the temporal proximity, simulation entity correlation, and type correlation between the target abnormal event and the simulation event, the correlation score of each simulation event is determined, and the simulation event with a correlation score exceeding a preset correlation threshold is regarded as a correlated event. Starting with the target abnormal event, causal chain data is constructed based on the target abnormal event and each of the related events in chronological order of their triggering times.

2. The method according to claim 1, characterized in that, The temporal proximity is used to indicate that the time interval between the target anomalous event and the simulated event is close; The simulation entity association is used to indicate that the target abnormal event and the simulation event belong to the same simulation entity; The type correlation is used to indicate that the target anomalous event and the simulated event conform to the associated response type.

3. The method according to claim 1, characterized in that, The quantitative evaluation of the abnormal response results of the system based on the causal chain data includes: Obtain the evaluation dimension benchmark data corresponding to the target abnormal event. The evaluation dimension benchmark data refers to the normal data corresponding to each preset evaluation dimension when the target abnormal event does not exist. Based on the causal chain data, the actual data corresponding to each preset evaluation dimension is determined after the system responds to the target abnormal event; For each of the preset evaluation dimensions, determine the deviation value between the actual data and the normal data; Based on the deviation value corresponding to each of the preset evaluation dimensions, the abnormal response results of the system to the target abnormal event are quantitatively evaluated.

4. The method according to claim 3, characterized in that, The step of obtaining the benchmark data for the evaluation dimensions corresponding to the target abnormal event includes: Obtain the first system operating status data stored before injecting the target anomaly event into the target engine, and determine the evaluation dimension benchmark data corresponding to the target anomaly event based on the first system operating status data; or, Simultaneously run a first simulation instance injected with the target abnormal event and a second simulation instance without the target abnormal event injected, obtain the second system operation status data corresponding to the second simulation instance, and determine the evaluation dimension benchmark data corresponding to the target abnormal event based on the second system operation status data.

5. The method according to claim 3, characterized in that, The preset evaluation dimensions include any one or more of the following: Anomaly detection capability, used to quantify detection latency and detection rate; Response timeliness is used to quantify decision delays and control effectiveness delays; Decision effectiveness is used to quantify task completion rate and security incident incidence rate; The scope of the chain reaction is used to quantify the number of affected engines and the number of state variable changes.

6. The method according to claim 1, characterized in that, The method further includes: Based on the abnormal response results, the subsequent injection plan for the target abnormal event is adjusted, and the subsequent injection plan includes abnormal parameters, injection timing and / or injection intensity.

7. The method according to claim 1, characterized in that, The co-simulation processing based on the target abnormal event among the task flow engine, the behavior rule engine, and the physics calculation engine includes: The task flow engine is used to determine the task instruction for each simulation step; or, upon receiving a task adjustment request triggered by the behavior rule engine, to determine another task instruction based on the task adjustment request. The behavior rule engine is used to determine a decision result based on the task instructions and / or the current physical state data of each of the simulation entities, as well as the target rules corresponding to the current target facts matched in the rule base, wherein the decision result includes task adjustment requests and / or control instructions; The physical calculation engine is used to determine new physical state data for each simulation entity based on the control command triggered by the behavior rule engine when it receives the control command. After injecting the target abnormal event into the target engine: If the target engine is the task flow engine, then in the task flow engine, the corresponding task instruction is determined based on the target abnormal event; If the target engine is the behavior rule engine, then in the behavior rule engine, the corresponding task adjustment request and / or control instruction are determined based on the target abnormal event; If the target engine is the physical computing engine, then in the physical computing engine, the corresponding physical state data is determined based on the target abnormal event.

8. An anomaly testing device for a low-altitude flight simulation system, characterized in that, The system includes a task flow engine, a behavior rule engine, and a physical calculation engine; The device includes: The instruction generation unit is used to determine an injection instruction whenever an abnormal injection condition is triggered during the low-altitude flight simulation of at least one simulation entity. The injection instruction carries the target abnormal event to be injected. An exception injection unit is used to inject the target exception event into the target engine based on the injection instruction, wherein the target engine is the task flow engine, the behavior rule engine, or the physical calculation engine; The simulation unit is used to perform collaborative simulation processing between the task flow engine, the behavior rule engine and the physical calculation engine based on the target abnormal event, so that the abnormal effect corresponding to the target abnormal event propagates between the engines to obtain the causal chain data corresponding to the target abnormal event. A quantitative evaluation unit is used to quantitatively evaluate the abnormal response results of the system based on the causal chain data. The simulation unit is used for: Multiple simulation events within a preset time window are extracted, starting from the trigger time of the target abnormal event; Based on the temporal proximity, simulation entity correlation, and type correlation between the target abnormal event and the simulation event, the correlation score of each simulation event is determined, and the simulation event with a correlation score exceeding a preset correlation threshold is regarded as a correlated event. Starting with the target abnormal event, causal chain data is constructed based on the target abnormal event and each of the related events in chronological order of their triggering times.

9. An electronic device, comprising: processor; as well as Stored program memory, The program includes instructions that, when executed by the processor, cause the processor to perform the method according to any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.

Images