A risk target early warning method and system for an MRI scene and a storage medium

Abstract

The application discloses an MRI scene-oriented risk target early warning method and system and a storage medium, and particularly relates to the technical field of safety monitoring, realizes type identification of multiple ferromagnetic dangerous articles, provides specific safety response information, and is richer in information compared with the binary judgment of the magnetic sensor scheme; a stability counter + hierarchical state machine effectively reduces the false alarm rate: a high-risk target needs to be confirmed for three frames in succession to trigger an alarm, and transient false detection is eliminated; in cooperation with a three-layer filtering pipeline, five levels of screening are performed from the original output of the model to the final alarm, and the "alarm fatigue" phenomenon is effectively avoided; a lightweight model + CPU reasoning can be run on an ordinary x86 server without a GPU acceleration card, and the hardware cost is low; three-layer filtering pipeline multi-level filtering reduces false alarms, and a ROI region can be accurately configured according to specific dangerous regions.

Description

Technical Field

[0001] This invention belongs to the field of security monitoring technology, specifically relating to a risk target early warning method, system, and storage medium for MRI scenarios. Background Technology

[0002] MRI equipment generates extremely strong static magnetic fields. When ferromagnetic objects enter this strong magnetic field, they are attracted to the magnet at high speed ("missile effect"), causing equipment damage or personal injury. Existing solutions include:

[0003] (1) Magnetic sensor solutions (such as Metrasens Ferroguard, Kopp FerrAlert): These use fluxgate sensors or Hall effect sensors to detect the presence of ferromagnetic objects. They can only make binary judgments of "present / absent" and cannot identify the specific type of object (such as gas cylinders, wheelchairs, hospital beds, etc.), and cannot provide targeted safety response measures.

[0004] (2) Traditional video surveillance solutions (such as Philips CN105745922B): Video cameras are installed at the entrance of the MRI room, and objects and people are classified using traditional image recognition technology (technical level in 2013). Deep learning object detection technology is not used, resulting in limited recognition accuracy and robustness.

[0005] (3) In recent years, single-stage deep learning target detection technology, represented by the YOLO (You Only Look Once) series, has been widely used in industrial inspection, traffic monitoring and other fields, and has the characteristics of fast inference speed and flexible deployment. However, existing deep learning target detection solutions have not been systematically integrated for the special needs of MRI scenarios, and lack a complete integration solution with ferromagnetic hazard classification, multi-frame temporal stability verification, hierarchical alarm state machine and multi-source data linkage.

[0006] All of the above solutions lack the ability to link multiple data sources and cannot make a combined judgment on alarm results from multiple data sources such as ferromagnetic detection, environmental monitoring (temperature / humidity / oxygen concentration), and AI visual detection.

[0007] The existing technology has at least the following drawbacks:

[0008] (1) The magnetic sensor solution can only make binary judgments, cannot identify the type of item, and cannot provide targeted security responses.

[0009] (2) There is no graded alarm mechanism. All ferromagnetic objects trigger the same alarm, resulting in the phenomenon of "alarm fatigue".

[0010] (3) There is a lack of false alarm suppression mechanism. The single frame detection result directly triggers the alarm, resulting in a high false alarm rate.

[0011] (4) It only covers the doorway area and cannot accurately monitor specific dangerous areas indoors.

[0012] (5) It is not possible to perform compound condition linkage judgment on alarm results from multiple data sources (ferromagnetic, environmental, AI). Summary of the Invention

[0013] The purpose of this invention is to provide a risk target early warning method, system, and storage medium for MRI scenarios to solve the above-mentioned problems.

[0014] To achieve the above objectives, the present invention provides the following technical solution: a risk target early warning method for MRI scenarios, comprising the following steps:

[0015] S1 (Pre-configuration of Safety Knowledge Base): A safety knowledge base is pre-established in the database. The safety knowledge base includes: (a) a hazardous material category-level mapping table, which defines multiple ferromagnetic hazardous material target categories (including but not limited to gas cylinders, trolleys, wheelchairs, chairs, hospital beds, stretchers) and their corresponding hazard levels. The hazard levels are divided into three levels: high (high risk), medium (medium risk), and low (low risk); (b) region of interest configuration, which defines the normalized coordinates (x, y, w, h) of a rectangular monitoring area for each camera, with the coordinate values ​​ranging from [0, 1]; (c) environmental monitoring threshold configuration, which configures three nested alarm intervals for environmental indicators such as oxygen concentration, temperature, and humidity, from the outside in: high alarm interval [highL, highH], medium alarm interval [midL, midH], and low alarm interval [lowL, lowH]; (d) multi-source linkage rules, which define the composite triggering conditions, operators, and result levels between multiple alarm sources.

[0016] S2 (Video Data Acquisition): Connects to a network camera in the MRI examination room via Real-time Streaming Protocol (RTSP) to acquire real-time video streams; A separate acquisition process continuously decodes video frames and adopts a "keep only the latest frame" strategy—each decoded frame immediately overwrites the internal frame variable, there is no queue buffer, and the inference thread always obtains the latest available frame, avoiding frame accumulation that leads to latency accumulation;

[0017] S3 (Image Preprocessing): Perform the following preprocessing operations sequentially on the acquired video frames to convert the original image into a normalized input tensor acceptable to the deep learning model: (a) Image scaling—scale the original video frame from the acquisition resolution (e.g., 1920×1080 pixels) to the model input size of 640×640 pixels; (b) Color space conversion—convert the image from the BGR color space to the RGB color space; (c) Pixel value normalization—divide the integer grayscale value of each pixel by 255.0, mapping it from the integer range of [0, 255] to the floating-point range of [0.0, 1.0]; (d) Dimension transformation—convert the image data from a height × width × channel (HWC) arrangement to a channel × height × width (CHW) arrangement, and add a batch dimension at the front to obtain a four-dimensional floating-point tensor with the shape (1, 3, 640, 640).

