A multi-algorithm model dynamic scheduling method and system for urban security

Abstract

The application discloses a kind of multi-algorithm model dynamic scheduling method and system for city security, and the method comprises: collecting video stream data, edge node computing load information and the security warning level of each monitoring area, and extracting the space-time dynamic characteristics of monitoring scene, regional risk level characteristics and node computing response characteristics, to generate the real-time demand level of each monitoring area algorithm model;Based on algorithm model real-time demand level and the residual computing power distribution of edge node, generate the multi-algorithm model scheduling priority sequence of each monitoring area;According to multi-algorithm model scheduling priority sequence, generate the conflict-free scheduling timetable of multi-model parallel execution;According to conflict-free scheduling timetable, execute model instance dynamic migration and version hot switching between edge computing nodes.Utilize the embodiment of the application, can improve edge node computing power utilization efficiency and task response real-time, and enhance the adaptive scheduling capability of city security system in complex dynamic scene.

Description

Technical Field

[0001] This invention belongs to the field of urban security technology, and in particular, it is a dynamic scheduling method and system for multi-algorithm models for urban security. Background Technology

[0002] Currently, urban security monitoring systems are gradually evolving towards intelligence and edge computing, achieving real-time risk perception and early warning by deploying various algorithm models (such as facial recognition, vehicle detection, and behavior analysis) at edge nodes. However, existing scheduling methods mostly employ static configuration or simple load balancing strategies, which are difficult to adapt to the dynamic changes in video stream density, regional security levels, and computing resources in monitoring scenarios. On the one hand, different algorithm models compete for and are mutually exclusive with computing resources, lacking an effective coordination mechanism for dependencies and conflicts between models, resulting in low resource utilization at edge nodes and uncontrollable task response delays. On the other hand, traditional scheduling methods fail to dynamically couple differentiated strategies such as prioritizing recognition accuracy and real-time response with the spatiotemporal characteristics of the scene and the regional risk level, making it impossible to achieve multi-objective optimization with limited computing power. Furthermore, existing systems lack forward-looking prediction of future demand changes and the ability to perform online hot migration of model instances. When monitoring hotspots shift or security situations change abruptly, it is difficult to adjust model deployment in a timely manner, affecting the overall reliability and real-time performance of the security system. Summary of the Invention

[0003] The purpose of this invention is to provide a dynamic scheduling method and system for multiple algorithm models for urban security, in order to overcome the shortcomings of the existing technology, improve the computing power utilization efficiency and real-time response of edge nodes, and enhance the adaptive scheduling capability of urban security systems in complex dynamic scenarios.

[0004] One embodiment of this application provides a dynamic scheduling method for multiple algorithm models in urban security, the method comprising: It collects video stream data, edge node computing load information, and security warning levels of each monitoring area in real time in urban security monitoring scenarios, and extracts the spatiotemporal dynamic features, regional risk level features, and node computing response features of the monitoring scenarios. Based on the aforementioned spatiotemporal dynamic characteristics, regional risk level characteristics, and node computation response characteristics, and combined with a preset scheduling strategy prioritizing identification accuracy or real-time response, the real-time demand level of the algorithm model for each monitoring area is generated. Based on the real-time demand level of the algorithm model and the remaining computing power distribution of edge nodes, the Nash equilibrium negotiation algorithm is used to generate a multi-algorithm model scheduling priority sequence for each monitoring area. Based on the scheduling priority sequence of the multi-algorithm models and combined with the resource mutual exclusion constraints between the algorithm models, a conflict-free scheduling schedule for the parallel execution of the multi-model model is generated using a conflict graph coloring algorithm. Based on the conflict-free scheduling schedule, the demand change trend at a preset time is predicted by a temporal convolutional network and a multi-algorithm model adaptation map is constructed. Based on the adaptation map, dynamic migration of model instances and hot switching of versions between edge computing nodes are performed to complete the dynamic scheduling of multi-algorithm models in urban security scenarios.

[0005] Another embodiment of this application provides a dynamic scheduling system for multiple algorithm models in urban security, the system comprising: The acquisition module is used to collect video stream data, edge node computing load information, and security warning levels of each monitoring area in real time in urban security monitoring scenarios, and to extract the spatiotemporal dynamic features, regional risk level features, and node computing response features of the monitoring scenario. The generation module is used to generate the real-time demand level of the algorithm model for each monitoring area based on the spatiotemporal dynamic characteristics, regional risk level characteristics and node calculation response characteristics, combined with a preset scheduling strategy that prioritizes identification accuracy or real-time response. The negotiation module is used to generate a multi-algorithm model scheduling priority sequence for each monitoring area based on the real-time demand level of the algorithm model and the remaining computing power distribution of the edge nodes using the Nash equilibrium negotiation algorithm. The scheduling module is used to generate a conflict-free scheduling schedule for the parallel execution of multiple models by combining the priority sequence of the multi-algorithm models with the resource mutual exclusion constraints between the algorithm models and using the conflict graph coloring algorithm. The execution module is used to predict the demand change trend at a preset time in the future and construct a multi-algorithm model adaptation map based on the conflict-free scheduling schedule and the temporal convolutional network. Based on the adaptation map, it performs dynamic migration of model instances and hot switching of versions between edge computing nodes to complete the dynamic scheduling of multi-algorithm models in urban security scenarios.

[0006] Another embodiment of this application provides a storage medium storing a computer program, wherein the computer program is configured to execute the method described in any of the preceding claims when running.

[0007] Another embodiment of this application provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described in any of the preceding claims.

[0008] Compared with existing technologies, the present invention provides a dynamic scheduling method for multi-algorithm models for urban security, which can improve the computing power utilization efficiency and real-time task response of edge nodes, and enhance the adaptive scheduling capability of urban security systems in complex dynamic scenarios. Attached Figure Description

[0009] Figure 1 The hardware structure block diagram of a computer terminal for a dynamic scheduling method of multi-algorithm models for urban security provided in an embodiment of the present invention; Figure 2 A flowchart illustrating a dynamic scheduling method for multi-algorithm models in urban security, provided by an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a multi-algorithm model dynamic scheduling system for urban security provided in an embodiment of the present invention. Detailed Implementation

[0010] The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0011] This invention first provides a dynamic scheduling method for multiple algorithm models for urban security. This method can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0012] The following detailed explanation uses a computer terminal as an example. Figure 1 This is a hardware structure block diagram of a computer terminal for a dynamic scheduling method of multi-algorithm models for urban security, provided in an embodiment of the present invention. Figure 1 As shown, the computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0013] See Figure 2 The present invention provides a dynamic scheduling method for multiple algorithm models for urban security, which may include the following steps: S201 collects video stream data, edge node computing load information, and security warning levels of each monitoring area in real time in urban security monitoring scenarios, and extracts the spatiotemporal dynamic features, regional risk level features, and node computing response features of the monitoring scenarios. Specifically, video stream data of each monitored area can be collected from the front-end camera, and load information including at least CPU utilization, memory usage and network bandwidth can be obtained from the edge computing node. Real-time security alert levels of each area can be synchronized from the security platform to generate a multi-source real-time data set. The core of this step is to complete the cross-terminal and cross-platform synchronous collection of three types of core real-time data in urban security scenarios, and integrate heterogeneous data to form a standardized multi-source dataset. This provides a complete and real-time data foundation for the subsequent extraction of scenario features, risk features, and computing power features. The specific implementation method is as follows: The front-end camera is the core sensing device for comprehensive video acquisition in urban security, covering all monitored areas such as city roads, commercial districts, residential areas, and checkpoints. The device continuously acquires high-definition dynamic video stream data. The video stream uses a fixed frame rate transmission, typically set at 25 frames per second. This frame rate parameter can completely capture dynamic changes in security scenarios such as pedestrian movement, vehicle passage, and crowd gathering, without issues like image stuttering or loss of dynamic details. The video stream data is a continuous time-series image frame sequence, containing raw visual information such as the content of each monitored area, target dynamics, and environmental conditions. The acquisition process uses a real-time streaming transmission mode, with data transmission latency stably controlled within 20ms, ensuring data real-time performance and meeting the timeliness requirements of dynamic security scheduling.

[0014] Edge computing nodes are the core computing power units that support the operation of security algorithm models and video data processing. The collected load information is used to accurately characterize the real-time computing power status of the nodes. The core parameters include three types: CPU utilization, memory utilization, and network bandwidth. All parameters adopt a real-time dynamic sampling mode, and the sampling frequency is consistent with the video stream acquisition frequency, which is uniformly 25 times per second to ensure data timing alignment. The CPU utilization parameter ranges from 0 to 100, representing the current resource usage ratio of the edge node's central processor. A higher value indicates less remaining computing power. In the example, the CPU utilization rate of the node is 15% in a normal idle state and can reach 85% under high load. The memory utilization parameter ranges from 0 to 100, representing the percentage of memory used by the node. It directly determines the number of algorithm models and data processing volume that the node can support. In the example, the memory utilization rate is 30% in a typical security scenario and can be increased to 78% when multiple models are running in parallel. The network bandwidth parameter is in Mbps, representing the current available data transmission rate of the node. It directly affects the efficiency of video stream reception, model data interaction, and scheduling command transmission. The normal idle bandwidth is 100Mbps, and the available bandwidth will drop to 45Mbps in high data transmission scenarios.

[0015] The security platform serves as a unified management and control backend for urban security. It can aggregate the security situation, risk events, and early warning feedback information of each monitored area in real time, and simultaneously output the real-time security early warning level of each area. The early warning level adopts a grading standard from 1 to 5. The higher the value, the higher the security risk of the area and the higher the dispatch priority. Level 1 is a risk-free normal area, Level 3 is a general risk area, and Level 5 is a major risk emergency area. In the example, the early warning level of a regular urban road section is Level 1, the early warning level of a densely populated commercial area during holidays is Level 3, and the early warning level of an area with sudden abnormal events is Level 5.

[0016] After completing the synchronous collection of three types of data, the system performs time-series alignment and format standardization on the scattered single-type data, unifying the collection timestamps, data precision, and storage format of all data, and eliminating empty data, abnormal drift data, and delayed data generated during the collection process. Finally, it integrates and generates a multi-source real-time data set, which includes video time-series data of the entire monitoring area, computing power load time-series data of each edge node, and risk warning classification data of each area, realizing the unified collection of multi-dimensional security data and providing complete data support for subsequent multi-level feature extraction.

[0017] Spatiotemporal slicing is performed on video stream data in multi-source real-time datasets to extract motion vector density, target dwell time and crowd gathering degree of each monitored area within a preset time window, generating spatiotemporal dynamic feature vectors. The core of this step is to decompose the temporal and spatial dimensions of continuous video streams through spatiotemporal slicing, mine the dynamic change characteristics of the monitoring scene, and transform the visualized video images into quantifiable and computable digital feature vectors, thereby realizing a structured expression of dynamic information in the security scene. The specific implementation method is as follows: Spatiotemporal slicing is a structured decomposition method for continuous video stream data, covering both temporal and spatial dimensions. It overcomes the drawbacks of storing video streams as a whole and without structure, accurately capturing dynamic changes in local spatiotemporal regions. The temporal dimension uses a preset fixed time window for slicing; this solution uses a 3-second preset time window, which is suitable for the dynamic changes in urban security scenarios. This allows for capturing short-term, sudden movements of people running or unusual gatherings, while avoiding feature extraction biases caused by random errors in single frames. Each time window corresponds to a set of independent video slice data. The spatial dimension is divided evenly according to the pixel area of ​​the camera's monitoring image, dividing a single video frame into several uniformly sized spatial sub-regions. Each sub-region participates independently in feature calculation, ensuring the precision of spatial feature extraction.

