A flight early warning center modeling method, device and equipment

Abstract

This application discloses a modeling method, apparatus, and equipment for a flight early warning center, relating to the field of civil aviation early warning technology, and is used to solve the technical problems of poor early warning accuracy, consistency, and centralized control capabilities in existing technologies. The method includes: constructing a rule management center using dynamic rule management services and dynamic rule loading services; the rule management center having standardized early warning event models and early warning rule distribution protocols; constructing a dynamic early warning rule library and an early warning processing center using the Drools rule engine; constructing an early warning calculation center using the Drools rule engine and the Disruptor asynchronous processing framework; and constructing a flight early warning center based on the dynamic early warning rule library, rule management center, early warning processing center, and early warning calculation center. Therefore, this application can effectively improve early warning accuracy and consistency through "Drools rule engine, Disruptor asynchronous processing framework, standardized early warning event models, and early warning rule distribution protocols."

Description

Technical Field

[0001] This application relates to the field of civil aviation early warning technology, and provides a method, apparatus and equipment for modeling a flight early warning center. Background Technology

[0002] Currently, large airports generally have multiple business systems in place, including an Airport Operational Database (AODB), a Flight Information Management System (FIMS), an operations command system, a departure system, a gate resource system, and a bridge-mounted equipment system. These systems, each focused on its own business objectives, implement functions such as delay warnings, resource conflict warnings, and support timeout warnings. They typically use independent thresholds, rules, and calculation methods, making judgments within their respective data domains and notifying staff through pop-ups, lists, and other means. However, this "multi-point warning" model clearly presents several challenges for airport operations management: (1) Inconsistent rule system: Each system has its own definition of delay, overtime, no passengers boarding, etc. The same flight may be marked as different warning levels in different systems, or even one system may issue a warning while another system does not, which affects the judgment of the command personnel and reduces the accuracy of the warning.

[0003] (2) Inconsistent calculation benchmarks: Some systems use planned time as the benchmark, while other systems use estimated time or actual time as the benchmark, resulting in inconsistent warning trigger times and reducing the consistency of warnings.

[0004] (3) Repeated and conflicting warnings: When multiple systems scan the same flight, multiple warnings with similar meanings but different codes will be generated. This increases the noise of the warnings and makes it difficult to conduct unified statistics, evaluation and assessment at the airport level, which increases the alarm fatigue of the administrator.

[0005] (4) Lack of a unified early warning protocol and distribution mechanism: At present, early warning results are mostly kept in the local system or shared point-to-point via interfaces. There is a lack of standardized "early warning event model" and "early warning rule distribution protocol", which makes it impossible to realize the unified configuration, calculation and distribution of rules at the airport level, reducing the airport's centralized control over early warning strategies.

[0006] (5) Lack of closed-loop management and traceability: The confirmation, ignoring, handling and rollback of early warnings are usually limited to a single system. At the airport level, it is not only difficult to see a complete link of an early warning from "triggering - confirmation - handling - alarm cancellation", but also difficult to conduct unified review and optimization of early warnings from multiple systems. Therefore, airports urgently need a "flight early warning center" to uniformly build early warning data baselines, rule systems, computing engines, and distribution protocols at the airport level, and to uniformly calculate and manage early warnings from various business systems, achieving the overall capability of "rules being centrally configured, uniformly calculated, and synchronized to various systems according to standard protocols". Summary of the Invention

[0007] This application provides a flight early warning center modeling method, apparatus, and equipment to solve the technical problems of poor early warning accuracy, early warning consistency, and centralized control capabilities in the prior art.

[0008] On the one hand, a method for modeling a flight early warning center is provided, the method comprising: A dynamic early warning rule base is constructed using the Drools rule engine; wherein, the dynamic early warning rule base includes an early warning rule master table, an early warning rule condition table, an early warning rule time calculation table, an early warning rule comparison time table, an early warning rule threshold configuration table, and an early warning rule processing suggestion table; A rule management center is constructed using dynamic rule management service and dynamic rule loading service; wherein, the dynamic rule management service and the dynamic rule loading service are both functional components; the rule management center has a standardized early warning event model and early warning rule distribution protocol; A Drools rule engine is used to build an early warning processing center; the early warning processing center is used for unified management and protocol access of the entire early warning lifecycle. An early warning computing center is built using the Drools rule engine and the Disruptor asynchronous processing framework. The flight early warning center is constructed based on the dynamic early warning rule base, rule management center, early warning processing center, and early warning calculation center.

[0009] Optionally, after constructing the flight early warning center, the method further includes: A flight data mapping table is constructed based on the current day's flight data and the previous day's flight data of the target aircraft obtained from the flight dynamics service; wherein, the flight dynamics service is a functional component; the flight data mapping table includes flight identifier, execution date, arrival / departure attributes, and related flight relationships; A configuration mapping table is constructed based on all warning type configurations obtained from the system configuration service; wherein, the system configuration service is a functional component. Construct a node mapping table based on the flight support nodes obtained from the support service interface; Based on the segment splicing relationship of the target aircraft, obtain the associated flight information of the target aircraft; Based on the flight data mapping table, configuration mapping table, node mapping table, and associated flight information, obtain the target warning context.

[0010] Optionally, after obtaining the target warning context based on the flight data mapping table, configuration mapping table, node mapping table, and associated flight information, the method further includes: The target warning context is asynchronously published using a Disruptor queue; wherein the Disruptor queue uses a circular buffer for lock-free concurrent processing. The target warning context is obtained from the Disruptor queue using a warning event processor, and all warning type configurations are traversed; wherein, the warning event processor is a custom component that processes warning type events.

[0011] Optionally, after retrieving the target alert context from the Disruptor queue using an alert event handler and iterating through all alert type configurations, the method further includes: A KieContainer is obtained using a dynamic rule loading service; wherein the KieContainer contains all enabled alert rules obtained from the dynamic alert rule library; Create a new thread-safe KieSession for the target alert context and insert the target alert context into the working memory of the Drools rule engine; Based on the attributes of the target warning context, the corresponding target warning rule is matched from the KieContainer container; wherein, the attributes include flight information, associated flights, support nodes, and warning type; The target warning rule is used to execute the rule on the target warning context to obtain the warning execution result; wherein, the warning execution result includes the warning plan time, comparison time and deviation minutes of the target warning context.

