Smart Grid Labs

A Tale of Two Clouds: Where Are You Using Your Standards?

by Grant Gilchrist, Principal Consultant

You hear a lot about the use of “cloud computing” in Smart Grid systems today.  The idea seems to be that instead of a utility building and maintaining its own Energy Management System (EMS), Distribution Management System (DMS), or Meter Data Management System (MDMS) hardware and software, it buys them as services from a provider.  The provider has a central “server farm” somewhere that it keeps up-to-date with the latest technology for the benefit of the utility.  The utility’s operators log into these systems via the web (presumably with sufficient security controls in place) and operate their power system through this interface.

In principle, this sounds like a great idea, especially for small utilities with smaller budgets.  The utility gets the benefit of the latest technology without the costs of building and maintaining the system.  The provider can do all the building and maintaining and still offer the service at a reasonable price because of economies of scale; they are doing this for more than one utility, after all.

But what if the utility becomes dissatisfied with the service of the provider?  How easy is it to switch providers?  Is the utility forever tying its success to that of the provider?  To me, the key question here is, “Where are you using your standards?”

The answer to that question lies with the location of the Front-End Processor, or FEP.  In either a Supervisory Control and Data Acquisition (SCADA) network or an Advanced Metering Infrastructure (AMI) network, this is the bottleneck in the system through which all the data gathered by the meters, sensors or other devices must pass.  It goes by a variety of different names, such as head-end, data collector, master station or network manager, but for the purposes of this discussion, let’s call it a FEP.

Consider two different “cloud computing” topologies:

• FEP in the Cloud.  In Figure 1, the connections from  SCADA or AMI networks are brought to the provider’s site and the FEP for the data is located at that site.  If it is necessary to switch providers, it is possible because today these connections are largely standardized, using protocols such as ANSI C12, IEC 61850, DNP3, Modbus and others.  The only problem is that depending on the technology, there may be a lot more than one connection to move from one provider to another, and a lot of provisioning and configuration to change.
• FEP at the Utility.  Figure 2 solves these problems by locating the FEP at the utility.  So only one connection, from the FEP to the provider, needs to be moved if providers change.  The problem here is that the standards for this kind of interface are very new, and it’s not certain that the provider and the utility will both have implemented the same standard in the same way, if they use standards at all.  The two leading standards suites here are IEC 61968/IEC 61970 (Common Information Model) and MultiSpeak. It is possible that the cloud provider may not be using either one of these technologies, but will attempt to use a proprietary method.  A second issue is that this connection will have to carry a lot of data, with required latencies ranging from 2 seconds (typical SCADA) to every 15 minutes (aggressive AMI) to once a day (typical AMI).

So if you’re considering moving your utility applications to the cloud, I recommend:

• Make sure all your interfaces to the provider are standardized, meaning from the SCADA or AMI network to the provider, not just from the provider to the operator.
• When developing your business case, consider carefully not just the cost savings of using a cloud provider, but also the relative costs of switching providers if you become dissatisfied with them in the future.

These two recommendations are just a specific way of phrasing the rule that we at EnerNex have been promoting in general for years now:

To minimize the impact of changes on your network, first clearly identify some well-defined points of interoperability, and then apply appropriate open standards to those critical points.

This rule applies equally well whether the changes involved are technological changes, organizational changes, or vendor changes.

Lastly, it is important to remember that the choice of where to deploy standards is only one of many factors that should be considered when making this kind of decision.  Some factors which should be considered when thinking about using “the cloud” include:

• Significant changes in business processes, with corresponding retraining costs.  Consider the impact on new substation installation, configuration, testing, disaster continuance, backups, and so on.  For AMI systems, consider customer move-in/move-outs, provisioning, forecasting, outage management… and the list goes on.
• Responsibility for NERC CIP and overall reliability requirements.  Does the cloud provider now have to follow NERC rules?  Do they have to file reports to NERC?  Will the utility take full responsibility and hold their cloud provider harmless for reliability violations?
• Performance concerns.  As noted earlier, the entire utility data set will now be shipped to another organization in “real-time”, whatever that term means to the application.  Sometimes this organization may be in an entirely different state or province.  The impact of such a massive data transfer on latency could be very significant.

Choosing to use “the cloud” may be a cost-effective way for smaller utilities to develop a smart grid.  But as with all outsourcing decisions, it should not be taken lightly.

Figure 1 – Front End Processor in the Cloud

Figure 2 – Front-End Processor at the Utility