Friday, August 26, 2016

Amendment to Power Quality Meter Goes IEC 61850 and IEC 60870-5-104

The recent post "Power Quality Meter Goes IEC 61850 and IEC 60870-5-104" needs some explanation to understand what the Gateway could do.
In the case described in the post, we use one gateway for one power quality meter. Of course this is only one example. A single gateway can acquire signals from many power quality meters from different brands and via different protocols: Modbus I/O, Modbus/TCP, Profibus, ProfiNet, Ethernet/IP, and IEC 61850.
The gateway acts as well as a data concentrator, data manager, or proxy gateway. You may use it for any other signals - outside the power quality application. It may be connected to a substation LAN and tap GOOSE messages flying around.
The nice thing is: It can transform between (almost) ANY protocol without the need that IEC 61850 or IEC 60870-5-10x is integrated directly into the end device like a power quality meter.
In the future we will see more devices that have IEC 61850 integrated into their devices (by using a special piece of hardware or integrated onto the main controller of the device).

Thursday, August 25, 2016

How to Exchange a Voltage Measurement with IEC 61850?

As discussed before you will find a reasonable example to learn the benefits of applying IEC 61850.
Let's look at a voltage measurement:

According to IEC Electropedia we find many names for the same semantic: voltage, Spannung, spenning, ... Ok. These help humans to understand what we are talking about. But what about machines (controllers, SCADA systems, ..)?
They have to use a data type (int16, int32, float32, ...) and a reference (address ...) for a specific protocol like Modbus. Each vendor will likely use different types and addresses.
What's about the scale in applications that use integer? Is the scale known when you read the value of a voltage? Do you know the offset or the multiplier (V, kV, mV, ...)?
How do you know where the measurement is taken in the electrical system (location in the single line diagram)?
Answers to these questions may be found in a set of documents sitting on a shelf or on someones computer - hard to find out if the owner is on vacation.
With IEC 61850 we have a model that could be implemented so that all these details are always accessible online from each device that is a source of measurements:

Phase A voltage has a standard name "MMXU.PhV.phsA" with the value, quality, timestamp, units, and scale. These names are used all over in any IEC 61850 device.

IEC 61850 services allow to retrieve the MMXU model and read the values:

The device has all information to interpret the voltage value for phase A.

Finally we need to know where the value is measured in the single line diagram. IEC 61850-6 (SCL) provides the solution specified as an SCL file (simplified SSD - Substation Specification Description):

The above voltage could be designated as follows:

The value is located in the device "BayController". The device is communication wise identified by an IP Address.

This information really exposes all information needed to interpret a measurement. 
Note that this name needs not to be communicated when the value is reported cyclically or issued by a limit change.The report message could only carry the value, quality and timestamp.
The SCL file has all information to configure the whole system and the devices.
Any question?
Hope you have learned this: IEC 61850 goes very far beyond a protocol! We only need the protocol when we retrieve the selfdescription or read out or report the values.
And: the nice thing is that any device that implements the standard uses the same model, configuration, and services. What else do we need?

If we would apply just a protocol like Modbus then most of the information exposed (directly from the device) through the standard IEC 61850 would have to be stored in paper docs or excel sheets ... 

Once Again: Is IEC 61850 another Protocol?

IEC 61850 and related standards like IEC 61400-25 offer very complex definitions that are intended to ease the life-cycle of the whole system: design, engineering, configuration, operation, maintenance, system extension, documentation, error diagnosis, ...
In my experience with protocols since 1982 (when I started working for Siemens) I have seen (too) many protocols coming and going. I guess I could list several hundred protocols including IEC 60870-5-10x, DNP3, Profibus FMS, Profibus DP, ...

Many experts (especially in the higher management and HR) have years of experience with one or several protocols - working with 600 baud or even 100 Mbit/s Ethernet based links. It happens quite often that those experts are promoted for higher management functions. Many of them have no experience with the approach of IEC 61850. But they often have to decide if, how and when the new technology will be used.

Because of the complexity, they may decide not to use it at all and even not trying to understand what it really could offer their engineers - at least as long as they are the persons in charge.

The real issue is (as Dee Hock, Founder of Visa put it): "The problem is never how to get new, innovative thoughts [IEC 61850] into someones mind, but how to get old ones out." One of these "old ones" is the opinion that IEC 61850 is something like DNP4 or IEC 60870-5-105 -- just another but more complex protocol (MMS, ISO 9506). This (old, too old, wrong) opinion has also a big impact on decisions, e.g., to get a green-light for attending an IEC 61850 training course. Managers and HR often have the opinion: Why do we need this comprehensive training (of 2, 3, 4, or 5 days) for just another protocol? Often the light stays at RED!
We could put it in future in a different way:

  1. IEC 61850 Protocol Training -> 1/2 day
  2. IEC 61850 Services (Client/Server, Publisher/Subscriber, Reporting, Control, Setting Groups, ...) -> 1 day
  3. IEC 61850 Modeling and Models -> 1 day
  4. IEC 61850 Engineering and Configuration -> 3 days 
  5. How to use it for protection, SCADA, monitoring, power generation applications -> x days (depending on what application you have in mind).
