Cloud-based duty management service method and system based on dynamic order dispatch

Abstract

The application discloses a cloud value guard service method and system based on dynamic order distribution, and relates to the technical field of big data processing. In the method, the number of online personnel, the number of monitoring points and historical emergency distribution data in a cloud value guard platform are acquired to determine a resource supply and demand fluctuation benchmark value; the benchmark value is used to acquire an emergency degree parameter of a to-be-processed task, and then a task complexity evaluation result is determined; if the evaluation result exceeds a preset threshold value, an adjusted task priority ranking is obtained through similarity analysis; path planning is performed based on the ranking to determine a cloud value guard order distribution scheme; deviation analysis and feedback correction are performed on the distribution scheme to obtain a target service pricing result; and finally, a response efficiency optimization path is determined and order distribution is performed according to the pricing result and the order distribution scheme. Through the big data analysis and processing process, the efficiency of the cloud value guard order distribution technology in a complex operation scenario can be improved by implementing the technical scheme provided by the application.

Description

Technical Field

[0001] This invention belongs to the field of big data processing technology, specifically a cloud-based duty service method and system based on dynamic dispatching. Background Technology

[0002] With the deepening of smart city construction and the widespread application of IoT technology, the demand for remote monitoring services in areas such as urban security, facility monitoring, and emergency response is increasing daily. Cloud-based monitoring services, as a new remote monitoring and management model based on big data processing, connect dispersed monitoring points with monitoring personnel through a centralized cloud platform, enabling unified supervision and rapid response across multiple areas and scenarios. To meet the needs of different monitoring scenarios, task types, and responses to various emergencies, cloud-based dispatching technology is showing a trend towards intelligent development. Its response efficiency and service quality in dynamic resource allocation environments are crucial for ensuring platform operational effectiveness and user satisfaction.

[0003] Currently, the dispatching methods in cloud-based monitoring services mainly employ manual scheduling or polling allocation techniques. The work arrangements for monitoring personnel are determined by dispatchers based on experience or by the system sequentially assigning tasks according to preset rules. This rule-based dispatching method matches pending tasks with preset allocation strategies to achieve task distribution, fulfilling basic task dispatching functions and finding widespread application in the field of cloud-based monitoring platform operation and management.

[0004] However, due to the complexity of the operating environment and the dynamic changes in resource supply and demand, cloud-based task dispatching scenarios are becoming increasingly complex and volatile. In practical applications, task dispatching methods based on fixed strategies struggle to account for the impact of dynamic fluctuations in multiple factors on task dispatching decisions, and the accuracy of task priority determination is difficult to guarantee. Especially when the platform's resource supply and demand changes over time, the task processing pressure faced by the system includes dynamically changing load characteristics. Existing methods, which use simple fixed task dispatching rules for allocation, are prone to causing delays in task response or even resource imbalances, thereby reducing the efficiency of cloud-based task dispatching technology in complex operating scenarios. Summary of the Invention

[0005] To address the above problems, this invention provides a cloud-based duty service method and system based on dynamic order dispatching, which solves the problem of low order dispatching efficiency of existing cloud-based duty dispatching methods in environments with dynamic changes in resource supply and demand, and can improve the efficiency of cloud-based duty dispatching technology in complex operational scenarios.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: Obtain data on the number of online personnel, the number of monitoring points, and the distribution of historical emergencies from the cloud monitoring platform; Based on the number of online personnel, the number of monitoring points, and the historical distribution data of emergencies, a baseline value for resource supply and demand fluctuations is determined. By using the resource supply and demand fluctuation benchmark value, the urgency parameter of the task to be processed is obtained, and the task complexity assessment result is determined by combining the urgency parameter. If the task complexity assessment result exceeds a preset threshold, then a similarity analysis is performed based on the task complexity assessment result to obtain an adjusted task priority ranking. Based on the adjusted task priority ranking, path planning is performed to determine the cloud-based duty dispatching scheme. A deviation analysis is performed on the cloud-based duty dispatching scheme to obtain a preliminary task pricing value. When the preliminary task pricing value exceeds a preset deviation, feedback correction is performed to obtain the target service pricing result. Based on the target service pricing result and the cloud-based duty dispatching scheme, determine the response efficiency optimization path for the cloud-based duty service, and execute the dispatching according to the response efficiency optimization path.

[0007] By adopting the above technical solution, and acquiring data on the number of online personnel, the number of monitoring points, and the distribution of historical emergencies in the cloud-based monitoring platform, and determining a baseline value for resource supply and demand fluctuations based on this data, the dispatch system can perceive the dynamic changes in the platform's resource supply and demand in real time. This provides a quantitative basis for subsequent task processing, reflecting the current system load status. Based on this, the urgency parameter of the tasks to be processed is obtained through the resource supply and demand fluctuation baseline value, and the task complexity assessment result is determined. This achieves linkage between task assessment and system resource status, allowing the same task to obtain differentiated urgency judgments under different resource supply and demand environments, avoiding the shortcomings of fixed-strategy dispatch methods that cannot adapt to dynamic fluctuations in resource supply and demand. When the task complexity assessment result exceeds a preset threshold, similarity analysis is performed based on the task complexity assessment result to obtain an adjusted task priority ranking. By mining the processing experience of similar historical tasks, intelligent optimization of task priorities is achieved, further improving the accuracy of task priority determination. Based on the adjusted task priority ranking, path planning is performed to determine the cloud-based monitoring dispatch allocation scheme, enabling dispatch decisions to comprehensively consider the importance of tasks and the rationality of the processing order, thereby reducing task response delays and resource allocation imbalances. By performing deviation analysis on the cloud-based duty dispatching scheme to obtain preliminary task pricing values, and then correcting these values ​​when they exceed a preset deviation to arrive at the target service pricing result, a correlation mechanism and adaptive correction mechanism between the dispatching scheme and the pricing result are established to ensure the rationality of service pricing. Finally, based on the target service pricing result and the cloud-based duty dispatching scheme, the response efficiency optimization path for the cloud-based duty service is determined and dispatching is executed. This achieves complete closed-loop management from resource awareness to task evaluation, priority adjustment, dispatching, pricing correction, and execution optimization, solving the problem of low dispatching efficiency in existing cloud-based duty dispatching methods under dynamically changing resource supply and demand environments, and improving the efficiency of cloud-based duty dispatching technology in complex operational scenarios.

[0008] Optionally, a point dispersion density index is calculated based on the number of monitoring points and the coverage data of the monitoring points in the cloud monitoring platform; an event density coefficient is calculated based on the historical distribution data of emergencies; the number of online personnel is compared with the average number of online personnel in the same historical period to obtain the personnel supply offset; and the resource supply and demand fluctuation benchmark value is determined based on the personnel supply offset, the point dispersion density index, and the event density coefficient.

[0009] Optionally, obtain the total number of all registered monitoring points and extract the total geographical area covered by all monitoring points from the coverage data; calculate the ratio of the number of monitoring points to the total geographical area; use the ratio as the point dispersion density index, which is used to characterize the number of monitoring points per unit geographical area.

[0010] Optionally, the following steps are taken: First, a task to be processed is acquired. Then, a response time threshold is determined based on the resource supply and demand fluctuation benchmark value. The initial alarm level of the task to be processed is then corrected according to the response time threshold to obtain the urgency parameter. Next, the features of the on-site monitoring screen corresponding to the task to be processed are analyzed, and the number of video verification points and the historical false alarm rate of the associated defense zone are extracted. Finally, a video verification difficulty coefficient is calculated based on the number of video verification points and the historical false alarm rate. The video verification difficulty coefficient and the urgency parameter are then weighted and fused together to output the task complexity assessment result.

[0011] Optionally, if the task complexity assessment result exceeds the preset threshold, then historical task records matching the task complexity assessment result are retrieved from the historical task database to form a set of similar historical tasks; a task execution risk index is calculated based on the set of similar historical tasks; and each of the tasks to be processed is sorted according to the task execution risk index to obtain the adjusted task priority ranking.

[0012] Optionally, based on the adjusted task priority sorting, obtain the current geographical coordinates and current task load rate of all online monitoring personnel; calculate the spatial distance cost between the online monitoring personnel and the task location based on the current geographical coordinates; perform a weighted calculation of the spatial distance cost and the current task load rate to obtain the comprehensive scheduling cost value for each task corresponding to each online monitoring personnel; extract the lowest value among the comprehensive scheduling costs corresponding to each task, and determine the online monitoring personnel corresponding to the lowest value as the target executor; write the identity data of the target executor into the scheduling instruction set of the corresponding task, and summarize to generate the cloud monitoring dispatch allocation scheme.

[0013] Optionally, the historical average completion time and historical benchmark price of similar tasks are extracted according to the cloud-based dispatching scheme; the time deviation rate between the estimated completion time of the current dispatch and the historical average completion time is calculated; the estimated completion time is corrected based on the time deviation rate, and the preliminary task pricing value is calculated in combination with the historical benchmark price.

[0014] Optionally, the task type identifier is extracted from the cloud-based dispatching scheme, and the corresponding historical pricing range is queried in the historical pricing database according to the task type identifier; the deviation between the initial task pricing value and the boundary value of the historical pricing range is calculated; the corresponding pricing correction coefficient is obtained from a preset correction coefficient mapping table according to the deviation; and the pricing correction coefficient is multiplied by the initial task pricing value to obtain the target service pricing result.

