The RTU Bill Comes Due: Why the Economics of Telecom Site Monitoring No Longer Add Up

The Math Nobody Wants to Do

Hardware and installation costs vary significantly across the market.  A basic remote terminal unit (RTU) unit from a vendor who is primarily interested in selling software could be around $500. A more capable RTU from a hardware specialist can run well over $1,000 — plus installation, plus a configuration service just to take the unit from a factory default to something reasonable for a specific site type.  The configuration cost alone is in the range of what a managed data layer costs in its entirety.

Whatever you paid for the unit, that is before you've even started to address the actual problem — standardizing the available data from your sites, delivering it consistently across a heterogeneous network, making it comparable and useful at scale. That work still has to happen. Someone still has to figure out how to normalize what the RTU produces alongside everything else in the network, how to deliver and store it, and how to make it comparable and useful across thousands of sites built on equipment from dozens of vendors over several decades.

That problem — the real problem — is where the value of most RTU deployments typically stall. The hardware gets deployed. A simpler alarm scheme gets configured, but the deeper work of turning raw device output into something genuinely valuable never fully materializes.

Whether hardware costs $500 or $2,000, the scope of the data work that follows is basically the same. An RTU is just a tool, someone still needs to know how to utilize it.  Across thousands of sites, that hardware sunk cost is an enormous number. What operators are now asking — with some urgency — is what operational improvement that investment actually delivered.

What Contact Closures Were Actually Solving

To understand why this has occured, it helps to understand a bit of history and what contact closures were designed to do. Historically, networks were built across equipment from dozens of vendors over decades, with no common data standard. Getting any consistent status picture across a heterogeneous network was nearly impossible.

Contact closures solved that by reducing everything to the same language: a major power alarm, a minor power alarm, a high temperature alert. Binary signals any piece of equipment could produce and any monitoring system could interpret. The standardization was real and had genuine operational value — something broke, you knew it at every site, regardless of who made the equipment.

RTUs extended that model and could do more. Many were sophisticated machines capable of reporting far richer data. The problem was that without a real data layer above them, there was nowhere useful for that richer data to go. The telemetry got discarded. What survived upstream was again a set of SNMP traps — a more expensive version of what contact closures had always produced. The industry settled for alarms, because alarms were what the rest of the system could handle.

The result: most RTU deployments are dealing in alarms, not telemetry. Equipment efficiency, trend analysis, site comparisons, the early signatures of a component approaching failure, many measures it would seem you should be able to get from your network, none of that survived the translation.

New Hardware Doesn't Fix This

The natural industry response from equipment vendors is new hardware or hardware features. Smarter controllers from power equipment vendors. Next-generation RTU-like devices with better connectivity and modern interfaces. New software platforms to support specific hardware.

The structural problem is unchanged. Adding more non-standard devices, no matter how smart or featured they are, alongside the tens of thousands already deployed devices doesn't reduce fragmentation — it adds to it.  Even if the new device is genuinely better, the overwhelming majority of the network is not going to get the new hardware in any reasonable timeframe.  

Some RTU vendors are beginning to adopt the modern data streaming methods we advocate — a positive development, but by definition it only extends to their own equipment. It's a difficult position when your business depends on hardware sales: advocating for an architecture that makes hardware interchangeable would undermine the core of what you sell. The implied solution remains: "Put our new solution in every site, and the problem will be solved."

When Hardware Is the Right Answer

This argument is not anti-hardware, and it's worth being precise about that.

Some functions require specific hardware and nothing else will do. If you need video, you need a camera. If you need AC metering, you need an AC meter. If a remote site needs out-of-band connectivity, you need a modem. If you need more ethernet ports, you need a switch. If you need contact closure inputs or output relay control — to exercise a generator, for example — some form of RTU may be the right answer. In each case the hardware is justified by a specific function it uniquely provides, and the value of that function is the test.

What hardware should no longer be considered is the monitoring platform itself. Not because site hardware doesn't work well in isolation — some of it works quite well — but because deploying it unevenly as the data layer across a heterogeneous network is the decision that has produced three decades of fragmentation and the economics conversation operators are having right now.

Software Platforms Are Better — But Still a Silo