[0012] Optionally, after applying the target warning rule to execute the rule on the target warning context and obtaining the warning execution result, the method further includes: Determine whether the deviation in minutes exceeds the deviation time threshold; If the deviation in minutes is determined to exceed the deviation time threshold, a warning flag is set; Based on the aforementioned warning indicator, a warning message is sent to all subscribed systems; If it is determined that the number of minutes of deviation does not exceed the deviation time threshold, then no warning flag is set; If the target aircraft already has a warning record, then the existing warning record will be marked as deleted by the system.

[0013] Optionally, after constructing the flight early warning center, the method further includes: In response to the administrator's management of alert rules, a dynamic rule management service is adopted to manage rule configuration in the rule management center; wherein, the rule configuration management includes automatically reloading the alert rules when the alert rules are added, modified, deleted, enabled or disabled.

[0014] Optionally, after constructing the flight early warning center, the method further includes: A standardized early warning rule distribution protocol is adopted to push standardized early warning event models that are created, updated, or deleted; wherein, the structure of the standardized early warning event model includes early warning code, flight identifier, early warning level, trigger time, deviation value, processing suggestion, and early warning status; If the same early warning event undergoes multiple changes, then the same early warning event will be deduplicated.

[0015] Optionally, after constructing the flight early warning center, the method further includes: For any given business system, receive business operations performed by the administrator at the front end of the business system on the target early warning event; wherein, the business operations are reported to the flight early warning center through a standardized early warning processing protocol; In response to the aforementioned business operation, an early warning processing record is obtained, and the corresponding operator, operation time, operation type, and processing result are recorded. Update the warning status of the target warning event and generate a version chain; wherein the warning status includes warning in progress, ignored, confirmed, processed, and deleted by the system; An early warning processing center is used to push changes in the early warning status of target early warning events to all subscribed systems via an early warning distribution protocol.

[0016] On the one hand, a flight early warning center modeling device is provided, the device comprising: The early warning rule base construction unit is used to build a dynamic early warning rule base using the Drools rule engine; wherein, the dynamic early warning rule base includes an early warning rule master table, an early warning rule condition table, an early warning rule time calculation table, an early warning rule comparison time table, an early warning rule threshold configuration table, and an early warning rule processing suggestion table; The rule management center construction unit is used to construct a rule management center using dynamic rule management service and dynamic rule loading service; wherein, the dynamic rule management service and the dynamic rule loading service are both functional components; the rule management center has a standardized early warning event model and early warning rule distribution protocol; The early warning processing center construction unit is used to build an early warning processing center using the Drools rule engine; wherein, the early warning processing center is used for unified management and protocol access of the entire early warning lifecycle; The early warning computing center building unit is used to construct the early warning computing center using the Drools rule engine and the Disruptor asynchronous processing framework; The flight early warning center construction unit is used to construct the flight early warning center based on the dynamic early warning rule base, rule management center, early warning processing center, and early warning calculation center.

[0017] On one hand, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement any of the methods described above.

[0018] On the one hand, a storage medium is provided that stores computer program instructions thereon, which, when executed by a processor, implement any of the methods described above.

[0019] Compared with the prior art, the beneficial effects of this application are as follows: In this application, when modeling the flight early warning center, firstly, a dynamic early warning rule base can be constructed using the Drools rule engine. This dynamic rule base includes a main early warning rule table, an early warning rule condition table, an early warning rule time calculation table, an early warning rule comparison time table, an early warning rule threshold configuration table, and an early warning rule processing suggestion table. Then, a rule management center can be constructed using dynamic rule management services and dynamic rule loading services. Both the dynamic rule management service and the dynamic rule loading service are functional components. The rule management center has a standardized early warning event model and an early warning rule distribution protocol. Next, an early warning processing center can be constructed using the Drools rule engine. This early warning processing center is used for unified management and protocol access throughout the entire early warning lifecycle. Then, an early warning calculation center can be constructed using the Drools rule engine and the Disruptor asynchronous processing framework. Finally, the flight early warning center can be constructed based on the dynamic early warning rule base, the rule management center, the early warning processing center, and the early warning calculation center.

[0020] Based on this, this application focuses on the "flight early warning center." By constructing a unified dynamic early warning rule base and standardized early warning event models and rule distribution protocols, compared to existing technologies, this application allows for centralized rule configuration at the center and unified distribution to various business systems via standard protocols. This avoids inconsistencies caused by customized calculation methods in different systems, achieving standardization across the entire process of rule configuration, early warning calculation, result distribution, and processing feedback. This not only improves the accuracy and consistency of early warnings but also strengthens the airport's centralized control over early warning strategies. Furthermore, because the early warning calculation center is built based on the Drools rule engine and the Disruptor asynchronous processing framework, this application can improve the computational performance of early warnings compared to existing technologies. Attached Figure Description

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

[0022] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application; Figure 2 A flowchart illustrating the flight early warning center modeling method provided in this application embodiment; Figure 3 A schematic diagram illustrating the generation, management, and processing of early warnings provided in this application embodiment; Figure 4 A schematic diagram of a warning type provided in an embodiment of this application; Figure 5 This is a schematic diagram of a flight early warning center modeling device provided in an embodiment of this application.

[0023] The diagram is labeled as follows: 10-Flight Early Warning Center Modeling Equipment, 101-Processor, 102-Memory, 103-I / O Interface, 104-Database, 50-Flight Early Warning Center Modeling Device, 501-Early Warning Rule Base Construction Unit, 502-Rule Management Center Construction Unit, 503-Early Warning Processing Center Construction Unit, 504-Early Warning Calculation Center Construction Unit, 505-Flight Early Warning Center Construction Unit. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. 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. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0025] Currently, large airports generally have multiple business systems in place, including an Airport Operational Database (AODB), a Flight Information Management System (FIMS), an operations command system, a departure system, a gate resource system, and a bridge-mounted equipment system. These systems, each focused on its own business objectives, implement functions such as delay warnings, resource conflict warnings, and support timeout warnings. They typically use independent thresholds, rules, and calculation methods, making judgments within their respective data domains and notifying staff through pop-ups, lists, and other means. However, this "multi-point warning" model clearly presents several challenges for airport operations management: (1) Inconsistent rule system: Each system has its own definition of delay, overtime, no passengers boarding, etc. The same flight may be marked as different warning levels in different systems, or even one system may issue a warning while another system does not, which affects the judgment of the command personnel and reduces the accuracy of the warning.

