Fire Protection Monitoring: Tracing Alarm Causes Before Risks Spread

This case covers a 120,000 m² commercial complex with a 5-story high-end mall, a 20-story Grade A office tower, and a 2-level underground garage. Daily foot traffic is around 30,000 and doubles on holidays. The complex’s fire protection monitoring system covers the shopping mall, office tower, and underground garage. The site uses 17 monitoring terminals to collect data around the clock. Data from seven categories of fire protection equipment, including smoke detectors, temperature sensors, water pressure and water level monitoring devices, sprinklers, fire doors, and emergency lighting, is transmitted to the fire control center over LoRa.

The challenge is making sense of the data. A smoke alarm triggers, but why is it 8 minutes later than it should be? The end-line water pressure drops below the safety line. Is the fire pump the problem, or did the sprinklers discharge too much water? The standby pump interlock has activated. What hidden risk sits behind that signal?

In a conventional fire protection monitoring setup, alarms from different detectors may appear separately. Staff at the fire control center can identify where an alarm occurred, but investigating its cause and potential effects requires reviewing data across multiple systems, often with support from the building engineering team.

Why fire protection monitoring needs connected alarm context

Fire protection events can involve several related signals changing over a short period. Smoke detection, temperature readings, sprinkler activity, and water pressure may follow different timelines. Three signal relationships help explain how the system responded:

• In this sample dataset, higher smoke readings are followed by a 5–7°C rise in ambient temperature about 12 minutes later. This time lag illustrates why related sensor readings need to be examined together.
• In this sample dataset, a 10 m³/h increase in sprinkler flow is followed by a 0.04 MPa drop in end-line water pressure approximately 2 minutes later. This relationship helps illustrate how changes in sprinkler demand and network pressure can be analyzed together.
• Main-pipe pressure remained below 0.5 MPa for 10 minutes. An FP-G2 standby-pump interlock event was recorded later in the sequence.

None of these couplings shows up in any single sensor. When the smoke detector triggers, you know there is smoke, but not that the temperature is climbing behind it. When the pressure drops, you know the network has lost pressure, but not whether the sprinklers discharged or the pump failed.

Two typical problems, two analysis paths

Problem 1: Why did the smoke detector alarm eight minutes after its reading crossed the threshold? Cross-sensor root cause analysis

Across inspection batches F-003 to F-007, smoke detector SD-M3 in the third-floor food court of the mall was the first to show an anomaly. Its smoke concentration rose gradually from a normal 0.05 ppm to 0.18 ppm but did not trigger an alarm, because it had not reached the 0.5 ppm threshold. The elevated baseline warranted further investigation, including a check for detector contamination. Here, ppm refers to the measured smoke concentration, not the detector’s sensitivity rating.

During the day shift of batch F-004, a wok caught fire and the smoke concentration jumped from 0.18 ppm to 4.2 ppm. The recorded smoke reading crossed the configured threshold at 11:20, but the alarm was not recorded until 11:28—an eight-minute gap that required further investigation. In those 8 minutes, the fire kept spreading.

TD-M3 then recorded a rise in ambient temperature from 29 °C to 78 °C, exceeding the 57 °C threshold; the rate of increase reached 12 °C/min. Six minutes after the temperature alarm, the recorded sprinkler flow increased to 85 m³/h. End-line water pressure fell from 0.65 MPa to 0.28 MPa, below the stated 0.35 MPa alarm threshold, prompting a check against the sprinkler system’s hydraulic requirements. The fire water tank level fell from 4.8 m to 2.6 m.

The recorded sequence runs: elevated smoke reading → delayed alarm → temperature rise → increased sprinkler flow → end-line pressure loss → water tank level drop. These six observations help reconstruct the event sequence, but their timing alone does not establish causation. In a conventional monitoring system, these six alarms appear on separate screens. The building operations team has to review them one by one to piece together what happened.

TDengine brings these alarms together to reconstruct the event sequence and investigate possible causes:

Step 1: detect the anomaly from the smoke concentration trend. SD-M3’s concentration curve starts rising from a flat 0.05 ppm line, clearly deviating from the normal baseline. More importantly, the alarm trigger time (11:28) lags the threshold crossing time (11:20) by 8 minutes. This eight-minute gap warrants investigation of the detector response, alarm configuration, and event timestamps; it does not establish sensitivity drift.