[0018] S4 (AI Object Detection Inference): The standardized tensor obtained in step S3 is input into a pre-trained lightweight deep learning object detection model based on the existing YOLO architecture (the YOLO architecture is a well-known single-stage object detection framework in this field), and real-time inference is performed on the CPU using the ONNX Runtime inference engine; the object detection model adopts a single-stage detection architecture, and its detection and classification principles include: (a) Feature extraction—through a backbone network composed of multi-layer convolutional neural networks, layer-by-layer convolution and downsampling operations are performed on the input image to sequentially extract multi-level feature maps from low-level texture edge features to high-level semantic features, with the spatial resolution of each layer of feature maps decreasing while the channel depth increases; (b) Multi-scale feature fusion—through a feature pyramid network, feature maps of different spatial resolutions are fused across layers. High-resolution feature maps are good at detecting small-sized targets (such as gas cylinders), while low-resolution feature maps are good at detecting large-sized targets (such as hospital beds and wheelchairs). After fusion, the model can simultaneously detect targets of different sizes in the same inference; (c) Joint prediction of classification and localization—The detection head simultaneously predicts two sets of parameters for each spatial grid location on multiple fused feature maps: four location parameters (representing the spatial location and size of the target in the image) including the center coordinates (cx, cy), width (w), and height (h) of the bounding box, and C classification parameters (C being the number of dangerous item categories preset in step S1). Each category score represents the probability that a target of the corresponding category exists at that grid location; (d) Category determination—For each candidate detection box, the maximum value among the C category confidence scores is taken as the comprehensive confidence of the box, and the category index corresponding to the maximum value is taken as the predicted category of the target, thereby realizing the automatic classification and identification of ferromagnetic dangerous items; (e) Model output—The final output is a three-dimensional tensor with shape (1, 4+C, N), where N is the total number of all candidate detection boxes, including the location parameters and classification parameters of each candidate box;

[0019] S5 (Post-processing and multi-level filtering of detection results): Perform the following post-processing and filtering operations sequentially on the original model output from step S4: (a) Output parsing—transpose the model output from (1, 4+C, N) to a (N, 4+C) matrix, separate the first 4 columns as bounding box coordinates (cx, cy, w, h), and the last C columns as scores for each category. Take the maximum category score for each candidate box as the confidence of the box, and take the category index corresponding to the maximum value as the predicted category of the box; (b) Confidence threshold filtering—filter candidate boxes with confidence scores lower than the preset threshold (default value 0.5, this value is determined by analyzing the precision-recall curve on the actual MRI scene test set, which is the best balance point between precision and recall, and can be adjusted within the range of 0.3 to 0.7 according to the actual scene), and eliminate noise detections with low confidence; (c) Coordinate format conversion—convert the center point + width and height format to the top left corner + bottom right corner format: x1=cx-w / 2, y1=cy-h / 2, x2=cx+w / 2, y2=cy+h / 2; (d) Non-maximum suppression (NMS) - Sort all candidate boxes in descending order of confidence, select the highest confidence box to keep, calculate its intersection-union ratio (IoU) with all remaining boxes = intersection area / (area_i+area_j-intersection area+ε), suppress overlapping boxes with IoU exceeding a preset threshold (e.g., 0.45), repeat this process until candidate boxes are exhausted, eliminating duplicate detection of the same target; (e) Coordinate normalization - Divide the pixel coordinates by the model input size 640, map to the range [0, 1] and crop to the legal interval; (f) ROI region filtering - Calculate the center point of each detection box cx=bbox.x+bbox.w / 2, cy=bbox.y+bbox.h / 2, determine whether region.x≤cx≤region.x+region.w and region.y≤cy≤region.y+region.h are true, and only retain targets whose center point falls within the preset region of interest in step S1; (g) Safety knowledge base mapping filter - query the safety knowledge base established in step S1, and only retain targets whose categories have a danger level mapping in the knowledge base. Unknown categories are directly discarded and no subsequent alarm process is triggered;

[0020] S6 (Risk Level Mapping): For all targets filtered in step S5, the detection category of each target is mapped to the corresponding danger level (high, medium, or low) according to the category-level mapping relationship in the safety knowledge base in step S1; the highest danger level among all detected targets in the current frame is taken as the overall risk level of the frame.

[0021] S7 (Sequence Stability Verification): Perform debounce processing on the detection results of multiple consecutive frames through a stability counter, adopting a mutually exclusive dual-counter mechanism — the high-risk counter (highHits) and the medium-risk counter (mediumHits) cannot be incremented simultaneously, and one counter is reset to zero when the other is incremented; when the current frame's comprehensive risk is high, highHits is incremented by 1 and mediumHits is reset to zero; when the comprehensive risk is medium, mediumHits is incremented by 1 and highHits is reset to zero; when the comprehensive risk is low or no target exists, both counters are reset to zero; a high-risk target needs to be detected for N consecutive frames (for example, N=3, corresponding to about 1.5 seconds) to be upgraded to an alarm state;

[0022] S8 (Hierarchical Alarm Decision-Making): Implement hierarchical alarm decision-making through a polymorphic state machine, where the state machine includes six states: offline, idle, detecting, attention, alarm, and timeout; perform state transition according to the stability verification result of step S7: transition to the alarm state when highHits ≥ N, transition to the attention state when highHits > 0 but < N, transition to the attention state when mediumHits ≥ N, and transition to the detecting state when mediumHits > 0 but < N; adopt a dual-timer architecture — the polling timer periodically acquires detection results, and the independent watchdog timer monitors timeout, with the two timers being independent of each other;

[0023] S9 (Multi-source Linked Alarm): For the risk grading result generated in step S6, perform multi-source linked alarm in combination with other data sources, including the following sub-steps: S9.1 Define 5 independent alarm sources: ferromagnetic detection, oxygen concentration, temperature, humidity, and AI recognition, each of which independently evaluates a four-level risk level (0 - Normal / 1 - Low / 2 - Medium / 3 - High); S9.2 The environmental indicators are evaluated using the three-layer nested interval thresholds configured in step S1, and the high / medium / low alarm intervals are checked sequentially from the outside to the inside, with each level including two boundary values of upper limit and lower limit; S9.3 For the ferromagnetic detection source, take the maximum value of the LED color levels of the left and right detectors (red→3, orange→2, yellow / blue→1, others→0); S9.4 Perform multi-condition AND composite matching through the linkage rules configured in step S1, and each condition supports two operators of "≥" and "="; S9.5 After the rule is triggered, an alarm event is generated and asynchronously written into the database; a 5-second debounce mechanism is adopted after the alarm disappears to prevent frequent on-off caused by sensor data fluctuation; S9.6 Automatically switch the frequency, waveform and rhythm of the sound alarm according to the alarm level (low risk: 880Hz sine, medium risk: 660Hz square, high risk: 440+880Hz sawtooth dual tone).

[0024] Preferably, the S8 uses a dual-timer architecture to achieve real-time monitoring: a polling timer periodically obtains the detection results, and an independent watchdog timer monitors for timeouts, with the two being independent of each other.

[0025] Preferably, in S5, the ROI region filtering adopts the detection box center point determination method, calculates the coordinates of the detection box center point, and determines whether the center point falls within the preset rectangular area.

[0026] Preferably, the stability counter in S7 adopts a mutually exclusive dual-counter mechanism, where the high-risk counter and the medium-risk counter cannot be incremented simultaneously, and when one is incremented, the other is reset to zero.