[0015] Optionally, the following steps are taken: obtaining the service level timeliness requirement corresponding to the target service pricing result; obtaining the terminal network bandwidth status and current task queuing sequence of the target personnel according to the cloud-based duty dispatching scheme; matching the corresponding video stream transmission node and bandwidth allocation strategy for the task to be processed in the cloud-based duty platform based on the service level timeliness requirement and the terminal network bandwidth status; combining the video stream transmission node, the bandwidth allocation strategy and the current task queuing sequence to generate the response efficiency optimization path; and pushing the on-site monitoring video stream of the task to be processed to the cloud-based duty terminal of the target personnel according to the response efficiency optimization path.

[0016] Secondly, embodiments of this application provide a cloud-based duty service system based on dynamic order dispatch. The cloud-based duty service system based on dynamic order dispatch includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the cloud-based duty service system based on dynamic order dispatch to perform the method described in the first aspect and any possible implementation thereof.

[0017] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages: By adopting the above technical solution, and acquiring data on the number of online personnel, the number of monitoring points, and the distribution of historical emergencies in the cloud-based monitoring platform, and determining a baseline value for resource supply and demand fluctuations based on this data, the dispatch system can perceive the dynamic changes in the platform's resource supply and demand in real time. This provides a quantitative basis for subsequent task processing, reflecting the current system load status. Based on this, the urgency parameter of the tasks to be processed is obtained through the resource supply and demand fluctuation baseline value, and the task complexity assessment result is determined. This achieves linkage between task assessment and system resource status, allowing the same task to obtain differentiated urgency judgments under different resource supply and demand environments, avoiding the shortcomings of fixed-strategy dispatch methods that cannot adapt to dynamic fluctuations in resource supply and demand. When the task complexity assessment result exceeds a preset threshold, similarity analysis is performed based on the task complexity assessment result to obtain an adjusted task priority ranking. By mining the processing experience of similar historical tasks, intelligent optimization of task priorities is achieved, further improving the accuracy of task priority determination. Based on the adjusted task priority ranking, path planning is performed to determine the cloud-based monitoring dispatch allocation scheme, enabling dispatch decisions to comprehensively consider the importance of tasks and the rationality of the processing order, thereby reducing task response delays and resource allocation imbalances. By performing deviation analysis on the cloud-based duty dispatching scheme to obtain preliminary task pricing values, and then correcting these values ​​when they exceed a preset deviation to arrive at the target service pricing result, a correlation mechanism and adaptive correction mechanism between the dispatching scheme and the pricing result are established to ensure the rationality of service pricing. Finally, based on the target service pricing result and the cloud-based duty dispatching scheme, the response efficiency optimization path for the cloud-based duty service is determined and dispatching is executed. This achieves complete closed-loop management from resource awareness to task evaluation, priority adjustment, dispatching, pricing correction, and execution optimization, solving the problem of low dispatching efficiency in existing cloud-based duty dispatching methods under dynamically changing resource supply and demand environments, and improving the efficiency of cloud-based duty dispatching technology in complex operational scenarios. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a cloud-based duty service method based on dynamic order dispatch disclosed in an embodiment of this application. Figure 2 This is another flowchart illustrating a cloud-based duty service method based on dynamic order dispatch disclosed in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a system provided in an embodiment of this application.

[0019] In the diagram: 301, Central Processing Unit; 302, Read-Only Memory; 303, Random Access Memory; 304, Bus; 305, Input / Output Interface; 306, Input Section; 307, Output Section; 308, Storage Section; 309, Communication Section; 310, Driver; 311, Removable Media. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solution, the present invention will be described in detail below with reference to embodiments. The description in this part is only exemplary and explanatory, and should not be used to limit the scope of protection of the present invention in any way.

[0021] It should be noted that, in this document, the terms "comprising," "including," and any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Specific examples have been used in this document to illustrate the principles and implementation methods of the present invention. These examples are merely for the purpose of helping to understand the method and core ideas of the present invention. The above are only preferred embodiments of the present invention. It should be pointed out that, due to the limitations of written expression and the objective existence of infinite specific structures, those skilled in the art can make several improvements, modifications, or variations without departing from the principles of the present invention, and can also combine the above technical features in an appropriate manner. These improvements, modifications, variations, or combinations, or the direct application of the concept and technical solution of the present invention to other situations without modification, should all be considered within the scope of protection of the present invention.

[0022] This application provides a cloud-based duty service method based on dynamic order dispatching, referring to... Figure 1 , Figure 1 This is a flowchart illustrating a cloud-based duty-attending service method based on dynamic order dispatch, provided in an embodiment of this application. The method is applied to a system, which refers to a hardware and software integrated platform capable of executing a cloud-based duty-attending service program based on dynamic order dispatch. The system can execute a cloud-based duty-attending service program based on dynamic order dispatch. The method includes steps 101 to 106, as follows: Step 101: Obtain the number of online personnel, the number of monitoring points, and the distribution data of historical emergencies from the cloud monitoring platform.

[0023] In this embodiment, the cloud-based monitoring platform refers to a remote monitoring and management system built on cloud computing technology, used to connect dispersed monitoring points and monitoring personnel to achieve centralized remote monitoring and rapid response services. A cloud-based monitoring platform typically includes components such as a cloud data center, monitoring front-end equipment, and mobile terminal applications, and can be exemplified by security monitoring cloud platforms or smart city integrated management platforms.

[0024] Specifically, obtaining data on the number of online personnel, monitoring points, and historical event distribution from the cloud monitoring platform includes the following operations: First, the total number of logged-in and active monitoring personnel accounts at the current time is read through the platform's user management system interface and recorded as the number of online personnel. Second, the platform's monitoring point database is queried to extract the number of all connected and operating monitoring devices, recorded as the number of monitoring points. Finally, all recorded events within a specific number of days (e.g., 30 days) are extracted from the platform's event log database, including the time of occurrence, location coordinates, event type, and processing status of each event, forming a historical event distribution dataset. This data will be used for subsequent resource supply and demand assessments and task scheduling calculations.

[0025] Step 102: Determine the baseline value for resource supply and demand fluctuations based on the number of online personnel, the number of monitoring points, and historical data on the distribution of emergencies.

[0026] In this embodiment, the resource supply and demand fluctuation benchmark value represents the dynamic balance between the supply of human resources and the demand for monitoring services in the cloud-based monitoring platform, and is a core indicator for measuring the current operational pressure of the platform. This benchmark value comprehensively considers three dimensions: personnel supply, location distribution, and event frequency, and is used for subsequent task urgency assessment and dispatching decisions. The value range is typically between 0 and 1, with a larger value indicating greater resource supply and demand pressure.

[0027] Specifically, the calculation process for determining the baseline value of resource supply and demand fluctuations is as follows: First, based on the number of monitoring points and their coverage data, the point dispersion density index is calculated. By extracting the geographic coordinate information of all monitoring points, the total geographic area covered by these points is determined. Then, the ratio of the number of points to the total geographic area is calculated to obtain the point dispersion density index, which represents the number of monitoring points per unit geographic area. Second, based on historical data on the distribution of emergencies, the event density coefficient is calculated. All emergencies recorded within a specific number of days in the past are clustered according to time and geographic location to obtain the average frequency of events in each time period and region. This frequency is compared with the historical average for the same period to obtain the event density coefficient. Then, the current number of online personnel is compared with the average number of online personnel in the same historical time period (such as weekday mornings, weekend evenings, etc.). The proportion of the difference between the current number of personnel and the historical average to the historical average is calculated to obtain the personnel supply offset. Finally, the three indicators are weighted and integrated. The benchmark value of resource supply and demand fluctuation is calculated by summing the product of the first weight and the point dispersion density index, the product of the second weight and the event density coefficient, and the product of the third weight and the personnel supply offset. The sum of each weight coefficient is equal to 1.

[0028] Step 103: Obtain the urgency parameter of the task to be processed by the baseline value of resource supply and demand fluctuation, and determine the task complexity assessment result by combining the urgency parameter.

[0029] In this embodiment, the urgency parameter is a quantitative representation of the response time requirement for a task, reflecting the time sensitivity and priority of task processing. It is typically represented by a value from 0 to 10, with a higher value indicating a more urgent task. The urgency parameter takes into account factors such as the initial alarm level and resource supply and demand, and is used to guide subsequent task allocation and processing procedures. For example, the urgency parameter for a fire alarm might be 9.5, while the urgency parameter for an offline alarm from a regular device might be 3.2.

