Most cable temperature monitoring projects are specified as a hardware purchase, then fail on decisions nobody made: what the system is for, where coverage stops, who acts on an alarm at 3 a.m., and what happens when the measurement itself fails. This guide walks through the nine decisions in the order they need to be made.
Need product specifications, use cases or references?
Call +86 130 4890 6506 for selection guidance and comparable project types Email usA typical specification document for a DTS installation lists: number of channels, measurement range, spatial resolution, temperature accuracy, communication protocol, enclosure rating. Those are all real requirements.
They are also all properties of the sensing device — and the sensing device is rarely what determines whether the installation is still trusted eighteen months later.
The decisions that actually determine success are about the layer above the sensor:
| Specified carefully | Usually left unsaid |
|---|---|
| Channels, range, resolution, accuracy | What the system is expected to decide |
| Protocol and interface | What happens when the fibre is damaged |
| Enclosure rating | Who acts on an alarm, and how fast |
| How fibre distance becomes a cable name | |
| How long evidence is kept |
Work through the nine decisions below before writing the hardware specification. Several of them change what hardware you need.
Three different jobs are often bundled into one tender, and they have different requirements:
| Purpose | What it needs |
|---|---|
| Detection — find a fault fast | Low latency, clear alarm routing, an owner who responds |
| Condition assessment — understand trends over time | Retention, trending, asset mapping, tolerance of noise |
| Compliance / reporting — demonstrate you monitored | Evidence integrity, retention period, audit trail |
A system optimised purely for detection tends to alarm too much to be useful for assessment. A system optimised for trending tends to be too slow for protection. Decide which is primary. If you genuinely need both, say so — because the alarm policy in §3.4 will differ per purpose.
Fibre goes where the cable goes — but only where you actually installed it. Before specifying channels, answer:
Write the uncovered list down. An undocumented coverage gap becomes an argument after the first incident — and it is much cheaper to agree it now.
The DTS device reports distance along a fibre. Operations need a cable, in a room, on a feeder.
Building that mapping is site work, not software work, and it is routinely underestimated. It requires the as-built fibre routing, the cable schedule, and someone who knows how the two correspond.
Decide before purchase:
If nobody is named for this, plan on the system producing distance-based information indefinitely.
This is the decision that most often determines whether the system survives. It has to be answered at specification time, not after the first week of alarms:
If the site cannot staff a response to fast alarms, specifying fast alarming does not create the capability — it creates alarm fatigue. Consider whether the system should say "attention advised" rather than "act now".
Fibre gets damaged. Devices reboot. Reads time out.
Decide explicitly what the system must show when it cannot measure. The only safe answer is a distinct state meaning "cannot determine" — never "no anomaly found". A system that silently reports normal while unmonitored is worse than no system, because it removes the reason to patrol.
Ask the vendor directly: "what does your system display when data is missing, and can I see an example?" The answer tells you a great deal about the software.
Ask what an incident review will need, then work backwards:
Retention drives storage sizing, and storage sizing is much cheaper to get right at specification than to retrofit.
A monitoring system that produces a screen nobody integrates is a system that gets checked occasionally by one person.
Decide:
If you buy the monitoring platform separately from the sensing device, be explicit about the boundary:
A retrofit onto existing hardware is a legitimate and often economical route (§4), but the responsibility split must be written down.
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.
If a DTS device is already installed and measuring correctly, replacing it will not fix a software-layer problem.
Before assuming replacement is necessary, check:
If the first two answers are yes, a monitoring-layer retrofit is usually the shorter path to a trustworthy system — and it does not disturb equipment that is already in service.
Use this as a cover sheet over the hardware specification.
| # | Decision | Answer | Owner |
|---|---|---|---|
| 1 | Primary purpose (detection / assessment / compliance) | ||
| 2 | Covered cables, rooms, sections — and explicitly uncovered ones | ||
| 3 | Who builds and maintains the asset mapping | ||
| 4 | Alarm meaning, recipient, response time, escalation | ||
| 5 | Acknowledgement semantics (must acknowledging clear?) | ||
| 6 | Behaviour when measurement fails | ||
| 7 | Automatic actions permitted (usually none) | ||
| 8 | Retention period, immutability, backup location | ||
| 9 | Downstream system consuming the output | ||
| 10 | Responsibility split for the sensing device |
If a vendor cannot answer rows 3–7 with specifics, that is itself information. Those are the rows that decide whether the installation is still trusted in two years.
The hardware figures — channels, range, resolution, accuracy — matter, but they are largely properties of the sensing device. What determines whether the installation stays trusted is the layer above it: what the system decides, how alarms behave, how fibre distance becomes a cable name, what happens when data is missing, and how long evidence is kept. Specify those before you write the hardware requirement.
Start from the tunnel's structure and the operational model rather than from the device. Decide which cable sections and joints must be covered, whether you need detection speed or condition trending, who is on duty when an alarm fires, and how distance will be mapped onto your cable naming. Those answers determine the channel count and alarm design; choosing the device first usually means re-specifying later.
Five things: what the system displays when it cannot measure; whether acknowledging an alarm clears the condition; how one physical hotspot maps to alarms; how the asset mapping is built and maintained; and the retention and immutability of evidence. Ask for a demonstration of each — particularly the first, which many systems handle badly.
That follows from coverage, not the other way round. Count the fibre routes you actually intend to install and the sections that must be distinguishable — and then write down which routes you are deliberately leaving out.
If your existing device exposes a usable interface with a documented register map, the monitoring layer can usually be retrofitted without replacing the sensing hardware. That is often the shorter path, since the sensing side is rarely the actual problem.
For most cable monitoring applications, no. Detection, judgement and action are better kept separate: the system advises, and a human authorises. If your specification requires automatic tripping or load shedding, state it explicitly — and consider whether you want a monitoring system holding that authority at all.
That depends on the job. For detecting a rise above normal, the relative behaviour matters more than absolute accuracy; for compliance reporting, absolute figures and their traceability matter more. This is also why we do not quote a single accuracy figure for the platform itself: accuracy is a property of the sensing device and the installation, and any platform claiming to improve it should be treated with suspicion.
Alarm fatigue. A system that produces more alarms than the team can act on gets silenced or ignored, and the real hotspot is then unmonitored by a system that is working correctly. It is a design problem, and it is solvable — but only if the alarm policy is decided before installation.
Yes. Send us the tunnel or distribution room layout, the cable schedule and what you are trying to detect, and we will tell you which of the nine decisions are already answered and which are still open — including the ones that may lead you to a supplier other than us.
If you are writing a specification for cable temperature monitoring, send us the layout and what you are trying to detect. We will tell you which of the nine decisions above are still open — and we will say so if the answer is that you do not need a new system at all.
Call +86 130 4890 6506 · export@rebe-tec.cn