Full-link linkage control and service callback method based on event priority queue

Abstract

The application relates to a full-linkage control and service callback method based on an event priority queue, relates to the technical field of intelligent monitoring, and is characterized in that a plurality of source heterogeneous alarm signals are uniformly formatted into a standard structure carrying a target cloud table position and resource demand estimation, the queue is recalculated and reordered at a preset period according to dynamic characteristic dimensions, a conflict of a queue head event with a current processing event on a cloud table control right and an encoder channel is detected, a resource pre-locking is selected and executed after a dissolving strategy is selected, a cloud table mechanism and an external linkage equipment are driven to complete physical action, a stage callback message is generated according to a physical execution state, is pushed through a subscription interface and receives callback feedback, a recalculation step is returned when the physical execution state or the callback feedback changes until the event is closed. The application reduces the situation that a processing link is interrupted due to single-link blockage, and improves the state synchronization between a physical execution component and an external service system.

Description

Technical Field

[0001] This application relates to the technical field of intelligent monitoring, and in particular to a method for end-to-end linkage control and business callback based on event priority queues. Background Technology

[0002] With the deepening application of IoT and AI technologies in outdoor infrastructure scenarios such as towers, base stations, and power transmission lines, intelligent maintenance camera equipment needs to simultaneously process alarm events from multiple sources such as video analysis, physical sensors, and external platforms in complex environments. It also needs to drive physical execution components such as pan-tilt units, encoders, and linked peripherals to complete a series of actions such as alignment, tracking, recording, uploading, and linkage notification, thereby achieving response to on-site targets and end-to-end management.

[0003] Existing intelligent monitoring and alarm scheduling solutions typically pre-set priority levels according to event type. Events are queued according to their priority and then scheduled sequentially. During the processing, physical actions such as PTZ control, encoding, recording, uploading, and linkage are carried out sequentially with external business systems according to a preset process.

[0004] However, in multi-source concurrent alarm scenarios, intelligent monitoring devices using the above solutions suffer from high alarm response latency and the alarm processing link is prone to suspension or interruption during physical execution or external business integration. Specifically, the time from alarm triggering to PTZ completing physical alignment is long, and this time is further exacerbated when multiple alarm events arrive simultaneously; when multiple events involve physical resources such as PTZ control and encoder channels, resource contention can easily occur during physical execution, leading to processing link interruptions; furthermore, if the physical execution stage is blocked due to network jitter, slow response from external devices, or other reasons, subsequent processing stages will be suspended for a long time, making it difficult for external business systems to know the actual processing progress during this period, thus affecting the overall completion rate of alarm from triggering to closure. Summary of the Invention

[0005] This application provides a method for end-to-end linkage control and business callback based on event priority queues to solve the problem that existing alarm processing links are prone to suspension or interruption in the physical execution stage or external business integration stage.

[0006] Firstly, this application provides a method for end-to-end linkage control and business callback based on event priority queues, applied to intelligent monitoring equipment, the method comprising:

[0007] Alarm signals from multiple heterogeneous event sources are collected, and each alarm signal is converted into a unified event data structure carrying the target gimbal location and resource demand estimation to obtain the event to be processed.

[0008] A weighted calculation is performed based on the dynamic feature dimensions of the events to be processed to obtain a comprehensive priority score. The comprehensive priority scores of all events to be processed in the queue are recalculated and reordered at a preset period to obtain a priority event queue.

[0009] Extract the head event from the priority event queue, detect the physical resource conflict between the head event and the currently processed event on the PTZ control and encoder channel, select a resolution strategy based on the conflict characteristics, and perform resource pre-locking based on the estimated resource requirements to determine the execution event;

[0010] Based on the target gimbal position of the execution event, the gimbal mechanism is driven to complete physical alignment and target tracking, and based on the type of the execution event, external linkage devices are driven to perform physical linkage actions, thereby obtaining the physical execution status reflecting each processing stage;

[0011] Based on the physical execution state, a stage callback message carrying an event identifier, the current stage, and the stage state is generated. The stage callback message is pushed to the subscribed external business system through the subscription interface to obtain the callback feedback from the external business system.

[0012] When the physical execution state or the callback feedback changes, the step of performing a weighted calculation based on the dynamic feature dimensions of the event to be processed to obtain a comprehensive priority score is returned to update the priority event queue until the execution event reaches the closed state.

[0013] In the above embodiments, this application first formats alarm signals from multiple heterogeneous event sources into a standard data structure carrying the target gimbal position and resource requirement estimates. Then, it performs weighted calculations based on dynamic feature dimensions and recalculates and reorders the priority scores of all pending events in the queue in real time at a preset period. Next, starting from the first event in the queue, it detects physical resource conflicts between the event and the currently processed event in terms of gimbal control and encoder channels, selects appropriate resolution strategies, and performs resource pre-locking. Then, it drives the gimbal mechanism to complete physical alignment and target tracking according to the execution events, drives external linkage devices to perform physical linkage actions, and generates data based on the physical execution status. The phased callback messages are pushed to external business systems through the subscription interface, and their callback feedback is received. Finally, when the physical execution status or callback feedback changes, the priority recalculation step update queue is returned until the event reaches the closed state. This not only improves the response latency and resource conflict issues under multi-source concurrency through dynamic priority recalculation and physical resource pre-locking, but also forms a complete closed loop of physical execution - business callback - scheduling recalculation by using the physical execution status and external business callback feedback as feedback quantities to participate in scheduling decisions. This reduces the occurrence of interruptions in the processing link due to blockage of a single link and improves the state synchronization between the physical execution component and the external business system.

[0014] In some embodiments, the step of collecting alarm signals from multiple heterogeneous event sources and converting each alarm signal into a unified event data structure carrying the target gimbal location and resource requirement estimation to obtain the event to be processed specifically includes:

[0015] Collect alarm signals from at least two of the following event sources: AI analysis module event source, sensor event source, external alarm subscription event source, operation and maintenance platform command event source, and periodic event source;

[0016] All alarm signals are uniformly converted into a standard event data structure to obtain the events to be processed; the standard event data structure includes at least a unique event identifier, event type, event source, event generation timestamp, comprehensive priority score, target PTZ location, threat level, scene identifier, confidence score, extended data fields, and resource requirement estimation fields.

[0017] In the above embodiments, this provides a unified input basis for subsequent multi-dimensional priority evaluation and physical resource pre-allocation, and also improves the problem of missing scheduling information caused by field differences between different event sources, thereby improving the comparability and scheduling accuracy of multi-source heterogeneous alarms in the same queue.

[0018] In some embodiments, the step of performing a weighted calculation based on the dynamic feature dimensions of the event to be processed to obtain a comprehensive priority score specifically includes:

[0019] Obtain the threat level score, urgency score, scenario importance score, historical frequency score, and confidence score of the event to be processed;

[0020] The weight coefficients for each dimension are determined based on the current scenario mode, and the comprehensive priority score is obtained by weighted summation according to the following formula: ;in, Scoring based on threat level; Scoring is based on the urgency level. Score the importance of the scene; Scoring is based on historical frequency. Scoring for the confidence dimension; , , , , These are the corresponding weighting coefficients.

[0021] In the above embodiments, this application obtains the normalized scores of the event to be processed under five dimensions: threat level, urgency, scene importance, historical frequency, and confidence level. It also determines the weight coefficients corresponding to each dimension according to the current scene mode and calculates the comprehensive priority score using a weighted summation model. This allows the priority assessment to reflect both the static and dynamic attributes of the event, and enables the weights to be adjusted according to the scene mode to adapt to different on-site pressures. This improves the problem of delayed processing of critical events under single-dimensional assessment and enhances the matching degree between the priority assessment results and the actual on-site urgency.