[0030] Specifically, the process of obtaining the urgency parameters of pending tasks and determining the task complexity assessment results includes: First, retrieving pending tasks from the task queue of the cloud monitoring platform, including information such as task identifier, task type, alarm source, and initial alarm level. Second, determining the response time threshold based on the resource supply and demand fluctuation baseline value calculated in the previous step. The calculation method is to multiply the basic response time by an adjustment factor, which is jointly determined by the resource supply and demand fluctuation baseline value and an adjustment coefficient. Then, correcting the initial alarm level of the pending task based on the calculated response time threshold, obtaining the urgency parameter by multiplying the initial alarm level by a correction factor, which is related to the ratio of the response time threshold to the basic response time. Next, analyzing the on-site monitoring screen features corresponding to the pending task through the video analysis system, extracting the number of video points requiring review and the historical false alarm rate of the defense zone where these points are located. Based on the extracted information, calculating the video review difficulty coefficient, which is jointly determined by the number of video points, the historical false alarm rate, and a proportional coefficient. Finally, the difficulty coefficient of video review and the urgency parameter are weighted and fused together. A weighting coefficient is used to control the influence ratio of the two to calculate the final task complexity assessment result.

[0031] In one possible implementation, the urgency parameter of the task to be processed is obtained through the resource supply and demand fluctuation benchmark value, and the task complexity assessment result is determined in combination with the urgency parameter. Specifically, this includes steps 1031-1033, as follows: Step 1031: Obtain the tasks to be processed; determine the response time threshold based on the resource supply and demand fluctuation benchmark value, and correct the initial alarm level of the tasks to be processed according to the response time threshold to obtain the urgency parameter.

[0032] In this embodiment, the urgency parameter is a quantitative representation of the response time requirement for a task, reflecting the time sensitivity and priority of task processing. It is typically represented by a value from 0 to 10, with a higher value indicating a more urgent task. The urgency parameter takes into account factors such as the initial alarm level and resource supply and demand, and is used to guide subsequent task allocation and processing procedures. For example, the urgency parameter for a fire alarm might be 9.5, while the urgency parameter for an offline alarm from a regular device might be 3.2.

[0033] Specifically, the process of acquiring tasks to be processed and determining urgency parameters includes the following steps: First, tasks to be processed are retrieved from the task queue of the cloud monitoring platform, including task identifier, task type, alarm source, and initial alarm level. Second, a response time threshold is determined based on the calculated resource supply and demand fluctuation baseline value. The specific calculation method is: Response Time Threshold = Base Response Time × (1 + α × Resource Supply and Demand Fluctuation Baseline Value), where α is an adjustment coefficient used to control the degree of influence of resource supply and demand on response time. Then, the initial alarm level of the task to be processed is corrected based on the calculated response time threshold. The calculation method is: Urgency Parameter = Initial Alarm Level × (Base Response Time ÷ Response Time Threshold)^β, where β is a correction factor used to adjust the sensitivity of response time changes to the urgency parameter. When the response time threshold is greater than the base response time, the urgency parameter will be lower than the initial alarm level; conversely, the urgency parameter will be higher than the initial alarm level, thus reflecting the impact of the current resource supply and demand situation on the urgency of the task.

[0034] Step 1032: Analyze the features of the on-site monitoring screen corresponding to the task to be processed, and extract the number of video verification points and the historical false alarm rate of the associated defense zone.

[0035] In this embodiment, the on-site monitoring screen features refer to key visual information extracted from the video stream collected from the monitoring point, including but not limited to moving targets, abnormal behavior patterns, and environmental change features in the screen. These features are derived from the original video through computer vision and image processing technologies, and are used to assist in judging the on-site situation and the authenticity of the alarm, such as smoke diffusion characteristics, personnel gathering characteristics, or abnormal behavior characteristics.

[0036] Specifically, the process of analyzing the features of the on-site monitoring footage corresponding to the task to be processed includes the following steps: First, obtain real-time video stream data of the corresponding monitoring points based on the association information of the task to be processed. Second, input the obtained video stream into a pre-trained video analysis model, which can be based on convolutional neural networks or other deep learning architectures and can identify key targets and behavioral patterns in the video. Then, extract the number of video verification points related to the task from the analysis results, that is, the number of monitoring devices that need to be manually verified, including the main alarm points and their surrounding auxiliary judgment related points. Finally, query the historical database of the cloud monitoring platform to extract the historical false alarm rate data of the defense zone where these verification points are located. This data represents the proportion of the number of false alarms generated in this defense zone within a specific time period (such as 30 days) to the total number of alarms. The calculation method is: Historical false alarm rate = Number of false alarms ÷ Total number of alarms × 100%.

[0037] Step 1033: Calculate the video review difficulty coefficient based on the number of video review points and the historical false alarm rate; weight and fuse the video review difficulty coefficient with the urgency parameter to output the task complexity assessment result.

[0038] In this embodiment, the task complexity assessment result refers to a comprehensive quantitative index of the difficulty and resources required to execute the task, typically represented by a value from 0 to 100, with higher values ​​indicating greater task complexity. This assessment result comprehensively considers multiple dimensions such as task urgency, video review difficulty, and environmental factors, guiding the system in resource allocation and task scheduling. For example, a task with a complexity assessment result of 85 may require more human resources and a longer processing time, while a task with a complexity of 30 may only require a standard processing procedure.

[0039] Specifically, the process of calculating the video review difficulty coefficient and determining the task complexity assessment result includes the following steps: First, the video review difficulty coefficient is calculated based on the number of extracted video review points and the historical false alarm rate of the associated defense zone. The calculation formula is: Video review difficulty coefficient = γ × Number of video review points × (1 + Historical false alarm rate), where γ is a proportional coefficient used to balance the impact of the number of points and the false alarm rate on the review difficulty. When the historical false alarm rate is high or the number of points that need to be reviewed is large, the video review difficulty coefficient will increase accordingly. Second, the calculated video review difficulty coefficient is weighted and fused with the urgency parameter obtained in step 1031. The calculation formula is: Task complexity assessment result = ω × Urgency parameter + (1-ω) × Video review difficulty coefficient, where ω is a weight coefficient, ranging from 0 to 1, used to control the proportion of urgency and review difficulty in the final assessment result. When the value of ω is large, the urgency of the task has a greater impact on the complexity assessment result; when the value of ω is small, the difficulty of video review has a greater impact on the assessment result. This weighted fusion approach takes into account both the time sensitivity of the task and the technical challenges that may be encountered during execution, thus obtaining a comprehensive and objective assessment of the task complexity.

[0040] Step 104: If the task complexity assessment result exceeds the preset threshold, then perform similarity analysis based on the task complexity assessment result to obtain the adjusted task priority ranking.

[0041] In this embodiment, similarity analysis refers to a method of retrieving historical records with similar characteristics to the current task from historical task data, and assessing the execution risk and priority of the current task by comparing factors such as task attributes, processing methods, and execution results. Similarity analysis utilizes data mining and pattern recognition technologies to achieve intelligent task classification and risk prediction, providing data support for task prioritization. For example, by analyzing the processing time and resource consumption of similar fire alarm tasks in history, the execution difficulty and urgency of the current fire alarm task can be predicted.

[0042] Specifically, the process of performing similarity analysis and obtaining the adjusted task priority ranking is as follows: First, the task complexity assessment result is compared with a preset threshold. If the assessment result is greater than the threshold, the similarity analysis process is triggered. A query operation is performed in the historical task database, using task type, complexity assessment result, monitoring point features, etc., as matching conditions to retrieve historical records similar to the current task. During similarity calculation, multiple feature values ​​of the current task and historical tasks are compared. The difference in each feature is assigned different weights according to its importance, and the similarity value between the two tasks is calculated comprehensively. Historical tasks with similarity higher than a specific threshold are selected to form a set of similar historical tasks. Based on the actual processing time, resource consumption, and processing results of each task in the similar historical task set, the execution risk index of the current task is calculated. This index is the average of the product of the processing difficulty coefficient and the result impact factor of all tasks in the set. All tasks in the task queue are sorted from high to low according to their execution risk index, generating an adjusted task priority ranking list. The sorting rules ensure that tasks with higher execution risk indices are ranked first.

[0043] In one possible implementation, if the task complexity assessment result exceeds a preset threshold, a similarity analysis is performed based on the task complexity assessment result to obtain an adjusted task priority ranking, specifically including steps 1041-1043, as follows: Step 1041: If the task complexity assessment result exceeds the preset threshold, retrieve historical task records that match the task complexity assessment result from the historical task database to form a set of similar historical tasks.

[0044] Specifically, the process of constructing a set of similar historical tasks includes the following steps: First, obtain the task complexity assessment result of the current task to be processed and compare it with a preset threshold. When the task complexity assessment result is greater than the preset threshold, the historical task retrieval process is initiated. Second, construct database query conditions, including primary and secondary conditions. The primary condition is set to ensure that the task type is consistent with the current task and that the complexity assessment result is within the positive or negative tolerance range of the current task's assessment result, where the tolerance parameter is a configurable similarity tolerance parameter. Secondary conditions include features that match the current task, such as the geographical location and time period (e.g., weekday / non-weekday, daytime / nighttime). Then, send a query request to the historical task database and execute the query statement to select historical task records that meet the conditions. Finally, receive the query results and preprocess the data, including removing invalid records and standardizing the data format to form a structured set of similar historical tasks. If the query results are empty or the number is less than the preset minimum threshold, appropriately relax the tolerance range value in the query conditions and re-execute the query until a sufficient number of historical records are obtained or the maximum number of attempts is reached.

[0045] Step 1042: Calculate the task execution risk index based on the set of similar historical tasks.

