IEC just Published Amendments to Three Core Parts of IEC 61850 as FDIS

Hurrah, after long wait ... now they are published:

IEC just Published amendments of the following three Core Parts of IEC 61850 as FDIS:

IEC 61850-7-2 - Services (57/2100/FDIS) - 138 pages
IEC 61850-7-3 - Common data classes (57/2101/FDIS) - 108 pages
IEC 61850-7-4 - Logical Nodes and Data Objects (57/2102/FDIS) - 422 pages

These amendments will be merged into the previous editions and made available as consolidated documents after FDIS ballot (Edition 2.1).

The consolidated documents (published as INF documents) comprise:

IEC 61850-7-2 (181 pages)
IEC 61850-7-3 (135 pages)
IEC 61850-7-4 (440 pages)

One of the most crucial issue solved now is the harmonization of definitions used in different domains like substation, protection, wind, hydro, DER, batteries, schedules, ...

NOTE: The three new documents (and the many other parts published or underway, e.g., 80-x, 90-x) make the standard series IEC 61850 even more comprehensive and MORE COMPLEX.

I hope that there will be enough people responsible for the future of the digitalization in the energy world understanding that there is no free lunch!! Education and training is key!

IEC 61850-7-2

This edition includes the following significant technical changes with respect to the previous
edition, based on almost 100 tissues ... and other issues.

IEC 61850-7-3

Compared to the second edition, this first revision of the second edition provides mainly clarifications and corrections to the second edition of IEC 61850-7-3, based on almost 100 tissues ... and other issues.

IEC 61850-7-4 

The motivation and goal of the amendment is to improve consistency of the data model over
all application domains of IEC 61850. Data (Logical Nodes, Data Objects, Data Attributes)
with the same semantics shall have the same naming where this part of IEC 61850 refers to
Logical Nodes and Data Objects and IEC 61850-7-3 to the Data Attributes.
Therefore, the amendement complements and updates the second edition of this part of
IEC 61850, which was published in 2010. It constitutes editorial revisions for consistency and
technical corrections of bugs as far as interoperability is touched.
To reach this goal and to keep it for all future as common working source a comprehensive
back-office UML version was created and will be maintained for future standard development.
The published parts of IEC 61850 such as IEC 61850-7-4, on which the amendment is based,
are generated automatically from the UML version. This allows publishing, voting and reading
the various parts of IEC 61850-7 as in the past.
This amendment includes changes with respect to IEC 61850-7-4:2010 based on almost 200 Tissues ... and other issues.

What Does Complexity of a Protocol Mean?

There is always a discussion on one protocol being more efficient and less complex than another or all other. Does this discussion help? I don’t think so.

The key issue is the “SYSTEM” – which is MUCH more than a protocol.

Let’s discuss briefly the configuration of a device with regard to reporting a value based on a deadband configuration and the range and multiplier of an analog value.

Usually the deadband values and range configurations and other crucial information are specified in a pdf file or – if you are lucky – in an excel sheet or XML file. So, to interpret a message the receiver has to know the configuration. The tables contained in the pdf file (below) have to be translated by somebody manually … and how can I find out in 10 years from now, what the limits of the Band width voltage are? Hm. No idea?! Usually you cannot ask the device. So, what now?

I am sorry, if you don’t have the pdf you may guess what the limits are – but you don’t know. Maybe somebody from the vendor is still there and can answer the question.

Example of a DNP3 SPECIFICATION - DEVICE PROFILE

Excerpt on deadbands and configuration:

A good thing is, that many vendors publish these files. Sur, you never know if they are up-to-date or applicable for your device you installed some time ago.

The information models of IEC 61850 provide dedicated attributes for a value that provide these meta data like deadband configuration, min, max, multiplier, SIUnit. These attributes could be used in the corresponding SCL file only or they could additionally be exposed by the device and made accessible through a simple read message.

With IEC 61850 in place we could easily expose the limits of power production and load and further attributes. The logical node MMXU (IEC 61850-7-4) could be used for the limits in which a value is valid:

Data Object TotW of class MV (measured value, IEC 61850-7-3) - Total active power (total P)

could provide the actual value, quality, range, Scale, limits, units, deadband in the details provided through the MV CDC:

mag.f	deadband filtered AnalogueValue coded as floating point
q	Quality
range	ENUMERATED normal|high|low|high-high|low-low (out of range would change quality value)
rangeC	RangeConfig: hhLim hLim lLim llLim min max
sVC	ScaledValueConfig (scale and offset) for Integer values
db	Deadband filter in % of range (min – max)
units	SIUnit and multiplier

min: the min (minimum) attribute shall represent the minimum process measurement for which values of i or f are considered within process limits. If the value is lower, q shall be set accordingly (validity = questionable, detailQual = outOfRange).

