Dam hidden danger intelligent early warning method and system based on multi-source sensing data fusion

Abstract

The application discloses a dam hidden danger intelligent early warning method and system based on multi-source sensing data fusion, relates to the technical field of dam hidden danger intelligent early warning, and comprises the following steps: accessing a monitoring point group state message, determining unusable monitoring points according to heartbeat time efficiency and fault levels, calculating idle monitoring point available time and occupied monitoring point release time, and generating an available time table and a state snapshot; establishing a report arrival prediction model and giving a report arrival uncertainty, combining a monitoring zone bandwidth budget to calculate a predicted processing time delay and an early warning generation time, calculating urgency, reliability, waiting compensation and fair punishment, generating a priority and outputting a sequence table; constructing a candidate monitoring point set and filtering according to data type matching, availability and in-zone scheduling strategies, establishing a minimum disturbance cost model, and generating an execution plan and a rearranged difference list under bandwidth budget constraints by using hierarchical greed and local exchange; and triggering iteration according to queue length, budget changes, a reply timeout and a deviation threshold.

Description

Technical Field

[0001] This invention relates to the field of intelligent early warning technology for dam hazards, and more specifically, to an intelligent early warning method and system for dam hazards based on multi-source sensor data fusion. Background Technology

[0002] During long-term operation, dam projects are susceptible to factors such as water level fluctuations, rainfall infiltration, seepage evolution, structural aging, and external disturbances. On-site data typically requires access to multiple types of sensors and monitoring ports, which are then aggregated and processed at the monitoring area or platform level to form a continuous perception and early warning output of the dam's operational status and risk condition. Existing technologies often rely on decentralized reporting and fixed threshold judgments, making it difficult to unify and integrate data when data field definitions are inconsistent. The linearity, fault status, and data availability of monitoring ports lack consistent constraints. Furthermore, when facing scenarios with uncertain observations, limited resources, or frequent status changes, problems such as inconsistent early warning trigger criteria and difficulty in tracing update links can easily arise.

[0003] Existing technologies still have shortcomings in the above applications, mainly including: significant differences in sampling frequency, time base, field caliber, and communication protocols among multi-source data, lacking a unified normalization expression and fusion standard, making the fusion results susceptible to variations from the source; when monitoring points are offline, drifting, faulty, or subject to outlier interference, there is a lack of unified constraints on data availability and abnormal states, easily incorporating unusable data into the judgment chain; early warning judgments often rely on fixed thresholds or single indicators, making it difficult to simultaneously characterize environmental fluctuations and observation uncertainties, easily leading to false alarms or missed alarms; when external operating conditions or data quality change, there is a lack of traceable result version management and consistency verification mechanisms, making it difficult to locate the input baseline and formation path of early warning conclusions; and the lack of closed-loop verification and update basis between early warning outputs and on-site handling receipts makes it difficult to correct in a timely manner and achieve stable convergence when early warning results are inconsistent with the execution status.

[0004] To address the above problems, this invention proposes a solution. Summary of the Invention

[0005] In order to overcome the above-mentioned defects of the prior art, embodiments of the present invention provide a method and system for intelligent early warning of dam hazards based on multi-source sensor data fusion, so as to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] A method for intelligent early warning of dam hazards based on multi-source sensor data fusion, including the following steps;

[0008] Step S1: Access the status message of the monitoring point group and complete field normalization; obtain the monitoring area identifier, monitoring point identifier, acquisition channel occupancy, heartbeat time, fault code, reception time and session identifier; calculate the heartbeat timeout and compare it with the heartbeat timeout threshold; calculate the fault level and compare it with the fault threshold; determine unavailable monitoring points and write them into the unavailable set; calculate the available time for idle monitoring points; obtain the remaining observation data volume and reference conservative bandwidth budget for occupied monitoring points and calculate the release time; summarize and generate an available time table and status snapshot.

[0009] Step S2: Establish a reporting arrival prediction model and calculate the reporting arrival prediction time and reporting arrival uncertainty. Calculate the reference conservative bandwidth budget based on the monitoring area bandwidth budget and available timetable, and calculate the expected processing delay and expected early warning generation time. Calculate the time margin and map the urgency. Calculate the credibility, calculate the waiting compensation, calculate the fair penalty, calculate the priority according to the weighted fusion algorithm and standardize it. Sort and generate a sorted table, and divide the strong cooperative set and ordinary set according to the credibility threshold and urgency threshold.

[0010] Step S3: Read the available timetable and the unavailable set, construct a candidate monitoring point set for each request, filter by data type matching, availability and intra-area scheduling strategy to obtain a feasible candidate set, establish a minimum disturbance cost model, calculate the monitoring point switching cost, start time drift cost, overdue cost and priority violation cost, and introduce bandwidth budget constraints as infeasibility determination, calculate the earliest start time and end time of the candidate combination, use a hierarchical greedy algorithm with local exchange to complete resource allocation, generate execution plan entries, and perform monitoring point overlap verification and time-sharing bandwidth budget summary verification, output execution plan and rearrangement difference list;

[0011] Step S4: Based on the queue length threshold, budget change threshold, receipt timeout threshold, and deviation threshold, the iteration is triggered. The station receipts are checked for version consistency. The arrival observation, bandwidth budget output observation, and completion observation are collected and the arrival deviation, bandwidth budget deviation, and completion deviation are calculated. If the limits are exceeded, the relevant predictions and constraints are updated. After determining the affected request subset, the preceding steps are locally called to update the sorting and execution plan. Rollback or freezing is performed when the receipts are mismatched, the check fails, or the reordering is too dense.

[0012] In a preferred embodiment, step S1 includes the following:

[0013] Monitoring points identified as out of contact or severely malfunctioning will be marked as unavailable. Specifically, this includes:

[0014] If the heartbeat duration of a certain monitoring point is greater than the heartbeat timeout threshold, then the monitoring point is determined to be out of contact.

[0015] If the fault level of a certain monitoring point is higher than the fault threshold, then the monitoring point is determined to be in a serious fault state.

[0016] Add the monitoring points that are in any of the above states to the unavailable set;

[0017] For a monitoring point whose status is occupied, the estimated release time is calculated as follows: the estimated release time is obtained by calculating based on the remaining amount of observation data and the reference conservative bandwidth budget, and the result is recorded as the available time of the monitoring point in the available time table.

[0018] In a preferred embodiment, step S2 includes the following:

