Since the beginning of infrastructure, the ability to “see” or “control” something far away, or to do so automatically, has been desirable. I like to imagine that early industrial concerns would have appreciated a PID-controlled flow valve upstream of the waterwheel to regulate RPM. Still, it wasn’t until innovations in radios, remote control, and electromechanical devices during the Second World War that these ideas could be implemented in routine industrial settings.

What started in earnest in the 1950s with “First Generation” mainframe-based monitoring and control (SCADA) solutions eventually gave way to “Second Generation” distributed systems that communicated over local networks. This then evolved into the "Third Generation" of wide area networked control and data acquisition solutions. We are now firmly in what is called the "Fourth Generation" or "Next Gen," which primarily relies on Edge Computing. 

From one generation to the next, hardware and computers have become smaller, more powerful, and more affordable. At the same time, networks and communication pathways have expanded and become faster, reaching a point where the hard ware is so compact, and the network is so extensive that we call it “The Internet of Things.” 

The great news is that, for whatever reason, you can now interact with everything from your saltshaker to livestock over the internet, usually from whatever device you happen to be carrying or sitting in front of anywhere in the world.

Focusing on energy infrastructure, we now have everything from smart meters with remote shut-off capabilities to remotely managed corrosion control and odorant systems, along with pressure control devices. These tools are now durable, dependable, secure, and affordable, allowing for major improvements in situational awareness, customer service, emergency response, predictive maintenance, and lowering operational and maintenance costs.

So, what’s not to love?

In short, the outcome may vary significantly, depending on how it is executed. That may seem indeterminate, but consider that the Internet of Things requires a few distinct elements to function, each of which can be done well or poorly:

1)     The Devices: The physical components that are being monitored or controlled. This can include a device, such as a transformer or switchgear, or a sensor that reads pressure, voltage, or temperature.

2)     The Network: How data moves to and from devices. This includes communication nodes (sometimes integrated into the device) and the network over which the data is transmitted. While the Internet is the main network through which IoT data flows, there are also entirely private networks and hybrid networks.

3)     The Application: Perhaps the most nebulous of the categories, the “application” is what one would use to interact with data from the device(s). This could be through a traditional SCADA platform and Human-Machine Interface (HMI), or it could be a web-based application hosted in the cloud.

With out any one of these elements, remote device interaction isn’t possible. This presents some challenges. Instead of detailing the specific challenges, let’s use the cellular phone ecosystem as a metaphor.

Apple and Samsung (along with many others) manufacture phones like the iPhone and Android devices, but they do not build or manage the networks those phones use to communicate. That responsibility lies with the carriers (such as Verizon, Sprint, and AT&T). However, neither the phone manufacturers nor the carriers create most of the applications you use on your phone; those are developed by platform and app companies.

Fortunately, the widespread adoption of cellular phones has led to standardization around key communication technologies (like LTE and 5G) and popular app platforms(mainly iOS and Android). Without this, our ability to communicate, share data, and use specific devices would be significantly more limited. Sadly, the Internet of Things still faces similar restrictions. While cell phones continue to evolve, they are now fairly mature in terms of adoption, whereas the Internet of Things remains in its early stages.

Returning to the notion of devices, networks, and applications (the D-N-A of the Internet of Things), generally, IoT product and service vendors focus on one or two of these aspects, rarely all three. When they do, the result is often a proprietary system with its own challenges. Using the cell phone example, we might end up with a beautiful iPhone that only works on an Apple network and only communicates with other iPhones. Or perhaps a phone made by Verizon, which isn’t a top-tier device but at least functions on one of the largest networks in the world. Or perhaps Meta produces a phone that requires all calls to be made using VR goggles…shudder. Clearly, the best approach is for each to specialize in their area of expertise, leading to (mostly) cross-compatible devices that foster choice and competition in the marketplace.

How is this connected to critical infrastructure?  

For simplicity, let’s assume the Internet carries the entire “N” component of the D-N-A and focus on the rest. In the infrastructure world (which is typically asset-focused), it’s no surprise that some of the leading companies in IoT are hardware vendors. After all, infrastructure mainly consists of hardware, and many manufacturers already have a large customer base, a capable supply chain, and established relationships. It’s only natural to start adding “smart” or remote features to traditional hardware (such as meters and valves) and to develop new, related products like methane detectors and pressure and flow sensors. 

Here lies a challenge: generally, you don’t buy all your field devices from the same manufacturer (and procurement may groan if you do). You might buy regulators from Fisher, valves from Cameron, and meters from Sensus. Since each manufacturer needs to complete the D-N-A architecture for their product to be useful, they develop their own applications to interact with the data. Think about your own home – are your security cameras, security system, HVAC, and landscape lights all made by the same manufacturer and on the same app? Likely not. Some applications can interact with non-brand devices, but it’s more the exception than the rule (at least for now). 

