A rule application method and device for a low-altitude flight simulation system

Abstract

This invention provides a rule application method and apparatus for low-altitude flight simulation systems, belonging to the field of computer simulation technology. The method includes: during a low-altitude flight simulation of at least one simulation entity, in response to an update of target facts, matching a target rule corresponding to the target facts in a rule base; determining a decision result based on the current target facts and target rules; when the decision result includes a task adjustment request, sending the task adjustment request to a task flow engine, so that the task flow engine determines another task instruction based on the task adjustment request, triggering an update of the target facts; when the decision result includes control instructions, sending the control instructions to a physics calculation engine, so that the physics calculation engine determines new physical state data for each simulation entity based on the control instructions, triggering an update of the target facts. Using this invention can improve the accuracy of simulation results.

Description

Technical Field

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

[0002] With the rapid development of the low-altitude economy, the operating scenarios of aircraft such as drones and eVTOLs are becoming increasingly complex, placing higher demands on the realism and dynamic response capabilities of low-altitude flight simulation systems.

[0003] Current mainstream low-altitude flight simulation systems generally adopt a fixed, pre-defined rule-driven architecture, with the rule logic being fixed and finalized during the system setup phase. This results in a flat rule hierarchy and rigid operational logic, capable only of performing simple logical judgments based on preset thresholds and static conditions. This makes it difficult to adapt to dynamic and complex scenarios such as temporary airspace control, multi-entity route conflicts, and aircraft equipment failures. Furthermore, such simulation systems only output decision commands in one direction, failing to perceive the execution effects of the simulated entities.

[0004] This fixed-rule model, lacking feedback loops, results in poor scenario adaptability of the simulation system, with simulation results deviating significantly from real-world operating scenarios, making it difficult to meet the simulation needs of the current complex low-altitude airspace environment. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a rule application method and apparatus for low-altitude flight simulation systems, which can improve the accuracy of simulation results.

[0006] According to one aspect of the present invention, a rule application method for a low-altitude flight simulation system is provided, the system including a task flow engine, a behavior rule engine and a physics calculation engine, the method being applied to the behavior rule engine; The method includes: In the low-altitude flight simulation of at least one simulated entity, in response to the update of the target facts, the target rules corresponding to the target facts are matched in the rule base according to the current target facts and the information of the current flight phase. The target facts include any one or more corresponding fact objects from the task instructions, the physical state data of each simulated entity, and the current simulation scene data. Based on the current target facts and the target rules, a decision result is determined, which includes a task adjustment request and / or control instructions; When the decision result includes the task adjustment request, the task adjustment request is sent to the task flow engine so that the task flow engine determines another task instruction based on the task adjustment request and triggers the update of the target facts; When the decision result includes the control command, the control command is sent to the physical computing engine so that the physical computing engine determines new physical state data for each of the simulation entities based on the control command, triggering an update of the target facts.

[0007] According to another aspect of the present invention, a rule application device for a low-altitude flight simulation system is provided, the system including a task flow engine, a behavior rule engine and a physics calculation engine, the device being applied to the behavior rule engine; The device includes: The rule matching unit is used to, in response to the update of the target facts during the low-altitude flight simulation of at least one simulated entity, match the target rules corresponding to the target facts in the rule base according to the current target facts and the information of the current flight phase. The target facts include any one or more corresponding fact objects from the following: mission instructions, physical state data of each simulated entity, and current simulation scene data. A rule decision unit is used to determine a decision result based on the current target facts and the target rules, the decision result including a task adjustment request and / or control instructions; The result transmission unit is configured to, when the decision result includes the task adjustment request, send the task adjustment request to the task flow engine so that the task flow engine determines another task instruction based on the task adjustment request and triggers the update of the target fact; and when the decision result includes the control instruction, send the control instruction to the physical calculation engine so that the physical calculation engine determines new physical state data for each of the simulation entities based on the control instruction and triggers the update of the target fact.

[0008] 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 rule application method for the low-altitude flight simulation system.

[0009] 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 execute the rule application method for the low-altitude flight simulation system described above.

[0010] In this invention, during the low-altitude flight simulation of at least one simulated entity, the target facts are continuously updated, triggering a behavior rule engine to match target rules in the rule base and determine a decision based on the current target facts and target rules. This decision may include a task adjustment request and / or control instructions. The task adjustment request can be sent to the task flow engine, enabling it to determine another task instruction based on the request; the control instructions can be sent to the physics calculation engine, allowing it to determine new physical state data for each simulated entity based on the control instructions. These new task instructions and physical state data trigger the updating of the target facts, which in turn triggers the behavior rule engine to match target rules, thus driving the continuous iteration of the low-altitude flight simulation and forming a real-time closed loop of "fact update - rule reasoning - decision output - fact re-update" for low-altitude flight simulation. Through this continuously iterative closed-loop feedback mechanism, the behavior decisions and physical states of the simulated entities can respond in real time to changes in the simulation scenario, thereby improving the realism and accuracy of the simulation results. 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 a rule application 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 provided according to an exemplary embodiment of the present invention is shown; Figure 3 A schematic diagram of a behavior rule engine provided according to an exemplary embodiment of the present invention is shown; Figure 4 A schematic diagram of a rule cascading chain provided according to an exemplary embodiment of the present invention is shown; Figure 5 A schematic diagram of a cross-level rule cascading chain provided according to an exemplary embodiment of the present invention is shown; Figure 6 A schematic diagram illustrating the application of flight lifecycle rules according to an exemplary embodiment of the present invention is shown. Figure 7 A schematic block diagram of a rule application device for a low-altitude flight simulation system provided according to an exemplary embodiment of the present invention is shown. Figure 8 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 a rule-based application method for low-altitude flight simulation systems. This method can be implemented by a terminal, a server, and / or other devices with processing capabilities. The method provided in this embodiment can be implemented 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 a rule application 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, the behavior rule engine is as follows Figure 3 As shown.