[0018] Based on the video sub-data after slice processing, three core spatiotemporal features were extracted: motion vector density, target dwell time, and crowd density. Motion vector density is used to quantify the intensity of movement of target objects within the monitored area. It is calculated by combining the number of displacement vectors and the sum of vector amplitudes of all moving targets in the spatial sub-region within the statistical time window with the total area of ​​pixels in the region. The value ranges from 0 to 1. The larger the value, the more frequent the movement of people, vehicles, and other targets in the region, and the higher the risk of abnormal dynamics. In the example, the motion vector density of an open road section is 0.12, and the motion vector density of a densely populated road section is 0.76.

[0019] The target dwell time is used to calculate the total duration of various moving targets within the monitored area within a statistical time window, measured in seconds. It characterizes the dwell status of targets within the area and can effectively identify abnormal security behaviors such as people loitering and vehicles lingering. In the example, the average dwell time of a single target in a normal passage scenario is 0.5 seconds, while the dwell time of a target in an abnormal loitering scenario can reach 2.8 seconds, which is close to the maximum value of the preset time window.

[0020] Crowd density is used to quantify the dense distribution of people within a monitored area. It is calculated by the ratio of the number of people in a spatial sub-region and the percentage of overlap between the targets to the effective monitored area within a statistical time window. The value ranges from 0 to 1. The higher the value, the higher the crowd density and the greater the public safety risk. In the example, the crowd density is 0.18 in the dispersed passage scenario and 0.85 in the dense gathering scenario.

[0021] After completing the quantitative calculation of the three types of features, the motion vector density, target dwell time normalized value, and crowd gathering degree within the corresponding time window of each monitoring area are sequentially spliced ​​together and integrated according to fixed feature sorting rules to generate a spatiotemporal dynamic feature vector with unified dimensions. Each vector accurately corresponds to the scene dynamic state of a single monitoring area and a single time window, realizing the digital and structured representation of spatiotemporal dynamic information of security scenes.

[0022] Based on spatiotemporal dynamic feature vectors and combined with the real-time safety warning levels of each region, regional risk heat values ​​are calculated by weighted fusion to identify high-risk periods and high-risk location attributes, and to generate a set of regional risk level feature descriptions. The core of this step is to integrate dynamic features of the scene with platform risk warning information, quantify the regional security risk level through a weighted fusion algorithm, accurately divide risk periods and risk locations, and construct a standardized regional risk feature system. This provides a risk basis for subsequent model requirement level determination. The specific implementation method is as follows: The weighted fusion algorithm is the core algorithm for realizing the fusion calculation of multi-dimensional risk features. Its core logic is to assign differentiated weight coefficients to spatiotemporal dynamic features and safety warning levels, taking into account both real-time dynamic changes in the scenario and the platform's official risk assessment results, thus avoiding risk assessment bias caused by a single feature. The algorithm sets the weight coefficient W_1 for spatiotemporal dynamic features to 0.6, representing that real-time scenario dynamics are the core basis for risk assessment. The weight coefficient W_2 for safety warning levels is set to 0.4, representing that the platform's warning level plays a corrective and constraining role in risk assessment. The sum of the two weight coefficients is fixed at 1 to ensure the rationality and standardization of the fusion calculation.

[0023] Regional risk heatmap is a core quantitative indicator for assessing the level of security risk in a monitored area. Its value ranges from 0 to 100, with higher values ​​indicating higher real-time security risk. The calculation process is as follows: First, the overall mean of the spatiotemporal dynamic feature vector is mapped from 0 to 100 to obtain the dynamic risk baseline value. Then, security warning levels 1 to 5 are proportionally mapped to warning risk correction values ​​from 0 to 100. Finally, the calculation is completed using the weighted formula: Risk Heatmap Value = Dynamic Risk Base Value × W_1 + Warning Risk Correction Value × W_2. In the example, the dynamic risk baseline value for a certain business district is 80, and the corresponding warning level correction value is 70. After weighting, the risk heatmap value for this area is 76, placing it in the medium-to-high risk range.

[0024] After obtaining the risk heatmap values ​​for all monitoring areas and time windows across the entire region, the system identifies the attributes of high-risk periods and high-risk locations. The system presets a risk heatmap value of 60 as the risk threshold; time windows with heatmap values ​​exceeding 60 are identified as high-risk periods, and monitoring locations with heatmap values ​​exceeding 60 are identified as high-risk locations. Simultaneously, the system provides detailed annotations of risk attributes, including three categories: risk duration, risk fluctuation amplitude, and risk scenario type. Risk duration is calculated as the cumulative duration of consecutive high-risk windows; risk fluctuation amplitude is calculated as the difference in heatmap values ​​between adjacent time windows; and risk scenario type distinguishes between different risk scenarios such as crowd gatherings, vehicle congestion, and abnormal personnel movement.

[0025] After completing the risk quantification and attribute identification of all regions, the risk heat values, risk time period attributes, risk location attributes, and risk scenario attributes of each region are integrated and uniformly collected according to the region number and time series order to generate a regional risk level feature description set. This description set fully records the real-time risk status and subdivided risk characteristics of the entire monitored area, providing accurate risk dimension data support for subsequent scheduling strategy matching and model requirement classification.

[0026] The load information of each edge node is normalized and trend analyzed to extract node response latency, task backlog, and available computing power ratio, and to generate node computing response feature vectors.

[0027] The core of this step is to standardize and perform time-series analysis on the raw load data of edge nodes, mine the real-time computing power performance and operating status characteristics of the nodes, and transform the raw load parameters into standardized computing power feature vectors to achieve a unified quantitative representation of the computing power resource status of edge nodes. The specific implementation method is as follows: Normalization is used to address the issues of inconsistent dimensions and numerical ranges among various load parameters at edge nodes. A max-min normalization method is employed to map the raw values ​​of all load parameters to a standard range of 0 to 1, ensuring that computing power data from different parameters and nodes can be compared and integrated horizontally. For the three types of raw load data—CPU utilization, memory usage, and network bandwidth—the maximum and minimum values ​​of the parameters across all edge nodes are extracted as normalization benchmarks. The closer the normalized value of a single parameter is to 1, the higher the resource utilization and the lower the remaining resources; the closer the value is to 0, the more idle resources there are.

[0028] Trend analysis is a time-series dynamic analysis method that fits and analyzes normalized load data over multiple consecutive time windows to capture the dynamic changes in the computing power load of edge nodes. It distinguishes between three operating trends: stable load, continuously rising load, and sudden increase or decrease in load. It can effectively predict the upcoming overload, idle, and other state changes of node computing power, avoiding the lag problem of computing power judgment caused by static data at a single moment. The time-series statistical interval of trend analysis is set to 5 consecutive time windows, accumulating 15 seconds of load data to ensure the accuracy of trend judgment.

[0029] Based on the standardized and trend-analyzed load data, three types of core node computational response characteristics are extracted. Node response latency, measured in milliseconds, represents the response time of an edge node receiving scheduling instructions and executing algorithm model inference. The value ranges from 10ms to 200ms; a smaller value indicates better node computing power response performance. In the example, the response latency of a low-load node is 25ms, while that of a high-load node can reach 120ms. Task backlog represents the number of security detection tasks currently queued for processing by the node. A larger value indicates more severe task congestion and weaker real-time processing capabilities. In the example, a normal node has a task backlog of 3 tasks, while a busy node has a backlog of up to 18 tasks. Available computing power ratio is the ratio of a node's remaining available computing power to its total computing power, ranging from 0 to 1. It directly characterizes the node's ability to handle new algorithm models and new scheduling tasks. In the example, the available computing power ratio of an idle node is 0.85, while that of a fully loaded node is only 0.1.

[0030] Finally, the normalized values ​​of response latency, task backlog, and available computing power ratio corresponding to each edge node are concatenated in an orderly manner, sorted and integrated according to fixed feature dimensions, to generate a node computing response feature vector exclusive to each edge node. This accurately quantifies the real-time computing power response capability and resource status of each edge node, providing core data support in the computing power dimension for subsequent model requirement matching and computing power scheduling game.

[0031] S202, Based on the spatiotemporal dynamic characteristics, regional risk level characteristics and node computation response characteristics, and combined with the preset scheduling strategy of prioritizing identification accuracy or real-time response, the real-time demand level of the algorithm model for each monitoring area is generated. Specifically, the spatiotemporal dynamic feature vector can be merged with the regional risk level feature description set to construct the state feature matrix of each monitoring area, which is used to characterize the complexity and priority of the current scene. The core of this step is to integrate the spatiotemporal dynamic information and regional risk information of the monitoring scene, standardize and fuse these two types of heterogeneous feature data, construct a matrix data structure that can comprehensively depict the real-time scene status of the monitoring area, quantify the scene complexity and security priority, and provide standardized feature inputs for subsequent requirement score calculations. The specific implementation method is as follows: The spatiotemporal dynamic feature vector is a dynamic data carrier of the scene previously extracted through video stream data slicing. This vector is a fixed-dimensional floating-point data sequence with a uniform 8-dimensional dimension, corresponding to eight core spatiotemporal parameters within a preset time window: motion vector density, duration of single-person target stay, duration of multiple-person group stay, frequency of small target movement, displacement amplitude of large-scale targets, scene dynamic change rate, proportion of abnormal movement, and proportion of static scene. All parameter values ​​are normalized to the range of 0 to 1. The closer the value is to 1, the more drastic the scene dynamic changes, the more frequent the target activity, and the higher the scene complexity. Taking a city business district monitoring area as an example, this area has dense pedestrian and vehicular traffic, and the corresponding spatiotemporal dynamic feature vector parameters are generally high, with the motion vector density parameter valued at 0.82 and the crowd gathering degree parameter valued at 0.79, which can accurately reflect the high dynamic scene characteristics of this area.

[0032] The regional risk level feature description set is a risk data set generated by weighted fusion of spatiotemporal features and security warning levels. It includes four core descriptive parameters: regional risk heat map average, proportion of high-risk locations, duration of high-risk periods, and warning level weight coefficient. It has also undergone normalization processing within the range of 0 to 1. A higher risk heat map average value indicates a greater overall security risk in the region. The proportion of high-risk locations represents the proportion of monitored sub-areas with potential security risks within the region. The warning level weight coefficient is calculated from the real-time warning levels of the security platform: Level 1 warning corresponds to a weight range of 0.9 to 1.0, Level 2 warning to 0.6 to 0.89, Level 3 warning to 0.3 to 0.59, and Level 4 warning to 0 to 0.29. Taking a city transportation hub monitoring area as an example, this area is in a Level 2 security warning state, with a warning level weight coefficient of 0.75 and a high-risk location proportion of 0.68, fully presenting the regional risk distribution characteristics.

[0033] After normalization preprocessing, the two types of feature data are merged using a horizontal splicing method. This avoids issues related to inconsistent dimensions and units between the two types of feature data, ensuring no loss or redundant overlap of feature information. During the merging process, temporal alignment is performed on the two types of feature data to ensure that the spatiotemporal dynamic features and regional risk features involved in the merging are real-time data from the same sampling time, avoiding feature distortion caused by temporal misalignment. After merging a single region, a complete regional state data with 12-dimensional feature parameters is formed, with 8-dimensional spatiotemporal dynamic parameters first and 4-dimensional regional risk parameters second, strictly fixing the feature arrangement order to ensure the standardization of subsequent matrix construction.

