E3 Group for Studies on IEC 61850 Went Public

I have reported earlier on the very appreciated “Teamwork” of Spanish utilities in working together to reach a higher level of interoperability in IEC 61850 multivendor projects.

Their objective is (from their website):

• Share information among companies and walk together through IEC 61850
• Generate a minimum common specification (available for download at the Documents page) of an IEC 61850 substation automation system (SAS) that should be valid for the companies in the group
• Lead the technological gap between now-available IEC 61850 systems and the desired final picture
• Improve efficiency and optimise IEC 61850 deployment

The E3 group went public:

Click HERE for their group Website.

Mapping IEC 61850 on Web Services

Just a few hours after my post on

Message Specification and Encoding – A Never Ending Story

earlier today I received an email with a very interesting contribution on the mapping of IEC 61850 on Web Services from my friend Wolfgang Maerz (Dortmund/Germany). Wolfgang is one of the few senior utility experts involved in IEC TC 57 – even after he retired from RWE many years ago, he is still very active in IEC TC 57 standardization work. He has implemented protocols on his own … to study the details! He “hired” me as a consultant in the early nineties to support IEC 60870-6 (ICCP) and later IEC 61850.

Please find his very detailed contribution on the Web Service mapping (I post this information with his permission):

“Here are some fundamentals to IEC 61850 over MMS versus IEC 61850 over Web Services:

As I wrote in my last email Web Services is a strongly typed communication system using a WSDL (Web Service Definition Language) XML type and service specification for mainly two purposes: (1) check the correct syntax of XML-messages, (2) allow the creation of the SEI (Service Endpoint Interface) including the binding (or mapping) of XML to the application business object types of any language (Java, C#, ..).

Fundamental of Web Services is the strict separation of XML message values and their XML type schema which is part of the type declaration of the WSDL implemented at both sides of the communication system using document / literal style. This means that for Web Services the types of communicated values must be known “before” any communication takes place by its WSDL.

The problem is that some services of IC 61850 are of dynamic nature as shown by the example of the 61850 Report-Control-Block (RCB) class model. The report service of the RCB sends reports from the server to the client based on the dynamic structure of the Report Format Specification to allow spontaneous transmission of altered event-driven objects of any type. The receiving application to decode this dynamically created type must know this type!

This cannot be mapped to static WSDL specifications. Possible would be a WSDL with a sequence of choice types as in MMS but a possible implementation is not known and is even conceptual impossible. Of course you can use any-type in the WSDL and use Web Services as a simple type transparent messaging service but that only moves the problem with no communication interface as SEI directly to the application.

So, what is then the fundamental difference between IEC 61850 over MMS and IEC 61850 over Web Services when it comes to dynamically created types? The point is the encoding!

MMS is written in ASN.1 using the Basic Encoding Rules (BER). With BER, the encoding of every data value in an abstract syntax is constructed in TLV-style (Tag, Length, Value): The three parts here are actually termed identifier (I), length (L) and contents (C). The important thing to mention here is the identifier part which consists of one single octet with three parts: tag class (2 bit for universal, application-wide, context-specific, private-use), form (1 bit for primitive or constructed), and INCLUDES the tag number defining the type (5 bit, e.g. decimal 16 means type Integer)!

THAT MEANS:

With MMS / BER the type information is INCLUDED in the message and allows the client / server to even understand dynamical event-driven or service created messages of any type not even known before runtime!

This is in contrast with Web Services / WSDL where the type of XML-message values is defined separately BEFORE runtime in the WSDL’s XML type and service definition used to implement the (static) SEI (Service Endpoint Interface).

If all this is true this would mean that IEC 61850 over Web Services would be restricted to a specific domain or to certain use cases with reduced requirements where only a subset of IEC 61850 can be used. Most think Web Services is simple compared with MMS, I do not think so.”

Comments are welcome.

IEC 61850, IEC 61400-25 and DNP3 at Remote Conference

2 day Seminar (NettedAutomation) on Power System Automation, Configuration, and Communication covering IEC 61850, IEC 61400-25, DNP3, NIST Interoperability Roadmap, Smart Grids, ...

Nashville (TN, USA) at Remote Conference

20.-21. September 2011

Click HERE for more detail and registration information.

Become smart before your system will become smarter!

Message Specification and Encoding – A Never Ending Story

Some 30 years ago I started studying digital communication like IEEE 802.4 (Token Passing) and IEC 802.3 (Ethernet) when I worked for Siemens. The “war” between the Token Passing supporters and the Ethernet friends caused a lot of struggle and generated many solutions to find a common way for information exchange in automation systems. One of the approaches was to make Ethernet deterministic. I invented a simple algorithm that used the three states of the transmission line: no-carrier, carrier and collision. The solution allowed a semi-deterministic behavior of Ethernet … the solution was patented in 1985.

Click HERE for the European Patent EP 0110015.

Unfortunately Siemens did not implement the patent – the direction was towards Token Passing

The international project MAP (Manufacturing Application Protocols) preferred Token Passing … then fieldbusses arrived … MAP opened the way for Ethernet – too late (or too early).

Ethernet “came” back some 10 years later, when it was obvious that traditional fieldbusses were quite limited in many aspects. Today Ethernet is the preferred solution in automation systems (industrial and power domain). Switched Ethernet has ended – to some extent – the wars on Data Link Layer solutions.

The communication wars for crucial automation domains are still ongoing! There are two issues discussed again and again: the approach of services and message encoding. What services are required (Get, Set, Event reporting, Event logging, Control, …) and what is the best message encoding method (abstract/concrete, XML schema, ASN.1, XML encoding or binary encoding like ASN.1 BER)?

The questions that are most crucial: What should be carried in a message? How many implicit or explicit content is needed to be carried in each message? How often has a message be sent/repeated? … and many other questions have a huge impact on the SYSTEM behavior. The focus should be on the SYSTEM and not on the encoding or message schema.

The most efficient encoding is to send an empty message! Really!

Click HERE for the story about a very efficient message.

It is quite interesting that old standards like Ethernet, TCP/IP and MMS have survived – even they are not the most efficient ways to communicate!

Why are they so successful – even in the electric power automation world, which is one of the most conservative markets? These standards are open and accepted globally!

I hope that the developer and users of automation systems will focus on the APPLICATION and SYSTEM ASPECTS – and not on communication layers 1 to 7!! The systems and applications based on open international standards will help to keep the power – more efficiently – flowing. IEC 61850 is one of the most crucial open standard.

The fastest way to get your information flowing with IEC 61850 information models, services and messages is: Develop your application using a simple IEC 61850 API. I have trained many experts in how to use IEC 61850 and a simple API to solve their APPLICATION needs!

Click HERE to evaluate such a simple API.

The power industry is short of experts – hope the remaining resources will focus on the applications and not on questions like: How can we optimize the message encoding, how can we save bits on the wire, … ?

Focus on the Applications!

IEC 61850-8-1 Edition 2 Published

IEC 61850-8-1 Edition 2 has been published (English/French):

Communication networks and systems for power utility automation - Part 8-1: Specific communication service mapping (SCSM) - Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC 8802-3

Click HERE for a Preview of IEC 61850-8-1.

Other parts with status Edition 2:

Preview Part 4 Edition 2

Preview Part 6 Edition 2

Preview Part 7-2 Edition 2

Preview Part 7-3  Edition 2

Preview Part 7-4 Edition 2

What is a Stack?

The term Stack has many meanings, flavors,  … ask 10 experts and you may get 11 definitions. People talk about an IEC 61850 stack, an OPC UA stack, .... What do these mean? Are they comparable?

Let’s start with the general definition:

According to the Wikipedia: “The protocol stack is an implementation of a computer networking protocol suite. The terms are often used interchangeably. Strictly speaking, the suite is the definition of the protocols, and the stack is the software implementation of them.”

So, the software that processes the protocols is called the (protocol) stack.

With regards to IEC 61850 this can mean many things: Session, Presentation, ACSE, MMS, ACSI, MMS-SCSM, Model management and configuration language, API to the application, … let’s have a look at the server side of the communication:

	“Protocol” aspects	Remarks and Explanations
1	API to application	Control of Server SW, local services for read, write, events, control, … “Protocol” that defines how the application can communicate with the underlying IEC 61850 software.
2	Models, model management and model and ACSI configuration language	Describe the server’s information model and binding to application (LDs, LNs, DO, DA, …) Be aware that LNs have also services and protocols (see below for LN GLOG). The information models has to be organized in the IED’s software (including retrieving the self-description of the model)
3	ACSI (Abstract Communication Service Interface)	The (protocol) software has to implement the services Association control, retrieve self-description (Server, Client, Publisher, Subscriber, LD, LN, DO, DA, ControlBlocks, …), Get, Set, DataSet services, Reporting (events), Logging (events; historian), GOOSE, Sampled Values, Control, File services, time synchronization, … The implementation of the protocols that define the dynamical behavior of the services are one of the crucial parts of IEC 61850.
4	MMS SCSM	The ACSI services use MMS to carry the payload between client and server. MMS provides the serialization of (service) messages. Example: A Buffered Report Control Block is a quite comprehensive “Service” model with a set of service parameters (for control block attributes). The state machine of the Control Block requires a bit of a software!
5	MMS	Simple classes like NamedVariables, NamedDataSets, Journal, … Message schema (encoding using ASN.1)
6	ACSE	Kind of a remote procedure call
7	Presentation	Concrete encoding: ASN.1 BER
8	Session	Session between client and server
9	RFC 1006	Binding OSI upper layers to TCP
10	Security	Security according to IEC 62351 … TLS
11	TCP/IP	you know …!!
12	Lower layers	…

Note: GOOSE and Sampled Value messages are mapped directly to Ethernet!

What is the Logical Node GLOG? An application or a model with services and protocol (messages)? The GLOG is a standardized application that defines a model, services and a protocol! Guess you did not expect this … others may not agree with me …

IEC 61850-7-4 Edition 2 defines:

“5.7.4 LN: Generic log Name: GLOG
The LN GLOG refers to a function which allows to log not only changed data itself but also any related data being defined in the settings of LN GLOG. The logging is started by the changed data object (TrgRef1) or by the operator (LogTrg). The logged data are identified by the references to the related source data objects in the data model.” This in short the state machine of the GLOG service model and protocol (in abstract terms). The GLOG communicates with a client via services and a protocol …

The logged Data Values will be stored in an IEC 61850 Log … it can be queried by services from a client.

Let’s come back to our question, what is implemented in a stack?

Stacks from different vendors may be for free, may be reasonable priced, or may be expensive! What does this mean? Almost nothing! Because the CRUCIAL question is: WHAT would you get for your Euros or Dollars?

A stack of vendor X may cover the implementation described under bullets 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10.

A stack of vendor Y may cover only 5, 6, 7, 8, 9, and 10.

The difference is tremendous: The efforts to implement the requirements listed in bullets 1, 2, 3, and 4 are (to my experience) likely more than 90 … 95 per cent of what needs to be implemented with regard to IEC 61850!

If you hear something like “the stack so-and-so is cheaper …” listen twice and then think about what you have heart three times and ask what that stack really provides four times AND ASK PEOPLE WITH EXPERIENCES WHAT IS LEFT FOR YOU TO DO to get a compliant IED !!! I have talked to many experts that were surprised that it took sooo long … and cost sooooo … much to get a compliant IED.

When it comes to the comparison of OPC UA and IEC 61850: Listen very carefully, and ask questions … and then … and then you may understand the difference from a standard and from an implementation point of view.

Click HERE if you want to experience what could be provided by a specific stack providing integrated software for issues 1 to 10 … with little left for you [German].
A workshop in English may be set up when you are interested … let Beck IPC know that you would attend a workshop in English.

Open Position for Protection Engineer with IEC 61850 Knowledge at Stadtwerke München

Stadtwerke München (Germany) has an open position for planning of substation automation and protection as well as telecontrol … experiences in IEC 61850 and IEC 60870-101/104 are required.

Click HERE for the job description [German].

Open Position for Development Engineer with IEC 61850 Knowledge at Phoenix Contact

Phoenix Contact (Bad Pyrmont, Germany) has an open position for a Development Engineer for applications in embedded systems. If you have knowledge in programming embedded platforms, in substation automation, in IEC 61850 … you may be the right person for that job.

Click HERE for the job description Job-ID: 1145 [German]

Network Rail (UK) to improve reliability and cutting cost with IEC 61850

The Head of Electrification of Network Rail (UK) talks about the benefits of applying IEC 61850 for the electrification the other day. Please find an excerpt below:

“Ah, indeed. I’m personally really excited about this [IEC 61850] because I think it
represents a huge step forward.” followed by statements like:

“IPC 61850 allows us to distribute the power – still enabling us to switch
– but limiting the number of fault breaking devices we need. This has two
benefits. The first is that this makes the switching less costly.”

“But the second benefit is that we will no longer have to compromise
between the electrical distribution needs of the system and the railway
operations needs of the train operating people.”

“It will enable us to think very carefully about using switching to focus on
achieving better reliability for the operators while still maintaining that
essential feature of distributing power … all at what looks to be at a
considerable saving.”

Click HERE to read the interview.

Schnelleinstieg in die Produktentwicklung IEC 61850 und IEC 61400-25 konformer Geräte

Beck IPC (Pohlheim bei Gießen) bietet eine eintägige Schulung für den Schnelleinstieg in die Produktentwicklung von Geräten mit einer Schnittstelle nach IEC 61850 und IEC 61400-25 an. Neben einer konzentrierten Einführung in IEC 61850 und IEC 1400-25 lernen die Teilnehmer, wie sie während kurzer Zeit (Stunden anstatt Wochen!) die Normenreihen integrieren und sich auf die Implementierung ihrer Anwendungen konzentrieren können.

Mit den Beck IPC Lösungen gelingt der schnelle Einstieg in IEC 61850 und IEC 61400-25.

Die Schulung findet am 05. Juli 2011 statt.

Klicken Sie HIER für weitere Details.

White House Policy Framework for 21st Century Grid

The White House has published today “A Policy Framework for the 21st Century Grid: Enabling Our Secure Energy Future”.

“The report delineates four overarching pillars that the Administration will pursue in order to ensure that all Americans benefit from investments in the Nation’s electric infrastructure. These pillars describe how we can move forward to secure benefits of a smarter grid:

1. “Scale what works” to enable cost-effective smart grid investments
2. Unlock the innovation potential in the electricity sector with a continued focus on open standards
3. Empower consumers with education, access to their own energy usage information in consumer- and computer- friendly formats, and improved privacy safeguards and consumer protections
4. Continue to secure the grid against natural or other disasters.”

Click HERE to download the report [PDF].

The speakers of the event “Building the 21st Century Grid" focused on the need to change the way how we generate, transport, store, distribute, and use electric power. There is a high potential for convert to a more efficient electric power system. One key player in this regard is to apply open standards.

Secretary Mr Chu (DoE) said: “We have no authority …” to force the market to do this or that … all the Government can do is keep the R&D and discussions going on – and expect that the most efficient solutions (on how to generate, transport, store, distribute, and use electric power) will win the battle.

Several global “winners” are already known: Standards published by IEC TC 57 and TC 88 like IEC 61968/61970 CIM, IEC 60870-6 ICCP, IEC 62351 on Security, IEC 61850 on utility automation, and IEC 61400-25 on Wind Turbine Communication. These “standards will [according to the report] not be mandatory. In short, regulators should publicly embrace the interoperability standards with the understanding that they will continue to develop with the ongoing evolution in smart grid technology …” [page 29].

In some cases the continuation of development will be very slow, e.g., in ICCP. While other standards, like the information models in CIM and IEC 61850 will continue to grow while we go. The technology will not be frozen (it cannot stop to develop)! That’s good news!!

One of the crucial aspects is that NIST and the DoE do obviously not expect that myriads of competing (de jure) standards should be embraced! … like in other industries.

Today is a good day for the standardization efforts!

Keep going!

I hope that the power industry will now stop discussing protocols … and start or continue to focus on APPLICATIONS using these standards. The standards are just a vehicle or a tool box. Meters, models and protocols do not make a Grid Smart! It is the Smart People that will use the standards and build many applications using them!

Building the 21st Century Grid – The White House reports today

On June 13, 2011, the White House will hold an event on "Building the 21st Century Grid." Starting at 10 a.m., the event can be watched live at http://www.whitehouse.gov/live.

Federal Smart Grid Initiatives highlights key government-sponsored programs and activities related to the development and modernization of the electric grid in the United States.

One of the four pillars of the future grid is:

Unlock the innovation potential in the electricity sector with a continued focus on open standards.

I hope that the electric power industry will follow a few open standards instead of a myriad of solutions. Could you imagine a situation were each state or county would have a different frequency and voltage of the electric system!??

There are two main standards: 230V/50Hz and 110V/60Hz … but there should be one standard to exchange information (measurements and statuses, …). The MMXU (a measurement model of 3 phase electrical system defined in the open standard IEC 61850-7-4) could be used for any kind of 3 phase system.

Click HERE for some more models.

If you are interested you may watch the event today.

Comment on second Draft Release Smart Grid Roadmap of NIST

The Draft NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 2.0 is now available for public comments.

NIST solicits comments on the draft Release 2.0 document.

Due to the fast growth in various aspects of Smart(er) Grids, it is required to speed up in the selection of the needed and recommended standards. IEC 61850 is one of the crucial standards for Smart(er) Grids!!

Click HERE for the SGIP website with more details on the draft.

The list of standards comprises also DNP3 as a new IEEE standard.

Click HERE for the draft list of standards … which states on page 2:

“Because the Smart Grid is evolving from the existing power grid, NIST has also included standards that support widely deployed legacy systems. Priority Action Plans (PAPs) have been established with the goal of resolving interoperability issues between the standards for legacy equipment and those others identified for the Smart Grid. For example, PAP12 seeks to enable implementations of the Distributed Network Protocol, DNP3.0 as specified in IEEE 1815, to work with implementations of the IEC 61850 standard …”

This will definitely help to tap the information provided by the running systems! … without replacing one protocol (DNP3) by another (IEC 61850-8-1, MMS).

IEC 61850 and DNP3 are becoming good FRIENDS … keep going!

IEC 61850-9-2 FDIS of Edition 2 open for Ballot

The IEC 61850-9-2 Edition: Communication networks and systems for power utility automation – Part 9-2: Specific communication service mapping (SCSM) – Sampled values over ISO/IEC 8802-3

is open for FDIS ballot until 2011-07-29.

Changes comprise:

• Addition of an optional Link redundancy layer
  Link Redundancy:
  Parallel redundancy protocol and high availability seamless ring
  IEC 62439-3, Amendment 1
• Redefinition of “reserved” fields in link layer
• USVCB and MSVCB components
• Encoding for the transmission of the sampled value buffer

IEC 61850-8-1 Edition 2 approved as International Standard

The 2nd Edition of IEC 61850-8-1 has been approved with 100 per cent support by the national committees of IEC TC 57.

IEC 61850-8-1 Ed. 2.0: Communication networks and systems for power utility automation - Part 8-1: Specific communication service mapping (SCSM) - Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC 8802-3

The standard will be published soon.

This mapping has been implemented in many IEDs. Even in the wind power market, this mapping is the most crucial mappings … the other four mappings defined in IEC 61400-25-4 may be implemented as well.

Please note that most of the changes and corrections have been implemented by many IEDs, because many of them have been made during the edition 1 Tissue process. The first Tissue goes back to 2005.

Click HERE for the list of Tissues for part IEC 61850-8-1 Edition 1. The green Tissues are those that have been solved already – most of them are required for conformance testing. IED’s TICS (Tissue Implementation Conformance Statement) have to indicate which of the green Tissues have been implemented.

Click HERE for a sample TICS document.

8-1
#116 GetNameList with empty response?
#165 Improper Error Response for GetDataSetValues
#183 GetNameList error handling

Click HERE for further details on Edition 2 of IEC 61850-8-1.

New Version of SystemCorp’s IEC 61850 Software

After the first certified IED using the SystemCORP Embedded Technology IEC61580 Library (PIS10) SystemCorp has published information and documentation about the latest Version (1.36.02) today. This version comprises all modifications, fixes and extensions that take many experiences and the successful conformance test at KEMA into account.

A comprehensive set of easy to browse web html pages are available.

Click HERE for more details on the updated stack software and documentation of version 1.36.02.

More details can be found HERE and HERE.

This new version runs smoothly on the Beck IPC Chip and other embedded controllers on LINUX, …

The interest in IEC 61850 Chips is growing very fast – all over.

Transformer Protection and Monitoring IED with IEC61850@Chip

C&S Electric Ltd (India) has developed a Transformer Protection and Monitoring IED with an IEC 61850 interface build on the Beck IPC Chip “IEC61850@CHIP” with SystemCorp’s IEC 61850 solution integrated.

Click HERE for more technical information.

Podcast from Black and Veatch on IEC 61850 in the U.S.

A podcast provided by Black & Veatch reports how IEC 61850 is expected to be accepted in the U.S. power industry. It is also reported how American Electric Power uses the GE BRICK solution for the interface between the control room and the switch yard.

There is no doubt about the trend towards IEC 61850 in North America!

The GE Brick solution is based on IEC 61850 concepts. Many benefits provided by IEC 61850 are offered by the Bricks – except one crucial issue that is not supported: The Brick solution is NOT interoperable with fully IEC 61850 compliant IEDs like protection and control devices or merging units according to IEC 61850-9-2.

An IED with an IEC 61850 interface can NOT communicate with the Brick! So, the Brick is a vendor specific solution using mainly fiber optic cables and Ethernet and message formats from IEC 61850 to replace copper wires to the switch yard. The idea of an open international standard for multi-vendor systems is supported by fully IEC 61850 compliant merging units and other IEDs (as publisher) and other IEDs (as subscribers).

Click HERE for listening the podcast [some 14 minutes].
Click HERE for more information on the concept.

Certified IEC 61850 compliant IEDs

KEMA has published a Test Register for conformance tested IEDs:

• IEC 61850 Client Systems
• IEC 61850 Server Devices
• IEC 61850 Ethernet Switches
• IEC 61850 Sampled Value Publishers (Merging Units)

Click HERE to access the test register dated 2011-01-27

Telecontrol and IEC 61850

IEC 61850 is used in many applications inside substations and other domains. RTUs from many vendors provide IEC 61850 support for Telecontrol.

Click HERE for a set of 27 slides of an applications of ABB RTUs (used as substation control system) in 12 substations of Stadtwerke München [German].

Click HERE for Information about ABB’s RTU 560 [English]

Click HERE for a description of an programmable device from WAGO that can be used for Telecontrol (RTU) [German]