[0019] This low-altitude flight simulation system comprises a mission flow engine, a behavior rule engine, and a physics calculation engine, enabling 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 mission 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 entity, influencing the decision-making of the behavior rule engine.

[0020] The rule application method provided by this invention is applied to the above-mentioned behavior rule engine, and the method includes the following steps 101-104.

[0021] Step 101: In the low-altitude flight simulation process of at least one simulation entity, in response to the update of the target facts, the target rules corresponding to the target facts are matched in the rule base according to the current target facts and the information of the current flight phase.

[0022] The target facts include any one or more corresponding fact objects from the task instructions, the physical state data of each simulation entity, and the current simulation scene data.

[0023] In one possible implementation, during the low-altitude flight simulation of at least one simulated entity, the working memory of the behavior rule engine can continuously maintain and update the fact base. The fact base stores multiple fact objects, which are various events that trigger rules, including task instructions triggered by the task flow engine, physical state data of each simulated 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.). These fact objects can serve as real-time input for rule matching, providing dynamic and effective factual support for rule reasoning.

[0024] Correspondingly, facts can be updated in any one or more of the following ways: The fact object that receives the task instructions triggered by the task flow engine is updated as a current target fact; The fact object that receives the physical state data of each simulated entity from the physics calculation engine is updated as a current target fact; Receive the fact object of the current simulation scene data and update it as a target fact.

[0025] The behavior rule engine can subscribe to the instruction stream of the task flow engine. When the task flow engine issues a task instruction (such as "enter the cruise phase"), it can obtain the fact object corresponding to the task instruction and insert it into the event library in its working memory as the target fact to be matched. By subscribing to the state stream of the physics calculation engine, when the physics calculation engine feeds back the physical state data of the simulated entity (such as "yaw caused by crosswind", "battery power below the threshold", and six-degree-of-freedom dynamics data of the aircraft), it can obtain the event object of the physical state data and insert it into the event library in its working memory as the target fact to be matched. At the same time, by subscribing to the scene data stream of the simulation scene, it can obtain the event object of the simulation scene data in a periodic or timed manner and insert it into the event library in its working memory as the target fact to be matched.

[0026] Low-altitude flight management covers key aspects such as airspace application, conflict detection, path planning, real-time monitoring, anomaly warning, and post-event assessment, constituting a complete flight lifecycle. Each flight stage has an integration interface with the behavior rule engine. This interface, serving as a lifecycle embedding point, can trigger rule engine calls at key nodes throughout the flight lifecycle, integrating the factual objects corresponding to the contextual data of each stage (such as flight plans, real-time location, and environmental information) into a unified decision context. This decision context is the set of decision-making bases supporting rule matching and decision reasoning.

[0027] In response to fact updates in the fact base, the behavioral rule engine can perform the following rule matching process: Based on the information of the current flight phase, retrieve the set of target rules corresponding to the current flight phase from the rule base; Based on the current target facts, obtain the target rules that match the target facts from the target rule set.

[0028] During the construction phase of the simulation system, the rule base needs to be built in advance. Domain experts can write rules through the rule definition layer, which provides tools such as rule editors, syntax checkers, and template libraries. It supports various rule expression methods such as natural language templates, domain-specific languages ​​(such as DRL, DSL, etc.), and decision tables. After syntax highlighting and real-time validation, the rules are serialized into standard formats such as JSON or DRL and stored in the rule base.

[0029] As the core storage and management center for behavioral rules, the rule base uses relational databases (such as MySQL and PostgreSQL) to achieve centralized storage and version control: each rule is assigned a unique ID (identity identifier) ​​and metadata such as creator, creation time, modification history, and scope of effect are recorded; rules are classified and managed according to low-altitude flight stage and the level to which the rule belongs, while analyzing and maintaining the dependency and conflict relationships between rules, as well as the timing, periodic, and conditional activation strategies, providing basic support for the rapid retrieval and invocation of rules in the subsequent simulation operation stage.

[0030] During rule matching, the behavioral rule engine's inference engine can perform pattern matching based on the RETE algorithm (Network Pattern Matching Algorithm). Combining information from the current flight phase, it retrieves the rule set for the corresponding phase from the rule base and uses the current target fact as input to quickly filter target rules that match the target fact. Whenever any target rule that matches the target fact is selected, step 102 is entered to execute the target rule for decision-making.

[0031] Step 102: Based on the current target facts and target rules, determine the decision results, which include task adjustment requests and / or control instructions.

[0032] In one possible implementation, the behavior rule engine can execute matched target rules based on a decision context that includes task instructions, current 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 simulated entities, and scene constraints to generate corresponding decision results. Since the decision-making process is based primarily on task instructions and the physical state data of simulated entities, while also incorporating factual information from the entire scene, such as the environment, airspace, and the simulation system's operational status, 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.

[0033] Step 103: When the decision result includes a task adjustment request, send the task adjustment request to the task flow engine so that the task flow engine can determine another task instruction based on the task adjustment request and trigger the update of the target facts.