[0022] In some embodiments, the urgency dimension score The calculation formula is: ;in, , The current target distance, To the maximum effective monitoring distance; , The current target movement speed, The speed threshold; The target orientation factor is set to 1.0 when the target is facing the center of the monitoring area, 0.0 when it is facing away from the center, and determined by linear interpolation when the target is facing other angles. , , The sub-weight coefficients, after normalization, are obtained as follows: , for The preset normalization upper limit.

[0023] In the above embodiments, this application decomposes the urgency dimension score into a target distance factor, a target speed factor, and a target orientation factor. The distance factor is determined by the ratio of the current distance to the maximum effective monitoring distance, the speed factor is determined by the ratio of the current speed to a preset speed threshold and does not exceed 1, and the orientation factor is determined by linear interpolation between forward, backward, and other angles. Then, the urgency dimension score is obtained by weighted summation according to sub-weight coefficients and normalization. This allows the urgency assessment to take into account the three physical characteristics of the target: position, movement, and orientation, thereby improving the ability of the urgency dimension score to represent the actual threat trend.

[0024] In some embodiments, the step of determining the weight coefficients corresponding to each dimension based on the current scene mode specifically includes:

[0025] When an event with the highest threat level appears among the pending events, the current scenario mode is determined to be emergency mode;

[0026] If the conditions for determining the emergency mode are not met, and the number of concurrent events to be processed is greater than or equal to the preset concurrency threshold, the current scenario mode will be determined as peak mode.

[0027] If the conditions for determining the emergency mode and the peak mode are not met, the current scenario mode is determined to be the normal mode.

[0028] In the emergency mode, the weight of the threat level dimension is greater than the corresponding weight in the peak mode, and the sum of the weights of the threat level dimension and the urgency dimension in the peak mode is greater than the sum of the corresponding weights in the normal mode.

[0029] Based on the determined current scenario mode, the weight coefficients corresponding to each dimension are obtained by querying the preset weight configuration table.

[0030] In the above embodiments, this application sequentially determines whether the highest-level threat event appears in the pending events and whether the number of concurrent events reaches a preset threshold, based on the determination order. Accordingly, it automatically switches between emergency mode, peak mode and normal mode, and obtains the weight coefficients corresponding to each dimension by querying the preset weight configuration table according to the determined mode. It also constrains that the weight of the threat level dimension in emergency mode is greater than the corresponding weight in peak mode, and the sum of the weights of the threat and urgency dimensions in peak mode is greater than the sum of the corresponding weights in normal mode. This enables the weight configuration to automatically switch with the on-site concurrent pressure and threat distribution, improves the problem of high-threat events being diluted and queued under fixed weights, and improves the response time of alarm scheduling in extreme scenarios.

[0031] In some embodiments, the step of detecting a physical resource conflict between the head-of-line event and the currently processed event on the PTZ control and encoder channel, and selecting a resolution strategy based on the conflict characteristics, specifically includes:

[0032] Detect physical resource conflicts between the queue-head event and the currently being processed event in at least one of the following: PTZ control, encoder channel, network bandwidth, and storage space, to obtain a set of conflicting events;

[0033] Determine whether there is an event with the highest threat level in the set of conflict events, and whether the difference between the comprehensive priority score of the highest-level event and the currently being processed event is greater than a preset preemption threshold. If so, determine the emergency preemption strategy as the resolution strategy, save the context state of the currently being processed event and switch resources to the highest-level event. After the highest-level event is processed, recalculate the comprehensive priority score of the preempted event and restore the execution of the preempted event based on the saved context state according to the current priority event queue status.

[0034] If the emergency preemption strategy is not determined, it is determined whether the conflicting resources in the conflict event set include gimbal control and whether the distance between the target locations of each event is less than a preset distance threshold. If so, the distance merging strategy is determined as the resolution strategy, and the conflicting events are merged into a comprehensive tracking task. The target location of the comprehensive tracking task is determined by weighting the comprehensive priority scores of each conflicting event.

[0035] Otherwise, the time-slicing strategy is determined as the resolution strategy, and time slices are allocated according to the weighted ratio of the comprehensive priority score of each event in the conflict event set, so as to perform time-sharing scheduling of the gimbal control.

[0036] In the above embodiments, this application first detects physical resource conflicts between the head event and the currently processed event in at least one of the following: gimbal control, encoder channel, network bandwidth, and storage space, to obtain a set of conflict events. Then, it sequentially determines whether there is a highest-level event whose priority difference with the current event is greater than the preemption threshold to execute an emergency preemption strategy and save the context. If not triggered, it determines whether the conflicting resource includes gimbal control and whether the distance to the target location of the conflicting event is less than a preset distance threshold to execute a distance merging strategy. Otherwise, it allocates time slices according to the priority score weighted ratio to execute a time slicing strategy. This not only makes the three resolution strategies mutually exclusive through layered judgment, avoiding rule overlap and coverage gaps, but also reduces the impact of preemption on interrupted events by saving and restoring the context of the preempted event, improves the problem of repeated gimbal switching under multiple concurrent events, and improves the rationality of physical resource allocation in conflict scenarios.

[0037] In some embodiments, the step of performing resource pre-locking based on the resource demand forecast specifically includes:

[0038] The required resources are determined by querying the resource requirement configuration table based on the event type of the executed event; the required resources include at least one of encoder channel, network bandwidth, storage space, and PTZ control.

[0039] Check the available resources in the current system resource pool. If the available resources meet the required resources, pre-lock the required resources and mark the resources as locked in the unified event data structure of the execution event.

[0040] If the available margin is insufficient to meet the required resources, and the overall priority score of the execution event is higher than that of the low-priority event that is currently occupying resources, then the resources occupied by the low-priority event are released and reallocated to the execution event.

[0041] If the available resources are insufficient to meet the required resources and the reallocation cannot be performed, the execution event is marked as a resource waiting state, and the resources are reallocated in descending order of the comprehensive priority score when they are released.

[0042] In the above embodiments, this application queries the resource requirement configuration table based on the event type to estimate the required resources when the event is enqueued, and checks the available reserve of the system resource pool. If the available reserve is sufficient, the resource is pre-locked and marked as locked in the event data structure. If the available reserve is insufficient but the current event priority is higher than the low-priority event occupying the resource, the resource is released and reallocated. If neither can be done, the event is marked as resource waiting and reallocated according to priority after the resource is released. By moving the resource request action forward to the enqueuing stage, the resource determinism of high-priority events is ensured through the waiting queue and preemptive reallocation, which improves the problem of interruption due to temporary resource shortage during the processing and improves the completion rate of the entire alarm chain.

[0043] In some embodiments, the step of driving the gimbal mechanism to complete physical alignment and target tracking based on the target gimbal position of the execution event, and driving external linkage devices to perform physical linkage actions based on the type of the execution event, to obtain a physical execution state reflecting each processing stage, specifically includes:

[0044] According to the predefined state machine, the execution events are driven sequentially through the physical alignment stage, the video capture stage, the encrypted upload stage, and the linkage notification stage; wherein, in the physical alignment stage, the PTZ mechanism is driven to complete physical alignment and target tracking, and in the linkage notification stage, the external linkage device is driven to perform physical linkage actions.

[0045] Configure timeout timers and exception rollback strategies for each stage in the state machine. When any stage times out or fails, proceed to the next stage in a retry or degradation manner according to the exception rollback strategy until the shutdown state is reached, thus obtaining the physical execution state.