[0034] The merged status data of all monitoring areas are arranged sequentially by area number to construct a global status feature matrix. The row dimension of the matrix corresponds to the number of all independent monitoring areas in the city, and the column dimension is fixed at 12-dimensional feature parameters. Each element in the matrix is ​​a normalized floating-point value. This status feature matrix can intuitively represent the real-time scene status of each monitoring area. The higher the overall value of a row in the matrix, the higher the dynamic complexity of the scene and the higher the security risk level of the corresponding monitoring area, and the higher the security scheduling priority. This accurately realizes the quantitative expression of scene complexity and scheduling priority, providing accurate basic data support for subsequent strategy correction and demand calculation.

[0035] Read the preset scheduling strategy parameters. If it is a recognition accuracy priority strategy, assign a higher basic requirement score to the high-precision model. If it is a real-time response priority strategy, assign a higher basic requirement score to the lightweight model and generate a strategy correction coefficient. The core of this step is to read the system's preset core scheduling rules, assign different basic requirement scores to different types of algorithm models, and generate strategy correction coefficients by combining quantitative calculation methods. This achieves directional constraints on the model requirement assessment by the scheduling strategy, allowing the requirement level to generate scheduling goals that fit the core scheduling objectives of the scenario. The specific implementation method is as follows: The preset scheduling strategy parameters are core scheduling rule identifiers that are pre-defined in the system. These are globally unified single-value identifiers with only two state values, corresponding to the accuracy-first strategy and the real-time response-first strategy, respectively. The parameters are stored in the system scheduling configuration center and can be manually switched based on urban security management needs or automatically switched based on time periods. The parameter refresh latency is no more than 20ms, allowing for real-time adaptation to scenario scheduling requirements. The accuracy-first strategy is suitable for high-risk security scenarios with dense populations, complex risks, and the need for accurate identification of abnormal targets, while the real-time response-first strategy is suitable for dynamic security scenarios with rapid traffic and pedestrian flow, requiring quick capture of instantaneous abnormal behavior.

[0036] The basic requirement score quantifies the adaptability of different algorithm models to specific scenario requirements. The score ranges from 0 to 100; a higher score indicates stronger adaptability and higher basic scenario requirements for the current strategy. Algorithm models are divided into two categories: high-precision and lightweight. High-precision models feature comprehensive feature extraction, high target recognition accuracy, and strong anti-interference capabilities, accurately identifying complex scene targets such as occluded, blurred, and small targets. Lightweight models feature small parameter size, short computation time, low resource consumption, and fast response speed, adapting to low-latency, fast-iteration real-time monitoring scenarios.

[0037] When the system reads a scheduling strategy parameter prioritizing recognition accuracy, it assigns a base requirement score of 85 to 100 to all high-precision algorithm models and a base requirement score of 40 to 60 to lightweight algorithm models. This highlights the core requirement of accurate recognition in complex and risky scenarios. In the example, the base requirement score for high-precision models is set to 92, and the base requirement score for lightweight models is set to 48, creating a clear difference in score values. When the system reads a scheduling strategy parameter prioritizing real-time response, the system assigns the opposite score, assigning a base requirement score of 85 to 100 to lightweight algorithm models and a base requirement score of 40 to 60 to high-precision algorithm models. This prioritizes ensuring the real-time performance of scenario monitoring. In the example, the base requirement score for lightweight models is set to 90, and the base requirement score for high-precision models is set to 45.

[0038] The strategy correction coefficient is a quantified correction parameter generated from the basic demand score. It is used to perform overall weighted correction on the subsequent state feature matrix, realizing the fusion calculation of scheduling strategy and scene features. The correction coefficient ranges from 0.5 to 1.5. A coefficient greater than 1 indicates strengthening the demand weight of the corresponding model, while a coefficient less than 1 indicates weakening the demand weight of the corresponding model. The system calculates the strategy correction coefficient based on the ratio of the basic demand scores of high-precision and low-precision models. Under the accuracy-first strategy, the strategy correction coefficient for the high-precision model is 1.35, and the strategy correction coefficient for the lightweight model is 0.65. Under the real-time response-first strategy, the strategy correction coefficient for the lightweight model is 1.35, and the strategy correction coefficient for the high-precision model is 0.65. The fixed coefficient assignment rules ensure the stability and consistency of the strategy constraints, accurately generating the strategy correction coefficient.

[0039] Multiply the state feature matrix with the policy correction coefficient, and then dynamically weight it by combining the proportion of available computing power in the node's response feature vector. Calculate the real-time demand score for each region for various algorithm models, and generate a region-model demand score matrix. The core of this step is to fuse scene state features and scheduling strategy constraints through matrix operations, and then dynamically adjust the algorithm based on the computing power resource status of edge nodes. This quantifies the real-time demand for different types of algorithm models in each monitoring area, constructs a standardized demand score matrix, and provides a quantitative basis for subsequent demand level determination. The specific implementation method is as follows: The multiplication of the state feature matrix and the policy correction coefficient is a weighted matrix multiplication operation. The core of the operation is to apply the policy correction coefficient to the feature parameters of all regions in the matrix, achieving a unified correction of the scheduling policy for the scene features across the entire region. During the operation, the corresponding policy correction coefficients are calculated independently for the high-precision model and the lightweight model, generating two sets of differentiated policy-corrected state matrices. Taking the accuracy-first policy as an example, the state feature parameters of all regions are multiplied by a 1.35 correction coefficient for the high-precision model and a 0.65 correction coefficient for the lightweight model. The corrected matrix values ​​retain the original scene complexity and risk level feature information while incorporating the preference constraints of the preset scheduling policy, ensuring that the feature data aligns with the current scheduling objective.

[0040] The node computing response feature vector is a standardized vector characterizing the computing power operation status of each edge node. The core parameter of the vector is the available computing power ratio, which ranges from 0 to 1. The parameter value represents the proportion of the edge node's currently idle and available computing power to the total computing power. The closer the value is to 1, the more abundant the node's remaining computing power, which can support the operation of complex and high-precision algorithm models. The closer the value is to 0, the more saturated the node's computing power is, and it can only be used for lightweight and simple algorithm models. This parameter is calculated by normalizing the real-time load data of the edge nodes and can reflect the node's computing power carrying capacity in real time. In the example, the available computing power ratio of edge nodes in the core urban area is 0.78, which means that 78% of the node's remaining computing power can be used to schedule new algorithm model tasks. The available computing power ratio of edge nodes in the old urban area is 0.32, which means that the node's computing power resources are relatively scarce.

[0041] Dynamic weighting is an adaptive adjustment process of computing power resources to the model demand score. The core logic is that the higher the proportion of available computing power of a node, the higher the weight of high-demand model tasks that the corresponding region can support, and the greater the positive increase in the demand score. In regions with insufficient computing power, the demand score of high-precision models is automatically reduced, while the demand adaptation score of lightweight models is increased. The weighting calculation adopts a linear dynamic weighting algorithm, using the state matrix value after policy correction as the base value, multiplied by the proportion of available computing power of the edge nodes of the corresponding region, and finally obtaining the real-time demand score of a single model in a single region. The score ranges from 0 to 100, and the higher the score, the more urgent the scheduling demand of the corresponding algorithm model in that region.

[0042] After calculating the demand scores for all regions and all models, all real-time demand scores are integrated according to the arrangement rule of region number as rows and algorithm model type as columns to generate a region-model demand score matrix. The number of rows in this matrix corresponds to the total number of all monitored regions in the city, and the number of columns corresponds to the total number of algorithm model types deployed in the system. Each element in the matrix represents the real-time demand score of the corresponding monitored region for the corresponding algorithm model. This matrix fully covers the quantitative results of demand for all regions and all models, with well-organized data dimensions and comprehensive information, providing complete quantitative data support for subsequent threshold filtering and priority ranking.

[0043] The region-model requirement score matrix is ​​sorted and thresholded to determine the required model type and performance level for each monitoring region at the current moment, ultimately generating the real-time requirement level of the algorithm model for each monitoring region.

[0044] The core of this step is to select the optimal model for a region by sorting by score, and to determine the level of demand by combining a fixed threshold. Inefficient model matching combinations are eliminated, and the real-time model demand standards for each region are accurately defined. This generates standardized demand level results, providing a core basis for subsequent model scheduling priority generation. The specific implementation method is as follows: The sorting of the region-model requirement score matrix adopts an in-row descending sorting method. Each monitoring region is treated as an independent unit, and all algorithm model requirement scores corresponding to that region are arranged in descending order. After sorting, a sequence of algorithm models with high to low adaptability to the current region can be directly obtained. The sorting process retains the original score values ​​and model type identifiers of all models, only adjusting the order to ensure that the sorting results accurately reflect the regional model adaptation priority. In the example, after sorting the high-risk business district, the high-precision target detection model with a requirement score of 91.2 points ranks first, the high-precision behavior analysis model with 88.7 points ranks second, and the lightweight monitoring and capture model with 52.3 points ranks last, intuitively reflecting the core model requirements of the region.

[0045] Thresholding is the core operation for filtering valid model requirements and eliminating invalid fit combinations. The system presets a fixed requirement filtering threshold of 65 points. This threshold is the optimal critical value determined through multi-scenario debugging. A requirement score of 65 or higher is considered a valid requirement model, indicating that the model is suitable for the current regional scenario and computing resource status and has scheduling value. A requirement score of less than 65 points is considered an invalid requirement model, indicating that the model has a low fit with the current regional scenario and computing resource conditions and will not be scheduled for adaptation. Thresholding verifies the model scores after sorting for each region, retaining valid requirement models and eliminating invalid requirement models to determine the currently schedulable valid model types for each monitored region.

[0046] Model performance levels are categorized based on the accuracy and computational power consumption of the effective demand models, into three levels: Level 1 is the ultra-high precision model level, corresponding to a demand score of 85 to 100, suitable for high-risk, high-complexity security areas; Level 2 is the conventional high precision model level, corresponding to a demand score of 65 to 84, suitable for medium-risk, conventional dynamic scene areas; Level 3 is the lightweight fast-response model level, corresponding to all effective lightweight models, suitable for low-risk, low-computing-power-margin areas. Through score range matching, the corresponding performance level can be matched to the effective models for each monitoring area, clearly defining the performance standards for model scheduling.

[0047] After completing the model type selection and performance level matching for each single region, and combining the overall risk level and scenario complexity of the region, a standardized real-time requirement level for algorithm models is established. The requirement levels are divided into three tiers from high to low: Level 1 Emergency Requirement, Level 2 Regular Requirement, and Level 3 Basic Requirement. High-risk regions with valid Level 1 performance model requirements are classified as Level 1 Emergency Requirement, requiring priority scheduling of model resources. Medium-risk regions with valid Level 2 performance model requirements are classified as Level 2 Regular Requirement, with resources scheduled according to the regular time sequence. Low-risk regions with only Level 3 Lightweight Model requirements are classified as Level 3 Basic Requirement, with resources flexibly scheduled as needed. After all monitored regions have completed the hierarchical determination, a unified real-time requirement level result for algorithm models across the entire domain is established, achieving scenario-based and adaptive quantitative output of model requirements to support subsequent game-theoretic scheduling and resource allocation calculations.

