Aircraft operation monitoring method, system, equipment, medium and program product

Abstract

The invention provides an aircraft operation monitoring method, system and device, a medium and a program product. The method comprises the following steps: constructing a monitoring specification for real-time monitoring of an aircraft operation state based on a streaming specification language; generating a high-order intermediate representation based on the monitoring specification, and converting the high-order intermediate representation into a low-order intermediate representation; compiling the low-order intermediate representation into a hardware description language code, and deploying the hardware description language code in a programmable logic device in an aircraft to construct a monitor with parallel processing capability; creating a monitor instance for the monitor by loading the configuration file represented by the low-order middle, and starting the monitor instance; and the monitor instance receives the real-time data flow of the sensor in the operation process of the aircraft, executes real-time monitoring logic judgment, and outputs a monitoring result when a preset condition is met. According to the method, formalized modeling and hardware-level parallel execution of the complex flight monitoring rule are realized, and the real-time performance, the resource controllability and the multi-scene adaptation capability of the system are improved.

Description

Technical Field

[0001] This application relates to the field of flight safety technology for avionics systems, and in particular to an aircraft operation monitoring method, system, equipment, medium, and program product. Background Technology

[0002] With the rapid development of unmanned autonomous aerial vehicles (UAVs) in logistics, surveying and mapping, and emergency rescue, the complexity of flight missions and the uncertainty of the environment are constantly increasing, placing higher demands on the safety of aircraft operations. To ensure flight safety, aircraft need to continuously monitor multi-source sensor data (such as satellite positioning, inertial measurement, altimeter, attitude sensors, etc.) collected during operation to identify potential risks such as yaw, boundary violations, abnormal attitude, or control failure.

[0003] Currently, existing aircraft operational status monitoring technologies mainly fall into the following two categories:

[0004] Safety verification methods based on offline simulation: These methods verify the flight control logic or fault conditions before mission execution using predefined scenarios or test cases. However, these methods struggle to cover sudden sensor anomalies or unexpected environmental interference that may occur during flight, and cannot address dynamic risks during runtime.

[0005] Real-time alarm mechanisms based on fixed thresholds: These mechanisms use simple threshold judgments to monitor key indicators and trigger alarms when they exceed preset values. However, this mechanism lacks the ability to model complex operating conditions, temporal consistency between sensors, or correlation characteristics, making it prone to false alarms or missed alarms.

[0006] The aforementioned existing technologies suffer from problems such as insufficient real-time performance and limited expressive power in practical applications. In addition, existing technologies typically use general-purpose processors to implement monitoring functions, which suffer from problems such as low parallel processing efficiency and high power consumption, making it difficult to meet the stringent requirements of aircraft for lightweight and low-power hardware.

[0007] Therefore, there is an urgent need for an aircraft operation monitoring method that can perform highly expressive modeling under resource-constrained conditions and complete real-time monitoring and judgment in a low-latency and low-overhead manner. Summary of the Invention

[0008] To address the shortcomings of existing technologies, this application provides an aircraft operation monitoring method, system, device, medium, and program product, which at least solves the problems of weak monitoring rule expression capabilities, insufficient real-time performance, and uncontrollable resource consumption in existing technologies, making them difficult to deploy efficiently in confined aircraft environments.

[0009] To achieve the above objectives and other advantages, some embodiments of this application provide the following aspects:

[0010] In a first aspect, some embodiments of this application provide an aircraft operation monitoring method, including:

[0011] A monitoring specification for real-time monitoring of aircraft operational status is constructed based on a streaming specification language. The monitoring specification includes: geofence boundary detection rules, sensor data validity verification rules, multi-source sensor data consistency verification rules, control status anomaly identification rules, and trigger response rules.

[0012] A higher-order intermediate representation is generated based on the monitoring specification. The higher-order intermediate representation expresses the descriptive meta-information of the monitoring specification in a structured manner. The descriptive meta-information includes: the semantic logic, syntax structure, data type information, inter-stream dependencies, and sliding window parameter configuration of the monitoring specification.

[0013] The higher-order intermediate representation is converted into a lower-order intermediate representation, which is used to structurally describe the scheduling semantics, evaluation rules and resource constraint information that can be mapped to hardware logic.

[0014] The low-order intermediate representation is compiled into hardware description language code and deployed in programmable logic devices in aircraft to build a monitor with parallel processing capabilities.

[0015] The monitor instance is created and started by loading the configuration file of the low-level intermediate representation;

[0016] The monitor instance receives real-time data streams from sensors during aircraft operation, performs real-time monitoring logic judgments, and outputs monitoring results when preset conditions are met.

[0017] Secondly, some embodiments of this application provide an aircraft operation monitoring system, including:

[0018] The monitoring specification construction module is used to construct monitoring specifications for real-time monitoring of aircraft operation status based on the streaming specification language. The monitoring specifications include: geofence boundary detection rules, sensor data validity verification rules, multi-source sensor data consistency verification rules, control status anomaly identification rules, and trigger response rules.

[0019] The intermediate representation generation module is used to generate a high-order intermediate representation according to the monitoring specification and convert the high-order intermediate representation into a low-order intermediate representation. The high-order intermediate representation structurally expresses the description meta-information of the monitoring specification. The description meta-information includes: semantic logic, syntax structure, data type information, inter-stream dependencies, and sliding window parameter configuration. The low-order intermediate representation is used to structurally describe the scheduling semantics, evaluation rules, and resource constraint information that can be mapped to hardware logic.

[0020] The code compilation and deployment module is used to compile the low-level intermediate representation into hardware description language code and deploy it in the programmable logic device in the aircraft to build a monitor with parallel processing capabilities.

[0021] The monitor instance management module is used to create and start a monitor instance by loading the configuration file of the low-level intermediate representation.

[0022] The data receiving and monitoring execution module is used to receive real-time data streams from sensors during aircraft operation by the monitor instance, perform real-time monitoring logic judgments, and output monitoring results when preset conditions are met.

[0023] Thirdly, some embodiments of this application also provide an electronic device, the electronic device comprising:

[0024] One or more processors; and a memory storing computer program instructions that, when executed, cause the processors to perform the aircraft operation monitoring method as described above.

[0025] Fourthly, some embodiments of this application also provide a computer-readable storage medium having a computer program and / or instructions stored thereon, which, when executed by a processor, implement the aircraft operation monitoring method as described above.

[0026] Fifthly, some embodiments of this application also provide a computer program product, including a computer program and / or instructions, which, when executed by a processor, implement the aircraft operation monitoring method as described above.

[0027] Compared with related technologies, the solution provided in this application significantly improves the expressive power and semantic integrity of rules by adopting a monitoring specification modeling and intermediate representation structure conversion mechanism based on a streaming specification language. It can formally describe complex flight safety conditions such as geofence crossing, data validity, multi-source data mismatch, and abnormal control states, overcoming the limitations of traditional threshold-based monitoring methods. By progressively converting the monitoring specification into high-order and low-order intermediate representations, and finally compiling it into hardware description language code for deployment in the aircraft's programmable logic devices, hardware-level acceleration and parallel scheduling of the monitoring logic are achieved, significantly improving runtime throughput and response speed, meeting the requirements for high real-time performance and high reliability in flight safety assurance. The low-order intermediate representation incorporates structured modeling of scheduling semantics, evaluation rules, and resource constraint information during generation, enabling the monitoring task to have predictable memory and computing resource boundaries, enhancing the system's controllability and stability in resource-constrained environments. By dynamically creating monitor instances, it supports flexible integration and decoupling deployment with the flight control system, making it suitable for various types of unmanned autonomous vehicles and operational monitoring platforms. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other implementation methods can be obtained based on these drawings without creative effort.

[0029] Figure 1 This is a flowchart illustrating an aircraft operation monitoring method provided in an embodiment of this application;

[0030] Figure 2 This is a schematic diagram of the flow-based aircraft operation monitoring process provided in an embodiment of this application;

[0031] Figure 3 This is a flowchart illustrating the process of constructing monitoring specifications based on the Flow Specification Language provided in an embodiment of this application;

[0032] Figure 4 This is a schematic diagram of the process for generating a high-order intermediate representation from the parsed monitoring specifications provided in an embodiment of this application;

[0033] Figure 5 This is a schematic diagram of the process of converting a high-order intermediate representation into a low-order intermediate representation provided in an embodiment of this application;

[0034] Figure 6 This is a schematic diagram of the logical framework of a monitor instance for real-time monitoring of aircraft operation provided in this application embodiment;

[0035] Figure 7 This is a schematic diagram of the structure of the aircraft operation monitoring system provided in the embodiments of this application;

[0036] Figure 8 This is a logical diagram illustrating the monitoring specification modeling and compilation process in the aircraft operation monitoring method provided in this application embodiment;

[0037] Figure 9 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0039] First Embodiment

[0040] The first embodiment of this application relates to an aircraft operation monitoring method, referring to... Figure 1 As shown, the method may include the following steps:

[0041] Step S1: Construct monitoring specifications for real-time monitoring of aircraft operation status based on streaming specification language. The monitoring specifications include: geofence boundary detection rules, sensor data validity verification rules, multi-source sensor data consistency verification rules, control status anomaly identification rules, and trigger response rules.