[0046] In the above embodiments, this application uses a predefined state machine to drive the execution of events through four stages: physical alignment, video capture, encrypted upload, and linkage notification. The physical alignment stage drives the PTZ mechanism to complete alignment and tracking, and the linkage notification stage drives external linkage devices to perform physical actions. Each stage is configured with an independent timeout timer and an exception rollback strategy. If any stage times out or fails, it will proceed to the next stage in a retry or degradation manner according to the configured strategy until it reaches the closed state. By setting boundaries for single-link failures through the timeout timer, the problem of the processing link being suspended due to single-link blockage is improved, and the completion rate and predictability of the alarm processing process are improved.

[0047] In some embodiments, the exception rollback strategy is configured as follows:

[0048] If the physical alignment phase times out, a preset position is used to replace the target position and the process proceeds to the next phase.

[0049] After the video capture stage times out, the acquired video and image content is retained and the process proceeds to the next stage;

[0050] If the encrypted upload phase times out, a local encrypted copy is retained and the encrypted upload is retried after the network is restored. If the maximum number of retries is exceeded, the process proceeds to the next phase. If the linked notification phase times out, the corresponding operation is skipped and the process proceeds to the next phase.

[0051] Furthermore, the retry is performed according to the exponential backoff strategy, and the number of retries in the same stage does not exceed the preset maximum number.

[0052] In the above embodiments, this application configures differentiated degradation paths for each stage. When the physical alignment stage times out, a preset bit is used to replace the target position before proceeding. When the video recording and image capture stage times out, the acquired content is retained before proceeding. When the encrypted upload stage times out, a local encrypted copy is retained, and after the network recovers, the exponential backoff and retries exceed the maximum number of times before proceeding. When the linkage notification stage times out, the corresponding operation is skipped before proceeding. This allows different stages to adopt differentiated fault tolerance measures based on their contribution to the final result, improving the stability of the link in abnormal scenarios.

[0053] In some embodiments, the step of pushing the stage callback message to a subscribed external business system via a subscription interface and obtaining callback feedback from the external business system specifically includes:

[0054] The phase callback message is pushed to the external business system through either long connection push mode or short connection callback mode;

[0055] The long-connection push mode reconnects based on the most recent event identifier after the connection is broken and resends the phase callback messages during the disconnection period;

[0056] The short connection callback mode retryes according to the exponential backoff strategy when the push fails and deduplicates the same event based on the unique identifier of the event;

[0057] Receive callback feedback returned by the external business system for the stage callback message.

[0058] In the above embodiments, this application supports two channels in the business callback process: long connection push mode and short connection callback mode. In the long connection push mode, after the connection is broken, the connection is reconnected based on the most recent event identifier and the stage callback message during the disconnection period is resent. In the short connection callback mode, when the push fails, the retry is performed according to the exponential backoff strategy and the same event is deduplicated based on the unique event identifier. Finally, the callback feedback returned by the external business system for the stage callback message is received. The disconnection resending and deduplication mechanism reduces the occurrence of message loss or duplication, improves the problem of the external business system's incomplete grasp of the processing progress, and improves the reliability of state synchronization between physical execution and external business.

[0059] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0060] 1. By unifying and formatting alarm signals from multiple heterogeneous event sources, and dynamically weighting and summing them according to the current scenario mode based on five dimensions: threat level, urgency, scenario importance, historical frequency, and confidence, and simultaneously recalculating and reordering the comprehensive priority score of all pending events in the queue in real time at a preset period, the problem of queuing delays for critical alarms caused by static sorting based on a single dimension in the existing solution is improved. This enhances the ability of priority assessment results to follow dynamic threats on site, and enables the accumulated threats in high-value areas to be reflected in the scheduling order in a timely manner.

[0061] 2. By pre-estimating resource requirements and locking physical resources such as encoder channels, bandwidth, storage, and PTZ control when events are enqueued, and judging and resolving physical resource conflicts in a hierarchical order of emergency preemption, distance merging, and time slicing, the problem of repeated PTZ switching and interruption of processing links due to temporary resource shortages under multiple concurrent events is improved, and the determinism of physical resource allocation and the completion rate of alarm processing links in conflict scenarios are improved.

[0062] 3. By using a state machine to drive the execution of events, the process sequentially goes through stages such as physical alignment, video recording and capture, encrypted upload, and linkage notification. The physical execution status and the callback feedback from the external business system are used together as feedback quantities to flow back to the priority recalculation step to participate in queue updates, forming a complete closed loop of physical execution - business callback - scheduling recalculation. This improves the problem in the existing solution where the physical execution link and the external business system only communicate through a one-time notification and the status cannot flow back to participate in decision-making. It also improves the state synchronization and link controllability between the physical execution component and the external business system. Attached Figure Description

[0063] Figure 1 This is a flowchart illustrating the end-to-end linkage control and business callback method based on event priority queues in this application embodiment;

[0064] Figure 2 This is an overall architecture diagram of the full-link closed-loop control system in the embodiments of this application;

[0065] Figure 3 This is a schematic diagram of the multi-dimensional dynamic priority evaluation model in the embodiments of this application;

[0066] Figure 4 This is a flowchart of the conflict resolution strategy in the embodiments of this application. Detailed Implementation

[0067] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification of this application, the singular expressions “a,” “an,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0068] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0069] To facilitate understanding, the application scenarios of the embodiments of this application are described below.

[0070] For operators deploying cameras on outdoor infrastructure such as towers, base stations, and power transmission lines, the effectiveness of their operations depends not only on the imaging and recognition capabilities of the cameras themselves, but also on their ability to reliably handle the entire process from event perception to external business collaboration when faced with multiple concurrent alarms. However, in real-world outdoor scenarios, multiple types of alarms often arrive simultaneously, including intrusion, obstruction by foreign objects, vibration, boundary violations, sudden changes in lighting, and commands from higher-level platforms. Furthermore, these alarms compete for physical resources (pan-tilt units, encoders, bandwidth, and storage), and external business systems often need to make synchronous decisions based on processing progress. This makes end-to-end management a real challenge for operators. The implementation of this application provides a crucial means for intelligent monitoring equipment to drive the collaborative operation of physical execution components and external business systems in complex concurrent scenarios. Its necessity is reflected in the following aspects:

[0071] First, the core of this application lies in constructing a full-link closed-loop control system centered on an event priority queue, which is the foundation for ensuring timely response to critical alarms. This application enables alarms from different sources and of different types to be fairly and dynamically evaluated in the same queue through unified formatting of multi-source heterogeneous events and preset periodic priority recalculation. The operations and maintenance team does not need to develop independent scheduling logic for different event sources, and can complete unified scheduling on the device side.

[0072] Secondly, this application can effectively resolve competition for physical resources. By determining three strategies—emergency preemption, distance merging, and time slicing—in a hierarchical order among conflicting events, the operation and maintenance team can avoid the PTZ repeatedly switching between multiple targets and prevent high-priority events from being interrupted during uploading or linkage due to temporary resource shortages. These improvements have direct value in multi-target intrusion detection and concurrent face recognition in tower scenarios.

[0073] This application also improves the state synchronization between the device and external business systems by using a closed-loop link where physical execution status and external business callback feedback flow back to priority recalculation. This enables the operations and maintenance team to make business decisions based on the real-time feedback of the device's processing progress at each stage. For example, it can trigger face comparison after image capture, start video analysis after recording, and adjust on-site handling strategies after linkage is completed, providing the operations and maintenance team with data-driven end-to-end collaborative capabilities.

[0074] The method provided in this embodiment is described in detail below. Please refer to [link / reference]. Figure 1 This is a flowchart illustrating the end-to-end linkage control and business callback method based on an event priority queue in this application embodiment.