If you don't understand what Models and SCL provide ... either take a course or stop discussing it.

IEC 61850 is not intended to replace any other protocol with MMS! In order to harvest the fruits of the application of IEC 61850, you have to look at any other topic than protocols.

But you have to be open to take a closer look at the issues listed under bullets 2 to 5.

You will not get an answer by just reading the standards ... take a course to get a reasonable understanding.

Be an ENGINEER - not just a boss or a leader.
Click HERE for a nice illustration at LinkedIn (or optionally HERE) to see the difference between old approaches and the engineers solution. IEC 61850 is a very big vehicle to carry a lot of loads - to make life easier.

I will post some example to show you the real benefits.

Tuesday, August 23, 2016

Neues Format für viertägiges IEC 61850 Seminar im Dezember 2016 in Karlsruhe

Der Bedarf an guter mehrtägiger Schulung kollidiert oft der notwendigen Anwesenheit am Arbeitsplatz! Die NettedAutomation GmbH hat jetzt eine Antwort für Sie gefunden:

Wir bieten bieten vom

06.-09. Dezember 2016 in Karlsruhe 
drei Seminarblöcke (1 Tag, 2 Tage und 1 Tag) 

an, die einzeln oder in Kombination gebucht werden können. Sie entscheiden selbst, ob Sie nur einen Tag von Ihrem Arbeitsplatz fern bleiben möchten oder zwei, drei oder vier. Je nachdem, welche Zeit und welchen Bedarf Sie haben.

Am ersten Tag wird ein Überblick über das Normungsumfeld und die einzelnen Normen gegeben. Im Mittelpunkt stehen dabei die grundlegenden Eigenschaften und Bedeutung der Normenreihe IEC 61850 für Systemdesign, System- und Geräteengineering, Datenmodellierung, Datenmodelle, Kommunikationsmöglichkeiten (Client/Server, Publisher/Subscriber) und Sicherheitslösungen.

Am zweiten Tag werden die Modellierungsmethode, die vielfältigen Modelle (Logische Knoten), die Kommunikationsdienste und -protokolle und die System-Konfigurations-Sprache (SCL) im Detail vorgestellt.

Am dritten Tag werden anhand vieler praktischer SCL-Beispiele Systembeschreibungen (SSD), Systemkonfigurationen (SCD), Gerätekonfigurationen (ICD und CID für Server/Publisher, Client/Subscriber und Server/Subscriber) diskutiert, erstellt und formal geprüft. Dabei kommt eine Reihe von Werkzeugen und Geräten zum Einsatz.

Am vierten Tag wird das Erlernte in praktischen Übungen mit marktgängigen Geräten und Werkzeugen vertieft.

Sie können den 1. Tag, den 2. und 3. Tag sowie den 4. Tag getrennt oder in jeder Kombination buchen!

Mit unserer Schulung bereiten wir Sie hervorragend auf neue Herausforderungen vor!

Klicken Sie HIER um mehr Details und Anmeldeinformationen herunterzuladen [pdf, 320 KB].

Die mehr als 4.100 Teilnehmer meiner über 230 Seminare seit 2004 würden sicher alle bestätigen, dass das komplexe Thema IEC 61850 unbedingt eine geeignete Schulung verlangt -- und dass wir eine erst-klassische Schulung bieten!

We will offer the same seminar in English from 13-16 Dezember 2016 as well in Karlsruhe (Germany). Details will be available the next days.

Friday, August 19, 2016

New Flyer for IEC 61850 Training conducted by FMTP and NettedAutomation

FMTP (Uppsala, Sweden) and NettedAutomation (Karlsruhe, Germany) designed a new flyer for IEC 61850 training courses:

The flyer lists all crucial topics that are comprised by the various training opportunities: public or in-house, 3, 4, or 5 days ... or as many days you (our customer) want.

In some cases we offered a 1 day introduction course - the maximum number of training days was 11 days (in three sessions) for a big transmission utility in Europe. Another training took 10 days in one block. The maximum number of attendees was 350 for 3 days:

Click HERE for a brief report of the Bangalore event.

You get whatever you need - 
wherever you are, 
whenever you are prepared to get it.
Talk to your management or HR - to get it.
You deserve it!

