Urban inland inundation monitoring and warning method based on dynamic interaction equipment management mechanism

Abstract

The invention relates to an urban inland inundation monitoring and warning method based on a dynamic interaction equipment management mechanism. The method comprises the following steps: S1, establishing a pgsql database; s2, establishing a dynamic equipment management mechanism to solve the problem of system instability caused by frequent interruption of a video stream or incapability of acquiring an rtsp address; s3, establishing an intelligent round-robin reasoning mechanism to solve the problem that hardware resources are limited during large-scale video monitoring; s4, establishing a rednet-based image anomaly classification model to ensure that a normal monitoring image can be accurately captured; s5, establishing a ponding segmentation model to realize high-precision real-time monitoring of the urban road ponding area and the water gauge; s6, establishing a data acquisition strategy, and performing data acquisition on each piece of monitoring equipment which is currently in a use state; and S7, establishing a waterlogging event alarm strategy to realize timely early warning. The system has the advantages of high real-time performance and accuracy, stable network transmission and automatic early warning.

Description

Technical Field

[0001] The invention relates to the technical field of urban water level monitoring, and in particular to an urban waterlogging monitoring and alarming method based on a dynamic interactive device management mechanism. Background Art

[0002] With the continuous advancement of urbanization, urban waterlogging is becoming increasingly serious. Especially during the monsoon rainy season or sudden rainstorms, urban roads and underground spaces are often covered with water, which leads to problems such as obstructed travel, damaged buildings, and power equipment failures, causing great trouble to the normal operation of the city and residents' lives. In addition, waterlogging may also cause environmental pollution and health hazards. In recent years, with the intensification of global climate change and the frequent occurrence of extreme weather events, urban waterlogging has become more common and serious, and effective monitoring and early warning measures are urgently needed to mitigate its impact.

[0003] At present, the technologies used for urban waterlogging monitoring mainly include physical equipment monitoring and remote sensing technology monitoring. This method has problems such as high installation and maintenance costs, limited coverage, etc. It is difficult to achieve large-scale real-time monitoring, and the real-time performance is poor. There is a lag in data collection and transmission. In recent years, with the rapid development of computer vision and deep learning technology, waterlogging monitoring methods based on video image processing have begun to emerge. These methods use surveillance cameras on urban roads to obtain video data, and through image processing and deep learning algorithms, they can realize automatic identification and monitoring of waterlogged areas. They have the advantages of strong real-time performance, low cost, and wide coverage, but there are the following problems

[0004] (1) Waterlogged areas change dynamically in time and space. They often have irregular shapes, and the boundaries between wetness, waterlogging, and waterlogging are fuzzy, which increases the difficulty of segmentation models.

[0005] (2) Frequent interruptions of video streams, unknown encoding errors, and inability to obtain RTSP addresses due to network transmission issues often cause instability and discontinuity in the monitoring and alarm system, which in turn causes the monitoring system to be unable to respond in a timely manner and provide accurate warning information;

[0006] (3) When dealing with large-scale video surveillance systems, due to the limited hardware resources (such as video memory, network bandwidth, and CPU processing power), implementing real-time concurrent reasoning for hundreds or thousands of cameras often exceeds the system's carrying capacity;

[0007] (4) Waterlogged areas may be confused with areas with similar appearances such as roads and low-lying areas, making it difficult for the model to accurately distinguish them; they may also contain obstructions such as debris and garbage, which will interfere with the model's segmentation process. The monitoring system needs to maintain high accuracy and stability under various complex conditions to avoid false alarms and missed alarms. Summary of the invention

[0008] In view of the above-mentioned deficiencies in the prior art, the technical problem to be solved by this patent application is how to provide an urban waterlogging monitoring and alarm method based on a dynamic interactive device management mechanism with high real-time performance and accuracy, stable network transmission, and automatic early warning.

[0009] In order to solve the above technical problems, the present invention adopts the following technical solutions:

[0010] A method for monitoring and warning urban waterlogging based on a dynamic interactive device management mechanism comprises the following steps: S1: establishing a pgsql database to efficiently manage equipment information, alarm event information, and trajectory information of urban waterlogging; S2: establishing a dynamic device management mechanism to address the problem of system instability caused by frequent interruptions of video streams or inability to obtain rtsp addresses; S3: establishing an intelligent round-robin reasoning mechanism to address the problem of limited hardware resources in large-scale video monitoring; S4: establishing a resnet-based image anomaly classification model to ensure that normal monitoring images can be accurately captured; S5: establishing a waterlogging segmentation model to achieve high-precision real-time monitoring of urban road waterlogging areas and water level gauges; S6: establishing a data collection strategy to collect data for each monitoring device currently in use; S7: establishing an urban waterlogging event alarm strategy to achieve timely warning.

[0011] As an optimization, the core of the dynamic device management mechanism described in step S2 is that when no available rtsp address is currently obtained, any device connection interruption exception is captured, or the system is interrupted and restarted due to heavy system load, it can quickly and automatically switch to the next group of available devices for continued identification, and update the relevant fields of the database to efficiently manage the device status.