[0026] (2) Inconsistent calculation benchmarks: Some systems use planned time as the benchmark, while other systems use estimated time or actual time as the benchmark, resulting in inconsistent warning trigger times and reducing the consistency of warnings.

[0027] (3) Repeated and conflicting warnings: When multiple systems scan the same flight, multiple warnings with similar meanings but different codes will be generated. This increases the noise of the warnings and makes it difficult to conduct unified statistics, evaluation and assessment at the airport level, which increases the alarm fatigue of the administrator.

[0028] (4) Lack of a unified early warning protocol and distribution mechanism: At present, early warning results are mostly kept in the local system or shared point-to-point via interfaces. There is a lack of standardized "early warning event model" and "early warning rule distribution protocol", which makes it impossible to realize the unified configuration, calculation and distribution of rules at the airport level, reducing the airport's centralized control over early warning strategies.

[0029] (5) Lack of closed-loop management and traceability: The confirmation, ignoring, handling and rollback of early warnings are usually limited to a single system. At the airport level, it is not only difficult to see a complete link of an early warning from "triggering - confirmation - handling - alarm cancellation", but also difficult to conduct unified review and optimization of early warnings from multiple systems.

[0030] Based on this, this application provides a method for modeling a flight early warning center. In this method, firstly, a dynamic early warning rule base can be constructed using the Drools rule engine. This dynamic early warning rule base includes a master table of early warning rules, a condition table of early warning rules, a time calculation table of early warning rules, a comparison table of early warning rules, a threshold configuration table of early warning rules, and a processing suggestion table of early warning rules. Then, a rule management center can be constructed using a dynamic rule management service and a dynamic rule loading service. Both the dynamic rule management service and the dynamic rule loading service are functional components. The rule management center has a standardized early warning event model and an early warning rule distribution protocol. Next, an early warning processing center can be constructed using the Drools rule engine. This early warning processing center is used for unified management and protocol access throughout the entire early warning lifecycle. Then, an early warning calculation center can be constructed using the Drools rule engine and the Disruptor asynchronous processing framework. Finally, the flight early warning center can be constructed based on the dynamic early warning rule base, the rule management center, the early warning processing center, and the early warning calculation center. Based on this, this application focuses on the "flight early warning center." By constructing a unified dynamic early warning rule base and standardized early warning event models and rule distribution protocols, compared to existing technologies, this application allows for centralized rule configuration at the center and unified distribution to various business systems via standard protocols. This avoids inconsistencies caused by customized calculation methods in different systems, achieving standardization across the entire process of rule configuration, early warning calculation, result distribution, and processing feedback. This not only improves the accuracy and consistency of early warnings but also strengthens the airport's centralized control over early warning strategies. Furthermore, because the early warning calculation center is built based on the Drools rule engine and the Disruptor asynchronous processing framework, this application can improve the computational performance of early warnings compared to existing technologies.

[0031] After introducing the design concept of the embodiments of this application, the following is a brief introduction to the application scenarios to which the technical solutions of the embodiments of this application can be applied. It should be noted that the application scenarios described below are only for illustrating the embodiments of this application and are not intended to limit the scope. In specific implementation, the technical solutions provided by the embodiments of this application can be flexibly applied according to actual needs.

[0032] like Figure 1 The diagram shown is an application scenario illustration provided by an embodiment of this application. This application scenario may include a flight early warning center modeling device 10.

[0033] The flight early warning center modeling device 10 can be used to model and utilize flight early warning centers. For example, it can be an onboard computer, a personal computer (PC), a server, or a laptop. The flight early warning center modeling device 10 may include one or more processors 101, memory 102, I / O interfaces 103, and a database 104. Specifically, the processor 101 can be a central processing unit (CPU) or a digital processing unit, etc. The memory 102 can be volatile memory, such as random-access memory (RAM); the memory 102 can also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or the memory 102 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. The memory 102 can be a combination of the above-mentioned memories. The memory 102 can store some program instructions of the flight early warning center modeling method provided in this application embodiment. When these program instructions are executed by the processor 101, they can be used to implement the steps of the flight early warning center modeling method provided in this application embodiment, so as to solve the technical problems of poor early warning accuracy, early warning consistency, and centralized control capability in the prior art. The database 104 can be used to store data such as the dynamic early warning rule base, flight data mapping table, configuration mapping table, node mapping table, associated flight information of the target aircraft, and target early warning context involved in the solution provided in this application embodiment.

[0034] In this embodiment, the flight early warning center modeling device 10 can obtain fault diagnosis instructions through the I / O interface 103. Then, the processor 101 of the flight early warning center modeling device 10 will solve the technical problems of poor early warning accuracy, early warning consistency, and centralized control capability in the prior art according to the program instructions of the flight early warning center modeling method provided in this embodiment in the memory 102. In addition, data such as the dynamic early warning rule base, flight data mapping table, configuration mapping table, node mapping table, associated flight information of the target aircraft, and target early warning context can be stored in the database 104.

[0035] Of course, the methods provided in the embodiments of this application are not limited to... Figure 1 The application scenarios shown can also be used in other possible scenarios, and this application embodiment does not impose any limitations. Figure 1 The functions that the various devices in the application scenarios shown can achieve will be described in subsequent method embodiments, and will not be elaborated on here. Below, the methods of the embodiments of this application will be described in conjunction with the accompanying drawings.

[0036] like Figure 2 The diagram shown is a flowchart of a flight early warning center modeling method provided in this application embodiment. This method can... Figure 1 The flight early warning center modeling equipment 10 is used to execute this method. The specific process is described below.

[0037] Step 201: Use the Drools rule engine to build a dynamic early warning rule base.

[0038] In this application, all early warning rules are centrally configured and managed at the central layer, supporting the dynamic addition, modification and deletion of rules, achieving "one-time configuration, dynamic effect". Specifically, the dynamic early warning rule base adopts a database storage method and includes core table structures such as the early warning rule master table (BS_WARN_RULE), the early warning rule condition table (BS_WARN_RULE_CONDITION), the early warning rule time calculation table (BS_WARN_RULE_TIME_CALC), the early warning rule comparison time table (BS_WARN_RULE_COMPARE_TIME), the early warning rule threshold configuration table (BS_WARN_RULE_THRESHOLD), and the early warning rule processing suggestion table (BS_WARN_RULE_ACTION).