Step 2: compare the timing of related signals. After SD-M3 alarmed, TD-M3 ambient temperature reached 78 °C at 11:50, SP-M3 sprinkler flow reached 85 m³/h at 11:58, WP-End end-line water pressure fell to 0.28 MPa at 12:03, and WL-Tank water level fell to 3.2 m at 12:08. Overlaying the five parameters on one trend chart helps compare their timing and guide further investigation.

Step 3: investigate possible causes. The comparison showed that SD-M3 alone had drifted to 0.18 ppm, while the other four detectors remained at 0.03–0.05 ppm. The investigation traced SD-M3’s sensitivity drift to grease buildup in the food court.

Problem 2: fire pump discharge pressure keeps falling. Is the seal the root cause? multi-parameter diagnosis of mechanical degradation

Across inspection batches F-010 to F-014, the discharge pressure of fire pump FP-G1 in the underground parking garage started to slide. But a falling pressure by itself says little. It could be a pipe network leak, a mechanical problem with the pump, or normal fluctuation.

TDengine’s real-time analysis triggered an alarm when FP-G1’s discharge pressure fell below 0.5 MPa. Overlaying three parameters showed falling discharge pressure, rising pump body temperature, and increasing vibration. Together, these trends are characteristic of mechanical-seal deterioration. The seal-leakage data below confirm the diagnosis.

Pressure trends show FP-G1’s discharge pressure falling, followed by WP-Main pressure dropping from 0.80 MPa to 0.48 MPa and WP-End pressure falling from 0.65 MPa to 0.38 MPa. These related readings trace the hydraulic response but do not, by themselves, establish its cause. WP-Main also fell below 0.5 MPa. Later, an interlock event was recorded for standby pump FP-G2.

FP-G1’s seal leakage increased from 0.1 to 2.8 L/min, exceeding the 0.5 L/min alarm threshold, while FP-G2’s seal leakage remained steady at 0.1 L/min. This comparison confirms mechanical-seal deterioration in FP-G1. A further review found that the F-010 monthly maintenance inspection had missed the small leak, by which time the opportunity for intervention had passed.

From alarm location to root cause and downstream risk

Effective fire protection monitoring brings sensor readings, equipment status, and alarm events together. With that context, engineering teams can investigate what triggered an alarm and understand how related equipment may be affected.

The two cases above illustrate three types of analysis:

• Cross-sensor root-cause tracing: an elevated smoke-reading baseline and an eight-minute gap between threshold crossing and the recorded alarm identify an issue for investigation. Comparing SD-M3 with other detectors helps narrow the possible causes, including contamination, for follow-up inspection and sensitivity testing.
• Multi-parameter coupled diagnosis: falling pump discharge pressure, rising pump body temperature, and increasing vibration flag an issue for investigation. Comparing FP-G1’s increasing seal leakage with FP-G2’s stable readings supports investigating seal deterioration and reviewing maintenance records, while inspection is needed to confirm the failure mechanism.
• Cascading propagation tracing: comparing pressure changes at FP-G1, WP-Main, and WP-End helps investigate how a pressure loss develops across the system. Reviewing these trends alongside the recorded FP-G2 standby-pump interlock event helps reconstruct the sequence and assess possible relationships between events.

TDengine organizes the time-series data scattered across 17 fire protection terminals into business objects with physical coupling relationships, so an alarm is no longer an isolated signal but a node on a causal chain. When an alarm reaches the fire control center, the staff on duty can review it alongside related equipment and sensor data. This gives the building engineering team a clearer starting point for investigating the cause and understanding how other systems may be affected.

TDengine comes with a high-performance, distributed time-series database, Industrial Ontology modeling and an Industrial Agent Runtime, providing a full-stack solution for industrial data streams from collection and storage to real-time analytics, visualization, event management, and root-cause analysis. To learn more about TDengine, visit www.tdengine.com and download it for free.

Try it yourself

Install and deploy TDengine Visit the TDengine Download Center, select TDengine All-in-One, choose the deployment platform and architecture that matches your environment, and follow the guided steps to complete the installation.

Load the sample data

On first activation, on the sample data loading screen, select Smart Fire Monitoring and Warning and wait for loading to complete.

If you have already activated the product, click your avatar in the top-right corner, select the Management Console, choose Sample Data on the left, then select Smart Fire Monitoring and Warning to load it. Wait a few minutes for loading to finish, and you are ready to explore.