[0048] S203, based on the real-time demand level of the algorithm model and the remaining computing power distribution of the edge nodes, the Nash equilibrium negotiation algorithm is used to generate a multi-algorithm model scheduling priority sequence for each monitoring area; Specifically, the algorithm model of each monitoring area can be analyzed to determine the real-time demand level. Each area can be regarded as an intelligent agent participating in the game, and its utility function can be defined as the ratio of the degree of demand satisfaction to the resource consumption, thereby generating a set of utility functions of the game participants. The core of this step is to define the game players and quantify the payoff standards in urban security monitoring scenarios. It transforms the differentiated algorithm model requirements of various regions into quantifiable game indicators, builds a basic model for multi-regional computing resource game theory, and provides a unified basis for payoff evaluation for subsequent Nash equilibrium negotiation iterations. The specific implementation method is as follows: The real-time demand level of the algorithm model is a quantitative indicator generated by combining the spatiotemporal characteristics of the scene, the regional risk level, and the scheduling strategy. It is used to accurately define the urgency and performance requirements of various security algorithm models for different monitoring areas. This level is defined by a continuous quantitative value from 1 to 10. The larger the value, the higher the regional security risk and the more urgent the algorithm model scheduling requirement. Among them, levels 1 to 3 are low demand levels, corresponding to normal monitoring areas with stable scenes and no security risks, which only require the routine operation of lightweight target detection algorithms; levels 4 to 7 are medium demand levels, corresponding to ordinary security areas with slight personnel movement and routine passage monitoring, which require the operation of mid-range algorithm models that balance detection accuracy and inference speed; levels 8 to 10 are high demand levels, corresponding to high-risk monitoring areas with personnel gathering, frequent abnormal behavior, and high warning levels, which must schedule high-precision and high-complexity security identification algorithms for real-time operation. The system performs a complete analysis of the real-time demand levels of all monitored areas across the entire domain, accurately matches the appropriate algorithm model type, performance level, and demand priority for each area, filters out idle area data with no monitoring tasks or computing power requirements, retains all valid game participant data, and completes the pre-game data preprocessing work.

[0049] To achieve distributed and collaborative scheduling of computing resources across multiple regions, this step defines each independently divided monitoring area in the urban security system as a separate intelligent agent autonomously participating in resource competition. All agents are independent of each other, make autonomous decisions, and uniformly participate in the competition and negotiation of computing resources at edge nodes across the entire region. For example, the urban security system is divided into 15 independent monitoring areas according to geographical functions, including traffic monitoring areas on main urban roads, personnel monitoring areas in commercial districts, security monitoring areas around schools, and patrol monitoring areas at suburban intersections, etc., corresponding to 15 independent game agents. Each agent is uniquely bound to the real-time model demand level and scenario risk characteristics of the corresponding area, ensuring that the game agents accurately correspond to the actual security scheduling scenarios, with no agent redundancy or scenario omissions.

[0050] The utility function is a core mathematical model for measuring the resource scheduling benefits of a single intelligent agent and evaluating the merits of scheduling schemes. In this technical solution, the utility function of each regional intelligent agent is uniformly defined as the ratio of the degree to which the regional algorithm model's needs are met to the consumption of regional computing resources. Its core function is to quantify the cost-effectiveness of the scheduling scheme for each monitored region. The higher the final calculated value of the utility function, the higher the degree of matching of the regional model's needs, the higher the efficiency of computing resource utilization, and the stronger the rationality of the scheduling scheme. The dimensionless parameter of the degree of need satisfaction, ranging from 0 to 1, is used to characterize the degree of adaptation of the currently allocated edge computing resources to the regional model's operational needs. When the allocated computing power can fully support the full real-time operation of the regional high-precision algorithm, the degree of need satisfaction approaches 1 infinitely; when the allocated computing power can only support the operation of basic lightweight algorithms and cannot meet the needs of accurate identification, the degree of need satisfaction ranges from 0.4 to 0.7; when there is no available computing power to support the operation of any algorithm model, the degree of need satisfaction is 0. The resource consumption is a normalized dimensionless parameter in the range of 0 to 1, used to characterize the total amount of computing resources occupied by the edge node for the corresponding regional scheduling algorithm model. The larger the value, the greater the resource consumption and the higher the resource redundancy loss.

[0051] After clarifying the definition of intelligent agents and the rules for calculating utility functions, the system determines the corresponding weight for calculating the degree of demand satisfaction and the statistical range for resource consumption for each regional intelligent agent, based on its specific model's real-time demand level and scenario risk attributes. It then independently generates a unique utility function calculation expression for each intelligent agent. Finally, it integrates and summarizes the utility functions, parameter value rules, and scenario adaptation attributes of all intelligent agents to form a complete set of utility functions for all game participants. This set covers all effective game entities in the entire domain, providing a unified, standardized, and accurate basis for calculating returns for subsequent multi-round distributed game iterations and strategy updates.

[0052] Obtain the remaining computing power distribution data of each edge node, including the number of idle CPU cores, GPU memory availability, and memory availability of each node, and construct a global resource constraint vector; The core of this step is to collect the idle computing resources of edge computing nodes across the entire domain, quantify all effective resources available for scheduling multiple algorithm models, and construct a globally unified resource constraint standard through standardized processing. This sets a rigid resource ceiling for the game negotiation process, preventing issues such as over-scheduling and resource overload. The specific implementation method is as follows: The urban security edge computing system consists of multiple distributed edge nodes. All security video analysis, target recognition, and risk assessment algorithm models rely on the computing power of the edge nodes to run. The remaining computing power distribution data specifically refers to the idle computing power resources remaining after the edge nodes have completed the basic system operation and permanent security backup tasks, which can be used for new model scheduling, model migration, and model hot switching. All data is collected dynamically in real time at the millisecond level, with a collection and update frequency of 2 times per second, to ensure that the resource data is completely synchronized with the real-time operating status of the nodes and to avoid scheduling deviations caused by static data lag.

[0053] The number of idle CPU cores is a key parameter determining the inference speed and parallel task capacity of edge node algorithms. It is measured in physical cores. For urban security edge nodes, the total number of CPU cores per node is uniformly 16. The underlying resident processes and basic video decoding tasks consistently occupy 4 to 5 CPU cores, leaving the remaining unused physical cores as the number of idle CPU cores. Under normal operating conditions, the number of idle CPU cores per node is stable at 11 to 12. This parameter directly determines the number of lightweight and mid-range security algorithm models that a node can run in parallel. The more idle CPU cores a node has, the stronger its ability to process multi-area monitoring tasks in parallel.

[0054] GPU memory availability, measured in GB, is a crucial and scarce resource supporting the operation of high-precision, complex security algorithms. Complex algorithms such as high-precision face recognition, crowd density analysis, and abnormal behavior tracing have high GPU memory requirements. A single edge node is configured with 8GB of GPU memory, with basic video image preprocessing tasks occupying a fixed 2GB. The remaining memory space in real-time is the GPU memory availability. Under normal operating conditions, the node's GPU memory availability is maintained between 5GB and 6GB. This parameter is a core constraint for scheduling high-precision algorithm models in high-demand areas. Insufficient memory availability can lead to problems such as inference lag, decreased accuracy, and task interruptions in complex algorithm models.

[0055] Available memory is a fundamental resource parameter ensuring the stable and continuous operation of all algorithm models. It is measured in GB. A single edge node has a total physical memory capacity of 32GB. System services, data caching, and network transmission processes will consistently occupy approximately 10GB of memory. The remaining memory space that can be freely allocated to various algorithm models is the available memory. Under normal operating conditions, available memory is stable between 20GB and 22GB. Available memory directly affects the stability of model operation; insufficient memory resources can lead to scheduling failures such as model loading failures, hot-switching lag, and task backlog overflow.

[0056] After completing the real-time collection of three types of core computing power parameters for all edge nodes across the entire domain, in order to eliminate calculation deviations caused by differences in the units and magnitudes of different parameters, the system performs global normalization processing on all computing power parameters. Using the maximum resource capacity of a single node as a benchmark, the measured values ​​of idle CPU cores, GPU memory availability, and available memory are uniformly mapped to a dimensionless range of 0 to 1. Taking a single node as an example, with a maximum of 16 CPU cores and 12 currently idle, the normalized CPU resource coefficient is 0.75; with a maximum of 8GB of GPU memory and 6GB currently available, the normalized memory resource coefficient is 0.75; and with a maximum of 32GB of memory and 20GB currently available, the normalized memory resource coefficient is 0.625.

[0057] The normalized three types of computing resource coefficients for all edge nodes are integrated according to fixed node and parameter sorting rules to construct a global resource constraint vector with unified dimensions and standardized values. The dimensions of this vector correspond to the total number of edge nodes deployed across the entire domain. Under each dimension, the CPU resource coefficient, GPU memory resource coefficient, and memory resource coefficient of the corresponding node are stored in an ordered manner. This fully and accurately covers the upper limit threshold of the schedulable computing resources across the entire domain, forming an insurmountable rigid resource constraint during the game negotiation process. This ensures that all resource allocation strategies generated by the subsequent Nash equilibrium game are consistent with the actual carrying capacity of the edge nodes, thus avoiding scheduling problems such as resource over-provisioning and node overload from the source.

[0058] A distributed Nash equilibrium negotiation algorithm is adopted. Each agent in each region performs multiple rounds of policy updates based on the set of utility functions and the global resource constraint vector, gradually converging to a stable state where the utility of each party cannot be improved individually, thus generating a Nash equilibrium solution. The core of this step is to rely on the distributed Nash equilibrium negotiation algorithm to drive all regional game agents to complete autonomous strategy iteration and optimization under global resource constraints, balance the model scheduling needs and resource consumption ratios of each region, achieve a stable equilibrium state with globally optimal scheduling utility, and output a compliant and effective optimal game solution. The specific implementation method is as follows: The distributed Nash equilibrium negotiation algorithm is an optimized algorithm adapted to the distributed, multi-node, and multi-demand scheduling scenarios of urban security. Unlike traditional centralized game theory algorithms that require a central node for unified coordination, this algorithm allows all regional agents to independently and in parallel complete policy calculations and updates without centralized control. It is suitable for the large-scale, distributed computing power deployment architecture and fragmented monitoring scenarios of urban security. The core convergence objective of the algorithm is to achieve Pareto optimal equilibrium, meaning that in the final stable state, no single monitoring regional agent can improve its own utility value by individually modifying its resource request strategy or model scheduling demand strategy, and policy modification will not cause a decrease in the utility value of any other regional agent, ultimately achieving a dynamic balance in the allocation of resources across the entire region.

[0059] In the initial stage of algorithm iteration, the system generates initial resource request strategies based on the real-time demand levels of the algorithm models of agents in each region, achieving differentiated configuration of the initial strategies. For high-risk agents in regions with demand levels of 8 to 10, the initial strategy prioritizes requesting high-ratio GPU memory and CPU core resources to meet the requirements of high-precision algorithm operation; for agents in regions with demand levels of 4 to 7, the initial strategy requests CPU, GPU, and memory resources in a balanced manner to meet the mixed operation requirements of mid-range algorithms; for agents in regions with demand levels of 1 to 3, the initial strategy requests only a small amount of CPU and memory resources to meet only the basic operation requirements of lightweight algorithms. All initial strategies strictly adhere to the resource upper limit of the global resource constraint vector, and there are no invalid strategies that exceed resource requests.

