Sunday, June 29, 2014

One Standard – multiple Terms for the same Thing

The Standard series IEC 61850 and IEC 61400-25 define hundreds of new terms for information models and communication models. Usually a term defined in one part and re-used in another part is the same (syntactically and semantically). In some cases you will find different terms for the same “meaning”.

Here is one example to explain what I mean:

The Standard part IEC 61850-7-2 (ACSI) defines in clause

TrgOp [0..2] – trigger option

The attribute TrgOp of type TriggerConditions shall define the trigger conditions (associated to a data attribute of a data object) that may cause a report to be sent or a log entry to be stored into a log.

Three values are defined to be used inside the data object:

dchg data-change A report or a log entry shall be generated due to a change of the value of the associated data attribute

qchg quality-change A report or a log entry shall be generated due to a change of the value of the associated quality data attribute q

dupd data value update A report or a log entry shall be generated due to updating the value of a data attribute. An updated value may have the same value as the old
value. An example is freezing the value of a freezable data attribute updating the value of another data attribute, which could lead to the same value it already has.

The trigger conditions integrity and general-interrogation of the TriggerConditions type are used independent of instances of a data object.

The service parameter IntegrityPeriod is mapped to intgPd: IntgPdintegrity period

IntgPd shall indicate the period in milliseconds used for generating an integrity report.

So far so good – even we have already three terms:

integrity, IntegrityPeriod, IntgPd, or integrity period.

What does part 6 (SCL) define?

<xs:complexType name="tTrgOps">
   <xs:attribute name="period" type="xs:boolean" use="optional" default="false"/>

and for the value attribute of “period”: intgPd="2000" in the report configuration element.

So, we find six terms that mean more or less the same thing … you have to understand what they mean and when to use one or the other!

When it comes to IED Configuration Tools (ICT), you may have to learn new terms again:


Here the SCL attribute “period” is set to true, if the checkbox for “Included in Integrity/Poll” is set.

By the way, these terms describe something quite easy: Push all (!) values of a DataSet every n milliseconds. Without a request from the client. In addition to the cyclic push you may configure the server to report the value of a single signal after it has changed (data change)):


You want to learn how to use the standard? We offer training courses that help you to apply the standards in your daily business! It is more convenient to attend a training than to read all the standards … we have the long-term experience that we would like to share with you.

Friday, June 27, 2014

Version 2 of SystemCorp’s IEC 61850 Stack and API available

The V2.02 of SystemCORP's IEC 61850 library is now available for all platforms. A new demo and evaluation package that runs under Windows is also available. This evaluation provides the DLL (includes Stack, internal IED SCL configuration tool, and API), a server application, and a client application. The demo applications come also with source code in C/C++:


This version supports both Edition 1 and Edition 2 of the IEC 61850 standard, and includes multiple improvements to system communication and memory management.

The following list shows the communication service models implemented:


and these are the API functions:


The API is very convenient and simple!

Click HERE for more general details.
Click HERE for the getting started check list …

We are offering 6 hours comprehensive hands-on training in our standard public training courses like the one scheduled for October 15-17, 2014: 

The most efficient education are offered as in-house training courses.

Tuesday, June 10, 2014

Useful Links for Visitors of the SG Paris 2014 - From Smart Grids to Smart Networks, June 11-13

In order to save paper copies, please find links to some interesting documents I usually distribute during conferences and exhibitions:

"The Beautiful Simplicity of the Integration of Modbus, DNP3, IEC 60870-5-104, and IEC 61850 into a powerful WEB-PLC operating on an Embedded Controller"

com.tom WEB-PLC and Integration of IEC 61850 and IEC 60870-5-104 - This document explains the first steps

"Easy, Affordable and Fast Integration of IEC 61850 in Small Devices". - More about IEC 61850 on IPC@CHIP®.

Personal experience, capabilities, of Karlheinz Schwarz ... introduction on IEC 61850, training modules, feedback from attendees, list of companies, countries, and pictures

Training opportunity 15-17 October 2014 in Frankfurt/Main, Germany

Friday, June 6, 2014


Erich Gunther, Aaron Snyder and Grant Gilchrist, EnerNex have published an interesting article in the SGIP Newsletter, Volume 6, June 2014 Issue:


Their Conclusion is right:

“Often misapplied, the term “standard” is truly only applicable in certain situations. The author of this piece advocates reserving the use of “standard” for de jure standards, especially when employed without the "de jure" modifier. There may appear to be little harm in referring to de facto "standards" simply as “standards,” but this actually dilutes and confuses the definition in the manner that the term "engineer" is often misapplied to functions requiring no engineering education or certification. For example, in these cases, it is preferable to use the applicable term of "specification," "requirements" and "requirements specification" instead of "standard."”