[0034] In one possible implementation, when the behavior rule engine generates a decision result that indicates the task needs adjustment (e.g., a "task abnormality" determination), 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, returning to step 101 to continue execution, thus achieving closed-loop iteration of the simulation task and dynamic adaptation of rules.

[0035] Step 104: When the decision result includes control instructions, send the control instructions to the physics calculation engine so that the physics calculation engine can determine new physical state data for each simulation entity based on the control instructions and trigger the update of the target facts.

[0036] In one possible implementation, when the behavior rule engine generates a decision result characterizing the physical control of the simulated entity (e.g., determining it as "climb and avoid"), this decision result is sent as a control command to the physics calculation engine. Upon receiving the control command, the physics calculation engine can calculate the six degrees of freedom attitude, flight position, and sensor data of each simulated entity based on the control command and the current simulation scene data, generating new physical state data for each simulated entity and triggering the update of the target facts. After the new target facts are injected into the fact base, a new round of decision processing will be triggered, returning to step 101 to continue execution, achieving closed-loop iteration of the simulation task and dynamic adaptation of rules.

[0037] Optionally, the decision results obtained from executing the target rule can be divided into two categories: external feedback and internal feedback. Among them, task adjustment requests and control instructions belong to external feedback, which are used to output to the task flow engine or physical calculation engine outside the behavior rule engine to drive task flow updates or entity physical state iterations; internal feedback is used to circulate within the behavior rule engine, triggering the execution of subsequent associated rules, forming a rule cascade relationship with the original rules, and realizing chain reasoning of complex logic.

[0038] In this embodiment, hierarchical modeling of rules enables precise differentiation and routing of decision outcome types. Specifically, the attribute information of a target rule can include its hierarchical information, which corresponds to one or more target engines among the task flow engine, behavior rule engine, or physical computing engine. Therefore, after rule execution, the feedback path can be automatically determined based on the hierarchical information, routing the result to the corresponding engine. The hierarchical level corresponding to the task flow engine can be the strategic level, and the rules at this level can be called strategic rules; the hierarchical level corresponding to the behavior rule engine can be the tactical level, and the rules at this level can be called tactical rules; the hierarchical level corresponding to the physical computing engine can be the physical level, and the rules at this level can be called physical rules.

[0039] The corresponding processing of decision results may include: When the hierarchical information of the target rule corresponds to the task flow engine, the target rule is executed to determine the strategic decision. When the strategic decision indicates a need to adjust the task, it is presented as a task adjustment request. The strategic decision focuses on overall planning and process control at the task level, including decisions indicating the need for task adjustments (such as task anomalies or path replanning requests), as well as other task-level control instructions such as task priority, airspace allocation, and process branch selection. When a strategic decision indicates a need to adjust the task, it is fed back to the task flow engine as a task adjustment request to drive task objective updates and the generation of new task instructions.

[0040] When the hierarchical information of the target rule corresponds to the physics calculation engine, the target rule is executed to determine the physics decision, and the physics decision is used as the control command. The physics decision focuses on the motion control and state adjustment of the simulated entity, including commands that directly control the entity's actions (such as target altitude, speed, heading angle, thrust output, and control surface deflection), as well as commands that correct and constrain the entity's motion state (such as over-limit protection, attitude stabilization control, and emergency obstacle avoidance maneuver parameters).

[0041] When the hierarchical information of the target rule corresponds to the behavior rule engine, the target rule is executed to determine the tactical decision. The tactical decision focuses on the logical reasoning and chain execution within the behavior rule engine, including intermediate results that trigger the execution of subsequent related rules (such as conflict detection markers, status judgment results, and scene event identifiers), as well as branch control and priority adjustment instructions for the rule execution process.

[0042] The aforementioned external and internal feedback mechanisms respectively realize closed-loop control of the behavior rule engine, task flow engine, and physics calculation engine, as well as chain reasoning within the engine. Together, they form a full-process intelligent management loop of "monitoring-fact update-rule reasoning-internal and external feedback-re-monitoring", providing complete and self-consistent dynamic decision-making logic support for low-altitude flight simulation.

[0043] Furthermore, the processing to form rule cascades can be as follows: Based on the decision result corresponding to any target rule, a fact object is generated and updated as a current target fact. If a new target rule corresponding to the current target fact is found in the rule base, the original target rule is used as the first rule and the new target rule is used as the second rule. After executing the first rule to determine the corresponding decision result, the second rule is executed to determine the corresponding decision result, and the process returns to the step of generating a fact object based on the decision result corresponding to any target rule, thus forming a rule cascade.

[0044] In one possible implementation, the behavior rule engine can convert the decision result into a corresponding fact object and inject it as a new target fact into the fact base, triggering a new round of rule matching and execution. If a new target rule corresponding to the tactical decision is matched in the rule base, the original target rule that triggered this tactical decision and has been executed is recorded as the first rule, and the newly matched target rule is recorded as the second rule.

[0045] The second rule is executed next to determine its corresponding decision result. No other rules are executed between the execution of the first and second rules to ensure the timing and integrity of the cascaded logic.

[0046] Based on the decision result output by the second rule, a corresponding fact object is generated and the target fact is updated, triggering a new round of rule matching. If a subsequent related rule is matched, it is executed as a new cascade node, thus forming a rule cascade chain that can be extended layer by layer. This rule cascade chain is as follows: Figure 4 As shown.