[0042] Specifically, regarding step S1, the Streaming Specification Language is a modeling language used to define data stream monitoring rules in a structured manner. It supports logical expression, condition evaluation, and event-triggered modeling of sensor data streams received during aircraft operation. This language features static semantics, a time-driven mechanism, and data type constraints, making it suitable for deploying real-time monitoring logic in resource-constrained embedded systems. The Streaming Specification Language can adopt JSON-like, SQL-like, or dedicated DSL (Domain-Specific Language) formats to describe input streams, output streams, expression definitions, and triggering rules.

[0043] like Figure 2 The aircraft operation is shown as a flow-based monitoring flow direction. Based on the aircraft's mission requirements, safety policies, and sensor configuration, a flow-based specification language is used for structured definition to build a complete monitoring specification.

[0044] The monitoring specifications include, but are not limited to, the following five types of structured rules:

[0045] Geofencing boundary detection rules: These rules define the airspace range within which aircraft are permitted to fly during mission execution. The rules include spatial descriptions of flight boundaries, supporting geofence modeling using polygon point sets, circular regions, and 3D envelopes. The system compares the current location information with the boundary model in real time. Once an aircraft is detected exceeding the preset flight boundary, it is considered a risk of overstepping the boundary and triggers the corresponding safety response process.

[0046] Sensor data validity verification rules: These rules are used to independently verify the quality of basic data from various flight sensors to determine if there are issues such as signal failure, abnormal update frequency, or invalid values. These rules may include: statistically analyzing the update frequency of satellite positioning modules to determine if the number of updates per unit time is below a preset threshold; integrating the acceleration data of inertial measurement units to estimate whether the position result deviates from the expected trajectory; and performing non-negativity or range validity checks on data from sensors such as altimeters. These rules help identify sensor failures or drift malfunctions independently of other sensors.

[0047] Multi-source sensor data consistency verification rules: These rules are used to verify the consistency of data from multiple sensors configured on an aircraft, thereby improving the system's ability to identify sensor faults or data anomalies. These rules can logically compare and analyze the position, velocity, attitude, and other state parameters calculated from different information sources (such as GPS modules and inertial measurement units, IMUs). If the measurement results from any group of sensors show a deviation exceeding a set threshold or an abnormal correlation, the system can determine that the sensor has drift, fault, or signal failure issues, thereby generating a consistency alarm signal.

[0048] Control State Anomaly Identification Rules: These rules are used to perform logical judgments and anomaly detection on key dynamic parameters in the aircraft's flight control state. These rules support the definition of various criteria, such as sudden changes in flight speed, altitude exceedance detection, and severe attitude angle fluctuations, enabling early responses to whether the flight control system exhibits execution anomalies, control hysteresis, or rapid deviations.

[0049] Trigger Response Rules: These rules define the triggering mechanisms for various anomaly detection results, along with the corresponding alarm signal types and levels (e.g., general, severe, emergency), and configure corresponding response actions, such as logging, operation prompts, automatic return to base, and system restart. These rules form the basis for the automated execution of monitoring actions and can be integrated with the flight control system to achieve event-driven safety policy deployment.

[0050] Step S2: Generate a higher-order intermediate representation based on the monitoring specification. The higher-order intermediate representation expresses the description meta-information of the monitoring specification in a structured way. The description meta-information includes: the semantic logic, syntax structure, data type information, inter-stream dependencies, and sliding window parameter configuration of the monitoring specification.

[0051] Specifically, in step S2, the monitoring specification written using the streaming specification language is parsed and processed, including lexical analysis, syntax analysis, name resolution, and type inference, to generate a high-level intermediate representation (HIR) for structured modeling. This HIR is used to express the key descriptive meta-information in the monitoring specification, which includes, but is not limited to, the following:

[0052] Semantic logic: Unify and abstract Boolean expressions, logical judgments, comparison conditions and triggering mechanisms in the monitoring specifications, and construct an analyzable semantic graph structure;

[0053] Syntax structure: Records the nesting level and syntax organization of input streams, output streams, and expression nodes in the monitoring specification for subsequent structured mapping;

[0054] Data type information: Determine the data type of the input stream data, variables and constants involved in the expression;

[0055] Inter-stream dependencies: Identify the reading, aggregation, and triggering relationships between input and output streams, and construct a dependency structure graph to guide the division of scheduling levels;

[0056] Sliding window parameter configuration: Extract window expressions related to time / events and record parameters such as window width, sliding step size, and alignment to support historical state aggregation and trend analysis in streaming monitoring logic.

[0057] Step S3: Convert the high-order intermediate representation into a low-order intermediate representation. The low-order intermediate representation is used to structurally describe the scheduling semantics, evaluation rules, and resource constraint information that can be mapped to hardware logic.

[0058] Specifically, for step S3, based on the generated high-level intermediate representation, a structural degradation and semantic mapping process is performed to transform it into a low-level intermediate representation (LIR) that is closer to runtime scheduling and hardware deployment. This low-level intermediate representation describes the schedulable units, computational expressions, and resource requirements in the monitoring logic in a structured manner, including but not limited to the following:

[0059] Scheduling semantics: All input streams, output streams and their associated expressions defined in the higher-order intermediate representation are divided into event-driven streams and time-driven streams according to their execution methods.

[0060] Evaluation rules: The evaluation rules for each executable stream (such as output stream, trigger stream) are defined in a structured manner, including: the generation conditions of the stream, the specific expression evaluation logic of the stream when it is triggered, and the termination conditions of the stream.

[0061] Resource constraint information: Multiple types of resource boundary parameters are embedded to ensure that the generated monitor has controllable resource consumption characteristics at runtime, including boundary parameters such as memory buffer boundaries, window structure, instance binding, and inter-stream dependencies.

[0062] Step S4: Compile the low-level intermediate representation into hardware description language code and deploy it in the programmable logic device in the aircraft to build a monitor with parallel processing capabilities.

[0063] Specifically, in step S4, a predefined code generator is used to convert the low-level intermediate representation into Hardware Description Language (HDL) code. The HDL code can be in VHDL or Verilog form and has the characteristic of directly mapping to digital circuit logic. During compilation, the system first parses the dependencies between each input and output stream, and automatically generates the corresponding scheduling logic and data paths based on the time-driven and event-driven mechanisms described in the low-level intermediate representation. Subsequently, the system constructs corresponding combinational logic and timing control modules for monitoring logic such as sliding windows, expression evaluation, and trigger condition determination. The generated HDL code can be input into an FPGA synthesis tool for logic synthesis, placement and routing, and bitstream generation, and finally deployed to pre-set programmable logic devices in the aircraft, such as FPGAs or CPLDs. After deployment, the monitor composed of programmable logic devices can operate independently during flight. In terms of functionality, the monitor supports using multiple input ports (such as analog and digital signals) as parallel event trigger sources to achieve collaborative monitoring of complex conditions; its output supports generating various response forms, including alarm signals, action trigger commands, or status report information, to achieve high-speed parallel processing of sensor data and real-time alarm output.

[0064] Step S5: Create a monitor instance by loading the configuration file of the low-level intermediate representation and start it.

[0065] Specifically, in step S5, a monitor instance is constructed by loading the configuration file (including variable binding, sensor channel mapping, and runtime parameters) corresponding to the low-level intermediate representation. During instance creation, core functional modules, including an event manager, a time manager, and an evaluator, are built. These modules are capable of initializing according to the configuration and entering the running state, and have the ability to process asynchronous sampling data and execute multiple monitoring tasks.

[0066] The monitor can be directly attached to the aircraft's internal data bus and acquire real-time data streams from sensors during flight via bypass monitoring, without modifying the data publishing path of the main flight control system. This enables non-intrusive acquisition and monitoring of input data. This bypass deployment architecture allows for independent operation without affecting core flight control tasks, ensuring decoupling between the main control system and the monitoring system.

[0067] In a hardware deployment environment, multiple monitoring specifications can be compiled into independent, parallel execution logic units, and uniformly loaded into the same monitor instance for execution, supporting concurrent analysis of multi-channel data and low-latency response capabilities. Furthermore, the monitor instance enters a continuously running state upon startup, supporting runtime rule hot updates and instance management.

[0068] Step S6: The monitor instance receives the real-time data stream from the sensors during aircraft operation, performs real-time monitoring logic judgment, and outputs the monitoring results when the preset conditions are met.

[0069] Specifically, regarding step S6, after the monitor instance starts, its internal event manager establishes multiple input channels to receive real-time data streams collected by various sensors during flight, including but not limited to: satellite positioning data, inertial measurement unit data, altimeter data, attitude angle information, and flight control status variables. Based on the loaded monitoring specification logic and evaluation strategy, the monitor instance continuously processes and dynamically monitors the input data according to an event-driven and periodic scheduling mechanism. The monitoring logic's judgment process includes, but is not limited to: determining whether the current flight position is out of bounds; detecting whether there are deviations or mismatches in multi-source sensor data; identifying whether there are sudden anomalies, rapid changes, or unstable trends in the control status; and assessing whether trigger response conditions are met, such as reporting or active intervention. When any rule meets the preset trigger conditions, the monitor immediately generates the corresponding monitoring result and feeds it back to the flight control system or ground monitoring center through a specific interface. The monitoring result may include anomaly alarm flags, safety status codes, automatic control suggestions, or flight interruption commands.