[0075] S101. Collect alarm signals from multiple heterogeneous event sources, convert each alarm signal into a unified event data structure carrying the target gimbal location and resource requirement estimation, and obtain the event to be processed.

[0076] Heterogeneous event sources refer to various data sources that generate raw alarm signals, including but not limited to artificial intelligence analysis modules, physical sensors, external alarm subscription channels, operation and maintenance platform command channels, and periodic event sources; alarm signals refer to raw event messages generated by each event source when it detects specific conditions, and their raw data format, field naming, and value range vary from event source to event source; target PTZ location refers to the physical monitoring orientation parameters pointed to by the alarm signal, including horizontal angle, vertical angle, and zoom magnification; resource requirement estimation refers to the estimated amount of physical resources required to process the alarm signal, including encoder channels, network bandwidth, and storage space; unified event data structure refers to a standardized data format that carries common fields from various heterogeneous event sources, used for subsequent scheduling and processing.

[0077] The intelligent monitoring equipment performs this step during the alarm generation process to unify the raw alarms from different event sources into a comparable and schedulable format. Specifically, the intelligent monitoring equipment first listens for raw alarm signals from five types of event sources; then, it performs format parsing for each event source, extracting key fields such as event type, timestamp, target location, threat level, and confidence level from the raw signals; next, it queries a pre-set resource requirement mapping table based on the event type to obtain the estimated resource requirement for that event; finally, it fills the extracted fields and the estimated resource requirement into a unified event data structure, forming a pending event and sending it to the subsequent priority evaluation process.

[0078] See Figure 2 This application employs a five-layer architecture model to achieve complete closed-loop control from event acquisition to business callback. The five layers, from bottom to top, are: event acquisition layer, event priority queue engine, conflict resolution and resource pre-allocation layer, state machine execution engine, and external linkage interface layer. Data flows between layers through standardized interfaces. The external linkage interface layer provides a business callback feedback path to the event priority queue engine, forming a complete closed-loop control loop of physical execution, business callback, and scheduling recalculation.

[0079] The event acquisition layer supports parallel access from five types of event sources. The first type is the AI ​​analysis module event source, generated by the neural network processing unit on the device running inference algorithms. This includes intrusion detection events, face recognition events, boundary crossing detection events, area intrusion events, object abandonment events, and smoke / flame detection events. The AI ​​analysis module analyzes the video stream in real time at 30 frames per second, generating events when the detection results meet the triggering conditions. The second type is sensor event sources, including environmental perception events generated by physical sensors such as photosensors, temperature sensors, humidity sensors, and vibration sensors. The third type is external alarm subscription event sources, receiving alarm subscription messages from external systems such as the upper-level operation and maintenance platform, neighboring devices, and IoT gateways through long or short connection interfaces. The fourth type is operation and maintenance platform command event sources, receiving manual alarm trigger commands, preset bit call commands, and parameter configuration commands from the operation and maintenance management platform. The fifth type is periodic event sources, including timed inspection events, timed image capture events, and timed health check events triggered by system timers.

[0080] Alarm signals generated by each event source are uniformly converted into a standard event data structure before entering the priority queue. This structure includes at least: a unique event identifier, event type, event source, event generation timestamp, comprehensive priority score, target PTZ location, threat level, scene identifier, confidence score, extended data fields, and resource requirement estimation fields. The target PTZ location includes three subfields: horizontal angle, vertical angle, and zoom magnification; the resource requirement estimation includes three subfields: encoder channels, network bandwidth, and storage space; and the extended data fields are used to carry additional parameters specific to different event sources.

[0081] In practical applications, issues may arise where the raw signals from different event sources lack information on the target PTZ location or resource requirements. To address this, intelligent monitoring devices can employ a field backfilling mechanism: First, for sensor events lacking the target PTZ location, the system queries a preset location mapping table based on the physical installation location of the event source to backfill the field; second, for maintenance platform command events lacking resource requirements, the system queries a default resource requirement configuration table based on the command type to backfill the field; finally, for events that cannot be automatically backfilled, their extended data fields are marked as pending supplementation and temporarily filled according to the event source's default values, ensuring that subsequent scheduling is not interrupted due to missing fields.

[0082] S102. Perform weighted calculation based on the dynamic feature dimensions of the events to be processed to obtain a comprehensive priority score, and recalculate and reorder the comprehensive priority scores of all events to be processed in the queue at a preset period to obtain a priority event queue.

[0083] Among them, the dynamic feature dimension refers to multiple assessment dimensions that reflect the real-time status of an event and its environment, including five dimensions: threat level, urgency, scene importance, historical frequency, and confidence level; the comprehensive priority score is the comprehensive assessment value obtained by weighting and summing the scores of each dimension according to the weight coefficients, and the larger the value, the higher the priority; the preset period is the time interval for recalculating the comprehensive priority score of all pending events in the queue; the priority event queue is the set of pending events arranged in descending order of comprehensive priority score, with the event at the head of the queue being the pending event with the highest current priority.

[0084] The intelligent monitoring device executes this step after a pending event is generated to determine the processing order of alarm events. Specifically, the intelligent monitoring device first calculates the normalized score of five dynamic feature dimensions for each pending event; then, it determines the weight coefficients corresponding to each dimension based on the current scene mode; next, it calculates the comprehensive priority score using a weighted summation model; finally, it writes the comprehensive priority score into the corresponding field of the pending event, and re-executes the above calculation process for all pending events in the queue at a preset period. When the change in the comprehensive priority score of a pending event exceeds a preset change threshold, the queue is reordered.

[0085] Referring to Figure 3, the overall priority score is calculated using the weighted summation model as follows: ;in For the threat level dimension score, the original threat levels of Emergency, High, Medium, and Low were normalized and mapped to 1.0, 0.75, 0.5, and 0.25, respectively. The urgency level score is calculated by weighting the target distance factor, target speed factor, and target orientation factor. Specifically, Among them, the distance factor , The current target distance, Maximum effective monitoring distance; speed factor , The current target movement speed, Velocity threshold; Orientation factor The value is 1.0 when the target is facing the monitoring center, 0.0 when it is facing away, and linear interpolation is used for other angles; sub-weights , , The default values ​​are 0.4, 0.4, and 0.2 respectively; in the example implementation, the maximum effective monitoring distance is... The speed threshold is determined based on the camera lens focal length and on-site deployment conditions; for example, 100 meters could be used. The normalization speed is determined based on the target type in the monitoring scenario: 2 m / s for personnel targets and 15 m / s for vehicle targets; a preset normalization upper limit is also used. Version 1.0 is acceptable, used to... The constraints are within the range [0,1]. It is understood that the above parameter values ​​are merely examples and can be adjusted according to the actual deployment scenario; no limitations are imposed here. After normalization... , This is a preset normalization upper limit. The scene importance dimension score is normalized to 0.2, 0.4, 0.6, 0.8, and 1.0 based on the preset scene levels 1 to 5. To score the historical frequency dimension, an exponentially weighted moving average algorithm is used for calculation. ,in This is the historical frequency value from the last calculation. This represents the number of alarms within the current time window. The attenuation coefficient (default value 0.7) is normalized to... , The historical frequency normalization threshold; The confidence score is directly taken from the confidence score field in the unified event data structure.

[0086] In an implementation with a preset period of 100ms, the priority recalculation process for intelligent monitoring devices is as follows: traverse all pending events in the priority queue; recalculate the normalized score of each pending event based on the latest sensor data, target location information, and historical alarm records for the five dimensions; select the corresponding weight configuration according to the current scene mode to calculate the new comprehensive priority score; if the comprehensive priority score of a pending event changes beyond the preset change threshold (default ±5 points), the queue is reordered; and the reordered queue is submitted to the subsequent conflict resolution process.