[0019] A weighted fusion algorithm is used to combine multiple scores into a comprehensive priority score. This is achieved by pre-setting weight coefficients for each score and performing a linear weighted combination. The division into strong collaborative sets and ordinary collaborative sets is as follows:

[0020] Early warning judgment tasks with both a credibility score higher than the credibility threshold and an urgency score higher than the urgency threshold are included in the strong collaboration set.

[0021] The remaining early warning and discrimination tasks are categorized into the general collaborative set.

[0022] In a preferred embodiment, step S3 includes the following:

[0023] Filtering the initial candidate monitoring point set includes: first, screening monitoring points that match the requested acquisition channel type; second, excluding monitoring points that belong to the unavailable set; and finally, filtering according to the strategy specified in the monitoring area, which includes prioritizing the allocation of monitoring points within the same monitoring area or avoiding specific combinations of monitoring points.

[0024] The resource allocation using a hierarchical greedy strategy combined with a local exchange optimization algorithm specifically includes:

[0025] According to the order of the sorting table, for each request in the strong cooperation set, the monitoring point that minimizes the incremental cost calculated by the current cost model is selected from its set of feasible candidate monitoring points for pre-allocation;

[0026] The same strategy is used to pre-allocate requests in the ordinary collaborative set;

[0027] Based on the pre-allocated plan, try to swap monitoring points for tasks in adjacent or similar time periods. If the swap reduces the overall cost and does not violate constraints, then adopt the swap.

[0028] In a preferred embodiment, step S4 includes the following:

[0029] Deviation thresholds include independent reporting arrival time deviation thresholds, bandwidth budget deviation thresholds, and completion time deviation thresholds;

[0030] Updating the corresponding prediction model or constraints includes: calibrating the parameters of the reported prediction model using the actual observation data, or adjusting the calculation logic of the reference conservative bandwidth budget using the actual observation bandwidth budget;

[0031] Performing a rollback or freeze operation specifically includes: when the plan version number of the site-side receipt is inconsistent with the version number of the locally executed plan, discarding the receipt and maintaining the original plan;

[0032] When the number of reorderings triggered per unit time exceeds a preset frequency threshold, the rescheduling of the affected request subset is suspended, and its original allocation scheme remains unchanged.

[0033] The intelligent early warning system for dam hazards based on multi-source sensor data fusion includes: a situation snapshot module, a priority sequencing module, a minimum disturbance scheduling module, and an event iteration rollback module, with signal connections between the modules;

[0034] The status snapshot module receives status messages from the monitoring point group and normalizes the fields. It obtains the monitoring area identifier, monitoring point identifier, acquisition channel occupancy, heartbeat time, fault code, reception time, and session identifier. It calculates the heartbeat timeout and compares it with the heartbeat timeout threshold. It calculates the fault level and compares it with the fault threshold. It determines unavailable monitoring points and writes them into the unavailable set. It calculates the available time for idle monitoring points. For occupied monitoring points, it obtains the remaining observation data volume of the session and the reference conservative bandwidth budget and calculates the release time. It summarizes and generates an available time table and status snapshot.

[0035] Priority sorting module: Establishes a reporting arrival prediction model and calculates the reporting arrival prediction time and reporting arrival uncertainty; calculates a reference conservative bandwidth budget based on the monitoring area bandwidth budget and available timetable, and calculates the expected processing delay and expected warning generation time; calculates time margin and maps urgency; calculates credibility; calculates waiting compensation; calculates fair penalty; calculates priority according to weighted fusion algorithm and standardizes it; sorts and generates a sorting table; and divides the strong cooperative set and ordinary set according to credibility threshold and urgency threshold.

[0036] Minimum Disturbance Scheduling Module: Reads the available timetable and unavailable set, constructs a candidate monitoring point set for each request, filters feasible candidate sets by data type matching, availability and intra-area scheduling strategy, establishes a minimum disturbance cost model, calculates monitoring point switching cost, start time drift cost, overdue cost and priority violation cost, and introduces bandwidth budget constraints as infeasibility determination, calculates the earliest start time and end time of candidate combinations, completes resource allocation using a hierarchical greedy algorithm with local switching, generates execution plan entries, performs monitoring point overlap verification and time-sharing bandwidth budget summary verification, and outputs execution plan and rearrangement difference list;

[0037] Event Iteration Rollback Module: Based on queue length threshold, budget change threshold, receipt timeout threshold and deviation threshold, it determines the trigger for iteration, performs version consistency verification on station receipts, collects and reports arrival observations, bandwidth budget output observations, and completion observations, and calculates the reporting arrival deviation, bandwidth budget deviation and completion deviation. If the limits are exceeded, it updates the relevant predictions and constraints. After determining the affected request subset, it locally calls the preceding steps to update the sorting and execution plan, and performs rollback or freeze when receipt mismatch, verification failure or reordering is too dense.

[0038] The technical effects and advantages of the intelligent early warning method for dam hazards based on multi-source sensor data fusion in this invention are as follows:

[0039] This invention constructs a situational snapshot and an availability timetable, normalizes the fields of status messages from a group of monitoring points, and forms an unavailable set based on heartbeat and fault criteria, thus constraining the candidate resource criteria from the source. In the sorting stage, it introduces reporting arrival prediction and duration calculation, combining urgency, credibility, waiting compensation, and fair penalty to generate comparable priorities and output a sorting table, while also hierarchically classifying the request set. In the scheduling stage, it establishes a minimum disturbance cost model and, combined with bandwidth budget constraints, uses a hierarchical greedy algorithm and local exchange to generate an execution plan and a rearrangement difference list, ensuring that plan updates have executable verification and quantifiable changes. In the iteration stage, it triggers local updates based on queues, budgets, receipts, and deviation thresholds, combined with version consistency verification, rollback, and freeze strategies, ensuring that sorting results, execution plans, and station receipts are traceable under the same version baseline, and providing a controlled update path in abnormal or high-frequency event scenarios. Attached Figure Description

[0040] Figure 1 This is a schematic diagram of the intelligent early warning system module for dam hazards based on multi-source sensor data fusion according to the present invention. Detailed Implementation

[0041] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0042] Example: Please refer to Figure 1 As shown, this invention discloses an intelligent early warning method for dam hazards based on multi-source sensor data fusion, including the following steps:

[0043] Step S1: Access the status message of the monitoring point group and complete field normalization; obtain the monitoring area identifier, monitoring point identifier, acquisition channel occupancy, heartbeat time, fault code, reception time and session identifier; calculate the heartbeat timeout and compare it with the heartbeat timeout threshold; calculate the fault level and compare it with the fault threshold; determine unavailable monitoring points and write them into the unavailable set; calculate the available time for idle monitoring points; obtain the remaining observation data volume and reference conservative bandwidth budget for occupied monitoring points and calculate the release time; summarize and generate an available time table and status snapshot.

[0044] Step S2: Establish a reporting arrival prediction model and calculate the reporting arrival prediction time and reporting arrival uncertainty. Calculate the reference conservative bandwidth budget based on the monitoring area bandwidth budget and available timetable, and calculate the expected processing delay and expected early warning generation time. Calculate the time margin and map the urgency. Calculate the credibility, calculate the waiting compensation, calculate the fair penalty, calculate the priority according to the weighted fusion algorithm and standardize it. Sort and generate a sorted table, and divide the strong cooperative set and ordinary set according to the credibility threshold and urgency threshold.

[0045] Step S3: Read the available timetable and the unavailable set, construct a candidate monitoring point set for each request, filter by data type matching, availability and intra-area scheduling strategy to obtain a feasible candidate set, establish a minimum disturbance cost model, calculate the monitoring point switching cost, start time drift cost, overdue cost and priority violation cost, and introduce bandwidth budget constraints as infeasibility determination, calculate the earliest start time and end time of the candidate combination, use a hierarchical greedy algorithm with local exchange to complete resource allocation, generate execution plan entries, and perform monitoring point overlap verification and time-sharing bandwidth budget summary verification, output execution plan and rearrangement difference list;

[0046] Step S4: Based on the queue length threshold, budget change threshold, receipt timeout threshold, and deviation threshold, the iteration is triggered. The station receipts are checked for version consistency. The arrival observation, bandwidth budget output observation, and completion observation are collected and the arrival deviation, bandwidth budget deviation, and completion deviation are calculated. If the limits are exceeded, the relevant predictions and constraints are updated. After determining the affected request subset, the preceding steps are locally called to update the sorting and execution plan. Rollback or freezing is performed when the receipts are mismatched, the check fails, or the reordering is too dense.

[0047] In step S1, the status message of the monitoring point group is accessed and the fields are normalized. The monitoring area identifier, monitoring point identifier, acquisition channel occupancy, heartbeat time, fault code, reception time, and session identifier are obtained. The heartbeat duration is calculated and compared with the heartbeat timeout threshold. The fault level is calculated and compared with the fault threshold. Unavailable monitoring points are identified and written into the unavailable set. The available time is calculated for idle monitoring points. For occupied monitoring points, the remaining observation data volume of the session and the reference conservative bandwidth budget are obtained and the release time is calculated. The available time table and status snapshot are summarized and generated. The specific contents include:

[0048] The status reports from monitoring points within the monitoring area are uniformly accessed and standardized, using the monitoring area identification results. As an index, it accesses the status messages of each monitoring point within the monitoring area and generates a reception time result for each message upon access. The message is then mapped to a unified set of fields, retaining only the monitoring point identification result. Results of channel occupancy Heartbeat timing results Fault code results Session identification results and the results of the observation increment Fields directly related to availability assessment;

[0049] Monitoring area identification results for the same monitoring point Multiple reported records are processed, but only the most recently received normalized record is retained and overwritten. Historical records are not included in subsequent criterion calculations. The latest normalized status record forms the latest status result of the monitoring point, which is used for subsequent lightweight verification, available time estimation, and available time table. With state snapshot A unified input baseline for the output;

[0050] If a monitoring point is offline, malfunctioning, or experiencing metering anomalies, even if a seemingly reasonable release time is calculated, unexecutable resources will be introduced during subsequent allocation. The three most critical unavailability criteria will be retained: heartbeat timeout, malfunction unavailability, and metering anomaly will trigger an immediate update. And uniformly use the long-term placeholder time. To avoid being selected incorrectly;

[0051] First, calculate the heart rate duration, which can be expressed using the formula: And preset the heartbeat timeout threshold result When the following conditions are met: When that happens, add the monitoring point. And its subsequent available time slots are treated as long-term placeholders;

[0052] To uniformly push the availability time of unavailable monitoring points to the future, the following calculations are performed: ;in, This is a placeholder for the long-term bias result; no further derived parameters will be expanded.

[0053] After determining the linearity, the fault status is then assessed. Faults are more directly related to non-executability and should be prioritized for elimination. The fault code results are then processed. The results are categorized into fault levels. And preset fault level threshold results When satisfied When that happens, add the monitoring point. and its subsequent available time is based on deal with;

[0054] The measurement anomaly criterion is only necessary when incremental reporting of observations is enabled in the monitoring area and this information affects the estimation of the release time; otherwise, it can be omitted to reduce coupling. If this rule is enabled, the anomalous mutation is used as a lightweight anomaly condition, defined as: And preset abnormal mutation threshold results When satisfied When that happens, add the monitoring point. , and according to deal with;

[0055] After the unavailability determination is completed, the availability time is a hard constraint for subsequent sequencing and allocation, and must be based on the premise that schedulability has been confirmed.

[0056] when When a monitoring point is idle, first check whether the monitoring point belongs to [the relevant category / region]. ,like Then let and will Write ,like If so, do not write. Write directly ;

[0057] when Characterizing the occupancy of monitoring points and When valid, the occupied monitoring points cannot be immediately allocated, and it is necessary to convert the release time into a calculable constraint. To reduce parameters, this embodiment only retains a reproducible conclusive process as follows:

[0058] The remaining observation data volume is obtained from the monitoring data warehouse or the monitoring data warehouse. It is obtained by subtracting the completed pending data volume from the session target observation data volume. If the difference is negative, it is treated as zero.

[0059] The conservative reporting rate upper limit is obtained by multiplying the smaller value of the monitoring point's rated capacity, the current allocable bandwidth budget of the monitoring area, and the processing resource budget by a conservative coefficient.

[0060] The estimated remaining duration is obtained by dividing the remaining amount of observation data by the conservative upper limit of the reporting rate, and then added to the current time. Obtain the expected end time;

[0061] If there is a task deadline, the release time is the smaller value between the expected end time and the task deadline; if there is no task deadline, the release time is the expected end time.