[0070] Compared with related technologies, the solution provided in this application significantly improves the expressive power and semantic integrity of rules by adopting a monitoring specification modeling and intermediate representation structure conversion mechanism based on a streaming specification language. It can formally describe complex flight safety conditions such as geofence crossing, data validity, multi-source data mismatch, and abnormal control states, overcoming the limitations of traditional threshold-based monitoring methods. By progressively converting the monitoring specification into high-order and low-order intermediate representations, and finally compiling it into hardware description language code for deployment in the aircraft's programmable logic devices, hardware-level acceleration and parallel scheduling of the monitoring logic are achieved, significantly improving runtime throughput and response speed, meeting the requirements for high real-time performance and high reliability in flight safety assurance. The low-order intermediate representation incorporates structured modeling of scheduling semantics, evaluation rules, and resource constraint information during generation, enabling the monitoring task to have predictable memory and computing resource boundaries, enhancing the system's controllability and stability in resource-constrained environments. By dynamically creating monitor instances, it supports flexible integration and decoupling deployment with the flight control system, making it suitable for various types of unmanned autonomous vehicles and operational monitoring platforms.

[0071] Second Embodiment

[0072] The second embodiment of this application relates to an aircraft operation monitoring method. The second embodiment is an improvement upon the first embodiment, as described below. Figure 3 As shown, the specific improvement lies in providing a concrete implementation method for defining input stream, output stream, and trigger stream based on a flow modeling mechanism. Specifically, step S1 can further include the following steps:

[0073] Step S101: Model the operational data from the sensors on board the aircraft into multiple input streams, each representing a key flight parameter, for continuous sampling and representation of the aircraft's operational status.

[0074] In this step, the system defines corresponding input data streams based on the data output characteristics of various sensors on board the aircraft (such as GPS modules, IMU inertial measurement units, altimeters, etc.). Each input stream represents a key flight status parameter and has the capability to update in real time, reflecting changes in the aircraft's operational status.

[0075] The following is an example of a monitoring standard for aircraft in the face of static intrusion:

[0076] import math

[0077] input lat:Float

[0078] input lon:Float

[0079] constant intruder_lat:Float:=123.743

[0080] constant intruder_lon:Float:=132.222

[0081] output distance:Float:=sqrt((intruder_lat-lat)**2.0+(intruder_lon-lon)**2.0)

[0082] output closer:Bool:=distance.offset(by:-1).defaults(to:distance)>=distance

[0083] trigger closer&&distance<0.1"Too close to the intruder"

[0084] To detect whether a target is too close to the coordinates of a static intruder, an operational status monitoring specification based on fixed-location coordinates was constructed using a structured streaming specification language. Here, `lat` and `lon` are defined as input streams, representing the latitude and longitude coordinates of the aircraft's current position, respectively. This input stream originates from the aircraft's onboard GPS sensor module, used to continuously sample and characterize its geographical location. `intruder_lat` and `intruder_lon` are constants, representing the known fixed position of the static intruder in space. These input streams and constants constitute the basic data source of this operational status monitoring specification; subsequent output streams and triggering logic all depend on the evolution of its real-time data.

[0085] Step S102: Construct an output stream based on the input stream. The output stream is used to perform real-time calculation and processing on the sensor data carried in the input stream to form a data expression that reflects the aircraft's operating status. The output stream includes an event-triggered output stream and an output stream based on fixed-period scheduling.

[0086] In this step, taking the monitoring scenario of an aircraft facing a static intrusion as an example, the input streams `lat` and `lon` are defined to represent the aircraft's current GPS latitude and longitude information, respectively, while the input streams `intruder_lat` and `intruder_lon` represent the spatial positioning coordinates of the external target (such as a stationary intruder). Based on this, an output stream `distance` is constructed to calculate the Euclidean distance between the aircraft's current position and the intruder in real time. Further, an output stream `closer` is constructed. This stream compares the distance values ​​at the current moment with those at the previous moment using an offset function to determine whether the aircraft is gradually approaching the intruder, thereby capturing potential threat trends. Since the `closer` expression is a Boolean logical judgment, when the `closer` output is true and the current distance is less than a preset safety threshold (e.g., 0.1 km), the monitor will trigger an "too close to the intruder" alarm signal to support the flight control system in making timely avoidance decisions or risk responses. This type of output stream and triggering mechanism uses an event-driven scheduling approach, eliminating the need for fixed-time polling. It can quickly assess and react when critical events occur, exhibiting good real-time performance and computational efficiency.

[0087] Based on the constructed input stream data, multiple output streams are built using computational methods such as sliding window averaging, integral accumulation, and local statistical feature extraction to express the dynamic behavioral characteristics of the aircraft during flight. The output streams, as intermediate variables in the monitoring logic, carry core computational tasks such as flight boundary judgment, sensor consistency analysis, and state fluctuation identification, forming the basis for triggering monitor responses and alarms.

[0088] It should be noted that if the monitoring specifications mandate synchronous updates for all input streams, then if any sensor experiences delays or missing data, the computation of the entire output stream will be delayed or fail, weakening the system's real-time performance and stability. Therefore, this embodiment does not mandate that all input streams have a uniform sampling frequency or strict synchronization during output stream construction. Different input streams can independently generate new values ​​at any given time. When an input stream experiences a sudden change (such as a sudden burst or temporary interruption of GPS sensor data), it may cause the dependent output streams to be frequently or abnormally evaluated, leading to a sudden increase in system load and affecting overall response performance. To mitigate these problems and enhance the adaptability of the monitoring system, this embodiment divides the output streams into two categories based on scheduling methods: event-triggered output streams and output streams based on fixed-period scheduling.

[0089] Event-triggered output streams refer to output streams that are scheduled using an event-driven processing mechanism, meaning that related computational operations are triggered only when a specific event occurs. Specific events include, but are not limited to: the arrival of a new value in an input stream, the fulfillment of a certain state change condition, or the realization of a specific logical judgment. Taking an aircraft dynamic intruder monitoring scenario as an example, if the location information of the aircraft or intruder changes, the distance and closer output streams will trigger real-time evaluation to ensure timely response to important state changes.

[0090] For example, the following is an example of a monitoring standard for aircraft facing dynamic intrusions:

[0091]

[0092] It should be noted that under synchronous settings, all input streams (such as the GPS coordinates of the aircraft and the intruder) can receive new values ​​simultaneously at the same time, thereby triggering the evaluation of dependent output streams (such as the distance stream). However, in practical applications, the intruder and the aircraft are controlled independently by different systems, and their sensor sampling frequencies and data transmission paths may be asynchronous. Therefore, the updates of input stream values ​​are often asynchronous and non-periodic. In this case, if the default event-driven mechanism that requires all dependent inputs to be updated simultaneously is still used, the output stream will not be able to trigger calculations for most of the time, thus losing key state changes and failing to meet the real-time and continuous requirements of flight safety monitoring. Considering that the above input streams are all asynchronously generated new values, at some times only some input streams may change. If the default synchronous calculation logic is still used, the evaluation process of the distance stream may not be triggered due to incomplete inputs, thus losing the ability to continuously perceive state evolution. To solve this problem, this application introduces a reserved value reference mechanism in the construction of the output stream.

[0093] The reserved value referencing mechanism is implemented by introducing the `hold()` method into the computational expression of the output stream. This method allows the latest available value of the input stream to be automatically referenced when calculating the output stream expression, without requiring the input stream to be updated simultaneously at the current computation moment. For example, in the above process of calculating the distance between the aircraft and the dynamic intruder, if only the aircraft's own GPS coordinates (lat, lon streams) change at the current moment, while the intruder's coordinates (intruder_lat, intruder_lon streams) have not been updated in time, the system automatically calls the latest historical values ​​of the intruder_lat and intruder_lon streams to participate in the calculation, without hindering the evaluation process due to missing input data. Similarly, if only the intruder's coordinates are updated and the aircraft's own coordinates have not yet generated new values, the historical values ​​of the aircraft's GPS position stream can also be called to continue calculating the distance stream.

[0094] It should be noted that the retained value referencing mechanism is not limited to referencing the input value from the previous moment, but flexibly adopts the most recently generated new value from the input stream, which may come from a previous point in time or even earlier. This design significantly enhances the adaptability and fault tolerance of the monitoring specification to asynchronous, multi-source input data environments, ensuring the continuous availability and robustness of the output stream computation logic. Furthermore, if the system has just started running and an input stream has not yet generated any historical values, the `hold()` method will have no historical data available at that moment. To avoid computational anomalies, this embodiment sets a default initial value (such as 0.0 or 1.0) within the `hold()` method, filling in the initial value during the initial evaluation to ensure computational continuity. This mechanism ensures that the system can robustly adapt to differences in input data update rhythms from initial operation to stable monitoring, continuously and effectively evaluating and responding to the aircraft's operational status in real time.