Click HERE for the full article.

So far so good. There are other languages that differentiate between “Standard” and “Norm”, like in German. German “DIN Standards” are specifications that are reflecting a document that has been published with lower hurdles than a “Norm”. The “DIN Norm” compares to the de-jure Standard.

The reality is more complex than just to differentiate between de-jure Standards and other documents. The (de-jure) Standards have to be extended in many cases by non-de-jure Standards: e.g., Implementation agreements that can be written by a Two-party (two vendors, one vendor and one user, one vendor and one testlab, …), an Alliance, Users Group, or standardization bodies.

The future power delivery systems will need many combinations of de-jure (Base) Standards and non-de-jure Documents (Implementation agreements, Profiles, … and even Green-Tissues-List as in case of IEC 61850, IEC 61400-25 – these are documents that are refer to de-jure Standards).

In the end of the day, we want to get interoperable devices to build multi-vendor automation systems for the future power delivery system! Or?

In case of IEC 61850 I see a lot of pressure to come up with more “official” Implementation agreements or Profiles that are agreed by more than two parties, two companies, or two experts.

One good example is the VHPReady Industrieforum.
Click HERE for the current Specification 3.0 in English.

This is a good starting point – it’s not yet the final result … to expected early 2015.

Wednesday, June 4, 2014

MegaWatt Needs Smarter Megabit/s

What do we need? Huge countries need many MWatt (unit of power) to survive. To get the power whenever we want to use it, we need more “Smart Mbit/s” (“smart” data transfer rate in Mega bit per second). That means: more communicating devices … maybe tens of Millions in some time down the road. What do 1,000 MegaWatt (= 1 GW) and 1,000 Mbit/s (= 1 Gbit/s) have in common? These are huge numbers! And more: We need them both in the near future! The crucial issue is here: One needs the other. Zero GW means Zero Gbit/s and Zero Gbit/s means Zero GW.

Yes, you got it! The two are becoming increasingly interdependent!

There is (mainly) ONE medium to carry power: wires. There are hundreds or even thousands of media to communicate information! Guess you could not count them all. In order to keep the cost for the future power delivery system reasonably low, we could and should think of preventing the proliferation of communication systems. Guess you agree. But: Which solutions are worth to use? No doubt: IEC 61850, IEC 60870-5-104, DNP3, Modbus, … are those that would do a good job!

I would be very happy to have as many communication systems as we have power delivery systems: DC 24V, DC 48V, 3 phase AC 110V/60Hz, 3 phase AC 240V/50 Hz, … and a few more.

Clark Gellings (one of the world’s leading experts on the electricity system, ERPI Palo Alto) talked in a podcast about “The Future of the Power Grid”. He talks about crucial aspects of the future power systems. Key issues (from my point of view) are summarized in the following three points:

“So what are a few of the things that will have to happen between now and 50 years from now to make your vision of the grid a reality?

Clark Gellings’ answer:
Well, first, we’re going to need communications standards that allow devices to talk to one another, so that we don’t have the problem we have now. For example, in buildings, the electronics that are being used have as many as 28 different communications architectures. And so one building technology that might control some new thermal storage unit you have may not be able to talk to another device in that building.

Number two, the computer system that would control these millions of nodes in any given region of the United States, they don’t exist. I mean, we can control tens of thousands of nodes, and we do now, but we’re going to need to control millions of nodes. So that’s another area of development.

And thirdly, technology. For example, power electronics to fully be able to control, in a very fluid way, the power systems, even to the point of doing things like having the system self-heal, or taking action so as to mitigate from an outage that it sees, even before necessarily the outage has occurred.”

… sounds very expensive!? Not that much … listen to Clark Gellings.

Click HERE to listen to the podcast, find a link to download the mp3, and read the content.

Anyway, the 28 different communication architectures in the building automation he mentions are not so bad - compared to the factory automation with hundreds of solutions!


why not use the IEC 61158 (solutions)? Because it has too many!


IEC 61850 is about to unify most of them (at least at the near-process level where we find the Millions of signals to be shared between Millions of smart devices). And to provide smarter mechanisms to share information.

I hope we can convert more Mbit/s into “Smart Mbit/s”: using them in a smart way. Using smart communication mechanisms (like IEC 61850) will require less bandwidth and smart power systems will need less MW.