NextEra Energy is, by installed capacity, America’s largest producer of wind and solar energy—a publicly traded utility operating more than 300 clean energy facilities across more than 40 U.S. states. The scale is real: over 100,000 individual generation assets and monitoring points, from wind turbines in the Texas Panhandle to solar arrays across the Mojave. Many of them are connected by links that would embarrass a 2003 DSL provider.
The question they needed answered: how do you move operational telemetry reliably when your “network” is a two-megabit cellular connection in the middle of the desert?
The Scale Problem Nobody Talks About
Every generation site in NextEra’s fleet produces continuous sensor data. SCADA systems poll hundreds of tags at 100-millisecond intervals—temperature, inverter state, wind vane position, fault indicators, pressure gauges, door contacts. That data flows through Ignition Edge (Inductive Automation’s field-level SCADA runtime), gets packaged as Sparkplug B MQTT, and travels to a HiveMQ broker cluster in the cloud.
The architecture is industry-standard. The physics are unforgiving.
Some sites run on Starlink. Others rely on cellular connections with hard capacity limits and unpredictable latency. On constrained links, Sparkplug B’s “birth certificate” pattern becomes a serious problem.
What Is a Sparkplug B Birth Certificate?
Sparkplug B defines a device lifecycle with three core message types: NBIRTH (node birth), DBIRTH (device birth), and NDEATH/DDEATH (death certificates). When a device connects—or reconnects after a network interruption—it publishes a birth certificate containing its complete current state: every metric, every current value, every metadata tag. This is by design. It ensures subscribers always have a consistent picture of device state without needing to track historical messages.
At small scale it’s elegant. At NextEra’s scale it’s a bandwidth emergency.
One site in NextEra’s fleet was generating birth certificates north of 800 MB. On a two-megabit connection, that’s over an hour of upload bandwidth consumed in a single burst. During that window, real-time data queues. The cloud broker sees sequence number gaps. Ignition Edge requests retransmits. Retransmits compound the congestion. Operations staff start receiving alerts from sites that are technically fine but effectively invisible—a phantom alarm storm that drains time and focus from actual problems.
Dead-banding helped at the margins—Ignition was already configured to suppress values that hadn’t changed beyond a meaningful threshold. A door sensor doesn’t need to report 0 forty times per second. A temperature reading with one-degree accuracy doesn’t need sub-degree precision in every message. But dead-banding alone couldn’t solve the fundamental throughput problem on the worst links. And it did nothing about the structural overhead of the Sparkplug protocol during birth events.
There was also a data quality problem hiding in the fleet’s diversity. NextEra’s SCADA estate spans hardware from multiple vendors across multiple decades. Occasionally, out-of-range values propagated downstream: door sensors reporting 1.5 instead of 0 or 1, temperature transducers returning physically impossible readings. No validation layer existed between the sensor and the broker.
A Layer That Thinks
Expanso’s role in NextEra’s architecture is surgical. It sits between Ignition Edge and the HiveMQ broker. Neither side knows it’s there. Ignition still publishes Sparkplug B. HiveMQ still receives Sparkplug B. The protocol is preserved, sequence integrity is maintained, and downstream historians and SCADA servers required zero configuration changes.
What changes is everything in between. Expanso applies a processing pipeline to every message in flight:
Schema enforcement. Values outside defined bounds are caught before they reach the broker. A door sensor reporting 1.5 or a temperature transducer returning 999°C routes to a dead-letter queue for investigation instead of propagating downstream. Every interception is logged and auditable.
Intelligent dead-banding. Configurable change-detection thresholds per metric type—1°C for temperature, 0.5 PSI for pressure—suppress messages that carry no new operational information. What was generating thousands of redundant packets per minute now generates dozens. The information that matters still arrives. The noise doesn’t consume bandwidth that isn’t there.
Payload compression. Sparkplug B uses Protocol Buffers for binary encoding—already more compact than JSON or XML. Further compression at the pipeline layer produces meaningful savings on burst events. Birth certificates that previously saturated uplinks for extended periods now complete in a fraction of the time.
Fan-out with differentiated routing. A single sensor stream now feeds multiple destinations simultaneously: the real-time broker for operations, an archival store for compliance, a filtered stream for anomaly detection. Logic lives in one place. It deploys identically to every site in the fleet—or with per-site customization where warranted.
Full pipeline observability. Every message processed—forwarded, dropped, flagged—is accounted for. Operations teams see real-time metrics: messages per second, bytes saved, validation failures by metric type, sequence integrity status. The difference between a network hiccup and genuine equipment failure becomes visible in seconds.
The Numbers That Matter
Across NextEra’s generation estate, Expanso now processes upward of tens of millions of sensor readings per day. On sites with the most constrained connectivity, effective wire utilization improved by more than 70%. Sequence gaps dropped dramatically. Alert storms from phantom alarms diminished as the pipeline learned to distinguish network hiccups from real events.
Zero downstream applications were modified. Zero protocol changes were required. The Ignition Edge investment NextEra had already made continues to do what it does well: translate SCADA protocols to Sparkplug B. Expanso handles everything that happens next.
Why This Architecture Generalizes
NextEra’s problem is not unique to energy. Anywhere you have constrained connectivity, heterogeneous sensor hardware, and a requirement to deliver clean data to a centralized broker, you have the same physics.
The Sparkplug B sequence problem is a property of the protocol, not a bug in any vendor’s implementation. The bandwidth problem is a property of the sites, not a failure of network procurement. What Expanso provides is a programmable layer at the point where those constraints actually live—not at the cloud, where the data has already consumed the bandwidth you didn’t have.
The processing happens at the edge, with full visibility into what was sent, what was dropped, and why. Every decision is auditable. Every pipeline is versioned. A fleet of hundreds of sites can run the same logic or a customized variant per site, managed from a single control plane.
That’s what edge-native data intelligence looks like in practice: not a cloud service that claims to handle edge workloads, but a runtime that actually runs at the edge and makes decisions where they need to be made.
Running a distributed fleet with constrained connectivity? Talk to the team.