[0095] It is also important to emphasize that the calculation and evaluation of the distance stream is not forcibly bound to the update event of a specific input stream; that is, its calculation triggering logic is decoupled from the data update rhythm of the input stream. In other words, even if the input stream data is updated, the distance stream may not necessarily trigger calculation immediately, but rather requires the satisfaction of a predefined specific activation condition to be calculated. To explicitly control when the distance stream is evaluated (i.e., generating a new value), this application introduces an activation condition control mechanism in the output stream definition, using the symbol "@" before the stream definition expression, followed by a Boolean expression to declare the specific triggering condition. For example, in the above dynamic intruder monitoring scenario, the activation condition of the distance stream is defined as: @((intruder_lat

[0096] The activation condition `&&intruder_lon)||(lat&&lon)` explicitly states that the distance stream will only be recalculated if either the intruder's coordinate input stream (`intruder_lat` and `intruder_lon`) or the aircraft's own position coordinate input stream (`lat` and `lon`) is updated. This activation condition ensures that the system only performs the corresponding calculation when the position information of the aircraft or the intruder actually changes, potentially causing an update in the distance between them. This effectively avoids unnecessary computational overhead caused by updates to irrelevant input stream data, reduces monitor resource consumption, and further improves operational efficiency.

[0097] This embodiment also introduces a fixed-period scheduling-based output stream (i.e., a periodic stream) during the output stream construction process. Unlike event-triggered output streams, periodic streams do not directly depend on the update event of a certain input stream, but actively evaluate the corresponding stream expression according to a preset fixed frequency or time period. For example, in a monitoring scenario of an aircraft facing dynamic intrusion, the trigger stream is defined as a periodic stream. The above definition means that the trigger stream actively performs a logical judgment once per second (i.e., at a frequency of 1Hz). During each evaluation, the system checks whether the state of the closer output stream has been continuously true (i.e., continuously approaching) in the past 5 seconds, and at the same time determines whether the current distance is less than a set threshold (e.g., 0.1 meters) to determine whether the aircraft and the intruder are at a dangerous distance.

[0098] By dividing the output stream into event-triggered and periodically scheduled output streams, the aircraft runtime monitoring specifications can better adapt to the asynchronous nature of multi-source sensor data input during flight. Specifically, event-triggered output streams are suitable for timely responses to high-frequency or sudden events such as GPS data changes and sudden attitude anomalies, possessing high processing immediacy and rapid alarm capabilities. Periodically scheduled output streams, on the other hand, can continuously and proactively evaluate key monitoring indicators even when input events are missing or the aircraft is in a stable flight state, effectively preventing monitoring blind spots caused by temporary interruptions in sensor data or delays in input stream updates. This dual-mode output stream design enables the monitoring system to maintain high real-time responsiveness while achieving reasonable resource allocation and balanced scheduling of computational load, avoiding unnecessary redundant computational overhead. In application scenarios with complex flight missions, heterogeneous sensor deployments, and inconsistent data update frequencies, this mechanism can significantly improve the continuity, robustness, and stability of flight status monitoring.

[0099] Step S103: Construct a trigger stream based on the output stream. The trigger stream is used to formally express the rule logic defined in the monitoring specification as executable trigger conditions, and to monitor the characteristic data reflecting the aircraft's operating status in the output stream. When the set trigger conditions are met, the corresponding response action is output.

[0100] In this step, based on the triggering conditions corresponding to various output streams defined in the monitoring specifications, the system promptly generates corresponding response actions when the aircraft's operational status becomes abnormal or at risk. For example, when the rate of change of aircraft speed calculated by the output stream exceeds a preset threshold, the system triggers a speed anomaly alarm; similarly, when the deviation between the GPS position evaluated by the output stream and the position calculated by the inertial measurement unit exceeds the allowable range, the system automatically triggers a sensor fault or data anomaly warning.

[0101] Furthermore, corresponding calculation expressions are defined for the output stream and trigger stream to form a monitoring stream. These calculation expressions include arithmetic operation expressions, window aggregation expressions, or logical judgment expressions. The monitoring stream performs lifecycle management based on preset control statements. Lifecycle management includes:

[0102] The generation phase is used to dynamically create monitoring stream instances when the set activation conditions are met.

[0103] The evaluation phase is used to execute the computational logic defined in the monitoring stream instance according to the set clock frequency or input event triggering conditions;

[0104] The shutdown phase is used to release the monitoring stream instance when the set termination conditions are met.

[0105] Specifically, this embodiment, based on the construction of output streams and trigger streams, introduces monitoring stream instances as the basic execution unit for runtime monitoring tasks. Each monitoring stream instance has a clear lifecycle control mechanism, which includes three phases: the Spawn phase, the Eval phase, and the Close phase. These phases are formally described and scheduled for execution through preset control statements.

[0106] Spawn Phase: This phase defines the activation conditions for the monitoring stream. When the set conditions are met (such as the availability of input data), the system dynamically creates the corresponding monitoring stream instance and incorporates it into the scheduling management. For example, in a scenario of monitoring intruders, a distance stream for calculating the distance to the aircraft is only generated when both the intruder's latitude and longitude coordinates intruder_lat and intruder_lon are detected as valid, thus avoiding unnecessary resource consumption.

[0107] Evaluation Phase (Eval): This phase defines the evaluation frequency and calculation logic for the monitored stream. The system can drive the evaluation process based on a fixed beat (e.g., a frequency of 1 Hz) or a specific event (e.g., an update of the input stream value). When both the beat condition and the decision condition (i.e., the when expression) are met, the system reads the required input data and executes the corresponding calculation expression. For example, a distance decision expression can be calculated periodically, or numerical operations such as square root calculations can be performed when certain data streams change.

[0108] Close Phase: This phase defines the termination conditions for the monitoring stream. When the monitored target is no longer active or meets specific closure logic, the system automatically releases the corresponding stream instance and its related resources to avoid continuously occupying the computing channel. For example, if the auxiliary judgment stream stale indicates that the intruder information has not been updated within 10 seconds, the target can be considered invalid, and the system will automatically close the associated distance stream instance, thereby reducing resource consumption and improving overall system efficiency.

[0109] This lifecycle management mechanism is supported by three types of control statements at the syntax level:

[0110] spawn@PACING when CONDITION: Defines the activation condition for the monitoring stream instance;

[0111] `eval@PACING when CONDITION with EXPRESSION`: Defines the computation logic for the monitoring stream instance;

[0112] close@PACING when CONDITION: Defines the termination condition for the monitoring stream instance.

[0113] The PACING parameter can be a fixed period (e.g., @1Hz), an event-triggered event (e.g., @obs_x), or a composite event. CONDITION is a Boolean expression used to describe when a certain control logic is met. If the when condition is omitted, it defaults to when true, meaning it is always executed.

[0114] Furthermore, to achieve dynamic lifecycle management of monitoring streams, this embodiment introduces a runtime scheduling framework into the monitoring system for fine-grained control over the generation, evaluation, and closure processes of various monitoring streams during runtime. This scheduling framework combines a statically defined monitoring specification structure with dynamic event-driven triggering logic, supporting efficient scheduling and execution of necessary monitoring tasks in resource-constrained environments. Specifically, the system internally maintains a stream instance management table for lifecycle status maintenance and resource scheduling control of each monitoring stream instance. This management table uses a unique stream identifier as the index key and records, but is not limited to, the following metadata: current lifecycle status (inactive, activated, closed), recent activity timestamp, input snapshot version information, dependency count, etc. The table structure supports dynamic insertion, state switching, and resource reclamation, ensuring that the monitoring system only schedules active and necessary stream instances for computation during operation, thereby reducing resource consumption and improving response efficiency.

[0115] During the Spawn phase, the system listens for the activation conditions of the monitored stream based on the preset spawn control statement "spawn@PACING whenCONDITION". When the runtime detects that the dependent input data or timed event meets the trigger conditions, the scheduler creates the corresponding stream instance in the stream instance management table, completes the initialization of data structure configuration, including data window allocation, input dependency registration and initial state setting, and marks the instance as "activated", thus including it in the subsequent scheduling queue.

[0116] During the evaluation phase (Eval), the system adds active monitoring streams to the scheduling plan according to the tick frequency (PACING) or event-driven mechanism defined in the monitoring specification. When a tick is triggered, the system reads current and necessary historical data from the input buffer and determines whether to execute the specific expression logic based on the condition in "eval@PACING when CONDITION with EXPRESSION". If the condition is true, the calculation process is executed immediately, and the result is written to the output buffer. To improve evaluation efficiency, the evaluation scheduling adopts an incremental evaluation strategy and, based on the dependency graph structure in the intermediate representation, schedules only the activated stream nodes with ready dependencies, avoiding unnecessary duplicate calculations.

[0117] During the closing phase, the system checks whether each flow meets the predefined closing condition "close@PACING when CONDITION" through periodic polling or event triggering. Once the termination condition of a flow instance is detected to be met, the system immediately updates its lifecycle state to "closed," releases runtime resources associated with that instance, including cache windows, output buffers, and scheduling references, and removes its dependency edges from the scheduling topology graph to prevent unnecessary subsequent scheduling triggers. It should be noted that closing a monitored flow does not mean permanent deregistration. If the activation condition is subsequently met again, the system can regenerate the flow instance and re-add it to the scheduler, implementing an on-demand activation and lifecycle restart mechanism based on data and event states.

[0118] By introducing the aforementioned lifecycle-based monitoring stream management mechanism, the system can dynamically schedule and manage the status of monitoring streams during operation, avoiding continuous full calculations of all monitoring specifications, thereby significantly reducing the system's data processing burden and computing resource consumption. This mechanism is particularly suitable for application scenarios such as avionics systems, which have high requirements for power consumption, resource usage, and real-time response, effectively improving the overall system's operating efficiency and resource utilization. Furthermore, this mechanism significantly enhances the expressive power of the formal specification language, enabling monitoring specifications to have stronger runtime adaptability without increasing expressive complexity.

[0119] It is easy to see that in this embodiment, by adopting a three-layer modeling approach of "input stream – output stream – trigger stream" based on streaming canonical language, sensor data is structurally expressed and continuously sampled, achieving refined perception of aircraft operating status. By combining the use of two types of output streams based on event triggering and periodic scheduling, the monitoring system can stably monitor changes in status trends while ensuring real-time response, effectively avoiding monitoring blind spots. Furthermore, by using the trigger stream to formally model the rule logic, the system's ability to automatically identify complex flight safety conditions is significantly enhanced, thereby improving the reliability, stability, and response speed of aircraft operating status monitoring.

[0120] Third Embodiment

[0121] The third embodiment of this application relates to an aircraft operation monitoring method. The third embodiment is an improvement upon the first embodiment, specifically in that it provides a mechanism for static semantic modeling and dependency scheduling analysis of monitoring specifications, referring to... Figure 4 As shown, step S2 can further include the following steps:

[0122] Step S201: Perform abstract syntax tree parsing and naming analysis on the monitoring specifications, complete the structural validity verification and operator matching check of the expressions, perform inline expansion of constant items, and assign a unique number to each expression.

[0123] Specifically, the monitoring specification undergoes Abstract Syntax Tree (AST) parsing to extract structured syntactic units, and name analysis is performed to ensure the uniqueness and scope consistency of named entities. Named entities include, but are not limited to, input streams, output streams, trigger streams, windows, constants, and variables. Through name analysis, potential issues in the monitoring specification, such as duplicate names, undeclared usage, scope shadowing, or symbol conflicts, can be effectively identified and reported, ensuring that all symbol references within their respective contexts are resolvable and avoiding runtime errors.

[0124] Based on this, the structure of all expressions undergoes legality validation, including syntactic integrity, type matching of operators and operands, and compliance of function call parameters, ensuring that the expressions conform to the definition requirements of the Streaming Language specification in terms of formal structure. Any non-compliant expressions will be accurately identified and reported at this stage.

[0125] Furthermore, for constant items defined through "let statements" and other similar means, their values ​​will be inlined at this stage. This means that the actual value will replace the reference to the constant name in the expression, reducing indirect access during execution and improving the efficiency and determinism of expression calculation.

[0126] Finally, all expressions will be numbered and reorganized, and a unique identifier will be assigned to each expression to build a node index system in the intermediate representation structure. This system will be used for unified reference and traceability in processes such as building semantic dependency structure graphs, performing topology sorting, and generating scheduling order, ensuring the correctness, maintainability, and execution efficiency of the entire monitoring specification.

[0127] Step S202: Perform type analysis and semantic consistency verification on all stream definitions and expressions.

[0128] In this step, after the initial construction of the higher-order intermediate representation is completed, type analysis and semantic consistency verification are further performed to improve the security and reliability of the specification execution process. By calling type checking methods (such as check_types), a unified type inference and verification process is performed on all stream definitions, window operations, and expression structures.

[0129] Specifically, firstly, based on the relationship between the internal operational structure of the expression and the input stream it depends on, the system automatically deduces the type of its computation result and compares all involved sub-expressions with the types of input variables to ensure type compatibility. Simultaneously, it verifies whether the following semantic consistency conditions are met: the operands of the expression have an executable type relationship (e.g., Boolean operations cannot be used with floating-point types); the parameter types of all function calls are consistent with their definition signatures; and the operational structures used, such as aggregate functions and window functions, are valid and defined within the range of input data types.

[0130] If an expression is found to have an undefined type, type conflict, or unresolvable combination structure during type inference, the subsequent intermediate representation generation process will be terminated, and structured error information will be output to help developers quickly locate and fix type-related issues.

[0131] Step S203: Construct a dependency structure graph based on streams and expressions to represent the dependencies between data streams.

[0132] In this step, after completing the type analysis and semantic consistency verification of all flow definitions and expressions in the monitoring specification, the dependency analysis phase begins. By calling the dependency analysis module (such as the analyze_dependencies method), all flows and expressions in the higher-order intermediate representation are parsed item by item, and the corresponding dependency structure graph is constructed.

[0133] Specifically, the upstream input items that each output stream or intermediate expression depends on are identified, including elements such as the original input stream, constants, window expressions, and aggregator results, and a complete dependency graph structure is formed based on this. This dependency graph uses nodes to represent various data items and directed edges to represent dependencies, forming a Directed Acyclic Graph (DAG) to ensure that there are no circular dependencies or recursive definitions in the data processing flow. This graph structure not only clearly expresses the upstream and downstream propagation paths between monitoring expressions but also reveals potential cross-level and cross-window access behaviors in the specification. Simultaneously, potential logical loops are automatically detected and eliminated during the dependency graph construction process, avoiding semantic conflicts or runtime deadlocks caused by circular references between expressions. Through this step, a structured model of the data relationships within the monitoring specification is achieved, providing an efficient and parsable semantic foundation for monitor generation and runtime task scheduling.

[0134] Step S204: Perform topological sorting based on the dependency structure graph to determine the scheduling and execution order of each data stream.

[0135] In this step, after constructing the dependency structure graph for each data flow item in the monitoring specification, the next step is to determine the evaluation calculation order. By calling the topology sorting module (e.g., the `determine_evaluation_order` method), all flow definition and expression nodes are topologically sorted based on the aforementioned dependency structure graph, thereby establishing an execution order and scheduling hierarchy that satisfies dependency constraints. Through this topology sorting process, the system can clearly determine the evaluation order of each flow or expression, thus effectively controlling the computation timing and isolation between different data flows, which is particularly suitable for scenarios with mixed scheduling based on event triggering and fixed periods. Furthermore, during the topology sorting process, the system simultaneously identifies the specific generation conditions of each data flow and expression, clarifying its initialization and activation scenarios, further improving runtime scheduling efficiency and flexibility.

[0136] Step S205: Analyze the state caching requirements of each stream or expression at different scheduling stages to determine the minimum required memory capacity or cache window size.

[0137] In this step, by calling the state cache requirement module (e.g., the `determine_memory_bounds` method), a static analysis is performed on the memory resources required by each data stream and expression at different scheduling stages to determine its minimum cache window size and memory usage boundaries. Specifically, this step comprehensively analyzes historical data accesses used in the monitoring specifications (e.g., the `offset(by:-1)` operator), the width and step size settings of sliding and discrete windows, and the state dimensions of multi-instance aggregation operations to accurately calculate the memory requirements of each stream or expression during runtime. Through this analysis, the system can determine and constrain the memory usage of the monitoring logic before runtime, effectively avoiding insufficient runtime memory or resource contention, and significantly improving the safety and reliability of runtime resource scheduling.

[0138] It is easy to see that, in this embodiment, by performing abstract syntax tree parsing, naming analysis, type validation, dependency graph construction, topology sorting, and memory boundary deduction on the monitoring specifications, structural errors, type inconsistencies, and dependency conflicts in the specifications can be accurately identified before deployment, avoiding potential runtime failures. At the same time, by constructing a directed acyclic dependency graph and a scheduling order generated based on topology relationships, the system can efficiently and orderly execute various monitoring rules according to dependency logic during the runtime phase, improving the real-time performance and robustness of data processing. In addition, static deduction of the memory requirements of each expression further ensures the rationality and security of runtime resource configuration, reducing the risk of monitoring interruption caused by memory overflow or resource contention.

[0139] It should be noted that the third embodiment of this application may also be an improvement based on any one or more of the first to second embodiments.

[0140] Fourth embodiment

[0141] The fourth embodiment of this application relates to an aircraft operation monitoring method. The fourth embodiment is an improvement upon the first embodiment, specifically in that it provides a conversion mechanism based on a high-order intermediate representation to a low-order intermediate representation, referring to... Figure 5 As shown, step S3 can further include the following steps:

[0142] Step S301: Establish a stream reference mapping table to uniformly map each input stream and output stream defined in the higher-order intermediate representation to the reference number in the lower-order intermediate representation.

[0143] In this step, each stream entity has a clear declaration and identifier in the abstract syntax tree. All stream definition nodes in the abstract syntax tree are traversed, initiating a scan of all stream entities. Number counters are set for input and output streams respectively; for example, input streams are numbered sequentially starting from In(0), and output streams are numbered sequentially starting from Out(0). For each input and output stream definition, a mapping relationship is established between its name and its corresponding number, and written into a mapping table. The resulting StreamReference mapping table records all stream names and their corresponding unique number references in the low-level intermediate representation. This mapping table has the following key functions: First, all subsequent references to streams are expressed in numbered form, avoiding reference resolution errors caused by naming conflicts, unclear scope, etc.; second, through the numbered mapping table, a unified reference index system can be established between different semantic modules (such as expression evaluation, dependency analysis, and scheduling mapping), improving the accuracy of semantic checks; third, it ensures that all defined input and output streams are registered in the mapping table without omissions or duplications, providing a reliable data foundation for the conversion process of the low-level intermediate representation.

[0144] Step S302: Convert the attribute structure of each input stream into an input stream object in a low-level intermediate representation. The attribute structure includes: name, data type, accessed relation, aggregated relation, and memory constraint information.

[0145] In this step, based on the stream reference mapping table established in step S2021, the key attribute information of each input stream defined in the higher-order intermediate representation is extracted sequentially, and a structured input stream description object is constructed. This object includes at least the following fields: the name of the input stream and its corresponding data type (ty), used to identify the stream ontology and its data structure; accessed_by: used to record which output streams read the input stream, providing a basis for dependency construction; aggregated_by: marking whether the input stream participates in window aggregation or other aggregation function operations as input; memory constraint (memory_bound): indicating the size of the historical state window that the input stream needs to retain during runtime to support semantic requirements such as delayed access and offset reading.

[0146] This phase ensures that all input stream objects meet the strict ascending ordering requirement in terms of numbering and verifies the consistency and integrity constraints of all references.

[0147] Step S303: Convert the semantic structure of each output stream into an output stream object in a low-level intermediate representation. The semantic structure includes: scheduling conditions, access relationships, aggregation logic, memory constraints, parameter binding relationships, and type information used to control the lifecycle of the monitoring stream.

[0148] In this step, the semantic structure of each output stream is converted into output stream objects in a low-level intermediate representation. Since output streams typically have more complex runtime behavior and lifecycle control requirements, their semantic structure needs to be fine-grained decomposition and mapping during the conversion process to form a structured representation with scheduling and execution semantics. Specifically, this includes the following aspects:

[0149] Lifecycle control conditions: Extract and transform scheduling conditions used to control the spawning, evaling, and closing of output stream instances, including periodic triggering, event triggering, and context-dependent conditions;

[0150] Access relationships: Identify the upstream data streams that the current output stream depends on (accesses) and the relationships that are referenced by downstream streams (accessed_by), providing a basis for deriving scheduling order and memory boundaries;

[0151] Aggregation logic: Identify whether the output stream is used as a user of the aggregator or as an object being aggregated (aggregated_by, aggregateates), and record the relevant aggregation window and function configuration;

[0152] Memory constraints: Calculate the minimum required cache window size (memory_bound) based on the historical data accesses and window operations involved in the stream expression;

[0153] Parameter binding: Handles dynamic parameter mapping and context variable references involved in the output stream to ensure runtime binding consistency;

[0154] Type information: Inherited and recorded the final derivation type of the output stream expression, used for type validation and result constraints.

[0155] After the transformation, all output stream objects are uniformly sorted according to their numbering order in the StreamReference map, so that the runtime monitor's scheduling engine can establish a stable scheduling order accordingly.

[0156] Step S304: Classify each output stream according to its triggering mode, and construct corresponding scheduling substructures for periodic driven streams and event driven streams respectively.

[0157] In this step, all output streams are first traversed, and based on the trigger expressions contained in their definitions, it is determined whether the output stream belongs to the cycle-driven mode or the event-driven mode:

[0158] For periodically driven streams, the is_periodic method is called to identify their scheduling attributes and generate a corresponding periodic scheduling substructure, which includes parameters such as periodic expression, scheduling step size, and time offset, to drive the output stream to execute periodically within a fixed time interval.

[0159] For event-driven streams, the is_event method is called to extract their event triggering characteristics and construct an event scheduling substructure containing information such as triggering conditions and context reference relationships, which is used to support conditional activation based on changes in input data or running status events.

[0160] This classification process helps to configure appropriate schedulers for different types of output streams during system runtime, enabling efficient scheduling of computing resources and monitoring of tasks.

[0161] Step S305: Convert the windows defined in the higher-order intermediate representation into normalized window objects in the lower-order intermediate representation. The normalized window objects include discrete windows, sliding windows, and instance aggregation windows. All window objects are numbered and their order is verified.

[0162] In this step, the windows defined in the higher-order intermediate representation are converted into standardized window objects in the lower-order intermediate representation. Standardized window objects include discrete windows, sliding windows, and instance aggregation windows. Specifically, all window operations explicitly declared in the monitoring specification are first traversed, and then categorized and structurally transformed according to their window types:

[0163] For discrete windows, extract their bound semantic elements such as stream identifier, dimension type, and closing condition expression, and map them into a standardized discrete window structure;

[0164] For a sliding window, its window width, sliding step size, alignment strategy and other parameters are degraded and transformed to form a sliding window object with a clear structure.

[0165] For instance aggregation windows, extract their multi-instance label identifiers, window binding rules, and aggregation logic definitions to support independent aggregation operations between concurrent instances.

[0166] After the conversion is completed, the system performs a unified numbering operation on all window objects to ensure that they have continuous numbering indices in the low-level intermediate representation, and further performs sequence consistency verification to provide a foundation for subsequent window trigger management and multi-window concurrent scheduling.

[0167] Step S306: Extract the trigger information defined in the event-driven output stream and construct the trigger object in the low-level intermediate representation. The trigger object includes a unique number and the reference number of the bound output stream.

[0168] In this step, after classifying the output streams, all output stream definitions marked as trigger types are further extracted, and a corresponding low-level intermediate representation trigger object is generated for each trigger. Each trigger object contains a unique identifier within the system and its bound output stream reference number, used to clarify the association between the trigger source and the response action. The construction of this trigger structure enables the system to support event-driven monitoring behavior and response scheduling, providing a structured triggering mechanism to support anomaly detection and status alarms in aircraft operations.

[0169] Step S307: Convert the global tag information defined in the higher-order intermediate representation into structured tag items in the lower-order intermediate representation. The structured tag items are represented in key-value pairs.

[0170] In this step, all explicitly declared tag items within the global scope are extracted from the higher-order intermediate representation and uniformly converted into structured tag objects in the lower-order intermediate representation. Each tag object records the tag name and its corresponding attribute value in key-value pairs, used to identify key modules, data domains, or semantic information in the monitoring specification. Through this conversion, the system introduces a unified tag index structure when constructing the lower-order intermediate representation, which not only helps improve the readability and maintainability of the monitoring specification but also facilitates error location, diagnostic analysis, and debugging visualization during operation, enhancing the overall system's interpretability and engineering adaptability.

[0171] It is easy to see that in this embodiment, by establishing a unified stream reference mapping relationship, the transformation from named references to numbered references is realized; by standardizing the conversion of input and output stream attribute structures, the behavioral semantics and memory requirements of each stream are clarified; by trigger pattern recognition and scheduling substructure construction, the precise division of periodic and event-driven mechanisms is achieved; by using various window structures and triggers for refined expression, the system's support for complex aggregation semantics and event-linked behaviors is enhanced; and the structured introduction of global tag items enhances the interpretability and engineering practicality of the monitoring specification in debugging, diagnosis, and visualization processes. Therefore, this embodiment not only optimizes the expression and conversion process of the monitoring specification, but also provides a structurally robust and semantically clear intermediate foundation for the dynamic scheduling and efficient execution of the runtime monitor, greatly improving the system's versatility, scalability, and engineering deployment efficiency.

[0172] It should be noted that the fourth embodiment of this application may also be an improvement based on any one or more of the first to third embodiments.

[0173] Fifth embodiment

[0174] The fifth embodiment of this application relates to an aircraft operation monitoring method. The fifth embodiment is an improvement upon the first embodiment, specifically in that, referring to... Figure 6 As shown, the monitor instance includes an event manager, a time manager, and an evaluator, meaning that step S5 can further include the following steps:

[0175] Creating a monitor instance specifically includes:

[0176] Load the configuration file representing the lower-level intermediate representation;

[0177] Initialize the event manager to build the input stream receive channel, which is used to receive real-time data streams from sensors during aircraft operation;

[0178] Initialize the time manager to establish a periodic task scheduling mechanism based on evaluation frequency;

[0179] Configure the evaluator to support expression evaluation of input data and periodic tasks, as well as monitoring the execution of logic.

[0180] Specifically, the system loads a pre-compiled configuration file of a low-level intermediate representation, which contains the intermediate representation structure of the monitoring specification described by the real-time streaming specification language. This intermediate representation structure defines the input stream, output stream, trigger stream, their dependencies, and scheduling conditions, forming the basis of the monitor's execution logic.

[0181] The event manager is initialized to receive and manage real-time data streams from various sensors during aircraft operation. During initialization, all input stream items defined in the monitoring specifications are read, and the corresponding input channel structure is established, typically using a multi-sender-single-receiver queue model. When an external input event (such as new speed data) is received during runtime, the system will look up the internal number corresponding to the input stream (such as In(1)) by name, thus mapping the event name to the internal stream identifier. To avoid execution conflicts caused by concurrent contention, the system will inject all input events into a sequential task queue to ensure that events are scheduled and executed in order.

[0182] The time manager is initialized to handle the scheduling tasks of all periodically driven streams. The system automatically parses the evaluation frequency of all periodic streams, calculates their least common multiple period, and groups streams with the same scheduling period for management. Whenever the system time reaches the predetermined deadline, the time manager encapsulates the periodic evaluation task into a standard event object and injects it into the task queue for scheduling and processing together with external input events, thereby realizing a unified scheduling mechanism for periodic tasks and event tasks.

[0183] Initialize the evaluator module. The evaluator is the core execution unit of the monitor instance, used to perform computation tasks based on input events, periodic scheduling events, and stream expression logic. During initialization, the evaluator loads the expression logic of all input streams, output streams, and trigger streams defined in the rule expression model, prepares the necessary execution environment and intermediate buffer, and prepares for subsequent high-frequency, low-latency monitoring logic computation.

[0184] Starting a monitor instance specifically includes:

[0185] Start the main control thread of the monitor instance;

[0186] Build a unified task queue for centralized scheduling of input events injected by the event manager and periodic task events generated by the time manager;

[0187] Driven by the event manager and time manager, the unified task queue is pushed into a parallel running state to support real-time monitoring task execution in both input-driven and periodic scheduling modes.

[0188] Specifically, the system launches the monitor's main control thread to construct a unified, sequential task queue. This task queue is responsible for centrally scheduling input events from the event manager and periodic task events from the time manager, executing them sequentially according to their timestamps and stream dependencies. During operation, the event manager listens for arrival events from the input data source, encapsulates the timestamps and data they carry into a standard event structure, and injects it into the task queue; the time manager generates periodic scheduling events according to a preset period and pushes them uniformly to the task queue, ensuring that tasks under different driving modes are uniformly scheduled and processed.

[0189] After starting the monitor instance, the event loop processing phase begins. During this phase, input events are continuously extracted from the real-time data stream collected during aircraft operation. Each event contains two core components: an event value (ev), representing the actual observed value of the flight parameters collected in the input stream; and a timestamp (ts), indicating the system time of data acquisition or reception. Based on the stream input item mapping rules established in the monitoring specifications, the system associates the event value and timestamp with their corresponding internal input stream identifier, achieving accurate binding between the event and the corresponding input stream. Subsequently, the extracted event (ev, ts) is used as input to call the evaluator module to execute the corresponding decision logic. In this process, the evaluator, according to the definition rules in the low-order intermediate representation, completes the following processing tasks: real-time evaluation of the stream expression associated with the input event; execution of window calculations and historical data access operations (e.g., sliding window, delay offset); implementation of aggregation function operations and state update logic; and generation of monitoring conclusions or output response actions when the set trigger conditions are met.

[0190] Once all event data from the input event source has been processed, the system explicitly notifies the monitor that the evaluation process is complete and enters the exit preparation phase by calling the monitor interface (e.g., monitor.end()). To ensure that all monitoring results are output completely, the system's main thread will wait during this phase for the asynchronous output processing thread to complete its remaining output tasks, including writing results and archiving statistical data. When all evaluation results have been processed, the main thread and the output thread exit synchronously, marking the complete end of this monitoring cycle and ensuring the reliability of the monitoring process and the integrity of data processing.

[0191] It is easy to see that in this embodiment, the event manager and time manager work together to support a unified scheduling strategy of input event-driven and periodic task scheduling, while the evaluator efficiently evaluates various stream expressions, aggregation calculations, and window logic according to the intermediate representation specification, ensuring the accurate execution of monitoring rules. By employing a monitor scheduling engine composed of an event manager, a time manager, and an evaluator, online real-time monitoring of aircraft operating status and multi-source event scheduling management are achieved. This execution mechanism features low latency, high accuracy, and good scalability, enabling continuous evaluation and response to complex state information during flight without affecting the system's main control logic.

[0192] It should be noted that the fifth embodiment of this application may also be an improvement based on any one or more of the first to fourth embodiments.

[0193] As can be seen from the above embodiments, the aircraft runtime monitoring mechanism provided in this application, by constructing a semantic modeling method based on a streaming canonical language and a schedulable execution engine system, can effectively support the real-time perception, expression, and verification of key aircraft parameters and operational status. While ensuring low latency and high accuracy, it achieves good execution scalability and system resource adaptability. This mechanism not only fully meets the high reliability requirements of unmanned aerial vehicles for online real-time verification, but also takes into account deployment flexibility and engineering constraints of limited system resources. It is particularly suitable for new types of aircraft such as unmanned aerial vehicles (UAVs), electric vertical takeoff and landing (eVTOL) aircraft, and electric rotorcraft, providing them with a low-intrusion, highly responsive, and formally verifiable runtime security solution.

[0194] Sixth Embodiment

[0195] The sixth embodiment of this application relates to an aircraft operation monitoring system, see below. Figure 7 As shown, it includes:

[0196] The monitoring specification construction module is used to build monitoring specifications for real-time monitoring of aircraft operation status based on the streaming specification language. The monitoring specifications include: geofence boundary detection rules, sensor data validity verification rules, multi-source sensor data consistency verification rules, control status anomaly identification rules, and trigger response rules.

[0197] The intermediate representation generation module is used to generate a high-order intermediate representation according to the monitoring specifications and convert the high-order intermediate representation into a low-order intermediate representation. The high-order intermediate representation expresses the description meta-information of the monitoring specifications in a structured way. The description meta-information includes: semantic logic, syntax structure, data type information, inter-stream dependencies, and sliding window parameter configuration. The low-order intermediate representation is used to describe the scheduling semantics, evaluation rules, and resource constraint information that can be mapped to hardware logic in a structured way.

[0198] The code compilation and deployment module is used to compile low-level intermediate representations into hardware description language code and deploy them in programmable logic devices in aircraft to build a monitor with parallel processing capabilities.

[0199] The monitor instance management module is used to create and start monitor instances by loading configuration files of low-level intermediate representations.

[0200] The data receiving and monitoring execution module is used to receive real-time data streams from sensors during aircraft operation by the monitor instance, perform real-time monitoring logic judgments, and output monitoring results when preset conditions are met.

[0201] The content of the above-described aircraft operation monitoring method embodiments is applicable to this embodiment. The specific functions implemented in this embodiment are the same as those in the above-described aircraft operation monitoring method embodiments, and the beneficial effects achieved are also the same as those achieved in the above-described aircraft operation monitoring method embodiments. To reduce repetition, further details are omitted here.

[0202] Furthermore, in this embodiment, the aircraft operation monitoring system also includes the following functional modules:

[0203] The simulation and playback module is used to replay and reenact historical flight log data during non-flight phases, reproducing changes in monitoring status during flight. This module simulates sensor data input and system response processes under actual flight conditions, verifying the effectiveness of monitoring specifications under typical or boundary conditions. It also assists developers in evaluating the rationality of the triggering conditions of monitoring strategies, thereby further optimizing monitoring logic and system behavior.

[0204] The anomaly logging module records all triggered monitoring anomaly events in real time during aircraft flight, along with detailed contextual information at the time of triggering, including relevant sensor snapshot data, flight status parameters, timestamps, and trigger expression identifiers. The generated anomaly logs can be used not only for post-flight problem tracing and root cause analysis but also provide comprehensive data support for subsequent monitoring rule optimization and system testing and verification.

[0205] The parameter configuration and mission loading module is used to write mission-related parameter configurations into the monitoring specifications before the flight mission begins, via configuration files or variable injection. These parameters include flight boundary conditions (such as maximum flight altitude and maximum speed), flight area restrictions, and alarm threshold settings for key indicators. Before mission initiation, the module completes system initialization and the hardware initialization process required by the monitor, and establishes a communication handshake mechanism with the flight control system to ensure consistency between the monitoring logic and mission requirements.

[0206] In this embodiment, as Figure 8 As shown, the overall architecture of this aircraft operation monitoring system includes a front-end modeling section and a back-end operation section. The front-end modeling section is primarily responsible for the structured parsing and intermediate representation generation of aircraft monitoring specifications, and performs operations such as semantic analysis, dependency graphing, and scheduling logic optimization. The system receives aircraft monitoring specifications described using a streaming specification language and transforms them into a standardized intermediate representation structure for subsequent operation modules to call. The back-end operation section is responsible for the specific monitoring execution tasks and has the capability to support both online operation and offline playback modes.

[0207] In online operation mode, the system interfaces in real time with the operating aircraft system, collecting input event streams including flight control bus, sensor arrays, remote control commands, and system logs. Based on a unified timestamp processing mechanism, the system evaluates the event streams sequentially and performs real-time judgments and alarm outputs according to the conditional logic defined in the monitoring specifications. This mode is suitable for scenarios such as in-flight status monitoring, anomaly detection, and dynamic flight mission management.

[0208] In offline operation mode, the system loads historical flight data logs, replays event records in the original timestamp order, and evaluates each record according to monitoring specifications. This mode can be used for application scenarios such as accident analysis, monitoring logic verification, flight data auditing, and system regression testing, helping to improve system traceability and maintenance efficiency.

[0209] The backend runtime employs two core components: an interpreter and a monitor. These support both interpreted and compiled execution modes, allowing users to flexibly choose the appropriate mode based on their deployment environment. Specifically, it includes:

[0210] Software compilation path: The intermediate representation is converted into program code written in an imperative language (such as Rust), and then deployed and run on an embedded CPU or ground simulation platform through an interpreter. The interpreter has good flexibility and debugging capabilities, and is suitable for scenarios such as pre-flight debugging, mission verification, and offline testing. It can dynamically parse the input event stream and output evaluation results in real time.

[0211] Hardware compilation path: The intermediate representation is compiled into hardware description language (such as Verilog or VHDL) code and burned into an FPGA or other embedded device for execution, with the monitor handling the actual execution tasks. This component receives sensor event data through input pins and triggers control signals or issues alarm messages through output pins. This approach supports nanosecond-level event response, extremely low power consumption, and minimal area overhead, making it suitable for aircraft systems with extremely high real-time, safety, and energy efficiency requirements.

[0212] This embodiment further includes a static resource analysis mechanism to perform a static pre-assessment of key dimensions such as the complexity, memory usage, and power consumption of the monitoring logic in a resource-constrained environment before the aircraft operation monitoring specifications are compiled and deployed. This assists developers in quickly assessing the feasibility of the monitor deployment before flight, ensuring that the system meets flight control safety constraints while balancing real-time performance and resource consumption.

[0213] Specifically, the static resource analysis includes, but is not limited to, the following evaluation dimensions:

[0214] Storage resource estimation: Based on the width and step size configuration of the sliding window defined in the monitoring specification and the computational complexity of the aggregate function used, the amount of state cache required at runtime is derived, and the minimum usage scale of the corresponding register group or on-chip memory unit is estimated to determine the deployment feasibility of the target chip under capacity constraints.

[0215] Logic resource estimation: Based on the parallel data flow paths, number of expressions and conditional branch structures involved in the monitoring specifications, the system can statically deduce the required lookup table (LUT) resource usage, routing resources and number of control triggers in the hardware implementation, providing a quantitative basis for the allocation and layout of logic resources for FPGA or other hardware platforms.

[0216] Peak power consumption analysis: Under the worst-case input scenario (such as sensors running at full speed or multiple rules being triggered simultaneously), the system can combine the maximum throughput of the input data stream to calculate the upper limit of the monitor's peak dynamic power consumption, and compare it with the thermal design power consumption and power margin of the flight control platform to determine whether it has stable operation capability.

[0217] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices.

[0218] The electronic device includes: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform an aircraft operation monitoring method as provided in any one or more of the above embodiments. Figure 9 An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0219] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103, and output device 1104 may be connected via a bus or other means. Figure 9 Taking the example of a connection between China and Israel via a bus.

[0220] In this embodiment, a computer-readable medium stores a computer program / instruction, which, when executed by a processor, implements an aircraft operation monitoring method provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not be assembled into that device. The aforementioned computer-readable medium carries one or more computer-readable instructions.

[0221] The computer program product provided in this application includes one or more computer programs / instructions, which, when executed by a processor, generate all or part of the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0222] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A method for monitoring aircraft operations, characterized in that, include: A monitoring specification for real-time monitoring of aircraft operational status is constructed based on a streaming specification language. The monitoring specification includes: geofence boundary detection rules, sensor data validity verification rules, multi-source sensor data consistency verification rules, control status anomaly identification rules, and trigger response rules. A higher-order intermediate representation is generated based on the monitoring specification. The higher-order intermediate representation expresses the descriptive meta-information of the monitoring specification in a structured manner. The descriptive meta-information includes: the semantic logic, syntax structure, data type information, inter-stream dependencies, and sliding window parameter configuration of the monitoring specification. The higher-order intermediate representation is converted into a lower-order intermediate representation, which is used to structurally describe the scheduling semantics, evaluation rules and resource constraint information that can be mapped to hardware logic. The low-order intermediate representation is compiled into hardware description language code and deployed in programmable logic devices in aircraft to build a monitor with parallel processing capabilities. The monitor instance is created and started by loading the configuration file of the low-level intermediate representation; The monitor instance receives real-time data streams from sensors during aircraft operation, performs real-time monitoring logic judgments, and outputs monitoring results when preset conditions are met.