[0027] Preferably, the linkage rules in S9 support an "automatic" result level mode. When the result level of a rule is set to automatic, the system automatically takes the highest level among all triggering conditions as the alarm level.

[0028] An MRI examination room security monitoring system includes:

[0029] (1) Multi-camera dynamic manager: adopts Manager-Worker architecture, periodically polls the configuration source to automatically add, delete and update Workers, and supports hot updates of ROI areas;

[0030] (2) Frame capturer: An independent process captures video streams through a video stream transmission protocol and adopts a "only keep the latest frame" strategy protected by inter-process pipe communication;

[0031] (3) AI Inference Engine: Real-time inference based on a lightweight inference engine, including nonmaximum suppression algorithm and three-layer filtering pipeline;

[0032] (4) Alarm decision engine: includes stability counter, polymorphic state machine and dual timers (polling + watchdog);

[0033] (5) AI detection result overlay display layer: Convert the normalized coordinates into percentage coordinates for positioning and overlay them on the real-time video stream.

[0034] Preferably, the video stream is transmitted via the WebRTC WHEP (WebRTC-HTTP Egress Protocol) protocol, the PeerConnection connection resources are shared using a reference counting mechanism, and a Track hot-swap mechanism is used to achieve seamless reconnection after disconnection.

[0035] Preferably, the AI ​​model supports dynamic updates without stopping the inference service.

[0036] Preferably, it supports unified management of multiple locations, allowing different MRI examination rooms to share the same monitoring platform.

[0037] Preferably, a precise tick inference loop is used, with a monotonic clock recording the cycle start point and the precise sleep difference after deducting the inference time is used to ensure a constant inference cycle.

[0038] The frame acquisition adopts the "only keep the latest frame" strategy. Each time a frame is decoded, the internal variables are immediately overwritten. There is no queue buffer, and the inference thread always obtains the latest available frame.

[0039] All workers share the same YOLO detector instance and database writer instance, reducing memory usage and supporting horizontal scaling of multiple cameras.

[0040] It supports hot updates of ROI (Region of Interest), and detects changes by periodically polling the configuration source through the Manager and calling the region update interface of the Worker without restarting the inference thread;

[0041] A computer-readable storage medium, specifically a memory, having a computer program thereon storing the method.

[0042] The technical effects and advantages of this invention are as follows: 1. It enables the identification of various types of ferromagnetic hazardous materials and provides specific safety response information. Compared with the binary judgment of magnetic sensor solutions, it provides richer information.

[0043] 2. Stability counter + hierarchical state machine effectively reduce false alarm rate: High-risk targets require confirmation for 3 consecutive frames (about 1.5 seconds) before triggering an alarm, eliminating instantaneous false detections; in conjunction with a three-layer filtering pipeline, the model's original output goes through 5 levels of filtering from the initial output to the final alarm, effectively avoiding the phenomenon of "alarm fatigue".

[0044] 3. Lightweight model + CPU inference: The model input size is 640×640 pixels. It uses ONNX RuntimeCPUExecutionProvider for inference, with an inference cycle of 0.5 seconds / frame (2 FPS). It can run on ordinary x86 servers without the need for a GPU accelerator card, resulting in low hardware costs.

[0045] 4. Three-layer filtration pipeline (YOLO→ROI→Safety Knowledge Base) multi-level filtration reduces false alarms, and ROI areas can be precisely configured for specific hazardous areas.

[0046] 5. The Manager-Worker architecture supports hot-swapping of cameras and hot updates of configurations: the configuration synchronization cycle is 10 seconds, and the addition or deletion of cameras takes effect automatically within 10 seconds; hot updates of ROI areas do not require restarting the inference thread, simplifying operation and maintenance.

[0047] 6. Dual timer architecture ensures timely detection of system faults: The watchdog timer checks independently every 250ms. If no response is received within 5000ms, a timeout state is triggered, and the fault detection delay does not exceed 5.25 seconds.

[0048] 7. Precise beat inference ensures stable detection frequency, unaffected by fluctuations in hardware performance.

[0049] 8. The multi-source linkage rule engine enables composite conditional alarms from 5 data sources, which are flexibly configurable to meet the personalized security strategy needs of different hospitals.

[0050] 9. A 5-second de-jitter mechanism avoids frequent alarms caused by sensor data fluctuations: after an alarm disappears, it waits 5000ms before confirming that it has been cleared. The detection data is retained for 24 hours and then automatically cleared, taking into account both audit traceability and storage space.

[0051] 10. The system supports independent inference for each camera, and each worker shares the same YOLO detector instance and database writer instance, reducing memory usage and supporting horizontal scaling of multiple cameras. Attached Figure Description

[0052] Figure 1 This is an overview diagram of the system architecture of the present invention;

[0053] Figure 2 This is a flowchart of the AI ​​target detection and three-layer filtering pipeline of the present invention;

[0054] Figure 3 This is a flowchart of the stability counter dejitter algorithm of the present invention;

[0055] Figure 4 This is the state transition diagram of the six-state machine of the present invention;

[0056] Figure 5 This is a diagram of the Manager-Worker multi-camera management architecture of the present invention;

[0057] Figure 6 This is a block diagram of the multi-source linkage alarm engine of the present invention. Detailed Implementation

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

[0059] This invention provides, for example Figures 1-6The following is an example of a risk target early warning method, system, and storage medium for MRI scenarios:

[0060] Example 1: AI-based target detection and hierarchical alarm;

[0061] System architecture;

[0062] like Figure 1 As shown, the system architecture of this invention is divided into four layers:

[0063] - AI Inference Service Layer: Acquires video streams via RTSP, executes ONNX model inference, and writes the detection results into the database after three layers of filtering;

[0064] - Web service layer: Provides a REST API to read detection results and perform coordinate normalization and risk classification;

[0065] - Front-end alarm layer: Polls to obtain detection results, performs stability counting and state machine decision-making, and displays the detection box overlaid;

[0066] - Multi-source linkage layer: rule engine + threshold evaluation + de-jitter lifecycle management + audible alarm;

[0067] Security knowledge base pre-configured;

[0068] Before system deployment, the following security knowledge base must be pre-configured in the database:

[0069] (1) Hazardous Goods Category-Level Mapping Table: Identifiable ferromagnetic hazardous goods categories are defined in the system dictionary table (sys_standernote, dictionary type ZDLX='I01'). Each category contains a unique category number (DMZ) and name (DMMS). During AI model training, each category is assigned an integer index (class_id) starting from 0. The system converts the model's class_id into a database dictionary number through a fixed mapping table: class_id 0=Cylinder (DMZ 17), 1=Trolley (DMZ20), 2=Wheelchair (DMZ 21), 3=Chair (DMZ 16), 4=Hospital Bed (DMZ 15), 5=Stretcher (DMZ 22). The backend risk classification module maps each category number to the corresponding basic hazard level (high / medium / low) by querying the dictionary table.