[0060] Multi-round policy updates are the core process for the algorithm to achieve balanced convergence. The system sets a maximum of 50 iteration rounds and a utility convergence accuracy threshold of 0.001 to ensure iterative efficiency and optimization accuracy. During each iteration, all regional agents synchronously call a preset set of utility functions, combine the global resource constraint vector to verify their current resource occupancy in real time, calculate the real-time utility value corresponding to the current policy, and simultaneously perceive the resource allocation status and utility gains of other agents in the entire domain. Based on this, they fine-tune their own resource request structure and model scheduling priority strategy. If the agent's current utility value is too low and the demand is not adequately met, the resource allocation is adjusted appropriately, prioritizing the acquisition of core computing resources suitable for its own scenario to improve the model's demand matching degree. If the agent's current resource consumption is too high and the utility cost-effectiveness is low, redundant resource requests are proactively reduced, and idle computing resources are released for other high-demand regions to use, realizing dynamic optimization and reallocation of resources.

[0061] During the iteration process, the system records the policy parameters, resource allocation values, and utility calculation results of all agents in each round in real time. It automatically eliminates invalid iteration strategies that exceed global resource constraints or do not improve returns, ensuring that each round of policy updates moves towards the direction of global utility optimization. When, after three consecutive rounds of iteration, the fluctuation range of the utility values ​​of all agents is less than the precision threshold of 0.001, or the number of iteration rounds reaches the maximum limit of 50 rounds, the multi-agent game strategy is considered to have converged, and the system enters a globally stable equilibrium state.

[0062] In a stable equilibrium state, the degree of model demand satisfaction, computing power consumption, and resource allocation ratio of all monitored areas in the entire domain reach a dynamic optimal balance, with no resource waste, no demand overload, and no space for individual optimization. At this point, the system extracts all agent policy data, resource allocation data, and global utility data after iterative convergence, and integrates them to generate a unique global Nash equilibrium solution. This equilibrium solution contains the optimal computing power quota and model scheduling adaptation scheme for each region in the entire domain, which is the core original basis for subsequently generating the scheduling priority sequence.

[0063] The model scheduling order and resource quota obtained from each region are extracted from the Nash equilibrium solution and mapped to a priority scheduling sequence, ultimately generating a multi-algorithm model scheduling priority sequence for each monitoring region.

[0064] The core of this step is to transform the abstract game equilibrium numerical results into concrete and executable model scheduling priority rules, quantify the scheduling priority authority of different regions, and form a standardized global scheduling sequence. This provides a precise sorting basis for the subsequent generation of conflict-free scheduling schedules. The specific implementation method is as follows: The Nash equilibrium solution stores the core data of the global optimal scheduling after the convergence of the multi-agent game. The core contains two key pieces of information: the dedicated computing power resource quota obtained by each monitoring region after the game and the model scheduling order weight. The resource quota is a specific quantitative value of the number of idle CPU cores, GPU memory capacity and available memory capacity precisely allocated by the edge nodes to the corresponding region, which directly determines the number and accuracy level of the schedulable algorithm models in that region. The scheduling order weight is directly mapped from the final utility value of each region in the equilibrium state. The higher the utility value, the greater the corresponding scheduling order weight, and the higher the model scheduling priority of the region.

[0065] The system first performs precise data analysis and extraction of the Nash equilibrium solution, matching the dedicated resource quota and scheduling weight data for each monitoring area one by one. Temporary redundant data and invalid data that has not converged during the iteration process are removed, retaining only the valid data under the final stable equilibrium state. For example, in a high-risk monitoring area in a commercial district, the final utility value after game convergence is 0.93, corresponding to a computing resource quota of 8 idle CPU cores, 4.2GB GPU memory, and 14.8GB RAM, with a scheduling order weight of 0.93. In a routine patrol monitoring area in the suburbs, the final utility value after game convergence is 0.46, corresponding to a computing resource quota of 3 idle CPU cores, 1.1GB GPU memory, and 7.6GB RAM, with a scheduling order weight of 0.46. The differentiated weight values ​​visually distinguish the scheduling priority differences between different areas.

[0066] After extracting the core data, the system uses scheduling order weights as the basis to globally sort all monitored areas from largest to smallest, initially forming a scheduling priority ranking framework. Simultaneously, it performs a secondary priority adjustment based on the real-time demand levels of the original algorithm models in each area. For high-risk security areas with demand levels of 8 to 10, a fixed adjustment coefficient of 0.05 is added to the original weights to further strengthen the scheduling priority of high-risk areas, ensuring priority scheduling and operation of algorithm models in sudden risk scenarios. For medium-demand areas with demand levels of 4 to 7, no coefficient adjustment is made, maintaining the original weight priority. For low-demand areas with demand levels of 1 to 3, the weight coefficient is reduced by 0.02 to prioritize the supply of computing resources to high-value security areas, achieving refined priority stratification.

[0067] After the correction is completed, the system will map the sorting position, corrected priority weight, adapted algorithm model type, and dedicated computing power resource quota of each monitoring area one by one to build an independent standardized scheduling unit. Each scheduling unit fully contains all the core scheduling parameters of a single area. All scheduling units are arranged in order of priority from high to low to form a complete scheduling sequence prototype.

[0068] Finally, the system performs a full-domain compliance check on the scheduling sequence. On one hand, it checks the total computing power resource quota of all regions to ensure that the total resource consumption does not exceed the total remaining computing power of the global edge nodes, preventing resource over-allocation. On the other hand, it checks the scheduling priority ranking logic to ensure that high-risk, high-demand areas are prioritized and low-risk, low-demand areas are prioritized, preventing priority inversion and resource misallocation. After the checks are fully passed, a multi-algorithm model scheduling priority sequence is generated, covering all monitored areas across the city, differentiating hierarchical priorities, and matching precise resource quotas. This sequence clearly defines the scheduling order and resource allocation standards for algorithm models in each region, providing a core ranking basis for subsequent conflict graph coloring and conflict-free parallel scheduling of multiple models.

[0069] S204. Based on the scheduling priority sequence of the multi-algorithm models and combined with the resource mutual exclusion constraints between each algorithm model, a conflict-free scheduling schedule for the parallel execution of multiple models is generated using a conflict graph coloring algorithm. Specifically, it can parse the scheduling priority sequence of multiple algorithm models, define each model instance to be scheduled as a task node, record its estimated execution time and required resource type, and generate a set of task nodes; The core of this step is to complete the parsing of scheduling priority data and the digital encapsulation of tasks, transforming the abstract model scheduling priority sequence into standardized, computable task node data units. This provides basic data support for subsequent conflict constraint identification, conflict graph construction, and time slot allocation, achieving a structured organization of security algorithm model scheduling tasks. The specific implementation method is as follows: The multi-algorithm model scheduling priority sequence is the core scheduling basis generated by the Nash equilibrium negotiation algorithm mentioned earlier. This sequence labels the scheduling priority weights of various security algorithm models corresponding to each monitoring area from high to low. The priority weight values ​​are set from 1 to 20. The larger the value, the higher the scheduling urgency and resource priority allocation authority of the corresponding model instance. Among them, weights of 16 to 20 are ultra-high priority, corresponding to the core identification models in high-risk security scenarios; weights of 8 to 15 are medium-high priority, corresponding to the monitoring models in conventional risk scenarios; and weights of 1 to 7 are low priority, corresponding to auxiliary security analysis models. During the parsing process, the system will traverse and identify all model instances in the sequence one by one, removing invalid model instances that have been scheduled and are in an idle standby state, and only retaining the valid model instances that need to be scheduled, deployed, and iteratively run at the current moment, ensuring that there is no redundant data interference in subsequent task processing.

[0070] After priority sequence parsing, each valid algorithm model instance to be scheduled is defined as an independent task node. Each task node, as the smallest scheduling unit, has a unique node identifier code. The encoding rule is a combination of region code, model type code, and timing code, which can accurately distinguish model instances from different regions, functions, and scheduling batches, avoiding task node confusion. For each newly created task node, the system synchronously collects and records two types of core parameters: estimated execution time and required resource type. These two types of parameters together define the operational characteristics and resource requirements of a single scheduled task.

[0071] Estimated execution time refers to the runtime of a single algorithm model instance under normal computing load on an edge node, completing the entire process of single video stream data analysis, feature extraction, and risk identification. The unit is milliseconds, and the value ranges from 200 to 5000 milliseconds. This parameter is generated by the system based on model computing complexity and historical running data fitting. The estimated execution time of high-precision human trajectory analysis models is generally between 1500 and 5000 milliseconds, while the estimated execution time of lightweight target detection models is generally between 200 and 1000 milliseconds. In the example, the estimated execution time of a high-precision model for crowd aggregation analysis in a high-risk monitoring area of ​​a certain urban area is 2800 milliseconds, and the estimated execution time of a lightweight model for non-motorized vehicle violation identification is 600 milliseconds. The parameter values ​​accurately reflect the differences in running time between different models.

[0072] The required resource types refer to the edge node hardware and data resources that the algorithm model must occupy to operate normally. These mainly include four core resource categories: GPU memory, CPU computing power, RAM, and front-end camera video data stream resources. The resource requirements vary significantly between different algorithm models. Large-scale, high-precision security algorithm models require GPU memory, CPU computing power, and RAM simultaneously. Small and medium-sized lightweight models primarily use CPU computing power and RAM. Video analysis models must be bound to the video data stream resources of the corresponding surveillance camera. In the example, the abnormal behavior recognition model requires GPU memory, CPU computing power, and surveillance video data stream resources, while the image quality enhancement model requires CPU computing power and RAM, with no exclusive data stream requirement.

[0073] After completing the node definition and parameter recording of all the model instances to be scheduled, the system will integrate all task nodes carrying complete identifiers, estimated execution times, and resource requirement types, sort them uniformly, and remove invalid nodes with missing parameters or abnormal data. Finally, a complete set of task nodes with unified parameters will be formed. This set covers all the core information of all the model tasks to be scheduled in the current urban security system, providing a complete task data source for subsequent resource conflict detection.

[0074] Identify resource mutual exclusion constraints between various algorithm models, including at least the GPU memory on the same edge node cannot be occupied by two large models at the same time, and the same camera data stream cannot be read by two models at the same time, and generate a set of conflict constraint rules. The core of this step is to uncover resource contention conflicts during the operation of different security algorithm models, clarify the mutual exclusion constraints between all models, standardize the definition of conflict judgment rules, and form a unified constraint rule system. This provides a basis for judgment in the subsequent construction of the conflict graph, thereby avoiding resource contention failures during parallel scheduling of multiple models from the root. The specific implementation method is as follows: Resource mutual exclusion constraints refer to the constraint relationship where two or more algorithm model instances cannot run synchronously on the same resource carrier at the same time due to the exclusive nature of the core hardware or data resources required for their operation. Resources in urban security edge scheduling scenarios all possess limited exclusive characteristics, and the resource capacity limit of a single resource carrier is fixed, making it impossible to support multiple high-demand models running simultaneously, thus leading to scheduling conflicts. The system, based on a set of task nodes, performs pairwise comparisons and verifications of the resource requirement parameters of any two different task nodes within the set, comprehensively identifying all potential resource mutual exclusion relationships. It corely covers two types of hard constraints while also being compatible with and extending to other secondary resource constraints.

[0075] The first type of core constraint is the mutual exclusion constraint of GPU memory resources on the same edge node. GPU memory is the core resource supporting the computation of high-precision and high-complexity security algorithm models. The total GPU memory capacity of a single edge node is fixed. Let's assume the total GPU memory capacity of a typical edge node is 8192MB. The threshold for judging large algorithm models is that a single run requires at least 2048MB of memory. When two or more large model instances are deployed simultaneously on the same edge node, the total memory usage will exceed the node's capacity limit, leading to problems such as model computation lag, decreased accuracy, and crashes. Therefore, the rule limits the GPU memory resources of the same edge node to only support the operation of one large model at a time. In the example, an edge node simultaneously connects a crowd situation analysis model and a boundary violation behavior accurate recognition model. Both models are large security models, occupying 3072MB and 2816MB of memory respectively. The combined memory requirements of the two exceed the node's capacity limit, resulting in a clear resource mutual exclusion conflict.

