If a distributed temperature sensing installation measures accurately but produces alarms nobody acts on, replacing the sensing hardware will not fix it. The measurement is not the problem — the interpretation, mapping and evidence layer is, and that layer can be replaced on its own.
Need product specifications, use cases or references?
Call +86 130 4890 6506 for selection guidance and comparable project types Email usA familiar position to be in:
The instinct is that the hardware must be inadequate and needs replacing. Usually it is not, and replacing it is the expensive way to solve a software problem.
This is worth stating plainly because it changes the commercial question. If the sensing layer is sound, the project is not a capital equipment purchase — it is a software and integration project, with a much shorter path to a working result.
| Layer | Replaceable without touching the sensing hardware? |
|---|---|
| Sensing — the DTS device, the fibre, the installation | No — and usually no need |
| Device integration — reading the profiles from the device | Yes |
| Standardisation — normalising measurements into a common model | Yes |
| Asset mapping — linking fibre distance to real cables | Yes |
| Health assessment — turning measurements into verdicts | Yes |
| Alarm governance — merging, states, silencing semantics | Yes |
| Evidence and retention — what is kept, and for how long | Yes |
Everything from the second row down is software. That is the layer where most operational failure actually occurs.
A retrofit is only viable if the device will talk to something else. Check these first — in this order, because each one gates the next:
The profile data has to be readable. Modbus TCP is the common case; Modbus RTU is a fallback. If the device is closed and only talks to its own vendor software, a retrofit is not possible and you should know that before spending anything.
An interface without a documented register map is not usable. You need to know where the profile points, the scan metadata and the device status live — and how the device signals a partial or failed read.
This is usually the largest piece of work, and it is a site task rather than a software task: someone has to establish which fibre distance corresponds to which cable, joint and section. If that mapping does not exist, the retrofit still works — it just starts by producing better information about distances until the mapping is built.
If current transformers exist, temperature can be assessed against load, which materially improves the quality of judgement. If they do not, basic temperature monitoring still runs in full — but the system must not then assert overload or connection fault as a confirmed cause.
If an incident review needs data from six months ago, that requirement shapes the storage design. It is much cheaper to decide this at the start than to discover it after an incident.
Important boundary: the retrofit is read-only with respect to the sensing device, and the platform itself does not trip breakers, interrupt supply or shed load. High-risk operations are denied by default. That is what makes it acceptable to attach this layer to equipment that is already in service.
| Before | After |
|---|---|
| A distance-temperature curve | A verdict naming the cable, with evidence and a recommended action |
| Threshold alarms that fire on noise | Spatial hotspots, one persisting hotspot → one business alarm |
| Acknowledging appears to resolve | Condition state and handling state are independent; silencing clears nothing |
| Missing data looks like normal data | An explicit "cannot determine" state |
| No asset context | Alarm names plant → room → feeder → cable → core |
| Data kept for hours | Per-frame 7 days · minute-level 1 year · evidence 3 years, off-box |
| Nothing to review after an incident | Immutable evidence bundles |
None of this requires the sensing hardware to change.
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.
Being explicit about the limits, because a retrofit sold on the wrong expectations fails during delivery:
In most cases the device stays exactly where it is. The monitoring platform reads profiles from it over Modbus and applies the monitoring, mapping and evidence layer on top. Whether it is viable for your specific device depends on it exposing a usable interface and a documented register map — those are the first two things we check.
No. The platform reads profiles as a client; it does not change the device's configuration or operating parameters. This is deliberate — it is what allows the layer to be attached to equipment already in service.
Yes, with a caveat: until the mapping is built, the system can only speak in distances. Building the asset mapping is usually the largest single piece of a retrofit, and it is site work rather than software work.
Yes. Basic temperature monitoring runs in full without current data. What the system will not do without it is assert overload or connection fault as a confirmed cause — it reports what it observed and what it cannot determine.
That depends almost entirely on asset mapping and policy design rather than on software installation. Tell us the cable layout, whether the fibre is mapped, and the device interface, and we can give you a realistic scope.
It stays where it is unless a migration is explicitly scoped. The retrofit adds a layer going forward; importing and reconciling historic data from another system is a separate exercise and should be decided deliberately rather than assumed.
No. A common path is to start with one distribution room or one cable route, establish that the mapping and alarm behaviour are right, and extend afterwards. Proving it on a bounded area is cheaper than discovering a policy problem across a whole site.
Technically a read-only client can coexist. Whether that is desirable depends on your operating model — running two alarm systems in parallel tends to recreate the trust problem you are trying to solve, so we would generally recommend a defined switchover.
If you already have DTS hardware and the problem is the layer above it, tell us the device interface, whether the fibre is mapped to cables, and what the alarms currently look like — we will tell you whether a retrofit is viable.
Call +86 130 4890 6506 · export@rebe-tec.cn