Test strategy execution method and related devices

Abstract

The application discloses a test strategy execution method and related equipment, and relates to the technical field of equipment testing. The method comprises the following steps: obtaining test strategy content arranged through a visual canvas, and generating a rule file according to the test strategy content; issuing the rule file to an execution side, so that the rule file is dynamically loaded in a strategy engine on the execution side; performing matching operation on real-time collected test parameters and trigger conditions in the rule file through a rule engine and an expression engine in the strategy engine, to determine whether the test parameters meet the trigger conditions of a target strategy; when it is determined that the target strategy is triggered, arbitrating and disposing the target strategy based on a preset strategy level, to generate disposal prompt information; and generating disposal result records based on disposal confirmation instructions fed back to the disposal prompt information. The application realizes dynamic configuration, real-time execution, level arbitration and whole-process recording of test strategies, and improves the flexibility, real-time performance and reliability of test strategy execution.

Description

Technical Field

[0001] This application relates to the field of equipment testing technology, and more specifically, to a test strategy execution method and related equipment. Background Technology

[0002] With the continuous improvement of the digitalization and intelligence level of aero-engine testing, the types and number of monitoring parameters involved in the testing process are constantly increasing. Configuring corresponding testing strategies for different testing conditions and realizing real-time monitoring and fault handling has become an important technical means to ensure testing safety and improve testing efficiency. Analyzing and judging the real-time collected testing parameters through testing strategies, and triggering corresponding handling measures in a timely manner when parameters are abnormal, can not only improve the automation level of the testing process but also reduce the burden of manual monitoring, thereby improving the safety and reliability of the testing process. Therefore, the research and application of testing strategy execution technology is of great significance.

[0003] In related technologies, test strategies are typically implemented using fixed program logic or static configuration files. The strategy content is highly coupled with the execution program, meaning that adjustments to the test strategy often require modification of the execution program or redeployment of the execution environment, resulting in poor strategy update flexibility. Furthermore, existing strategy configuration methods largely lack a structured organizational form oriented towards test operations, making it difficult to uniformly describe test parameter triggering conditions, execution actions, and fault handling processes. This hinders the maintenance, reuse, and rapid configuration of test strategies. In addition, during test execution, real-time parameter determination usually relies on a single rule matching method, which can easily lead to insufficient efficiency and accuracy for triggering conditions containing complex logical expressions. When multiple test strategies simultaneously meet their triggering conditions, existing technologies typically lack an effective strategy priority arbitration mechanism, easily leading to conflicts between multiple handling strategies and affecting the orderly execution of the test handling process. In other words, related technologies suffer from poor test strategy configuration flexibility, low real-time triggering efficiency, and a high risk of conflict between multiple strategy handling methods. Summary of the Invention

[0004] In the summary section of this application, the relevant technical solutions are described in general terms, and a series of simplified concepts are introduced. These concepts will be further elaborated in the detailed embodiments section. This summary section should not be construed as limiting the key or essential technical features of the claimed solutions, nor is it intended to limit the scope of protection of the claimed solutions.

[0005] The test strategy execution method and related equipment provided in this application can decouple test strategy configuration and execution through structured configuration, dynamic loading, real-time triggering, hierarchical arbitration and disposal records. This improves the real-time performance, flexibility and reliability of strategy execution, and enhances the orderly handling, management efficiency and full traceability of the test process.

[0006] In a first aspect, this application provides a method for executing an experimental strategy, comprising: acquiring experimental strategy content arranged through a visual canvas, and generating a rule file based on the experimental strategy content, wherein the experimental strategy content includes basic events, result events, and troubleshooting plans; the basic events are used to define triggering conditions for abnormal experimental parameters; the result events are used to define action information to be executed when the triggering conditions are met; and the troubleshooting plans are used to define fault handling guidance information corresponding to the triggering conditions; the rule file is distributed to the execution side so that the rule file is dynamically loaded into the strategy engine on the execution side; the rule engine and expression engine in the strategy engine are used to perform matching operations on the real-time collected experimental parameters and the triggering conditions in the rule file to determine whether the experimental parameters meet the triggering conditions of the target strategy, wherein the rule engine is used to interpret and execute the rule file and drive the rule matching process, and the expression engine is used to evaluate the triggering condition expressions in the rule file; when it is determined that the target strategy is triggered, the target strategy is arbitrated based on a preset strategy level to generate handling prompt information; and a handling result record is generated based on the handling confirmation instruction fed back to the handling prompt information.

[0007] In some implementations, obtaining the experimental strategy content arranged through a visual canvas includes: in response to an arrangement operation on the visual canvas, obtaining a first element set, a second element set, and a third element set, wherein the first element set includes a first triggering condition expression representing the basic event, the second element set includes action instruction information representing the result event, and the third element set includes a main table for troubleshooting and a sub-item for troubleshooting representing the troubleshooting scheme; obtaining the association relationship established between the first element set, the second element set, and the third element set through canvas connections to obtain the experimental strategy content.

[0008] In some implementations, the step of sending the rule file to the execution side includes: obtaining a publishing instruction for the rule file and switching the status of the rule file from editing to published; in response to a revision instruction for the published rule file, generating a new version of the rule file based on the original rule file; or, in response to a version rollback instruction, determining a target historical version from the historical version record to republish the target historical version as the currently effective version; and sending the rule file to the execution side when the rule file is in the published state.

[0009] In some implementations, the step of sending the rule file to the execution side so that the rule file is dynamically loaded into the strategy engine on the execution side includes: obtaining test configuration information corresponding to the rule file, wherein the test configuration information includes an aircraft model identifier, a test task identifier, and an engine identifier; sending the rule file to the strategy loading interface on the execution side based on the test configuration information; and loading the rule file into the running strategy engine through the strategy loading interface in a data injection manner to update the rule file without stopping the system.

[0010] In some implementations, the step of matching real-time collected experimental parameters with trigger conditions in the rule file using the rule engine and expression engine in the strategy engine to determine whether the experimental parameters meet the trigger conditions of the target strategy includes: converting the real-time collected experimental parameters into fact data objects and inputting the fact data objects into the rule engine; the rule engine determining the current trigger conditions to be matched in the rule file during the interpretation and execution of the rule file; if the current trigger conditions to be matched contain a preset expression, the rule engine calling the expression engine and controlling the expression engine to evaluate the preset expression to obtain a calculation result; and the rule engine determining the matching status of the current trigger conditions to be matched based on the calculation result and the fact data object to determine whether the target strategy is triggered.

[0011] In some implementations, the arbitration of the target policy based on a preset policy level to generate a handling prompt message includes: obtaining a first policy level of the triggered target policy and obtaining a second policy level of at least one policy currently in the handling execution state, wherein the policy in the handling state is a policy that has been triggered, has generated a handling prompt, and has not yet received a handling confirmation instruction; if the first policy level is higher than the second policy level, a first overriding instruction is generated, and the handling type of the target policy is determined to be normal processing, wherein the first overriding instruction is used to cancel the current handling process of the policy in the handling state and generate an overriding handling record, the overriding handling record including a high-level policy identifier and an overriding handling type identifier; and generating the handling prompt message according to the troubleshooting plan and handling button configuration information corresponding to the target policy.

[0012] In some implementations, generating a handling result record based on the handling confirmation instruction based on the handling prompt information includes: obtaining feedback operation data for the handling prompt information, wherein the feedback operation data includes the identifier of the triggered handling button; generating the handling confirmation instruction based on the feedback operation data; obtaining the handling time, handling type identifier, and response rule identifier of this handling based on the handling confirmation instruction; and performing structured encapsulation of the handling time, handling type identifier, handling button identifier, and response rule identifier to generate the handling result record.

[0013] In some embodiments, the experimental strategy execution method further includes: acquiring multiple disposal result records generated within a preset historical time period; extracting strategy trigger frequency information, disposal response duration information, and disposal type distribution information from the multiple disposal result records; determining high-frequency triggering strategies and low-frequency triggering strategies based on the strategy trigger frequency information; determining the average disposal response duration corresponding to each strategy based on the disposal response duration information; and generating strategy optimization suggestion information based on the high-frequency triggering strategy, the low-frequency triggering strategy, and the average disposal response duration, wherein the strategy optimization suggestion information is used to prompt the triggering judgment conditions or preset strategy level for adjusting the strategy.

[0014] Secondly, this application also provides a test strategy execution device, comprising: a rule acquisition unit, configured to acquire test strategy content arranged through a visual canvas, and generate a rule file based on the test strategy content, wherein the test strategy content includes basic events, result events, and troubleshooting plans; the basic events are used to define triggering conditions for test parameter anomalies; the result events are used to define action information to be executed when the triggering conditions are met; and the troubleshooting plans are used to define fault handling guidance information corresponding to the triggering conditions; a rule loading unit, configured to distribute the rule file to the execution side so that the rule file is dynamically loaded into the strategy engine of the execution side; and a triggering... The system includes a fault unit, which uses the rule engine and expression engine in the strategy engine to perform matching calculations on the real-time collected test parameters and the trigger conditions in the rule file to determine whether the test parameters meet the trigger conditions of the target strategy. The rule engine interprets and executes the rule file and drives the rule matching process, while the expression engine evaluates the trigger condition expressions in the rule file. A handling prompt unit is used to arbitrate the target strategy based on a preset strategy level when it is determined that the target strategy has been triggered, thereby generating handling prompt information. A result generation unit is used to generate a handling result record based on the handling confirmation instruction received in response to the handling prompt information.

[0015] Thirdly, this application also provides an electronic device, including: a memory and a processor, wherein the processor is configured to implement the steps of the test strategy execution method described in the first aspect when executing a computer program stored in the memory.

[0016] Fourthly, this application also provides a computer-readable storage medium storing computer-executable instructions or a computer program, wherein when the computer-executable instructions or the computer program are executed by a processor, the steps of the test strategy execution method described in the first aspect are implemented.

[0017] Fifthly, this application also provides a computer program product, including a computer program or computer executable instructions, wherein when the computer program or computer executable instructions are executed by a processor, the steps of the test strategy execution method provided in the embodiments of this application are implemented.

[0018] In summary, this application uses a visual canvas to structure and organize the experimental strategy content, converting the experimental strategy content, including basic events, result events, and troubleshooting solutions, into rule files, which are then dynamically loaded onto the execution side. Since the experimental strategy is managed independently of the execution program in the form of rule files, it achieves decoupling of strategy configuration and execution logic. Strategy updates can be completed without modifying the execution-side program, improving the configuration flexibility and deployment efficiency of the experimental strategy, while also facilitating unified management and rapid application of the experimental strategy. During execution, the rule engine interprets and executes the rule files, and the expression engine evaluates the trigger condition expressions to jointly complete the matching and determination of real-time experimental parameters and rule conditions. The rule engine is responsible for the rule matching process, while the expression engine is responsible for calculating complex condition expressions. Their collaboration achieves a division of labor between rule parsing and expression calculation, thereby improving the efficiency of the experimental strategy. The real-time performance and accuracy of parameter triggering judgment make the strategy triggering process more efficient and reliable. After determining that the target strategy has been triggered, the target strategy is arbitrated based on the preset strategy level, and corresponding handling prompts are generated. Due to the introduction of the strategy level mechanism, when multiple strategies have triggering relationships, they can be uniformly arbitrated according to the strategy level, which can avoid handling conflicts between different strategies and allow high-priority strategies to participate in the handling decision first, thereby improving the orderliness and rationality of strategy execution during the experiment. After generating the handling prompts, the handling result record is generated based on the handling confirmation instructions fed back by the operator, so that the strategy triggering, handling confirmation and handling result form a complete recording process. By recording the handling results, not only can the strategy execution and handling situation during the experiment be preserved, but also a basis can be provided for subsequent experimental process query, analysis and traceability, thereby improving the manageability and traceability of the experimental strategy execution process. In summary, the test strategy execution method provided in this application, through structured configuration, dynamic loading, real-time triggering, hierarchical arbitration, and handling records of test strategies, can decouple test strategy configuration and execution, improve the real-time performance, flexibility, and reliability of strategy execution, and enhance the orderly handling, management efficiency, and full-process traceability of the test process. Attached Figure Description

[0019] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating a method for executing an experimental strategy, as provided in an embodiment of this application; Figure 2A schematic diagram of the composition structure of an experimental strategy execution device provided in this application embodiment; Figure 3 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] The terms used in the specification, claims, and drawings of this application, such as "first," "second," "third," "fourth," etc. (if any), are used to distinguish similar objects and not to describe a specific order or sequence. Therefore, it is to be understood that these terms can be used interchangeably where appropriate, allowing the described embodiments to be used in different orders, unless specifically required by the illustrations or description. Furthermore, the terms "is" and "has," and any variations thereof, are intended to cover, non-exclusively, all possible constituent elements. For example, a process, method, system, product, or apparatus comprising several steps or units is not necessarily limited to the steps or units explicitly listed, but may also include other steps or units not explicitly listed, or steps or units inherent to the process, method, product, or apparatus.

[0021] In this application, a "module" or "unit" refers to a computer program or part of a computer program that has a specific function and works in conjunction with other related parts to achieve a predetermined goal. These modules or units can be implemented by software, hardware (e.g., processing circuitry or memory), or a combination of both. One or more processors or memories can implement one or more modules or units. Furthermore, each module or unit can also be part of a larger module or unit.