[0012] As an optimization, in step S3, an intelligent round-robin reasoning mechanism is established to efficiently utilize limited resources and ensure the continuous and stable operation of the monitoring system; including a timer system, which is responsible for monitoring the usage time of each batch of RTSP devices currently allocated for reasoning. When the threshold is reached, a resource reset signal will be triggered. After capturing the reset signal, it will immediately "start round-robin the next batch of devices."

[0013] As an optimization, a resnet-based picture anomaly classification model is established in step S4. The model is a picture anomaly classification model based on the ResNet residual network, which realizes preprocessing data and optimizing the model training process. It can process video streams in real time and quickly classify each frame or key frame for anomalies to eliminate abnormal video frames caused by network transmission jams and camera blur, ensuring that only normal and clear video frames are included in the subsequent data collection and water accumulation analysis processes.

[0014] As an optimization, the waterlogging segmentation model in step S5 is based on an improved version of the YOLOv8 instance segmentation model, and its training includes the following steps: A1: Data acquisition: Video data is collected by surveillance cameras installed on urban roads. The cameras need to be installed at a suitable height and angle and have night vision functions to ensure all-weather monitoring effects. The collected video data is transmitted to the data processing center in real time through the network for analysis; A2: Data preprocessing: Frame extraction, denoising, color correction and other preprocessing operations are performed on the collected video data to ensure the quality and consistency of the input data. After the video frames are converted into image sequences, they are input into the YOLOv8 model for further processing; A3: Model training and optimization: High-quality training sets and test sets are constructed. These data sets include images of waterlogging in various scenarios, covering different weather conditions, lighting changes and camera angles. The YOLOv8 model is trained using labeled data, and the model parameters are continuously tuned to improve its detection accuracy and stability for waterlogged areas and water level gauges.

[0015] As an optimization, the process of high-precision real-time monitoring of urban road waterlogging areas and water level scales by the waterlogging segmentation model established in step S5 is as follows: B1: The video frames are processed in real time by optimizing the improved YOLOv8 instance segmentation model, the waterlogging areas are identified and segmented, and the area and position of the waterlogging areas are calculated by using image processing technology, so as to determine the scope of the waterlogging; B2: The different colors on the scale, including green, yellow, and red areas, are identified by optimizing the improved YOLOv8 instance segmentation model, and their positions and sizes are determined, and the depth of waterlogging is calculated by analyzing the height ratio of the color area; B3: In the scenario where there are multiple water level scales, the optimized improved YOLOv8 instance segmentation model identifies all scales, and determines the coordinates of the scales and the relative positions and heights between the scales through geometric analysis. According to the recognition results of each scale, the depth of waterlogging is comprehensively calculated through a weighted average algorithm; B4: When the physical scale is blocked or invisible for a long time, a virtual scale is used to judge the depth of waterlogging.

[0016] As an optimization, in step S6, a data collection strategy is established to collect data from the monitoring equipment currently in use. Regardless of whether the equipment detects water accumulation in real time, it is set to automatically capture and save the original image frame of the current camera to a dedicated storage server every 10 minutes.

[0017] As an optimization, the waterlogging event alarm strategy established in step S7 has an alarm process of starting waterlogging, continuing waterlogging and ending waterlogging; its alarm method relies on the above-mentioned model reasoning results and event alarm timer. In each round-robin reasoning device, a dedicated event alarm timer is assigned to each device code. The timer records the corresponding device code, the last time waterlogging was found, the last time waterlogging was not found, whether the current device confirms the discovery of waterlogging, the number of missed detections during continuous waterlogging, the number of false waterlogging detections during no waterlogging, the number of event reasonings, whether there is a flag for an unfinished waterlogging event, and the current waterlogging event number information. If it is found in the database waterlogging event table that the device has an event with a start time but no end time value, the flag of the unfinished waterlogging event is initialized to True, the current event number is the event number of the unfinished waterlogging event, and the waterlogging records found before the current event ends are all the tracks of the event; otherwise, the flag for the unfinished waterlogging event is False, a new event number is created with the current device and timestamp combination, and a new waterlogging event is started to be recorded.

[0018] The present invention has the following effects:

[0019] Under the condition of limited hardware resources, it can effectively deal with adverse factors such as network fluctuations and equipment failures, realize effective monitoring of large-scale camera networks, and at the same time ensure the continuity and stability of reasoning services, reduce the risk of monitoring failure due to connection problems, avoid unnecessary consumption of resources, and improve the overall performance of the system.

[0020] A high-precision YOLOv8 model is trained for waterlogging area segmentation. At the same time, through refined state transition logic and fault-tolerant mechanism, combined with real-time video stream analysis and regular data recording, accurate detection, timely warning and full-process tracking of urban waterlogging events are achieved, which improves the accuracy and reliability of monitoring and alarming in urban waterlogging areas, and provides strong technical support for urban flood prevention and disaster reduction work. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 This is a method flow chart of an urban waterlogging monitoring and alarm method based on a dynamic interactive device management mechanism described in the present invention.