2. The aircraft operation monitoring method according to claim 1, characterized in that, The steps for constructing monitoring specifications based on the streaming specification language include: Operational data from aircraft-borne sensors is modeled as multiple input streams, each representing a key flight parameter, for continuous sampling and representation of the aircraft's operational status; An output stream is constructed based on the input stream. The output stream is used to perform real-time calculation and processing on the sensor data carried in the input stream to form a data expression that reflects the aircraft's operating status. The output stream includes an event-triggered output stream and an output stream based on fixed-cycle scheduling. A trigger stream is constructed based on the output stream. The trigger stream is used to formally express the rule logic defined in the monitoring specification as executable trigger conditions, and to monitor the aircraft's operating status in combination with the feature data in the output stream that reflects the aircraft's operating status. When the set trigger conditions are met, the corresponding response action is output.

3. The aircraft operation monitoring method according to claim 2, characterized in that, Define corresponding calculation expressions for the output stream and the trigger stream to form a monitoring stream. The calculation expressions include arithmetic operation expressions, window aggregation expressions, or logical judgment expressions. The monitoring stream performs lifecycle management based on preset control statements. The lifecycle management includes: The generation phase is used to dynamically create monitoring stream instances when the set activation conditions are met. The evaluation phase is used to execute the computational logic defined in the monitoring stream instance according to the set beat frequency or input event triggering conditions; The shutdown phase is used to release the monitoring stream instance when the set termination conditions are met.