[0022] The technical solutions of this application will be described in detail below with reference to the accompanying drawings of the embodiments. It should be noted that the described embodiments are only a part of this application, and not all embodiments. In the following description, the "some embodiments" mentioned are only a subset of all possible embodiments, which may be the same or different subsets, and different embodiments can be combined with each other without conflict.

[0023] Figure 1 This is a schematic flowchart illustrating a method for executing an experimental strategy according to an embodiment of this application. For example, see [link to example]. Figure 1 The experimental strategy execution method provided in this application embodiment may include the following steps 101 to 105: Step 101: Obtain the experimental strategy content arranged through the visual canvas, and generate a rule file based on the experimental strategy content.

[0024] The test strategy can include basic events, result events, and troubleshooting plans. Basic events are used to define the triggering conditions for abnormal test parameters. Result events are used to define the action information to be executed when the triggering conditions are met. Troubleshooting plans are used to define the fault handling guidance information corresponding to the triggering conditions.

[0025] In some examples, the visualization canvas is a graphical visual editing platform integrated into the test strategy configuration subsystem. It provides a dedicated visual interactive interface for the structured arrangement of test strategies, supporting no-code editing operations such as component drag-and-drop, logic connection, parameter configuration, and free element layout. This is completely different from the text editing, code writing, and fixed table configuration modes in the traditional equipment testing field. It is the carrier for realizing the visualization, structure, and flexible configuration of test strategies, and can fully adapt to the strategy editing needs of various test scenarios such as aero-engine whole-machine test, component performance test, and equipment durability test. For example, in the aero-engine steady-state test operation scenario, after the test engineer logs into the test strategy digital configuration platform, the system immediately loads a blank visualization canvas interface. The interface has three types of standardized draggable functional components: basic events, result events, and troubleshooting solutions. It is also equipped with auxiliary functions such as parameter configuration pop-ups, conditional expression editing windows, and strategy logic previews. Engineers can freely adjust the component layout and build business logic connections between components through connection operations to complete the visual arrangement of test strategies.

[0026] The test strategy content is a complete set of closed-loop handling logic preset for various abnormal test parameter conditions and equipment failure scenarios, covering the entire process of equipment testing. It is the business data that supports subsequent rule file generation, test parameter matching, and abnormal condition handling. The test strategy content is composed of three independent structured elements: basic events, result events, and troubleshooting solutions. It can fully cover all dimensions of business information, including test parameter abnormality judgment conditions, equipment actions after abnormality triggering, and manual fault handling guidance, providing complete logical support for the automated execution of test strategies. For example, in the low-speed warm-up test condition of aero-engines, the corresponding test strategy content is the complete closed-loop handling logic for engine temperature abnormality faults. This content fully includes the parameter judgment conditions for engine operating temperature exceeding the limit, the automatic adjustment actions of the test equipment after the temperature exceeds the limit, and the standardized troubleshooting process and handling suggestions for temperature abnormality faults. The three core elements are connected through visual logic to form an independent test strategy adapted to the specific low-speed warm-up condition, which can accurately match the abnormal handling needs of this test scenario.

[0027] Basic events are the core triggering elements that constitute the test strategy. As the triggering source of the entire test strategy, their core function is to accurately define the normal operating thresholds, over-limit judgment ranges, and multi-parameter linkage judgment logic of various equipment test parameters through standardized conditional expressions. This provides accurate and quantifiable data basis for the triggering judgment of the test strategy and is the foundation for realizing the automatic identification of test parameter anomalies. For example, during the implementation of high-temperature test conditions for aero-engines, engineers can customize the corresponding basic events, select the engine turbine back temperature as the core monitoring parameter, and set the judgment logic to real-time monitoring temperature values ​​greater than 950 degrees Celsius. Based on this judgment logic, a unique conditional expression is generated, and this basic event is the sole triggering judgment basis for the engine high-temperature anomaly test strategy.

[0028] Result events are the execution elements in the test strategy that carry over the judgment results of basic events. They are specifically used to define the standardized response actions that the test system and test equipment need to perform after the basic event triggering conditions are met. They are the instruction carriers for realizing automated intervention and unmanned handling of abnormal operating conditions of equipment testing, and directly determine the equipment's operating status and adjustment logic after an anomaly is triggered. For example, for the basic event of engine turbine overheating, engineers match and configure a dedicated result event. The execution actions defined by this result event are to slightly reduce the fuel supply flow, continuously lock and monitor engine temperature parameters, and mark the current test condition as an abnormal state. When the basic event determines that the temperature parameter exceeds the limit and the triggering conditions are met, the system can automatically call this result event to drive the test equipment to perform the corresponding adjustment and control actions.

[0029] Troubleshooting plans are standardized manual handling guidance elements in the test strategy that accompany abnormal parameter faults. They are used to accurately define the fault verification items, standardized troubleshooting procedures, compliant handling suggestions, and fault clearing and reset standards for corresponding abnormal operating conditions. This element mainly provides standardized and procedural fault handling guidance for on-site operators after abnormal test parameters are triggered, while supporting the system to complete the structured recording and traceability of the handling process. For example, for the turbine after-temperature overheating fault condition of an aero-engine, engineers configure a dedicated troubleshooting plan. The main fault clearing table of this plan is uniformly marked as engine high temperature over-limit fault. The troubleshooting sub-items include standardized troubleshooting steps such as fuel supply pipeline unobstructedness check, temperature sensor accuracy verification, and intake air flow parameter verification, while also providing corresponding fault handling optimization suggestions and fault reset verification standards, providing clear guidance for on-site manual troubleshooting.

[0030] The rule file is a standardized executable file automatically compiled and generated by the configuration-side system, which can be parsed, recognized, loaded, and run by the execution-side strategy engine. The rule file can be a domain rule language file. Domain rule language (DRL) is a dedicated standardized language for defining business rules. Its core function is to convert the graphical and structured test strategy business logic in the visualization canvas into standardized code logic that can be recognized, calculated, and driven by the execution-side equipment, so as to achieve seamless connection between the configuration-side visualization strategy and the execution-side automated processing. For example, after the test engineer completes the canvas arrangement and logic verification of the engine warm-up over-temperature fault strategy, the system automatically compiles and generates a standardized rule file with the suffix DRL. This file internally stores core data such as the engine temperature over-limit judgment expression, the equipment adjustment instructions after the temperature exceeds the limit, the over-temperature fault-specific troubleshooting list, and the handling standards. The file format is fully compatible with the parsing and running specifications of the execution-side strategy engine and can be directly sent to the execution side for loading and calling.

[0031] For example, before the formal test of an aero-engine under rated operating conditions, the test engineer logs into the equipment test digital management platform and enters the dedicated strategy configuration subsystem. The system automatically completes the background initialization calculations and renders a blank visual canvas editing interface, providing a standardized editing medium for test strategy arrangement. The engineer, combining the formal test procedures, equipment parameter standards, and fault handling specifications for this engine rated operating condition test, sequentially completes the drag-and-drop configuration of three types of core strategy elements in the visual canvas. First, the engineer drags and drops the basic event component to configure trigger conditions, selecting two core monitoring parameters: engine turbine inlet temperature and fuel supply pressure. Combining the rated test condition standards, the engineer edits a composite trigger condition expression, explicitly setting that when the real-time turbine inlet operating temperature exceeds 1000 degrees Celsius and the fuel supply pressure is below the standard threshold of 0.2 MPa, the test parameters are considered abnormal, thus completing the logical definition of the strategy trigger source. Subsequently, the drag-and-drop result event component matches the corresponding execution actions for abnormal operating conditions. For high-temperature and low-pressure linkage anomaly scenarios, automated equipment handling logic is configured, specifically including automatically reducing fuel supply opening, real-time locking of the current test operating condition, and pausing the progressive adjustment process of test parameters to ensure controllable equipment operation under abnormal conditions. Next, the drag-and-drop troubleshooting solution component builds a manual handling system. It retrieves the system's built-in standardized troubleshooting template for engine high-temperature and low-pressure linkage faults, and, combined with the specific technical parameters of this test model, supplements and optimizes the verification details of troubleshooting sub-items, clarifies fault clearing standards and compliance handling suggestions, and forms a complete fault handling guide adapted to this test task. After completing the parameter configuration and content editing of all core elements, engineers use the connection function of the visual canvas to establish one-to-one logical relationships between basic events and result events, and between basic events and troubleshooting solutions. This allows the parameter anomaly judgment conditions, automatic equipment execution actions, and manual fault handling guidelines to form a complete closed-loop logic, thereby generating complete and structured test strategy content specific to this test. After the strategy orchestration is completed, the system automatically starts the built-in compliance verification program to comprehensively verify the syntax of the conditional expressions within the canvas, the logical relationships between each element, and the rationality of the experimental parameter thresholds. After verifying that there are no logical errors and the parameters are compliant, the rule file generation module immediately reads all the structured strategy data within the canvas and strictly follows the domain rule language standardization compilation specifications to convert the graphical and visual strategy logic into a standardized DRL rule file that can be recognized, loaded, and computed by the device. The file completely retains all the core information of the parameter anomaly judgment rules, automatic device handling actions, and manual troubleshooting instructions for this test strategy, successfully completing the entire implementation process of this step and providing standardized and implementable rule data support for subsequent rule file loading, real-time parameter matching, and anomaly strategy triggering and handling work on the execution side.

[0032] By implementing step 101, the experimental strategy content arranged by the visualization canvas is obtained, and the experimental strategy content, which includes basic events, result events, and troubleshooting solutions, is converted into a rule file. This allows the experimental strategy to be organized and described in a structured manner, enabling the separation of experimental strategy configuration and execution logic. At the same time, since basic events, result events, and troubleshooting solutions correspond to trigger judgment, action execution, and fault handling guidance, respectively, the configurability, maintainability, and reusability of the experimental strategy can be improved, and a unified rule description basis can be provided for subsequent strategy execution.

[0033] Step 102: Distribute the rule file to the execution side so that the rule file can be dynamically loaded in the strategy engine on the execution side.

[0034] In some examples, the execution side is a real-time running server deployed on the control network of the aero-engine test site. It is independent of the configuration side, which is responsible for strategy editing and configuration release, but they are interconnected. It is the operating platform responsible for collecting test parameters, calculating rules, triggering strategies, and executing on-site actions. The execution side directly connects to the test equipment data acquisition link and the on-site monitoring terminal, and has the characteristics of high real-time performance and high stability. It receives the rule files issued by the configuration side throughout the process and continuously carries out test condition monitoring and strategy processing. It is the hardware and software integrated environment for the implementation of test strategies. For example, at the aero-engine test site, the control server deployed in the on-site control LAN is the execution side operating platform. This server independently runs the test execution subsystem, continuously receives various test parameters collected by the front-end sensors, and is ready to receive the rule files issued by the configuration side, supporting the loading and execution of strategy rules throughout the test process.

[0035] The strategy engine is a service program embedded within the execution subsystem on the execution side. It is a dedicated runtime component for loading, parsing, and running domain rule language rule files. The strategy engine provides an independent runtime container for the execution of test strategies. It can independently complete rule file reception, dynamic injection, rule caching, and runtime scheduling. It can stably support uninterrupted rule matching calculations under test conditions and is the core computing power carrier for realizing the automated and real-time execution of test strategies. For example, when aero-engines conduct long-term steady-state test tests, the strategy engine service runs resident in the background on the execution side. This engine continuously listens for instructions issued by the configuration side and can receive new domain rule language rule files at any time. After completing online dynamic loading, it continuously relies on the loaded strategy rules to perform cyclic matching calculations on real-time parameters such as test temperature, pressure, and speed.

[0036] The configuration side can push verified and published compliant domain rule language rule files to the execution side of the test site through a dedicated data transmission link. After receiving the files, the execution side uses the strategy engine to complete the rule update and deployment through online data injection. This process is different from the traditional deployment mode of updating after system shutdown and restarting. It can complete the replacement and activation of old and new test strategies while the test system is running continuously and the test tasks are advancing uninterrupted, realizing the seamless iterative update of test strategies.

[0037] For example, before the formal commencement of an aero-engine test or during the iterative adjustment of test conditions, the configuration-side strategy subsystem has completed the visual orchestration, logical verification, and generation of domain rule language rule files for the test strategy. The corresponding rule files have been published and are ready for deployment. The configuration-side distribution module automatically captures the complete data of the rule file to be deployed, and simultaneously associates and binds it with complete test configuration information specific to this test, such as the aircraft type identifier, test task number, engine number, and execution-side service port address, forming a standardized strategy data packet with an identity identifier. Subsequently, the configuration side distributes the encapsulated strategy data packet to the execution side at the test site via the platform's dedicated intranet transmission link, employing encrypted transmission and integrity verification mechanisms throughout to prevent rule file data loss and tampering. The execution-side execution subsystem continuously maintains a data monitoring service in the background, capturing the strategy data packet distributed by the configuration side in real time and performing data verification. After successful verification, it extracts the complete internal domain rule language rule file. Meanwhile, the strategy engine running continuously in the background on the execution side remains operational without interrupting current parameter monitoring and rule calculation tasks. The system imports the new rule files into the strategy engine's runtime container via a dedicated dynamic loading interface, injecting data online to complete the cache registration and deployment of the new strategy rules. This dynamic loading process was completed without any downtime, system restarts, or interruptions to experimental tasks. The new experimental strategy rules immediately replace the old rules for the existing matching conditions and are formally incorporated into the real-time matching and calculation system for subsequent experimental parameters, successfully completing the entire execution process of this step. This provides the latest and most accurate rule basis for subsequent dual-engine collaborative parameter matching and strategy triggering.