[0022] Figure 2 It is a flow chart of the port interaction device management interface in the present invention. DETAILED DESCRIPTION

[0023] The present invention is further described in detail below in conjunction with the accompanying drawings. In the description of the present invention, it should be understood that the directions or positional relationships indicated by directional words such as "upper, lower" and "top, bottom" are usually based on the directions or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description. Unless otherwise stated, these directional words do not indicate or imply that the devices or components referred to must have a specific direction or be constructed and operated in a specific direction, and therefore cannot be understood as limiting the scope of protection of the present invention; the directional words "inside and outside" refer to the inside and outside relative to the contours of each component itself.

[0024] like Figure 1-2 As shown, a method for monitoring and warning urban waterlogging based on a dynamic interactive device management mechanism includes the following steps: S1: establishing a pgsql database to efficiently manage the device information, alarm event information, and trajectory information of urban waterlogging; S2: establishing a dynamic device management mechanism to address the system instability problem caused by frequent interruptions of video streams or inability to obtain rtsp addresses; S3: establishing an intelligent round-robin reasoning mechanism to address the problem of limited hardware resources in large-scale video monitoring; S4: establishing a resnet-based image anomaly classification model to ensure that normal monitoring images can be accurately captured; S5: establishing a waterlogging segmentation model to achieve high-precision real-time monitoring of urban road waterlogging areas and water level gauges; S6: establishing a data collection strategy to collect data for each monitoring device currently in use; S7: establishing an urban waterlogging event alarm strategy to achieve timely warning.

[0025] Specifically, the device information, alarm event information, alarm event correspondence table and some field information in the database in step S1 are as follows:

[0026] Field Name type length Notes device_code varchar 255 Device Code device_name vachar 255 Device Name device_region varchar 255 Device location device_region_name vachar 255 Name of the region where the device is located delete_status int4 32 Device deletion status: 0-not deleted; 1-deleted scene_type varchar 255 Device screen scene type status int4 32 Device usage status: 0-not in use; 1-in use latest_used_time timestamp 6 Update time of device usage status is_available int4 32 The availability status of the device rtsp: 0-unavailable; 1-available latest_available_time timestamp 6 Update time of device rtsp available status

[0027] Table 1 - Device Information Table - device_info