[0062] If key session information is missing or the monitoring point belongs to Then press directly at the release time. The time when the monitoring point is finally released after being written is recorded as follows. and write ;

[0063] The availability results scattered across various monitoring points are aggregated and output as an availability timetable and status snapshot. The server generates an availability timetable for all monitoring points within the monitoring area. Each record retains only the fields required for this step, including the monitoring area identifier. Monitoring point signage Results of channel occupancy And available time results, where the monitoring point is idle when written. Write when monitoring point is occupied Write when monitoring point is unavailable Simultaneously, an unavailable flag is written, which is used by the monitoring point to indicate whether the GID belongs to the unavailable set. Obtain directly;

[0064] After the table output is complete, the server generates a state snapshot result. Snapshots are taken according to the monitoring area identifier. With this round of version number The organization only solidifies the current version number Ver0, the bandwidth budget results for the monitoring area, and... and The summary information is used to ensure that subsequent priority calculations, minimum perturbation rearrangements, and event-driven iterations all reference the same traceable state input.

[0065] In step S2, a reporting arrival prediction model is established, and the reporting arrival prediction time and reporting arrival uncertainty are calculated. Based on the monitoring area bandwidth budget and available timetable, a reference conservative bandwidth budget is calculated, along with the expected processing delay and expected warning generation time. Time margin is calculated and mapped to urgency. Confidence is calculated, waiting compensation is calculated, and fairness penalties are calculated. Priorities are calculated using a weighted fusion algorithm and standardized. A sorted ranking table is generated, and strong cooperative sets and ordinary sets are divided based on confidence thresholds and urgency thresholds. Specific content includes:

[0066] In step S1, the status of monitoring points within the monitoring area has been normalized, unavailability has been determined, and the results have been output. , as well as Next, this step involves priority calculation and sequence table generation. Since priority is not simply a matter of monitoring objects arriving first and being served first, but must be calculated in a comparable manner in combination with the current available resources and bandwidth budget boundaries of the monitoring area, otherwise a situation may occur where the sorting is reasonable but not executable. First, the requests of the monitoring objects are structured into computable files, then the basic predictions of the arrival of reports and the expected processing delay are introduced, followed by the calculation of urgency, credibility, waiting compensation and fairness constraints, and finally the formation of comparable priority values ​​and the output of the sequence table, while generating a set of stable constraints.

[0067] Before any sorting, the reported source requests need to be transformed into a request file with the same scope. Different monitored objects may report missing fields or have different expressions. If the data is not structured first, the subsequent calculations of urgency and credibility cannot be performed consistently. After receiving the early warning judgment task submitted by the monitored object, the result at the time of request submission is generated. The minimum required field set is parsed and formed. If the monitored object provides equipment health profile, historical stability profile or data reporting arrival information at the same time, it is written into the extension area only as an optional profile field.

[0068] Subsequently, the number of missed reports for this monitored object was retrieved from the historical stability profile database. Results of the number of late reports Report time series stability results The results of forming a reliable feature set of the monitored object by combining the near-end context can be expressed as follows: ,Will Write the results to the alarm handling task queue and will This request is associated with storage for reference in subsequent credibility calculations;

[0069] The order in which requests are submitted alone cannot determine whether the deadline will be met. Therefore, it is necessary to introduce a basic prediction of the reported arrival time and the estimated processing delay before sorting. The predicted arrival time is generated based on the link delay or historical data of the monitoring area. And give the prediction uncertainty results. , It can be obtained from the dispersion of historically reported arrival errors on the same road segment;

[0070] Subsequently, to ensure that the predicted processing delay is consistent with the boundary of the monitoring area in step S1, a status snapshot output in step S1 is read. The monitoring area budget information, combined with the current available monitoring points, is used to... The bandwidth budgeting capability within the budget forms a reference conservative bandwidth budget result. , for satisfying Furthermore, for monitoring points whose acquisition channel types are compatible, a representative value of their conservative bandwidth budget estimate is taken, and truncated under the budget constraint of the monitoring area, to obtain... ;

[0071] Based on this, the expected processing delay is calculated: And calculate the expected time of warning generation: This allows subsequent urgency calculations to be based on whether the deadline is expected, rather than approximating it with the amount of static observation data.

[0072] To make priorities interpretable and adjustable, priorities are divided into four components, corresponding to deadline constraints, fulfillment reliability, waiting time, and fairness constraints, respectively. The reason for this decomposition is to clarify which requests can be sacrificed and which requests should be prioritized when performing minimum disturbance rearrangement in step S3, thereby reducing frequent rollbacks.

[0073] Calculation results of time margin: Two margin segmented threshold results are introduced. and And a segmented approach is used to map Slack to urgency results. It can be directly written in the following formula-insertable form: Among them, when (Slack<0) it indicates that the deadline is expected to be exceeded, and the urgency level is taken as a high value; when Slack is large, the urgency level tends to be low.

[0074] Credibility results To characterize the stability of the request's arrival and execution according to the planned data, and to avoid frequent disturbances in step S3 caused by repeatedly writing high-uncertainty requests into the plan, the historical stability profile and the reported arrival uncertainty are first normalized to a dimensionless quantity: (Intensity result is then cancelled.) Results of the intensity of no-show On-time stability results Uncertain reduction results For count-type indicators, normalize them according to the window length; for proportional-type indicators, use the original value directly; and for uncertainty, normalize it after truncation by the upper limit.

[0075] Credibility results The calculation can be expressed by the formula: ;in, The reduction factor is preset according to the monitoring area strategy. This formula ensures that the more cancellations and no-shows there are, the greater the uncertainty of the reported arrival, the lower the credibility, and the higher the on-time rate, the higher the credibility.

[0076] Awaiting compensation results This is used to suppress the continuous pressure on long-waiting monitored objects, and calculates the current waiting time for requests already in the queue. Subtract the request submission time from the current time. get Introducing the upper limit of compensation results And calculate: This allows the compensation to increase with the waiting period but eventually saturate, facilitating subsequent weight adjustments.

[0077] Fair punishment results This is used to constrain the systematic bias caused by the same monitoring object repeatedly dominating or interrupting within a short window, and to maintain the results of the number of delays within the most recent window. Results of cumulative delay and classify them as ,right Normalize according to the window limit, Normalize the maximum acceptable delay time for the monitoring area, then sum and truncate to obtain the result. Based on this, calculate: When a monitored object has been delayed significantly recently, the penalty can be designed as a reverse penalty to improve its ranking; when a monitored object has repeatedly dominated recently, the penalty is positive to suppress its continued dominance.