[0038] By implementing step 102, the rule file is distributed to the execution side and dynamically loaded in the execution side policy engine. This allows the test policy to be deployed independently to the execution environment in the form of a rule file without modifying or redeploying the execution program. This improves the flexibility and efficiency of test policy updates, shortens the effective time after policy adjustment, and enhances the online adaptability of the test policy.

[0039] Step 103: The real-time collected test parameters are matched with the triggering conditions in the rule file using the rule engine and expression engine in the strategy engine to determine whether the test parameters meet the triggering conditions of the target strategy.

[0040] The rule engine is used to interpret and execute the rule file and drive the rule matching process, while the expression engine is used to evaluate the trigger condition expressions in the rule file.

[0041] In some examples, the rule engine is a logic scheduling component deployed within the execution-side strategy engine. Its full name is Drools Rule Engine (DRE). It is primarily responsible for fully interpreting and parsing rule files written in the domain rule language, and for uniformly coordinating the execution sequence, matching logic, and process jumps of the entire test strategy. It serves as the central scheduling carrier for the entire strategy matching process. The rule engine can fully identify the basic event judgment logic, strategy relationships, and execution constraints defined in the rule files, continuously driving the overall rule matching process in a loop, and coordinating and managing all parameter comparisons and condition judgment processes. For example, during the steady-state test of an aero-engine, the rule engine continuously reads the loaded domain rule language rule files, parses the complete strategy logic corresponding to temperature anomalies, pressure anomalies, and speed anomalies contained in the files, uniformly schedules the matching sequence of each strategy, and continuously drives the cyclic matching and judgment of all-dimensional test parameters, ensuring the orderly parallel detection of multiple strategies.

[0042] The expression engine, officially named Aviator Expression Engine (AEE), is a dedicated numerical computation component embedded within the strategy engine. It is specifically designed to handle and accurately evaluate various custom trigger condition expressions within rule files. Addressing complex mathematical logic in experimental scenarios, such as multi-parameter linkage, threshold comparison, formula calculation, and interval determination, the expression engine can independently perform high-precision calculations, providing accurate numerical results to support the rule engine's condition determinations and overcoming the limitations of a purely logic-based engine in handling complex formula calculations. For example, during variable-condition testing of an aero-engine, the strategy trigger conditions may include a composite calculation formula involving temperature change rate and pressure difference. The rule engine calls the expression engine to evaluate this composite formula in real time, accurately calculating the parameter changes under the current operating condition and providing a quantitative basis for parameter exceedance determination.

[0043] The real-time acquired test parameters are various operating condition data of the aero-engine and test bench continuously collected by the test site data acquisition link according to a fixed acquisition cycle. They are the original factual data source for strategy matching calculations. These parameters cover all core monitoring dimensions of engine testing, including various physical quantities such as temperature, pressure, speed, flow rate, vibration, and fuel parameters, and can truly and in real time reflect the current test operation status of the equipment. For example, under the aero-engine acceleration test condition, the data acquisition system continuously collects four core test parameters in real time: turbine after-run temperature, engine speed, total intake pressure, and fuel flow rate. The data is updated every 10 milliseconds and continuously pushes standardized real-time parameter data to the strategy engine for subsequent strategy condition matching calculations.

[0044] The trigger conditions in the rule file are standardized judgment criteria pre-embedded within the domain rule language rule file. They are generated by test engineers based on basic events during the visualization canvas stage and exist in the form of various expressions, logical formulas, and threshold ranges. The trigger conditions correspond to the judgment criteria for various abnormal test conditions, used to define the numerical boundaries between normal and abnormal test conditions, and are the judgment criteria for determining whether the target strategy is triggered. For example, for the engine over-temperature anomaly strategy, the trigger condition pre-embedded in the rule file is a judgment expression for the real-time temperature after the engine turbine being greater than 950 degrees Celsius. This condition serves as a fixed judgment criterion and is continuously used to compare the real-time collected temperature parameters to determine whether an over-temperature anomaly has occurred in the current operating condition.

[0045] Matching operations are a real-time operating condition determination process jointly completed by the rule engine and the expression engine. It refers to the overall calculation process of comparing, evaluating, and verifying the dynamic test parameter data collected in real time with the static trigger conditions fixed in the rule file. Matching operations combine logical judgment and mathematical calculation, and finally output the judgment result of whether the condition is met or not, realizing the quantitative transformation from raw parameters to abnormal operating condition judgment. For example, after the strategy engine obtains the engine speed and vibration parameters collected in real time, it calls the expression engine to calculate the composite condition formula of speed fluctuation linkage vibration threshold, compares the calculation result with the rule preset threshold, completes the matching operation of this operating condition, and finally determines whether the current parameter meets the trigger condition of the speed fluctuation abnormal strategy.

[0046] For example, once the rule file is successfully loaded dynamically and officially takes effect in the execution-side policy engine, the experiment enters the real-time monitoring and policy judgment operation phase. The data acquisition equipment at the test site continuously collects all-dimensional operating parameters during the aero-engine test, such as turbine temperature, fuel pressure, engine speed, and intake flow, according to a preset acquisition cycle. After data preprocessing and format standardization, these parameters are uniformly encapsulated into structured fact data objects and continuously pushed to the execution-side rule engine. As the scheduling core of the overall process, the rule engine continuously reads the loaded domain rule language rule file, parsing line by line the trigger conditions, logical structures, and judgment rules corresponding to each target policy stored within the file, thus driving the overall rule matching process to run continuously. During the matching operation, the rule engine recognizes that some trigger conditions contain custom composite formulas and logical operation expressions. It then actively calls the coupled and integrated expression engine, inputting real-time parameter data into the corresponding expression formula. The expression engine independently performs high-precision mathematical operations and logical evaluation, outputting standardized calculation results and sending them back to the rule engine. After receiving the calculation results returned by the expression engine, the rule engine combines real-time factual data objects with preset trigger condition thresholds to perform a comprehensive comparison and judgment, verifying each current real-time test parameter to ensure it fully matches all trigger conditions of the target strategy. If the current parameter does not meet the preset trigger standard, the target strategy is determined not to be triggered, and the system continues to the next round of real-time parameter collection and cyclic matching calculation; if the current parameter fully meets all the judgment requirements of the corresponding trigger condition, the current operating condition is determined to match the target abnormal operating condition, completing the identification and confirmation of the target strategy trigger conditions, and providing accurate preliminary judgment results for subsequent strategy arbitration and handling prompt generation.

[0047] By implementing step 103, the rule engine interprets and executes the rule file, and the expression engine evaluates the trigger condition expression, enabling collaborative processing of rule matching and expression calculation. The rule engine is responsible for rule parsing and matching process control, while the expression engine is responsible for calculating complex trigger conditions, allowing real-time collected experimental parameters to quickly determine trigger conditions, thereby improving the real-time performance, accuracy, and execution efficiency of experimental strategy triggering.

[0048] Step 104: When it is determined that the target policy is triggered, the target policy is arbitrated based on the preset policy level to generate a handling prompt message.

[0049] In some examples, the target strategy is a valid test strategy determined by the collaborative matching and calculation of the rule engine and expression engine, which determines that the real-time test parameters fully meet the internal triggering conditions. It is the abnormal response strategy that needs to be initiated under the current test conditions. The target strategy is a complete test strategy that is pre-structured and compiled into a rule file through a visual canvas and dynamically loaded into the strategy engine. It contains complete triggering judgment conditions, corresponding handling logic for the test conditions, and fault troubleshooting guidance. It is the basis for the execution of this abnormal handling. For example, under the medium-speed test conditions of an aero-engine, the real-time collected turbine back temperature parameters exceed the preset threshold, and at the same time, the fuel supply pressure shows a slight deviation. After matching and calculation, both the temperature over-limit test strategy and the pressure anomaly test strategy meet the triggering conditions. These two types of strategies are the target strategies corresponding to the current test conditions.

[0050] Pre-defined strategy levels are standardized grade markers pre-configured within each test strategy to distinguish the degree of danger and priority of handling abnormal faults. They serve as the basis for arbitration of concurrent handling of multiple strategies. Different abnormal test conditions correspond to different risk levels. Pre-defined strategy levels can accurately define the handling priority of various faults, ensuring that high-risk faults are handled first and routine faults are handled in an orderly manner, thus avoiding conflicts in concurrent handling of multiple strategies from a mechanism perspective. For example, based on test safety specifications, differentiated grade standards can be configured for aero-engine test strategies. Fault strategies that endanger equipment safety, such as turbine overheating and sudden speed changes, are set to high levels, while routine abnormal strategies that do not affect the overall safety of the engine, such as small pressure fluctuations and slight flow deviations, are set to low levels, forming a hierarchical pre-defined strategy level system.

[0051] Arbitration is a standardized handling process by the strategy engine for scenarios where multiple target strategies are triggered concurrently. Based on preset strategy levels, it performs priority judgment, invalid strategy blocking, and effective strategy screening. The role of arbitration is to orderly manage multiple target strategies triggered at the same time, identify high-priority effective handling strategies, block low-priority conflicting strategies, and determine the final handling logic that needs to be implemented, ensuring that the handling actions at the test site are unique, safe, and orderly. For example, during engine testing, if a high-level turbo over-temperature strategy and a low-level fuel pressure fluctuation strategy are triggered simultaneously, the system will initiate the arbitration process, automatically compare the preset levels of the two types of strategies, determine that the turbo over-temperature strategy has a higher priority, determine the over-temperature handling logic as the core handling solution, and block the simultaneous handling action of the low-level pressure fluctuation strategy.

[0052] The handling prompt information is a visualized and standardized fault handling guidance information generated by the system after completing the strategy arbitration and handling, based on the final effective target strategy. It is displayed on the test monitoring interface to provide on-site operators with intuitive and standardized fault handling basis. The handling prompt information completely corresponds to the business logic of the effective target strategy and can accurately match the current abnormal test conditions, ensuring that operators complete the fault handling operations in a standardized manner. For example, after the system arbitration determines that the turbine over-temperature strategy is the effective strategy, it automatically generates the corresponding handling prompt information. The interface displays the current fault type as engine turbine over-temperature, the corresponding test conditions, standardized troubleshooting guidance, and supporting handling operation options to guide operators to complete the standardized handling.

[0053] For example, during the real-time operation of an aero-engine test, the execution-side strategy engine, through the collaboration of the rule engine and expression engine, completes the matching calculation of real-time test parameters. When it is determined that the real-time collected test parameters meet the triggering conditions of one or more test strategies, the system marks all successfully triggered test strategies as target strategies. The system then retrieves the preset strategy levels of each target strategy, which are pre-fixed and stored in the rule file on the configuration side, and initiates an automated arbitration process to compare the levels and determine the priorities of all target strategies triggered concurrently at the same time. If only a single target strategy is triggered, it is directly determined as the final effective strategy; if multiple target strategies are triggered simultaneously, the system prioritizes them according to the preset strategy levels, determines the high-priority effective strategy, and simultaneously handles and shields low-priority conflicting strategies to avoid equipment action conflicts and operational disorder caused by the simultaneous execution of multiple strategies. After completing multi-strategy level arbitration and effective strategy screening, the system, based on the final effective target strategy, integrates the core content such as the abnormal operating condition information, standardized fault handling guidelines, and operating condition constraints corresponding to the strategy, automatically generates structured and visualized handling prompts, and pushes the handling prompts to the monitoring operation interface at the test site in real time. This clearly displays the current abnormal equipment status and the corresponding standardized handling plan, providing accurate and intuitive information support for subsequent operators to perform handling confirmation operations, thus completing the complete execution process of this step.

[0054] By implementing step 104, after determining that the target strategy has been triggered, the target strategy is arbitrated based on the preset strategy level, and corresponding handling prompt information is generated. This enables multiple strategies that are triggered at the same time to be uniformly managed and coordinated according to the preset priority, thereby avoiding handling conflicts between different strategies, ensuring that high-priority strategies are executed first, and improving the orderliness and rationality of the experimental strategy execution process.

[0055] Step 105: Based on the handling confirmation instruction fed back from the handling prompt information, generate a handling result record.

[0056] In some examples, the handling confirmation command is a valid confirmation command that the test operator sends back to the system through a dedicated interactive control on the interface after completing the on-site fault verification and standardized handling operations based on the handling prompts displayed on the monitoring interface. It is a standardized signal that the execution of this abnormal handling process is complete. This command is used to inform the system that the abnormal condition corresponding to the current target strategy has been manually intervened, the fault has been investigated, or the condition has been reset. It is a prerequisite for triggering the generation of subsequent result records. For example, during the test of an aero-engine, the system pops up a handling prompt message corresponding to the temperature over-limit anomaly. After the operator completes the parameter verification, equipment condition adjustment, and fault reset operations according to the troubleshooting guide displayed on the interface, he clicks the corresponding confirmation operation control on the monitoring interface. The system immediately generates the corresponding handling confirmation command, marking that the handling process for this over-temperature anomaly has been manually completed.

