IoT in Energy: Enhancing Efficiency and Reliability

IoT deployments in energy infrastructure have moved well past pilot projects. Grid operators, renewable plant managers, and industrial energy teams are now running sensor networks at scale, and the decisions they face are architectural, not conceptual. This post covers how those systems are actually built, where they break, and what it costs to get them right.

What Does an IoT Stack Look Like in an Energy Context?

The energy sector doesn't use generic IoT stacks. The constraints — safety-critical uptime, legacy SCADA systems, remote physical sites, and regulatory compliance — push engineers toward specific choices at every layer.

Edge Layer

Most energy IoT deployments start with IEC 61850 or DNP3 for substation communication, and Modbus RTU/TCP for older field devices. These aren't going away. Any modern IoT layer has to coexist with them, which usually means protocol translation at the edge using gateways like the Moxa UC-8200 or Cisco IR1100.

Edge compute matters here. Running inference at the edge — anomaly detection on a turbine vibration signal, for instance — reduces round-trip latency and keeps operations functional during WAN outages. NVIDIA Jetson Orin NX modules are showing up in substations for exactly this reason. The alternative is sending raw time-series back to a cloud platform, which works until the backhaul drops or your data egress costs become untenable.

Connectivity

Cellular (4G LTE/5G) covers most grid-connected sites reasonably well. For remote generation assets — offshore wind, isolated solar farms, pipeline monitoring — you're looking at VSAT or LoRaWAN depending on data volume. LoRaWAN is adequate for low-frequency telemetry (meter reads, valve states) but can't carry waveform data. VSAT adds latency and cost but handles higher throughput.

Private LTE networks using CBRS spectrum (in the US) or licensed bands are becoming standard for large utility campuses. They give the control needed for QoS prioritisation on protection signalling without depending on a public carrier.

Platform Layer

Most teams choose between a purpose-built energy platform like OSIsoft PI (now AVEVA PI System) and a cloud-native IoT platform like AWS IoT SiteWise, Azure IoT Hub, or Google Cloud IoT (though Google Cloud IoT Core was deprecated in 2023, which caught several teams mid-implementation). AVEVA PI remains dominant for historian workloads in power generation. AWS SiteWise has gained ground for greenfield renewable deployments where there's no legacy historian to integrate.

The honest trade-off: AVEVA PI has decades of connectors and an enormous user base in operations, but it's expensive and requires specialist knowledge to administer. AWS SiteWise is cheaper to start and integrates cleanly with Lambda and S3, but you'll rebuild a lot of the contextualisation and asset modelling that PI provides out of the box.

How Do You Handle Reliability When the Network Is Unreliable?

This is the question most IoT architecture discussions skip. Edge devices in energy environments lose connectivity. A substation in a flood zone, a wind turbine on a remote ridge, a pipeline monitoring unit in a region with poor coverage — all of these will experience periods of disconnection.

Store-and-forward is the baseline requirement. Devices need local buffering (typically SQLite or a time-series store like InfluxDB at the edge) with guaranteed delivery queues using MQTT with QoS level 1 or 2. AWS Greengrass and Azure IoT Edge both handle this pattern. The choice between them usually comes down to which cloud platform the rest of the stack is on, not on significant technical differentiation at this layer.

Redundancy at the edge matters too. Dual SIM modems with automatic failover between carriers add cost (roughly £150–300 per unit) but are worth it for any asset where an undetected fault has safety or financial consequences.

Watchdog timers and remote reboot capability via out-of-band management (a separate cellular modem on a different carrier, running something like OpenGear CM7100) have saved operations teams from physical site visits in cases where a device locks up during off-hours.

Predictive Maintenance: Where the Analytics Actually Add Value

Predictive maintenance is the most-cited IoT use case in energy, and it's also where the gap between promise and delivery is widest.

The use cases that work reliably:

• Transformer health monitoring using dissolved gas analysis (DGA) sensors correlated with load and temperature data. Models trained on historical fault signatures from the same transformer family perform well. Generic models don't.
• Wind turbine gearbox and bearing monitoring using accelerometers and SCADA data. Vestas and Siemens Gamesa both run proprietary ML pipelines for this. Third-party implementations using the same sensor inputs (vibration RMS, kurtosis, crest factor) can get close, but require 12–18 months of baseline data before anomaly thresholds are meaningful.
• Distribution line fault detection using current and voltage phasor data from PMUs (Phasor Measurement Units). IEEE C37.118.2 standardises the data format. The detection algorithms are well understood. The hard part is getting the PMU data off the network in real time.