[0047] If no subsequent rule corresponding to the current tactical decision is found during the rule matching process, the current cascade chain will naturally terminate, awaiting the injection of new target facts into the fact base before triggering a new round of rule matching and execution. It should be noted that task adjustment requests corresponding to strategic decisions and control commands corresponding to physical decisions, while being output to the external engine, will also be converted into new fact objects and injected into the fact base. Therefore, the cascade chain will not necessarily terminate due to the output of external decisions; these new facts may also trigger a new round of rule matching, forming cross-level rule cascades. Cross-level rule cascade chains are as follows: Figure 5 As shown.

[0048] This rule cascading mechanism enables complex decisions to be made through the sequential combination of multiple rules, rather than relying on a single complex rule, thus improving the maintainability and reusability of the rules.

[0049] Optionally, the attribute information of the target rule can also include influence level information, which corresponds to one or more engines among the task flow engine, behavior rule engine, and physical calculation engine. The influence level information of the second rule matches any engine corresponding to the influence level information of the first rule, thus forming the aforementioned cross-level rule cascade. That is, when a target rule is triggered, its decision result not only takes effect at its own level but can also propagate to other levels based on its influence level information, thereby triggering rules at that level. For example, when a physical level rule is triggered, its execution result (such as "attitude loss of control") not only takes effect at that level but also propagates to the tactical level via the event bus, triggering tactical rules (such as "initiating emergency landing procedures"). The decision result at the tactical level further propagates to the strategic level, triggering task flow adjustments. This hierarchical propagation is directional and controllable, avoiding rule storms.

[0050] Further, optionally, when the number of target rules matched in step 101 or when forming rule concatenation is greater than 1, the following scheduling process can also be performed: The execution order of each target rule is determined based on the scheduling strategy, and the rule decision sequence is determined so that the target rules are executed in the order of the rule decision sequence.

[0051] The scheduling strategy may include a priority sorting strategy and a rule conflict resolution strategy.

[0052] Priority ranking strategy is used to determine the execution order of each target rule according to its priority. The priority is adjusted based on the decision effect of the corresponding target rule to increase the priority of target rules with positive effects or decrease the priority of target rules with negative effects.

[0053] The rule conflict resolution strategy is used to determine the target rule to be retained among multiple conflicting target rules based on the rule hierarchy weight and information from the current flight phase.

[0054] In one possible implementation, when multiple target rules are matched simultaneously, the behavior rule engine can determine the execution order of each target rule and generate a rule decision sequence according to a preset scheduling strategy. Subsequent execution processes will then follow this sequence, avoiding disorderly competition between rules. The scheduling strategy includes both a priority ranking strategy and a rule conflict resolution strategy, which work together to ensure the orderliness and rationality of the rule reasoning process.

[0055] The priority ranking strategy is used to determine the execution order of each target rule according to its priority. The priority is not a fixed configuration but a dynamic attribute of the rule, which can be continuously adjusted based on the rule's actual decision-making effect. When a rule generates control commands that produce the expected results multiple times consecutively (such as successful obstacle avoidance or smooth task progress), its priority is increased so that it is used preferentially in subsequent scheduling. Conversely, if a rule causes negative effects multiple times consecutively (such as frequent false alarms or control command failure), its priority is decreased, and the engine will try other rules, forming a feedback-driven dynamic rule optimization mechanism.

[0056] The rule conflict resolution strategy is designed for scenarios where multiple rules are activated simultaneously. When rules at different levels conflict in decision-making (for example, a tactical rule requires "climb and avoidance," while a physical rule requires "maintain current attitude to maintain stability"), it does not simply prioritize rules by a single priority. Instead, it combines the rule level weights with information from the current flight phase for comprehensive arbitration: first, it assigns basic weights based on the level to which the rule belongs; then, it dynamically weighs the necessity of executing different rules in conjunction with the scenario constraints of the current flight phase, and selects the target rules that should be retained to ensure that the final decision not only conforms to the overall mission objective but also satisfies the physical operational constraints of the current phase.

[0057] Optionally, the low-altitude flight simulation system may also include a spatial grid computing engine, which can be integrated as a built-in component into the behavior rule engine. This allows the grid codes output by the spatial grid computing engine to be used as the native condition parameters (i.e., first-order citizens) of the rule conditions of the behavior rule engine. This supports the direct reference of grid codes by rule conditions without the need to convert spatial coordinate data into general facts before matching.

[0058] The process of determining decision results based on a spatial grid computing engine may include: When the target rule includes an aggregation function, structured aggregation data that fits the aggregation function is obtained from the grid data of the current spatial grid. The decision result is determined based on the structured aggregation data. The structured aggregation data is obtained by the behavior rule engine through sliding updates of the time window after each simulation step. When the target rule includes spatial constraints, the spatial constraint determination of the current spatial grid is determined based on the spatial constraint determination of the parent grid to which the current spatial grid belongs, and the decision result is determined based on the spatial constraint determination.

[0059] In one possible implementation, when the target rule contains an aggregation function, in order to avoid repeatedly traversing historical location data for each rule evaluation and significantly reduce computational overhead, the behavior rule engine can convert the aggregation operator into a dedicated data structure for maintaining time windows during the compilation phase. It can extract structured aggregation data that fits the aggregation function from the grid data of the current spatial grid and continuously maintain it through a sliding window after each simulation step. For example, for the rule "the number of aircraft in the same grid exceeds 10 in the last 5 minutes", the engine will maintain the aircraft number statistics within the corresponding time window, and then execute the target rule and determine the decision result based on the aggregation data.