[0057] The handling result record is a structured and standardized data archive generated by the system based on the handling confirmation instruction. It completely retains the core information of a single test strategy from triggering, arbitration, prompting to manual handling confirmation. This record is used to solidify key business data such as the occurrence time of abnormal test conditions, handling execution time, corresponding strategy information, and handling execution method. It can support subsequent test review, fault tracing, strategy iteration and optimization, and test task archiving. For example, after the handling of abnormal engine pressure fluctuation is completed and a confirmation instruction is fed back, the system automatically integrates all core data such as the trigger time of this abnormality, the corresponding target strategy identifier, the handling operation type, and the manual confirmation time, generates an independent handling result record, and archives it to the corresponding test task ledger, realizing the complete retention of the abnormal handling behavior of this test.

[0058] For example, during the test operation of various operating conditions of an aero-engine, after the execution-side system completes the arbitration of the target strategy level and generates the corresponding handling prompt information, it persistently displays the handling prompt information on the test site monitoring terminal interface and enters the handling pending confirmation state. Test operators view the abnormal operating condition information and standardized troubleshooting and handling guidelines pushed by the interface in real time, and conduct on-site verification and fault handling operations in combination with the current operating status of the test equipment. They strictly follow the troubleshooting plan corresponding to the strategy to complete the corresponding handling actions such as fault investigation, parameter adjustment, operating condition reset or fault shutdown. After the operator confirms that the abnormal operating condition on site has been eliminated, the equipment has returned to normal operation, or the established fault handling procedure has been completed, the operator submits a confirmation operation through the pre-set handling interaction module of the monitoring interface. The front-end monitoring system captures this human-machine interaction behavior and generates a valid handling confirmation command, which is synchronously transmitted back to the execution-side back-end system. After receiving the handling confirmation instruction, the backend system automatically retrieves all the data from the entire process of this strategy trigger, including the strategy trigger time, real-time test parameters, strategy level information, arbitration results, handling prompts, and manual interaction data. It then organizes and encapsulates the data according to the system's preset standardized data structure, automatically generates a complete handling result record, and archives it both locally and in the cloud. It also links and binds the current test task information, completing the closed-loop record of the entire process of a single test strategy trigger and handling. This provides complete and effective data support for subsequent test data traceability, operational review, and strategy optimization.

[0059] By implementing step 105, a disposal result record is generated based on the disposal confirmation instruction fed back by the disposal prompt information, so that the strategy triggering, disposal confirmation and disposal result form a complete closed loop record. This not only completely preserves the strategy execution and disposal situation in the test process, but also provides data support for subsequent test process query, fault analysis and historical traceability, thereby improving the manageability and traceability of the test strategy execution process.

[0060] In summary, this embodiment uses a visual canvas to structure and organize the experimental strategy content, converting the experimental strategy content, which includes basic events, result events, and troubleshooting solutions, into a rule file. This file is then dynamically loaded onto the execution side. Since the experimental strategy is managed independently of the execution program in the form of a rule file, the strategy configuration and execution logic are decoupled. Strategy updates can be completed without modifying the execution program, improving the configuration flexibility and deployment efficiency of the experimental strategy. This also facilitates unified management and rapid application of the experimental strategy. During execution, the rule engine interprets the execution rule file, and the expression engine evaluates the trigger condition expressions to jointly determine the matching between real-time experimental parameters and rule conditions. The rule engine is responsible for the rule matching process, while the expression engine is responsible for calculating complex condition expressions. This collaborative process achieves a division of labor between rule parsing and expression computation, thereby improving efficiency. The real-time performance and accuracy of high-parameter trigger determination make the strategy triggering process more efficient and reliable. After determining that the target strategy has been triggered, the target strategy is arbitrated based on the preset strategy level, and corresponding handling prompts are generated. Due to the introduction of the strategy level mechanism, when multiple strategies have triggering relationships, they can be uniformly arbitrated according to the strategy level, which can avoid handling conflicts between different strategies and allow high-priority strategies to participate in the handling decision first, thereby improving the orderliness and rationality of strategy execution during the experiment. After generating the handling prompts, the handling result record is generated based on the handling confirmation instructions fed back by the operator, so that the strategy triggering, handling confirmation and handling result form a complete recording process. By recording the handling results, not only can the strategy execution and handling situation during the experiment be preserved, but also a basis can be provided for subsequent experimental process query, analysis and traceability, thereby improving the manageability and traceability of the experimental strategy execution process. In summary, the test strategy execution method provided in this application, through structured configuration, dynamic loading, real-time triggering, hierarchical arbitration, and handling records of test strategies, can decouple test strategy configuration and execution, improve the real-time performance, flexibility, and reliability of strategy execution, and enhance the orderly handling, management efficiency, and full-process traceability of the test process.

[0061] In some embodiments, the aforementioned acquisition of the experimental strategy content arranged through a visual canvas may include: in response to the arrangement operation on the visual canvas, acquiring a first element set, a second element set, and a third element set, wherein the first element set may include a first triggering condition expression representing the aforementioned basic event, the second element set may include action instruction information representing the aforementioned result event, and the third element set may include a troubleshooting master table and troubleshooting sub-items representing the troubleshooting scheme; acquiring the association relationship established between the first element set, the second element set, and the third element set through canvas connections to obtain the experimental strategy content.

[0062] In some examples, the first element set is a structured data set used to carry the trigger judgment basis of the test strategy, and as a whole, it represents all the core content of the aforementioned basic events. The first element set integrates and stores the judgment logic data corresponding to various test parameters. The core component is the first trigger condition expression, which can realize the quantitative judgment of the abnormal state of the equipment test condition parameters. It is the trigger source data unit of the entire test strategy. For example, in the scenario of steady-state test of aero-engine, the engineer configures two types of trigger condition expressions in the visualization canvas: temperature over-limit judgment logic and speed fluctuation judgment logic. The system unifies and encapsulates the two types of parameter judgment expressions to form the first element set corresponding to the abnormal operating conditions of the steady-state test, which is used for the abnormal trigger judgment of subsequent test parameters.

[0063] The second element set is a structured data set used to carry the equipment execution logic after the test anomaly is triggered. It is used as a whole to represent all the core content of the aforementioned result event. The second element set integrates and stores the equipment control instructions and operating condition adjustment information corresponding to various operating condition anomalies. The core component is action instruction information, which is used to define the standardized response actions that the test equipment and test system need to execute after the trigger conditions are met. For example, for the two anomaly judgment scenarios of engine temperature exceeding the limit and speed fluctuation, engineers configure cooling and voltage stabilization adjustment actions, speed steady-state correction actions, and abnormal operating condition marking actions, respectively. The system will collect all the equipment action instruction information corresponding to the anomalies and form a second element set adapted to the steady-state test conditions for automated action response after the anomaly is triggered.

[0064] The third element set is a structured data set used to carry out manual troubleshooting guidance for test faults. It represents all the core content of the aforementioned troubleshooting plan. The third element set is composed of a main error clearing table and troubleshooting sub-items. It fully defines the fault classification standards, standardized troubleshooting steps, and compliant handling specifications for various test anomalies, providing test personnel with a visualized and process-oriented fault troubleshooting basis. For example, for two fault scenarios, abnormal engine temperature and abnormal speed fluctuation, engineers enter the corresponding fault clearing classification entries and configure troubleshooting sub-items such as sensor calibration, pipeline inspection, and parameter calibration for each entry. The system integrates all fault classification information and troubleshooting steps to form a complete third element set, which is used for manual troubleshooting guidance after test anomalies.

[0065] The element set canvas connection relationship is a one-to-one business logic binding relationship between three types of element sets established through visual connection operations in the visual canvas editing interface. This relationship is used to achieve precise matching and binding of abnormal trigger judgment conditions, automatic equipment execution actions, and manual fault troubleshooting solutions, so that the three independent element sets form a closed-loop complete test strategy, ensuring that a single abnormal condition corresponds to a unique judgment logic, execution action, and troubleshooting process. For example, in the visual canvas, an engineer can connect and bind the first trigger condition expression corresponding to temperature over-limit with the temperature adjustment action command and the temperature fault-specific troubleshooting sub-item, and at the same time connect and bind the speed fluctuation trigger expression with the speed correction action and the speed fault troubleshooting process, forming multiple sets of independent and logically corresponding element relationships.

[0066] For example, in the visualization configuration phase of an aero-engine test strategy, test engineers log into the digital configuration platform for the test strategy and load the visualization canvas editing interface. Based on the operating conditions and fault handling standards of this test mission, they complete the structured arrangement and logical association configuration of three types of element sets step by step. First, the engineer constructs the first element set. Combining the core monitoring parameters of temperature, speed, and pressure for this test, the engineer edits the first trigger condition expressions corresponding to various parameter anomalies one by one in the canvas, clarifying the over-limit thresholds, linkage judgment logic, and interval judgment rules for each parameter. The system collects all configured trigger judgment expressions to generate the first element set for identifying operating condition anomalies. Then, the engineer constructs the second element set. For each parameter anomaly judgment scenario in the first element set, the engineer matches the corresponding test equipment handling logic, edits various action command information such as equipment parameter adjustment, test condition locking, and abnormal status marking, and the system integrates all automated execution action data to generate the second element set for equipment response and handling. Building upon this foundation, engineers constructed a third set of elements. For each type of abnormal parameter condition, a dedicated fault clearing master table was established to categorize the faults. The system then refined the troubleshooting sub-items and handling verification standards for each item, collecting all fault investigation and reset specification data to generate a third set for manual handling guidance. After the three sets of elements were independently configured, engineers performed connection and arrangement operations on the visualization canvas based on the experimental business logic. Each trigger judgment expression in the first set was uniquely associated with and bound to the corresponding abnormal handling action instruction in the second set, while simultaneously binding the corresponding fault clearing entries and troubleshooting sub-items in the third set, establishing a one-to-one standardized logical mapping relationship. The system automatically recorded the association rules corresponding to all canvas connections, integrating the scattered and independent three sets of elements into a logically closed-loop, structurally complete experimental strategy content. This achieved both modular and independent configuration of various strategy units and ensured accurate matching of trigger conditions, execution actions, and troubleshooting solutions, providing structured and standardized strategy data support for subsequent rule file generation, real-time parameter matching, and abnormal strategy handling.

[0067] Through the implementation of the above embodiments, in response to the arrangement operation on the visualization canvas, the element sets representing basic events, result events, and troubleshooting solutions are obtained respectively. The relationship between each element is established by combining the canvas connections to generate the test strategy content. This allows the equipment test strategy to be configured in a graphical and structured manner without having to directly write complex rule logic. For test strategies that are frequently adjusted during equipment testing, this can reduce the difficulty of strategy configuration, improve the efficiency of strategy construction, and make the logical relationship between triggering conditions, execution actions, and fault handling clearer. This is conducive to the maintenance, reuse, and rapid modification of the test strategy, thereby improving the flexibility of test strategy configuration.

[0068] In some embodiments, the aforementioned distribution of the rule file to the execution side may include: obtaining a publishing instruction for the rule file and switching the status of the rule file from editing to published; generating a new version of the rule file based on the original rule file in response to a revision instruction for the published rule file; or, in response to a version rollback instruction, determining a target historical version from the historical version record and republishing the target historical version as the currently effective version; and distributing the rule file to the execution side when the rule file is in the published state.

[0069] In some examples, the release command for the rule file is a standardized operational command used to switch the test strategy from the editing and debugging state to the officially effective state. It serves as a prerequisite for the rule file to be issued and as the basis for the state switch. This command is used to confirm that the test strategy logic of the current canvas arrangement is complete, the expression syntax is compliant, the element relationships are correct, the debugging and verification have been completed, and it can be included in the official version management system and issued to the downstream execution side for deployment. For example, after the test engineer completes the canvas arrangement, trigger condition configuration and logic self-check of the test strategy for the aircraft engine idling condition, and confirms that the current strategy can be adapted to the official test condition, he clicks the release button on the interface, and the system generates the release command for the corresponding rule file, starting the strategy state switch process.

[0070] The status of a rule file is a standardized status marker used by the system to indicate the stage of the rule file's lifecycle. It is used to distinguish between the editing and debugging attributes of a policy and its official implementation attributes. The overall status includes two fixed states: "in editing" and "published." These two states are isolated from each other and have independent permissions. This is used to manage the editing, revision, and distribution permissions of the rule file. For example, a newly created engine acceleration test rule file is initially in the "in editing" state by default, supporting secondary modifications to the canvas, parameter adjustments, and logic optimizations. After receiving a release command and completing the state switch, the rule file changes to the "published" state and can no longer be freely edited. It can only be updated and optimized through version iterations.

[0071] Revision commands for published rule files are secondary optimization and modification commands initiated for rule files that have been published and are in effect. Published rule files have their original content locked and cannot be directly edited or overwritten. Secondary editing permissions can only be enabled by responding to revision commands to achieve iterative optimization of test strategies and adapt to iterative needs for test condition adjustments, parameter threshold optimization, and fault logic improvement. For example, during the test application of a published engine over-temperature protection strategy, engineers may need to fine-tune the temperature trigger threshold and optimize troubleshooting sub-items based on multiple batches of test data. In this case, an operation can be initiated through the interface revision entry, and the system will generate the corresponding revision command to unlock iterative editing permissions for this version of the rule file.