[0078] After obtaining the four components, set the weight set result: Different monitoring areas have different preferences for timely completion, stable performance, and fair waiting under different congestion conditions, based on the results of the alarm handling task queue length. Cong generates congestion results, which can be accessed by clicking [button / button]. The monotonic rule that the larger the value of Cong, the larger the value of Cong becomes is obtained, and the weights are adaptively adjusted accordingly: when Cong increases, the weights are increased. And inhibit The growth of Cong; when Cong decreases, the normal weight is restored;

[0079] Then, the priority value is calculated: To facilitate comparisons across monitoring areas and time periods, the PRI values ​​within the same iteration are standardized to obtain standardized priority results. The standardization method can be linear normalization, which provides an insertable formula form: ;in and These are the maximum and minimum priority values ​​in the queue for this round. To prevent extremely small constant results with a denominator of zero;

[0080] according to Sort the results from highest to lowest to generate a sorted list. When there are ties, in order to avoid introducing too many new parameters, three fixed ties breaking rules are adopted: the one that was submitted earlier is given priority; if they are still tied, the one with smaller observation data volume is given priority; if they are still tied, the one with a narrower data type matching range is given priority.

[0081] Preset confidence threshold results Results with Urgent Threshold And partition the set according to the following criteria, when the following conditions are met. And satisfy If so, then the result of the request will be identified. Results of adding strong collaborative candidate sets Otherwise, add the result to the normal set. ;

[0082] After the set is partitioned, , , as well as Keep in the same iteration version In the context of this, so that step S3 can directly reference and trace the corresponding input baseline when an event is triggered.

[0083] In step S3, the available timetable and unavailable set are read, and a candidate monitoring point set is constructed for each request. Feasible candidate sets are obtained by filtering according to data type matching, availability, and intra-area scheduling strategy. A minimum disturbance cost model is established to calculate the monitoring point switching cost, start time drift cost, overdue cost, and priority violation cost. Bandwidth budget constraints are introduced as an infeasibility criterion. The earliest start and end times of the candidate combinations are calculated. A hierarchical greedy algorithm with local switching is used to complete resource allocation, generating execution plan entries. Monitoring point overlap verification and time-sharing bandwidth budget summary verification are performed. The execution plan and rearrangement difference list are output, including:

[0084] Perform minimum disturbance rearrangement and execution plan generation within the budget boundary of the monitoring area. Transform into actionable execution plans. And update the existing plan with minimal disturbance when an event is triggered;

[0085] We need to first generate a set of feasible candidate monitoring points for each request, and the unavailable monitoring points have been identified. If the available time for each monitoring point is not filtered first, subsequent solutions will repeatedly attempt to access unavailable resources, causing plan instability. and For each request Results of constructing candidate monitoring point set And filter according to the following rules:

[0086] If the monitoring point collects channel type results Results required by task data type If it does not match, then... Do not enter the candidate set;

[0087] like Then the Not included in the candidate set; if the monitoring point is in Available time in , are also considered unusable and removed;

[0088] If a monitoring point has an intra-area scheduling policy identifier, the candidate set will be retained or flow limited according to the policy; this policy can be directly determined by the monitoring area configuration.

[0089] The results of filtering yielded a feasible candidate set. .like If empty, an unsatisfiable flag result is generated. The request is downgraded: it remains in the alarm handling task queue, but no execution plan entry is generated in this round. At the same time, an alarm event is generated for step S4 to notify the monitored object to change the station or time period.

[0090] To ensure the new plan closely approximates the previous version's plan while meeting resource and bandwidth budget constraints, the execution plan results from the previous version are maintained. Furthermore, the changes to the plan were broken down into quantifiable cost items;

[0091] For the same request If the newly assigned monitoring point differs from the old one, a switching cost will be incurred. If the change at the start time exceeds the tolerance window result... This results in a time drift cost. To provide an insertable formula, we define the monitoring point switching indicator and the time drift: ;

[0092] And define the time drift penalty: The cost of the change can then be written as: ,in To change the weighting results;

[0093] Delay cost is used to reflect whether the expected completion date has been exceeded, and the amount of delay is defined as follows: ,but: ;in, To delay the weighting results;

[0094] To avoid high The request was placed after a significantly lower priority request, and the priority difference threshold was set. For any adjacent sorted pairs ,in Later in the plan ,definition: And define the violation of the instruction: ;but: ;in This violates the weighting results;

[0095] The bandwidth budget constraint is a hard constraint; if it is violated, the plan cannot be executed. The total bandwidth budget is calculated for discrete time slice t: Where A(t) represents the set of plan entries in the execution state at time slice t, and the over-limit is defined as: When there exists any time slice that satisfies At that time, it is considered infeasible and subject to a very high cost M: ;

[0096] Based on the above cost terms, the total objective cost is defined as follows: ;in The total weight result, to reflect the constraint effect of the output set in step S2, is... Internal requests are assigned a higher delay weight, making the system more inclined to guarantee high-reliability, high-urgency requests; for The internal request sets a higher tolerance for changes, making it a perturbable buffer layer;

[0097] After the cost function is defined, the schedule is arranged within the rolling time window result H, incorporating the discrete time slice result. The reason for dividing the future timeline is that bandwidth budget and concurrency constraints need to be examined in the time dimension, and discretization allows for direct statistical analysis. And verify it;

[0098] For each request With each candidate monitoring point Calculate the earliest possible start time result Since step S1 provides information on idle monitoring points Give the following information regarding the occupation of monitoring points: The time is uniformly written as the available reference time for the monitoring point. The rule for its value is: if the monitoring point is idle, then... If the monitoring point is occupied, then ,but: Meanwhile, based on the expected processing delay results of step S2 Construct the expected end time under this candidate allocation and define the adjustment factor results. The adjusted duration is as follows: And obtained: ;

[0099] To reduce disturbances and prioritize critical requests, a layered approach is adopted:

[0100] First layer: according to Sequential traversal Internal requests, for each In its Enumerate several candidates within the available time slice range Combinations, prioritizing those that... The minimum combination that does not violate the bandwidth budget constraint forms the initial allocation result of the strong set. If a strong set request has no feasible combinations, then it is marked as And keep it in the queue to wait for the next iteration;