[0060] When the target rule includes spatial constraints, in order to avoid performing full spatial geometry calculations for each grid, pruning optimization can be performed using the hierarchical characteristics of grid encoding. First, based on the spatial constraint judgment results of the parent grid to which the current spatial grid belongs, the spatial constraint judgment of the current spatial grid itself is derived and determined. For example, when detecting whether an aircraft has entered a no-fly zone, first check whether the parent grid of the grid where the aircraft is located contains a no-fly zone. If it does not contain a no-fly zone, the detailed check of the current grid can be skipped. Then, the target rule is executed based on the final spatial constraint judgment and the decision result is determined.

[0061] This embodiment deeply integrates the inference capabilities of the spatial grid computing engine and the behavioral rule engine, achieving the unification of spatial computing and rule-based reasoning. On one hand, spatial computing is simplified from complex geometric operations to efficient encoding comparisons, significantly improving execution efficiency. On the other hand, the expression of spatiotemporal aggregation rules is simplified to intuitive rule statements, which business personnel can directly write and maintain without implementing complex historical data queues and real-time computing logic. This greatly reduces the threshold for rule writing and the probability of errors. At the same time, hierarchical pruning optimization reduces unnecessary computation, providing efficient support for large-scale, high-frequency rule reasoning in low-altitude flight scenarios.

[0062] Furthermore, the behavior rule engine can also sense whether the physical state of the simulated entity output by the physics calculation engine is approaching physical limits (such as maximum overload or minimum turning radius). When approaching physical limits, the rule engine automatically reduces the requirement for response speed and increases the safety margin; when far from physical limits, it can adopt more aggressive strategies to improve efficiency. Based on this, a closed loop of "decision-execution-perception-re-decision" is constructed, and the rules can self-optimize based on the execution effect, realizing true adaptive intelligent decision-making.

[0063] This embodiment can achieve the following beneficial effects: During low-altitude flight simulation of at least one simulated entity, the target facts are continuously updated, triggering the behavior rule engine to match target rules in the rule base and determine a decision based on the current target facts and target rules. This decision may include task adjustment requests and / or control commands. Task adjustment requests can be sent to the task flow engine to determine another task command based on the request; control commands can be sent to the physics calculation engine to determine new physical state data for each simulated entity based on the control commands. These new task commands and physical state data trigger updates to the target facts, which in turn trigger the behavior rule engine to match target rules, thus driving the continuous iteration of the low-altitude flight simulation and forming a real-time closed loop of "fact update - rule reasoning - decision output - fact update again." Through this continuously iterative closed-loop feedback mechanism, the behavior decisions and physical states of the simulated entities can respond in real time to changes in the simulation scenario, thereby improving the realism and accuracy of the simulation results.

[0064] Based on the same inventive concept, the embodiments of this invention will describe the process of applying the rules in chronological order, through each stage of the low-altitude flight simulation process, as follows: Figure 6 The diagram shows the application of flight lifecycle rules.

[0065] Prior to low-altitude flight simulation, a rule definition and management phase may be included, which may include the following steps: Step 1: Classify the rules according to the management area (airspace management, flight rules, emergency response, safety assessment) to form a rule list, and clarify the business semantics, triggering conditions, execution actions, and constraint scope of each rule.

[0066] Step 2: Utilize the editing environment provided by the rule editor, along with pre-built rule templates from the template library (such as no-fly zone detection templates, interval maintenance templates, priority judgment templates, etc.), to assist rule writers in quickly constructing rules. During rule writing, the syntax checker performs real-time validation of the rule syntax, indicating error locations and providing correction suggestions; the rule language definition tool supports custom domain-specific languages, making rule expressions more closely aligned with the semantics of low-altitude airspace management.

[0067] For example, the rules for detecting incursions into a no-fly zone can be expressed as: Rule "No-fly zone intrusion detection" when $flight: Flight(position $pos) $noFly: NoFlyZone(zoneCode, contains($pos)) then insert(new Alert("No-fly zone intrusion", $flight.id, $noFly.zoneCode)); end Step 3: Configure metadata (effective time, priority, version number, domain) for structured rules using the rule editor.

[0068] Step 4: Conduct rule testing to verify the correctness of the rule logic and the execution efficiency.

[0069] Step 5: Publish the rule to the rule library, update its effective status, and store it as a template in the template library of the rule definition layer.

[0070] During the simulation initialization phase, the task flow engine parses the task script and generates a macro-level task execution plan; the behavior rule engine loads the relevant rule set according to the task type and initializes the decision context (such as clearing the working memory and setting initial facts).

[0071] The low-altitude flight simulation process can be divided into three stages: pre-flight rule application, in-flight rule application, and post-flight rule application.

[0072] The aforementioned pre-flight rule application phase may include the following steps: Step 1: The user submits a flight plan (take-off and landing points, time, altitude, aircraft type), which is then packaged into a task request and sent to the task flow engine.

[0073] Step 2: The task flow engine triggers the airspace application approval, converts the plan data into facts, and calls the behavior rule engine.

[0074] Step 3: The behavior rule engine executes the admission rules (e.g., whether it is in a no-fly zone, whether it exceeds the height limit, whether it conflicts with existing plans).

[0075] Step 4: The rule execution result is returned to the task flow engine. If it passes, proceed to the next step; otherwise, it is rejected and the reason is given.

[0076] Step 5: The task flow engine triggers path planning, and the planning calculation point calls the rule engine again to execute path optimization rules (such as prioritizing low-energy routes and avoiding sensitive areas).