[0072] Generating a new version of the rule file based on the original rule file is the version upgrade generation logic after the system responds to the revision instruction. It means that the system uses the currently released original rule file as a base template, inherits the basic strategy framework, element relationships and core logic of the original file, and retains the manually revised and optimized content to generate a brand new version of the rule file. The new version of the rule file is archived independently and marked with a version number, without overwriting the original historical version, realizing strategy iteration and upgrade while retaining historical versions. For example, the system retrieves the released original rule file for engine over-temperature protection. After the engineer fine-tunes the temperature trigger expression and troubleshooting sub-items, the system generates a brand new rule file with an upgraded version number based on the complete framework of the original file and overlays the optimized content. The original old version file is completely retained and not overwritten.

[0073] Version rollback commands are used to revoke the currently effective policy version and restore the historical compliant policy version. When the latest version of the rule file has adaptation anomalies, logical deviations, or operating condition mismatches, the version rollback command can be used to terminate the current new version's effective state and restore the running permissions of the historical stable version, ensuring a smooth and controllable test process. For example, after the latest version of the engine steady-state operating condition policy is issued and run, if a parameter mis-triggered problem occurs, the test personnel can initiate a rollback operation through the configuration-side version management module. The system will generate a version rollback command and start the historical version restoration process.

[0074] The process of identifying a target historical version from historical version records and republishing it as the current effective version involves the system receiving a version rollback instruction, traversing the historical version database to match a unique target historical version based on a manually selected version identifier, completing file integrity and compliance checks, and then automatically republishing the historical version as the current effective version. For example, after receiving a rollback instruction, the system retrieves the previous stable engine steady-state operating condition rule file from the version ledger, verifies that the file is complete and undamaged and logically compliant, and then remarks the historical version as published, making it the currently deployable and loadable effective policy version.

[0075] The system identifies the current status of rule files in real time. After determining that the rule file is published and fully compliant, it automatically triggers the distribution process and pushes the rule file to the execution-side strategy engine. For example, a transient operating condition strategy file that is in the editing state cannot be distributed. After the publication status is switched, the system identifies the compliance status and automatically distributes the version of the rule file to the test site execution side to complete the dynamic loading and deployment.

[0076] For example, in the specific implementation of version management and distribution of aero-engine test strategies, the configuration-side strategy subsystem implements full lifecycle status control and version iteration management for all domain rule language rule files generated by the visualization canvas. After the engineer initially completes the canvas arrangement, element association configuration, and rule file generation for the engine variable operating condition test strategy, the initial rule file is in an editable state by default. The system allows secondary modification, parameter adjustment, and logic optimization permissions, while restricting the distribution permission of this version file to prevent immature strategies from being put into test operation. When the engineer completes the full-dimensional verification of the strategy and confirms that the strategy triggering conditions, execution actions, and troubleshooting logic are fully adapted to the test operating condition requirements, the engineer initiates a release operation through the configuration-side interface. The system receives the corresponding release instruction and automatically switches the status of the rule file from editable to released. At this time, the version strategy is officially included in the valid version ledger and is qualified for distribution and deployment. During subsequent test iterations, if it is necessary to optimize the threshold for judging abnormal operating conditions or update the troubleshooting sub-items, engineers can initiate revision commands for the currently released effective policies. After the system responds to the revision command, it uses the currently effective original rule file as a baseline template, retains the original core policy architecture and element association logic, and compiles and generates a new rule file with an upgraded version number, incorporating manually optimized modifications. The new version file is archived independently and enters a new version lifecycle. If the latest iterative policy version exhibits abnormal operating conditions such as adaptation deviations or accidental triggering during test applications, staff can initiate a version rollback command through the version management module. After the system responds to the command, it automatically traverses the historical version record ledger, accurately matches and locates the manually specified stable historical version, completes the file integrity and policy compliance verification, and then re-releases the target historical version as the current effective version, achieving rapid repair of policy anomalies. Throughout the entire version control process, the system consistently executes strict distribution access logic, only distributing rule files that are already published. Incomplete policy files in the editing state are blocked from distribution. Ultimately, published rule files that have been verified to be compliant and valid are distributed to the execution side, providing a stable, reliable, and traceable basis for the execution side's policy engine to dynamically load and perform real-time parameter matching calculations.

[0077] Through the implementation of the above embodiments, a mechanism for editing, publishing, and version management of rule files is set up, and it supports the generation of new versions through revisions and the rollback of historical versions. This enables the unified release control of equipment testing strategies before they are officially put into execution. At the same time, when test requirements change, it is possible to quickly switch to a new strategy version or restore a historical version. This ensures that the execution side always loads the published and confirmed rule files, reduces the management chaos caused by strategy modifications, improves the standardization and flexibility of the test strategy update process, and avoids the normal progress of equipment testing due to incorrect strategy versions.

[0078] In some embodiments, step 102 may include: obtaining test configuration information corresponding to the aforementioned rule file, wherein the test configuration information may include aircraft type identifier, test task identifier, and engine identifier; sending the rule file to the strategy loading interface on the execution side based on the test configuration information; and loading the rule file into the running strategy engine through the strategy loading interface in the form of data injection, so as to update the rule file without stopping the system.

[0079] In some examples, test configuration information is a set of multi-dimensional identity attributes used to uniquely identify a single aero-engine test mission. It serves as the binding basis for targeted matching, precise distribution, and ledger traceability of rule files. Test configuration information is used to distinguish test strategies corresponding to different aircraft types, test missions, and individual engines, ensuring that various test-specific rule files accurately correspond to the target test scenarios and avoiding strategy misuse and mismatch issues under multiple test parallel operating conditions. For example, in the creation phase of the aero-engine overall performance assessment test, the system collects all attribute data such as the aircraft type, test mission number, and engine serial number corresponding to this test, and integrates them to form unique test configuration information for this test, which is used to bind the rule file for the corresponding operating condition.

[0080] The aircraft type identifier is a standardized and unique identification field used to distinguish different aero-engine product models and to define the range of engine models to which the current test strategy is applicable. Different aircraft models have different engine parameter thresholds, test condition standards, and fault handling logic. The aircraft type identifier can ensure that the rule file strictly matches the test specifications of the corresponding aircraft model, and achieve strategy model isolation adaptation. For example, when conducting a steady-state test of a certain type of commercial aero-engine, the test personnel select the corresponding aircraft model, and the system generates a unique aircraft type identifier. This identifier is bound to the current steady-state operating condition rule file to ensure that the test strategy is only applicable to the test of this type of engine.

[0081] The test task identifier is a globally unique code used to distinguish each independent test operation. It serves as an index field for test task ledger management, strategy binding, and traceability of distribution records. Multiple batches, multiple operating conditions, and multiple stages of test tasks can be accurately distinguished through the test task identifier, ensuring that each set of rule files corresponds to a unique test task and achieving one-to-one binding between strategies and test tasks. For example, if the same engine undergoes warm-up tests, steady-state tests, and transient acceleration tests successively, the system generates a unique test task identifier for each independent test task. Rule files for different operating conditions are bound to the corresponding task identifiers, enabling independent control and distribution of multi-operating-condition strategies.

[0082] An engine identifier is a unique identification code used to distinguish an individual aero-engine. It generally corresponds to the engine's unique factory serial number. Different individual engines of the same model may have assembly differences and performance deviations. The engine identifier enables precise matching between test strategies and individual engines, ensuring that the strategy is adapted to the characteristics of the individual equipment. At the same time, it supports the traceability and review of test data and strategy versions of a single engine. For example, when two aero-engines of the same model are subjected to endurance tests in sequence, independent engine identifiers are generated by entering different factory serial numbers. The two sets of endurance test rule files are respectively bound to the corresponding engine identifiers to avoid confusion between the test strategies of the two equipments and data disorder.

[0083] The policy loading interface on the execution side is a standardized program interaction interface deployed on the execution side server. It is a dedicated communication entry point for the configuration side and the execution side to realize the data transmission of rule files and the exchange of policy update instructions. This interface has the capabilities of file reception, data verification, format parsing, permission interception, and loading instruction pass-through. It can reliably receive rule file data issued by the configuration side, providing a standardized channel support for subsequent dynamic data injection and loading. For example, after the test policy is released and the version is confirmed, the configuration side calls the preset policy loading interface on the execution side according to the test configuration information, and pushes the encapsulated rule file data package to the execution side server to complete cross-end data transmission.

[0084] After the policy loading interface completes file reception and integrity verification, it automatically triggers the background data injection program to inject new rule data into the running policy engine, completing memory overwrite and policy refresh. The entire process requires no manual intervention or downtime. For example, during long-term continuous test runs of an aero-engines, it is necessary to optimize the anomaly judgment threshold policy. The system receives the new rule file through the policy loading interface and updates the internal rule logic of the policy engine by injecting memory data. The test data acquisition process runs continuously without any interruptions such as downtime, data loss, or restarts, and the new policy takes effect immediately.

[0085] For example, in the specific implementation scenario of aero-engine test strategy distribution and dynamic loading, after completing rule file release, version verification, and compliance confirmation, the configuration side initiates a precise targeted distribution and non-stop update process. The system first automatically retrieves the complete set of test configuration information corresponding to the current test task, fully obtaining the aircraft type identifier, test task identifier, and engine identifier for this test. These three unique identifiers are encapsulated in the header of the rule file data packet, serving as the basis for targeted strategy distribution and identity verification. Based on the network addressing parameters corresponding to the test configuration information, the configuration side accurately locates the on-site execution side service address corresponding to this test, calls the strategy loading interface pre-deployed on the execution side and continuously monitoring it, and pushes the rule file carrying unique test identity information completely to the execution side server. The execution side completes data packet reception, file integrity verification, version compliance verification, and identity matching verification through the strategy loading interface. After confirming that the rule file fully matches the currently running test task, it initiates the non-stop dynamic update process. While ensuring the strategy engine operates normally throughout the entire process, continuously monitoring test parameters and without interrupting any test tasks, the system employs online data injection to directly write the strategy logic, trigger conditions, and handling configuration data of the new rule file into the strategy engine's runtime memory space. This achieves dynamic overwriting of the original old strategy data and immediate registration and activation of the new strategy. The entire loading and update process requires no system shutdown, no service restart, and no pause in test data acquisition, enabling seamless iterative updates of the strategy during continuous test operation. This ensures both the continuity of test conditions and the integrity of test data, while also enabling rapid iteration, dynamic deployment, and precise adaptation of test strategies, effectively addressing the technical shortcomings of traditional test strategy updates that require system shutdown and restart.

[0086] Through the implementation of the above embodiments, test configuration information such as the model identifier, test task identifier, and engine identifier corresponding to the rule file is obtained, and the rule file is sent to the execution-side policy loading interface to be loaded into the running policy engine in a data injection manner. This enables different equipment test tasks to automatically match the corresponding test policies and complete policy updates without stopping the system. For continuous equipment test scenarios, policy replacement can be completed without stopping the test system, which can improve policy deployment efficiency and the continuity of equipment testing, while also enhancing the flexibility of test policy configuration.

[0087] In some embodiments, step 103 may include: converting real-time collected experimental parameters into fact data objects and inputting the fact data objects into the rule engine; during the interpretation and execution of the rule file, the rule engine determines the current trigger condition to be matched in the rule file; if the current trigger condition to be matched contains a preset expression, the rule engine calls the expression engine and controls the expression engine to perform evaluation operations on the preset expression to obtain the calculation result; the rule engine determines the matching status of the current trigger condition to be matched based on the calculation result and the fact data object, so as to determine whether the target strategy is triggered.

[0088] In some examples, fact data objects are structured data carriers formed by standardizing and encapsulating raw test parameters collected in real time at the test site. This is a unified data format that the rule engine can recognize, read, and participate in logical matching and formula calculations. Raw test parameters, on the other hand, are scattered physical quantity data collected by hardware, with inconsistent formats and no structured field definitions, making them unsuitable for direct participation in the complex logical judgments of rule files. Fact data objects standardize the fields, units, values, and structures of various test parameters, forming standard input data adapted to the dual-engine computing system. For example, during the steady-state test of an aero-engine, the data acquisition system collects multiple raw physical parameters in real time, such as turbine afterburner temperature, fuel supply pressure, engine speed, and intake airflow. The system uniformly encapsulates and standardizes these scattered parameters, generating fact data objects containing complete parameter fields, standard values, and acquisition time information, which serve as standard input data for rule matching.

[0089] Inputting factual data objects into the rule engine refers to the continuous data feeding process whereby, after the system completes parameter standardization and encapsulation, it continuously pushes structured operating condition data into the rule engine's running memory in real time. This process provides a continuous and dynamic operating condition data source for subsequent iterative rule matching, enabling the rule engine to perform real-time logical judgments based on the latest test operating conditions, ensuring the dynamism and continuity of the strategy matching process. For example, during engine variable operating condition test operation, the system continuously generates new factual data objects at a fixed acquisition cycle and inputs them into the rule engine one by one. The rule engine refreshes its built-in operating condition data in real time and always performs rule condition matching calculations based on the latest engine operating parameters.