[0039] The system includes the following components: a main table for storing rule information, including rule code, rule name, warning type key, arrival / departure attributes, scan interval, trigger type, and priority; a condition table for storing rule judgment conditions, supporting multiple condition combinations (AND / OR), including field path, comparison operator, comparison value, and value type; a time calculation table for storing warning plan time calculation rules, including time source, time offset, and whether to use associated flight time; a comparison table for storing comparison base time calculation rules to calculate deviation in minutes; a threshold configuration table for storing rule threshold configurations, supporting configuration by function grouping and other dimensions, and supporting adaptive rules; and a processing suggestion table for storing processing suggestions after rule triggering, including processing type, processing description, and whether to process automatically.

[0040] Furthermore, regarding "rule condition support," in this application, the warning rules can not only support multiple condition judgments, such as abnormal flight status, normal status, arrival / departure attributes, flight tasks, comparison of flight attributes and time, etc., but also support field path access, such as df.abnormalState.code, df.normalState.code, linkDf.remoteScheTime, etc.; moreover, the warning rules can also support multiple comparison operators, such as EQ, NE, IS_NULL, GT, GE, LT, LE, IN, NOT_IN, BETWEEN, etc.

[0041] In addition, regarding "time calculation support", in this application, the warning rules can not only support multiple time sources, such as LOCAL_SCHE, LOCAL_ESTM, LOCAL_ACTL, REMOTE_SCHE, REMOTE_ESTM, REMOTE_ACTL, NODE_TIME, CURRENT, etc., but also support time offset calculation, use of associated flight time and backup time sources.

[0042] For example, regarding the port entry side, the following early warning rules can be constructed in this application: (1) The previously scheduled departure did not take off (no delay): That is, when arriving at the port, the previous station was later than the scheduled departure time and had not yet taken off.

[0043] Check once per minute.

[0044] Judgment criteria: Current time > scheduled departure time, inbound flight status is empty (abnormal status), inbound flight status is empty (normal status), and data status has not been processed.

[0045] The normal status of inbound flights includes flights that have taken off and flights that have arrived.

[0046] Action taken: The station ahead issues a delay report, or updates the actual takeoff status.

[0047] (2) The flight was scheduled to depart 30 minutes prior but has not yet taken off (there is a delay status and an estimated departure time): That is, when arriving at the port, the previous station was 30 minutes later than the scheduled departure time and had not yet taken off.

[0048] Check once per minute.

[0049] Judgment criteria: (Current time - estimated departure time) > 30 minutes, the abnormal status of the inbound flight at this station is delayed, the normal status of the inbound flight is empty, and the data status has not been processed.

[0050] Action: Update the delay time, or update the actual takeoff time. (3) The actual takeoff was 30 minutes later than scheduled (no delay): That is, when arriving at the port, the actual departure time of the previous station is 30 minutes later than the scheduled departure time.

[0051] The judgment is made only once when the aircraft takes off.

[0052] Judgment criteria: The abnormal status of the inbound flight is empty, the normal status of the inbound flight is that it has departed from the previous station, (actual departure time - planned departure time) > 30 minutes, and the data status has not been processed.

[0053] Handling: Release delayed.

[0054] For example, regarding the departure side, the following early warning rules can be constructed in this application: (1) No passengers boarded within 20 minutes of the scheduled start time (no delays): That is, no passengers boarded the departing flight 20 minutes before its scheduled departure time.

[0055] Check once per minute.

[0056] Judgment conditions: The abnormal status of departing flights is empty, and the normal status of departing flights is not equal to (flight takeoff / flight arrives at the next station). That is, the normal status of departing flights is neither the flight takeoff status nor the flight arrives at the next station status; 0≤(planned takeoff time-current time)<20 minutes, there is no boarding command node, and the data status has not been processed.

[0057] The normal status of departing flights includes check-in start, check-in end, boarding start, boarding reminder, boarding end, flight takeoff, and flight arrival at the next station.

[0058] Handling: Direct passengers to board, or issue a delay notice. (2) Failed to take off by the scheduled departure time (no delay): That is, the departing flight did not take off after the scheduled departure time.

[0059] Check once per minute.

[0060] Judgment criteria: The abnormal status of the departing flight is empty, the normal status of the departing flight is not equal to (flight departure / flight arrival at the next station), the current time is greater than the scheduled departure time, and the data status has not been processed.

[0061] Handling: Release delayed. (3) The cabin has been closed for more than 1 hour and the flight has not yet taken off (delay status is not determined): That is, a departing flight has been waiting with its cabins closed for more than one hour without taking off. Here, "cabin closure" refers to any of the last recorded times for cabin closure, such as passenger cabin or cargo hold closure.

[0062] Check once per minute.

[0063] Judgment criteria: The outbound flight is in normal status ≠ (flight takeoff / flight arrival at the next station), (current time - cabin closing time) > 1 hour, and the data status has not been processed.

[0064] Handling: Automatically removed; disappears after updating the cabin closure time. (4) No passengers boarded 20 minutes later than the scheduled time: That is, the departing flight is delayed, 20 minutes later than the scheduled departure time, there is no designated boarding point, and it has not yet taken off.

[0065] Check once per minute.

[0066] Judgment criteria: The abnormal status of the departing flight is a delay, the normal status of the departing flight is not equal to (flight departure / flight arrival at the next station), (current time - estimated departure time) is greater than 20 minutes, there is no boarding command node, and the data status has not been processed.

[0067] Action: Pick up passengers or update the delay time. (5) Delayed to the scheduled departure time but not yet departed (for delays without a scheduled departure time, the planned time is used as the reference): That is, there is a delay, and the current time has exceeded the scheduled departure time and the flight has not yet taken off (30-60 minutes).

[0068] Check once per minute.

[0069] Judgment criteria: The abnormal status of the departing flight is a delay, the normal status of the departing flight is not equal to (flight departure / flight arrival at the next station), 30 minutes < (current time - estimated / planned departure time) ≤ 1 hour, and the data status has not been processed.

[0070] Action taken: Update the estimated departure time. (6) Delayed for more than 1 hour without taking off: That is, the departing flight is delayed by more than 1 hour and has not yet taken off.