[0087] In some embodiments, the intelligent monitoring device will automatically switch between multiple scene modes according to the current real-time scene conditions. That is, the intelligent monitoring device first determines whether there is an event with the highest threat level among the events to be processed. If there is, the current scene mode is determined to be the emergency mode. If there is no highest-level event but the number of concurrent events to be processed is greater than or equal to the preset concurrency threshold, the current scene mode is determined to be the peak mode. Otherwise, it is determined to be the normal mode. Finally, the device queries the preset weight configuration table to obtain the weight coefficients corresponding to each dimension according to the determined current scene mode.

[0088] The weight of the normal mode is set to... =0.35, =0.25, =0.15, =0.10, =0.15$; Peak mode is triggered when the number of concurrent events is greater than or equal to 5, and the weight is set to $. =0.40, =0.30, =0.10, =0.10, =0.10; Emergency mode is triggered when the highest-level event exists among the pending events, with a weight of 0.10. =0.50, =0.30, =0.10, =0.05, =0.05. The three scenario modes satisfy the following constraints: the weight of the threat level dimension is greater in emergency mode than the corresponding weight in peak mode, and the sum of the weights of the threat level dimension and the urgency dimension in peak mode is greater than the sum of the corresponding weights in normal mode.

[0089] In practical applications, sensor data fluctuations may occur within a certain period, causing the overall priority score of some pending events to frequently exceed a threshold change, thus triggering frequent queue reordering. To address this issue, intelligent monitoring devices can introduce a threshold change hysteresis mechanism: firstly, reordering is only triggered when the absolute value of the overall priority score change exceeds a first threshold; secondly, the interval between two adjacent reorderings must be no less than a preset period; and finally, for events that repeatedly exceed the threshold within a short period, a sliding window is used to smooth the overall priority score change curve, ensuring queue stability.

[0090] S103. Extract the head event from the priority event queue, detect the physical resource conflict between the head event and the currently processed event on the PTZ control and encoder channel, select a resolution strategy based on the conflict characteristics, and perform resource pre-locking based on the estimated resource requirements to determine the execution event.

[0091] Among them, the first priority event refers to the event with the highest overall priority score in the priority event queue at the current moment; the currently being processed event refers to the event that has been dequeued from the priority event queue and is in the process of state machine execution; physical resource conflict refers to the situation where two events have simultaneous requirements for occupying the same physical resource, which includes at least PTZ control and encoder channels, and may also include network bandwidth and storage space; resolution strategy refers to the specific processing method used to resolve physical resource conflicts; resource pre-locking refers to the operation of pre-occupying the physical resources required by an event before it enters the state machine for execution; execution event refers to the event that is determined to be able to enter the state machine for execution after conflict resolution and resource pre-locking.

[0092] The intelligent monitoring device executes this step after updating the priority event queue to avoid physical resource contention when multiple events occur concurrently. Specifically, the intelligent monitoring device first extracts the head event from the priority event queue; then it checks whether the head event and the currently processed event have physical resource conflicts in at least one of the following: PTZ control, encoder channel, network bandwidth, and storage space, forming a set of conflicting events; next, it selects an appropriate resolution strategy based on the characteristics of the conflicting event set; then, it checks the available resource pool based on the resource requirements corresponding to the head event, and if the available resource meets the requirements, it pre-locks the required resources; finally, the event that completes conflict resolution and resource pre-locking is determined as the execution event and handed over to the subsequent state machine process for execution.

[0093] It should be noted that, see Figure 4The conflict resolution strategy is determined and executed in the following order: First, it is determined whether there is an event with the highest threat level in the conflict event set, and whether the difference in the comprehensive priority score between this highest-level event and the currently processed event is greater than a preset preemption threshold. If so, the emergency preemption strategy is determined as the resolution strategy: immediately suspend the currently processed low-priority task and save its context state; switch resources to handle the highest-priority event. During the waiting period, the priority event queue engine continuously recalculates the comprehensive priority score of all pending events, including the preempted task, and updates the queue sorting according to a preset period. After the highest-priority event is processed, the execution of the preempted event is resumed based on the latest state of the current priority event queue and the saved context state. The maximum number of times the same task can be preempted does not exceed a preset number; if the preset number is exceeded, the processing is downgraded to recording only without tracking. In the example implementation, the preset preemption threshold can be set to 0.2, meaning that the overall priority score of the highest-level event must be at least 0.2 higher than the currently being processed event before emergency preemption is triggered; the preset distance threshold is set to 15° by default; and the maximum number of times the same task can be preempted by default is 2. It is understood that the above thresholds are only example values ​​and can be dynamically adjusted according to the deployment scenario.

[0094] The second step, if an emergency preemption strategy is not determined, determines whether the conflicting resources in the conflict event set include gimbal control. Since a gimbal can only physically point to one location at a time, the essence of the distance merging strategy is to avoid repeated gimbal switching by merging multiple nearby targets. Therefore, the prerequisite for this strategy is that the conflicting resources include gimbal control. Under this premise, it is determined whether the distance between the target positions of each conflicting event is less than a preset distance threshold (default 15°). If it is determined to be yes, the distance merging strategy is determined as the resolution strategy: the conflicting events are merged into a comprehensive tracking task. The target position of the comprehensive tracking task is the average of the target positions of each conflicting event weighted by the comprehensive priority score. The priority of the merged event is the highest priority among the merged events. The third step, if neither of the above two strategies is triggered, the time slicing strategy is determined as the resolution strategy: the total time slice (default 10 seconds) is allocated to each event according to the weighted ratio of the comprehensive priority score of each conflicting event. Each event exclusively holds gimbal control within the allocated time slice, and switches to the next event after the time slice expires.

[0095] In some embodiments, resource pre-locking can be implemented in several ways: Optionally, the intelligent monitoring device can adopt a pessimistic locking approach, locking the resource pool and atomically deducting the available reserve when an event is enqueued, ensuring the determinism of resource allocation; alternatively, the intelligent monitoring device can adopt an optimistic locking approach, marking the resource pool with a version number when an event is enqueued, and deducting the available reserve only after verifying the version number consistency before actual use, reducing lock contention overhead. It is understood that other locking mechanisms can also be used to implement resource pre-locking, and this is not limited here.

[0096] Specifically, the resource pre-locking process is as follows: The intelligent monitoring device first queries the resource requirement configuration table based on the event type of the executed event to determine the required resources; then it checks the available resources in the current system resource pool. If the available resources meet the required resources, the required resources are pre-locked and the resources are marked as locked in the unified event data structure of the event; if the available resources do not meet the required resources and the overall priority score of the current event is higher than that of a lower priority event that is currently occupying resources, resource preemption is triggered, the resources occupied by the lower priority event are released and reallocated to the current event; if the available resources do not meet the required resources and reallocation is not possible, the event is marked as a resource waiting state and reallocated in descending order of overall priority score when resources are released.

[0097] The example resource requirements are as follows: Intrusion detection events require a main stream plus a slave stream channel, 10Mbps bandwidth, 75MB / min storage, and continuous PTZ occupation; Face recognition events require a main stream channel, 8Mbps bandwidth, 50MB / min storage, and PTZ occupation for 3-5 seconds; Motion detection events require a slave stream channel, 2Mbps bandwidth, 15MB / min storage, and PTZ occupation for 3-10 seconds; Occlusion alarm events require a slave stream channel, 2Mbps bandwidth, 10MB / min storage, and no PTZ rotation is required. The system resource pool maintains the following resource statuses in real time: Encoder channels support a maximum of 2 main streams plus 4 slave streams; the total network bandwidth is capped at 20Mbps, with 5Mbps reserved for control signaling; storage space is monitored in real time for SD card capacity, triggering an alarm when it falls below 10%; PTZ control can only be exclusively held by one event at a time.

