Most articles about industrial IoT talk about connectivity as if it's one problem. In practice, “remote monitoring” means very different things depending on what you're actually monitoring. A borehole in the middle of a field and a transformer panel in a substation both count as remote assets, but they fail you in completely different ways if you get the design wrong. One has no power and no network anywhere nearby. The other has both, but the cost of losing local control for even a few seconds is a transformer that overheats without anyone knowing.
We've been working through both cases recently, and the contrast turned out to be a useful way to think about edge design in general. Here's what we learned from each.
Case one: monitoring something with no power and no wired networks
Boreholes are a genuinely hard environment to instrument. Sites are often kilometers apart across a wellfield, there's no mains supply anywhere near the wellhead, and running a wired network out to each one isn't realistic. The traditional answer is a manual dip reading: someone drives out, drops a tape measure, writes down a number, and drives to the next site. It works, but it tells you nothing about what happened between visits, and by the time a level problem shows up on a clipboard, a pump may have been running dry for days.
The obvious fix is a battery-powered logger with its own cellular connection, so the site doesn't need mains power or a local network at all. That part isn't controversial. The harder part is making the battery actually last long enough that a deployment is worth doing in the first place. A node that needs a battery swap every six months across a wellfield of forty sites is not a solution, it's a maintenance burden.
The detail that actually matters here is how the device decides when to transmit. Logging the sensor frequently is cheap, since it just means waking up, taking a reading, and going back to sleep. Transmitting over cellular is expensive by comparison, since keying up a radio and holding a connection burns far more energy than a local read. So instead of transmitting every reading, a transmit-on-change approach only keys up the radio when the water level has moved meaningfully, plus a periodic heartbeat so you know the node is still alive. Battery life isn't a fixed number, it depends heavily on that interval. A fixed hourly reporting schedule typically lands in the 4-5 year range in NORVI's own field data. Transmit-on-change pushes toward the upper end of that, and beyond it, since most hours generate no transmission at all, but the exact gain depends on how often the water level actually moves at a given site.
The other variable worth mentioning is sensor choice. A 316L stainless submersible sensor lowered directly into the water column is the established approach and holds up well for long-term immersion. A tube-type sensor, where the sensing head stays accessible at the wellhead and reads the water column through a tube run into the borehole, keeps the sensing electronics out of the water, which can make servicing easier. Field life for either type comes down mainly to the sensor's own current draw, not where the head sits, and how consistently the installation gets maintained. Neither is universally right, it depends on the installation and how the site will be maintained over its life.
We wrote up the full comparison, along with real battery-life numbers from an 80-meter borehole deployment, in more detail here: NORVI's borehole and groundwater level monitoring solution.
One more thing worth calling out on this side of things is cellular technology choice. The modem used in this class of logger supports NB-IoT, LTE-M (Cat-M), and 2G fallback, and NB-IoT tends to be the best default where it's supported, since it's built for low-power, deep-coverage scenarios. Coverage quality itself also matters more than people expect. A node reaching for a weak signal transmits harder to get its data out, and that alone can meaningfully shorten how long the battery lasts, which is part of why matching the radio technology to the actual site conditions matters more than defaulting to whatever's newest.
Case two: monitoring something where local control has to survive a lost connection
Transformer winding temperature monitoring is close to the opposite problem. A transformer panel isn't short on power, and it's usually not far from a network connection either. The real constraint is that temperature monitoring on a transformer isn't just a nice-to-have data feed, it's tied to protection logic. If a winding gets too hot, something needs to happen locally and immediately, whether that's starting forced cooling, raising an alarm, or issuing a trip request. None of that can be allowed to depend on whether a cloud service happens to be reachable at that moment.
For dry-type and cast resin transformers, the sensing side is usually Pt100 or Pt1000 RTDs embedded in or near the winding, sometimes with an extra RTD for ambient temperature so you can tell a genuine winding heating event apart from a wider ventilation problem. A typical setup assigns three channels to the three phase windings and a fourth to ambient or another manufacturer-provided point, using a four-channel RTD input module feeding into the main controller - in our deployments, a NORVI X CPU with its built-in TFT display and microSD logging, paired with a relay expansion module for the alarm outputs.
The design principle that matters most here is keeping the alarm logic on the device itself, entirely independent of whether a network connection exists at that moment. The controller reads the RTDs and shows live winding and ambient temperatures directly on its built-in display, so a technician standing at the panel can see current status without needing a live network link at all. When a reading crosses a configured threshold, the controller latches a relay output on a relay expansion module - driving forced cooling, an alarm light, or a horn - and steps that response up through a cooling stage, a high alarm, and a high-high or trip condition as things get worse. None of that decision-making touches the network. At the same time, every reading is written to the onboard microSD card, so if connectivity drops out entirely, the device keeps a complete local record instead of leaving a gap: once the link comes back, historical trending picks up from an unbroken log rather than a blank stretch. Only after the alarm logic and local logging are already handled does the data get forwarded to a dashboard, SCADA system, or cloud platform for visibility and historical trending. That ordering is deliberate. Cloud connectivity is genuinely useful for trend analysis, remote visibility, and maintenance reporting, but it should never be a link in the chain that has to hold for a protective action, or even basic data continuity, to happen.
It's worth being direct about something here too: none of this replaces the transformer manufacturer's actual protection settings. Fan, alarm, and trip temperatures vary by transformer design and thermal class, so the values used in any deployment need to come from the transformer's own documentation rather than a generic table. The monitoring system's job is to apply those approved limits reliably, not to invent new ones.
We went into the wiring layout, channel assignment, and staged alarm approach in more detail here, including relevant standards like IEC 60076-11 and IEEE C57.134: NORVI's transformer temperature monitoring solution.
The common thread
These two cases sit at opposite ends of what “remote” means, but the underlying design principle ends up being the same: figure out what the site can't guarantee, and don't build the system's most important behavior around assuming it will be there. For the borehole, what's missing is power and a network, so the answer is a device that can run for years on a battery and only spends energy on communication when it actually needs to. For the transformer, power and network are usually fine, but a live cloud connection can't be guaranteed at the exact moment it matters, so the answer is keeping protective logic local and treating remote visibility as an addition on top, not a dependency underneath.
If you're working on a similar problem, whether it's pipeline pressure, remote pump stations, or any other asset where the site doesn't give you everything you'd like, the question worth asking early is which of these two failure modes you're actually designing around. The right answer usually isn't more connectivity everywhere, it's being precise about which parts of the system genuinely need to survive without it.
Related documentation
For anyone implementing either of these, the following references cover the hardware and setup details this article doesn't go into:
- NORVI EC-M12 documentation — datasheets and setup guides for the battery-powered cellular logger used in the borehole case.
- How We Use Cellular IoT to Monitor Boreholes — a deeper field-deployment write-up on the borehole use case.
- NORVI X-RTD4 datasheet - RTD input channels, terminal configuration, and Pt100/Pt1000 selection for the transformer case.
- NORVI X CPU-ESPS3-X1 datasheet - built-in TFT display, RS-485, Ethernet, RTC, and microSD logging for the controller used in the transformer case.
- NORVI X-R4 datasheet - 4-channel relay expansion module used to latch the local alarm and cooling outputs.
- NORVI X getting started guide - CPU selection, expansion modules, wiring, and initial setup for the NORVI X controller.
- NORVI documentation library - current datasheets and technical references across the full product line.
Top comments (0)