[0071] Check once per minute.

[0072] Judgment criteria: The abnormal status of the departing flight is a delay, the normal status of the departing flight is not equal to (flight takeoff / flight arrives at the next station), 1 hour < (current time - estimated takeoff time) ≤ 2 hours, and the data status has not been processed.

[0073] Action: Publish the delay and update the delay time. (7) Delayed for more than 2 hours without taking off (current time exceeds the scheduled departure time, and has not taken off for 2 hours): That is, the departing flight is delayed for more than 2 hours and has not yet taken off.

[0074] Check once per minute.

[0075] Judgment criteria: The abnormal status of the departing flight is a delay, the normal status of the departing flight is not equal to (flight departure / flight arrival at the next station), (current time - estimated departure time) is greater than 2 hours, and the data status has not been processed.

[0076] Action: Publish the delay and update the delay time.

[0077] Step 202: Build a rule management center using dynamic rule management service and dynamic rule loading service.

[0078] In this application, both the dynamic rule management service and the dynamic rule loading service are functional components; the rule management center has a standardized early warning event model and an early warning rule distribution protocol. Specifically, when standardizing the early warning event model, the rule management center can define a unified early warning event structure. For example, the early warning event structure needs to include fields such as early warning code (warnTypeKey), flight identifier, early warning level, trigger time, deviation value, processing suggestion, and early warning status to ensure that the early warning format received by each business system is consistent. Furthermore, early warning events can be encapsulated through WarnEvent objects, which contain early warning context and early warning status information.

[0079] In addition, the rule management center can push alert creation, update, and deletion events through a standardized "early warning event distribution protocol" (supporting message bus, RESTful API, etc.).

[0080] In addition, the rule management center also has a dynamic rule management mechanism, which includes functions such as rule configuration management, dynamic rule loading, automatic rule reloading, rule version management, and rule protocol support.

[0081] When performing "rule configuration management", the Dynamic Rule Management Service can provide functions for adding, deleting, modifying and querying alert rules. It supports configuring alert rules through the API interface (WarnRuleController). The alert rule configuration includes rule master information, condition list, time calculation configuration, comparison time configuration, threshold configuration and processing suggestions.

[0082] When performing "dynamic rule loading", the enabled rule configuration can be loaded from the dynamic alert rule library through the Dynamic Rule Loader Service. The rule generator converts the rule configuration into Drools rule files (.drl format), builds the KieContainer container and caches it. The alert rules are organized by alert type key.

[0083] When performing "automatic rule reloading", the flight warning center can automatically reload the warning rules when they are added, modified, deleted, or enabled / disabled. The rules will take effect without restarting the application, enabling dynamic management of warning rules.

[0084] When performing "rule version management", if a warning rule changes, information such as the update time and the person who updated it can be recorded.

[0085] When implementing "rule protocol support", it is possible to configure alert rules through an alert rule protocol in XML format. This alert protocol contains complete information such as rule master information, condition list, time calculation, comparison time, threshold configuration, and processing suggestions.

[0086] Step 203: Use the Drools rule engine to build an early warning processing center.

[0087] In this application, the early warning processing center is used for unified management and protocol access of the entire early warning lifecycle.

[0088] Specifically, the early warning processing center can uniformly manage the entire lifecycle of all early warnings, such as triggering, changing, confirming, ignoring, handling, canceling and rolling back of early warnings; each business system can report early warning processing operations to the early warning processing center through standard protocols, and the early warning processing center uniformly records and synchronizes them to all subscribed systems to ensure consistent early warning status.

[0089] Furthermore, this early warning processing center can maintain a unified early warning status, such as WARN, IGNORE, CONFIRM, DEAL, and SYS_DELETE. Changes to the early warning status can also be centrally managed by this center to prevent inconsistencies caused by individual systems modifying their own settings. Early warning flags are stored in the DynFlightWarn table, with the warnFlag field indicating the current status of the warning. In the application, early warning data can be displayed through a constructed flight dynamic management page (which may include inbound flight number, outbound flight number, all routes, gate, carousel, flight mission, early warning confirmation, early warning processing, airline, takeoff count, expected landing, actual landing, and latest status). Based on this, users can directly view the confirmation and processing statuses of the early warnings on the flight dynamic management page.

[0090] Step 204: Build an early warning computing center using the Drools rule engine and the Disruptor asynchronous processing framework.

[0091] In this application, the early warning computing center can implement early warning computing based on the Drools rule engine and use the Disruptor asynchronous processing framework to improve computing performance, thereby achieving "centralized computing, dynamic rule execution, and asynchronous high-performance processing". Specifically, the early warning computing center has functions such as scheduled task triggering, data acquisition and context construction, Disruptor asynchronous processing, and early warning event processor.

[0092] When triggering a scheduled task, the early warning calculation center can perform an early warning calculation once per minute through a scheduled task (WarnCenterThread). A distributed lock (RedisLock) is used to ensure that only one instance performs the calculation in a multi-instance environment to avoid duplicate calculations.

[0093] When performing "data acquisition and context construction", the scheduled task can obtain flight data from the flight dynamic service, obtain early warning configuration from the system configuration service, obtain support nodes from the support service, and construct an early warning context (WarnContext) object, which contains complete information such as the current flight, related flights, support nodes, and system configuration.

[0094] When performing "Disruptor asynchronous processing", the constructed list of warning contexts can be asynchronously published through the Disruptor queue (WarnEventQueueHelper). The high-performance ring buffer can be used to achieve lock-free concurrent processing and improve the throughput of warning calculation.

[0095] When the "WarnEventProcessor is working", the WarnEventProcessor can obtain the warning context from the Disruptor queue, traverse all warning type configurations, set the warning type key and name for each warning type, and call the rule service to execute Drools rules. The WarnEventProcessor is a custom component that handles warning type events (e.g., alarms, threshold triggers, abnormal states, etc.) and can implement microservices for logic such as event filtering, transformation, and alarm push.

[0096] Step 205: Construct a flight early warning center based on the dynamic early warning rule base, rule management center, early warning processing center, and early warning calculation center.

[0097] In this application, the flight early warning center can be set up in the middle layer of the airport's information architecture.