[0046] Specifically, the process of calculating the task execution risk index includes the following steps: First, extract key feature data from a set of similar historical tasks, including the actual processing time, resource consumption (such as the number of participants, equipment usage, etc.), and processing result rating (success, partial success, failure, etc.) for each historical task. Second, standardize these feature data, converting data of different dimensions into a unified standard score. The standardization method is to subtract the average value of the features from the original value and then divide by the standard deviation to obtain the standardized value. Then, calculate the processing difficulty coefficient for each historical task. The calculation method is to sum the standardized processing time, resource consumption, and processing result rating according to preset weights, where the processing result rating needs to be reversed (subtract the standardized value from 1). Next, calculate the result impact factor for each historical task, representing the importance and scope of the task's processing result. The calculation method is to sum the impact area, the number of people affected, and the economic loss according to preset weights. Finally, the execution risk index of the current task is obtained by weighted averaging of the processing difficulty coefficients and result impact factors of all historical tasks. The calculation method is to sum the products of the processing difficulty coefficients and result impact factors of all historical tasks, divide by the number of tasks, and then multiply by 100 for standardization.

[0047] Step 1043: Sort each task to be processed according to the task execution risk index to obtain the adjusted task priority ranking.

[0048] Specifically, the process of sorting tasks based on their execution risk index includes the following steps: First, obtain a list of all pending tasks in the current cloud monitoring platform, including the identification information, complexity assessment result, and calculated execution risk index for each task. For tasks whose complexity assessment result does not exceed a preset threshold, their execution risk index can be set to a default value or obtained through simplified calculation. Second, sort the tasks in descending order according to their execution risk index, i.e., tasks with higher execution risk indices are ranked higher. Efficient comparison sorting algorithms such as quicksort and heapsort can be used, with a time complexity of log-linear, where n is the total number of pending tasks. The sorting process can be represented as: sorting the task set according to the corresponding execution risk index set, such that the sorted task set satisfies the condition of the execution risk index being arranged from largest to smallest. Then, when multiple tasks have the same or very close execution risk indices (the difference is less than a preset tolerance value), auxiliary sorting rules are introduced, such as the order of task creation time and the initial alarm level, to ensure the uniqueness and stability of the sorting results. Finally, a final adjusted task priority ranking list is generated, which contains the identification information of all pending tasks sorted by priority. This ranking result is stored in the system's task queue for use in the subsequent task allocation process.

[0049] Step 105: Based on the adjusted task priority ranking, perform path planning to determine the cloud-based task dispatching scheme; perform deviation analysis on the cloud-based task dispatching scheme to obtain preliminary task pricing values, and provide feedback correction when the preliminary task pricing values ​​exceed the preset deviation to obtain the target service pricing result.

[0050] In this embodiment, the cloud-based task assignment scheme refers to a specific execution plan for assigning tasks to suitable online personnel, including information such as task-person matching relationships, execution order, and estimated completion time. This scheme considers factors such as the location, workload, and task compatibility of the personnel to guide the system in task assignment, ensuring that tasks are efficiently and reasonably allocated to the most suitable personnel. For example, high-priority fire alarm tasks are assigned to the nearest personnel with relevant experience.