[0077] Step 6: The behavior rule engine returns the optimized route to the task flow engine, which writes it into the flight plan database and updates the task status to "planned," awaiting subsequent execution.

[0078] The above-mentioned in-flight rule application phase may include the following steps: Step 1: The physics calculation engine continuously reports real-time data such as the aircraft's position, speed, and weather to the behavior rule engine and the task flow engine.

[0079] Step 2: The real-time monitoring points of the behavior rule engine subscribe to the state stream of the physical calculation engine and convert the received real-time data into fact objects in the working memory.

[0080] Step 3: The behavior rule engine's inference engine performs rule matching on the latest facts in the working memory at a preset period (e.g., once per second), such as: Spacing maintenance rule: Detect whether the distance between two aircraft within the same airspace grid is less than the minimum safe spacing; Deviation from route rule: Detects whether the aircraft's current position has deviated from the planned route by more than a threshold; Weather deterioration rule: Combines meteorological grid data to detect whether an aircraft has entered a hazardous weather zone; Fuel level warning rule: Detect whether the remaining fuel is insufficient to complete the remaining voyage.

[0081] Step 4: When the conditions of a rule are met, the rule is activated and added to the decision-maker. The decision-maker executes the rules sequentially according to scheduling rules such as rule priority and conflict resolution strategies, generating rule execution results. These results may produce two types of outputs: Internal cascade output: Insert new facts (such as "conflict risk detected") into the fact base, trigger the execution of subsequent rules, and form a rule cascade. The intermediate results of the cascade chain can flow within the behavior rule engine. External output: The final output is a control command (such as "yaw 10 degrees to the right") sent to the physics calculation engine, or a mission adjustment request sent to the mission flow engine.

[0082] Step 5: The rule execution results output externally are sent to the corresponding engine or module through an external interface, such as: The "control commands" will be sent to the physics calculation engine, which will then convert them into specific control quantities and update the aircraft's status. A "task adjustment request" can be sent to the task flow engine, which will then decide whether to change the task objective or activate an emergency procedure.

[0083] Step 6: After the physics calculation engine executes the control command, the new aircraft status is reported again. The behavior rule engine re-evaluates based on the new aircraft status, forming a real-time closed loop of "monitoring-decision-execution-re-monitoring". At the same time, if the mission process engine receives a mission adjustment request, it may change the mission phase and influence the subsequent decisions of the behavior rule engine through fact injection.

[0084] The post-flight rule application phase mentioned above may include the following steps: Step 1: After the flight mission is completed, the evaluation and analysis point collects all flight data (track, events, command records).

[0085] Step 2: Convert historical data into facts and call the behavior rule engine to execute the evaluation rules.

[0086] Step 3: The behavior rule engine performs compliance checks (e.g., whether the spacing standards are followed throughout the flight, and whether the flight is within the designated airspace).

[0087] Step 4: Based on the rule evaluation results, generate flight quality scores, violation records, safety recommendations, etc.

[0088] In addition, a dynamic rule adjustment phase may be included, which may include the following steps: Step 1: Monitor rule execution logs and system performance metrics to identify rule efficiency bottlenecks or logical defects.

[0089] Step 2: Rule administrators modify or add rules through the rule definition layer.

[0090] Step 3: After the new rule has been tested, it is published to the rule base and its effective status is set.

[0091] Step 4: The rule engine hot-loads new rules without interrupting operation. Subsequent evaluations use the updated rule set, and the hot-loading mechanism does not affect the simulation task being executed.

[0092] This embodiment can achieve the following beneficial effects: During low-altitude flight simulation of at least one simulated entity, the target facts are continuously updated, triggering the behavior rule engine to match target rules in the rule base and determine a decision based on the current target facts and target rules. This decision may include task adjustment requests and / or control commands. Task adjustment requests can be sent to the task flow engine to determine another task command based on the request; control commands can be sent to the physics calculation engine to determine new physical state data for each simulated entity based on the control commands. These new task commands and physical state data trigger updates to the target facts, which in turn trigger the behavior rule engine to match target rules, thus driving the continuous iteration of the low-altitude flight simulation and forming a real-time closed loop of "fact update - rule reasoning - decision output - fact update again." Through this continuously iterative closed-loop feedback mechanism, the behavior decisions and physical states of the simulated entities can respond in real time to changes in the simulation scenario, thereby improving the realism and accuracy of the simulation results.

[0093] Based on the same inventive concept, embodiments of the present invention provide a rule application device for low-altitude flight simulation systems, which is used to implement the aforementioned rule application method for low-altitude flight simulation systems. For example... Figure 7 As shown, the rule application device 700 includes: a rule matching unit 701, a rule decision unit 702, and a result transmission unit 703.

[0094] The rule matching unit 701 is used to, in response to the update of the target facts during the low-altitude flight simulation of at least one simulation entity, match the target rules corresponding to the target facts in the rule base according to the current target facts and the information of the current flight phase, wherein the target facts include any one or more corresponding fact objects among the mission instructions, the physical state data of each simulation entity, and the current simulation scene data. The rule decision unit 702 is used to determine a decision result based on the current target facts and the target rules, the decision result including a task adjustment request and / or control instructions; The result transmission unit 703 is configured to, when the decision result includes the task adjustment request, send the task adjustment request to the task flow engine so that the task flow engine determines another task instruction based on the task adjustment request and triggers the update of the target fact; and when the decision result includes the control instruction, send the control instruction to the physical calculation engine so that the physical calculation engine determines new physical state data for each of the simulation entities based on the control instruction and triggers the update of the target fact.