[0098] In one possible implementation, after the flight early warning center is successfully built, it can be directly used to generate, manage, and process various flight early warnings, such as... Figure 3The diagram shown is a schematic of the early warning generation, management and processing provided in the embodiment of this application. For example, "flight data access and preprocessing" can be performed. An early warning calculation is performed once per minute by a scheduled task (WarnCenterThread) to obtain flight information from multiple data sources and build a "unified flight view".

[0099] Specifically, firstly, "flight master data aggregation" can be performed. That is, a flight data mapping table can be constructed based on the current day's flight data and the previous day's flight data (DynFlightDto) of the target aircraft obtained from the Flight Dynamics Service (DynFlightCrudService) to solve the problem of inconsistent coding within various business systems. Here, the Flight Dynamics Service is a functional component. The flight data mapping table includes a unified flight identifier, execution date, arrival / departure attributes, and related flight relationships.

[0100] Then, "system configuration retrieval" can be performed. That is, based on all alert type configurations retrieved from the system configuration service (SysFlightConfigService), a configuration mapping table can be built according to the alert type key to provide parameters for subsequent rule execution; whereby the system configuration service is a functional component. For example... Figure 4 The diagram shown is a schematic of one type of warning provided in an embodiment of this application. As can be seen, in this application, the warning types include: no passengers boarding 20 minutes before the scheduled takeoff, actual takeoff of the preceding airport 30 minutes later than the scheduled takeoff, no takeoff 30 minutes before the scheduled takeoff of the preceding airport, and no takeoff of the preceding airport as scheduled.

[0101] Next, "Flight Support Node Access" can be implemented, which means that a node mapping table can be constructed based on the flight support nodes (DNode) obtained from the support service interface (KeyServiceFeignService) and the flight support nodes include key nodes such as cabin closure time, and "Flight Support Node Access" supports the calculation of early warning rules based on flight support nodes.

[0102] Then, “associated flight processing” can be performed, that is, the associated flight information of the target aircraft can be obtained according to the segment splicing relationship (DynLink) of the target aircraft; among them, “associated flight processing” supports early warning calculation of inbound flights based on the status of previous flights.

[0103] Finally, "warning context construction" can be performed, which means that the target warning context can be obtained based on the flight data mapping table, configuration mapping table, node mapping table, and related flight information. In other words, information such as flight data, related flights, flight support nodes, and system configuration can be encapsulated into a warning context (WarnContext) to serve as a fact object for the rule engine. It contains complete information such as the current flight, related flights, support node list, and system configuration mapping.

[0104] In one possible implementation, such as Figure 3 As shown, after obtaining the target warning context, the Disruptor asynchronous processing framework can also be used to improve computational performance.

[0105] Specifically, firstly, a Disruptor queue (WarnEventQueueHelper) can be used to asynchronously publish the target warning context; wherein, the Disruptor queue uses a high-performance ring buffer for lock-free concurrent processing, thereby improving the throughput of warning calculation.

[0106] Then, the target warning context can be obtained from the Disruptor queue using a WarnEventProcessor, and all warning type configurations can be traversed.

[0107] In one possible implementation, such as Figure 3 As shown, after traversing all alert type configurations, you can also "execute the alert rule judgment process based on the Drools rule engine".

[0108] Specifically, firstly, a "rule container acquisition" can be performed, that is, a KieContainer container can be obtained using a dynamic rule loading service; wherein, the KieContainer container contains all enabled warning rules obtained from the dynamic warning rule library, and the warning rules are organized according to the warning type key.

[0109] Then, a "rule session creation" can be performed, that is, a new thread-safe KieSession is created for the target alert context, and the target alert context is inserted into the working memory of the Drools rule engine.

[0110] Next, "rule matching and execution" can be performed, that is, the corresponding target warning rule can be matched from the KieContainer based on the attributes of the target warning context; wherein, the attributes include flight information, associated flights, support nodes, and warning type; Finally, "rule execution" can be performed, that is, the target warning rule can be used to execute the rule on the target warning context to obtain the warning execution result; wherein, the warning execution result includes the warning plan time, comparison time and deviation minutes of the target warning context. In other words, when the warning rule condition is met, the then clause of the warning rule is executed to calculate the warning plan time (warnScheTime), comparison time (compareTime) and deviation minutes (warnMinute).

[0111] In one possible implementation, such as Figure 3 As shown, after obtaining the warning execution result, you can also "process the warning execution result", such as performing warning judgment, warning deduplication, time change detection, warning saving and warning deletion.

[0112] In the process of "early warning judgment", firstly, it can be determined whether the number of deviation minutes exceeds the deviation time threshold; then, if it is determined that the number of deviation minutes exceeds the deviation time threshold, an early warning flag (warnFlag) is set, that is, an early warning needs to be issued; next, according to the early warning flag, an early warning message can be sent to all subscribed systems.

[0113] Conversely, if the deviation in minutes is determined to be less than the deviation time threshold, no warning flag is set. In this case, it can be checked whether the target aircraft has a warning record; if it is determined that the target aircraft already has a warning record, the existing warning record is marked for system deletion and saved.

[0114] When performing "early warning deduplication", you can also check the early warning signs. If the early warning sign indicates that it has been ignored, confirmed or processed, no new early warning will be generated.

[0115] When performing "time change detection", it can check whether the warning plan time has changed. If the warning plan time has not changed and the target aircraft already has a warning record, the warning record will not be updated.

[0116] When saving an alert, if the deviation in minutes is greater than 0, the alert record (DynFlightWarn) will be saved or updated, and information such as the alert type key, alert type name, alert flag, deviation in minutes, and alert schedule time will be set.

[0117] When performing "early warning deletion", if it is determined that the deviation minutes are ≤0, or the early warning rule conditions are not met, and the target aircraft already has an early warning record, then the existing early warning record will be marked as deleted by the system.

[0118] In one possible implementation, such as Figure 3As shown, after constructing the flight early warning center, "dynamic rule management" can also be carried out.

[0119] Specifically, in response to administrator-managed alert rules, a dynamic rule management service can be used to configure and manage rules in the rule management center. This rule configuration management includes automatically reloading alert rules when they are added, modified, deleted, enabled, or disabled. As mentioned earlier, rule configuration management, dynamic rule loading, automatic rule reloading, and rule version management can be performed based on the dynamic rule management mechanism of the rule management center.

[0120] In one possible implementation, such as Figure 3 As shown, after constructing the flight early warning center, "early warning event push and deduplication" can also be performed.