4. The aircraft operation monitoring method according to claim 1, characterized in that, The step of generating a high-order intermediate representation based on the monitoring specification includes: The monitoring specifications are subjected to abstract syntax tree parsing and naming analysis to complete the structural legality verification and operator matching check of the expressions, perform inline expansion of constant items, and assign a unique number to each expression. Perform type analysis and semantic consistency checks on all stream definitions and expressions; Construct a dependency structure graph based on streams and expressions to represent the dependencies between data streams; Based on the dependency structure graph, topological sorting is performed to determine the scheduling and execution order of each data stream; Analyze the state caching requirements of each stream or expression at different scheduling stages to determine the minimum required memory capacity or cache window size.

5. The aircraft operation monitoring method according to claim 1, characterized in that, The step of converting the higher-order intermediate representation into a lower-order intermediate representation includes: Establish a stream reference mapping table to uniformly map each input stream and output stream defined in the higher-order intermediate representation to the reference number in the lower-order intermediate representation; The attribute structure of each input stream is converted into an input stream object in a low-level intermediate representation. The attribute structure includes: name, data type, access relationship, aggregation relationship, and memory constraint information. The semantic structure of each output stream is converted into an output stream object in a low-level intermediate representation. The semantic structure includes: scheduling conditions, access relationships, aggregation logic, memory constraints, parameter binding relationships and type information for controlling the lifecycle of the monitoring stream. Based on the triggering mode of each output stream, they are classified and the periodic driven stream and the event driven stream are respectively constructed into corresponding scheduling substructures; The windows defined in the higher-order intermediate representation are converted into standardized window objects in the lower-order intermediate representation. The standardized window objects include discrete windows, sliding windows, and instance aggregation windows. All window objects are numbered and their order is verified. Extract the trigger information defined in the event-driven output stream, and construct a trigger object in the low-order intermediate representation. The trigger object includes a unique number and a reference number of the bound output stream. The global tag information defined in the higher-order intermediate representation is converted into structured tag items in the lower-order intermediate representation, and the structured tag items are represented in the form of key-value pairs.