[0095] The apparatus further includes a fact updating unit, which is configured to update facts in any one or more of the following ways: The fact object that receives the task instruction triggered by the task flow engine is updated as a current target fact; The fact object that receives the physical state data of each of the simulated entities fed back by the physical calculation engine is updated as a current target fact; Receive the fact object of the current simulation scene data and update it as a target fact.

[0096] Optionally, the rule matching unit 701 is used for: Based on the information of the current flight segment, obtain the target rule set corresponding to the current flight segment from the rule base; Based on the current target facts, obtain the target rules that match the target facts from the set of target rules.

[0097] Optionally, the attribute information of the target rule includes the hierarchical information, which corresponds to any one of the task flow engine, the behavior rule engine, and the physical calculation engine. The rule decision unit 702 is used for: When the hierarchical information of the target rule corresponds to the task flow engine, a strategic decision is determined, wherein when the strategic decision indicates that the task needs to be adjusted, the strategic decision is used as a task adjustment request. When the hierarchical information of the target rule corresponds to the physical computing engine, a physical decision is determined and the physical decision is used as a control command. When the hierarchical information of the target rule corresponds to the behavior rule engine, a tactical decision is determined.

[0098] Optionally, the device further includes a rule cascading unit, the rule cascading unit being used for: Based on the decision result corresponding to any target rule, a fact object is generated and updated as a current target fact. If a new target rule corresponding to the current target fact is found in the rule base, the original target rule is used as the first rule and the new target rule is used as the second rule. After executing the first rule to determine the corresponding decision result, the second rule is then executed to determine the corresponding decision result, and the step of generating a fact object based on the decision result corresponding to any target rule is returned, so as to form a rule cascade.

[0099] Optionally, the attribute information of the target rule also includes influence level information, which corresponds to any one or more engines among the task flow engine, the behavior rule engine, and the physical calculation engine. The hierarchical information of the second rule is matched with any engine corresponding to the influence hierarchical information of the first rule to form a cross-level rule cascade.

[0100] Optionally, when the number of matched target rules is greater than 1, the rule decision unit 702 is further configured to: The execution order of each target rule is determined according to the scheduling strategy, and a rule decision sequence is determined so that the target rules are executed in the order of the rule decision sequence. The scheduling strategy includes a priority ranking strategy and a rule conflict resolution strategy; The priority ranking strategy is used to determine the execution order of each target rule according to the order of priority, wherein the priority is adjusted based on the decision effect of the corresponding target rule, so as to increase the priority of target rules with positive effects or decrease the priority of target rules with negative effects. The rule conflict resolution strategy is used to determine the target rule to be retained among multiple conflicting target rules based on the rule hierarchy weight and the information of the current flight segment.

[0101] Optionally, the system further includes a spatial grid computing engine, which is integrated as a built-in component into the behavior rule engine, so that the grid code output by the spatial grid computing engine is used as the native condition parameter of the rule conditions of the behavior rule engine; The rule decision unit 702 is used for: When the target rule includes an aggregation function, structured aggregation data adapted to the aggregation function is obtained from the grid data of the current spatial grid, so as to determine the decision result based on the structured aggregation data. The structured aggregation data is obtained by the behavior rule engine through sliding updates of the time window after each simulation step. When the target rule includes spatial constraints, the spatial constraint determination of the current spatial grid is determined based on the spatial constraint determination of the parent grid to which the current spatial grid belongs, and the decision result is determined based on the spatial constraint determination.

[0102] This embodiment can achieve the following beneficial effects: During low-altitude flight simulation of at least one simulated entity, the target facts are continuously updated, triggering the behavior rule engine to match target rules in the rule base and determine a decision based on the current target facts and target rules. This decision may include task adjustment requests and / or control commands. Task adjustment requests can be sent to the task flow engine to determine another task command based on the request; control commands can be sent to the physics calculation engine to determine new physical state data for each simulated entity based on the control commands. These new task commands and physical state data trigger updates to the target facts, which in turn trigger the behavior rule engine to match target rules, thus driving the continuous iteration of the low-altitude flight simulation and forming a real-time closed loop of "fact update - rule reasoning - decision output - fact update again." Through this continuously iterative closed-loop feedback mechanism, the behavior decisions and physical states of the simulated entities can respond in real time to changes in the simulation scenario, thereby improving the realism and accuracy of the simulation results.

[0103] 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.

[0104] 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.

[0105] 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.

[0106] refer to Figure 8 The present invention will now be described in the form of a structural block diagram of an electronic device 800 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.

[0107] like Figure 8 As shown, the electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. The RAM 803 may also store various programs and data required for the operation of the electronic device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0108] Multiple components in electronic device 800 are connected to I / O interface 805, including: input unit 806, output unit 807, storage unit 808, and communication unit 809. Input unit 806 can be any type of device capable of inputting information to electronic device 800. Input unit 806 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 807 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 808 may include, but is not limited to, disks and optical discs. Communication unit 809 allows electronic device 800 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.

[0109] The computing unit 801 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 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 801 performs the various methods and processes described above. For example, in some embodiments, the rule application method for low-altitude flight simulation systems described above can be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 800 via ROM 802 and / or communication unit 809. In some embodiments, the computing unit 801 can be configured to perform the rule application method for low-altitude flight simulation systems described above by any other suitable means (e.g., by means of firmware).

[0110] 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.

[0111] 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.

[0112] 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.