[0028] Field Name type length Notes id vachar 32 Event ID device_code vachar 255 Device Code device_name vachar 255 Device Name device_region vachar 128 Device location start_time timestamp 6 Event Start Event end_time timestamp 6 Event end time created_time timestamp 6 Event Create Event modified_time timestamp 6 Event update time depth int4 32 Water depth (cm) depth_area numeric 8 <![CDATA[Water depth area m 2 >

[0029] Table 2 - Alarm event information table - alarm_event

[0030] Field Name type length Notes id varchar 32 Record ID event_id varchar 32 Event ID image_path varchar 255 Snapshot image address accuracy numeric 5 Accuracy accuracy_tag int4 32 Accuracy label: 0-inaccurate; 1-accurate capture_time timestamp 6 Snap time depth int4 32 Water depth (cm) depth_area numeric 8 <![CDATA[Water depth area (m 2 )]]>

[0031] Table 3 - Alarm event capture record - alarm_event_capture

[0032] In this embodiment, the core of the dynamic device management mechanism described in step S2 is: when no available rtsp address is currently obtained, any device connection interruption exception is captured, or the system is interrupted and restarted due to heavy system load, it can quickly and automatically switch to the next group of available devices for continued identification, and update the relevant fields of the database to efficiently manage the device status.

[0033] The details are as follows:

[0034] 1. Query available devices

[0035] The standards for currently available devices are clarified, including: the device is not in use, the road type is specified, the device RTSP address is currently in a connectable state, and the device is not deleted and is in an open state; the devices to be queried are filtered out from the database device information table according to the conditions, and are sorted from early to late in the order of the device's most recent use time, and the first n*2 devices that meet the conditions are selected as query targets, and finally the integrated information including the device code, device name and the area where the device is located is queried; because only when the RTSP address is obtained according to the device code and the external interface is called, can it be known whether the current device can actually be put into use, so assuming that each instance service supports the identification process of running n devices at the same time, at this time, it is necessary to query n*2 devices to be used first, and after calling the external interface, select the devices that can actually be put into use by the current instance service, so as to prevent the query of n devices to be used due to the inability of some devices to obtain the RTSP address, resulting in less than n devices each time the instance service runs, resulting in a waste of computing resources.

[0036] 2. Multi-threaded RTSP address acquisition

[0037] In view of the above-mentioned acquisition of n*2 device codes, multi-threading technology is used to call the external interface in parallel to obtain the RTSP address of the device. Each thread independently processes a device number. The input parameter of the interface is the device number, and the output information is the interface return result status, description information and device RTSP address; the results of multi-threaded parallel calls to the external interface are mainly divided into the following three points:

[0038] (1) If the external interface can be called and the interface returns a result status of 0, it means that the device code can successfully obtain the RTSP address, and the device RTSP address field is the RTSP address corresponding to the device code;

[0039] (2) If the external interface can be called and the interface returns a result status of 1, it means that the device code cannot obtain the corresponding RTSP address, the corresponding device RTSP address field is empty, and the device RTSP address throws "Playback timeout, please check whether the pull-down push stream is normal", "Device rtsp address cannot be connected",

[0040] 'err=400' and other prompt information;

[0041] (3) If an external interface error occurs and it cannot be called, or the connection times out during the external interface call, the program throws an exception, and in this case, all device codes cannot obtain the RTSP address;

[0042] Among the above three cases, the device codes that can successfully obtain the RTSP address need to update the corresponding RTSP connectable status in the device information table to 1, indicating that the RTSP address of the current device code is connectable; similarly, all other device codes that cannot obtain the RTSP address need to update the corresponding RTSP connectable status to 0, indicating that the RTSP address of the current device code is not connectable, so as to avoid repeatedly querying the unconnectable device code within a short period of time, resulting in multiple invalid calls to the program and reducing the computing efficiency. The above-obtained RTSP addresses and the corresponding device codes total x (x <= n * 2), and x has the following different processing methods in different intervals:

[0043] (1) If x = 0, it means that all device codes queried cannot obtain the RTSP address. Call the set_device_code interface in the port interaction device management interface, and set the field "device_code" to an empty list, indicating that no available devices have been found for the current instance. At the same time, trigger the intelligent retry policy, re-query the currently available device codes, and call the external interface in multiple threads until x > 0 available device codes can be obtained;

[0044] (2) If 0 < x < n, directly use these x device codes as the devices used by the current instance. Call the set_device_code interface in the port interaction device management interface, and set the field "device_code" to a set list of x device codes;

[0045] (3) If n <= x <= n * 2, it is necessary to screen out the first n device codes as the devices used by the current instance. Call the set_device_code interface in the port interaction device management interface, and set the field "device_code" to a set list of n device codes.

[0046] After the above steps, finally determine x (0 < x <= n) device information and the corresponding RTSP addresses that can be used by the current instance. At this time, it is also necessary to update the usage status of the corresponding device codes in the device information table device_info to 1 and the latest usage time to the current time, indicating that the device is already being used by a certain instance, and the latest usage time is the current time, and set the dynamic update of the device usage status to prevent other instances from repeatedly querying the devices that are being used and repeatedly putting them into use, resulting in a waste of computing resources;

[0047] 3. Establish the port interaction device management interface

[0048] To enable the application-side service to periodically monitor the device code list or empty list in use under each instance, so as to view the device information running under each instance, and assist in dynamically updating the device usage status, so as to realize interactive device management between the identification end and the application end.

[0049] The identification end initializes the global variable instance_info of the current instance information, assigns a unique id field to the current instance through uuid to represent the unique identifier of the current instance, and initializes the device code used by the current device to an empty list; the interface information of the identification end is as follows:

[0050] set_device_code: used by the identification end to set the device currently being used by the instance. The calling method is post, the input parameter is device_code, and the device_code field in the global instance information variable instance_info is updated. The output parameter is the status result of whether the device code is updated successfully.

[0051] get_device_code: used by the application to obtain the device currently being used by the instance. The calling method is get, with no input parameters. The return parameter is instance_info, the current instance information of the identification end.

[0052] Assume that the identification end has a number of instances running stably, and each instance is assigned its own unique identification end port; the application end initializes the global variable instance_info_dict to store all instance information, and then uses the apscheduler scheduled task framework to start the BlockingScheduler scheduler, sets the interval mode to execute every 30 seconds, and iterates and updates the global variable instance_info_dict regularly to reflect the status of the instance running device in each period;

[0053] The main process uses a multi-threaded parallel approach to interactively manage the device of this instance a, and uses the get method to request and call the get_device_code interface of each instance identification end respectively; if the interface call is successful, the information instance_info of the instance at the current moment identification end is output, including the id of the current instance and the device code device_code currently being used; at the same time, the instance id_0 and device code device_code_0 under a certain instance in the application end instance information variable instance_info_dict are obtained, indicating the instance id and device code of the last scheduled task. If the current instance id is different from the last instance id_0 when calling the same interface, it means that the instance system encounters an unknown exception and causes the system to restart. At this time, the use status status of the device code device_code_0 corresponding to the last instance id before the instance restart needs to be updated to 0 to avoid the batch of device numbers being unable to be updated to the hang-up state at the identification end due to unknown exceptions, resulting in a long period of inability to be used in rotation. Finally, update the id and device code of the corresponding instance in the instance information variable instance_info_dict on the application side to the latest; if the device code being used by the current instance is different from the device code stored in the last task, it means that the application has captured a device code change in a certain instance on the identification side due to an abnormal connection error during the rtsp identification process, or the intelligent round-robin reasoning mechanism is turned on. At this time, it is necessary to check whether the usage status of the device code being used by the current instance is successfully updated to 1, and check whether the usage status of the device code stored in the last task is successfully updated to 0, otherwise the application needs to re-update the device code usage status to the correct status. Finally, update the id and device code of the corresponding instance in the instance information variable on the application side to the latest; if the interface call fails, it means that the instance corresponding to the interface is not enabled, or the instance system is captured to be in a restarting state for unknown reasons; if the instance information variable on the application side contains the prior instance id of the interface, it is necessary to check and ensure that the usage status status of the device code corresponding to the prior instance id is successfully updated to 0;

[0054] At the end of each round of scheduled tasks, the application side outputs the summary information of the current instance information variables, namely the total number of instances, the number of currently running instances, the number of instances being restarted, the code of the currently running device, and the code of the device that needs to be restored. Through the above identification end and application end multi-instance interactive device management interface, the dynamic management of the use status of all monitoring devices is realized, ensuring the accuracy and timeliness of real-time changes in the status of each device.

[0055] 4. Intelligent retry strategy

[0056] An intelligent reconnection algorithm based on increasing retry intervals is designed. If the initial query fails to obtain any available RTSP address or the rtsp connection is abnormally disconnected during the model inference process, the retry mechanism is triggered. The retry process follows the following rules: (1) Maximum number of retries to prevent infinite loops; (2) Dynamic retry interval, each retry interval increases exponentially to reduce frequent requests for external resources; (3) Retry will continue until at least one available RTSP address is successfully obtained or the maximum number of retries is reached.

[0057] In this embodiment, in step S3, an intelligent round-robin reasoning mechanism is established to efficiently utilize limited resources and ensure the continuous and stable operation of the monitoring system; including a timer system, which is responsible for monitoring the usage time of each batch of RTSP devices currently allocated for reasoning. When a threshold is reached, a resource reset signal will be triggered. After capturing the reset signal, "start round-robin for the next batch of devices" immediately.

[0058] Specifically, the reset signal thrown not only marks the end of the current inference task, but also serves as a trigger for starting the retry mechanism mentioned above. After the retry mechanism is triggered, the next batch of available devices can be queried to continue using the inference service.

[0059] In this embodiment, a resnet-based picture anomaly classification model is established in step S4. The model is a picture anomaly classification model based on the ResNet residual network, which realizes preprocessing data and optimizing the model training process. It can process video streams in real time and quickly classify each frame or key frame for anomalies to eliminate abnormal video frames caused by network transmission jams and camera blur, ensuring that only normal and clear video frames are included in subsequent data collection and water accumulation analysis processes.

[0060] In this embodiment, the water accumulation segmentation model in step S5 is based on an improved version of the YOLOv8 instance segmentation model, and its training includes the following steps:

[0061] A1: Data collection: Video data is collected through surveillance cameras installed on urban roads. The cameras must be installed at a suitable height and angle and have night vision function to ensure all-weather monitoring effects. The collected video data is transmitted to the data processing center in real time through the network for analysis;

[0062] A2: Data preprocessing: Perform preprocessing operations such as frame extraction, denoising, and color correction on the collected video data to ensure the quality and consistency of the input data. After the video frames are converted into image sequences, they are input into the YOLOv8 model for further processing;

[0063] A3: Model training and optimization: Build high-quality training and test sets. These data sets include images of waterlogging in various scenarios, covering different weather conditions, lighting changes, and camera angles. Use labeled data to train the YOLOv8 model and continuously tune the model parameters to improve its detection accuracy and stability for waterlogged areas and water level gauges.

[0064] In this embodiment, the process of high-precision real-time monitoring of urban road waterlogging areas and water level gauges by the waterlogging segmentation model established in step S5 is as follows:

[0065] B1: The video frames are processed in real time by optimizing the improved YOLOv8 instance segmentation model, the waterlogged areas are identified and segmented, and the area and location of the waterlogged areas are calculated using image processing technology to determine the scope of the waterlogged areas.

[0066] B2: The optimized and improved YOLOv8 instance segmentation model is used to identify different colors on the ruler, including green, yellow, and red areas, and determine their positions and sizes. The depth of the accumulated water is calculated by analyzing the height ratio of the color areas.

[0067] B3: In the scenario where there are multiple water level scales, the optimized and improved YOLOv8 instance segmentation model identifies all scales, and determines the coordinates of the scales and the relative positions and heights between the scales through geometric analysis. Based on the recognition results of each scale, the water depth is comprehensively calculated through a weighted average algorithm;

[0068] B4: When the physical ruler is blocked or invisible for a long time, use a virtual ruler to determine the depth of water.

[0069] Specifically, the calculation of the water depth in steps B2, B3, and B4 is based on the analysis of the coverage of the color area of ​​the water level gauge, and is implemented in detail through the following steps:

[0070] 1. Scale coverage judgment: By analyzing the water level scale color area in the real-time video frame, it is judged whether the water covers the scale. The specific method is to compare the actual height of each color area in the current frame with the height difference of the preset scale color area. If the actual height of a color area is significantly lower than the preset height, it means that the area is covered by water.

[0071] 2. Calculation of coverage: For the color area covered by water, further calculate its coverage. The specific method is to calculate the proportion of the covered area of ​​the color area to the total area. By analyzing the coverage of each color area, the specific height of the water can be determined. For example, if the green area is completely covered and the yellow area is partially covered, it can be determined that the depth of the water is between 15 cm and 30 cm. According to the coverage of the yellow area, the depth of the water is further accurately calculated. For example, if the water covers half of the yellow area, the depth of the water is about 22.5 cm.

[0072] 3. Depth calculation formula: Comprehensively analyze the coordinates, area and color changes of the water level scale to calculate the depth of the accumulated water. Assume that the heights of the green, yellow and red areas are (h g ,h y ,h r ), according to the proportion of the covered part (P g ,P y ,P r ), the formula for calculating the water depth d is as follows:

[0073] d=P g ·h g +P y ·h y +P r ·h r

[0074] Among them, (P g ,P y ,P r ) is the proportion of the covered part, (h g ,h y ,h r ) is the height of each color area.

[0075] In this embodiment, in step S6, a data collection strategy is established to collect data from the monitoring equipment currently in use. Regardless of whether the equipment detects water accumulation in real time, it is set to automatically capture and save the original image frame of the current camera to a dedicated storage server every 10 minutes.

[0076] Specifically, this periodic data collection process not only reflects the actual scenarios in different time periods and environmental conditions, but also covers various situations of the presence or absence of waterlogging, providing rich and diverse data resources for subsequent waterlogging detection models, which can effectively enhance the generalization ability and accuracy of waterlogging detection models.

[0077] The waterlogging event alarm strategy established in step S7 has an alarm process of starting waterlogging, continuing waterlogging and ending waterlogging; its alarm method depends on the above-mentioned model reasoning results and event alarm timer. In each round-robin reasoning device, a dedicated event alarm timer is assigned to each device code. The timer records the corresponding device code, the last time waterlogging was found, the last time waterlogging was not found, whether the current device confirms the discovery of waterlogging, the number of missed detections during continuous waterlogging, the number of false waterlogging detections during no waterlogging, the number of event reasoning times, whether there is a flag for an unfinished waterlogging event, and the current waterlogging event number information. If it is found in the database waterlogging event table that the device has an event with a start time but no end time value, the flag of the unfinished waterlogging event is initialized to True, the current event number is the event number of the unfinished waterlogging event, and the waterlogging records found before the current event ends are all the tracks of the event; otherwise, the flag for the unfinished waterlogging event is False, a new event number is created with the current device and timestamp combination, and a new waterlogging event is started to be recorded.

[0078] Specifically, the conditions for the beginning, continued and ending of waterlogging are as follows:

[0079] 1. Start water accumulation conditions

[0080] When detecting water accumulation on a device, first initialize the timer and set the current device to a non-water accumulation state, that is, is_water = 0. In the non-water accumulation state, if no water accumulation is detected in the video stream, the reasoning will continue. Once water accumulation is detected in a frame of the video stream, the start time of the water accumulation event to be generated is recorded as the current time, and a 10-minute observation period is set. During this period, if water accumulation is continuously detected in the video frame within the fault tolerance range, the water accumulation state is_water = 1 is updated at the end of the observation period, indicating that the current device has confirmed that a water accumulation event has been found. If the current device does not have an unended water accumulation event, that is, is_event_no_end = 0, a new water accumulation event is recorded, and the current water accumulation event number event_id is generated to record the current water accumulation event trajectory.

[0081] During the observation period, a fault-tolerance mechanism is set. During the observation period, the number of inferences infer_num is recorded for each inference. If a missed detection is found (i.e., actual water accumulation is not recognized by the system), the number of missed detections water_omit is recorded, and the proportion of missed detections to the number of inferences is calculated. When the missed detection rate reaches 20%, the scene under the device is considered to be in an unreliable state of water accumulation. The start time of the water accumulation event to be generated and the new round of observation period are reset when water accumulation is found next time to prevent missed detection of water accumulation due to uncontrollable factors such as pedestrians and car occlusion, thereby ensuring the accuracy of water accumulation event judgment.

[0082] Once the start of water accumulation event is generated, the water accumulation screen found at the end of the observation period is taken as the start of water accumulation screen. The water accumulation detection contour map is drawn by performing contour detection on the mask field of the detection result, and uploaded to the corresponding position of the minio storage for viewing; at the same time, the water accumulation depth of the current device is obtained through the water accumulation depth recognition model, and the event information including event number event_id, occurrence time event_time, device number device_code, device name device_name, device region device_region_name, water accumulation depth depth and water accumulation snapshot image path img_path are sorted out, and inserted into the corresponding fields of the alarm event information table - alarm_event and the alarm event capture record - alarm_event_capture, and the message is sent through the RockectMQ message queue. The client will receive the message response in time, find out the water accumulation at the water accumulation point in time, and take rapid and effective defense measures for the current point.

[0083] 2. Continuous water accumulation conditions

[0084] When the device hangs up and re-circulates to a certain device, the timer bound to the current device will be reinitialized. If the above conditions for water accumulation are met during the observation period, and the current device has an unfinished water accumulation event is_event_no_end, and the unfinished water accumulation event number event_id is obtained, it means that the current device has found water accumulation and is in a continuous water accumulation state. At this time, you need to upload the current water accumulation contour map to minio, and insert the water accumulation information into the corresponding field of the alarm event capture record-alarm_event_capture.

[0085] During the cycle period when the system is in continuous operation and the equipment is not changed, if the above conditions for water accumulation have been met and is_water=1, the timer for continuous water accumulation will be initialized, and the water accumulation snapshot interval will be set. If the water accumulation snapshot interval is reached during the is_water=1 state, the current water accumulation contour map needs to be uploaded to minio, and the water accumulation information needs to be inserted into the corresponding field of the alarm event capture record-alarm_event_capture to ensure detailed tracking and backtracking of the entire process of the water accumulation event.

[0086] 3. End the waterlogging condition

[0087] When is_water=1 in the continuous water accumulation state or is_event_no_end=1 is found in the current device, if the video stream can continuously detect water accumulation, the reasoning will continue and the water accumulation track will be recorded according to the capture interval. Once a frame of the video stream does not detect water accumulation, the start time of the water accumulation event to be ended is recorded as the current time, and a 10-minute observation period is set. During this period, if the video frame does not detect water accumulation continuously within the fault tolerance range, the end water accumulation state is_water=0 is updated at the end of the observation period, indicating that the water accumulation event of the current device has ended.

[0088] Similarly, a fault-tolerant mechanism is set during the observation period. During the observation period, the number of inferences infer_num is recorded for each inference. If a false detection is found (i.e., there is no water accumulation but the system falsely reports water accumulation), the number of false detections water_wrong is recorded, and the proportion of false detections to the number of inferences is calculated. When the missed detection rate reaches 20%, the scene under the device is considered to be unreliable for ending the water accumulation state. The start time of the water accumulation event to be ended and a new round of observation period are reset when no water accumulation is detected next time.

[0089] Once the end of waterlogging event is generated, the end of waterlogging screen found at the end of the observation period is used as the end of waterlogging screen for this event, and the original screen is uploaded to the corresponding location of the minio storage for viewing; at the same time, the event information including event number event_id, occurrence time event_time, device number device_code, device name device_name, device region device_region_name, waterlogging depth depth and waterlogging snapshot image path img_path are sorted out and inserted into the corresponding field of the alarm event information table - alarm_event, and the end of waterlogging message is sent through the RockectMQ message queue. The client will receive the message response in time, indicating that the current point has receded and there is no need to arrange personnel to deal with it on site.

[0090] The present invention has the following effects:

[0091] Under the condition of limited hardware resources, it can effectively deal with adverse factors such as network fluctuations and equipment failures, realize effective monitoring of large-scale camera networks, and at the same time ensure the continuity and stability of reasoning services, reduce the risk of monitoring failure due to connection problems, avoid unnecessary consumption of resources, and improve the overall performance of the system.

[0092] A high-precision YOLOv8 model is trained for waterlogging area segmentation. At the same time, through refined state transition logic and fault-tolerant mechanism, combined with real-time video stream analysis and regular data recording, accurate detection, timely warning and full-process tracking of urban waterlogging events are achieved, which improves the accuracy and reliability of monitoring and alarming in urban waterlogging areas, and provides strong technical support for urban flood prevention and disaster reduction work.

[0093] Finally, it should be noted that those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. A method for monitoring and warning urban waterlogging based on a dynamic interactive device management mechanism, characterized in that: The following steps are involved: S1: Establish a pgsql database to efficiently manage the equipment information, alarm event information, and trajectory information of urban waterlogging; S2: Establish a dynamic device management mechanism to address system instability issues caused by frequent video stream interruptions or inability to obtain rtsp addresses; S3: Establish an intelligent round-robin reasoning mechanism to address the problem of limited hardware resources in large-scale video surveillance; S4: Establish a resnet-based image anomaly classification model to ensure that normal surveillance images can be accurately captured; S5: Establish a waterlogging segmentation model to achieve high-precision real-time monitoring of urban road waterlogging areas and water level gauges; S6: Establish a data collection strategy to collect data from each monitoring device currently in use; S7: Establish a waterlogging incident warning strategy to achieve timely early warning.

2. According to claim 1, a method for monitoring and warning urban waterlogging based on a dynamic interactive device management mechanism is characterized in that: The core of the dynamic device management mechanism described in step S2 is that when no available rtsp address is currently obtained, any device connection interruption exception is captured, or the system is interrupted and restarted due to heavy system load, it can quickly and automatically switch to the next group of available devices for continued identification, and update the relevant fields of the database to efficiently manage the device status.

3. The urban waterlogging monitoring and alarm method based on the dynamic interactive device management mechanism according to claim 2 is characterized in that: In step S3, an intelligent round-robin reasoning mechanism is established to efficiently utilize limited resources and ensure the continuous and stable operation of the monitoring system; including a timer system, which is responsible for monitoring the usage time of each batch of RTSP devices currently allocated for reasoning. When a threshold is reached, a resource reset signal will be triggered. After capturing the reset signal, "the next batch of devices will be started in round-robin" immediately.

4. The urban waterlogging monitoring and alarm method based on a dynamic interactive device management mechanism according to claim 3 is characterized in that: In step S4, a resnet-based picture anomaly classification model is established. The model is a picture anomaly classification model based on the ResNet residual network, which realizes preprocessing data and optimizing the model training process. It can process video streams in real time and quickly classify each frame or key frame for anomalies to exclude abnormal video frames caused by network transmission jams and camera blur, ensuring that only normal and clear video frames are included in the subsequent data collection and water accumulation analysis process.

5. The urban waterlogging monitoring and alarm method based on dynamic interactive device management mechanism according to claim 4 is characterized in that: The water accumulation segmentation model in step S5 is based on an improved version of the YOLOv8 instance segmentation model, and its training includes the following steps: A1: Data collection: Video data is collected through surveillance cameras installed on urban roads. The cameras must be installed at a suitable height and angle and have night vision function to ensure all-weather monitoring effects. The collected video data is transmitted to the data processing center in real time through the network for analysis; A2: Data preprocessing: Perform preprocessing operations such as frame extraction, denoising, and color correction on the collected video data to ensure the quality and consistency of the input data. After the video frames are converted into image sequences, they are input into the YOLOv8 model for further processing; A3: Model training and optimization: Build high-quality training and test sets. These data sets include images of waterlogging in various scenarios, covering different weather conditions, lighting changes, and camera angles. Use labeled data to train the YOLOv8 model and continuously tune the model parameters to improve its detection accuracy and stability for waterlogged areas and water level gauges.

6. The urban waterlogging monitoring and alarm method based on dynamic interactive device management mechanism according to claim 5 is characterized in that: The process of high-precision real-time monitoring of urban road waterlogging areas and water level gauges by the waterlogging segmentation model established in step S5 is as follows: B1: The video frames are processed in real time by optimizing the improved YOLOv8 instance segmentation model, the waterlogged areas are identified and segmented, and the area and location of the waterlogged areas are calculated using image processing technology to determine the scope of the waterlogged areas. B2: The optimized and improved YOLOv8 instance segmentation model is used to identify different colors on the ruler, including green, yellow, and red areas, and determine their positions and sizes. The depth of the accumulated water is calculated by analyzing the height ratio of the color areas. B3: In the scenario where there are multiple water level scales, the optimized and improved YOLOv8 instance segmentation model identifies all scales, and determines the coordinates of the scales and the relative positions and heights between the scales through geometric analysis. Based on the recognition results of each scale, the water depth is comprehensively calculated through a weighted average algorithm; B4: When the physical ruler is blocked or invisible for a long time, use a virtual ruler to determine the depth of water.

7. The urban waterlogging monitoring and alarming method based on a dynamic interactive device management mechanism according to claim 6 is characterized in that: In step S6, a data collection strategy is established to collect data from the monitoring equipment currently in use. Regardless of whether the equipment detects water accumulation immediately, it is set to automatically capture and save the original image frame of the current camera to a dedicated storage server every 10 minutes.

8. The urban waterlogging monitoring and alarming method based on dynamic interactive device management mechanism according to claim 6 is characterized in that: The waterlogging event alarm strategy established in step S7 has an alarm process of starting waterlogging, continuing waterlogging and ending waterlogging; its alarm method depends on the above-mentioned model reasoning results and event alarm timer. In each round-robin reasoning device, a dedicated event alarm timer is assigned to each device code. The timer records the corresponding device code, the last time waterlogging was found, the last time waterlogging was not found, whether the current device confirms the discovery of waterlogging, the number of missed detections during continuous waterlogging, the number of false waterlogging detections during no waterlogging, the number of event reasoning times, whether there is a flag for an unfinished waterlogging event, and the current waterlogging event number information. If it is found in the database waterlogging event table that the device has an event with a start time but no end time value, the flag of the unfinished waterlogging event is initialized to True, the current event number is the event number of the unfinished waterlogging event, and the waterlogging records found before the current event ends are all the tracks of the event; otherwise, the flag for the unfinished waterlogging event is False, a new event number is created with the current device and timestamp combination, and a new waterlogging event is started to be recorded.

Images