Implementing Smart Grid Standards: A Letter from the Trenches

Lee Margaret Ayers, Assoc. Fellow, IEEE

Abstract -- The stamp of approval has been given by the global community around two standards: the Common Information Model (CIM) (IEC 61979 and IEC 61968) and IEC 61850. Together, these models offer a comprehensive view of the business with an opportunity to allow data from substations to readily flow into utility operational and enterprise systems, thus enabling the smarts of the grid, but there are a number of challenges that must be addressed before the benefits are reaped. CIM and IEC 61850 have been developed to address the needs of two different worlds with fuzzy connection points. Integrating these two models on paper may be relatively simple, but there is a lot more effort involved when it comes to making it work in the real world. And what happens to all the sources of data that exist in pre-standards format today? Once the decision has been made to adopt these standards, the real work begins. This paper will discuss business challenges from the trenches of implementing one of the first real-world applications of a CIM/IEC 61850 harmonized solution. Index Terms—CIM; CIM/IEC 61850 Harmonization; Common Information Model; IEC 61850; IEC 61968; IEC 61970; Interoperability; Smart Grid; Smart Grid Standards.

I. INTRODUCTION he goal of this paper is to address business issues surrounding standards more than the specifics of standards themselves. Typically, the “I” is left from

technical papers, but it is important to preface this article with this distinction. I want to be clear that I am not an expert in the Common Information Model (CIM) (IEC 61979 and IEC 61968) nor IEC 61850, however, my experience gives me unique perspective on the topic. In my early years, I was a programmer analyst with a penchant for economy and reusability of code and eventually evolved to become a Corporate Integrator (involving Geographic Information Systems (GIS) and Supervisory Control and Data Acquisition (SCADA)). I have also implemented wide-scale solutions and over the last twenty years have functioned in the role as a technical architect for integrating real-time systems. So for me, at the end of the day, the topic of standards always boils down to identifying the costs and value to the business. While I may not be an expert in CIM, I participated in its early development (late 1990’s) and have successfully implemented the CIM (AMI meter to SCADA) in my recent past. Today, I am heavily involved in a CIM and IEC 61850-based implementation that spans several utilities. This is not

a Smart Grid or Interoperability test, but one of the first implementations involving CIM, IEC 61850, and the harmonization of the two standards in a real world application. This paper is an introduction to the process and progress around which we will be reporting over the next year. Even at the early stages, there is already much to report. Please note that where CIM is mentioned hereafter in this paper, it is mostly referring to CIM as a logical model rather than the IEC 61968 and 61970 specifications, which are derivatives of the CIM as a model. These specifications facilitate business information exchanges among utility operational and enterprise systems.

II. STANDARDS AT A GLANCE Over the past decade, two standards have been under continuous development and have reached a level of maturity that makes them valuable options for challenges facing our industry today: these standards are the IEC 61850 and IEC 61968/61970 (CIM). What is interesting to note is that these standards were developed independent of each other, and were designed to solve different business cases. CIM began with Control-Center interests and grew two embrace all areas of the business, while IEC 61850 remained doggedly focused on the substation. As the two standards expanded toward each other’s domain, one could say that they missed an opportunity to connect. Then, with the advent of the Smart Grid, it became apparent that information between traditional boundaries (e.g. metering versus grid operations) needed to be shared, and overnight, our perfect world of build-and-deploy-as-needed went up in smoke. Technology could no longer exist in isolation—or if it did, it would continue to do so at great cost. Data needs to be shared, but underlying models and mechanisms for sharing information have impedance mismatch. Could these developing standards bridge the gap? So the industry turned its eyes more seriously upon CIM and IEC 61850, but this time the gaze included government muscle in the form of Smart Grid dollars and Federal endorsements. Since it is perceived that the Smart Grid is somewhat broken until we can more easily integrate data from various systems, the goal has been to adopt technologies that support two-way sharing of information or

T

978-1-4577-0875-6/11/$26.00@2011 IEEE

