IEC 61850 Lessons Learned 2016 04-11

Editor's Notes

• #2: Good morning and thank you for your interest in today’s presentation. My name is Kevin Mahoney, President and Integration Specialist at Casco Systems., the Control & Automation Solutions Company. For the past 15 years Casco’s team of engineering and integration specialist have worked extensively providing solutions to the power generation and transmission industry. Today we offer a range of services for protection, control, automation, integration and operational technology applications. First I would like to thank our hosts from the University of Maine for the opportunity to be here today and our sponsors from the Maine IEEE & OMICRON for their generous support. Most importantly I would like to thank you, the attendees, for helping to make this a successful and informative event. Like most of you here today our focus at Casco is on the power industry. We are excited by the prospect of employing technology in an intelligent way to address the industry’s need for advanced automation, protection, control and security solutions. Our topic for this conference, IEC-61850, is a technology that will enable the industry to provide more efficient, reliable and secure power delivery & production. This morning I plan to share with you some of the lessons learned as Casco Systems developed a new automation & integration platform for Central Maine Power Company’s next generation substation. This journey began over six years ago when Casco was selected as the system integrator for the Maine Power Reliability Program (MPRP). Along with our associates at Relay Application Innovation, Burns & McDonnell and CMP’s Protection & Control Engineering Department; we were tasked with not only developing a platform with enhanced functionality, but also implementing new and evolving technology used to underpin the entire system. The core of this platform, as John Freeman explained, was based on the IEC-61850 standard which we will discuss, and Alex will review in detail later today. The goal of my presentation is to review many of the “Lessons Learned” as we executed the design, programming and testing of 345/115kV bulk power substations for MPRP. To best illustrate the lessons learned, I will present a series of questions that were answered during the development, implementation and commissioning process. These questions and the corresponding answers embody the lessons learned over the course of this five year, $1.4B project; and subsequent projects that were constructed using the resulting reference design.
• #3: So what exactly is IEC-61850? The following is a brief overview of the IEC-61850 standard which will be covered in greater detail by Alex later today.
• #4: In a complicated industry with many facets, it is useful to put 61850 and other standards into context. The IEC has developed a graphical overview of the more than 300 standards that apply to “Smart Grid” applications. This Reference Architecture may be found online at http://smartgridstandardsmap.com. With this tool you are able to identify any given standard in relation to its role within the Smart Grid. The map defines the entire industry from generation through consumption on the horizontal axis, and from markets to field devices along the vertical. The stated goal of this map is to allow users to “Easily and instantly identify the standards that are needed for any part of the Smart Grid – no need to be a standards expert”. While I question the later part of that statement, this graphic does a great job of defining the use cases each standard addresses and can be filtered to show the portions defined by 61850.
• #5: IEC-61850 is a communication and engineering standard for electrical substation automation systems. It defines a common set of features and functions that allow interoperability between different vendors and products. This view of the reference architecture diagram filters out areas not directly impacted by 61850. As you can see the standard touches upon a wide cross section of the industry but is primarily focused on the Operation, Field, Station and Process levels.
• #6: So what exactly is IEC-61850? Is it a Modbus or DNP style communication protocol on steroids, a design standard, or something else altogether? The first "Lesson Learned" was that IEC 61850 offers a complete set of specifications covering all communication issues inside a substation. The objective of the IEC group that developed and continues to enhance 61850 was to specify requirements and to create a framework necessary to achieve interoperability between IEDs designed by different suppliers. So the IEC-61850 standard is much more than just a communication protocol such as DNP3 or Modbus. IEC-61850 comprehensively defines the engineering process, data and service models, conformance testing, and the entire communication process within substations. Included in the standard are a station data model and multiple messaging services to address the needs of different applications within a typical substation. In short, IEC-61850 is much more than a protocol. It is a standard that defines a communication approach for electrical substations which includes data modeling, a family of protocols, and associated performance requirements. We’ll look at each of these aspects of IEC-61850 briefly and then review many of the Lessons Learned along the way. NOTES ON IEC-61850 STANDARD UPDATES Per the IEC website the most recent release of the standard is the IEC 61850:2016 SER series which has the following sections. IEC TR 61850-1:2013 IEC TS 61850-2:2003 IEC 61850-3:2013 IEC 61850-4:2011 IEC 61850-5:2013 IEC 61850-6:2009 IEC 61850-7-1:2011 IEC 61850-7-2:2010 IEC 61850-7-3:2010 IEC 61850-7-4:2010 IEC 61850-7-410:2012+AMD1:2015 CSV IEC 61850-7-420:2009 IEC TR 61850-7-510:2011 IEC 61850-8-1:2011 IEC 61850-9-2:2011 IEC PAS 61850-9-3:2015 IEC 61850-10:2012 IEC TS 61850-80-1:2008 IEC TR 61850-80-3:2015 IEC TS 61850-80-4:2016 IEC TR 61850-90-1:2010 IEC TR 61850-90-2:2016 IEC TR 61850-90-4:2013 IEC TR 61850-90-5:2012 IEC TR 61850-90-7:2013 IEC TR 61850-90-8:2016 IEC TR 61850-90-12:2015 Technical Specifications (TS) - Technical Specifications are often published when the subject under question is still under development or when insufficient consensus for approval of an International Standard is available. Technical Specifications approach International Standards in terms of detail and completeness, but have not yet passed through all approval stages either because consensus has not been reached or because standardization is seen to be premature. Technical Reports (TR) - Technical Reports contain collected data of a kind different from that normally published as an International Standard, for example data obtained from a survey carried out among national committees, data of work in other international organizations or data on "the state of the art" in relation to standards of national committees on a particular subject. A Publicly Available Specification (PAS) is a publication responding to an urgent market need, representing either a consensus in an organization (e.g. manufacturers or commercial associations, industrial consortia, user group and professional and scientific societies) external to the IEC or a consensus of experts within a working group. Key features of IEC 61850 from the IEC website: As in an actual project, the standard includes parts describing the requirements needed in substation communication, as well as parts describing the specification itself. The specification is structured as follows: An object-oriented and application-specific data model focused on substation automation. This model includes object types representing nearly all existing equipment and functions in a substation – circuit breakers, protection functions, current and voltage transformers, waveform recordings, and many more. Communication services providing multiple methods for information exchange. These services cover reporting and logging of events, control of switches and functions, polling of data model information. Peer-to-peer communication for fast data exchange between the feeder level devices (protection devices and bay controller) is supported with GOOSE (Generic Object Oriented Substation Event). Support of sampled value exchange. File transfer for disturbance recordings. Communication services to connect primary equipment such as instrument transducers to relays. Decoupling of data model and communication services from specific communication technologies. This technology independence guarantees long-term stability for the data model and opens up the possibility to switch over to successor communication technologies. Today, the standard uses Industrial Ethernet with the following significant features: o 100 Mbit/s bandwidth o Non-blocking switching technology o Priority tagging for important messages o Time synchronization of 1 ms A common formal description code, which allows a standardized representation of a system’s data model and its links to communication services. This code, called SCL (Substation Configuration Description Language), covers all communication aspects according to IEC 61850. Based on XML, this code is an ideal electronic interchange format for configuration data. A standardized conformance test that ensures interoperability between devices. Devices must pass multiple test cases: positive tests for correctly responding to stimulation telegrams, plus several negative tests for ignoring incorrect information. IEC 61850 offers a complete set of specifications covering all communication issues inside a substation.
• #7: The Substation Data Model outlines a method for consistently defining data and attributes for any piece of equipment in the substation. The abstract data models defined in IEC 61850 can be mapped to any number of communication protocols.  As you can see from this graphic the Substation Data Model is used to represent real world, physical attributes of the substation in a virtual data structure. This data structure can then be easily mapped into various communication protocols and devices for consumption. While legacy protocols have typically defined how bytes are transmitted on the wire, they did not generally specify how data should be organized in devices in terms of the application. This approach required engineers to manually configure objects and map them to variables and low-level register numbers, index numbers, I/O modules, etc. In this respect IEC-61850 is unique as in addition to the specification of the protocol elements (how bytes are transmitted on the wire), it provides a model for how power system devices should organize data in a manner that is consistent across all types and brands of devices. In theory this should eliminate much of the tedious system configuration effort because the devices can configure themselves and the data points are self-documenting. The IEC 61850 device model begins with a physical device. A physical device is the device that connects to the communication network such as a protective relay or other IED. Within each physical device, there may be one or more logical devices. Each logical device contains one or more logical nodes. A logical node is a named group of data and associated services that is logically related to some power system function. For example there are logical nodes for protection, the names of which all begin with the letter “P”, logical nodes for metering and measurement, the names of which all begin with the letter “M”, and so on. In this way an entire power system can be represented in a abstract data model.
• #8: The abstract data models defined in IEC 61850 can be mapped to any number of protocols, including those defined in the standard. Current mappings in the standard include: GOOSE (Generic Object Oriented Substation Event) MMS (Manufacturing Message Specification) SMV (Sampled Measured Values) FTP (File Transfer Protocol) HTTP (Web Services) These protocols can run over TCP/IP networks using high speed switched Ethernet to obtain the response times appropriate for the application. This includes response times below four milliseconds necessary for protective relaying.
• #9: The transmission times specified in the requirements column of this table are the maximum times allowed for a data exchange through a communications system. This term is vague but is usefully defined as the time duration between the action of communicating a value from the logic processing of one device to the logic processing within a second device as part of an application. As you can see the maximum times vary depending on the response requirements of a particular application. So in summary IEC-61850 is a standard that defines a communication approach for electrical substations including data modeling, a family of protocols, and associated performance requirements.
• #10: So, what did we learn while applying IEC-61850 on multiple MPRP substations?
• #11: Our experience on MPRP showed that the nature of the design shifted complexity from the physical to virtual realms. While the hardware design was simplified the complexity of the network system and application software grew substantially. For example most “equipment to relay” and “relay to relay” interconnection wiring was eliminated, simplifying the hardware design, reducing cabling & component counts, and lowering installation costs. However at the same time all of this functionality needed to be recreated in the virtual realm by the use of GOOSE messaging. IED settings now needed to incorporate messaging and logic to support the transfer of information and to allow for testing and maintenance features. Of course with the Operational Technology Network (OT LAN) carrying this critical traffic, network design and redundancy became much more complex. The OT LAN must be fault tolerant with no single point of failure and guarantee performance to meet the <4ms response times dictated by the protection requirements.
• #12: An example of traditional, worse case hardwired implementations using cabling and serial connections is on the left. An advanced, 61850 based system is shown on the right. As you can see there are significant savings in wiring, components and complexity.
• #13: IEC-61850 is sometimes described as self-documenting. However a "Lesson Learned" from our experience is that while 61850 devices use human language naming conventions they are often far from intuitive or self documenting. In general IEC-61850 names, while standardized, are not easy to use. And given that the standard allows each vendor latitude in naming, a wide variety of styles have been found. For example these two points represent the status of a GOOSE Message Failure indicating point in SEL-421 and GE-L90 relays. While the point means the same in both cases, the structure of the name is different depending on the vendor’s implementation.
• #14: That being said 61850 at least provides the framework within the standard for self-documenting naming conventions. Unlike legacy protocols that map data to indexes or addresses, 61850 allows vendors to select naming conventions suitable for the application. In this example a single binary status point is mapped to DNP Object 30, Variation 1, Index 3; to Modbus Coil 10003, and to IEC-61850 variable name Relay1/XCBR1$Health$stVal. The intent of the standard is that vendors will all use a common, standard naming convention. However to date many vendors have chosen to implement conventions that while meeting the standard’s technical requirements don’t achieve this goal.
• #15: While interoperability is the goal of 61850, it is far from assured or easy. Being a new protocol, the first edition of IEC 61850 had issues that each vendor solved differently, leading to more than a few interoperability issues. The second edition should solve that problem and lead to better vendor to vendor interoperability. However even after adoption of the second edition, each vendor will be free to implement different subsets, meaning that interoperability will always be measured in degrees that need to validated. For utilities that are searching for exchangeability of IEDs from different vendors, much work remains to be done. It is possible to reach a level of system specification that will allow interoperability AND exchangeability of IEDs from multiple vendors! However to get there: You need to request something more than just "IEC 61850". MPRP used IEC-61850 capable equipment from at least seven different vendors, each with their own unique implementation. Let’s explore some of the differences in naming conventions between them.
• #16: This table reflects binary status point naming conventions as implemented in various devices. While there are some similarities between names used in different devices there are also many differences. These inconsistencies make working with the software tools challenging for the human engineers and technicians who must use these tools!
• #17: This table reflects analog point naming conventions as implemented in various devices, in this case there are even greater variations.
• #18: Traditional documentation has shown to be insufficient for IEC 61850 applications and new forms need to be created to represent all features.
• #19: GOOSE MAPS: With traditional documentation information on GOOSE messages would be scattered throughout multiple documents, different IED tools and specific descriptions. So, virtual wiring maps called "GOOSE Maps" were developed, with the information flow, sources, destinations, descriptions, addresses, etc, as shown. These documents associate the publishers and the subscribers, their messages, links and descriptions.
• #20: GOOSE MAPS: With traditional documentation information on GOOSE messages would be scattered throughout multiple documents, different IED tools and specific descriptions. So, virtual wiring maps called "GOOSE Maps" were developed, with the information flow, sources, destinations, descriptions, addresses, etc, as shown. These documents associate the publishers and the subscribers, their messages, links and descriptions.
• #21: LOGIC DIAGRAMS:IED Logic Diagrams were developed to provide a graphical representation of the custom logic within each IED, as well as all real and virtual I/O points, LEDs’, etc. This is an invaluable tool for the design, commissioning and technical support staff working with these devices over their entire life cycle. While not unique to 61850 applications, the LD’s took on increasing importance as the relay’s logic escalated in complexity.
• #22: Memory Maps are critical to building the model of a particular relay or device. We learned that two types of maps where required. SCADA MAPS: The first is the traditional SCADA map which defines all analog, status and control points provided to SCADA. This map was enhanced by providing additional information to aid in commissioning and troubleshooting, new data included the IED’s RTU Point Alias, IEC-61850 Point Name and IED Element Name. This allows tracing of a point from SCADA through the RTU and down to the IED. IED MAPS: The second type of map defined all of the data available from a given IED. This was a superset of the data required by SCADA and included points for the local HMI, SCADA, DME, SER, and DSD systems. This map showed all of the data points being pulled from a particular IED and reflected where they would be used. The local HMI’s on MPRP had anywhere from 1,500 to 11,000 tag names with the majority of these being IEC-61850 points. Data mapping was critical to organizing the design and ensuring that all desired functions were properly implemented.
• #23: The simple answer is NO, generally speaking the overall system is more complex. This complexity is driven by multiple factors: The ability to work in the new “virtual” world requires a skill set that is different from traditional P&C systems. The availability of additional data enables increased functionality necessary to address business drivers.  The implementation approach taken by some vendors ties protection functions much more closely with integration functions. With less separation between integration and protection complexity and risks increase.
• #24: The simple answer is NO, generally speaking the overall system is more complex. This complexity is driven by multiple factors: The ability to work in the new “virtual” world requires a skill set that is different from traditional P&C systems. The availability of additional data enables increased functionality necessary to address business drivers.  The implementation approach taken by some vendors ties protection functions much more closely with integration functions. With less separation between integration and protection complexity and risks increase.
• #25: We found over the course of MPRP that not all of the data we were interested in was exposed via the vendor’s IEC-61850 interface. In some cases the data existed in the relay but simply could not be provided from the relay’s logic to its communication interface. In other cases data was available but not in its native location within the relay, requiring remapping and additional logic to make the data available. In still others customization of the IED’s CID file was necessary to remap values.
• #26: Monitoring of IED and network status is critical. In our implementation every single communication circuit, device health status point and trip path was continually monitored to ensure system integrity. While the entire system was designed with no single point of failure, immediate detection of network or device problems was critical to ensuring the system performed as expected when faults occur. We learned that at a minimum the following are required: Device Health: Monitor each device for internal faults, power supply problems, or other issues typically monitored by the manufacture's watchdog functions Communication Health: Monitor communication between all IED’s and other devices. For example IED to IED GOOSE message traffic is monitored and failures alarmed. Similarily RTU/HMI to IED traffic is monitored and alarmed. Network Health: Monitor each communication path to ensure both primary and secondary links are functioning properly. The design provides for switchover to backup paths automatically when a primary fails. This insures correct system functionality, but also alerts operations staff so that repairs can be made in a timely fashion. Trip Path Monitoring: With our 61850 implementation much of the tripping was done via GOOSE messages. Therefore features were built in to allow periodic testing of each relay’s trip path to verify system integrity.
• #27: Our experience indicates that interoperability tests in a lab setting are critical to project success. Our expectation is that the need for lab testing will decrease as the standard and vendor implementations mature, but for now this is an invaluable tool to ensure the SAS works as expected and the project is kept on schedule.
• #28: Implementation, commissioning and maintenance of 61850 systems requires a host of new tools. This includes items such as: Protective Relay Test Sets such as OMICRON’s CMC 850 or Doble 6150 IED Browsers such as OMICRON’S IED Scout Substation Configuration Language (SCL) Configuration Software such as SEL Architect or Triangle Microworks SCL Forge Text Editing & Comparison Tools such as NotePad++ or WinMerge Network Traffic Capture and Analysis tools such as WireShark IED Specific Configuration Software
• #29: IEC-61850 requires the extensive use of networking and software tools not previously required. Therefore prior to the adoption of this new platform the technical work force necessary for the design, commissioning and maintenance of these systems requires extensive training. A mix of old and new skills is required. Basic automation coupled with advanced network communications, 61850 design philosophy, automated testing and configuration tools, and new testing skills for site engineers and technicians are needed. Overall there is a lack of technical knowledge on the IEC standard, computer networks and supporting tools. All of this combines to demand more training for all involved.
• #30: In every design there are literally 1,000’s of decisions to be made. When moving to a virtual platform the number of options grows exponentially. Therefore well written standards that consider the multitude of applications & options need to be constructed in order to bring a level of consistency across a given fleet of substations. While no two locations will ever be identical, the better samples and go-bye documentation is constructed the more consistent the end result.
• #31: Support from the vendor community is crucial. Over the course of MPRP we identified in excess of 100+ firmware or software bugs that could only be addressed by the hardware and software vendors. As products and standards mature this should become less of an issue, however; front line vendor support is critical to the success of a 61850 project for the foreseeable future. We found significant differences in the support provided by various vendors. In particular smaller manufacturers tended to purchase 61850 interface modules from third parties and integrate them into their existing product. This results in another layer of integration problems (between the module and product) and a lack of understanding of 61850 at the IED vendor. Unlike DNP3 or ModBus which are well understood in the vendor community, support for 61850 is not as readily available.
• #32: The initial IEC 61850 projects were more costly than a traditional solution mainly because of the networking functionality and extensive configuration required; however, they provide greater flexibility to manage the system, along with requiring less maintenance and providing better monitoring and system performance. Important savings should be realized in subsequent projects from engineering design reuse and system cloning. In addition IEC 61850 projects offer a simpler way to expand systems in the future as changes to interconnections can be done in software. Networked systems also increase system reliability by having IEDs close to switchyard equipment connected via fiber-optic cables, which reduces commissioning tasks and construction related work.
• #34: Thank you very much.