[0090] The rule engine can continuously interpret and execute the code logic of the loaded rule file, and automatically traverse and filter all trigger conditions corresponding to the current test condition according to the preset strategy arrangement order and working condition adaptation range within the file, and determine the current set of trigger conditions to be matched. For example, during the engine acceleration test, the rule engine parses the currently effective rule file, automatically filters out multiple trigger conditions that are suitable for the acceleration condition, such as excessive speed change rate, excessively rapid temperature rise, and abnormal pressure fluctuation, and determines the above conditions as the trigger conditions to be matched in the current round.

[0091] After identifying that the condition to be matched contains a preset expression that is not a simple comparison, the rule engine automatically generates an engine call instruction, pushes the corresponding parameter fields in the fact data object to the expression engine, and the expression engine independently completes the formula parsing and numerical calculation and returns the result. For example, in the engine transient condition determination scenario, the trigger condition contains a composite preset expression of temperature change rate linked to pressure compensation. After the rule engine identifies this complex formula condition, it actively calls the expression engine to complete the calculation of the change rate difference and the compensation correction calculation, and outputs accurate quantitative calculation results.

[0092] After receiving the expression calculation result, the rule engine combines the working condition characteristics of the original factual data to complete the full-dimensional logical comparison and compliance judgment, autonomously marks the matching status of the current triggering condition, and finally completes the triggering judgment of the target policy. For example, after the rule engine obtains the factual data corresponding to the temperature change rate calculation result and the real-time pressure parameter, it compares it with the preset safety threshold range, determines that the current parameter combination fully meets the abnormal triggering conditions, and finally marks the current target policy as triggered, and enters the subsequent policy arbitration and processing process.

[0093] For example, during the real-time operation of various aero-engine operating condition tests, the execution-side system continuously performs parameter standardization and dual-engine collaborative matching calculations. The test site data acquisition link continuously collects raw test operating condition parameters such as engine temperature, pressure, speed, and flow rate at fixed intervals. The system performs format calibration, field encapsulation, and structural standardization on these scattered raw parameters to generate unified and standardized factual data objects. The system continuously inputs each round of updated factual data objects into the background-running rule engine in real time, providing a dynamic and up-to-date test operating condition data source for rule matching loop calculations. The rule engine continuously interprets and executes the dynamically loaded domain rule language rule files, traversing the various judgment logics stored within the file according to a preset strategy and execution sequence, filtering all verification content suitable for the current test operating condition, and determining all matching trigger conditions that need to be verified in the current round. The rule engine performs type identification on each matching trigger condition, distinguishing between simple threshold comparison conditions and complex formula calculation conditions. If the current trigger condition to be matched is only a single parameter threshold comparison, the rule engine directly completes the logical judgment. If the current trigger condition to be matched includes various preset expressions such as multi-parameter linkage and rate of change calculation, the rule engine actively initiates a cross-engine scheduling instruction, calls the coupled and integrated expression engine, inputs the corresponding target parameter field in the fact data object into the preset expression, and the expression engine independently completes formula parsing, numerical substitution, and high-precision evaluation, finally generating a standardized calculation result and sending it back to the rule engine. The rule engine simultaneously combines the quantitative calculation result returned by the expression engine with the real-time valid fact data object, compares it with the preset judgment criteria and logical constraints in the rule file, and comprehensively determines the final matching status of the current trigger condition to be matched. If the parameters and calculation results do not meet the trigger criteria, it is determined that the target strategy has not been triggered, and the system automatically enters the next round of parameter collection and matching loop; if the parameters and calculation results completely match the preset trigger conditions, it is determined that the corresponding target strategy has been successfully triggered, providing accurate and reliable preliminary judgment basis for subsequent strategy level arbitration and handling prompt generation.

[0094] Through the implementation of the above embodiments, the real-time collected test parameters are converted into factual data objects and input into the rule engine. The rule engine then calls the expression engine to evaluate the trigger condition expression during the interpretation and execution of the rule file. The trigger condition matching status is then determined by combining the factual data. This allows rule matching and expression calculation to be completed by different functional modules. During equipment testing, when faced with a large number of real-time monitored parameters and complex judgment conditions, the efficiency of test parameter matching calculation and the accuracy of trigger judgment can be improved. This enables the test strategy to respond to parameter changes more quickly, thereby improving the efficiency of real-time triggering of the test strategy.

[0095] In some embodiments, the aforementioned arbitration processing of the target policy based on a preset policy level to generate processing prompt information may include: obtaining the first policy level of the triggered target policy and obtaining the second policy level of at least one policy currently in the processing execution state, wherein the policy in processing is a policy that has been triggered, has generated a processing prompt, and has not yet received a processing confirmation instruction; if the first policy level is higher than the second policy level, a first overriding instruction is generated, and the processing type of the target policy is determined to be normal processing, wherein the first overriding instruction is used to cancel the current processing of the policy in processing and generate an overriding processing record, the overriding processing record may include a higher-level policy identifier and an overriding processing type identifier; and generating processing prompt information according to the troubleshooting plan and processing button configuration information corresponding to the target policy.

[0096] In some examples, the first strategy level is the preset priority level parameter corresponding to the most recently triggered target strategy, and it is one of the comparison parameters in this arbitration and handling process. The first strategy level is used to characterize the degree of danger and urgency of handling the newly entered abnormal fault condition. It is the basis for determining whether the newly entered strategy has priority handling authority and directly determines the handling priority and coverage authority in multi-strategy concurrent scenarios. For example, during the test of an aero-engine, the most recently triggered abnormal strategy of sudden change in turbine speed is a high-risk fault strategy. The system automatically reads the priority parameter built into the target strategy to determine the corresponding first strategy level, which is used to compare and arbitrate with the currently in-place handling strategy.

[0097] The "in-processing strategy" refers to a historically triggered strategy that is currently in the test processing execution state. Specifically, it refers to a non-closed-loop strategy that has completed the strategy triggering judgment, generated front-end processing prompt information, but has not yet received a processing confirmation instruction from the operator. This type of strategy has entered the on-site processing process, but has not completed the manual confirmation closure, and will continue to occupy the current test processing channel. It is the main source of multi-strategy conflict scenarios. For example, during engine testing, if the fuel pressure fluctuation strategy is triggered first, the system has pushed the corresponding processing prompt information, but the operator has not yet completed the investigation and confirmation operation. This pressure fluctuation strategy is the "in-processing strategy" under the current test conditions.

[0098] The second strategy level is a preset priority level parameter corresponding to the currently executing strategy, used to characterize the risk level and priority of the fault handling condition. The second strategy level and the first strategy level form a bidirectional comparison benchmark, which is the key comparison basis for the system to realize automated priority arbitration and determine whether the strategy coverage mechanism is triggered. For example, if the strategy for handling fuel pressure fluctuations is a normal low-risk anomaly strategy, the system retrieves the preset level parameter of this strategy from the background strategy ledger to obtain the corresponding second strategy level, which is used to compare the priority with the first strategy level of the newly entered sudden speed change strategy.

[0099] The first overriding instruction is a standardized control command automatically generated by the system after determining that a new target strategy has a higher priority. It is used to terminate the execution process of the current low-level handling strategy and give priority to the high-level fault strategy. The first overriding instruction is a control command that resolves conflicts between multiple strategy handling processes. It can forcibly terminate the existing low-priority handling process and ensure priority response to high-risk and emergency faults. For example, if the system determines that the first strategy level corresponding to a sudden change in speed is higher than the second strategy level corresponding to pressure fluctuation, it automatically generates a first overriding instruction to terminate the original pressure fluctuation handling process and switch to the special handling process for the high-level speed anomaly.

[0100] The handling type of the target strategy is a standardized type definition of the handling attributes of the newly entered target strategy after the system completes priority arbitration. In the embodiments of this application, when a high-level strategy covers a low-level strategy, the handling type of the target strategy is defined as normal processing, which means that the target strategy is the only valid and priority-executed regular handling strategy under the current working condition, and has full handling execution authority and process advancement authority. For example, after the high-level strategy of sudden speed change successfully covers the original low-level strategy of pressure fluctuation, the system marks the handling type of the target strategy of sudden speed change as normal processing, and determines that it is the only legal and valid handling execution strategy at present.

[0101] The process of generating handling prompts based on the troubleshooting plan and handling button configuration information corresponding to the target strategy involves the system automatically reading the text content of the troubleshooting plan, the error clearing items, and the troubleshooting sub-items preset on the configuration side of the target strategy after completing strategy arbitration and handling type determination. At the same time, it reads the handling button function configuration preset on the interface and integrates the two types of data to automatically render and generate front-end visual handling prompts. For example, the system retrieves the standardized troubleshooting steps, fault descriptions, and reset standards corresponding to the sudden speed change strategy, and matches the interface button configurations corresponding to confirmation handling and emergency shutdown. It then integrates and generates complete handling prompts containing fault descriptions, troubleshooting guidance, and operation options and pushes them to the monitoring interface.

[0102] For example, during the parallel monitoring and anomaly handling of multiple operating conditions in aero-engine testing, the execution-side system continuously maintains a global strategy handling status ledger, monitoring the triggering status and handling closure progress of various test strategies in real time. When the dual-engine collaborative calculation determines that a new target strategy meets the triggering conditions, the system immediately reads the preset priority parameters of the new target strategy to obtain the corresponding first strategy level. At the same time, the system automatically traverses all handling tasks currently in an unclosed-loop state, filters out strategies that have been triggered, have had handling prompts pushed, and have not received manual confirmation instructions, and retrieves the preset priority parameters of each handling strategy to obtain the corresponding second strategy level. The system compares the first and second strategy levels to determine their relative importance. If the first strategy level of the new target strategy is lower than or equal to the second strategy level of the handling strategy, the current in-place handling process remains unchanged, and the new strategy is temporarily suspended. If the first strategy level of a newly entered target strategy is higher than the second strategy level of the strategy under handling, the system immediately generates a first overriding instruction. This instruction forcibly cancels the currently executing handling process of the lower-level strategy, terminates the original prompting process, and stops the corresponding handling logic from progressing. Simultaneously, it automatically generates an overriding handling record containing the higher-level strategy identifier and the overriding handling type identifier, completely preserving the strategy overriding conflict handling process. In this scenario, the system uniformly classifies the handling type of the newly entered higher-level target strategy as normal processing, establishing this strategy as the only valid handling strategy under the current test conditions. Finally, the system retrieves the complete troubleshooting plan pre-bound to the higher-level target strategy, including the fault classification and clearing master table and hierarchical troubleshooting sub-items. It also matches the pre-set front-end handling button configuration information of the strategy, integrating fault condition descriptions, standardized troubleshooting steps, fault reset requirements, and human-computer interaction options. This automatically generates complete, standardized, and interactive visual handling prompts and pushes them to the test monitoring terminal interface, guiding operators to perform precise and orderly fault handling operations, achieving automated arbitration and safe handling in multi-strategy concurrent conflict scenarios.

[0103] By implementing the above embodiments, the strategy levels of the target strategy and the strategy in the current handling are obtained. When the target strategy level is higher, the current handling process of the lower-level strategy is canceled. At the same time, an overriding handling record is generated. Then, handling prompt information is generated according to the troubleshooting plan corresponding to the target strategy. This enables the automatic priority arbitration according to the strategy level when multiple strategies are triggered at the same time during the equipment test. This can avoid conflicts caused by multiple handling strategies acting on the same test equipment or the same test parameters at the same time, ensure that the high-priority test strategy is executed first, and improve the orderliness and safety of fault handling during the equipment test.

[0104] In some embodiments, step 105 may include: obtaining feedback operation data for the aforementioned handling prompt information, wherein the feedback operation data may include the identifier of the triggered handling button; generating a handling confirmation instruction based on the feedback operation data; obtaining the handling time, handling type identifier, and response rule identifier of this handling based on the handling confirmation instruction; and performing structured encapsulation of the handling time, handling type identifier, handling button identifier, and response rule identifier to generate a handling result record.

[0105] In some examples, feedback operation data refers to the human-computer interaction data generated by the operator after completing fault handling based on the handling prompts displayed on the front-end monitoring interface. Feedback operation data accurately represents on-site handling behavior and is the original data source for generating standardized handling confirmation instructions. Its core includes the triggered handling button identifiers, accurately distinguishing different types of on-site handling operations and fully reflecting the type of manual handling actions performed. For example, after handling an aero-engine overheating anomaly, the operator completes fault diagnosis and condition reset operations according to the troubleshooting guidelines, clicks the confirm handling button on the monitoring interface, and the system captures the identifier information and operation behavior corresponding to this button click in real time, generating the corresponding feedback operation data.

[0106] The process of generating a disposal confirmation instruction based on feedback operation data involves the execution side backend receiving feedback operation data from the frontend, verifying the completeness, validity, and permission compliance of the operation data, and after the verification is passed, encapsulating and converting the original interactive data according to the system's preset instruction format to automatically generate a standardized disposal confirmation instruction. For example, when the system receives feedback operation data corresponding to the operator's confirmation of disposal, after completing the data validity verification, it encapsulates the confirmation operation behavior into a standardized disposal confirmation instruction and notifies the backend disposal archiving module to start the disposal record generation process.

[0107] The handling time is a standardized timestamp data that characterizes the completion node of the anomaly handling in this test. It is used to accurately record the specific moment when the operator completes the fault handling and submits the confirmation operation. The handling time is the time sequence basis for test fault review, handling efficiency statistics, and strategy response time analysis. It can accurately identify the closed-loop time node of a single anomaly handling. For example, after the engine pressure fluctuation fault handling is completed and the confirmation operation is submitted, the system immediately captures the current standard system time and generates the corresponding handling time to mark the final closed-loop moment of this fault handling process.