[0113] 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).

[0114] 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.

[0115] 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. A rule-based application method for low-altitude flight simulation systems, characterized in that, The system includes a task flow engine, a behavior rule engine, and a physical calculation engine, and the method is applied to the behavior rule engine. The method includes: In the low-altitude flight simulation of at least one simulated entity, in response to the update of the target facts, the target rules corresponding to the target facts are matched in the rule base according to the current target facts and the information of the current flight phase. The target facts include any one or more corresponding fact objects from the task instructions, the physical state data of each simulated entity, and the current simulation scene data. Based on the current target facts and the target rules, a decision result is determined, which includes a task adjustment request and / or control instructions; When the decision result includes the task adjustment request, the task adjustment request is sent to the task flow engine so that the task flow engine determines another task instruction based on the task adjustment request and triggers the update of the target facts; When the decision result includes the control command, the control command is sent to the physical computing engine so that the physical computing engine determines new physical state data for each of the simulation entities based on the control command, triggering an update of the target facts.

2. The method according to claim 1, characterized in that, Update the facts using any one or more of the following methods: The fact object that receives the task instruction triggered by the task flow engine is updated as a current target fact; The fact object that receives the physical state data of each of the simulated entities fed back by the physical calculation engine is updated as a current target fact; Receive the fact object of the current simulation scene data and update it as a target fact.

3. The method according to claim 1, characterized in that, The step of matching the target rule corresponding to the target fact from the rule base based on the current target facts and the information of the current flight phase includes: Based on the information of the current flight segment, obtain the target rule set corresponding to the current flight segment from the rule base; Based on the current target facts, obtain the target rules that match the target facts from the set of target rules.

4. The method according to claim 1, characterized in that, The attribute information of the target rule includes its hierarchical information, which corresponds to any one of the task flow engine, the behavior rule engine, and the physical calculation engine. The determination of the decision result includes: When the hierarchical information of the target rule corresponds to the task flow engine, a strategic decision is determined, wherein when the strategic decision indicates that the task needs to be adjusted, the strategic decision is used as a task adjustment request. When the hierarchical information of the target rule corresponds to the physical computing engine, a physical decision is determined and the physical decision is used as a control command. When the hierarchical information of the target rule corresponds to the behavior rule engine, a tactical decision is determined.

5. The method according to claim 4, characterized in that, The method further includes: Based on the decision result corresponding to any target rule, a fact object is generated and updated as a current target fact. If a new target rule corresponding to the current target fact is found in the rule base, the original target rule is used as the first rule and the new target rule is used as the second rule. After executing the first rule to determine the corresponding decision result, the second rule is then executed to determine the corresponding decision result, and the step of generating a fact object based on the decision result corresponding to any target rule is returned, so as to form a rule cascade.

6. The method according to claim 5, characterized in that, The attribute information of the target rule also includes influence level information, which corresponds to any one or more engines among the task flow engine, the behavior rule engine, and the physical calculation engine. The hierarchical information of the second rule is matched with any engine corresponding to the influence hierarchical information of the first rule to form a cross-level rule cascade.

7. The method according to claim 1, characterized in that, When the number of matched target rules is greater than 1, the method further includes: The execution order of each target rule is determined according to the scheduling strategy, and a rule decision sequence is determined so that the target rules are executed in the order of the rule decision sequence. The scheduling strategy includes a priority ranking strategy and a rule conflict resolution strategy; The priority ranking strategy is used to determine the execution order of each target rule according to the order of priority, wherein the priority is adjusted based on the decision effect of the corresponding target rule, so as to increase the priority of target rules with positive effects or decrease the priority of target rules with negative effects. The rule conflict resolution strategy is used to determine the target rule to be retained among multiple conflicting target rules based on the rule hierarchy weight and the information of the current flight segment.

8. The method according to claim 1, characterized in that, The system also includes a spatial grid computing engine, which is integrated into the behavior rule engine as a built-in component, so that the grid code output by the spatial grid computing engine is used as the native condition parameter of the rule conditions of the behavior rule engine. The determination of the decision result includes: When the target rule includes an aggregation function, structured aggregation data adapted to the aggregation function is obtained from the grid data of the current spatial grid, so as to determine the decision result based on the structured aggregation data. The structured aggregation data is obtained by the behavior rule engine through sliding updates of the time window after each simulation step. When the target rule includes spatial constraints, the spatial constraint determination of the current spatial grid is determined based on the spatial constraint determination of the parent grid to which the current spatial grid belongs, and the decision result is determined based on the spatial constraint determination.

9. A rule-based application 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, and the device is applied to the behavior rule engine; The device includes: The rule matching unit is used to, in response to the update of the target facts during the low-altitude flight simulation of at least one simulated entity, match the target rules corresponding to the target facts in the rule base according to the current target facts and the information of the current flight phase. The target facts include any one or more corresponding fact objects from the following: mission instructions, physical state data of each simulated entity, and current simulation scene data. A rule decision unit is used to determine a decision result based on the current target facts and the target rules, the decision result including a task adjustment request and / or control instructions; The result transmission unit is configured to, when the decision result includes the task adjustment request, send the task adjustment request to the task flow engine so that the task flow engine determines another task instruction based on the task adjustment request and triggers the update of the target fact; and when the decision result includes the control instruction, send the control instruction to the physical calculation engine so that the physical calculation engine determines new physical state data for each of the simulation entities based on the control instruction and triggers the update of the target fact.

10. 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-8.

11. 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-8.

Images