[0098] In practical applications, there may be instances where resource pre-locking is successful, but the locked resources are not fully consumed during the actual execution of the event, resulting in resource waste. To address this issue, intelligent monitoring equipment can establish a resource occupancy and reclamation mechanism: first, it records the difference between the pre-locked amount and the actual usage when resources are pre-locked; second, it immediately releases the remaining pre-locked resources when the event enters the closed state; and finally, it periodically calibrates the resource demand configuration table based on historical data to make the pre-locked amount closer to the actual usage.

[0099] S104. Drive the gimbal mechanism to complete physical alignment and target tracking according to the target gimbal position of the execution event, and drive the external linkage device to perform physical linkage action according to the type of the execution event, so as to obtain the physical execution status reflecting each processing stage.

[0100] Among them, the pan-tilt mechanism refers to the mechanical component that carries the camera lens and can physically rotate in the horizontal and vertical directions; physical alignment refers to the physical action of driving the pan-tilt mechanism to point the lens at the target pan-tilt position specified by the execution event; target tracking refers to the process of continuously adjusting the pan-tilt position based on image feedback after physical alignment to keep the target in the center of the image; external linkage equipment refers to physical peripherals that work in conjunction with intelligent monitoring equipment, including supplementary lighting, audible and visual alarms, access control mechanisms, and adjacent monitoring equipment; physical linkage action refers to the specific physical action performed by the external linkage equipment according to the type of execution event; and physical execution status refers to the real-time status of each stage of the execution event during processing.

[0101] Specifically, the intelligent monitoring equipment first calculates the pan-tilt-zoom (PTZ) trajectory based on the target PTZ position of the executed event and drives the PTZ mechanism to complete physical alignment; then it initiates the target tracking process; next, it triggers corresponding processing steps such as recording, capturing images, encryption, and uploading based on the type of executed event; then, it drives external linkage devices to perform physical linkage actions based on the type of executed event and pre-configured linkage rules; finally, it summarizes the execution results of each processing step into the physical execution status.

[0102] It should be noted that the intelligent monitoring equipment drives the entire chain processing of execution events according to a standardized state machine model, which is further divided into four processing stages. The physical alignment stage includes an initialization state, a gimbal alignment state, and a target tracking state: the initialization state is used to load event configuration parameters, initialize the state machine context, allocate worker threads, and set a default global timeout timer of 60 seconds; the gimbal alignment state calculates the gimbal motion trajectory based on the target gimbal position parameters of the event, driving the gimbal mechanism to rotate at a maximum speed of 360° / s horizontally and 90° / s vertically; the target tracking state uses a proportional-integral-derivative control algorithm to achieve automatic target tracking, and the control formula is... ,in This represents the deviation between the current target position and the center of the image. , , Set the values ​​to 1.2, 0.1, and 0.3 respectively, and continue tracking until the target leaves the monitoring area or reaches the maximum tracking time.

[0103] The video recording and image capture phase includes recording mode and image capture mode: In the recording mode, the main stream is started with high-efficiency video encoding at 1920×1080@25fps and recorded and saved to the local memory card, while a slave stream at 640×360@25fps is started for real-time transmission; In the image capture mode, keyframes are extracted from the video stream and image quality is evaluated. The image capture adopts the Joint Picture Experts Group standard format, resolution of 1920×1080, quality factor of 90, and a maximum of 3 retries.

[0104] The encrypted upload phase includes an encryption state and an upload state: In the encryption state, the national cryptographic algorithm SM4 is used to encrypt captured images and video clips, using a password book mode and a key length of 128 bits. The integrity of the encrypted data is guaranteed by a hash-based message authentication code verification value. In the upload state, a multi-channel parallel upload strategy is adopted. Channel 1 writes to the local storage card as a backup, and Channel 2 uploads to the cloud storage platform via the Hypertext Transfer Security Protocol, supporting breakpoint resume.

[0105] The linkage notification phase includes linkage trigger state, notification state, archiving state, and closing state: The linkage trigger state drives external linkage devices to perform physical linkage actions based on the event type and configured linkage rules, including turning on supplementary lights, triggering audible and visual alarms, sending control commands to the access control system, and sending collaborative alarms to adjacent devices; The notification state pushes phase callback messages to all subscribed external business systems through the external linkage interface, using a reliable messaging mechanism; The archiving state archives the complete processing record of the event to the local database; The closing state releases all occupied resources, updates the event status to closed, and generates the final processing report.

[0106] In some embodiments, the intelligent monitoring device configures independent timeout timers and exception rollback strategies for each stage in the state machine. When any stage times out or fails, it proceeds to the next stage in a retry or degradation manner according to the configured exception rollback strategy, until the shutdown state is reached. Specifically, in the physical alignment stage, after the PTZ alignment state times out, a preset position is used to replace the target position and the process proceeds to the target tracking state. After the target tracking state times out, tracking stops and the process proceeds to the video capture stage. In the video capture stage, after the recording state times out, the recorded content is saved and the process proceeds to the capture state. After the capture state times out, a default image is used and the process proceeds to the encrypted upload stage. After the encrypted upload stage times out, a local encrypted copy is retained, and encrypted upload is retried after the network recovers. If the preset maximum number of retries is exceeded, the process proceeds to the next stage. In the linkage notification stage, after the linkage trigger state times out, the linkage operation is skipped and the process proceeds to the notification state. After the notification state times out, the stage callback message is added to the asynchronous retry queue and the process proceeds to the archiving state. After the archiving state times out, archiving is skipped and the process directly enters the shutdown state. Retry adopts an exponential backoff strategy, with the waiting time for the nth retry being... , Based on the base waiting time, the maximum number of retries for the same state is 3.

[0107] In some embodiments, anomaly rollback can be implemented in several ways: Optionally, the intelligent monitoring device can adopt a fixed rollback method, performing pre-configured fixed degradation actions for each timeout or failure condition, which is simple and predictable; Optionally, the intelligent monitoring device can adopt an adaptive rollback method, dynamically adjusting degradation actions based on historical failure mode statistics and current system resource status, such as temporarily reducing the number of retries for upload status during prolonged periods of network instability, or temporarily shortening the maximum recording duration for recording status during periods of limited storage. It is understood that other anomaly rollback mechanisms can also be used to achieve unidirectional process progression, which is not limited here.

[0108] In practical applications, the gimbal alignment may fail to reach its target position within the timeout period due to mechanical load or environmental interference. To address this issue, intelligent monitoring equipment can employ a fault-tolerant replacement mechanism: firstly, after a gimbal alignment timeout, the most recently successfully positioned position or a preset position for the scenario is used to replace the target position, preventing the entire process from being suspended; secondly, abnormal gimbal movement events are recorded for subsequent mechanical health analysis; and finally, in the event of multiple consecutive timeouts, a gimbal anomaly alarm is pushed to the operations and maintenance platform.

[0109] S105. Generate a stage callback message carrying an event identifier, the current stage, and the stage status based on the physical execution state. Push the stage callback message to the subscribed external business system through the subscription interface to obtain the callback feedback from the external business system.