[0108] The handling type identifier is a standardized identifier field used to distinguish the business attributes of this anomaly handling. It is used to characterize the handling execution category after the current policy is triggered. It can effectively distinguish different handling scenarios such as normal handling and high-level policy coverage handling, and realize the classification, archiving and differentiated statistics of multiple types of handling behaviors. For example, after the high-level speed anomaly policy covers the low-level pressure fluctuation policy to complete the handling, the system automatically matches and generates the corresponding handling type identifier for the coverage handling scenario based on the previous coverage arbitration result, which is used to distinguish between normal independent handling and conflict coverage handling scenarios.

[0109] The response rule identifier is a unique coded identifier used to uniquely identify the target strategy corresponding to this anomaly handling, and it corresponds one-to-one with a single test strategy within the rule file. The response rule identifier can accurately locate the triggering conditions, troubleshooting solutions, and strategy configuration content corresponding to this handling, realizing the precise binding of handling records and strategy rules, and providing an index basis for subsequent strategy tracing, problem localization, and iterative optimization. For example, after the engine turbine over-temperature anomaly strategy is triggered and the handling loop is completed, the system retrieves the unique rule code corresponding to the over-temperature strategy in the rule file as the response rule identifier for this handling record, realizing the precise association between the handling record and the over-temperature strategy.

[0110] The process of structurally encapsulating the handling time, handling type identifier, handling button identifier, and response rule identifier to generate a handling result record involves the system collecting all key field data corresponding to this handling, aligning, binding, and formatting the fields according to a preset data storage template, automatically encapsulating and generating a standardized handling result record, and archiving it. For example, after the system collects the handling time, handling type identifier, confirmation handling button identifier, and over-temperature strategy-specific response rule identifier corresponding to the over-temperature fault, it encapsulates all fields into an independent structured file, generates the handling result record corresponding to this over-temperature anomaly, and archives it to the corresponding test task ledger.

[0111] For example, in the specific implementation of the closed-loop handling of aero-engine test anomalies, after completing strategy-level arbitration and pushing standardized handling prompts, the execution-side system continuously monitors the human-machine interaction status of the front-end monitoring interface, awaiting manual handling feedback instructions. Test operators refer to the troubleshooting solutions displayed on the interface to complete corresponding fault investigation, equipment condition adjustment, and fault reset operations. After confirming that the current test conditions have returned to normal and the fault handling process has been completed, they click the corresponding handling function button on the monitoring interface to confirm the operation. The front-end monitoring system immediately captures this human-machine interaction, collects complete feedback operation data including the specific triggered handling button identifier, and transmits this set of raw interaction data back to the execution-side backend system in real time. After receiving the feedback operation data, the backend system first performs data integrity and operation validity verification. After confirming that the interaction behavior is compliant and valid, it performs standardized format conversion on the raw feedback operation data, automatically generates the corresponding handling confirmation instruction, and triggers the subsequent handling data extraction, recording, and archiving process. The system responds to the handling confirmation command, simultaneously retrieving and collecting various core identifiers for this handling. It obtains the precise handling time through the system's timestamp module, matches the corresponding handling type identifier by associating it with the arbitration results of the pre-emptive strategy, and obtains the corresponding response rule identifier by binding the unique code of the trigger strategy. Simultaneously, it retains the handling button identifier collected from the front end, thus collecting all core archiving fields. Finally, the system uniformly organizes, associates, and encapsulates the four independent key fields—handling time, handling type identifier, handling button identifier, and response rule identifier—according to a pre-defined standardized data structure. This integrates them to generate a complete, independent, traceable, and batch-scalable standardized handling result record, which is simultaneously archived to the corresponding test task database. This completes the entire closed-loop process of a single test's abnormal triggering, arbitration handling, manual confirmation, and data retention, providing comprehensive data support for subsequent test condition review, fault tracing analysis, and iterative optimization of test strategies.

[0112] By implementing the above embodiments, feedback operation data from operators regarding the handling prompts is obtained, handling confirmation instructions are generated, and further information such as handling time, handling type identifier, and response rule identifier is obtained to generate a structured handling result record. This ensures that the handling process after each strategy trigger during the equipment test is fully recorded. This not only accurately records the strategy execution during the test but also facilitates subsequent querying, analysis, and accountability of the handling process, improving the manageability of the equipment test strategy execution process and providing data support for subsequent strategy optimization.

[0113] In some embodiments, the aforementioned test strategy execution method may further include: acquiring multiple disposal result records generated within a preset historical time period; extracting strategy trigger frequency information, disposal response duration information, and disposal type distribution information from the multiple disposal result records; determining high-frequency triggering strategies and low-frequency triggering strategies based on the strategy trigger frequency information; determining the average disposal response duration corresponding to each strategy based on the disposal response duration information; and generating strategy optimization suggestion information based on the high-frequency triggering strategy, low-frequency triggering strategy, and average disposal response duration, wherein the strategy optimization suggestion information is used to prompt the triggering judgment conditions or preset strategy level for adjusting the strategy.

[0114] In some examples, the preset historical time period is a fixed statistical interval pre-configured by the system for batch extraction of test handling ledger data. It serves as the time dimension filtering benchmark for historical data review and analysis. This time period can be flexibly defined according to test batches, test cycles, and equipment operation and maintenance cycles. It is used to limit the data retrieval scope of this strategy optimization data analysis, ensuring the relevance, effectiveness, and timeliness of the analyzed data, and avoiding interference from outdated and invalid data on the optimization results. For example, in the scenario of quarterly batch test optimization of aero-engines, the management personnel preset the past 90 days as a fixed historical statistical time period in the system. The system automatically filters all abnormal handling data generated by engine test tests within this time period as the basic data source for this strategy optimization analysis.

[0115] Multiple handling result records are a collection of standardized data archives that are automatically structured and archived after each abnormal test and manual handling closed loop within a preset historical time period. These records completely retain core fields such as response rule identifier, handling time, handling type identifier, and handling operation information for each test strategy trigger. They serve as the original data carrier for multi-dimensional data feature extraction and strategy analysis. For example, the system retrieves the closed-loop handling ledgers for all operating conditions of the aero-engine steady-state test, transient acceleration test, and idle speed test over the past 90 days, and summarizes dozens of handling result records corresponding to various faults such as over-temperature anomalies, pressure fluctuations, and speed deviations, which constitute the analysis dataset for this strategy optimization.

[0116] Strategy trigger frequency information is characteristic data used to quantify the frequency of triggering of each test strategy within a preset historical time period. It can intuitively reflect the probability of occurrence of various abnormal test conditions and the rationality of condition suitability. This information is formed by statistically analyzing the cumulative number of triggers and trigger ratio of individual strategies. It can accurately locate various strategies such as frequent false triggers, high-frequency real fault triggers, and long-term zero triggers, providing data basis for strategy simplification and threshold optimization. For example, the system statistics show that the engine fuel pressure fluctuation strategy has been triggered 32 times in the past 90 days, the turbine temperature over-limit strategy has been triggered 5 times, and the speed steady-state deviation strategy has been triggered 2 times. Based on this, the strategy trigger frequency information corresponding to each strategy is generated to distinguish high-frequency and low-frequency trigger characteristics.

[0117] The response time information is a time-series characteristic data used to characterize the efficiency of handling anomalies in a single test. It refers to the time difference between the moment the strategy is triggered and the moment the operator completes the handling confirmation and generates the handling result record. This information can accurately reflect the handling difficulty, the rationality of the troubleshooting plan, and the smoothness of on-site handling for different fault conditions, and serves as the basis for optimizing strategy levels and troubleshooting processes. For example, the system statistically analyzes the handling records of temperature over-limit anomalies and finds that the average handling time for this type of fault is 8 minutes, while the average handling time for pressure fluctuation anomalies is 3 minutes. Based on this, the system generates response time information for the two types of strategies, reflecting the differences in handling efficiency for different faults.

[0118] The disposal type distribution information is characteristic data used to statistically analyze the proportion of various disposal scenarios within a preset historical time period. It mainly includes the quantity and proportion of different disposal types such as routine independent disposal and disposal covered by high-level strategies. This information can intuitively reflect the frequency of concurrent conflicts of multiple strategies and the appropriateness of high and low-level strategies, providing quantitative support for strategy level adjustment. For example, the system statistics show that in historical disposal cases, routine independent disposal cases account for 85%, and conflict disposal cases where high-level strategies cover low-level strategies account for 15%. Based on this, complete disposal type distribution information is generated, quantifying the frequency of strategy conflicts.

[0119] High-frequency triggering strategy and low-frequency triggering strategy are two sets of differentiated strategies obtained by the system based on strategy triggering frequency information and a preset frequency threshold. High-frequency triggering strategy is a test strategy with a high number of historical triggers and a high frequency of operating conditions, including two scenarios: real high-frequency fault triggering and false triggering caused by excessive sensitivity of the strategy threshold. Low-frequency triggering strategy is a test strategy with a low number of historical triggers and very few or even zero triggers in the long term, including two scenarios: scarce suitable operating conditions, overly strict strategy thresholds, and strategy redundancy failure. For example, the system presets an average of ten triggers per month as the frequency classification threshold, classifying the fuel pressure fluctuation strategy as a high-frequency triggering strategy and the turbo speed sudden change strategy as a low-frequency triggering strategy, thus completing the accurate classification of the two types of strategies and providing a classification basis for differentiated optimization.

[0120] The average response time is the average standardized response time for a single strategy, calculated by the system based on the response time information of multiple batches of single strategies. It is a quantitative indicator that characterizes the overall difficulty of handling a single type of fault and the rationality of the process. This indicator can eliminate data deviations caused by differences in individual manual operations and truly reflect the fault handling complexity and troubleshooting suitability of the strategy. For example, the system collects multiple batches of response time data for the temperature exceedance strategy and calculates that the average response time for this strategy is 7.5 minutes, accurately characterizing the overall handling efficiency and difficulty of this type of fault.

[0121] The strategy optimization suggestion information is a standardized and actionable strategy iteration optimization guide automatically generated by the system based on multi-dimensional historical data analysis results. Its core purpose is to prompt staff to adjust the trigger conditions or preset strategy levels for targeted adjustments. This information can accurately match the operational defects of different strategies, enabling the correction of high-frequency false trigger thresholds, the upgrading of high-risk and inefficient strategy levels, and the simplification and optimization of redundant low-frequency strategies, thereby improving the accuracy and rationality of the entire test strategy system. For example, if the system determines that the fuel pressure fluctuation strategy has high-frequency false triggers and short handling time, it generates optimization suggestions to lower the strategy sensitivity and fine-tune the trigger threshold; if it determines that the temperature over-limit strategy has long handling time and high risk level, it generates optimization suggestions to maintain a high priority level and refine troubleshooting sub-items.

[0122] For example, in the specific implementation of iterative optimization of aero-engine test strategies, the system initiates a historical data review and strategy optimization process. First, it retrieves a fixed, preset historical time period from the backend to lock the statistical interval for this data analysis, avoiding interference from invalid, outdated data. Based on the defined time interval, the system automatically traverses the test handling archive database, batch-searches, filters, and summarizes all complete handling result records generated after the closure of all test tasks within that time period, forming a standardized historical dataset for strategy analysis. The system performs multi-dimensional feature extraction operations on the batch handling result records, classifies and statistically analyzes the cumulative trigger count and trigger ratio of each strategy based on the response rule identifier carried by each record, and generates corresponding strategy trigger frequency information. Simultaneously, the system extracts the strategy trigger timing data and handling closure timing data for each record, calculates the handling time of a single fault sequentially, batch-calculates the handling response time information corresponding to each strategy, and, based on the handling type identifier of all handling cases, classifies and statistically analyzes the quantity and ratio of routine handling and conflict coverage handling, forming complete handling type distribution information. After extracting multi-dimensional feature data, the system categorizes all test strategies into high-frequency triggering strategies and low-frequency triggering strategies based on built-in frequency thresholds. Simultaneously, it averages the processing time data from multiple batches for each strategy, removing extreme anomalies to determine the average response time for each strategy. Finally, the system integrates strategy triggering frequency characteristics, processing efficiency characteristics, and processing conflict distribution characteristics, combined with preset strategy optimization rules, to generate differentiated strategy optimization suggestions. For strategies with high-frequency false triggers, the system outputs optimization guidelines for fine-tuning trigger judgment thresholds and reducing strategy sensitivity; for strategies with high-frequency, real, high-risk faults and long processing times, the system outputs optimization guidelines for maintaining or increasing preset strategy levels and refining troubleshooting plans; for redundant strategies with long-term low-frequency triggers and no actual fault matching, the system outputs optimization guidelines for verifying strategy adaptability and simplifying redundant rules. The generated strategy optimization suggestions provide intuitive guidance for test personnel to iteratively adjust test strategies, enabling adaptive optimization of the test strategy system based on real historical operating data, continuously improving the accuracy of aero-engine test anomaly identification, the orderliness of fault handling, and the overall adaptability of the test strategy system.