Click HERE for the new 2 page flyer [pdf, 1. MB]

I look forward to meeting you some time down the street.

Thursday, August 18, 2016

IEC 61859 Training Course in Stockholm is Filling-Up - Reserve your Seat Now

FMTP, KTH, OPAL RT, and NettedAutomation have scheduled a very comprehensive IEC 61850 Training in Stockholm (Sweden) for 19-23 September 2016.
The course is filling-up very fast.
Please reserve your seat as soon as possible.

Click HERE for the brochure with all details.
A similar Course (4 days) is scheduled for Karlsruhe (Germany) 10.-13. October 2016.

See you soon.

Wednesday, August 17, 2016

IEC just published Draft Guidelines for Handling Role-based Access Control in Power Systems

IEC TC 57 just published (57/1764/DC):

Draft IEC TR 62351-90-1, Power systems management and associated information exchange – Data and communications security – Part 90-1: Guidelines for Handling Role-based Access Control in Power Systems

This draft technical report addresses the handling of access control of users and automated agents
to data objects in power systems by means of role-based access control (RBAC) as defined in
IEC 62351-8. IEC 62351-8 defines three different profiles to distribute role information and
also defines a set of mandatory roles to be supported. Adoption of RBAC has shown that the
defined mandatory roles are not always sufficient and that the method for defining custom
roles should be standardized to ensure interoperability. Hence, the main focus of this
document lies in developing a standardized method for defining and engineering custom
roles, their role-to-right mappings and the corresponding infrastructure support needed to
utilize these custom roles in power systems.

Comments are welcome latest by 2016-10-07.

Tuesday, August 16, 2016

IEC 61850: Gateway for Cloud Computing and Fog Computing

Cloud computing and Fog Computing is in principle supported by a single gateway offered by HMS:

  • Bridges any signal from the process level directly to your own or third party cloud.
  • Maps any signal from Modbus, Profibus, ProfiNet, Ethernet/IP, IEC 61850, IEC 61400-25, IEC 60870-5-104 ... to Modbus, Profibus, ProfiNet, Ethernet/IP, IEC 61850, IEC 61400-25, IEC 60870-5-104 ...
  • Provides many logic functions AND, OR, Timer, Counter, ... to build applications.
  • Has digital Input and Output pins.
  • Reads M-Bus.
  • Supports Client, Server, Client/Server, Client/GOOSE-Subscription (with or more Server/GOOSE-Publishers), and Sever/GOOSE-Subscription
  • What else do you need for simple applications?

Click HERE for more information.

Next Hype: Do You Know Fog Computing?

Some 30 years ago the hype was: MAP (Manufacturing Automation Protocol). One of the next hype is "Fog Computing".

"The Manufacturing Automation Protocols (MAP) and Technical Office Protocols (TOP) were the first commercially defined and accepted functional profiles. Both arose because of the operational concerns of two large corporations, General Motors and Boeing. lt is generally accepted that MAP and TOP were the forerunners, first in adopting OSI standards and then in developing usable profiles.
lt all started at the end of the 1970s. GM had on its manufacturing plant shop floors some 20 000 programmable controllers, 2000 robots, and more than 40 000 intelligent devices, all in support of its business. The main problem was that less than one-eighth of the equipment could communicate beyond the limits of its own island of automation; the main inhibiting factor to greater integration being the lack of an appropriate communications infrastructure. As devices supplied were mostly vendor-specific, to do a particular job, they were not designed or optimised to intercommunicate or support each other's functions.
GM finally realised the gravity of their situation when they began to evaluate the cost of automation, attributing half the cost to the need for devices to intercommunicate. To resolve the matter a task force was created comprising representatives from GM's divisions and their suppliers, with the objective of developing an independent computer network protocol capable of supporting a true multi-vendor environment on the shop floor. They used the OSI model and standards as a basis for interconnection and development of further enhancements. " (Source: The Essential OSI, NSW Technical and Further Education Commission 1991)

The first MAP Profile was published in 1982, Version 1.0 in 1984, MAP 3.0 in 1988. Long time ago!

The MAP approach was understood by just a few experts. Most people believed that MAP was too complex, too ... The fieldbusses were thought as the solutions that could cover a kind of Mini-MAP and realtime communication. MAP passed away and hundreds of fieldbusses have been developed since the late 80s. The result was that myriads of automation islands hit the factory floor. These islands where bridged with OPC and so on ... Now we write 2016! Is there anything new?

Not that much. We still have the problem that the sheer unlimited number of (usually raw) signals (measurements, status, settings, ...) are polled or pushed from the sensor and actuator level all the way up to the SCADA level or even higher. This approach of signal acquisition does not scale in the future where we expect thousand of times more devices, sensors, controllers, ... as GM had to manage in the 70s. Does the Cloud Computing solve this challenge? It is unlikely that this (more or less raw data acquisition) will work?