“Interoperability.”1 This has put increased pressure on the CIM and IEC 61850 standard’s bodies to complete the effort and even harmonize the two—while also putting them on the fast track for adoption.2 It is an understatement to say the industry currently suffers from standard’s fever. After a deep-dive evaluation into interoperability and standards, FERC ruled on July 11, 2011, “…that there is insufficient consensus for the five families of standards under consideration,”[3] and so the industry is (currently) off the hook regarding conformance to communication using the standards forwarded by the National Institute of Standards (NIST). This simply reflects what we already know: standards are not quite ready. However, in the same order FERC still endorses continuation of the work by NIST and others whereby interoperability is still the goal. Even though the standards are incomplete, they are expansive and quite useable already, which is why they came under FERC Order in the first place. So where does that leave companies that are building or bringing new solutions to the market? Each company (utility and vendor alike) will have to quickly evaluate the distinctions between and within these standards and determine if, how or when to incorporate them. There are many ways to push forward. If your company embraces an incomplete standard, you do so understanding that the convention could change, and thereby impact the long-term costs of connecting to standards-based applications in the future. But if one sits on the sidelines until the standards are done, and develops a new solution without leveraging anything from them, the resulting application is in jeopardy of existing as another island of automation—no interoperability. Integration at a later date could incur higher

1 Legislative Mandates: In December 2007, Congress passed, and the President approved, Title XIII of the Energy Independence and Security Act of 2007 (EISA). EISA provided the legislative support for DOE’s smart grid activities and reinforced its role in leading and coordinating national grid modernization efforts. Key provisions of Title XIII include:

• Section 1303 establishes at DOE the Smart Grid Advisory Committee and Federal Smart Grid Task Force.

• Section 1304 authorizes DOE to develop a “Smart Grid Regional Demonstration Initiative.”

• Section 1305 directs the National Institute of Standards and Technology (NIST), with DOE and others, to develop a Smart Grid Interoperability Framework.

• Section 1306 authorizes DOE to develop a “Federal Matching Fund for Smart Grid Investment Costs”, [1].

2 According to NIST, the suites of smart grid standards will: • Provide a Common Information Model necessary for exchanges of data

between devices and networks, primarily in the transmission (IEC 61970) and distribution (IEC 61968) domains (the IEC numbers reference two related groups of standards);

• Facilitate substation automation, communication and interoperability through a common data format (IEC 61850);

• Facilitate exchanges of information between control centers (IEC 60870-6); and

• Address the cyber security of the communication protocols defined by the preceding IEC standards (IEC 62351). [2].

costs. So how does one proceed? Besides carefully, the goal should be to adopt what makes sense and keep your architecture as flexible and adaptable as possible. So the question becomes, can we identify the lowest common denominators when integrating and avoid a costly, spindly exercise in connecting systems?

III. WHERE STANDARDS HELP While there is a lot of hype around the Smart Grid, there is an underlying truth: systems are becoming more connected because business processes need to run across business domains and boundaries. Data collected in one system has value to another. And nothing is more eye-opening than seeing the dynamic interplay of data in a Smart Grid scenario. At one time, the MVA loading on a transformer was only important to an engineer at a control center, but in a Smart Grid scenario, grid operations needs to know that a transformer is reaching capacity so that an automated signal can be sent to a demand response application—which may or may not include communication to smart meters or the Home Area Network (HAN). Today, the way data moves from a substation device, such as a relay or Intelligent Electronic Device (IED), to the corporation is typically via an interface that communicates using a specific protocol, such as DNP3. But, with the exception of the IEC 61850, which has not yet gained wide adoption, most (if not all) interfaces move data from one point to the other using what is referred to as point-to-point links using point names which may or may not carry information about the asset. Point names usually have a source name, which could be a port identifier on a relay, and a target name, which may contain some asset information, such as transformer201.aphase.voltage, which means a measurement value for Transformer 201, A Phase, and Volts. Most of this mapping from the source to target is done and maintained manually (or semi-automatically), which usually produces a number of problems. • Errors can be introduced at each point in the process • Asset names and conventions can vary across divisions. • Assets can share the same name or location (sub names can

be duplicated across divisions). • Multiple devices contained within a sub are deployed by a

variety of vendors and utility employees over a period of years—each of which will have implemented unique conventions for naming and mapping, which complicates substation integration by a factor of devices or diagnostic tests.

• Multiple devices talk various protocols, so the effort to manually or programmatically name, update, add, delete, and change points is labor intensive.

• When points are moved from the sub to a centralized system, if there is no asset reference or model inferred on these systems, then all the points exist in one location in the view—which is akin to having all documents on your computer stored in one file.