[0070] (2) Camera AI Configuration Table (EQP_CAMERA_AI_CONFIG): Configures whether AI detection is enabled (ai_enabled field) and the normalized coordinates of the region of interest (region_x, region_y, region_w, region_h) for each camera. The coordinate values ​​range from [0, 1], representing the proportional position relative to the width and height of the screen. The AI ​​inference service periodically polls this configuration table to achieve hot updates of the ROI region.

[0071] (3) Environmental monitoring threshold configuration: Three nested interval thresholds are configured for oxygen concentration, temperature and humidity respectively. The interval model is [highL, highH] ⊃ [midL, midH] ⊃ [lowL, lowH]. The outermost layer is the high alarm interval (widest) and the innermost layer is the low alarm interval (narrowest). The state is normal if it falls within the innermost interval.

[0072] (4) Multi-source linkage rule configuration: Each rule contains several triggering conditions (alarm source + operator + level threshold) and a result level. All conditions are ANDed. Supports two operators: "≥" (greater than or equal to) and "=" (exactly equal to). The result level can be set to a specific level (1 / 2 / 3) or "automatic" (take the maximum value of the current level of each triggering source).

[0073] Object detection model:

[0074] This invention employs a single-stage object detection model based on the YOLO (You Only Look Once) architecture. Unlike two-stage detectors (such as Faster R-CNN, which require generating candidate regions before classification), the YOLO model completes object localization and category classification simultaneously in a single forward propagation, resulting in higher inference speed and suitability for real-time monitoring scenarios.

[0075] The model structure consists of three core components: (1) Backbone: composed of multiple convolutional layers and downsampling layers, performing layer-by-layer convolution operations on the input 640×640×3 image. The first few layers extract low-level features such as edges and textures through small-sized convolutional kernels, while the subsequent layers extract high-level semantic features such as shape and parts through a deeper network structure, ultimately generating multiple feature maps with different spatial resolutions; (2) Neck: performs cross-layer fusion of feature maps of different scales output by the backbone network in a top-down and bottom-up manner. High-resolution feature maps (such as 80×80 grids) retain spatial detail information of small targets, suitable for detecting smaller objects such as steel cylinders, while low-resolution feature maps (such as 20×20 grids) contain global semantic information of large targets, suitable for detecting large objects such as hospital beds and wheelchairs. After fusion, a single model can detect targets of different sizes simultaneously; (3) Detection Head: predicts four bounding box parameters (cx, cy, w, ...) for each grid position on each fused feature map. h) and C category confidence scores (C is the preset number of categories), the target category is determined by taking argmax from the category scores, thus achieving "one forward propagation, simultaneously outputting the position and category of all targets".

[0076] like Figure 2 As shown, a YOLO26 model was used, exported to ONNX format, and inference was performed using the ONNX RuntimeCPUExecutionProvider. The input size was 640×640 pixels. Six categories of ferromagnetic hazardous materials were retained: cylinders, carts, wheelchairs, chairs, beds, and stretchers.

[0077] Preprocessing steps: (1) Scale the original BGR image to 640×640 pixels; (2) Convert BGR to RGB color space; (3) Normalize pixel values: pixel / 255.0, map to [0.0, 1.0]; (4) Dimension transformation: HWC → CHW, add batch dimension to get (1, 3, 640, 640).

[0078] Post-processing flow: The model output shape is (1, 4+C, N), where C is the number of categories and N is the number of candidate boxes. (1) Transpose to (N, 4+C), separate the first 4 columns as coordinates (cx, cy, w, h) and the last C columns as category scores; (2) Take the highest category score for each candidate box and filter candidate boxes below the confidence threshold (0.5); (3) Coordinate format conversion: center point + width and height → top left corner + bottom right corner, i.e., x1 = cx - w / 2, y1 = cy - h / 2, x2 = cx + w / 2, y2 = cy + h / 2; (4) Perform NMS (non-maximum suppression), IoU threshold 0.45; (5) Normalize to the range [0, 1]: divide each coordinate by the input size 640 and crop to the legal range.

[0079] NMS Algorithm: A greedy NMS algorithm implemented in pure NumPy with no external dependencies. (1) Calculate the area of ​​all candidate boxes: area = (x2 - x1) × (y2 - y1); (2) Sort in descending order of confidence; (3) Greedy selection loop: keep the highest-scoring box and calculate the intersection area with the remaining boxes, IoU = inter / (area_i + area_j -inter + 1e-6); (4) Suppress overlapping boxes with IoU > threshold, repeat until candidate boxes are exhausted.

[0080] Three-layer filtering pipeline: Detection results are filtered through three layers before being written to the database. First layer: Confidence filtering + NMS. Second layer: ROI region filtering, calculating the center point of the detection box cx = bbox.x + bbox.w / 2, cy = bbox.y + bbox.h / 2, and determining whether it is within a preset rectangular area, i.e., region.x ≤ cx ≤ region.x + region.w and region.y ≤ cy ≤ region.y + region.h. Third layer: Security knowledge base mapping filtering, only retaining categories with class_id mapped to a hazard level in the security knowledge base; unknown categories do not trigger alarms.

[0081] Precise cycle control: A monotonic clock is used to achieve constant-cycle inference. `cycle_start = monotonic()`, after inference, three-layer filtering, and database write, `remaining = interval - (monotonic() - cycle_start)`. If `remaining > 0`, then `sleep(remaining)`. This ensures the inference cycle remains constant at `interval` seconds (default 0.5 seconds), unaffected by fluctuations in inference latency.

[0082] Stability counter debouncing algorithm:

[0083] like Figure 3 As shown, the system maintains two independent counters: highHits (consecutive hit count of high-risk targets) and mediumHits (consecutive hit count of medium-risk targets).

[0084] Counting rules: When the highest risk level of the current frame is determined to be high, highHits += 1, and mediumHits is reset to zero (the two are mutually exclusive); when the highest risk of the current frame is medium, mediumHits += 1, and highHits is reset to zero; when the highest risk of the current frame is low or there is no target, both counters are reset to zero.

[0085] Elevation rules (threshold N=3): highHits ≥ N → alarm; highHits < N and > 0 → attention; mediumHits ≥ N → attention; mediumHits < N and > 0 → detecting.

[0086] Six-state machine:

[0087] like Figure 4 As shown, the status definitions are: offline (AI is not enabled or there is no camera); idle (AI is online but has not found any targets to focus on); detecting (detecting, a target has been detected but the escalation threshold has not yet been reached); attention (attention, medium hit has reached the threshold or high hit has not reached the threshold); alarm (alarm, high risk target has been hit N times consecutively); timeout (timeout, more than 5000ms have passed since the last successful result acquisition).

[0088] State transition table:

[0089] - Backend offline / timeout + arbitrary risks → remain unchanged, all counters are reset to zero;

[0090] - Backend idle + any → idle, all counters are reset to zero;

[0091] - Active + null (no target) → idle, all counters are reset to zero;

[0092] - Active + high + highHits+1 ≥ N → alarm, highHits+1;

[0093] - Activity + high + highHits+1 < N → attention, highHits+1;

[0094] - active + medium + mediumHits+1 ≥ N → attention, mediumHits+1;

[0095] - active + medium + mediumHits+1 < N → detecting, mediumHits+1;

[0096] - Active + low → detecting, all counters are reset to zero;

[0097] Dual timer architecture:

[0098] Polling (specifically, a polling timer) is implemented using recursive setTimeout instead of setInterval. Each request waits 400ms after completion before initiating the next request, preventing request backlog.

[0099] Watchdog timer: Independently checks the time interval since the last successful response every 250ms. If it exceeds 5000ms, a timeout state is triggered, and the stability counter is reset to zero. Completely independent of the polling timer, it ensures timely detection of anomalies even during network congestion.

[0100] The test results are displayed in an overlay:

[0101] Coordinate transformation for overlay display: The backend normalizes pixel coordinates to the range [0, 1]: `bbox.x = clamp(round(px / 1920, 4), 0, 1), bbox.y = clamp(round(py / 1080, 4), 0, 1)`. The frontend converts the normalized coordinates to percentage coordinates for positioning: `CSS left = bbox.x × 100%, CSS top = bbox.y × 100%, CSS width = bbox.w × 100%, CSS height = bbox.h × 100%`. This method decouples the detection box positioning from the video resolution, making it suitable for display terminals of any size. Each detection box is assigned a fixed color according to its category.

[0102] Manager-Worker Multi-Camera Management:

[0103] like Figure 5 As shown, the manager polls the configuration interface data source every 10 seconds to obtain the latest camera configuration and executes three-way synchronization logic: adding (creating a worker process instance, starting the frame acquisition thread and inference loop thread), deleting (stopping the corresponding Worker and releasing resources), and updating (calling worker.update_region() to hot-update the ROI region without restarting the inference thread). All Workers share the YOLO detector instance and the database writer instance, reducing memory usage.

[0104] Low-latency frame capture:

[0105] Frame acquisition uses PyAV (FFmpeg Python binding) to connect to the RTSP stream, configured with the following low-latency parameters: fflags=nobuffer (disable input buffer), flags=low_delay (enable low-latency decoding mode), probesize=32 (minimize startup probe data size), analyzeduration=0 (skip stream format analysis phase), and stimeout=10000000 microseconds (RTSP connection timeout). A "keep only the latest frame" strategy is adopted: each decoded frame immediately overwrites internal variables, with no queue buffering. The inference thread always acquires the latest available frame to avoid frame backlog leading to latency accumulation. Automatic reconnection occurs upon disconnection, with a 5-second wait before retrying.

[0106] Example 2: Multi-source linkage alarm engine:

[0107] Three-level nested threshold evaluation:

[0108] like Figure 6As shown, a three-layer nested threshold assessment is used for environmental indicators (oxygen concentration, temperature, humidity), with the three intervals from the outside in determining the level: (1) If value < highL or value > highH → Level 3 (high alarm); (2) If value < midL or value > midH → Level 2 (medium alarm); (3) If value < lowL or value > lowH → Level 1 (low alarm); (4) If none of these conditions are met → Level 0 (normal). Interval model: [highL, highH] is the outermost (widest), [lowL, lowH] is the innermost (narrowest), and falling within the innermost layer is considered normal. Unconfigured levels are automatically skipped.

[0109] Source independent assessment:

[0110] Ferromagnetic (Ferromagnetic Detection): The maximum color level of the left and right detectors is obtained through LED color mapping (red→3, orange→2, yellow / blue→1). Oxygen Concentration / Temperature / Humidity: Custom thresholds are used for evaluation first; if no custom threshold is available, the system reverts to the device's native alarm flags. AI: Transmits external AI detection results (reserved interface).

[0111] Linkage rule matching:

[0112] The linkage rule engine performs multi-condition AND composite matching, where each condition specifies the alarm source, operator, and level. The operator >=: the current source level must be greater than or equal to the condition level to be satisfied; the operator =: the current source level must be exactly equal to the condition level to be satisfied. Example: "Ferromagnetic detection >= Medium risk AND Oxygen concentration >= Low risk → Trigger high-risk alarm".

[0113] De-jitter lifecycle management:

[0114] Dejitter lifecycle management: Add alarm: Immediately write asynchronously to the database and obtain the event ID; Continuous alarm: Remain unchanged; Alarm disappears: Start a 5-second dejitter timer; Re-triggered during dejitter: Cancel the timer and the alarm continues; If no alarm is triggered after the 5-second timer: Write the end event to the database and remove it from the active list.

[0115] Three-level frequency division sound alarm:

[0116] Three-level frequency division sound alarm: Level 1 (low risk): 880 Hz, sine wave, single playback, no repetition. Level 2 (medium risk): 660 Hz, square wave, loop playback, 1500 ms interval. Level 3 (high risk): 440→880 Hz, sawtooth wave, alternating dual tones, 800 ms interval.

[0117] Example 3: WebRTC WHEP video streaming:

[0118] WebRTC WHEP low-latency video transmission:

[0119] This embodiment describes the transmission scheme for real-time video streams from the camera to the front-end display terminal in the system. It employs the WebRTC-HTTP Egress Protocol (WHEP), shares connection resources through a reference counting mechanism, and utilizes a track hot-swap mechanism to achieve seamless reconnection after disconnection.

[0120] WHEP protocol connection establishment:

[0121] The connection establishment process is as follows: (1) The front end creates an RTCPeerConnection instance and configures the STUN (Session Traversal Utilities for NAT) server address for NAT traversal; (2) Add two Transceivers in the receiving direction (receive only) to receive video and audio tracks respectively; (3) Create a persistent MediaStream object and add the received media tracks to the object through the ontrack callback; (4) Call createOffer() to generate an SDP (Session Description Protocol) Offer; (5) Call setLocalDescription() to set the local description, trigger ICE (Interactive Connectivity Establishment) candidate address collection, and set a 10-second timeout protection; (6) Send the complete SDP Offer to the WHEP endpoint of the streaming media server via an HTTP POST request, with the URL format being http: / / {host}:{port} / {cameraCode} / whep and the Content-Type header set to application / sdp; (7) After receiving the SDP Answer returned by the server, call setRemoteDescription() to set the remote description. The WebRTC connection is then established, and the video stream begins to transmit.