[0051] Specifically, the process of route planning and dispatching based on task priority ranking includes: First, based on the adjusted task priority ranking list, obtaining the current geographical coordinates and current task load rate (the ratio of the number of assigned tasks to the personnel's processing capacity) of all online monitoring personnel. For each task in the task priority ranking list, calculating the spatial distance cost between all online monitoring personnel and the task location, which is the Euclidean distance between the personnel's location and the task's location. The spatial distance cost and the current task load rate are weighted and calculated, with a weighting coefficient controlling the influence ratio between the two, to obtain the comprehensive scheduling cost for each online monitoring personnel for each task. For each task, selecting the personnel with the lowest comprehensive scheduling cost from all online monitoring personnel as the target executor. The identity data of the target executor is written into the scheduling instruction set of the corresponding task, generating a cloud-based dispatching scheme containing all task-person matching pairs.

[0052] In one possible implementation, path planning is performed based on the adjusted task priority ranking to determine the cloud-based duty dispatch allocation scheme, specifically including steps 1051-1054, as follows: Step 1051: Based on the adjusted task priority, obtain the current geographical coordinates and current task load rate of all online monitoring personnel.

[0053] Specifically, the process of obtaining the current geographic coordinates and current task load of all online monitoring personnel includes the following steps: First, query the user management system of the cloud monitoring platform to obtain a list of all monitoring personnel accounts currently logged in as "online" and with a work status of "available for assignment," and obtain their user identifiers, terminal device numbers, and other information. Second, send location information requests to the mobile terminals of each online monitoring personnel. After receiving the request, the terminal device returns the current GPS positioning data or network positioning data in a standard geographic coordinate information format, including parameters such as longitude, latitude, and positioning accuracy. If the terminal device fails to locate or does not respond within a timeout period, the location data of the last successful location of the personnel is used, and the update time of the location data is marked in the record. Then, query the number of tasks currently assigned but not yet completed for each online monitoring personnel in the task management system, and at the same time, obtain the task processing capacity parameters of each monitoring personnel from the personnel information configuration database. This parameter reflects the maximum number of tasks that the personnel can handle simultaneously based on their work experience and professional level. Finally, for each online operator, calculate the current task load rate: Current task load rate = Number of currently assigned but incomplete tasks ÷ Task processing capacity parameter, with the result rounded to two decimal places. Store the acquired geographic coordinates and the calculated current task load rate data in an associative array for subsequent dispatch decision calculations.

[0054] Step 1052: Calculate the spatial distance cost between the online monitoring personnel and the task location based on the current geographical coordinates.

[0055] Specifically, the process of calculating the spatial distance cost between online monitoring personnel and the task location includes the following steps: First, the geographical coordinates of each task to be processed are obtained sequentially from the adjusted task priority ranking list. This coordinate information comes from the alarm location or monitoring equipment location recorded when the task was created. Second, the geographic spatial distance between each task and each online monitoring personnel is calculated. When calculating the distance between two points on the Earth's surface, the Haversine formula is used to calculate the spherical distance. This formula takes into account the curvature of the Earth and can provide a relatively accurate geographic distance estimate. In the Haversine calculation process, latitude and longitude coordinates are first converted from angles to radians, then the central angle between the two points is calculated, and finally multiplied by the Earth's radius (approximately 6371 kilometers) to obtain the actual distance. For points that are relatively close (less than 10 kilometers), the calculation can be simplified to planar Euclidean distance to improve computational efficiency. Then, the calculated geographic spatial distance is corrected based on the current road traffic conditions. By accessing a third-party traffic data service API or the platform's self-built traffic condition database, the congestion index of the main roads between the two points is obtained. The original geographic distance is multiplied by a congestion correction factor to obtain the actual distance estimate after considering traffic factors. Finally, the corrected actual distance is converted into a standardized spatial distance cost. The conversion method is as follows: divide the distance value by a preset standard distance (e.g., 10 kilometers), then perform a non-linear transformation. This amplifies the difference over shorter distances and compresses the difference over longer distances. The calculation formula can be expressed as: Spatial distance cost = 100 × (1 - the ratio of the negative actual distance to the standard distance using an exponential function). The calculation result is rounded to one decimal place, ranging from 0 to 100; the greater the distance, the closer the cost is to 100.

[0056] Step 1053: Calculate the weighted cost of spatial distance and the current task load rate to obtain the comprehensive scheduling cost of each online monitor for each task; extract the lowest value among the comprehensive scheduling costs of each task, and determine the online monitor corresponding to the lowest value as the target executor.

[0057] Specifically, the process of calculating the comprehensive scheduling cost and determining the target personnel includes the following steps: First, for each task and each online staff member combination, obtain the spatial distance cost calculated in the previous step and the current task load rate of the staff member. Second, convert the spatial distance cost into a standardized value with the same dimensions as the task load rate. The conversion method is: Standardized spatial distance cost = Spatial distance cost ÷ 100. The converted value ranges from 0 to 1, consistent with the range of the task load rate. Then, for each task-person combination, calculate the comprehensive scheduling cost using a weighted average method. The calculation formula is: Comprehensive scheduling cost = α × Standardized spatial distance cost + (1-α) × Current task load rate, where α is a weighting coefficient with a value range of 0-1, used to control the relative importance of spatial distance and task load in the final decision. Based on actual business needs, this weighting coefficient can be set to 0.6, indicating that the spatial distance factor is slightly more important than the task load factor. The calculated comprehensive scheduling cost is then multiplied by 100, mapping to the 0-100 range for easy understanding and comparison. Next, for each pending task, the overall scheduling cost value of all online monitoring personnel for that task is compared, and the minimum value is found, with the corresponding monitoring personnel identifier recorded. If multiple monitoring personnel have the same or very close overall scheduling cost value (the difference is less than a preset threshold, such as 0.5), auxiliary decision-making rules are used for selection, such as prioritizing personnel with higher professional skill matching or personnel with higher recent task completion scores. Finally, the monitoring personnel corresponding to the minimum overall scheduling cost value are determined as the target executor for that task, and the correspondence between task identifiers and target executor identifiers is recorded for subsequent dispatch plan generation.

[0058] Step 1054: Write the identity data of the target personnel into the scheduling instruction set of the corresponding task, and summarize to generate a cloud-based duty dispatching scheme.

[0059] Specifically, the process of generating a cloud-based dispatching scheme includes the following steps: First, create a new dispatching scheme data structure, including basic information fields such as a unique scheme identifier (usually generated by a combination of a system timestamp and a random string), scheme creation time (timestamp accurate to milliseconds), and scheme status (initially set to "draft"). Second, read detailed information for each pending task from the adjusted task priority sorting list, including task identifier, task type, priority number, alarm source, and location. Simultaneously, obtain the identification data of the target personnel identified for the task in the previous step, including personnel number, name, job level, and department. Then, create a scheduling instruction data structure for each task. This structure contains basic task information, execution time limits, quality control parameters, and complete identification data of the target personnel. The scheduling instruction data structure should also include a task execution status tracking field (initially set to "pending dispatch"), creation time, and expected execution time interval. Next, integrate all created scheduling instructions into the task list field of the dispatching scheme according to task priority, and calculate the overall statistics of the scheme, such as the total number of tasks, the number of personnel involved, and the distribution of task types. Finally, the status of the dispatch allocation plan is updated from "draft" to "pending execution," and a digital signature of the plan is generated (using the system's private key to encrypt the hash value of key fields), ensuring the integrity and immutability of the plan. The complete cloud-based dispatch allocation plan is written to the system database, and an execution log is created to provide data support for subsequent dispatch execution and performance evaluation.

[0060] In one possible implementation, a deviation analysis is performed on the cloud-based task dispatching scheme to obtain a preliminary task pricing value, specifically including steps 1055-1056, as follows: Step 1055: Extract the historical average completion time and historical benchmark price of similar tasks based on the cloud-based task allocation scheme.

[0061] Specifically, the process of extracting the historical average completion time and historical benchmark pricing for similar tasks includes the following steps: First, extract the task type identifier code for each pending task from the cloud-based dispatching scheme. This identifier code is usually a predefined code used to distinguish tasks of different natures and processing flows, such as "FIRE_ALARM" indicating fire alarm verification and "EQUIP_OFFLINE" indicating equipment offline failure. Second, construct database query conditions, using the extracted task type identifier code as the primary key, and set the query time range to 3-6 months prior to the current date (adjustable according to system configuration). Then, send a query request to the historical task database, execute an aggregate query operation, and obtain the average completion time of all completed tasks of the specified task type within the set time range. The completion time is calculated based on the task status change record, specifically the time difference between the "assigned" and "completed" statuses. Simultaneously, query the pricing management database to obtain the average service pricing amount for this task type within the same time range. This amount is the arithmetic mean of the actual settlement amounts for all similar tasks. If the query results are empty or the sample size is too small (below a preset threshold, such as 10), the query time range is expanded or the query is downgraded to a more general task type category. Finally, the historical average completion time (in minutes) and historical benchmark pricing (in yuan or other currencies) obtained from the query are associated with the original task and stored for subsequent pricing calculations.

[0062] Step 1056: Calculate the time deviation rate between the estimated completion time of the current order and the historical average completion time; adjust the estimated completion time based on the time deviation rate, and calculate the preliminary task pricing value by combining the historical benchmark pricing.

[0063] Specifically, the process of calculating the time-consuming deviation rate and obtaining the preliminary task pricing value includes the following steps: First, calculate the estimated completion time of the current task assignment. The estimation process comprehensively considers factors such as the historical processing efficiency of the target executor (extracted from the personnel performance database), the current task complexity assessment result, and the current task load rate of the executor. The calculation formula is: Estimated completion time = Historical average completion time × Personnel efficiency factor × Task complexity correction coefficient × Load adjustment factor. Wherein, the personnel efficiency factor represents the efficiency ratio of the executor relative to the average level, the task complexity correction coefficient increases with the increase of the task complexity assessment result, and the load adjustment factor increases with the increase of the current task load rate. Second, calculate the time-consuming deviation rate between the estimated completion time and the historical average completion time. The calculation formula is: Time-consuming deviation rate = (Estimated completion time - Historical average completion time) ÷ Historical average completion time × 100%. This result is expressed as a percentage; a positive value indicates that more time is expected, and a negative value indicates that less time is expected. Then, the estimated completion time is corrected based on the time-consuming deviation rate to obtain the corrected completion time. The purpose of the correction is to smooth out extreme estimates and avoid excessive deviations caused by a single factor. The correction formula is: Corrected completion time = Estimated completion time ÷ (1 + Correction coefficient × Time deviation rate), where the correction coefficient is a configuration parameter between 0 and 1, used to control the strength of the correction. Finally, combining historical benchmark pricing and the corrected completion time, the preliminary task pricing value is calculated. The calculation formula is: Preliminary task pricing value = Historical benchmark pricing × (1 + Price fluctuation coefficient × Time deviation rate), where the price fluctuation coefficient is a configuration parameter between 0 and 1, used to control the degree of impact of time deviation on price. Through this calculation, when the task is expected to take a longer time, the price will be increased accordingly; when the task is expected to take a shorter time, the price will be decreased accordingly.

[0064] In one possible implementation, when the initial task pricing value exceeds a preset deviation, feedback correction is performed to obtain the target service pricing result, specifically including steps 1057-1059, as follows: Step 1057: Extract the task type identifier from the cloud-based dispatching scheme, and query the corresponding historical pricing range in the historical pricing database based on the task type identifier.

[0065] Specifically, the process of extracting task type identifiers and querying historical pricing ranges includes the following steps: First, parse the detailed information fields of each task to be processed from the data structure of the cloud-based dispatching scheme, locate and extract the value of the task type identifier field. Task type identifiers typically use a hierarchical encoding method, such as the "ABC" format, where A represents the task category (e.g., fire protection, security, equipment maintenance), B represents the task subcategory (e.g., alarm verification, inspection, fault diagnosis), and C represents the specific task type (e.g., smoke alarm, perimeter alarm). Second, the extracted task type identifiers are standardized to ensure their format meets the query requirements of the historical pricing database. This processing includes removing leading and trailing spaces, converting case, and handling special characters to ensure query accuracy. Then, database query conditions are constructed. The primary condition is an exact match of the task type identifier, and the secondary condition is a time range limitation (usually 6-12 months prior to the current date; the specific time span can be adjusted according to system configuration). For hierarchical task type identifiers, a multi-level query strategy is employed: First, an exact match query is attempted using the complete task type identifier. If no match is found or the sample size is too small (below the system's preset sample size threshold, such as 30), the next higher-level task type identifier is truncated (e.g., "AB" is truncated from "ABC") to obtain broader reference data. Finally, a database query is executed to calculate statistical indicators such as the minimum, maximum, average, and standard deviation of pricing for all historical tasks meeting the specified conditions. Typically, the historical pricing range is defined as: [average - k × standard deviation, average + k × standard deviation], where k is the system-configured range width coefficient, typically 1.5 or 2, used to control the width of the range. The historical pricing range obtained from the query is associated with the current task and temporarily stored for subsequent pricing adjustments.

[0066] Step 1058: Calculate the excess deviation between the initial task pricing value and the boundary value of the historical pricing range.

[0067] Specifically, the process of calculating the excess deviation amount between the preliminary task pricing value and the historical pricing range boundary value includes the following steps: First, obtain the preliminary task pricing value calculated in step 1056 and the historical pricing range queried in step 1057 from temporary storage. The historical pricing range is usually expressed as an ordered pair [L, U], where L is the lower bound of the range (historical lowest pricing) and U is the upper bound of the range (historical highest pricing). Second, determine whether the preliminary task pricing value P falls within the historical pricing range [L, U]. The judgment conditions are as follows: If L ≤ P ≤ U, then the preliminary pricing is within the historical range; if P < L, then the preliminary pricing is lower than the historical lowest price; if P > U, then the preliminary pricing is higher than the historical highest price. Then, calculate the excess deviation amount D according to the judgment result. The calculation formula is as follows: If L ≤ P ≤ U, then D = 0; if P < L, then D = P - L (at this time D is negative); if P > U, then D = P - U (at this time D is positive). For the convenience of subsequent processing, the relative excess deviation rate R can also be calculated. The calculation formula is: R = D / [(U - L) / 2], that is, divide the excess deviation amount by the half-width of the historical pricing range to obtain a dimensionless relative deviation value. Finally, associate the calculated excess deviation amount D and relative excess deviation rate R with the current task and temporarily store them for the subsequent pricing correction coefficient query process. For special cases, such as when the historical data is insufficient and the historical pricing range is unavailable, or the historical pricing range is too narrow (such as U - L < threshold), alternative strategies can be adopted, such as using a fixed default deviation amount or expanding the historical pricing range and then calculating the deviation amount.

[0068] Step 1059: Obtain the corresponding pricing correction coefficient from the preset correction coefficient mapping table according to the excess deviation amount; perform a multiplication operation on the pricing correction coefficient and the preliminary task pricing value to obtain the target service pricing result.

[0069] Specifically, the process of obtaining the pricing correction coefficient and calculating the target service pricing result includes the following steps: First, a preset correction coefficient mapping table is loaded from the system configuration library. This mapping table defines the correspondence between the excess deviation amount or relative excess deviation rate and the pricing correction coefficient, usually in the form of a piecewise function. For example, different correction coefficient values ​​correspond to different intervals of the relative excess deviation rate R. A typical structure of the mapping table might be: when R=0, the correction coefficient = 1.0 (no correction required); when 0<|R|≤0.2, the correction coefficient = (1-0.25×R); when 0.2<|R|≤0.5, the correction coefficient = (1-0.4×R); when |R|>0.5, the correction coefficient = (1-0.5×R). Second, the excess deviation amount D or relative excess deviation rate R calculated in step 1058 is retrieved from temporary storage, and the corresponding pricing correction coefficient C is searched in the correction coefficient mapping table according to its value. The search process uses interval matching or interpolation calculation methods to ensure that a suitable correction coefficient can be obtained for any deviation amount. For deviation values ​​not explicitly defined in the mapping table, linear interpolation can be used to calculate the corresponding correction coefficient to ensure the smoothness of the correction process. Then, the calculated or retrieved pricing correction coefficient C is multiplied by the initial task pricing value P, using the formula: Target service pricing result = P × C. This calculation adjusts the initial pricing according to the correction coefficient, making the final pricing more consistent with historical pricing patterns. For an excessively high initial price, the correction coefficient is less than 1, resulting in a price reduction; for an excessively low initial price, the correction coefficient is greater than 1, resulting in a price increase; for an initial price within a reasonable range, the correction coefficient is close to 1, keeping the price essentially unchanged. Finally, the calculated target service pricing result is normalized, such as rounding to one or two decimal places, or rounding to the nearest integer or a specific rounding unit (e.g., multiples of 5 yuan), making the final pricing more standardized and easier to understand. The target service pricing result is then written into the corresponding field of the task data structure, completing the pricing process.

[0070] Step 106: Based on the target service pricing results and the cloud-based duty dispatching scheme, determine the response efficiency optimization path for the cloud-based duty service, and execute the dispatching according to the response efficiency optimization path.

[0071] In this embodiment, the response efficiency optimization path refers to a resource scheduling and data transmission strategy designed to improve the execution efficiency of cloud-based monitoring tasks. This includes elements such as video stream transmission node selection, network bandwidth allocation, and task execution order arrangement. This path aims to maximize system resource utilization, reduce task response latency, and ensure the processing quality of high-value tasks. For example, it allocates high-bandwidth channels to high-priority tasks to ensure real-time transmission and clarity of video surveillance footage.

[0072] Specifically, the process of determining the optimal response efficiency path for cloud-based monitoring services and executing task dispatch includes: First, querying the service level configuration table based on the target service pricing result to obtain the corresponding service level timeliness requirements, including parameters such as maximum response time and video stream quality requirements. Second, according to the cloud-based monitoring task dispatch allocation scheme, obtaining the target personnel's terminal network bandwidth status (including uplink bandwidth, downlink bandwidth, network latency, etc.) and current task queuing sequence. Third, based on the service level timeliness requirements and terminal network bandwidth status, selecting the optimal video stream transmission node from the cloud-based monitoring platform's video server cluster. The selection criterion is to comprehensively consider the network round-trip time between the target personnel and the video server, and the server with the smallest weighted sum of the two. Fourth, calculating the required bandwidth resources based on the service level timeliness requirements and video stream characteristics (such as resolution, frame rate, etc.). Fifth, formulating a bandwidth allocation strategy based on the calculation results, determining the video stream's encoding parameters, transmission priority, and caching strategy. Sixth, integrating the selected video stream transmission node, bandwidth allocation strategy, and the target personnel's current task queuing sequence to generate an optimized response efficiency path. Finally, following the response efficiency optimization path, the scheduling instructions for the tasks to be processed and the on-site monitoring video stream are pushed to the cloud terminal of the target personnel through the selected transmission node to complete the task dispatching process.

[0073] In one possible implementation, based on the target service pricing result and the cloud-based service dispatching scheme, a response efficiency optimization path for the cloud-based service is determined, and dispatching is executed according to the response efficiency optimization path. Specifically, this includes steps 1061-1064, as follows: Step 1061: Obtain the service level timeliness requirements corresponding to the target service pricing result; according to the cloud-based dispatching scheme, obtain the terminal network bandwidth status and current task queuing sequence of the target personnel.

[0074] Specifically, the process of obtaining service level timeliness requirements, terminal network bandwidth status, and current task queuing sequence includes the following steps: First, read the service level definition table from the system configuration database. This table defines the service levels and corresponding timeliness requirements for different price ranges. The service level definition table typically contains multiple price ranges and corresponding service level parameters. For example, the price range [0, 80] corresponds to the basic service level, with parameters {initial response time: 120 seconds, video stream setup time: 30 seconds, problem resolution time: 30 minutes}; the price range [80, 150] corresponds to the standard service level, with parameters {initial response time: 60 seconds, video stream setup time: 15 seconds, problem resolution time: 20 minutes}; and the price range [150, +∞) corresponds to the advanced service level, with parameters {initial response time: 30 seconds, video stream setup time: 10 seconds, problem resolution time: 10 minutes}. Based on the target service pricing result calculated in step 1059, search for the matching price range in the service level definition table and obtain the corresponding service level timeliness requirement parameters. Secondly, the network bandwidth status of the target personnel's terminal is obtained through the network monitoring interface. This process first extracts the target personnel's terminal device ID from the cloud-based dispatching scheme, then sends a query request to the network monitoring system to obtain the real-time network status data of that terminal device. The network status data includes key indicators such as downlink bandwidth (receive rate), uplink bandwidth (transmit rate), network latency, packet loss rate, and jitter. If real-time data acquisition fails or the data is abnormal, the average network status of the terminal over a recent period (e.g., the past 30 minutes) is used as a substitute value. Next, the task management system is queuing to obtain the target personnel's current task queue. This process extracts the target personnel's ID from the cloud-based dispatching scheme, sends a query request to the task management system, and obtains the list of tasks currently being processed and tasks awaiting processing. The task list includes information such as the ID, reception time, start processing time (if processing has already started), estimated processing time, and task priority for each task. Simultaneously, the remaining processing time and estimated completion time for each task are calculated to construct a complete task timeline for subsequent video stream transmission scheduling. Finally, the obtained service level timeliness requirements, terminal network bandwidth status, and current task queuing sequence are stored in the temporary work area for subsequent video stream transmission node matching and bandwidth allocation strategy formulation.

[0075] Step 1062: Based on the service level timeliness requirements and the terminal network bandwidth status, match the corresponding video stream transmission nodes and bandwidth allocation strategies for the tasks to be processed in the cloud monitoring platform.

[0076] Specifically, the process of matching video streaming nodes and bandwidth allocation strategies includes the following steps: First, based on the geographical location of the task to be processed and the monitoring point information, available video streaming nodes are filtered. This process extracts the monitoring point location information (such as latitude and longitude or area code) from the task data, queries the deployment location and service range of all video streaming nodes in the system, calculates the network hop count or estimated transmission delay from each node to the monitoring point, and filters out multiple candidate nodes with the closest location or the optimal network path. Typically, the filtering considers factors such as geographical proximity, network topology, and inter-node routing performance, selecting 3-5 potential best nodes as candidates. Second, the current load status and available resources of each candidate video streaming node are evaluated. This process obtains performance indicators such as CPU utilization, memory usage, network bandwidth usage, and the number of video streams currently being processed for each candidate node by calling the resource monitoring interface, and calculates the comprehensive load score and remaining processing capacity. The load assessment uses a weighted calculation method, such as load score = 0.4 × CPU utilization + 0.3 × memory utilization + 0.3 × bandwidth utilization, with a lower score indicating a lighter load. Then, considering service level timeliness requirements, terminal network bandwidth status, and node load, the optimal video stream transmission node is selected for the task. The selection process uses a multi-factor scoring mechanism, comprehensively considering factors such as the distance from the node to the monitoring point, the network path quality from the node to the operator's terminal, the node's current load status, and the response time required by the service level. A comprehensive score is calculated for each candidate node, and the node with the highest score is selected as the final video stream transmission node. Next, based on the service level timeliness requirements, terminal network bandwidth status, and the selected video stream transmission node, a suitable bandwidth allocation strategy is formulated. The strategy formulation process first determines the basic parameters of the video stream, such as the encoding format (usually H.264 or H.265), initial resolution, and base bitrate. Then, based on the service level, video quality priority and processing rules under resource contention are determined. Higher service levels typically correspond to higher video quality and more guaranteed bandwidth allocation. Simultaneously, considering the terminal network bandwidth status, an adaptive bitrate adjustment strategy is designed for different network conditions, such as providing high-definition video when network bandwidth is sufficient and automatically reducing resolution and bitrate when bandwidth is limited to ensure the continuity of the video stream. Finally, the selected video stream transmission nodes and the established bandwidth allocation strategy are combined into a video stream processing configuration, and the configuration information is stored in a temporary workspace for subsequent task queuing and video stream push processes. The configuration information includes a complete set of video stream processing instructions such as node identifiers, access parameters, transcoding rules, quality control parameters, and priority settings.

[0077] Step 1063: Combine the video stream transmission nodes, bandwidth allocation strategy, and current task queuing sequence to generate a response efficiency optimization path.

[0078] Specifically, the process of generating an optimized response efficiency path includes the following steps: First, analyze the current task queuing sequence of the target personnel and evaluate the insertion position of the new task. This process analyzes each task in the current task queuing sequence, calculating its remaining processing time, priority, and service level. For urgent tasks or high service level tasks, the system will consider inserting the new task at the front of the queue; for ordinary tasks, it is usually added to the end of the queue according to the first-in, first-out principle. The determination of the insertion position also considers the continuity of the personnel's work and the switching cost between tasks, trying to avoid frequent interruptions to the tasks being processed. Second, calculate the video stream start time window for the new task based on the service level timeliness requirements. The time window calculation considers the insertion position of the task, the expected completion time of the preceding tasks, and the response time required by the service level. For example, if the new task is inserted third in the queue, and the first two tasks are expected to take another 15 minutes to complete, while the service level requirement is a response within 30 seconds, then the system needs to pre-establish a video stream connection while the current task is being processed, ensuring that the personnel can view the video stream of the new task immediately after completing the first two tasks. Next, the video stream transmission nodes selected in step 1062 are matched with the corrected task queue positions to construct a video stream transmission schedule. The schedule includes the trigger time, warm-up time, official push time, and expected end time for video stream establishment, forming a complete video stream lifecycle management plan. The trigger time is typically set as a reserved time (e.g., 30 seconds or 1 minute) before personnel can begin processing new tasks, ensuring the video stream is ready when needed. Then, combined with bandwidth allocation strategies, corresponding transmission parameters are set for the video stream at different stages. Parameter settings include technical indicators such as encoding format, resolution, bitrate, and frame rate for different stages, as well as priority rules in bandwidth contention situations. For example, a lower resolution and bitrate may be used for transmission during the warm-up stage, consuming only a small amount of bandwidth; during the official push stage, the most suitable video quality is provided based on service level and terminal bandwidth status. Finally, the video stream transmission nodes, schedule, bandwidth allocation strategies, and task queue position information are integrated into a complete response efficiency optimization path data structure. This data structure contains all necessary configuration parameters and control instructions to guide the subsequent video stream push process.

[0079] Step 1064: Optimize the path according to response efficiency and push the on-site monitoring video stream of the task to be processed to the cloud terminal of the target personnel.

[0080] Specifically, the process of pushing the on-site monitoring video stream to the cloud-based monitoring terminal of the target personnel includes the following steps: First, based on the time schedule in the response efficiency optimization path, the video stream establishment procedure is initiated at the specified trigger time. This procedure first verifies the online status of the target personnel's cloud-based monitoring terminal to confirm whether the terminal can currently receive new video streams. The verification process detects the terminal's response and current working status by sending heartbeat packets or status query requests to the terminal. If the terminal is offline or in an abnormal state, the system will attempt to notify the personnel through backup communication channels and adjust the video stream push plan according to the preset anomaly handling strategy. Second, a video stream acquisition command is sent to the selected video stream transmission node to establish an initial connection from the on-site monitoring device to the transmission node. This process first sends a video stream request to the on-site monitoring device through a device access protocol (such as RTSP, ONVIF, etc.) to acquire the raw video stream. Then, the transmission node receives the raw video stream and performs real-time encoding processing according to the parameters defined in the bandwidth allocation strategy, such as adjusting resolution, bit rate, and frame rate, and applying video enhancement algorithms. The processed video stream is temporarily stored in the transmission node's buffer, awaiting push to the target terminal. Then, a secure transmission channel is established from the video stream transmission node to the target personnel's cloud monitoring terminal. This process first establishes a secure connection between the transmission node and the target terminal using encrypted communication protocols (such as TLS, SRTP, etc.) to ensure that video data is not accessed or tampered with during transmission. After the connection is established, the system performs a bandwidth test to assess the current network conditions and fine-tunes the parameters in the bandwidth allocation strategy based on the test results to ensure the video stream can adapt to the actual network environment. Next, according to the quality control parameters defined in the bandwidth allocation strategy, the system begins pushing video stream data to the target terminal. The push process uses adaptive streaming technology, dynamically adjusting video quality based on real-time network conditions. When network conditions are good, the system gradually increases video quality to maximize the use of available bandwidth; when network conditions fluctuate or deteriorate, the system automatically reduces video quality, prioritizing the continuity and stability of the video stream. Simultaneously, the system monitors video stream transmission performance indicators such as latency, jitter, and packet loss rate, and adjusts transmission parameters in real time based on the monitoring data. Finally, the video display interface is activated on the target personnel's cloud monitoring terminal, presenting the monitoring video stream from the site. This process includes video stream decoding, buffering, and rendering, as well as the overlay display of relevant task information. The system adjusts the video display size, position, and interface layout based on the terminal's display capabilities and user preferences to ensure personnel can clearly view the video content and easily operate related controls. Simultaneously, the system records the video stream's setup time, transmission quality, and terminal display status for subsequent service quality assessment and system optimization. For high-priority tasks or emergencies, the system also triggers audio or visual alerts to ensure personnel immediately notice the new video stream.

[0081] In the above embodiments, basic cloud-based monitoring task response efficiency optimization functions were achieved through video stream transmission node matching and bandwidth allocation strategy formulation. To further improve the accuracy and adaptability of resource scheduling and establish a dynamic balance between personnel supply, monitoring point distribution, and the patterns of emergencies, this application also provides a cloud-based monitoring service method based on dynamic dispatch. This method analyzes the spatial distribution characteristics of monitoring points, the spatiotemporal clustering patterns of historical emergencies, and the fluctuation trends of the number of online personnel to construct a matching measurement model of geographic spatial density and human resource supply. It then calculates and dynamically adjusts resource supply and demand benchmark values, enabling the system to more accurately calculate stable and reliable resource scheduling benchmarks in environments with fluctuating human resources and uneven task demands, thereby achieving efficient operation and optimal resource allocation for cloud-based monitoring services. The following section combines... Figure 2 The following describes a cloud-based duty service method based on dynamic order dispatch in an embodiment of this application: Please see Figure 2 This is a flowchart illustrating a cloud-based duty service method based on dynamic dispatching in an embodiment of this application.

[0082] Step 201: Calculate the point dispersion density index based on the number of monitoring points and the coverage data of the monitoring points in the cloud monitoring platform.

[0083] Specifically, the process of calculating the point dispersion density index based on the number of monitoring points and their coverage data includes the following steps: First, obtain the total number of all registered monitoring points. This involves counting all activated and normally functioning monitoring cameras, sensors, and other devices from the cloud monitoring platform's monitoring device database, including fixed cameras, mobile inspection devices, and virtual monitoring points. Second, extract the total geographical area covered by all monitoring points from the coverage data. This data is derived from the effective coverage area calculated based on the field of view parameters, installation height, and lens focal length of each monitoring point. A geographic information system (GIS) is used to perform a spatial union operation on the coverage polygon areas of each point, resulting in a total coverage area without duplicate calculations, expressed in square kilometers or square meters. Then, calculate the ratio of the number of monitoring points to the total geographical area, dividing the number of monitoring points by the total geographical area to obtain the point dispersion density index. This ratio is directly used as the point dispersion density index to characterize the number of monitoring points per unit geographical area. If the total geographical area is zero or abnormal, a default minimum area value is used to avoid division by zero errors, and logs are logged for exception handling.

[0084] In one possible implementation, the point dispersion density index is calculated based on the number of monitoring points and the coverage data of the monitoring points in the cloud monitoring platform, specifically including steps 2011-2012, as follows: Step 2011: Obtain the total number of all registered monitoring points and extract the total geographical area covered by all monitoring points from the coverage data.

[0085] Specifically, by accessing the underlying device management database, all records of monitoring devices that are currently active and have completed system registration are retrieved. The retrieved device records are then traversed and counted to obtain the total number of registered monitoring points. Subsequently, the coverage data associated with the aforementioned registered monitoring points is retrieved, and the effective monitoring radius or boundary coordinate set of each monitoring point in a two-dimensional plane coordinate system is read. Based on the obtained boundary coordinate set of each monitoring point, the area of ​​each independent coverage area is calculated, and the overlapping coverage areas are processed by union to remove duplicate areas. Finally, all the deduplicated area areas are summed to extract the total geographical area covered by all monitoring points from the coverage data.

[0086] Step 2012: Calculate the ratio of the number of monitoring points to the total geographical area; use the ratio as the point dispersion density index, which is used to characterize the number of monitoring points per unit geographical area.

[0087] Specifically, the system obtains the total number of registered monitoring points obtained from the aforementioned statistics, as well as the total geographical area covered by all the monitoring points. It then performs a division operation on the number of monitoring points as the dividend and the total geographical area as the divisor to calculate the ratio of the number of monitoring points to the total geographical area. After obtaining the quotient from the division operation, the quotient is extracted and its data type converted. This ratio is then used as the monitoring point dispersion density index, which characterizes the number of monitoring points per unit geographical area.

[0088] Step 202: Calculate the event density coefficient based on historical emergency distribution data; compare the number of online personnel with the average number of online personnel in the same historical period to obtain the personnel supply offset.

[0089] Specifically, the process of calculating the event density coefficient and obtaining the personnel supply offset based on historical emergency event distribution data includes the following steps: First, calculate the event density coefficient based on historical emergency event distribution data. Extract the spatiotemporal distribution information of all emergencies within a specific number of days (e.g., 30 days) from the event database, including event timestamps, geographic coordinates, event types, and severity levels. Perform cluster statistics according to time windows (e.g., hourly) and spatial grids (e.g., 1-kilometer grids) to calculate the current event frequency of each spatiotemporal unit. Then, divide the current frequency by the historical average frequency of the same spatiotemporal unit to obtain the local density value. Calculate the weighted average of the local density values ​​of all units, with the weights based on the unit area and the event severity level, to obtain the overall event density coefficient. Secondly, the number of online users is compared with the average number of online users in the same historical time period. First, the category of the current time period is identified (such as weekday morning, weekend evening, night shift). The number of online users in the same category of time period is extracted from historical data, and the arithmetic mean of the sequence is calculated as the average number of online users in the same historical time period. Then, the difference between the current number of online users and the historical average number of online users is calculated and divided by the historical average number of online users to obtain the personnel supply offset. A positive value indicates insufficient supply, and a negative value indicates abundant supply.

[0090] Step 203: Determine the benchmark value for resource supply and demand fluctuations based on personnel supply offset, location dispersion density index, and event density coefficient.

[0091] Specifically, the process of determining the benchmark value for resource supply and demand fluctuations based on personnel supply offset, location dispersion density index, and event density coefficient includes the following steps: First, the three indicators are standardized. The location dispersion density index is divided by a preset maximum density threshold to obtain a standardized value. The event density coefficient is subtracted by 1 and then divided by a preset maximum density deviation to obtain a standardized value. The absolute value of the personnel supply offset is divided by a preset maximum offset threshold to obtain a standardized value, ensuring that each standardized value is between 0 and 1. Then, the standardized location dispersion density index is multiplied by the first weight, the standardized event density coefficient by the second weight, and the standardized personnel supply offset by the third weight. The three are added together to obtain the benchmark value for resource supply and demand fluctuations, where the sum of the three weights is 1. The weight ratios are adjusted according to business configuration, such as a location density weight of 0.4, an event density weight of 0.35, and a personnel offset weight of 0.25. Finally, the calculation results are clipped. If the value is less than 0, it is set to 0; if it is greater than 1, it is set to 1. The result is rounded to two decimal places to obtain the final benchmark value for resource supply and demand fluctuations.

[0092] The following describes a cloud-based duty management service system based on dynamic dispatching from the perspective of hardware processing. Please refer to [link to relevant documentation]. Figure 3This is a schematic diagram of the structure of a cloud-based duty service system based on dynamic dispatching in an embodiment of this application.

[0093] It should be noted that, Figure 3 The structure of a cloud-based duty service system based on dynamic dispatch shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0094] like Figure 3 As shown, a cloud-based duty management service system based on dynamic dispatch includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes according to a program stored in a Read-Only Memory (ROM) 302 or a program loaded from a storage section 308 into a Random Access Memory (RAM) 303, such as executing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

[0095] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

Claims

1. A cloud-based duty service method based on dynamic dispatching, characterized in that, The method includes: Obtain data on the number of online personnel, the number of monitoring points, and the distribution of historical emergencies from the cloud monitoring platform; Based on the number of online personnel, the number of monitoring points, and the historical distribution data of emergencies, a baseline value for resource supply and demand fluctuations is determined. By using the resource supply and demand fluctuation benchmark value, the urgency parameter of the task to be processed is obtained, and the task complexity assessment result is determined by combining the urgency parameter. If the task complexity assessment result exceeds a preset threshold, then a similarity analysis is performed based on the task complexity assessment result to obtain an adjusted task priority ranking. Based on the adjusted task priority ranking, path planning is performed to determine the cloud-based duty dispatching scheme. A deviation analysis is performed on the cloud-based duty dispatching scheme to obtain a preliminary task pricing value. When the preliminary task pricing value exceeds a preset deviation, feedback correction is performed to obtain the target service pricing result. Based on the target service pricing result and the cloud-based duty dispatching scheme, determine the response efficiency optimization path for the cloud-based duty service, and execute the dispatching according to the response efficiency optimization path.

2. The method according to claim 1, characterized in that, The step of determining the baseline value for resource supply and demand fluctuations based on the number of online personnel, the number of monitoring points, and the historical distribution data of emergencies includes: Calculate the point dispersion density index based on the number of monitoring points and the coverage data of the monitoring points in the cloud monitoring platform; Calculate the event density coefficient based on the historical event distribution data; The number of online users is compared with the average number of online users in the same historical period to obtain the personnel supply offset. The baseline value for resource supply and demand fluctuations is determined based on the personnel supply offset, the location dispersion density index, and the event density coefficient.

3. The method according to claim 2, characterized in that, The step of calculating the point dispersion density index based on the number of monitoring points and the coverage data of the monitoring points in the cloud monitoring platform includes: Obtain the total number of all registered monitoring points, and extract the total geographical area covered by all monitoring points from the coverage data; Calculate the ratio of the number of monitoring points to the total geographical area; The ratio is used as the point dispersion density index, which is used to characterize the number of monitoring points per unit geographical area.

4. The method according to claim 1, characterized in that, The step of obtaining the urgency parameter of the task to be processed through the resource supply and demand fluctuation benchmark value, and determining the task complexity assessment result in combination with the urgency parameter, includes: Get tasks to be processed; The response time threshold is determined based on the resource supply and demand fluctuation benchmark value, and the initial alarm level of the task to be processed is corrected based on the response time threshold to obtain the urgency parameter. Analyze the features of the on-site monitoring screen corresponding to the task to be processed, and extract the number of video verification points and the historical false alarm rate of the associated defense zone; The video review difficulty coefficient is calculated based on the number of video review points and the historical false alarm rate. The video review difficulty coefficient and the urgency parameter are weighted and fused to output the task complexity assessment result.

5. The method according to claim 1, characterized in that, If the task complexity assessment result exceeds a preset threshold, then a similarity analysis is performed based on the task complexity assessment result to obtain an adjusted task priority ranking, including: If the task complexity assessment result exceeds the preset threshold, then historical task records that match the task complexity assessment result are retrieved from the historical task database to form a set of similar historical tasks. Calculate the task execution risk index based on the set of similar historical tasks; The tasks to be processed are sorted according to the task execution risk index to obtain the adjusted task priority ranking.

6. The method according to claim 1, characterized in that, The step of determining the cloud-based task dispatch allocation scheme based on the adjusted task priority ranking includes: Based on the adjusted task priority sorting, obtain the current geographical location coordinates and current task load rate of all online on-duty personnel; Calculate the spatial distance cost between the online monitoring personnel and the task location based on the current geographical coordinates; The spatial distance cost is weighted and calculated with the current task load rate to obtain the comprehensive scheduling cost of each online duty personnel for each task; Extract the lowest value from the comprehensive scheduling cost corresponding to each task, and determine the online duty personnel corresponding to the lowest value as the target execution personnel; The identity data of the target personnel is written into the scheduling instruction set of the corresponding task, and the cloud-based duty dispatching scheme is generated by summarizing the data.

7. The method according to claim 1, characterized in that, The deviation analysis of the cloud-based task dispatching scheme to obtain preliminary task pricing values ​​includes: Based on the cloud-based task dispatching scheme, extract the historical average completion time and historical benchmark pricing for similar tasks. Calculate the time deviation rate between the estimated completion time of the current order and the historical average completion time; The estimated completion time is corrected based on the time consumption deviation rate, and the preliminary task pricing value is calculated by combining the historical benchmark pricing.

8. The method according to claim 1, characterized in that, The step of providing feedback correction when the initial task pricing value exceeds a preset deviation, to obtain the target service pricing result, includes: Extract the task type identifier from the cloud-based dispatching scheme, and query the corresponding historical pricing range in the historical pricing database based on the task type identifier; Calculate the deviation between the preliminary task pricing value and the boundary value of the historical pricing range; The corresponding pricing correction coefficient is obtained from a preset correction coefficient mapping table based on the amount of deviation. The target service pricing result is obtained by multiplying the pricing correction coefficient with the initial task pricing value.

9. The method according to claim 1, characterized in that, The step of determining the response efficiency optimization path for the cloud-based service based on the target service pricing result and the cloud-based service dispatching scheme, and executing dispatching according to the response efficiency optimization path, includes: Obtain the service level timeliness requirement corresponding to the target service pricing result; According to the cloud-based duty dispatching scheme, obtain the terminal network bandwidth status and current task queuing sequence of the target personnel; Based on the service level timeliness requirements and the terminal network bandwidth status, the cloud monitoring platform matches the corresponding video stream transmission node and bandwidth allocation strategy for the task to be processed. The video stream transmission node, the bandwidth allocation strategy, and the current task queuing sequence are combined to generate the response efficiency optimization path; According to the response efficiency optimization path, the on-site monitoring video stream of the task to be processed is pushed to the cloud monitoring terminal of the target executor.

10. A cloud-based duty service system based on dynamic dispatching, characterized in that, The cloud-based duty service system based on dynamic order dispatch includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the cloud-based duty service system based on dynamic order dispatch to perform the method as described in any one of claims 1-9.

Images