o What happens when you forget the name of that asset for the DNP3 interface? Is it the same one the used for OPC?

o As you can imagine, writing applications against this type of structure is also problematic. It requires the code to carry the asset searches for the various asset references with lots of error trapping and tracking.

• When target systems grow from to hundreds of thousands and millions of points, data management becomes a big issue. Manual management of such systems eventually becomes impossible. o Enforcing a naming convention on the large system

helps, but as mentioned earlier, those names will always contain errors, and unless source and target points are dynamically synched, there is no way to edit or delete them when devices change in the field.

• The uniqueness within these systems requires yet more code, or translation code to connect to other unique systems. o Multiple applications have multiple interfaces to

multiple systems. If one application changes, all interfaces break and must be replaced.

• To keep to two systems in synch, one must create a mapping between the two systems with planned updates to any changes.

We might get out of the above integration rat-trap if we can agree upon an underlying model and infuse connect points between source and target systems with a common mechanism for exchanging information (while addressing changes). Provided we can agree on this approach, there are essentially three integration tasks you must consider: 1) implementing or expanding CIM; 2) harmonizing CIM and IEC 61850; and 3) deciding upon your approach for exchanging model information.

IV. IMPLEMENTING OR EXPANDING CIM I find the term, “Common Information Model” very misleading. CIM is actually a reference model that exists in Unified Modeling Language (UML) format3 [4], which I refer to as a paper model. To be useful in an application, it is typically represented in one of the two ways: one, as an interface that is derived from the semantics of the CIM (as a model) in the form of XML Schemas and/or RDF schemas; and two, when a portion of the CIM is moved into a physical model associated with a database. There are procedures for creating a CIM compliant model or exchange format, which, if done right, enables “interoperability,” but because CIM has been developed with an “Open” directive, it must cover a large number of requirements from many communities (international or otherwise). As such, CIM is an extensive, generic model that requires human interpretation for semantics and structure to fit with specific context. It is important to note that “a software product is compliant with the CIM standards if the product is able to expose internal data to external products in a standard way using the CIM objects and classes as defined in an IEC 671968 or

3 CIM references can be found at the CIM User Group website: http://cimug.ucaiug.org/default.aspx [4]

61970 spec”4 so it is important that one understands how to make a qualified CIM model from the start. When building a CIM-based physical model, the objective is to extract from the CIM UML elements your application needs. These elements can then be ported into an application that can ‘build’ or auto-generate a format, such as XML, for input into the physical target database where the model will reside. CIM creation can be cumbersome, and unfortunately, is often easier done with the help of an expert—which is ironic considering that the idea of open systems is to reduce costs. I have seen various approaches to building a CIM model--some of them pretty and others not so pretty. The more “open” the approach, the more complex the process seems to become. Depending upon your adopted “open” technologies, your CIM-based model may touch several applications before it is useable—e.g. 1) view the entire CIM in one tool, 2) export part of the CIM to an application where it is easier to add new elements, 3) import these new elements back into the CIM viewer/UML environment; 4) re-export from CIM UML environment to the application that can take CIM XML (or other formats); and 5) use the target application to create your physical database. The frustration in all this is that even for the smallest addition, the process must be repeated. So when you evaluate products in the market, look for something that will ease CIM creation. The cost will be worth it. A misconception about CIM is that it is a fixed model, but it is not. Each implementation of CIM could be unique. Your implementation of properties contained within a transformer class will likely be different from mine. In the same way the CIM build allows us to create models in a database, the CIM build allows disconnected applications to read and understand each others’ properties. Another nuance about CIM, and understanding how it affects interoperability, is that CIM is a mesh model (though hierarchical views can be created from this). A mesh view of the world offers an intriguing new way for how we think of, utilize and access information. The challenge is, most of our world (the thinking, utilizing and accessing of information) revolves around hierarchies. A common hierarchy for a power system is high-side bus leads to transformer, which leads to low-side bus, which leads to breaker, which leads to feeder and so on down the line to the meter. In a CIM mesh model, breakers and transformers exist at the same level. One can select a breaker and traverse the path down to transformer—essentially taking you back to the top (which is the opposite direction from a meter). The CIM mesh model allows you traverse paths from either direction. From meter, we can find our way back to the transformer. Hierarchies have a definitive begin and end point, but a mesh model can lead you in circles if you are not careful. Since most programming environments depend upon a fixed, hierarchical view of the world, there is an aspect of CIM that is recursive.