[0110] Among them, the stage callback message refers to a structured message reflecting the current processing stage and status of the execution event; the event identifier refers to an identifier used to uniquely identify the execution event; the current stage refers to the current processing stage of the execution event; the stage status refers to the execution status of the current stage (such as executing, successful, failed, skipped); the subscription interface refers to the standard interface between the external business system and the intelligent monitoring device for alarm subscription and message push; the external business system refers to the upper-level business platform that works in conjunction with the intelligent monitoring device, including the operation and maintenance management platform, the upper-level business platform, the third-party video management system, and the IoT gateway, etc.; the callback feedback refers to the response information returned by the external business system to the intelligent monitoring device after receiving the stage callback message.

[0111] Specifically, the intelligent monitoring device first generates a stage callback message based on the physical execution status, which includes at least the event identifier, the current stage, and the stage status fields. Then, it filters the objects to be pushed to based on the subscription parameters pre-set by the external business system. Next, it pushes the stage callback message to the qualified external business system through the subscription interface. Finally, it receives the callback feedback returned by the external business system for the stage callback message.

[0112] It should be noted that the subscription interface supports two modes: long-connection push mode and short-connection callback mode. In long-connection push mode, the external business system establishes a long connection with the intelligent monitoring device and specifies the event types and alarm levels to be monitored through subscription messages. When the physical execution state changes, the intelligent monitoring device pushes phase callback messages in real time through the long connection. The long connection maintains its connection state through periodic heartbeat messages. After the connection is broken, it reconnects based on the most recent event identifier and resends the phase callback messages from the period of disconnection. In short-connection callback mode, the external business system pre-registers a callback address. When the physical execution state changes, the intelligent monitoring device sends a callback request containing phase callback messages to the callback address. If the callback request fails, it retryes a limited number of times (e.g., a maximum of 5 times) according to an exponential backoff strategy, and deduplicates the same event based on the event's unique identifier.

[0113] In some embodiments, the complete fields of the stage callback message include a unique event identifier, event type, callback message generation timestamp, current stage, stage status, overall processing progress percentage, stage-related data payload, next stage, and estimated remaining completion time; wherein the stage status values ​​include pending, in progress, successful, failed, and skipped. External business systems can display alarm processing progress in real time based on stage callback messages, or trigger secondary business logic based on changes in processing status, such as performing face comparison immediately after image capture or starting video analysis after recording.

[0114] It should be noted that after receiving the phase callback message, the external business system can return callback feedback to the intelligent monitoring device through the corresponding channel of the subscription interface. The callback feedback includes at least three types of signals: the first is a business confirmation signal, used by the external business system to confirm that it has successfully received and processed the phase callback message; the second is a priority adjustment suggestion, used by the external business system to request the intelligent monitoring device to increase or decrease the processing priority of the corresponding event based on its own business judgment, such as the upper-level operation and maintenance platform returning feedback of "confirmed as a real intrusion" after receiving the PTZ alignment phase callback message and combining it with manual verification results; the third is a supplementary context signal, used by the external business system to provide the intelligent monitoring device with additional processing information for the event, such as the access control system returning the actual execution result of access control linkage, or a neighboring device returning its status of having taken over tracking. After receiving the callback feedback at the external linkage interface layer, the intelligent monitoring device, on the one hand, stores the callback feedback record locally for reconciliation, and on the other hand, submits the callback feedback as a feedback signal to the event priority queue engine for recalculation triggering of subsequent steps.

[0115] In practical applications, the same external business system may need to switch between long-connection push mode and short-connection callback mode. To address this issue, intelligent monitoring devices can establish a channel switching mechanism: First, automatically switch to short-connection callback mode when a long connection is broken and reconnection fails more than a preset number of times, avoiding the accumulation of phase callback messages due to the unavailability of the long connection; second, after the short connection callback has been successful for a period of time, allow the external business system to actively request the restoration of the long connection, and resend the phase callback messages during the switching period according to the most recent event identifier after restoration; finally, use a common event unique identifier for both modes to achieve deduplication, avoiding the duplicate processing of the same phase callback message during the switching process.

[0116] In practical applications, there may be instances where external business systems become temporarily unreachable or experience timeouts, leading to the loss of phase callback messages. To address this issue, intelligent monitoring devices can establish a reliable push mechanism: First, in long-connection mode, the offset of the last pushed message is recorded using a recent event identifier, and pushes resume from that offset after a disconnection and reconnection; second, in short-connection mode, failed callback requests are added to an asynchronous retry queue and retried using an exponential backoff strategy; finally, when the same phase callback message is triggered multiple times by the same event, deduplication is performed using a unique event identifier to prevent external business systems from receiving duplicate messages.

[0117] S106. When the physical execution state or the callback feedback changes, return to the step of performing weighted calculation based on the dynamic feature dimensions of the event to be processed to obtain a comprehensive priority score, so as to update the priority event queue until the execution event reaches the closed state.

[0118] Among them, feedback backflow refers to using changes in the physical execution state generated downstream or callback feedback from external business systems as input trigger signals for upstream priority recalculation steps; the closed state refers to the final state where the execution event has reached the end of the state machine and all occupied resources have been released.

[0119] Specifically, the intelligent monitoring device first listens for the physical execution state change signals reported by the state machine execution engine and the callback feedback signals reported by the external linkage interface layer; then, for each change signal, it injects the parameters such as the scene identifier, resource occupancy status, and external business judgment carried by it into the recalculation context of the event priority queue engine; then, it triggers the recalculation of the comprehensive priority score of the affected pending events in the queue and updates the priority event queue; finally, it executes steps S102 to S105 in a loop until the execution event reaches the closed state.

[0120] It should be noted that, in addition to the proactive recalculation driven by a preset cycle, the event priority queue engine also accepts physical execution state change signals from the state machine execution engine and callback feedback signals from the external linkage interface layer as passive triggers. When the state machine execution engine reports that an execution event has entered a new stage, timed out, or rolled back abnormally, the event priority queue engine updates the parameters related to that execution event to the queue context and immediately recalculates the comprehensive priority score for the affected pending events. When the external linkage interface layer receives callback feedback from an external business system for a certain stage callback message, the event priority queue engine recalculates the comprehensive priority score of the corresponding event based on the business confirmation status, priority adjustment suggestions, or supplementary context information carried in the callback feedback and triggers queue reordering. The above passive triggers and the proactive recalculation driven by the preset cycle together form a complete closed loop.

[0121] In this embodiment, by employing a multi-source heterogeneous alarm access method based on a unified event data structure and a dynamic priority recalculation method based on a preset period and a feedback return dual trigger mechanism, the intelligent monitoring device can dynamically evaluate and sort alarms from multiple heterogeneous event sources in the same queue. It also ensures the determinism of physical execution through physical resource conflict resolution and resource pre-locking mechanisms. Furthermore, it improves the state synchronization between physical execution components and external business systems by having physical execution status and external business callback feedback flow back to the priority recalculation closed-loop link. This effectively solves the problems of high physical response latency and easy suspension or interruption of the alarm processing link in the physical execution or external business connection links in existing solutions under multi-source concurrent alarm scenarios. As a result, it achieves highly deterministic full-link linkage control of alarm events in outdoor infrastructure scenarios such as towers and base stations.