[0121] Specifically, when pushing "early warning events", a standardized early warning rule distribution protocol can be used to push standardized early warning event models that have been created, updated or deleted; wherein, the structure of the standardized early warning event model includes early warning code, flight identifier, early warning level, trigger time, deviation value, processing suggestion and early warning status.

[0122] When performing "early warning event deduplication," if the same early warning event undergoes multiple changes, it is deduplicated to provide a "cleaner" early warning list to duty stations and business systems. This ensures that business systems do not receive duplicate early warning events, thereby reducing alarm fatigue among operators. Furthermore, it supports early warning event replay, facilitating the request for early warning data after business systems recover from faults.

[0123] In one possible implementation, such as Figure 3 As shown, after constructing the flight early warning center, "unified management and protocol access throughout the entire early warning lifecycle" can also be implemented.

[0124] Specifically, for any business system (e.g., FIMS, operation command system, etc.), the system can receive business operations performed by the administrator on the target warning event at the front end of the business system. These business operations can be reported to the flight warning center through a standardized warning processing protocol. The business operations can be confirmation, processing, or ignoring. Furthermore, in this application, a constructed warning confirmation page can be used to process or ignore warning information; or a constructed warning processing page can be used to process warning events, such as directing passenger boarding or issuing delay notices; or a constructed comprehensive warning page can be used to process various flight themes, where the comprehensive warning page aggregates and displays the specific warning content for all flights, and each warning type has a corresponding processing operation.

[0125] Then, a "unified record of the early warning processing center" can be performed. That is, in response to the business operation, an early warning processing record can be obtained, and the corresponding operator, operation time, operation type and processing result can be recorded (the threshold or estimated takeoff time can be adjusted at the same time).

[0126] Next, the alert status of the target alert event can be updated, and a version chain can be generated; the alert status includes alerting, ignored, confirmed, processed, and deleted by the system. Alert processing records can be stored in the DynFlightWarnConfirm table and associated with the alert records.

[0127] Then, "status synchronization distribution" can be performed. This means that an early warning processing center can be used to push changes in the warning status of the target warning event to all subscribed systems via an early warning distribution protocol, ensuring that the warning status displayed on the front end of each business system is consistent with that of the flight early warning center. In other words, when the warning status changes, an update event can be automatically pushed to third-party services, and the subscribed systems can simultaneously update their warning lists. In one possible implementation, the flight warning center in this application can also perform "version tracing". Specifically, the flight alert center can maintain a complete version chain for each alert event, and record every status change, creation operation, processing operation, cancellation behavior, threshold adjustment, and estimated time update at the central level, facilitating post-event analysis and continuous rule optimization. Simultaneously, the version chain supports auditing and review, enabling analysis of alert handling effectiveness and rule optimization. Every change to an alert is recorded in the DynFlightWarn table, thus enabling unified closed-loop management of version traceability and alerts through version numbers or timestamps.

[0128] In summary, this application has the following advantages: (1) It provides a unified dynamic early warning rule base and rule distribution protocol at the airport level, so that early warning rules can be centrally configured in the center and uniformly distributed to various business systems through standard protocols, avoiding inconsistencies caused by custom calculation methods of various business systems, and greatly improving the accuracy and consistency of early warning.

[0129] (2) Based on the Drools rule engine and Disruptor asynchronous processing framework, an early warning computing center is built, which dynamically loads and executes early warning rules, supports flexible configuration of early warning rule conditions and diversification of time calculation, and realizes "centralized computing, dynamic execution of rules and asynchronous high-performance processing", thereby improving computing performance.

[0130] (3) Based on the Drools rule engine, the dynamic early warning rule library and rule management mechanism are configured and stored in the dynamic early warning rule library in the central layer. The Drools rule file is dynamically generated through the rule generator, which supports the dynamic addition, modification, deletion, enabling or disabling of rules, realizing the dynamic management and automatic reloading of rules, and improving the controllability and accuracy of early warning rules.

[0131] (4) Provides unified management and protocol access for the entire lifecycle of early warnings. At the central level, the triggering, modification, confirmation, ignoring, handling, cancellation and rollback of early warnings are managed in a unified manner. Each system reports and processes operations through standard protocols, and records and synchronizes them to all subscribed systems in a unified manner, thereby strengthening the airport's centralized control over early warning strategies.

[0132] (5) It provides standardized early warning event models, rule issuance protocols, early warning distribution protocols and processing protocols, providing a consistent early warning access method for various business systems within the airport, realizing the standardization of the entire process of rule configuration, early warning calculation, result distribution and processing feedback, reducing the workload and error rate of repeated configuration of multiple business systems, and further strengthening the airport's centralized control over early warning strategies.

[0133] Based on the same inventive concept, embodiments of this application provide a flight early warning center modeling device 50, such as... Figure 5 As shown, the flight early warning center modeling device 50 includes: The early warning rule base construction unit 501 is used to build a dynamic early warning rule base using the Drools rule engine. The dynamic early warning rule base includes an early warning rule main table, an early warning rule condition table, an early warning rule time calculation table, an early warning rule comparison time table, an early warning rule threshold configuration table, and an early warning rule processing suggestion table. The rule management center construction unit 502 is used to build the rule management center using dynamic rule management service and dynamic rule loading service; wherein, dynamic rule management service and dynamic rule loading service are both functional components; the rule management center has a standardized early warning event model and early warning rule distribution protocol; The early warning processing center building unit 503 is used to build an early warning processing center using the Drools rule engine; the early warning processing center is used for unified management and protocol access of the entire early warning lifecycle. The early warning computing center building unit 504 is used to build the early warning computing center using the Drools rule engine and the Disruptor asynchronous processing framework; The Flight Early Warning Center Construction Unit 505 is used to construct the Flight Early Warning Center based on the Dynamic Early Warning Rule Base, Rule Management Center, Early Warning Processing Center, and Early Warning Calculation Center.

[0134] The flight early warning center modeling device 50 can be used to execute... Figures 2-3 The method performed by the flight early warning center modeling device in the illustrated embodiment can be referenced for understanding the functions that each functional module of the flight early warning center modeling device 50 can achieve. Figures 2-3 The embodiments shown are described in detail below.