4 Details for CIM Compliance can be found at the CIM User group website [5]

So your database or application needs to be able to take this into account. The easy part of adopting CIM is agreeing, yes, a transformer is a member of a specific class and that that classes have properties, such as voltage, and that a transformer is part of Power System Resources, and it inherits properties from x and has specific electrical connections. But adopting CIM won’t always be that easy. Not all IEDs or data from the numerous IEDs in the substation are defined within the CIM, but the mechanism is in place to easily add these new sources. In spite of the fact we have to create new CIM components (e.g. Bushing Monitor and Power Factor), we can report that there is substantial comfort in having adopted a model that has already been vetted by a lot of brilliant minds. This saves time; and time is money. Examples of new CIM elements and methods by which they were created along with isseus will be presented at the 2011 IEEE Meeting.

V. CIM/IEC 618850 HARMONIZATION CIM is an asset-relative model, which understands that transformers have voltages, but it will not know the data came from a Schweitzer relay. Whereas IEC-61850 is an equipment-relative model which knows that the Schweitzer relay has a voltage measurement point, but no real notion that it is connected to transformer 201. The mismatch between the two models is obvious. CIM adds value because it is so expansive in nature. And IEC 61850 adds value because CIM misses a lot of the details contained within the substation. Harmonization work between CIM and IEC 61850 has occurred in the past [6] [7], but this work has been conducted in tests or by standards groups. Few, if any, have tackled a real-world application in advance of industry decisions in this area. There is an optimal way in which both technologies can be combined, but this means that one of the modeling environments must give ground to the other. The links between the two structures is so subtle as to be elegant. Doble perspectives will also be presented at the IEEE Meeting. Doble’s early foray into connecting these two models resulted in some interesting lessons. Unlike CIM (which is a mesh model), IEC 61850 is hierarchical in nature, so you can imagine that when combining the two, there might be issues. If your application depends upon a mesh environment, and it traverses to a point where a hierarchy begins, there is no way to get back to the top, and so your application can hang. If your application expects a fixed hierarchy, or a hard stop when traversing a path, it can get stuck in a recursive track when exposed to a mesh. The database technologies that you adopt will also impact you’re your experience in harmonizing models. A good question to ask is: does your database support a mesh model or only hierarchies? Ultimately, you want a technology that can support both.

VI. APPROACHES TO EXCHANGING MODEL INFORMATION

Many substation plans now call for IEC 61850 integration, but it is likely the authors of that request do not realize that data moved within this structure will not naturally connect to the corporate model (CIM), or that if the data are sent to a SCADA system (which does not talk IEC 61850) all the model information will be lost. But, in this author’s perspective, it is better to implement a standard even if the connected sources cannot leverage it, under the assumption that more systems will eventually support CIM-based standards. Making the decision to adopt CIM and IEC 61850 models is easy in comparison to the debate upon how systems should and will exchange model information, which is why FERC has not yet made a ruling. A lot of work has been done in the area of Service Oriented Architectures (SOA) and Enterprise Service Bus, whereby systems exchange information through a common pipe, known as middleware, or a bus. Source information is typically unpacked from the specific protocol into XML at one end; delivered over the bus; and then repackaged at the far-end into a format (another protocol) the target system can understand. In some ways this can be likened to delivering a packed suit case, unloading it (expanding the message), and delivering this expanded message and then reloading it once you reach your destination. Integration projects might tout that one hundred interfaces had been written to “the bus” and information was successfully moved between targets and sources, but what the publication failed to include is that many of the new interfaces were hard-coded point-to-point links that lacked the robustness of the original interface, and so were poor cousins to established practices, and essentially throw-away. Plus, the volume of data (XML produces a much larger message) was so great, it bogged down delivery of the messages and, thereby, end processes that needed that data. Our understanding of bus architectures is constantly evolving as is our understanding of data. What is important to note is for reasons of security and speed, data (such as A phase voltage) would never be delivered to a control system from a substation over a bus, so why would we move meter or non-operational substation data through a bus? No matter what the source system is, raw data from source systems need to be delivered fast and securely. The challenge FERC has in adopting standards today is in the nature of secure exchange of information, which takes us back to the argument that dealing with one data class separate from another might be a fallacy (e.g. SCADA data should be treated more securely than non-operational data). In the long run, we will likely see that bus technologies are better suited for certain situations, where others require more direct communication due to security and performance requirements. These directly connected systems can also satisfy a common and integrated model infrastructure to facilitate interoperability. Doble’s approach is to leverage the robustness of installed interfaces, from source to target, while infusing a standards-based model-management layer on top of that. Because of the