[0076] The second core constraint is the mutual exclusion constraint of the same camera data stream. The real-time video stream data output by the front-end monitoring camera is single-channel time-series data, and the data output is exclusive. It can only be read and parsed by one algorithm model at a time. If multiple models read the same data stream simultaneously, it will cause problems such as data frame corruption, parsing failure, and data loss. Therefore, the rule limits the real-time video data stream of a single camera to only one model instance to call and read at a time. In the example, the real-time data stream of a high-definition camera at an intersection cannot be simultaneously provided to the vehicle violation recognition model and the pedestrian trajectory tracking model for reading and running, because the two models have a mutual exclusion conflict of data stream resources.

[0077] In addition to the two core constraints, the system simultaneously identifies extended resource mutual exclusion constraints, including multi-task preemption constraints under full CPU load on the same edge node and memory resource overflow constraints, thus improving the conflict identification dimensions. All identified resource mutual exclusion relationships are defined as rules in a standardized format, clearly specifying the task node type, resource type, conflict judgment threshold, and conflict impact. After unified sorting and integration, duplicate and invalid constraint rules are eliminated, ultimately generating a comprehensive and standardized conflict constraint rule set. This rule set is the core judgment standard for subsequent conflict graph construction and conflict resolution, ensuring that all model scheduling conflicts can be accurately identified and handled.

[0078] A conflict graph is constructed based on a set of conflict constraint rules. Each node in the graph corresponds to a task node. If two task nodes have mutually exclusive resources, they are connected by an edge. A greedy coloring algorithm is used to assign colors to the conflict graph. Each color represents a time slot that can be executed in parallel, and a coloring scheme is generated. The core of this step is to transform abstract resource conflict constraints into visualized and computable graph structure data. A greedy coloring algorithm is then used to group conflicting tasks in a temporal sequence, enabling off-peak scheduling of conflicting tasks and parallel scheduling of conflict-free tasks. This involves quantifying and dividing time slots that can be executed in parallel, generating a scientific coloring scheduling scheme. The specific implementation is as follows: A conflict graph is an undirected topological graph used to represent the conflict relationships between model scheduling tasks. It consists of two parts: graph nodes and connecting edges. The core basis for constructing the conflict graph is the conflict constraint rule set generated earlier. Each graph node in the conflict graph corresponds one-to-one with a task node in the task node set, maintaining a completely equal mapping. Each graph node uniquely corresponds to a scheduled algorithm model instance task and inherits all parameters of the corresponding task node, such as estimated execution time, resource requirements, and scheduling priority. This ensures that the graph node data is completely consistent with the original scheduling task data, with no data deviation or information loss.

[0079] After initializing and constructing the graph nodes, edge connection operations are performed based on the conflict constraint rule set. Conflict determination is performed on the task nodes corresponding to any two graph nodes. If the two task nodes have any resource mutual exclusion constraint, an undirected connection edge is established between the two corresponding graph nodes in the conflict graph. This undirected edge only indicates that a scheduling conflict exists and does not distinguish between primary and secondary conflicts or unidirectional effects. If the two task nodes have no resource mutual exclusion relationship, no connection edge is established, indicating that the two tasks can run in parallel. By performing conflict verification and edge connection processing on all graph node combinations one by one, a complete conflict graph structure is finally constructed, clearly presenting the conflict relationships of all scheduled tasks.

[0080] The greedy coloring algorithm is the core algorithm for implementing temporal grouping of conflicting tasks. Its core logic involves assigning unique colors to nodes sequentially based on node priority. This ensures that conflicting nodes with connected edges are assigned different colors, while non-conflicting nodes without connected edges can share the same color. The algorithm follows a priority-first principle, assigning colors to graph nodes with higher scheduling priority weights first, maximizing the scheduling timeliness of high-risk security models. The number of color types corresponds to the number of time slots that can be scheduled in parallel. Each independent color uniquely corresponds to a time slot of fixed duration. The base duration of each time slot is uniformly set to 1000 milliseconds and can be adaptively fine-tuned based on the model's estimated execution time to adapt to the runtime requirements of different models.

[0081] During algorithm execution, all graph nodes are first sorted from highest to lowest scheduling priority. Then, each graph node is traversed sequentially, checking the assigned colors of all its adjacent nodes. Colors not used by conflicting nodes are selected for assignment, continuing until all graph nodes have been colored. In the example, three sets of conflicting model task nodes are assigned red, blue, and green colors respectively, corresponding to three independent time slots. Multiple low-priority model nodes without conflict are uniformly assigned yellow and execute in parallel using the same time slot. After all nodes are colored, the system integrates the color assignment results, corresponding time slot numbers, and parallel task lists to form a complete and standardized conflict graph coloring scheme. This scheme clarifies the parallel and off-peak scheduling rules for all model tasks, providing a core basis for subsequent scheduling timetable generation.

[0082] Task nodes are assigned to time slots according to the coloring scheme, and the execution order of tasks in the same time slot is adjusted according to the priority sequence, ultimately generating a conflict-free scheduling schedule for parallel execution of multiple models.

[0083] The core of this step is to use a coloring scheme to complete the timing allocation and order optimization of scheduling tasks. While ensuring parallel scheduling without resource conflicts, it optimizes the task execution order according to scheduling priority requirements, and finally generates a standardized, directly executable multi-model conflict-free scheduling timetable, completing conflict resolution and parallel scheduling planning. The specific implementation method is as follows: A time slot is the smallest sequential unit for parallel model execution. Independent time slots corresponding to different colors represent non-overlapping time intervals, eliminating any temporal overlap and completely avoiding resource scheduling conflicts between tasks across time slots at the temporal level. The system reads the color-time slot mapping relationship from the conflict graph coloring scheme, categorizes and matches all task nodes according to their corresponding colors, and assigns them one by one to their respective dedicated time slots. This completes the initial temporal allocation of all scheduled model tasks. All task nodes corresponding to the same color are included in the scheduling scope of the same time slot, enabling synchronous parallel execution. Task nodes corresponding to different colors are distributed across different time intervals, avoiding conflicts through staggered execution.

[0084] After initial time slot allocation, the execution order of multiple parallel task nodes within the same time slot is fine-tuned and optimized by combining the original multi-algorithm model scheduling priority sequence. Although tasks within the same time slot do not have resource mutual exclusion conflicts and can be computed in parallel, in order to ensure response efficiency in high-risk security scenarios, the internal execution order needs to be optimized according to priority weights. Task nodes with higher priority weights enjoy priority computing and data output rights within the same time slot, auxiliary model tasks with lower priority weights are executed later, and task nodes with the same weights maintain synchronous parallel execution without adjusting the order. In the example, the same time slot contains a 18-priority emergency event recognition model, a 12-priority crowd flow statistics model, and a 6-priority image denoising model. After adjustment, the emergency event recognition model becomes the primary output task, the crowd flow statistics model performs synchronous auxiliary computing, and the image denoising model is adapted in parallel in the background, balancing parallel efficiency and core business priority.

[0085] After completing task allocation and sequence optimization for all time slots, the system integrates all time-series scheduling information, including the start and end times of each time slot, the model type, execution priority, estimated runtime, resource type, and parallel task list of all task nodes within the slot. This information is then uniformly arranged in chronological order, eliminating redundant scheduling information and conflicting residual data to form a structured and standardized conflict-free scheduling schedule for multi-model parallel execution. This schedule completely resolves resource mutual exclusion conflicts between all algorithm models, maximizing the utilization of edge node computing resources for multi-model parallel scheduling. Simultaneously, it strictly adheres to scenario risk priority and scheduling strategy requirements, ensuring the scheduling timeliness and operational stability of high-priority security models. It can be directly used for the dynamic scheduling and execution of subsequent urban security multi-algorithm models.

[0086] S205, based on the conflict-free scheduling schedule, predict the demand change trend at a future preset time through a temporal convolutional network and construct a multi-algorithm model adaptation map. Based on the adaptation map, perform dynamic migration of model instances and hot switching of versions between edge computing nodes to complete the dynamic scheduling of multi-algorithm models in urban security scenarios.

[0087] Specifically, conflict-free scheduling schedules and historical demand level data can be input into a temporal convolutional network. This network extracts temporal dependencies through dilated causal convolution and outputs the predicted demand level of each monitoring area at a preset future time, generating a demand change trend sequence. The core of this step is to leverage the powerful temporal feature mining capabilities of temporal convolutional networks, combined with standardized scheduling time-series data and historical demand data, to deeply mine the temporal evolution patterns of algorithm model requirements in various regions under urban security scenarios, accurately predict changes in model demand levels in future periods, and generate continuous and quantifiable demand trend data. This provides accurate temporal data support for the subsequent construction of model adaptation maps. The specific implementation method is as follows: The conflict-free scheduling schedule is a standardized time-series execution file generated after multi-model conflict resolution and priority ranking. It fully records core information such as the parallel execution scheme, resource quota, task execution duration, and task priority ranking of each edge node within each time slot. It has strict time-series standardization and resource conflict-free characteristics, and can accurately represent the current running and scheduling status of all security algorithm models. Historical demand-level data is a time-series dataset continuously collected and retained by the system. It contains real-time demand-level information of algorithm models in continuous time periods in each monitoring area. The data sampling period is fixed at 1 second. A single set of data covers multi-dimensional features such as regional risk level, model type requirements, computing power adaptation requirements, and priority level. It typically retains nearly 300 seconds of continuous historical data, which can fully cover the dynamic changes in model requirements caused by short-term risk fluctuations and changes in pedestrian and vehicle traffic in urban security scenarios. Before inputting both types of data, they undergo time-series alignment preprocessing to unify the time dimension benchmark, eliminate deviations caused by sampling time differences and data delays, and ensure the time-series integrity and consistency of the input data.

[0088] Temporal convolutional networks are deep learning models adapted for time series prediction tasks, specifically designed to uncover implicit correlations in time series data. Compared to traditional recurrent time series models, this model effectively avoids the vanishing gradient problem in long sequences, possesses a longer temporal receptive field, and offers higher prediction accuracy, perfectly meeting the time series prediction needs of dynamic urban security scheduling. The core computational unit of this network is dilated causal convolution. The core characteristic of causal convolution is unidirectional temporal operation, using only current and past historical data for feature calculation, without introducing unknown future data, logically ensuring the rigor of time series prediction. Dilated convolution, by configuring the dilation coefficient, expands the network's temporal receptive field without increasing the number of convolution kernel parameters or computational power consumption, enabling the extraction of long-span temporal features while balancing prediction efficiency and accuracy.

[0089] In the specific operation, the temporal convolutional network has a preset kernel size of 3. The basic dilation coefficient is configured to increase layer by layer. The first layer dilation coefficient is set to 1, meaning that the current convolution operation only perceives temporal data within an adjacent 1 second. The second layer dilation coefficient is set to 2, meaning that it perceives temporal data with a 2-second interval. The third layer dilation coefficient is set to 4. After stacking multiple layers, a maximum temporal receptive field of 30 seconds can be achieved, which can fully capture the short-term and medium-term demand fluctuation characteristics of security scenarios. The future preset time is a custom prediction parameter, which is fixed at 20 seconds in this security scheduling scenario. This parameter represents the future time node that the network needs to predict. The parameter value can be fine-tuned according to the real-time requirements of security early warning. The smaller the value, the higher the prediction accuracy; the larger the value, the longer the predictable trend period.