max: the max (maximum) attribute shall represent the maximum process measurement for which values of i or f are considered within process limits. If the value is higher, q shall be set accordingly (validity = questionable, detailQual = outOfRange).

In our case, the TotW for the CHP generator may be limited between 0 W (min) and 35 kW (max). A value of “minus 600” MW would have to be flagged as questionable and outOfRange !! Negative values and values higher than 35 kW would be flagged out of range!

The receiver (a control center) could check the limits of the values (either by reading the range configuration online by a service or getting it from the corresponding SCL file). It could figure out that the range is 0-35 kW. Even if the gateway (RTU) would send “minus 600” MW (load) … the CC could understand that this is a bad value – recommended not to use.

The ScaledValueConfig exposes the scale factor and offset value – required to interpret an integer value.

The deadband db defines when to report a new value: when a change of the value is “+/- db of the range”: a range of 100 A and db=2000 (2 %) means –> every change of 2 A will be reported; the last reported value was 78 A, then the next report will be issued when the value reaches 76 A or 80 A.

The units contain the SIUnit (e.g., A) and the multiplier (10**0 –> 1).

The meta-data of the measured value serve as a means to help interpreting the plausibility and validation of a value communicated.

To focus on a message “Report a changed value based on a deadband configuration” and discuss which protocol does it more efficient is not helpful! Modbus can communicate the total Power – as can any other protocol. But: HOW to INTERPRET a received value? Is the value within the limits defined for an application? Is the value given in W, kW, MW or GW??

A system should be able to provide more than just A value – all crucial meta data that help to interpret the value are needed in any case. Either you get it – or …

Please focus on the “System” – a holistic approach is what we need.

This blog post will likely not stop protocol efficiency discussion … ok. And?

If it makes you happy when you discuss protocol issues … do it.

Does IEC 61850 Add Complexity for Technicians in Power Utilities?

This week I was asked the question in the title during an introduction of IEC 61850 to some 15 utility experts. My response was not just yes or no. Initiated by that question I thought it would be of interest to discuss this issue on the blog.

We have to understand that the expected complexity in power system information exchange has at least the following three crucial aspects:

1. Complexity of the network infrastructure (independent of protocols defined and used by standards like IEC 60870-5-104, DNP3, IEC 61850, IEC 61400-25, …). The infrastructure used and discussed these days seems to explode! Compared to dial-up-links and and fixed land lines used usually for remote access of something, the application of Switched Ethernet, Ethertype, VPN, VLAN, TCP/IP, UDP/IP, GSM, UMTS, LTE, … requires a good understanding of your needs and the various solutions that could be used.
2. Complexity of standards (like IEC 60870-5-104, DNP3, IEC 61850, IEC 61400-25, …) that use the above infrastructure.
3. Complexity of communication software and application interfaces between applications and communication software, and complexity of engineering and configuration tools.

In many cases I have experienced that users do have little understanding what they really need! And may even have lesser knowledge about the various solutions, how to use them for their systems, and to understand how they impact the dynamics of the whole system!

I have talked to many people that have complained about the complexity of protocols … but usually we figured out that the complexity was caused by a bit of everything … and mainly by the fact that people tend to NOT TRUST the chain of solutions from, e.g., a control system application to an API of a front-end, front-end application, protocol API, protocol IEC 60870-5-104, TCP/IP, VPN, GPRS, RTU, interface between RTU and remote application, and remote application.

Here is an example I have experienced recently (with the topology based on GPRS as listed above):

1. The control system does not trust that the information exchange with the RTU is reliable and available. Therefore the control system sends Pings every 2 seconds.
2. The front-end application does not trust that the RTU is reliable and available. Therefore the front-end applications issues a 104 control command (toggle bit) every 10 seconds … just to see if the 104 protocol is still alive.
3. The front-end application does not trust (even it figures out that the RTU is available) that the remote application is really receiving a parameter setting for a function in the remote application. Therefore the remote application copies a received setting value to another 104 information object and sends a spontaneous message with the just received setting value.
4. The protocol IEC 60870-5-104 exchanges flow control messages to acknowledge the received messages (in both directions).
5. TCP uses flow control messages and keep alive messages …

So, what do you think about such a bunch of deep mistrusts? Do you think that such a system would work properly and reliable?

I guess that there are many huge GAPS: in the understanding of the NEEDs, the various links in the chain like the dynamics of a system using, e.g., GPRS, … the APIs, the applications …

I recommended to the audience that there is a crucial need for: MORE EDUCATION !! 

A screw driver is not sufficient for future power delivery systems. And: Ignoring IEC 61850 is not sufficient to get the job done! IEC 61850 solutions can be very easy for simple needs.

You can experience it – if you want! Let me know!