[0122] Reference counting shared PeerConnection mechanism:

[0123] When multiple UI components need to play the same camera video simultaneously, the system uses a reference counting mechanism to share PeerConnection connection resources. Data Structure: A global Map is maintained (the key is the camera code `cameraCode`, and the value is the connection entry `StreamEntry`). Each entry contains an `RTCPeerConnection` instance, a persistent `MediaStream` object, a reference count `refCount`, and a reconnection timer flag. A pending Map is also maintained for concurrent request deduplication. Retrieval Process: When `getOrCreateStream(cameraCode)` is called, if the camera entry already exists in the Map, the reference count `refCount` is incremented by 1, and the existing `MediaStream` is returned directly (reusing the same WebRTC connection); if an ongoing creation Promise exists, the Promise is returned directly (concurrent deduplication); otherwise, a new WebRTC connection is created. Release Process: When `releaseStream(cameraCode)` is called, the reference count is decremented by 1. When the reference count drops to 0, the `RTCPeerConnection` is closed, the reconnection timer is cleared, the entry is removed from the Map, and all connection resources are released. This mechanism ensures that only one WebRTC connection is maintained, regardless of how many components reference the same camera.

[0124] Track hot-swap seamless reconnection after disconnection:

[0125] When the WebRTC connection is lost, a seamless reconnection is achieved through the Track hot-swap mechanism, requiring no state updates or re-rendering of the front-end playback component. Disconnection detection: Listen for the connectionstatechange event of RTCPeerConnection, and trigger the reconnection process when the connection state changes to failed or closed. Reconnection process: (1) Close the old RTCPeerConnection; (2) After waiting for the reconnection delay (default 3 seconds), check the reference count. If it has reached zero, abandon the reconnection and clean up the resources; (3) Create a new RTCPeerConnection and re-execute the complete WHEP handshake process (as described in 6.10.1) to obtain a temporary MediaStream containing the new media track; (4) Perform Track hot replacement on the persistent MediaStream: first call removeTrack() to remove all old tracks, and then call addTrack() to add all new tracks; (5) Update the PeerConnection reference in the connection entry to the new connection and bind the same disconnection reconnection logic to the new connection (recursive reconnection is supported).

[0126] The "seamless" principle: The `srcObject` attribute of the `video` element in all playback components always points to the same persistent `MediaStream` object reference. This reference is assigned when the connection is first established and remains unchanged regardless of how many times the connection is lost and reconnected. During reconnection, only the tracks within the `MediaStream` are replaced (`removeTrack` + `addTrack`), without changing the reference to the `MediaStream` object itself. The browser's `video` element can automatically detect track changes and switch playback content accordingly, so the playback component does not need to reset `srcObject` or trigger a re-render.

[0127] The effects of this embodiment are: (1) The WHEP protocol completes SDP signaling exchange based on standard HTTP POST interaction, without the need to deploy a separate WebSocket signaling server, simplifying the deployment architecture; (2) The reference counting mechanism enables multiple display components to share the same WebRTC connection, avoiding bandwidth waste and server resource consumption caused by repeated connection establishment; (3) Track hot replacement realizes completely transparent disconnection and reconnection to the playback component, and the interruption time perceived by the user is equal to the reconnection delay (about 3 seconds), without the need to manually refresh the page.

[0128] Example 4: Dynamic Update of AI Model:

[0129] AI model dynamic updates:

[0130] The Manager synchronously checks whether the model configuration items (including the model file path and version identifier) ​​have changed each time it polls the configuration source (every 10 seconds). When a new version model file is detected, the following hot update process is executed: (1) Download the new model file to a temporary directory; (2) Load the new model as a new InferenceSession instance using ONNX Runtime. This process is executed in parallel with the current inference and does not affect the ongoing detection; (3) Verify that the input and output dimensions of the new model are consistent with expectations (input shape is (1, 3, 640, 640), and the output dimension contains the correct number of categories); (4) After verification, switch the session reference in the shared YOLO detector instance from the old model to the new model through an atomic replacement operation; (5) Release the InferenceSession resources of the old model. During the replacement process in step (4), the Worker that is performing inference still uses the old session to complete the inference of the current frame, and automatically uses the new session when inferring the next frame. All Workers share the same detector instance, so one replacement takes effect on all cameras. This mechanism allows for uninterrupted model version switching without stopping any Worker threads, enabling uninterrupted inference service.

[0131] The effect of this embodiment is that maintenance personnel can update the AI ​​model (e.g., switch from a general model to a model optimized for a specific MRI examination room) without stopping the monitoring service, avoiding monitoring blind spots during the model update process.

[0132] Example 5: Unified Management of Multiple Locations:

[0133] Unified management of multiple locations:

[0134] Each location corresponds to an independent MRI examination room, with independent camera configurations, ROI area configurations, linkage alarm rules, and environmental threshold configurations. The system maintains a global list of locations, each with a unique number and name. The front end stores the currently selected location ID through a global state manager and persists it locally to ensure that the current location selection is maintained after the page is refreshed. When users switch locations on the device management page, the button for the currently selected location is grayed out and disabled, and the user is automatically redirected to the homepage after switching. All monitoring pages (homepage, environmental monitoring, ferromagnetic security, video surveillance, video linkage) read the current location ID from the global state manager, and all data query interfaces carry location parameters, achieving complete data isolation between different MRI examination rooms. The alarm engine also loads the corresponding linkage rules and threshold configurations based on the current location ID, ensuring that different examination rooms can be configured with different alarm strategies. The AI ​​inference service layer specifies the location ID it serves through a configuration file, and all cameras under that location are managed by the same Manager-Worker group. Different locations can be deployed on the same server (multi-process mode) or distributed across different servers, providing horizontal scalability.

[0135] The effect of this embodiment is that if a hospital has multiple MRI devices (such as one 1.5T and one 3.0T), they can be managed uniformly through the same monitoring platform. Maintenance personnel do not need to switch between multiple systems, thus reducing management costs.

[0136] Example 6: Automatic Result Level of Linkage Rules:

[0137] Automatic result level of linkage rules:

[0138] In the rule editor, when configuring the result level for each linked rule, the administrator can select a specific level (1=low risk, 2=medium risk, 3=high risk) or select "automatic" (internal value 0). When the result level of a rule is set to "automatic", the system performs the following calculation after all conditions of the rule are met: Iterate through the alarm sources corresponding to each trigger condition of the rule, obtain the actual alarm level of each source at the current moment, and take the maximum value as the final level of this alarm event, that is: final level = max(current level of source corresponding to condition 1, current level of source corresponding to condition 2, ...). Example: The rule is defined as "ferromagnetic detection >= low risk AND oxygen concentration >= low risk", and the result level is set to "automatic". At a certain moment, the current level of ferromagnetic detection is 3 (high risk) and the current level of oxygen concentration is 2 (medium risk), then the alarm event level is max(3, 2) = 3 (high risk). If the ferromagnetic detection subsequently drops to 1 (low risk) and the oxygen concentration remains at 2, then the alarm event level is max(1, 2) = 2 (medium risk). When the level in the condition is set to "any" (internal value 0), the condition means "it is satisfied as long as the source is in any alarm state (level >= 1)", and the operator is forced to ">=".

[0139] The effect of this embodiment is that the administrator does not need to configure multiple rules of different levels for the same set of triggering conditions (for example, it is not necessary to configure three rules separately: "ferromagnetic + oxygen concentration → low risk", "ferromagnetic + oxygen concentration → medium risk", and "ferromagnetic + oxygen concentration → high risk"). The system automatically matches the alarm intensity according to the actual danger level of each alarm source, which simplifies the rule configuration while ensuring that the alarm level is consistent with the actual risk level.

[0140] In summary, this solution can implement a stability counter de-jitter algorithm. By using mutually exclusive highHits / mediumHits dual counters and threshold determination for N consecutive frames, it achieves the anti-interference capability of "alarm only after continuous confirmation," effectively solving the false alarm problem caused by single-frame false detection.

[0141] The six-state machine hierarchical alarm decision (offline / idle / detecting / attention / alarm / timeout) maps the uncertainty of AI detection results to a clear operational state. Each state corresponds to a different safety response measure, which is the core innovation of this invention that distinguishes it from existing technologies.

[0142] The three-layer filtering pipeline (YOLO inference → ROI region filtering → security knowledge base mapping filtering) filters the model output, spatial location, and security knowledge base in a step-by-step manner to systematically reduce the false alarm rate.

[0143] The multi-source linkage rule engine features a multi-condition AND composite matching mechanism that supports both >= and = operators, enabling flexible combination and judgment of alarm results from heterogeneous data sources such as ferromagnetic, environmental, and AI data.

[0144] The dual-timer architecture (polling timer + independent watchdog) ensures that system faults can be detected in a timely manner even when there are network anomalies or inference blockages, thus guaranteeing monitoring reliability.

[0145] The three-layer nested interval threshold evaluation model, with its outward-to-inward nested judgment logic, allows for fine adjustment of the alarm sensitivity of environmental indicators.

[0146] The precise tick inference loop, based on adaptive frame rate control of a monotonic clock, accurately calculates the sleep difference after deducting the actual inference time, ensuring a stable detection frequency even under hardware performance fluctuations.

[0147] The 5-second de-jitter lifecycle management system delays confirmation after the alarm disappears rather than immediately clearing it, ensuring both timeliness and stability of alarms.

[0148] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A risk target early warning method for MRI scenarios, characterized in that: The specific steps are as follows: S1. Establish a safety knowledge base, which includes: defining multiple target categories of ferromagnetic hazardous materials and their respective hazard levels; Establish the region of interest, specifically by defining the normalized coordinates of a rectangular monitoring area for each camera; Configure environmental monitoring thresholds, specifically including configuring three nested alarm ranges for environmental indicators such as oxygen concentration, temperature, and humidity; Establish multi-source linkage, defining composite triggering conditions, operators, and result levels among multiple alarm sources; S2. Video data acquisition: The system connects to the network camera in the MRI examination room via a real-time streaming protocol to acquire real-time video streams. An independent acquisition process continuously decodes video frames and adopts a "keep only the latest frame" strategy. Each decoded frame immediately overwrites the internal frame variable. There is no queue buffer, and the inference thread always obtains the latest available frame, i.e., the video frame. S3. Image preprocessing: Converting the original image into a normalized input tensor acceptable to the deep learning model; S4. Input the standardized tensor obtained in step S3 into a pre-trained lightweight deep learning object detection model based on the YOLO architecture, and output a three-dimensional tensor with shape (1, 4+C, N), where C is the total number of ferromagnetic hazardous material categories preset in step S1, N is the total number of all candidate detection boxes, including the position parameters and classification parameters of each candidate box, and use the ONNXRuntime inference engine to perform real-time inference on the CPU. S5. Perform the following operations on the original model output from step S4 in sequence: S51. Transpose the output of the pre-trained lightweight deep learning object detection model from (1, 4+C, N) to a (N, 4+C) matrix. Separate the first four columns as bounding box coordinates (cx, cy, w, h), where cx and cy are the x and y coordinates of the bounding box center point, respectively, and w and h are the width and height of the bounding box, respectively. The last C columns are the scores for each category. For each candidate box, take the maximum category score as the confidence score of the box, and take the category index corresponding to the maximum score as the predicted category of the box. S52. Filter candidate boxes with confidence scores lower than a preset threshold. The preset threshold is determined based on the balance requirement between the false negative rate and the false positive rate in the target detection scenario, and the value range is 0.3-0.7, to eliminate noise detection with low confidence scores. S53. Convert the center point + width and height format to the top left corner + bottom right corner format: x1=cx-w / 2, y1=cy-h / 2, x2=cx+w / 2, y2=cy+h / 2; S54. Sort all candidate boxes in descending order of confidence, select the box with the highest confidence and keep it, calculate the intersection-union ratio (IoU) between it and all remaining boxes = intersection area / (area_i + area_j - intersection area + ε), where ε is a minimal smoothing constant to prevent the denominator from being zero; suppress overlapping boxes whose IoU exceeds the preset threshold, repeat this process until candidate boxes are exhausted, and eliminate duplicate detection of the same target; S55. Divide the pixel coordinates by the model input size 640, map them to the range [0, 1] and crop them to the valid interval; S56. Calculate the center point of each detection box as cx=bbox.x+bbox.w / 2 and cy=bbox.y+bbox.h / 2, and determine whether region.x≤cx≤region.x+region.w and region.y≤cy≤region.y+region.h hold, where bbox denotes the detection box, bbox.x and bbox.y are respectively the abscissa and ordinate of the top-left corner of the detection box, bbox.w and bbox.h are respectively the width and height of the detection box, region denotes the rectangular region of interest preset in step S1, region.x and region.y are respectively the abscissa and ordinate of the top-left corner of the region, and region.w and region.h are respectively the width and height of the region; only the targets whose center points fall within the region of interest preset in step S1 are retained; S57. Query the safety knowledge base established in step S1, and only retain the targets whose categories have a hazard level mapping in the knowledge base, and directly discard the targets of unknown categories without triggering the subsequent alarm process; S6. For the targets that have passed all the filtering in step S5, map the detection category of each target to the corresponding hazard level according to the category-level mapping relationship in the safety knowledge base in step S1; take the highest hazard level among all detected targets in the current frame as the comprehensive risk level of this frame; S7. Implement hierarchical alarm decision-making through a polymorphic state machine, where the state machine includes six states: offline, idle, detecting, attention, alarming, and timeout; perform state transition according to the stability verification result: transition to the alarming state when highHits≥N, transition to the attention state when highHits>0 but <N, transition to the attention state when mediumHits≥N, and transition to the detecting state when mediumHits>0 but <N, where highHits is the consecutive hit frame counter of high-risk targets, and mediumHits is the consecutive hit frame counter of medium-risk targets; S8. Perform multi-source linkage alarm on the risk classification result generated in step S6 in combination with other data sources.