So what?

The fragmented device and applications ecosystem can pose challenges ranging from in convenience to overspending and safety issues. Many operators avoid adding telemetry to their systems because they see it as too complicated; however, this author (admittedly biased) believes that having early warning signals for undesirable conditions in critical infrastructure is extremely valuable. 

But let’s say you take that jump into adding your first piece of telemetry or perhaps expanding your visibility across the system with new IoT devices. There are some other considerations to keep in mind. In addition to watching for siloed data, overlapping services, and compatibility issues, security must remain a top priority.

When done well, IoT implementations can align with the Purdue model and be subject to the same policies, procedures, and engineered controls used to secure OT devices worldwide, but done poorly, and they are an express lane from the internet (and any adversary hanging out there) to your critical infrastructure.

Not all IoT devices, networks, and applications are created equally, and yet each one you acquire should receive dedicated attention to ensure your data is secure in transit and at rest, with adequate redundancy, disaster recovery, and security features in place. It goes without saying that deploying more brands, models, and software suites can expand and complicate your attack surface. This is where leveraging SOC 2 Type II reports you’re your vendors become crucial in your decision-making process.

Lastly, what do you do with the data once it is collected from the field and transmitted to an application? For those of you with control rooms, consider whether the rapidly expanding point count fits your control room philosophy(and regulatory requirements), or if the signal-to-noise ratio of useful yet potentially sub-critical IoT data is suitable for that environment. For those without a control room, there’s no reward for collecting data and doing nothing with it, unfortunately. Setting up passive alarms and text/email notifications is a good start, but without 24/7 monitoring, those alerts might be ignored if the recipient is sleeping on vacation or caught up in their weekend activities, making the alarms late and ineffective.

So how can we have our cake and eat it too?

Or more specifically, how can we increase situational awareness and safety, without a corresponding increase in cost, complexity, or security attack surface?

Here’s the recipe: Buy whatever devices solve your business needs* and let EverLine be your network and applications. Avoid proprietary cloud apps and on-premises software that require extra computing power and constant updates. Instead, send data directly from the devices to EverLine’s data centers through secure tunnels. 

*(if the devices are robust, reliable and secure!)

From there, we utilize our enterprise-grade SCADA, HMI, and data visualization suites to display your data on a screen in front of a trained controller, store it in a historian for scheduled and ad-hoc reports, and/or present it in a data visualization package where stakeholders can access the data 24/7 on their own.

Leave security to us. Not only do we encrypt and protect data in transit and at rest, but our Security Operations Center monitors OT network traffic 24/7, responds to the latest threat intelligence, and actively defends your operation.

EverLine is your single pane of glass (SPoG) for OT data. Let us create a simple, secure, and comprehensive overview that your operation needs to meet its safety, reliability, and affordability goals.

If you don’t have a control room, you do now. If you already have one, you also have an overflow or backup control room to handle what the primary can’t. 

Don’t wait for “no gas” calls from your customer to detect an outage; monitor pressure and low levels at every regulator station.

Don’t wait for odor calls to determine if a relief has popped; instead, monitor valve position in real-time.

Don’t wait until a hiker finds the leak; use leak detection algorithms to monitor integrity.

Who is EverLine?

We are the largest third-party energy control room provider in North America; we offer a secure, reliable, and redundant infrastructure to our clients at a fraction of the cost. We operate pipelines, electric transmission systems, fuel cells, solar farms, and industrial fuel delivery infrastructure 24/7/365 for more than40 customers, and deliver security, compliance, integrity, and consulting services for nearly 300 across the US.

In addition to control room operations, EverLine offers a full range of Operational Technology (OT) services, such as network design, network audits, Purdue Model setup and deployment, and OT/ICS cybersecurity consulting. Our team guarantees your critical infrastructure functions with maximum security, efficiency, and resilience, whether starting from scratch or modernizing existing legacy systems.

About the author

Mike Bradley is a gas and electric utility professional with15+ years of experience in construction, O&M, R&D, standards and procedures, regulatory compliance, ethics, and risk management. He holds degrees in engineering, business administration, and engineering management, and has a passion for simplifying, making utility-scale operations safer, and enhancing their security. Mike’s role at EverLine is Director of Utilities Services, where he works with customers to identify and reduce or mitigate risks to their businesses, whether that involves engaging EverLine’s technical operations (control room, security, SCADA, and OT networking) or compliance and integrity management services.

‍