What might seem like a reasonable solution to this problem is a hardware-agnostic, proprietary software platform. The pitch is reasonable: no hardware required, works with what you already have, modern interface.

The problem is subtler but structurally similar. These platforms may be hardware-agnostic on the input side, but they are not data-agnostic on the output side. Your data flows into their system in a proprietary format, queryable on their terms, subject to their pricing and their decisions about what you can and cannot do with information about your own network. That's before you factor in AI — if a more capable tool emerges, proprietary software becomes the thing standing between you and it.

There's an economic problem too. Hardware and software vendors both carry significant overhead that has nothing to do with your operational problem — manufacturing, firmware, proprietary development, support infrastructure. Those costs are embedded in what you pay. A company focused purely on the end goal of standardized site data and how to use it avoids that overhead entirely.

What ClaritechIO provides is closer to what a telecom operator would build for themselves — if they had the time, the tolerance for trial and error, and the accumulated expertise. We aren't trying to shoehorn in proprietary tools to create vendor stickiness. The question we asked when founding this company was simple: what would we do if it was our own network? FOCUS is that answer. The goal isn't to make operators dependent on us — it's to impart the method and build something WITH the operator that is genuinely and lastingly valuable.

The Distinction That Actually Matters

The right question isn't hardware versus software. It's whether you end up with a proprietary product or a dataset you own.

A proprietary product — hardware or software — gives you access to what the vendor built, on the vendor's terms. When a better tool comes along, or when AI systems need access to that data, you negotiate with the vendor. Or you don't get access at all.

A dataset you own is different in kind, not just degree. That dataset can feed Grafana dashboards, Snowflake, an AI optimization model, a billing system, a digital twin — anything that exists today, and anything built tomorrow. No permission required. No renegotiation. The data is yours and it goes where you decide.

This is what hardware and software agnostic actually means when it's real: not just flexibility in what the system ingests, but full ownership and portability of what it produces. The value of that portability compounds over time. Every new analytical capability, every new AI tool, every new application can be applied to the same dataset — without starting over.

What Different Economics Look Like

FOCUS is a managed energy data layer — not a software license you configure yourself. ClaritechIO integrates with your existing equipment, standardizes data across every vendor format and protocol in your network, and delivers per-site and network-level dashboards, all maintained on an ongoing basis.  If you have all this intelligent equipment creating data, what is your plan for how that data will be used? Unlike an NMS tool that hands you a configuration problem, FOCUS delivers a working data layer from day one. 

For a network of 1,000 sites, FOCUS can be implemented for several hundred dollars per site — integration, standardization, pipeline, and dashboarding included, deployed rapidly without disrupting current alarm systems or processes. That figure comes down further as site types get templated. More importantly, it replaces two expenditures operators have historically made sequentially: the hardware entry fee, and the data work that always had to follow.  FOCUS skips the first by working with equipment already in your network without needing an RTU as an intermediary device, and delivers the second.   

Existing RTUs and legacy equipment are simply data sources. FOCUS normalizes what they produce alongside everything else in the network.  Your installed base of site monitoring tools finally starts delivering something closer to what it was always theoretically capable of.  

Unlike RTU-based approaches, where partial coverage collapses much of the value, FOCUS delivers meaningful data at any coverage level and improves as coverage expands. New sites and existing sites are addressed by the same layer simultaneously.

An Approach That Works for Both New Sites and Legacy Sites

Designing the data layer for new cabinet specs is one problem. Bringing thousands of existing sites — already deployed, already heterogeneous, already paid for — into the same data standard is a different and larger one. Most new site architectures answer the first and ignore the second.

The only architecture that answers both simultaneously is one that sits above the hardware entirely — normalizing data regardless of what's underneath it, feeding it to whatever tools the operator chooses, owned by the operator rather than the vendor.

The economics align. The AI strategy aligns. The vendor lock-in question resolves. New builds and the legacy network are addressed at the same time.  Unlike hardware-based approaches that can't be cost-effectively scaled across every site type, the same data layer applies equally to your smallest edge sites and your largest data centers.

It is not a complicated argument, but it is one that you may not have heard because it works against existing voices in the industry, because it works directly against their current business models.