The use cases that look good in demos but underdeliver in production: battery state-of-health prediction without cell-level telemetry, and generator fault detection using only SCADA data (sample rates are too low to catch early-stage mechanical faults).

Use Case	Data Source	Minimum Data History	Production-Ready?
Transformer DGA anomaly detection	DGA sensors + load data	6 months	Yes, with asset-specific tuning
Wind turbine bearing fault detection	Accelerometers + SCADA	12–18 months	Yes
Battery state-of-health prediction	Cell-level BMS telemetry	24 months	Yes, if cell-level data available
Distribution fault classification	PMU phasor data	3 months	Yes
Generator fault detection via SCADA	SCADA tags only	Any	No — insufficient resolution

Cybersecurity in OT Networks: Different Rules Apply

IT security practices don't translate directly to OT environments. A patch cycle that's acceptable for a web server — weekly, automated — can take 18 months in a substation because firmware updates require outage windows, vendor certification, and regulatory sign-off.

The IEC 62443 standard is the right framework here. It defines security levels (SL 1–4) and specifies requirements at the zone and conduit level rather than at the device level, which maps well to how energy networks are actually segmented.

Practical controls that matter: network segmentation between OT and IT using unidirectional security gateways (Waterfall Security and Owl Cyber Defense are the main vendors), strict asset inventory using tools like Claroty or Nozomi Networks (which understand OT protocols and don't just report unknown devices as generic endpoints), and anomaly detection on OT traffic rather than signature-based IDS.

One point that's underappreciated: the attack surface in IoT-connected energy systems expanded significantly when cloud connectivity was added to previously air-gapped systems. The connection is usually justified, but it requires explicit threat modelling. MITRE ATT&CK for ICS is the most useful framework for that exercise.

What Should You Build vs. Buy?

Most energy teams shouldn't be building their own IoT platform. The integration and maintenance burden is high, and there are mature options available. Where custom development makes sense:

• Protocol translation and edge logic when your legacy field devices use proprietary or poorly-documented protocols that commercial gateways don't support.
• Custom ML models for asset-specific failure modes where vendor tools give generic outputs that don't match your failure history.
• Integration middleware between your OT historian and your enterprise systems (ERP, CMMS) when the available connectors don't meet your data model or latency requirements.

The clearest signal that you need custom work: your data is stuck in a system that can't export it at the resolution or frequency your analytics require.

Conclusion

IoT in energy is mature enough that the architecture decisions are no longer about whether to deploy, but about which stack to commit to, how to handle OT security without breaking operations, and where to invest in custom development versus commercial tooling. The reliability and security requirements are non-negotiable, and they're also well-understood — the standards and reference architectures exist. The gap is usually in implementation, integration, and sustained operations.

If you're working through a specific architecture decision — connectivity stack, edge compute selection, OT/IT integration — bring a concrete problem. Generic evaluations rarely surface the constraints that actually determine the right choice.

FAQ

What communication protocols are used in energy IoT systems? The dominant protocols are IEC 61850 for substation automation, DNP3 for SCADA communication with field devices, and Modbus RTU/TCP for older equipment. MQTT is widely used for cloud-bound telemetry. Most real deployments involve protocol translation at the gateway layer because these protocols don't coexist natively.

How much data does an energy IoT deployment typically generate? It varies significantly by asset type. A single PMU generates roughly 30–120 measurements per second. A wind farm with 50 turbines, each with 200 SCADA tags sampled at 1-second intervals, produces around 250 million data points per day. Data volume drives storage and egress costs more than any other single factor in cloud-based deployments.

Is cloud connectivity safe for OT networks in energy? It can be, with appropriate architecture. Unidirectional gateways, strict zone segmentation per IEC 62443, and OT-aware anomaly detection tools like Claroty reduce risk substantially. The key is that cloud connectivity should be an explicit design decision with a documented threat model, not an afterthought added to an air-gapped system.

How long does it take to get predictive maintenance models into production? Plan for 12–18 months from sensor installation to a model that's producing reliable alerts for most asset types. The bottleneck is baseline data collection, not model development. You need enough historical data to establish normal operating envelopes before anomalies are meaningful. DGA-based transformer monitoring is an exception and can produce useful outputs in 3–6 months.

What's the biggest implementation mistake in energy IoT projects? Treating connectivity as a solved problem and then discovering the real edge network is unreliable. Most production issues trace back to devices that lose connectivity, miss firmware updates, or accumulate local data that never syncs correctly. Store-and-forward architecture, remote management capability, and hardware watchdog timers should be designed in from the start, not retrofitted.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.