[0101] Second layer: To The internal request uses a greedy allocation to form the initial allocation result. The greedy rule is: without violating the bandwidth budget constraint, prioritize the combination that can start earliest and has the lowest change cost to make the plan stable;

[0102] The third layer: Performs local swaps on the overall allocation to further reduce costs, identifies the requests causing the greatest delay cost, and attempts to swap or postpone them with requests from adjacent time periods or adjacent monitoring points. If the swap results in a delay... If the result decreases, it is accepted. To control the number of iterations, a preset improvement threshold is set. When the cost reduction resulting from a series of consecutive exchanges does not exceed Stop at this time;

[0103] After obtaining the final assignment result (Assign), construct the execution plan result. , The target bandwidth budget result for this entry in each time slice is determined by the monitoring area bandwidth budget allocator based on the desired bandwidth. , and Calculated under constraints;

[0104] If a constant bandwidth budget is used, it can be It is denoted as a constant; if a segmented bandwidth budget is used, it can be denoted as a segmented sequence, but its segmented form is not expanded in this step;

[0105] Layered solution and local switching may introduce monitoring point conflicts or local bandwidth budget overruns. If the data is not checked and sent directly, it will generate non-executable feedback on the execution side in step S4 and trigger frequent rollbacks.

[0106] Inspect the same monitoring point If there is a time overlap between the planned items, the plan is deemed infeasible, and the plan is rolled back to the previous feasible solution or the conflicting items are postponed and then rechecked.

[0107] Statistics by discrete time slice If there exists any time slice that satisfies: Or satisfy This will trigger a reduction in bandwidth budget or a delay strategy, and update accordingly. and Continue until the constraint is met; if it cannot be met within the scrolling window H, then set the relevant request... ;

[0108] After verification, output the execution plan results for the current version. And generate a list of rearranged differences. ,in Record the key changes compared to the previous version, which will be used as the basis for versioning, verification, and rollback in step S4.

[0109] In step S4, iteration is triggered based on queue length threshold, budget change threshold, receipt timeout threshold, and deviation threshold. Version consistency is checked on the station-side receipts. Arrival observations, bandwidth budget output observations, and completion observations are collected, and arrival deviations, bandwidth budget deviations, and completion deviations are calculated. If limits are exceeded, relevant predictions and constraints are updated. After determining the affected request subset, the preceding steps are locally called to update the sorting and execution plan. Rollback or freezing is performed when receipts mismatch, verification fails, or reordering is too dense. Specific details include:

[0110] Not every state change during the execution of the plan is worth reordering. First, classify the events and set triggering criteria. Only start the iteration when the event meets the condition that will change the executability or the ordering basis.

[0111] Access and standardize event type results Record the event time for each event. Associated objects and generate event sequence results. ;

[0112] When satisfied When this happens, an iteration is triggered to suppress the continued accumulation of queues in a congested state;

[0113] Calculation of budget change results When satisfied When this happens, an iteration is triggered to ensure that the bandwidth budget constraint is consistent with the plan;

[0114] An iteration is triggered when a receipt times out or an execution deviation exceeds the limit, in order to avoid a plan existing but not being executed at the station.

[0115] After triggering an iteration or generating a plan for the first time, the plan distribution data needs to be reported to the receiving end and the monitoring object side. If the station does not accept or executes the old version, any subsequent rearrangement based on the new version will be out of touch with the actual situation.

[0116] right Generate plan summary results and will The system will be issued along with the plan, and the station and the monitored objects will return feedback results. , ;

[0117] Define the waiting time for the site-side receipt: When satisfied and If the timeout occurs, it is determined to be a receipt timeout event and a rollback is initiated.

[0118] when At the same time, verify whether the version number in the site's response receipt matches the summary: if the version number in the site's response receipt is not equal to... Or the abstract is not equal to If the error occurs, it is determined to be a version mismatch event, and a rollback is initiated to prevent multiple versions from executing in parallel.

[0119] Key deviations are collected and threshold criteria are used to determine whether to update. Three types of deviations are used: reported arrival deviation, bandwidth budget deviation, and completion deviation.

[0120] Report arrival deviation results: When satisfied This triggers a reported arrival model correction: replacing or correcting subsequent prediction uncertainties with observed reported arrivals. And update the reported time-series stability statistics of the monitored object;

[0121] Bandwidth budget deviation results: When satisfied If this occurs, a bandwidth budget correction is triggered: the available time estimate of the monitoring point in step S1 is adopted with a more conservative bandwidth budget reference, and the bandwidth budget violation cost is increased in the next round of step S3, thereby reducing the probability that the monitoring point is selected first.

[0122] Completed deviation results: When satisfied Then, a duration-based correction is triggered: the estimated processing delay statistics are written back using the observed early warning time, thereby correcting the delay in the next step S2. The basis for estimation;

[0123] In addition, a window-based determination is used for cases where the timeout has not yet occurred, and the duration of the reported timeout is defined: When satisfied If the timeout occurs, it is determined to be a reporting timeout event, and the monitoring object is updated. And release the reserved resources it occupies, while reducing its value in the next round, step S2. ;

[0124] For task cancellation events of monitored objects, update the result of the number of missing reports. and will send the request from and Remove from candidates;

[0125] When an event is triggered and the receipt and deviation criteria require an update, instead of directly performing a full rearrangement, the affected subset is first determined and then steps S1 to S3 are called for a partial update.

[0126] When event-related monitoring points fail, bandwidth budgets deviate, or release times change, all events will be affected. The middle allocation to this And its Requests falling within the scroll window H are added. When an event is a new request report arrival or cancellation, only the request and its associated information are reported. Several neighboring requests joined ;

[0127] Only for the monitoring areas involved Perform a lightweight update in step S1: reread the relevant monitoring points. , , And update Corresponding If the fault is resolved, the entry is removed according to the criteria in step S1. And restore its availability; if a budget change triggers, update. The budget field in the database and the new version baseline are generated. ;

[0128] Only for Internal request to recalculate , as well as and partial updates The relative order in the middle, for satisfying and The request remains in The rest remain ;

[0129] by With the updated , For input only Perform minimum perturbation rearrangement on the relevant entries and output the new version. List of differences ;

[0130] In high-frequency events or unstable site scenarios, frequent iterations can cause plan oscillations. Therefore, this step sets up a rollback and freeze mechanism. When the new version cannot be confirmed by the site or fails to be verified, it should be quickly restored to the previous feasible version.