And now? What to do? Use Fog Computing!

"Fog computing is the missing link to accelerate IoT.  It spans the continuum from Cloud to Things in order to bring compute, control, storage and networking closer to where the data is being generated.

The sheer breadth and scale of IoT solutions requires collaboration at a number of levels, including hardware, software across edge and cloud as well as the protocols and standards that enable all of our “things” to communicate. Existing infrastructures simply can’t keep up with the data volume and velocity created by IoT devices, nor meet the low latency response times required in certain use cases, such as emergency services and autonomous vehicles. The strain on networks from cloud-only or cloud-mostly models will only get worse as IoT applications and devices continue to proliferate.  In addition, the devices themselves are starting to become smarter, allowing for additional control and capabilities closer to where the data is being generated." (

Quite interesting that the hype Cloud Computing is seen from a different perspective in 2016.

The approach of IEC 61850 (starting in 1998) is from the very beginning the same as discussed in the Fog Computing community: Compute, control, store, and networking closer to where the data is being generated (at THE process level like in substations or power generation all over). Many information models standardized in IEC 61850 and IEC 61400-25 define distributed functions like protection, active power control or reactive power compensation ... schedules for tariffs, alarming, tripping, reporting by exception (RBE), ... in order to reduce the needed bandwidth and allow for realtime and near realtime behavior.

Lesson learned: Fog Computing is already practiced in the domain of power automation - and based on well defined standards (IEC 61850 and IEC 61400-25)! Both standard series make use of the most crucial standard of MAP: MMS (Manufacturing Message Specification, ISO 9506). It took some 30 years for more people to understand the challenges! ;-) There is nothing new under the sun.

Saturday, August 6, 2016

IEC 61850-90-10 Draft Technical Report on Schedules just published

IEC TC 57 just published the Draft Technical Report:
IEC/TR 61850-90-10 Ed.1.0 (57/1762/DTR)
Communication networks and systems for power utility automation -
Part 90-10: IEC 61850 objects for scheduling

Closing date for voting is 2016-09-30

Schedules establish which behavior (e.g., tariff 1 or 2, mode 1 or 3) or expectation (e.g., forecast) is applied during specified time periods. A schedule consists of a series of entries with a setting for the value of a setpoint, the selection of a particular mode or the value of a parameter for a mode.
There are different ways to operate a scheduled entity based on the following operation principles:

  • The actual values of a scheduled entity (e.g. active and reactive power produced or consumed) are directly controlled using setpoints and controls. For example, the DER system reacts on changes of the setpoints or on controls (e.g. start or stop the DER system) in real time.
  • The functional behavior of a scheduled entity is configured to operate in a mode in which it responds to locally sensed conditions (e.g. Volt-VAr Mode in case of DER) or externally provided information (e.g. prices). 

The schedules offer a very powerful functionality that can be used in many different applications.
Currently we have two major applications in Germany  that make use of the schedules: 
  1. VHPready
  2. FNN Steuerbox
NettedAutomation has implemented the most crucial concepts on an embedded controller used in the HMS gateways.

More to come soon.

Thursday, August 4, 2016

What is a Critical Infrastructure?

According to Wikipedia:
"Critical infrastructure is a term used by governments to describe assets that are essential for the functioning of a society and economy - the infrastructure."

The first three infrastructures listed are:
  1. electricity generation, transmission and distribution;
  2. gas production, transport and distribution;
  3. oil and oil products production, transport and distribution;
  4. ...
Many other areas could be taken into account - all domains where we have some automation in one form or another you may or may NOT TRUST. So far we have trusted our teachers, our employers, our parents, our car, our friends, our banks, our electric power delivery system ... There seems to be a change coming step by step.
What could we all do about it? 
For our family we have just decided to install a 9,8 kWp Photo Voltaic system on our roof. This is - hopefully - a power harvesting machine we could trust ... as long as the sun is shining.
The latest issue discussed is on "Election Systems" according to the FederalNewsRadio:
"The Homeland Security Department is actively considering whether it should add the nation’s election system — or the individual systems that 9,000 local and state jurisdictions use to collect, tally and report votes — as an entity that needs DHS protection from cybersecurity attacks."

What if we put it all under the new term "Critical Everything" (CE)?
All depends on human beings we have to trust! I want to be such a person - my wife, my family, our friends, you, ... can trust.

When we engineers develop something, we should pay a lot of attention to make the "something" robust, safe, ... better safe than sorry.

Let's do our best in the interest of all our societies.