6. The aircraft operation monitoring method according to claim 1, characterized in that, The monitor instance includes an event manager, a time manager, and an evaluator. The steps of creating and starting the monitor instance by loading the configuration file of the low-level intermediate representation include: Creating the monitor instance specifically includes: Load the configuration file of the low-level intermediate representation; Initialize the event manager to build an input stream receiving channel for receiving real-time data streams from sensors during aircraft operation; Initialize the time manager to establish a periodic task scheduling mechanism based on evaluation frequency; Configure the evaluator to support expression evaluation of input data and periodic tasks, as well as monitoring the execution of logic. Starting the monitor instance specifically includes: Start the main control thread of the monitor instance; Build a unified task queue for centralized scheduling of input events injected by the event manager and periodic task events generated by the time manager; Driven by the event manager and the time manager, the unified task queue is pushed into a parallel running state to support real-time monitoring task execution in both input-driven and periodic scheduling modes.

7. An aircraft operation monitoring system, characterized in that, include: The monitoring specification construction module is used to construct monitoring specifications for real-time monitoring of aircraft operation status based on the streaming specification language. The monitoring specifications include: geofence boundary detection rules, sensor data validity verification rules, multi-source sensor data consistency verification rules, control status anomaly identification rules, and trigger response rules. The intermediate representation generation module is used to generate a high-order intermediate representation according to the monitoring specification and convert the high-order intermediate representation into a low-order intermediate representation. The high-order intermediate representation structurally expresses the description meta-information of the monitoring specification. The description meta-information includes: semantic logic, syntax structure, data type information, inter-stream dependencies, and sliding window parameter configuration. The low-order intermediate representation is used to structurally describe the scheduling semantics, evaluation rules, and resource constraint information that can be mapped to hardware logic. The code compilation and deployment module is used to compile the low-level intermediate representation into hardware description language code and deploy it in the programmable logic device in the aircraft to build a monitor with parallel processing capabilities. The monitor instance management module is used to create and start a monitor instance by loading the configuration file of the low-level intermediate representation. The data receiving and monitoring execution module is used to receive real-time data streams from sensors during aircraft operation by the monitor instance, perform real-time monitoring logic judgments, and output monitoring results when preset conditions are met.

8. An electronic device, characterized in that, The electronic device includes: One or more processors; and a memory storing computer program instructions that, when executed, cause the processors to perform the aircraft operation monitoring method as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program and / or instructions stored thereon, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the aircraft operation monitoring method as described in any one of claims 1-6.

10. A computer program product comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the aircraft operation monitoring method as described in any one of claims 1-6.

Images