[0123] Through the implementation of the above embodiments, information such as the frequency of strategy triggering, response time, and distribution of disposal types in the historical disposal result records are statistically analyzed. Based on the statistical results, strategy optimization suggestions are generated, so that a large amount of strategy execution data accumulated during equipment testing can be effectively utilized. When it is found that a certain strategy is triggered frequently, has a long response time, or has an unreasonable strategy level setting, the trigger judgment conditions or strategy level can be adjusted accordingly, thereby continuously optimizing the test strategy configuration, improving strategy triggering efficiency, and further reducing multi-strategy disposal conflicts, so that the test strategy can better adapt to the actual operating needs during equipment testing.

[0124] Furthermore, as an implementation of the aforementioned method embodiments, this application also provides an experimental strategy execution device for implementing the aforementioned method embodiments. This device embodiment corresponds to the aforementioned method embodiments. For ease of reading, this experimental strategy execution device embodiment will not repeat the details of the aforementioned method embodiments one by one, but it should be clear that the device in this application embodiment can correspondingly implement all the contents of the aforementioned method embodiments. Figure 2 As shown, the test strategy execution device 20 includes: a rule acquisition unit 201, a rule loading unit 202, a trigger judgment unit 203, a handling prompt unit 204, and a result generation unit 205. The rule acquisition unit 201 acquires the test strategy content arranged through a visual canvas and generates a rule file based on the aforementioned test strategy content. The test strategy content may include basic events, result events, and troubleshooting plans. Basic events define the trigger judgment conditions for abnormal test parameters, result events define the action information to be executed when the trigger judgment conditions are met, and troubleshooting plans define the fault handling guidance information corresponding to the trigger judgment conditions. The rule loading unit 202 distributes the rule file to the execution side to enable... The rule file is dynamically loaded into the strategy engine on the execution side; the trigger judgment unit 203 is used to match the real-time collected test parameters with the trigger conditions in the rule file through the rule engine and expression engine in the strategy engine to determine whether the test parameters meet the trigger conditions of the target strategy. The rule engine is used to interpret and execute the rule file and drive the rule matching process, and the expression engine is used to evaluate the trigger condition expressions in the rule file; the handling prompt unit 204 is used to arbitrate the target strategy based on the preset strategy level when it is determined that the target strategy has been triggered, so as to generate handling prompt information; the result generation unit 205 is used to generate a handling result record based on the handling confirmation instruction fed back to the handling prompt information.

[0125] In some embodiments, the rule acquisition unit 201 is further configured to, in response to an arrangement operation on a visualization canvas, acquire a first element set, a second element set, and a third element set, wherein the first element set includes a first triggering condition expression representing a basic event, the second element set includes action instruction information representing a result event, and the third element set includes a troubleshooting master table and troubleshooting sub-items representing a troubleshooting scheme; and acquire the association relationship established between the first element set, the second element set, and the third element set through canvas connections to obtain the experimental strategy content.

[0126] In some embodiments, the rule loading unit 202 is further configured to obtain a publishing instruction for the rule file and switch the status of the rule file from editing to published; in response to a revision instruction for the published rule file, generate a new version of the rule file based on the original rule file; or, in response to a version rollback instruction, determine the target historical version from the historical version record and republish the target historical version as the currently effective version; and when the rule file is in the published state, distribute the rule file to the execution side.

[0127] In some embodiments, the rule loading unit 202 is further configured to obtain test configuration information corresponding to the rule file, wherein the test configuration information includes the model identifier, test task identifier and engine identifier; based on the test configuration information, send the rule file to the strategy loading interface on the execution side; and load the rule file into the running strategy engine through the strategy loading interface in the form of data injection, so as to complete the update of the rule file without stopping the system.

[0128] In some embodiments, the triggering judgment unit 203 is further configured to convert the real-time collected test parameters into fact data objects and input the fact data objects into the rule engine; during the process of interpreting and executing the rule file, the rule engine determines the current trigger condition to be matched in the rule file; if the current trigger condition to be matched contains a preset expression, the rule engine calls the expression engine and controls the expression engine to perform evaluation operations on the preset expression to obtain the calculation result; the rule engine determines the matching status of the current trigger condition to be matched based on the calculation result and the fact data object, so as to determine whether the target strategy is triggered.

[0129] In some embodiments, the handling prompt unit 204 is further configured to obtain the first policy level of the triggered target policy and the second policy level of at least one policy currently in the handling execution state, wherein the policy in handling is a policy that has been triggered, a handling prompt has been generated, and a handling confirmation instruction has not yet been received; if the first policy level is higher than the second policy level, a first overriding instruction is generated, and the handling type of the target policy is determined to be normal processing, wherein the first overriding instruction is used to cancel the current handling process of the policy in handling and generate an overriding handling record, the overriding handling record including a high-level policy identifier and an overriding handling type identifier; and generate handling prompt information according to the troubleshooting plan and handling button configuration information corresponding to the target policy.

[0130] In some embodiments, the result generation unit 205 is further configured to obtain feedback operation data for the handling prompt information, wherein the feedback operation data includes the identifier of the triggered handling button; generate a handling confirmation instruction based on the feedback operation data; obtain the handling time, handling type identifier, and response rule identifier of this handling based on the handling confirmation instruction; and perform structured encapsulation of the handling time, handling type identifier, handling button identifier, and response rule identifier to generate a handling result record.

[0131] In some embodiments, the test strategy execution device 20 further includes a rule acquisition unit, configured to acquire multiple disposal result records generated within a preset historical time period; extract strategy trigger frequency information, disposal response duration information, and disposal type distribution information from the multiple disposal result records; determine high-frequency trigger strategies and low-frequency trigger strategies based on the strategy trigger frequency information; determine the average disposal response duration corresponding to each strategy based on the disposal response duration information; and generate strategy optimization suggestion information based on the high-frequency trigger strategy, low-frequency trigger strategy, and average disposal response duration, wherein the strategy optimization suggestion information is used to prompt the trigger judgment conditions or preset strategy level for adjusting the strategy.

[0132] This application also provides a computer-readable storage medium storing computer-executable instructions or a computer program that, when executed by a processor, will cause the processor to perform any step of the test strategy execution method provided in this application.

[0133] In some embodiments, the computer-readable storage medium may be a random access memory (RAM), a read-only memory (ROM), flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); or it may be a variety of devices that include one or any combination of the above-mentioned memories.

[0134] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0135] In some embodiments, computer-executable instructions may, but do not necessarily, correspond to files in a file system, and may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0136] In some embodiments, computer-executable instructions may be deployed to execute on an electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0137] like Figure 3 As shown, this application also provides an electronic device 30, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, it implements any step of the above-described test strategy execution method.

[0138] This application also provides a computer program product comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer program or computer-executable instructions from the computer-readable storage medium and executes the computer program or computer-executable instructions, causing the electronic device to perform any step of the test strategy execution method described above.

[0139] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for implementing an experimental strategy, characterized in that, include: The test strategy content arranged through a visual canvas is obtained, and a rule file is generated based on the test strategy content. The test strategy content includes basic events, result events, and troubleshooting solutions. The basic events are used to define the triggering conditions for abnormal test parameters. The result events are used to define the action information to be executed when the triggering conditions are met. The troubleshooting solutions are used to define the fault handling guidance information corresponding to the triggering conditions. The rule file is distributed to the execution side so that it can be dynamically loaded into the strategy engine on the execution side. The strategy engine uses a rule engine and an expression engine to match the real-time collected test parameters with the triggering conditions in the rule file to determine whether the test parameters meet the triggering conditions of the target strategy. The rule engine is used to interpret and execute the rule file and drive the rule matching process, and the expression engine is used to evaluate the triggering condition expressions in the rule file. When it is determined that the target policy is triggered, the target policy is arbitrated based on a preset policy level to generate a handling prompt message; Based on the processing confirmation instruction fed back from the processing prompt information, a processing result record is generated.

2. The method for implementing the experimental strategy according to claim 1, characterized in that, The acquisition of the experimental strategy content arranged through a visual canvas includes: In response to the arrangement operation on the visualization canvas, a first element set, a second element set, and a third element set are obtained, wherein the first element set includes a first trigger condition expression representing the basic event, the second element set includes action instruction information representing the result event, and the third element set includes a main table for troubleshooting and a sub-item for troubleshooting representing the troubleshooting scheme. The relationship between the first set of elements, the second set of elements, and the third set of elements is established through canvas connections to obtain the content of the experimental strategy.

3. The method for implementing the experimental strategy according to claim 1, characterized in that, The step of sending the rule file to the execution side includes: Obtain a publishing instruction for the rule file and switch the status of the rule file from editing to published. In response to a revision instruction for the published rule file, a new version of the rule file is generated based on the original rule file; or, in response to a version rollback instruction, a target historical version is determined from the historical version record, and the target historical version is republished as the currently effective version. When the rule file is in the published state, the rule file is sent to the execution side.

4. The method for implementing the experimental strategy according to claim 1, characterized in that, The step of distributing the rule file to the execution side so that the rule file is dynamically loaded into the policy engine on the execution side includes: Obtain the test configuration information corresponding to the rule file, wherein the test configuration information includes the aircraft type identifier, test task identifier, and engine identifier; Based on the test configuration information, the rule file is sent to the strategy loading interface on the execution side; The rule file is loaded into the running policy engine via the policy loading interface in a data injection manner, so as to update the rule file without stopping the system.

5. The method for implementing the experimental strategy according to claim 1, characterized in that, The step of matching and calculating the real-time collected test parameters with the triggering conditions in the rule file through the rule engine and expression engine in the strategy engine to determine whether the test parameters meet the triggering conditions of the target strategy includes: The real-time collected test parameters are converted into fact data objects, and the fact data objects are input into the rule engine; During the process of interpreting and executing the rule file, the rule engine determines the current triggering condition to be matched in the rule file; If the current trigger condition to be matched contains a preset expression, then the expression engine is called through the rule engine, and the expression engine is controlled to perform evaluation on the preset expression to obtain the calculation result; The rule engine determines the matching status of the current trigger condition based on the calculation result and the fact data object, in order to determine whether the target strategy is triggered.

6. The method for implementing the experimental strategy according to claim 1, characterized in that, The arbitration process based on a preset policy level to generate a processing prompt message for the target policy includes: Obtain the first policy level of the triggered target policy, and obtain the second policy level of at least one policy currently in the process execution state, wherein the policy in the process is a policy that has been triggered, has generated a process prompt, and has not yet received a process confirmation instruction. If the first policy level is higher than the second policy level, a first overriding instruction is generated, and the handling type of the target policy is determined to be normal processing. The first overriding instruction is used to cancel the current handling process of the policy in the handling and generate an overriding handling record. The overriding handling record includes a high-level policy identifier and an overriding handling type identifier. Based on the troubleshooting plan and handling button configuration information corresponding to the target strategy, the handling prompt information is generated.

7. The method for implementing the experimental strategy according to claim 1, characterized in that, The step of generating a handling result record based on the handling confirmation instruction fed back from the handling prompt information includes: Obtain feedback operation data in response to the handling prompt information, wherein the feedback operation data includes the identifier of the triggered handling button; The disposal confirmation instruction is generated based on the feedback operation data; Based on the disposal confirmation instruction, obtain the disposal time, disposal type identifier, and response rule identifier for this disposal. The processing time, processing type identifier, processing button identifier, and response rule identifier are structured and encapsulated to generate the processing result record.

8. The method for implementing the test strategy according to any one of claims 1 to 7, characterized in that, The method for implementing the experimental strategy also includes: Retrieve multiple records of processing results generated within a preset historical time period; Extract strategy trigger frequency information, response duration information, and response type distribution information from the multiple response result records; Based on the trigger frequency information of the strategy, high-frequency trigger strategy and low-frequency trigger strategy are determined; Based on the aforementioned response time information, the average response time for each strategy is determined. Based on the high-frequency triggering strategy, the low-frequency triggering strategy, and the average handling response time, strategy optimization suggestion information is generated, wherein the strategy optimization suggestion information is used to prompt the triggering judgment conditions or preset strategy level for adjusting the strategy.

9. A test strategy execution device, characterized in that, include: The rule acquisition unit is used to acquire the test strategy content arranged through a visual canvas and generate a rule file based on the test strategy content. The test strategy content includes basic events, result events, and troubleshooting solutions. The basic events are used to define the triggering conditions for abnormal test parameters. The result events are used to define the action information to be executed when the triggering conditions are met. The troubleshooting solutions are used to define the fault handling guidance information corresponding to the triggering conditions. The rule loading unit is used to distribute the rule file to the execution side so that the rule file is dynamically loaded into the strategy engine on the execution side. The trigger judgment unit is used to perform matching calculations between the real-time collected test parameters and the trigger conditions in the rule file through the rule engine and expression engine in the strategy engine, so as to determine whether the test parameters meet the trigger conditions of the target strategy. The rule engine is used to interpret and execute the rule file and drive the rule matching process, and the expression engine is used to evaluate the trigger condition expression in the rule file. The handling prompt unit is used to arbitrate the target policy based on a preset policy level when it is determined that the target policy has been triggered, so as to generate handling prompt information. The result generation unit is used to generate a processing result record based on the processing confirmation instruction fed back from the processing prompt information.

10. An electronic device, comprising: A memory and a processor, characterized in that the processor, when executing a computer program stored in the memory, implements the steps of the test strategy execution method as described in any one of claims 1 to 8.

Images