Field Computing Needs

Written by Doug Houseman

When I started in the industry in the 1960s, edge computers were all analog computers, and they each did one and only one function. Most had dedicated lines to send the readings continuously back to someone who monitored them, but others recorded their information on circle or strip charts for later retrieval. Fast forward more than 50 years, some analog computers are still in use in the distribution system and circle charts still exist. But these devices are becoming ever rarer. Today, if we were to deploy analog instruments and communications lines for all the data, there would be no space for any other communications for anyone.

In the 1970s, the world woke up to digital computing and field computing was no exception. Relays and control devices started going digital, as did meters and other monitoring devices. That trend is continuing as old equipment is replaced and new equipment is being deployed. Gone are the days of 4-bit digital computers being installed in meters and relays, replaced today by 64-bit chips.

As fast as the industry has changed, society has changed faster. Today, almost every significant home appliance has computing capability - if only to run the displays - and universal communication capability is not far behind. With consumers not only accepting WiFi-connected appliances but demanding it in some cases, more and more devices not only compute but connect and communicate. In an average home, based on work done by an IEEE ICAD project, it’s estimated that more than 20 devices, including lights, could or would be capable of communicating and responding to requests for demand response and energy usage information by 2030. This is what people call the Internet of things (IoT). For a utility with 1 million customers, implementing IoT could mean they need to communicate with up to 20 million devices belonging to their customers.

Why would a utility want to communicate with customer devices?

There are many reasons, most of them boil down to Demand Side Management (DSM):

• Health of the device (including cyber security)
• Cost of changing the status of the device (e.g., $/kW or $/kWh)
• How long the current or requested period of operation needs to be
• The device’s status set by the customer. Is this item “must run” or “complete by X time” or is it coded as “can be turned off/on”?
• Consumer maximum and minimum demand for power (kW)

IEEE 2030.5 provides a protocol for communicating with these devices. The protocol makes it possible to determine the computing power and bandwidth required to communicate with any device or collection of devices. Should the required functionality get built into a utility-owned device like a revenue meter, or would it be better if built into a consumer-owned device like a home energy management system, or included in a cloud device like Amazon’s Echo (Alexa)? The answer to that question will determine computing needs at the grid edge. For now, let’s assume it is built into a utility device, which is the worst/most expensive case for edge computing and therefore all field computing.

What is field computing and edge computing?

Field computing is any computing device that is placed in the actual grid, whether in a substation, on a line or at a premise. Edge computing is the placement at a customer premise on the utility side of the meter.

A grid edge device would need to perform the following functions to handle all the needs for customers and utilities:

• Cybersecurity and privacy both for the utility and for the customers it communicates with. Firewall-like functionality that is bi-directional is probably the most critical and basic function.
• Protection of data both resident in the device and while being communicated is also critical to the control functions of the device.
• The ability to take and manage a schedule for the devices it controls or communicates with. One cannot always expect to have perfect communications, so schedules should be provided in advance, both for demand and for pricing. Depending on the quality of the communications and the latency, the device might have to hold several days of projected schedule data and get regular updates based on communications availability.
• Manage the negotiation between customer devices, and potentially negotiation with customers.
• Manage the uphill negotiations and communications of what customers want and from the utility.
• Monitor and record performance, possibly including self-reported usage from the devices, at the interval set by the utility for pricing periods.
• Compute from the data, any deviations from plan and forward that to both the customer and the utility. This may include daily bill information (e.g., how much did today cost me?)
• Keep the official reference time for all the devices in the “family” and keep a heartbeat of communications active with its family of devices.
• Compute performance and other analytics for communication to customers locally. May also communicate system-wide or area analytic results to give the customer(s) information to compare against.

This is not a trivial set of functions. Security requirements alone argue for a modern Central Processing Unit (CPU) with a commercial operating system (e.g., Linux, Windows, etc.). As more electric vehicles, EV chargers, storage, and demand side management programs are rolled out to customers on the grid, it is critical that the communications and computing infrastructure at the edge can deal with all of those devices to keep the costs of duplicate infrastructure down. Remember that in regulated utilities, every customer must have access to their data to provide social justice, not just the people who can afford expensive add-on energy management systems.

If a distributed control architecture is used, the computing power at substations must be capable of supporting these edge devices.  Otherwise, enough communications bandwidth to support the data rolling up to the central system. That central system needs enough processing power to handle a million or more edge computing devices. Edge and field computing is the better choice.

One of the biggest issues is forecasting what the edge computing needs will be over the next 15 to 20 years as customer demand and energy pricing systems change in response to electrification and other efforts to reduce GHG emissions. Predicting the size and speed of the changes that will determine these needs is the great challenge utility field computing now faces.

This article edited by Mehdi Moghadasi

For a downloadable copy of the August 2021 eNewsletter which includes this article, please visit the IEEE Smart Grid Resource Center.

Doug Houseman has extensive experience in the energy and utility industry and has been involved in projects in more than 70 countries. Doug is a leader in grid modernization thinking, he was asked to author significant portions of the IEEE’s GridVision 2050, DOE’s QER and to revise CEATI’s Distribution Utility Technology Roadmap. Doug is a NIST fellow and member of the GridWise Architecture Council (GWAC) where he had a hand in both the Smart Grid Interoperability Maturity Model and Transactive Energy. He has led the IEEE Power and Energy Society’s Intelligent Grid Coordinating Committee and Emerging Technology Committee for the last five years. He has presented more than 20 tutorials and webinars for grid modernzation for IEEE.