2. The risk target early warning method for MRI scenarios according to claim 1, characterized in that: The step S3 includes: S31. Image scaling: scale the original video frame from the acquisition resolution to a model input size of 640×640 pixels; S32. Color space conversion: convert the image from the BGR color space to the RGB color space; S33. Pixel value normalization: divide the integer grayscale value of each pixel by 255.0, and map it from the integer range [0, 255] to the floating point range [0.0, 1.0]; S34. Dimension transformation: convert the image data from the arrangement of height×width×channel to the arrangement of channel×height×width, and add a batch dimension at the forefront to obtain a 4-dimensional floating-point tensor with the shape of (1, 3, 640, 640).

3. The risk target early warning method for MRI scenarios according to claim 1, characterized in that: The pre-trained lightweight deep learning target detection model in S4 adopts a single-stage detection architecture, and its detection and classification principle includes: S41. Feature extraction: Through a backbone network composed of multiple convolutional neural networks, layer-by-layer convolution and downsampling operations are performed on the input image to extract multi-level feature maps from low-level texture edge features to high-level semantic features in sequence. The spatial resolution of each feature map decreases while the channel depth increases. S42. Multi-scale feature fusion: The feature pyramid network fuses feature maps of different spatial resolutions across layers. High-resolution feature maps are good at detecting small targets, while low-resolution feature maps are good at detecting large targets. After fusion, the model can detect targets of different sizes in the same inference. S43. Joint prediction of classification and localization: The detection head predicts two sets of parameters for each spatial grid location on multiple fused feature maps: four location parameters, namely the center coordinates (cx, cy) of the bounding box, width and height, and C classification parameters, namely the confidence score of each preset target category. C is the number of dangerous item categories preset in step S1, and each category score represents the probability that the corresponding category target exists at the grid location. S44. Category determination: For each candidate detection box, the maximum value among the C category confidence scores is taken as the comprehensive confidence of the box, and the category index corresponding to the maximum value is taken as the predicted category of the target, thereby realizing the automatic classification and identification of ferromagnetic hazardous materials. S45. Model output: Output a three-dimensional tensor with shape (1, 4+C, N).

4. The risk target early warning method for MRI scenarios according to claim 1, characterized in that: Before S7 implements the graded alarm decision, it also includes performing jitter removal processing on the detection results of multiple consecutive frames through a stability counter. A mutually exclusive dual-counter mechanism is adopted—the high-risk counter and the medium-risk counter cannot be incremented at the same time. When one is incremented, the other is reset to zero. When the overall risk of the current frame is high, highHits is incremented by 1 and mediumHits is reset to zero. When it is medium, mediumHits is incremented by 1 and highHits is reset to zero. When it is low or there is no target, both counters are reset to zero. A high-risk target needs to be detected continuously for N frames before it is upgraded to an alarm state.

5. A risk target early warning method for MRI scenarios according to claim 1, characterized in that: The multi-source linkage alarm process in S8, which combines other data sources, specifically includes: S81. Define independent alarm sources: ferromagnetic detection, oxygen concentration, temperature, humidity, and AI recognition. Each source is independently assessed as a level four risk level. S82. Environmental indicators are evaluated using the three-layer nested interval threshold configured in step S1. The high / medium / low alarm intervals are checked sequentially from the outside to the inside, and each level contains two boundary values: the upper limit and the lower limit. S83. The ferromagnetic detection source takes the maximum value of the LED color level of the left and right detectors; S84. Perform multi-condition AND compound matching using the linkage rules configured in step S1. Each condition supports two operators: "≥" and "=". S85: After the rule is triggered, an alarm event is generated and asynchronously written to the database; after the alarm disappears, a 5-second de-jitter mechanism is used to prevent sensor data fluctuations from causing frequent switching. S86: Automatically switch the frequency, waveform, and rhythm of the audible alarm according to the alarm level.

6. A risk target early warning method for MRI scenarios according to claim 4, characterized in that: In S5, the ROI region filtering adopts the detection box center point determination method, calculates the coordinates of the detection box center point, and determines whether the center point falls within the preset rectangular area. The stability counter adopts a mutually exclusive dual counter mechanism, and the high-risk counter and the medium-risk counter cannot be incremented at the same time. When one is incremented, the other is reset to zero.

7. The operating system of a risk target early warning method for MRI scenes according to any one of claims 1-6, characterized in that: The system includes: Multi-camera dynamic manager: Adopts Manager-Worker architecture, periodically polls the configuration source to automatically add, delete and update Workers, and supports hot updates of ROI areas; Frame capturer: An independent process captures video streams through a video streaming protocol, employing a "keep only the latest frame" strategy protected by inter-process pipe communication; AI Inference Engine: Real-time inference based on a lightweight inference engine, including a nonmaximum suppression algorithm and a three-layer filtering pipeline; Alarm decision engine: includes stability counter, polymorphic state machine and dual timers; AI detection results overlay display layer: Normalized coordinates are converted into percentage coordinates for positioning and overlaid on the real-time video stream.

8. The operating system of the risk target early warning method for MRI scenes according to claim 7, characterized in that: Video streams are transmitted via the WebRTC WHEP protocol, PeerConnection connection resources are shared using a reference counting mechanism, and seamless reconnection is achieved through a Track hot-swap mechanism.

9. A computer-readable storage medium, specifically a memory, characterized in that: It contains a computer program that runs the method according to any one of claims 1-6.

Images