[0135] In some possible implementations, various aspects of the methods provided in this application can also be implemented as a program product comprising program code that, when run on a computer device, causes the computer device to perform the steps of the methods according to the various exemplary embodiments of this application described above. For example, the computer device may perform actions such as... Figures 2-3 The method performed by the flight early warning center modeling device in the illustrated embodiment.

[0136] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks. Alternatively, if the integrated units of this application are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of software products. These computer software products are stored in a storage medium and include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0137] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0138] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for modeling a flight early warning center, characterized in that, The method includes: A dynamic early warning rule base is constructed using the Drools rule engine; wherein, the dynamic early warning rule base includes an early warning rule master table, an early warning rule condition table, an early warning rule time calculation table, an early warning rule comparison time table, an early warning rule threshold configuration table, and an early warning rule processing suggestion table; A rule management center is constructed using dynamic rule management service and dynamic rule loading service; wherein, the dynamic rule management service and the dynamic rule loading service are both functional components; the rule management center has a standardized early warning event model and early warning rule distribution protocol; A Drools rule engine is used to build an early warning processing center; the early warning processing center is used for unified management and protocol access of the entire early warning lifecycle. An early warning computing center is built using the Drools rule engine and the Disruptor asynchronous processing framework. The flight early warning center is constructed based on the dynamic early warning rule base, rule management center, early warning processing center, and early warning calculation center.

2. The method as described in claim 1, characterized in that, After establishing the flight early warning center, the method further includes: A flight data mapping table is constructed based on the current day's flight data and the previous day's flight data of the target aircraft obtained from the flight dynamics service; wherein, the flight dynamics service is a functional component; the flight data mapping table includes flight identifier, execution date, arrival / departure attributes, and related flight relationships; A configuration mapping table is constructed based on all warning type configurations obtained from the system configuration service; wherein, the system configuration service is a functional component. Construct a node mapping table based on the flight support nodes obtained from the support service interface; Based on the segment splicing relationship of the target aircraft, obtain the associated flight information of the target aircraft; Based on the flight data mapping table, configuration mapping table, node mapping table, and associated flight information, obtain the target warning context.

3. The method as described in claim 2, characterized in that, After obtaining the target warning context based on the flight data mapping table, configuration mapping table, node mapping table, and associated flight information, the method further includes: The target warning context is asynchronously published using a Disruptor queue; wherein the Disruptor queue uses a circular buffer for lock-free concurrent processing. The target warning context is obtained from the Disruptor queue using a warning event processor, and all warning type configurations are traversed; wherein, the warning event processor is a custom component that processes warning type events.

4. The method as described in claim 3, characterized in that, After retrieving the target alert context from the Disruptor queue using an alert event handler and iterating through all alert type configurations, the method further includes: A KieContainer is obtained using a dynamic rule loading service; wherein the KieContainer contains all enabled alert rules obtained from the dynamic alert rule library; Create a new thread-safe KieSession for the target alert context and insert the target alert context into the working memory of the Drools rule engine; Based on the attributes of the target warning context, the corresponding target warning rule is matched from the KieContainer container; wherein, the attributes include flight information, associated flights, support nodes, and warning type; The target warning rule is used to execute the rule on the target warning context to obtain the warning execution result; wherein, the warning execution result includes the warning plan time, comparison time and deviation minutes of the target warning context.

5. The method as described in claim 4, characterized in that, After applying the target warning rule to execute the rule on the target warning context and obtaining the warning execution result, the method further includes: Determine whether the deviation in minutes exceeds the deviation time threshold; If the deviation in minutes is determined to exceed the deviation time threshold, a warning flag is set; Based on the aforementioned warning indicator, a warning message is sent to all subscribed systems; If it is determined that the number of minutes of deviation does not exceed the deviation time threshold, then no warning flag is set; If the target aircraft already has a warning record, then the existing warning record will be marked as deleted by the system.

6. The method as described in claim 1, characterized in that, After establishing the flight early warning center, the method further includes: In response to the administrator's management of alert rules, a dynamic rule management service is adopted to manage rule configuration in the rule management center; wherein, the rule configuration management includes automatically reloading the alert rules when the alert rules are added, modified, deleted, enabled or disabled.

7. The method as described in claim 1, characterized in that, After establishing the flight early warning center, the method further includes: A standardized early warning rule distribution protocol is adopted to push standardized early warning event models that are created, updated, or deleted; wherein, the structure of the standardized early warning event model includes early warning code, flight identifier, early warning level, trigger time, deviation value, processing suggestion, and early warning status; If the same early warning event undergoes multiple changes, then the same early warning event will be deduplicated.

8. The method as described in claim 1, characterized in that, After establishing the flight early warning center, the method further includes: For any given business system, receive business operations performed by the administrator at the front end of the business system on the target early warning event; wherein, the business operations are reported to the flight early warning center through a standardized early warning processing protocol; In response to the aforementioned business operation, an early warning processing record is obtained, and the corresponding operator, operation time, operation type, and processing result are recorded. Update the warning status of the target warning event and generate a version chain; wherein the warning status includes warning in progress, ignored, confirmed, processed, and deleted by the system; An early warning processing center is used to push changes in the early warning status of target early warning events to all subscribed systems via an early warning distribution protocol.

9. A flight early warning center modeling device, characterized in that, The device includes: The early warning rule base construction unit is used to build a dynamic early warning rule base using the Drools rule engine; wherein, the dynamic early warning rule base includes an early warning rule master table, an early warning rule condition table, an early warning rule time calculation table, an early warning rule comparison time table, an early warning rule threshold configuration table, and an early warning rule processing suggestion table; The rule management center construction unit is used to construct a rule management center using dynamic rule management service and dynamic rule loading service; wherein, the dynamic rule management service and the dynamic rule loading service are both functional components; the rule management center has a standardized early warning event model and early warning rule distribution protocol; The early warning processing center construction unit is used to build an early warning processing center using the Drools rule engine; wherein, the early warning processing center is used for unified management and protocol access of the entire early warning lifecycle; The early warning computing center building unit is used to construct the early warning computing center using the Drools rule engine and the Disruptor asynchronous processing framework; The flight early warning center construction unit is used to construct the flight early warning center based on the dynamic early warning rule base, rule management center, early warning processing center, and early warning calculation center.

10. An electronic device, characterized in that, The device includes: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the method described in any one of claims 1-8 according to the obtained program instructions.

Images