Most false alarms in distributed temperature sensing (DTS) cable monitoring do not come from the sensing hardware. They come from the layer above it — threshold-only alarming, no spatial merging, no separation between "condition" and "handling", and treating missing data as normal.
Need product specifications, use cases or references?
Call +86 130 4890 6506 for selection guidance and comparable project types Email usA DTS system is bought to catch a hot cable joint before it becomes a fire. It is judged, in practice, by a different measure: does anyone still look at the alarms? In that sense the problem is not measurement accuracy but alarm management — what is raised, what is merged, what is held, and what is kept as evidence.
An installation that produces dozens of alarms a week fails, even if every measurement it takes is perfectly accurate. The operating sequence is predictable:
This is the most common way a DTS deployment ends. It is not a sensing failure. It is an interpretation failure, and it is fixable in software.
A fixed threshold — say 70 °C — does not know whether the cable is carrying 20 A or 400 A, whether it is August or January, or whether that section has always run warm.
A cable that legitimately runs at 65 °C under full summer load will trip a 60 °C threshold every afternoon. The alarm is technically correct and operationally useless.
What is needed instead: temperature must be assessed alongside rate of temperature rise, difference against neighbouring objects, and difference within a parallel cable group. Those relative measures distinguish "this cable is hot" from "this cable is hotter than its own history and than its neighbours" — the second is the one that predicts a fault.
Every DTS measurement has noise. A single measurement point can transiently exceed a threshold while its neighbours, a metre away, are normal.
Alarming on individual points therefore produces alarms that no engineer would act on, because there is nothing physically there to act on.
What is needed instead: spatial merging. Adjacent anomalous points must be combined into a single spatial hotspot before an alarm is raised. One physical event should produce one alarm, not eleven.
A DTS system scans continuously — a hotspot present for ten minutes is present across many scans.
If each scan raises its own alarm, a single genuine event generates a burst of alarms and buries everything else.
What is needed instead: a hotspot that persists across scans must resolve to one business alarm, not one per scan.
Most systems have one state per alarm, so acknowledging an alarm is indistinguishable from resolving it.
The consequences are bad in both directions: an acknowledged-but-unresolved hotspot disappears from the work queue, and an operator who silences a noisy alarm has also silenced a real one.
What is needed instead: condition state and handling state must be independent.
Fibre gets damaged. A connector is disturbed. A device loses power. In a great many systems, the result of "no measurement" and the result of "measured, nothing wrong" look the same on the screen: nothing.
This is the most dangerous behaviour in the whole list, because it fails silently in the direction of reassurance.
What is needed instead: loss of data must be surfaced as a distinct state, and the system must never report "no anomaly" when it could not measure. A monitoring system must be able to say "cannot determine".
An alarm that says "62 °C at 1,243 m" requires the operator to go and work out which cable that is, in which room, on which feeder — usually from a drawing, sometimes at 3 a.m.
Under that workload, alarms get deferred. Deferred alarms become ignored alarms.
What is needed instead: fibre distance must be mapped onto the real asset hierarchy — plant, distribution room, feeder, line section, cable, core — so the alarm names the thing that needs attention.
When an incident does happen, the post-mortem needs the data from before it. If raw profiles are only kept for a few hours and the reasoning behind past verdicts was never recorded, there is nothing to review.
What is needed instead: immutable evidence attached to each assessment, with retention long enough to matter — and backup that leaves the machine.
We can provide: selection guidance · integration and network design guidance · product documentation on request
Call +86 130 4890 6506 for selection guidance and comparable project types Email usTell us your site conditions and what the data needs to connect to — we reply within one business day.
Pulling the seven points together, a DTS deployment that operators keep trusting has these properties:
| Property | Why |
|---|---|
| Multi-level health verdict, not a binary alarm | Distinguishes "attention advised" from "serious" so the response can be proportionate |
| An explicit "cannot determine" state | Missing data and clean data must never look the same |
| Spatial hotspot merging | One physical event → one alarm |
| One persisting hotspot → one business alarm | Prevents scan-rate-driven alarm floods |
| Condition state ⟂ handling state | Acknowledging is not resolving; silencing is not clearing |
| Relative measures (rise rate, neighbour difference, parallel-group difference) | Separates "hot" from "hotter than it should be" |
| Asset mapping | The alarm names a cable, not a distance |
| Evidence per verdict | Each conclusion carries object, time, location, value, trend, quality, coverage, limitation, recommended action |
| Long retention, off-box backup | An incident can be reconstructed months later |
None of this is exotic. All of it is software, and all of it is independent of which DTS device you bought.
Much of the value above — distinguishing a genuinely overloaded cable from a warm one — depends on knowing the load current. If current data is available, temperature can be assessed against it.
Two honest points:
A system that guesses a cause is worse than one that admits the limit — because the guess will eventually be acted on.
In our experience the sensing hardware is rarely the cause. The common causes are in the layer above it: threshold-only rules, no spatial merging, acknowledging treated as resolving, and missing data presented as normal. Those are software behaviours and can be changed without replacing the sensing equipment.
Usually yes. If your DTS device exposes a Modbus interface, a monitoring platform can read the profiles and apply the alarm governance described here, while leaving the sensing hardware in place.
That depends on your cable, its loading and its environment, and it is not something we would set from a datasheet. The more useful question is what the system does around the threshold — relative measures, spatial merging and data-quality handling matter more than the exact number.
By making silencing safe: silencing must not clear the condition, change its state, or stop recording. When silencing a noisy alarm no longer hides a real one, operators stop needing to defeat the system.
A distinct data-quality or coverage condition — never "no anomaly found". Loss of communication should be identified within the design target of 15 seconds and surfaced explicitly.
No. Our system does not trip breakers, interrupt supply or shed load. High-risk operations are denied by default and require authorisation and approval. Detecting and deciding are separated deliberately.
Per-frame profiles for 7 days, minute-level profiles for 1 year, and assessment and alarm evidence for 3 years. Evidence bundles are immutable, and backup must be off-box.
If your DTS installation is producing more alarms than your team can act on, tell us what the alarms look like and what device you are reading — we will tell you which of the seven causes above apply.
Call +86 130 4890 6506 · export@rebe-tec.cn