[0122] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0123] The above are all preferred embodiments of this application, and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A method for end-to-end linkage control and business callback based on event priority queues, characterized in that, The method, applied to intelligent monitoring equipment, includes: Alarm signals from multiple heterogeneous event sources are collected, and each alarm signal is converted into a unified event data structure carrying the target gimbal location and resource demand estimation to obtain the event to be processed. A weighted calculation is performed based on the dynamic feature dimensions of the events to be processed to obtain a comprehensive priority score. The comprehensive priority scores of all events to be processed in the queue are recalculated and reordered at a preset period to obtain a priority event queue. Extract the head event from the priority event queue, detect the physical resource conflict between the head event and the currently processed event on the PTZ control and encoder channel, select a resolution strategy based on the conflict characteristics, and perform resource pre-locking based on the estimated resource requirements to determine the execution event; Based on the target gimbal position of the execution event, the gimbal mechanism is driven to complete physical alignment and target tracking, and based on the type of the execution event, external linkage devices are driven to perform physical linkage actions, thereby obtaining the physical execution status reflecting each processing stage; Based on the physical execution state, a stage callback message carrying an event identifier, the current stage, and the stage state is generated. The stage callback message is pushed to the subscribed external business system through the subscription interface to obtain the callback feedback from the external business system. When the physical execution state or the callback feedback changes, the step of performing a weighted calculation based on the dynamic feature dimensions of the event to be processed to obtain a comprehensive priority score is returned to update the priority event queue until the execution event reaches the closed state.

2. The method according to claim 1, characterized in that, The steps of collecting alarm signals from multiple heterogeneous event sources, converting each alarm signal into a unified event data structure carrying the target gimbal location and resource requirement estimates, and obtaining the events to be processed, specifically include: Collect alarm signals from at least two of the following event sources: AI analysis module event source, sensor event source, external alarm subscription event source, operation and maintenance platform command event source, and periodic event source; All alarm signals are uniformly converted into a standard event data structure to obtain the events to be processed; the standard event data structure includes at least a unique event identifier, event type, event source, event generation timestamp, comprehensive priority score, target PTZ location, threat level, scene identifier, confidence score, extended data fields, and resource requirement estimation fields.

3. The method according to claim 1, characterized in that, The step of calculating a comprehensive priority score by weighting the dynamic feature dimensions of the events to be processed specifically includes: Obtain the threat level score, urgency score, scenario importance score, historical frequency score, and confidence score of the event to be processed; The weight coefficients for each dimension are determined based on the current scenario mode, and the comprehensive priority score is obtained by weighted summation according to the following formula: ;in, Scoring based on threat level; Scoring is based on the urgency level. Score the importance of the scene; Scoring is based on historical frequency. Scoring for the confidence dimension; , , , , These are the corresponding weighting coefficients.

4. The method according to claim 3, characterized in that, The urgency dimension score The calculation formula is: ;in, , The current target distance, To the maximum effective monitoring distance; , The current target movement speed, The speed threshold; The target orientation factor is set to 1.0 when the target is facing the center of the monitoring area, 0.0 when it is facing away from the center, and determined by linear interpolation when the target is facing other angles. , , The sub-weight coefficients, after normalization, are obtained as follows: , for The preset normalization upper limit.

5. The method according to claim 3, characterized in that, The step of determining the weight coefficients corresponding to each dimension based on the current scene mode specifically includes: When an event with the highest threat level appears among the pending events, the current scenario mode is determined to be emergency mode; If the conditions for determining the emergency mode are not met, and the number of concurrent events to be processed is greater than or equal to the preset concurrency threshold, the current scenario mode will be determined as peak mode. If the conditions for determining the emergency mode and the peak mode are not met, the current scenario mode is determined to be the normal mode. In the emergency mode, the weight of the threat level dimension is greater than the corresponding weight in the peak mode, and the sum of the weights of the threat level dimension and the urgency dimension in the peak mode is greater than the sum of the corresponding weights in the normal mode. Based on the determined current scenario mode, the weight coefficients corresponding to each dimension are obtained by querying the preset weight configuration table.

6. The method according to claim 1, characterized in that, The step of detecting physical resource conflicts between the head event and the currently processed event in terms of PTZ control and encoder channel, and selecting a resolution strategy based on the conflict characteristics, specifically includes: Detect physical resource conflicts between the queue-head event and the currently being processed event in at least one of the following: PTZ control, encoder channel, network bandwidth, and storage space, to obtain a set of conflicting events; Determine whether there is an event with the highest threat level in the set of conflict events, and whether the difference between the comprehensive priority score of the highest-level event and the currently being processed event is greater than a preset preemption threshold. If so, determine the emergency preemption strategy as the resolution strategy, save the context state of the currently being processed event and switch resources to the highest-level event. After the highest-level event is processed, recalculate the comprehensive priority score of the preempted event and restore the execution of the preempted event based on the saved context state according to the current priority event queue status. If the emergency preemption strategy is not determined, it is determined whether the conflicting resources in the conflict event set include gimbal control and whether the distance between the target locations of each event is less than a preset distance threshold. If so, the distance merging strategy is determined as the resolution strategy, and the conflicting events are merged into a comprehensive tracking task. The target location of the comprehensive tracking task is determined by weighting the comprehensive priority scores of each conflicting event. Otherwise, the time-slicing strategy is determined as the resolution strategy, and time slices are allocated according to the weighted ratio of the comprehensive priority score of each event in the conflict event set, so as to perform time-sharing scheduling of the gimbal control.

7. The method according to claim 1, characterized in that, The step of performing resource pre-locking based on the resource demand forecast specifically includes: The required resources are determined by querying the resource requirement configuration table based on the event type of the executed event; the required resources include at least one of encoder channel, network bandwidth, storage space, and PTZ control. Check the available resources in the current system resource pool. If the available resources meet the required resources, pre-lock the required resources and mark the resources as locked in the unified event data structure of the execution event. If the available margin is insufficient to meet the required resources, and the overall priority score of the execution event is higher than that of the low-priority event that is currently occupying resources, then the resources occupied by the low-priority event are released and reallocated to the execution event. If the available resources are insufficient to meet the required resources and the reallocation cannot be performed, the execution event is marked as a resource waiting state, and the resources are reallocated in descending order of the comprehensive priority score when they are released.

8. The method according to claim 1, characterized in that, The steps of driving the gimbal mechanism to complete physical alignment and target tracking based on the target gimbal position of the execution event, and driving external linkage devices to perform physical linkage actions based on the type of the execution event, to obtain the physical execution state reflecting each processing stage, specifically include: According to the predefined state machine, the execution events are driven sequentially through the physical alignment stage, the video capture stage, the encrypted upload stage, and the linkage notification stage; wherein, in the physical alignment stage, the PTZ mechanism is driven to complete physical alignment and target tracking, and in the linkage notification stage, the external linkage device is driven to perform physical linkage actions. Configure timeout timers and exception rollback strategies for each stage in the state machine. When any stage times out or fails, proceed to the next stage in a retry or degradation manner according to the exception rollback strategy until the shutdown state is reached, thus obtaining the physical execution state.

9. The method according to claim 8, characterized in that, The abnormal rollback strategy is configured as follows: If the physical alignment phase times out, a preset position is used to replace the target position and the process proceeds to the next phase. After the video capture stage times out, the acquired video and image content is retained and the process proceeds to the next stage; If the encrypted upload phase times out, a local encrypted copy is retained and the encrypted upload is retried after the network is restored. If the maximum number of retries is exceeded, the process proceeds to the next phase. If the linked notification phase times out, the corresponding operation is skipped and the process proceeds to the next phase. Furthermore, the retry is performed according to the exponential backoff strategy, and the number of retries in the same stage does not exceed the preset maximum number.

10. The method according to claim 1, characterized in that, The step of pushing the stage callback message to the subscribed external business system through the subscription interface and obtaining the callback feedback from the external business system specifically includes: The phase callback message is pushed to the external business system through either long connection push mode or short connection callback mode; The long-connection push mode reconnects based on the most recent event identifier after the connection is broken and resends the phase callback messages during the disconnection period; The short connection callback mode retryes according to the exponential backoff strategy when the push fails and deduplicates the same event based on the unique identifier of the event; Receive callback feedback returned by the external business system for the stage callback message.

Images