[0090] After receiving the aligned, conflict-free scheduling time-series data and historical demand level dataset, the network extracts the temporal dependencies layer by layer through multi-layer dilated causal convolution. These dependencies include implicit temporal patterns such as the persistent characteristics of model demand in high-risk areas, the decaying characteristics of model demand in regular areas, the temporal fluctuation characteristics of edge node computing load, and the dynamic changes in model scheduling priorities. The extracted multi-dimensional temporal features undergo batch normalization to unify the data dimensions of each dimension, eliminating prediction biases caused by data differences. Then, a non-linear activation function is used for feature mapping and enhancement. Finally, a fully connected layer completes feature fitting, outputting the accurate predicted demand level for each independent monitoring area for the next 20 seconds. This result clearly indicates the core information such as the algorithm model type, accuracy level, and computing power matching specifications required for each area in the future. The predicted demand levels of all monitoring areas are integrated according to area number and temporal order to form a continuous and complete demand change trend sequence, intuitively presenting the dynamic evolution of the overall security model demand.

[0091] Based on the demand change trend sequence, a multi-algorithm model adaptation graph is constructed. The nodes in the graph represent the deployment relationship between model instances and edge computing nodes, and the edges represent migration costs and hot switching compatibility, generating an adaptation graph structure. The core of this step is to transform time-series demand trend data into structured topological graph data. This graph topology digitally represents the multi-dimensional relationships between edge nodes, model instances, migration costs, and version switching adaptability, enabling a visualized and quantified expression of model scheduling and adaptation relationships. This provides a standardized, structured data carrier for subsequent intelligent migration planning. The specific implementation method is as follows: The demand change trend sequence is the core prerequisite data for building the adaptive map. The sequence accurately records the dynamic changes in model demand, accuracy upgrades, computing power expansion, and priority adjustments for each monitoring area in the entire domain at a preset time in the future. It can accurately locate edge nodes that are about to be overloaded, idle nodes with idle computing power, model instances that need to be updated and iterated, and algorithm models that need to be newly deployed. It provides a comprehensive demand basis for map node construction and associated edge assignment, ensuring that the map construction is highly matched with the actual security scheduling needs.

[0092] The multi-algorithm model adaptation graph is a custom topology graph adapted for multi-model scheduling in urban security. It consists of two core units: node units and associated edge units. All units are configured with quantifiable feature parameters to achieve a precise digital description of deployment relationships and adaptation characteristics. Graph nodes are divided into two core types: edge computing nodes and algorithm model instance nodes. The binding relationship between these two types of nodes is the core infrastructure of the graph. Each algorithm model instance node uniquely corresponds to a real-time deployed edge computing node, accurately recording the current model's deployment location, running status, and computing power usage. It is also associated with the future predicted demand level of the corresponding monitoring area, marking the future demand adaptation coefficient of the model instance. The adaptation coefficient ranges from 0 to 1; the closer the coefficient is to 1, the higher the matching degree between the current model and the future regional demand, and vice versa.

[0093] The edges of the graph are topological connections linking different nodes. Each edge carries two core quantification parameters: migration cost parameter and hot-switching compatibility parameter. Both parameters range from 0 to 1, with higher values ​​indicating better adaptability and lower scheduling overhead. The migration cost parameter quantifies the overall cost of migrating a model instance from its current deployment edge node to a target edge node. It is calculated by comprehensively considering factors such as network transmission latency between nodes, model parameter size, node computing power scheduling overhead, and task interruption risk. In the example, the migration cost parameter between edge nodes within the same intranet region is 0.15, indicating extremely low resource consumption and extremely high task stability during the migration process. The migration cost parameter between nodes in a different extranet region is 0.65, indicating higher resource consumption and a slight scheduling delay.

[0094] The hot-switching compatibility parameter is used to quantify the adaptability of different versions and types of algorithm models to complete non-disruptive version switching at the target edge node. It is calculated by comprehensively considering dimensions such as the node system operating environment, model interface protocol compatibility, video data stream docking matching degree, and inference kernel adaptability. A parameter value of 1 indicates that completely uninterrupted hot-switching can be achieved, while a parameter value below 0.3 indicates that hot-switching cannot be completed and a system shutdown and restart are required to complete the version update. In the example, the hot-switching compatibility parameter between the high-precision model and the lightweight model with the same function is 0.92, indicating excellent adaptability. The hot-switching compatibility parameter for the cross-functional heterogeneous algorithm model is 0.21, indicating that direct hot-switching is not supported.

[0095] Based on the demand change trend sequence, all model instances that need to adjust their deployment location and update their model version are selected. Combined with the computing power idle status of the global edge nodes, the initial construction of the graph nodes is completed. Then, according to the transmission characteristics between nodes and the model adaptation characteristics, the parameter values ​​of all related edges are assigned. Finally, a multi-algorithm model adaptation graph structure with complete structure, accurate parameters, and clear associations is generated, which comprehensively covers the current deployment status of global models, future adaptation needs, and the loss and adaptation characteristics of cross-node scheduling.

[0096] Perform shortest path migration planning on the adaptation graph, select target migration nodes for model instances on nodes that are about to be overloaded, mark model instances that support version hot switching, and generate model migration and switching schemes. The core of this step is to use the quantized parameters of the adaptation graph as the calculation benchmark, solve the optimal model migration path through the shortest path planning algorithm, accurately match the optimal target deployment node, complete the model hot-switching attribute classification and labeling, and integrate to generate a scheduling and execution scheme that combines high efficiency and stability, thereby achieving dynamic and balanced allocation of edge computing resources. The specific implementation method is as follows: First, based on the computing power load prediction data of edge nodes in the adaptation graph, edge nodes that are about to be overloaded are identified. The system presets the node overload judgment threshold to 85%. This threshold refers to the combined computing power utilization rate of the edge node's CPU, GPU, and memory. When the predicted combined computing power utilization rate of the edge node exceeds 85% at a preset time in the future, the node is determined to be an overloaded node. The remaining computing power in the node cannot meet the future model operation requirements, which will lead to problems such as task backlog, increased inference latency, and decreased recognition accuracy. It is necessary to migrate some model instances to release computing power resources.

[0097] Shortest path migration planning is a process of finding the optimal path by weighting the migration costs of associated edges in the adaptation graph. The total weight of the migration path between any two nodes in the graph is the sum of the migration costs of all associated edges on the path. The path with the minimum total weight is the optimal migration path, and the corresponding target node is the optimal migration deployment node. During the planning calculation, not only the migration cost weight is considered, but also the target node's computing power adaptation deviation parameter is added simultaneously. The computing power adaptation deviation parameter ranges from 0 to 1. The smaller the value, the higher the match between the idle computing power of the target node and the computing power required by the model. Through dual-parameter weighted calculation, the problem of low migration cost but poor computing power adaptation is avoided, ensuring the stability of the model operation after migration.

[0098] For each overloaded node and its corresponding model instance to be migrated, all idle edge nodes with sufficient computing power in the adaptation graph are traversed. The comprehensive cost of each optional migration path is calculated one by one, and the target node corresponding to the minimum global cost is selected to complete the migration target location of the model instance. At the same time, based on the regional risk level priority, migration paths are planned first for model instances corresponding to high-risk monitoring areas to ensure the resource priority of core security monitoring tasks and avoid insufficient computing power in high-risk areas.

[0099] After completing the migration path planning, the hot-switching compatibility parameters of all model instances to be adjusted are traversed. The system presets the effective threshold for hot-switching to 0.6. Model instances with compatibility parameters greater than or equal to 0.6 are uniformly marked as hot-swappable models. These models can complete version iteration updates without stopping the system or interrupting the video analysis task. Model instances with compatibility parameters lower than 0.6 are marked as non-hot-swappable models. These models only support cross-node migration or version updates during downtime, and downtime update operations must be scheduled to be executed during low-load periods.

[0100] After completing the selection of optimal migration nodes, marking of model hot-switching attributes, and sorting of scheduling priorities, the core information such as the migration target location, migration execution sequence, version switching method, and task priority of all models is integrated. Combined with the time slot constraints of the conflict-free scheduling schedule, resource conflicts in parallel scheduling are avoided, and finally a standardized and implementable model migration and switching scheme is generated, clarifying the dynamic scheduling execution details of the entire model.

[0101] According to the plan, the dynamic migration of model instances and hot switching of versions between edge computing nodes are performed, the list of running model instances of each node is updated, and finally the dynamic scheduling of multi-algorithm models in urban security scenarios is completed.

[0102] The core of this step is to implement a standardized migration and switching solution. Through seamless migration and uninterrupted hot-switching, it achieves dynamic reconstruction of model resources, synchronously updates node operation logs, and forms a complete closed loop of time-series prediction, graph adaptation, planning and scheduling, and implementation. This adapts to the dynamically changing risks and computing power requirements of urban security scenarios. The specific implementation method is as follows: The dynamic migration of model instances strictly follows the time slot sequence of the preset plan and conflict-free scheduling schedule, and is carried out in a step-by-step manner according to the principle of prioritizing high-risk areas and high-priority tasks. The migration process adopts a seamless migration mode with synchronous preheating of two nodes. First, the corresponding model instance is initialized and deployed on the target edge node, and the core data such as model weight parameters, video stream interface, task inference configuration, and early warning threshold parameters of the original node are synchronously replicated. After the model instance on the target node has completed preheating and reached a normal operating state, the video analysis tasks of the original node are gradually diverted. After the tasks have completely and smoothly transitioned, the model instance on the original node is shut down. The entire process achieves no task interruption and no data loss, avoiding blank periods in security monitoring.

[0103] The hot-swapping operation is performed on all marked hot-swapping model instances. It leverages the model's built-in compatible switching interface to achieve non-stop version iteration, maintaining a continuous input path for front-end video stream data during the switching process. Only the model's internal inference calculation kernel and parameter weights are replaced, without requiring program restarts or task interruptions. The entire hot-swapping process takes less than 200ms, with extremely low latency, ensuring no impact on the response efficiency of real-time security monitoring. It can quickly switch between lightweight and high-precision models, and between general recognition models and specific risk recognition models, based on changes in regional risk, accurately adapting to the monitoring needs of different scenarios. For model instances that cannot be hot-swapped, a unified downtime version update is completed within a low-load time slot, minimizing the impact on security operations.

[0104] After all migration and switching operations are completed, the system automatically traverses the real-time running status of all edge computing nodes, and counts the core information of each node, such as the number of algorithm model instances currently deployed, model type, version specification, running status, computing power utilization ratio, and monitoring area of ​​the corresponding service. The system comprehensively updates the list of running model instances of each edge node to ensure that the information recorded in the list is completely consistent with the actual running status of the nodes, eliminates data lag and information deviation, and provides accurate basic data support for the next round of feature collection, demand calculation, and scheduling planning.

[0105] Through the entire process of time-series demand prediction, model graph construction, optimal path planning, dynamic migration and hot switching, the system completely solves the problems of wasted computing resources, uneven resource allocation in high and low risk areas, lagging model adaptation, and untimely monitoring and response in the traditional fixed model deployment mode. It can adapt to changes in pedestrian flow, risk fluctuations, and dynamic changes in node computing power in urban security scenarios in real time, continuously optimize the deployment layout and operation status of multi-algorithm models across the entire domain, and ultimately efficiently complete the dynamic scheduling of multi-algorithm models in complex urban security scenarios.