[0131] A rollback is triggered when any of the following conditions are met. :

[0132] Receipt timed out: and ;

[0133] Version mismatch: The website's version number is not equal to... Or the abstract is not equal to ;

[0134] Verification failed: There exists an arbitrary time slice that satisfies... or Furthermore, the over-limit cannot be eliminated even within the allowed bandwidth reduction budget and the number of delayed adjustments;

[0135] During rollback, the current version is marked as unavailable and the previous version is restored, while the difference list is retained for subsequent auditing;

[0136] In the window Internal statistical rearrangement results When satisfied When the time comes, it enters the freeze mode: only hard events are processed in the freeze window, and soft events are only updated in the queue and file but do not trigger step S3 reordering. The freeze is lifted after the state returns to stability.

[0137] If no receipt timeout or bandwidth budget overrun events occur for a continuous period of time, the freeze will be lifted and normal iteration will resume.

[0138] A set of current plan versions that have completed consistency verification and can be identified by the execution side is obtained, and the event judgment results and deviation correction results corresponding to the version are obtained simultaneously. This allows each subsequent state refresh, sequence update and plan reordering to be referenced and traced based on the same version baseline. At the same time, controlled iterative decision results are formed for situations such as abnormal receipts, excessive bandwidth budget, and excessive reporting arrival deviation. This enables the system to stop the spread and fall back to the executable state in a timely manner when the execution conditions are not met, and to perform only a partial update on the affected scope when the execution conditions are met, thereby maintaining the long-term consistency of the correspondence between the plan version, on-site execution and state snapshot.

[0139] This invention discloses an intelligent early warning system for dam hazards based on multi-source sensor data fusion, comprising: a situation snapshot module, a priority sequencing module, a minimum disturbance scheduling module, and an event iteration rollback module, with signal connections between the modules;

[0140] The status snapshot module receives status messages from the monitoring point group and normalizes the fields. It obtains the monitoring area identifier, monitoring point identifier, acquisition channel occupancy, heartbeat time, fault code, reception time, and session identifier. It calculates the heartbeat timeout and compares it with the heartbeat timeout threshold. It calculates the fault level and compares it with the fault threshold. It determines unavailable monitoring points and writes them into the unavailable set. It calculates the available time for idle monitoring points. For occupied monitoring points, it obtains the remaining observation data volume of the session and the reference conservative bandwidth budget and calculates the release time. It summarizes and generates an available time table and status snapshot.

[0141] Priority sorting module: Establishes a reporting arrival prediction model and calculates the reporting arrival prediction time and reporting arrival uncertainty; calculates a reference conservative bandwidth budget based on the monitoring area bandwidth budget and available timetable, and calculates the expected processing delay and expected warning generation time; calculates time margin and maps urgency; calculates credibility; calculates waiting compensation; calculates fair penalty; calculates priority according to weighted fusion algorithm and standardizes it; sorts and generates a sorting table; and divides the strong cooperative set and ordinary set according to credibility threshold and urgency threshold.

[0142] Minimum Disturbance Scheduling Module: Reads the available timetable and unavailable set, constructs a candidate monitoring point set for each request, filters feasible candidate sets by data type matching, availability and intra-area scheduling strategy, establishes a minimum disturbance cost model, calculates monitoring point switching cost, start time drift cost, overdue cost and priority violation cost, and introduces bandwidth budget constraints as infeasibility determination, calculates the earliest start time and end time of candidate combinations, completes resource allocation using a hierarchical greedy algorithm with local switching, generates execution plan entries, performs monitoring point overlap verification and time-sharing bandwidth budget summary verification, and outputs execution plan and rearrangement difference list;

[0143] The event iteration rollback module determines the trigger for iteration based on queue length thresholds, budget change thresholds, receipt timeout thresholds, and deviation thresholds. It performs version consistency checks on station-side receipts, collects and calculates arrival, bandwidth budget output, and completion observations, and calculates arrival, bandwidth budget, and completion deviations. If limits are exceeded, relevant predictions and constraints are updated. After identifying the affected request subset, it locally calls previous steps to update the sorting and execution plan. Rollback or freezing is performed when receipts mismatch, verification fails, or reordering is too dense. The above formulas are all dimensionless numerical calculations, derived from software simulations using collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art based on actual conditions.

[0144] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0145] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and inventive constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0146] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0147] 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 conceived 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.

[0148] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for intelligent early warning of dam hazards based on multi-source sensor data fusion, characterized in that, Includes steps; Step S1: Access the status message of the monitoring point group and complete field normalization; obtain the monitoring area identifier, monitoring point identifier, acquisition channel occupancy, heartbeat time, fault code, reception time and session identifier; calculate the heartbeat timeout and compare it with the heartbeat timeout threshold; calculate the fault level and compare it with the fault threshold; determine unavailable monitoring points and write them into the unavailable set; calculate the available time for idle monitoring points; obtain the remaining observation data volume and reference conservative bandwidth budget for occupied monitoring points and calculate the release time; summarize and generate an available time table and status snapshot. Step S2: Establish a reporting arrival prediction model and calculate the reporting arrival prediction time and reporting arrival uncertainty. Calculate the reference conservative bandwidth budget based on the monitoring area bandwidth budget and available timetable, and calculate the expected processing delay and expected early warning generation time. Calculate the time margin and map the urgency. Calculate the credibility, calculate the waiting compensation, calculate the fair penalty, calculate the priority according to the weighted fusion algorithm and standardize it. Sort and generate a sorted table, and divide the strong cooperative set and ordinary set according to the credibility threshold and urgency threshold. Step S3: Read the available timetable and the unavailable set, construct a candidate monitoring point set for each request, filter by data type matching, availability and intra-area scheduling strategy to obtain a feasible candidate set, establish a minimum disturbance cost model, calculate the monitoring point switching cost, start time drift cost, overdue cost and priority violation cost, and introduce bandwidth budget constraints as infeasibility determination, calculate the earliest start time and end time of the candidate combination, use a hierarchical greedy algorithm with local exchange to complete resource allocation, generate execution plan entries, and perform monitoring point overlap verification and time-sharing bandwidth budget summary verification, output execution plan and rearrangement difference list; Step S4: Based on the queue length threshold, budget change threshold, receipt timeout threshold, and deviation threshold, the iteration is triggered. The station receipts are checked for version consistency. The arrival observation, bandwidth budget output observation, and completion observation are collected and the arrival deviation, bandwidth budget deviation, and completion deviation are calculated. If the limits are exceeded, the relevant predictions and constraints are updated. After determining the affected request subset, the preceding steps are locally called to update the sorting and execution plan. Rollback or freezing is performed when the receipts are mismatched, the check fails, or the reordering is too dense.