proprietary nature of this solution, details of the methodology will be presented at the meeting.

VII. SUMMERY One of the fallacies of integrating systems (and even standards) is in the notion that business cases help us better define what needs to be accomplish, but this process often reinforces the subjective view that resulted in limitations in the first place—such as non-operational data must be handled and processed differently than other measurement data (e.g. SCADA relevant data). And when most forays into standards exist merely on paper, the larger integration topics are overlooked. Meter data, which is arguable now part of the operations data set, is still being modeled with a billing-centric focus, and substations still exist in isolation from metering. Business cases (around which developing standards depend) often result in fixed views that are less flexible to change, and only deliver incremental advancements and solutions that are outdated by installation. So it is important that standard’s integration goes beyond development of a paper model. It can be argued that any single technology a company adopts has additional merit beyond the immediate business problem to which it solves. Transformer monitoring is no longer just about health, but the same information can be used to take an asset safely closer to its operating limits, so it is important that information from one system be accessible to others that need it. Information can no longer exist in silos—nor can it be treated in terms of traditional uses. Store data in its original form and let source applications decide how the information will be used. The Smart Grid is about the dynamic interplay of information toward the goal of improving reliability, and better managing costs and our impact on the environment. The goal in adopting standards should be in solving integration issues with finesse rather than muscle—and with ever-an-eye to cost. If we continue pushing for a harmonized model and can evolve our notion of model exchange to the lowest common denominator and thereby minimize costs, we will have achieved something great.

VII. ACKNOWLEDGEMENT

The author gratefully acknowledges the contributions of J. Zhou and his valued input into reviewing and refining the arguments presented in this document.

VIII. REFERENCES

[1] http://energy.gov/oe/technology-development/smart-grid [2] “FERC takes first step in smart grid rulemaking process,” News Release:

October 7, 2010, Docket No. RM11-2-000 http://www.ferc.gov/media/news-releases/2010/2010-4/10-07-10.asp

[3] 136 FERC ORDER 61,039; Docket No. RM11-2-000; Smart Grid Interoperability Standards Issued July 19, 2011; http://www.nerc.com/files/Order_Smart_Grid_Interoperability_standards.pdf

[4] CIM User Group website: http://cimug.ucaiug.org/default.aspx

[5] “CIM Compliance 004,” Report, June 22, 2010, [Online] Available: http://cimug.ucaiug.org/Search/results.aspx?k=CIM%20Compliance%20004&s=Search%20CIM

[6] “Smart Grid Report Explores IEC CIM and 61850 Harmonization”, http://news.thomasnet.com/companystory/Smart-Grid-Report-explores-IEC-CIM-and-61850-harmonization-583044, 2010

[7] "Harmonizing the IEC Common Information Model (CIM) and 61850 - Key to Achieve Smart Grid Interoperability Objectives,” EPRI Report, [Online] Available: http://cimug.ucaiug.org/Harmonization%20Documents/CIM%2061850%20Harmonized%20Model%20for%20Smart%20Grid.pdf

IX. BIOGRAPHY Lee Margaret Ayers joined Doble Engineering in 2010 as the Solutions Manager for the Asset Risk Management System (ARMS), Smart Grid and Knowledge Services. She has garnered twenty-eight years of experience; twenty-four in providing solutions in the power industry, and is a recognized thought leader with a

reputation for innovation. Her recent experience includes a two-year, head-to-toe deployment of a full Smart Grid solution—Xcel Energy’s SmartGridCity™—where she developed the concept of substations as the Roll-up Report Card for the Smart Grid. Throughout her career, she has worked closely with utilities and with SCADA (EMS and DMS), DA, Substation, Metering, Smart Grid and GIS vendors desiring to link real-time data to their applications and throughout the corporation, and received national and international awards for the strategic integration of real-time data (2002 and 2003). She is the author of 40 papers, has been a member of IEEE since 1993 and served in the USAF as an Avionics and Inertial Radar Navigation Systems specialist.