[0106] Another embodiment of the present invention provides a dynamic scheduling system for multi-algorithm models for urban security, see [link to relevant documentation]. Figure 3 The system may include: The acquisition module 301 is used to acquire video stream data, edge node computing load information and security warning level of each monitoring area in real time in urban security monitoring scenarios, and extract the spatiotemporal dynamic features, regional risk level features and node computing response features of the monitoring scenario. The generation module 302 is used to generate the real-time demand level of the algorithm model for each monitoring area based on the spatiotemporal dynamic characteristics, regional risk level characteristics and node calculation response characteristics, combined with a preset scheduling strategy that prioritizes identification accuracy or real-time response. The negotiation module 303 is used to generate a multi-algorithm model scheduling priority sequence for each monitoring area based on the real-time demand level of the algorithm model and the remaining computing power distribution of the edge nodes using the Nash equilibrium negotiation algorithm. The scheduling module 304 is used to generate a conflict-free scheduling schedule for the parallel execution of multiple models by using a conflict graph coloring algorithm, based on the scheduling priority sequence of the multiple algorithm models and the resource mutual exclusion constraints between the algorithm models. The execution module 305 is used to predict the demand change trend at a preset time in the future and construct a multi-algorithm model adaptation map based on the conflict-free scheduling schedule through a temporal convolutional network. Based on the adaptation map, it performs dynamic migration of model instances and hot switching of versions between edge computing nodes to complete the dynamic scheduling of multi-algorithm models in urban security scenarios.

[0107] This invention also provides a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0108] This invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0109] Specifically, the aforementioned electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the aforementioned processor, and the input / output device is connected to the aforementioned processor.

[0110] The above description, based on the embodiments shown in the figures, details the structure, features, and effects of the present invention. The above description is only a preferred embodiment of the present invention, but the present invention is not limited to the scope of implementation shown in the figures. Any changes made in accordance with the concept of the present invention, or equivalent embodiments modified to have equivalent changes, that do not exceed the spirit covered by the specification and figures, should be within the protection scope of the present invention.

Claims

1. A dynamic scheduling method for multiple algorithm models in urban security, characterized in that, The method includes: It collects video stream data, edge node computing load information, and security warning levels of each monitoring area in real time in urban security monitoring scenarios, and extracts the spatiotemporal dynamic features, regional risk level features, and node computing response features of the monitoring scenarios. Based on the aforementioned spatiotemporal dynamic characteristics, regional risk level characteristics, and node computation response characteristics, and combined with a preset scheduling strategy prioritizing identification accuracy or real-time response, the real-time demand level of the algorithm model for each monitoring area is generated. Based on the real-time demand level of the algorithm model and the remaining computing power distribution of edge nodes, the Nash equilibrium negotiation algorithm is used to generate a multi-algorithm model scheduling priority sequence for each monitoring area. Based on the scheduling priority sequence of the multi-algorithm models and combined with the resource mutual exclusion constraints between the algorithm models, a conflict-free scheduling schedule for the parallel execution of the multi-model model is generated using a conflict graph coloring algorithm. Based on the conflict-free scheduling schedule, the demand change trend at a preset time is predicted by a temporal convolutional network and a multi-algorithm model adaptation map is constructed. Based on the adaptation map, dynamic migration of model instances and hot switching of versions between edge computing nodes are performed to complete the dynamic scheduling of multi-algorithm models in urban security scenarios.

2. The method according to claim 1, characterized in that, The system collects video stream data, edge node computing load information, and security warning levels for each monitored area in real-time urban security monitoring scenarios, and extracts spatiotemporal dynamic features, regional risk level features, and node computing response features of the monitoring scenarios, including: Video stream data of each monitored area is collected from the front-end camera, and load information including at least CPU utilization, memory usage and network bandwidth is obtained from the edge computing node. Real-time security warning levels of each area are synchronized from the security platform to generate a multi-source real-time data set. Spatiotemporal slicing is performed on video stream data in multi-source real-time datasets to extract motion vector density, target dwell time and crowd gathering degree of each monitored area within a preset time window, generating spatiotemporal dynamic feature vectors. Based on spatiotemporal dynamic feature vectors and combined with the real-time safety warning levels of each region, regional risk heat values ​​are calculated by weighted fusion to identify high-risk periods and high-risk location attributes, and to generate a set of regional risk level feature descriptions. The load information of each edge node is normalized and trend analyzed to extract node response latency, task backlog, and available computing power ratio, and to generate node computing response feature vectors.

3. The method according to claim 2, characterized in that, The process involves generating real-time demand levels for algorithm models in each monitoring area based on the spatiotemporal dynamic characteristics, regional risk level characteristics, and node response characteristics, combined with a preset scheduling strategy prioritizing either identification accuracy or real-time response. This includes: The spatiotemporal dynamic feature vectors are merged with the regional risk level feature description set to construct the state feature matrix of each monitoring area, which is used to characterize the complexity and priority of the current scenario. Read the preset scheduling strategy parameters. If it is a recognition accuracy priority strategy, assign a higher basic requirement score to the high-precision model. If it is a real-time response priority strategy, assign a higher basic requirement score to the lightweight model and generate a strategy correction coefficient. Multiply the state feature matrix with the policy correction coefficient, and then dynamically weight it by combining the proportion of available computing power in the node's response feature vector. Calculate the real-time demand score for each region for various algorithm models, and generate a region-model demand score matrix. The region-model requirement score matrix is ​​sorted and thresholded to determine the required model type and performance level for each monitoring region at the current moment, ultimately generating the real-time requirement level of the algorithm model for each monitoring region.

4. The method according to claim 3, characterized in that, Based on the real-time demand level and the remaining computing power distribution of edge nodes in the algorithm model, the Nash equilibrium negotiation algorithm is used to generate a multi-algorithm model scheduling priority sequence for each monitoring area, including: The algorithm model of each monitoring area is analyzed to determine the real-time demand level. Each area is regarded as an intelligent agent participating in the game, and its utility function is defined as the ratio of the degree of demand satisfaction to the resource consumption, thus generating a set of utility functions of the game participants. Obtain the remaining computing power distribution data of each edge node, including the number of idle CPU cores, GPU memory availability, and memory availability of each node, and construct a global resource constraint vector; A distributed Nash equilibrium negotiation algorithm is adopted. Each agent in each region performs multiple rounds of policy updates based on the set of utility functions and the global resource constraint vector, gradually converging to a stable state where the utility of each party cannot be improved individually, thus generating a Nash equilibrium solution. The model scheduling order and resource quota obtained from each region are extracted from the Nash equilibrium solution and mapped to a priority scheduling sequence, ultimately generating a multi-algorithm model scheduling priority sequence for each monitoring region.

5. The method according to claim 4, characterized in that, The step of generating a conflict-free scheduling schedule for the parallel execution of multiple models based on the scheduling priority sequence of the multi-algorithm models, combined with the resource mutual exclusion constraints between the algorithm models, and using a conflict graph coloring algorithm includes: The scheduling priority sequence of multiple algorithm models is analyzed, each model instance to be scheduled is defined as a task node, and its estimated execution time and required resource type are recorded to generate a set of task nodes; Identify resource mutual exclusion constraints between various algorithm models, including at least the GPU memory on the same edge node cannot be occupied by two large models at the same time, and the same camera data stream cannot be read by two models at the same time, and generate a set of conflict constraint rules. A conflict graph is constructed based on a set of conflict constraint rules. Each node in the graph corresponds to a task node. If two task nodes have mutually exclusive resources, they are connected by an edge. A greedy coloring algorithm is used to assign colors to the conflict graph. Each color represents a time slot that can be executed in parallel, and a coloring scheme is generated. Task nodes are assigned to time slots according to the coloring scheme, and the execution order of tasks in the same time slot is adjusted according to the priority sequence, ultimately generating a conflict-free scheduling schedule for parallel execution of multiple models.

6. The method according to claim 5, characterized in that, The process involves predicting future demand trends at predetermined times using a temporal convolutional network based on the conflict-free scheduling schedule, constructing a multi-algorithm model adaptation graph, and performing dynamic migration and version hot-switching of model instances between edge computing nodes based on this adaptation graph to complete the dynamic scheduling of multi-algorithm models in urban security scenarios. This includes: The conflict-free scheduling schedule and historical demand level data are input into the temporal convolutional network. The network extracts the temporal dependencies through dilated causal convolution and outputs the predicted demand level of each monitoring area at a preset future time, generating a demand change trend sequence. Based on the demand change trend sequence, a multi-algorithm model adaptation graph is constructed. The nodes in the graph represent the deployment relationship between model instances and edge computing nodes, and the edges represent migration costs and hot switching compatibility, generating an adaptation graph structure. Perform shortest path migration planning on the adaptation graph, select target migration nodes for model instances on nodes that are about to be overloaded, mark model instances that support version hot switching, and generate model migration and switching schemes. According to the plan, the dynamic migration of model instances and hot switching of versions between edge computing nodes are performed, the list of running model instances of each node is updated, and finally the dynamic scheduling of multi-algorithm models in urban security scenarios is completed.

7. A dynamic scheduling system for multi-algorithm models in urban security, characterized in that, The system includes: The acquisition module is used to collect video stream data, edge node computing load information, and security warning levels of each monitoring area in real time in urban security monitoring scenarios, and to extract the spatiotemporal dynamic features, regional risk level features, and node computing response features of the monitoring scenario. The generation module is used to generate the real-time demand level of the algorithm model for each monitoring area based on the spatiotemporal dynamic characteristics, regional risk level characteristics and node calculation response characteristics, combined with a preset scheduling strategy that prioritizes identification accuracy or real-time response. The negotiation module is used to generate a multi-algorithm model scheduling priority sequence for each monitoring area based on the real-time demand level of the algorithm model and the remaining computing power distribution of the edge nodes using the Nash equilibrium negotiation algorithm. The scheduling module is used to generate a conflict-free scheduling schedule for the parallel execution of multiple models by combining the priority sequence of the multi-algorithm models with the resource mutual exclusion constraints between the algorithm models and using the conflict graph coloring algorithm. The execution module is used to predict the demand change trend at a preset time in the future and construct a multi-algorithm model adaptation map based on the conflict-free scheduling schedule and the temporal convolutional network. Based on the adaptation map, it performs dynamic migration of model instances and hot switching of versions between edge computing nodes to complete the dynamic scheduling of multi-algorithm models in urban security scenarios.

8. The system according to claim 7, characterized in that, The acquisition module is specifically used for: Video stream data of each monitored area is collected from the front-end camera, and load information including at least CPU utilization, memory usage and network bandwidth is obtained from the edge computing node. Real-time security warning levels of each area are synchronized from the security platform to generate a multi-source real-time data set. Spatiotemporal slicing is performed on video stream data in multi-source real-time datasets to extract motion vector density, target dwell time and crowd gathering degree of each monitored area within a preset time window, generating spatiotemporal dynamic feature vectors. Based on spatiotemporal dynamic feature vectors and combined with the real-time safety warning levels of each region, regional risk heat values ​​are calculated by weighted fusion to identify high-risk periods and high-risk location attributes, and to generate a set of regional risk level feature descriptions. The load information of each edge node is normalized and trend analyzed to extract node response latency, task backlog, and available computing power ratio, and to generate node computing response feature vectors.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method of any one of claims 1-6 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method of any one of claims 1-6.

Images