2. The intelligent early warning method for dam hazards based on multi-source sensor data fusion according to claim 1, characterized in that, Monitoring points identified as out of contact or severely malfunctioning will be marked as unavailable. Specifically, this includes: If the heartbeat duration of a certain monitoring point is greater than the heartbeat timeout threshold, then the monitoring point is determined to be out of contact. If the fault level of a certain monitoring point is higher than the fault threshold, then the monitoring point is determined to be in a serious fault state. Add the monitoring points that are in any of the above states to the unavailable set.

3. The intelligent early warning method for dam hazards based on multi-source sensor data fusion according to claim 2, characterized in that, For a monitoring point whose status is occupied, the estimated release time is calculated as follows: the estimated release time is obtained by calculating based on the remaining amount of observation data and the reference conservative bandwidth budget, and the result is recorded as the available time of the monitoring point in the available time table.

4. The intelligent early warning method for dam hazards based on multi-source sensor data fusion according to claim 1, characterized in that, The weighted fusion algorithm is used to merge multiple scores into a comprehensive priority score. This is achieved by pre-setting a weight coefficient for each score and performing a linear weighted combination.

5. The intelligent early warning method for dam hazards based on multi-source sensor data fusion according to claim 4, characterized in that, The specific steps for dividing strongly cooperative sets into ordinary cooperative sets are as follows: Early warning judgment tasks whose credibility score is higher than the credibility threshold and whose urgency score is higher than the urgency threshold are included in the strong collaboration set; The remaining early warning and discrimination tasks are categorized into the general collaborative set.

6. The intelligent early warning method for dam hazards based on multi-source sensor data fusion according to claim 1, characterized in that, Filtering the initial candidate monitoring point set includes: first, screening monitoring points that match the requested acquisition channel type; second, excluding monitoring points belonging to the unavailable set; and finally, filtering according to the strategy specified for the monitoring area, which includes prioritizing the allocation of monitoring points within the same monitoring area or avoiding specific combinations of monitoring points.

7. The intelligent early warning method for dam hazards based on multi-source sensor data fusion according to claim 6, characterized in that, The resource allocation using a hierarchical greedy strategy combined with a local exchange optimization algorithm specifically includes: According to the order of the sorting table, for each request in the strong cooperation set, the monitoring point that minimizes the incremental cost calculated by the current cost model is selected from its set of feasible candidate monitoring points for pre-allocation; The same strategy is used to pre-allocate requests in the ordinary collaborative set; Based on the pre-allocated plan, try to swap monitoring points for tasks in adjacent or similar time periods. If the swap reduces the overall cost and does not violate constraints, then adopt the swap.

8. The intelligent early warning method for dam hazards based on multi-source sensor data fusion according to claim 1, characterized in that, Deviation thresholds include independent reporting arrival time deviation thresholds, bandwidth budget deviation thresholds, and completion time deviation thresholds; Updating the corresponding prediction model or constraints includes: calibrating the parameters of the reported prediction model using the actual observation data, or adjusting the calculation logic of the reference conservative bandwidth budget using the actual observation bandwidth budget.

9. The intelligent early warning method for dam hazards based on multi-source sensor data fusion according to claim 1, characterized in that, Performing a rollback or freeze operation specifically includes: when the plan version number of the site-side receipt is inconsistent with the version number of the locally executed plan, discarding the receipt and maintaining the original plan; When the number of reorderings triggered per unit time exceeds a preset frequency threshold, the rescheduling of the affected request subset is suspended, and its original allocation scheme remains unchanged.

10. A smart early warning system for dam hazards based on multi-source sensor data fusion, used to implement the smart early warning method for dam hazards based on multi-source sensor data fusion as described in any one of claims 1-9, characterized in that... ； The status snapshot module receives status messages from the monitoring point group and normalizes the fields. It obtains the monitoring area identifier, monitoring point identifier, acquisition channel occupancy, heartbeat time, fault code, reception time, and session identifier. It calculates the heartbeat timeout and compares it with the heartbeat timeout threshold. It calculates the fault level and compares it with the fault threshold. It determines unavailable monitoring points and writes them into the unavailable set. It calculates the available time for idle monitoring points. For occupied monitoring points, it obtains the remaining observation data volume of the session and the reference conservative bandwidth budget and calculates the release time. It summarizes and generates an available time table and status snapshot. Priority sorting module: Establishes a reporting arrival prediction model and calculates the reporting arrival prediction time and reporting arrival uncertainty; calculates a reference conservative bandwidth budget based on the monitoring area bandwidth budget and available timetable, and calculates the expected processing delay and expected warning generation time; calculates time margin and maps urgency; calculates credibility; calculates waiting compensation; calculates fair penalty; calculates priority according to weighted fusion algorithm and standardizes it; sorts and generates a sorting table; and divides the strong cooperative set and ordinary set according to credibility threshold and urgency threshold. Minimum Disturbance Scheduling Module: Reads the available timetable and unavailable set, constructs a candidate monitoring point set for each request, filters feasible candidate sets by data type matching, availability and intra-area scheduling strategy, establishes a minimum disturbance cost model, calculates monitoring point switching cost, start time drift cost, overdue cost and priority violation cost, and introduces bandwidth budget constraints as infeasibility determination, calculates the earliest start time and end time of candidate combinations, completes resource allocation using a hierarchical greedy algorithm with local switching, generates execution plan entries, performs monitoring point overlap verification and time-sharing bandwidth budget summary verification, and outputs execution plan and rearrangement difference list; Event Iteration Rollback Module: Based on queue length threshold, budget change threshold, receipt timeout threshold and deviation threshold, it determines the trigger for iteration, performs version consistency verification on station receipts, collects and reports arrival observations, bandwidth budget output observations, and completion observations, and calculates the reporting arrival deviation, bandwidth budget deviation and completion deviation. If the limits are exceeded, it updates the relevant predictions and constraints. After determining the affected request subset, it locally calls the preceding steps to update the sorting and execution plan, and performs rollback or freeze when receipt mismatch, verification failure or reordering is too dense.

Images