IEC 61850 To Help Securing Process Automation Systems

A Hacker Tried to Poison a Florida City's Water Supply ... the attacker upped sodium hydroxide levels in the Oldsmar, Florida, water supply to extremely dangerous levels ... Within seconds, the intruder was attempting to change the water supply's levels of sodium hydroxide, also known as lye or caustic soda, moving the setting from 100 parts per million to 11,100 parts per million. 

Click HERE for a news report.

How could that happen? Who knows!

There are a lot of discussions complaining about missing security measures like VPN, etc.

Independent of the communication security it is a big mistake that the value could be set to such a BIG number: 11,100 ppm.

IEC 61850 could help to prevent such a situation by applying Analogue Setting model:

At the City of Oldsmar water treatment facility, the "maxVal" of Sodium Hydroxide injection may have been limited to 500 ppm ... as a consequence, there would be no way to configure this to 11,000 ppm.

And: in case somebody changed the value at all, the setMag would change and dchg would become true issuing a report or log entry ...

With the SCL (System Configuration Language, IEC 61850) it could also be configured (in SCL notation) that a particular configuration value could not be changed at all (Fix), changed by a service (Dyn), or changed by SCL only (Conf).

For Input signals there are many specific configuration attributes defined ... 

It is very difficult to convince programmers, managers, R&D people, any other group ... to apply the IEC 61850 Tool.

Hope that will slowly change ... 

Additional discussion by Jake Brodsky click HERE ... summarizing: "... The more self integrity features we include, the more reasonable process limits that we include, the safer we will be."

IEC 61850 und eCl@ss - Interoperabilität durch standardisierte Informationsmodelle

Interoperabilität durch standardisierte Informationsmodelle

Der „eCl@ss“-Standard ermöglicht den digitalen Austausch von Produktstammdaten über Branchen, Länder, Sprachen oder Organisationen hinweg. Wie ein Produkt nach „eCl@ss“ mit Merkmalen nach IEC 61850 ganzheitlich zur Interoperabilität auf den Ebenen Produktbeschreibung, Systemengineering, Gerätekonfiguration, Informationsaustausch und Protokolle ergänzt werden kann, zeigt der nachfolgende (frei herunterladbare 5-seitige) Beitrag im etz Heft 12/2019 (Link siehe unten):

Hier klicken, um das gesamte etz Heft 12/2019 inklusive des obigen Beitrags (Seiten 30-35) herunterzuladen. 

OPC-UA@TSN, Profinet@TSN or CC-Link@TSN - and IEC 61850

Automation and industrial communication are buzzwords for decades. They mean something quite different when you look at the 80s, 90s, 00s, 10s, today ... Where are we today? Not really far away from the 80s.

In February 1985 I attended the first time the GM MAP Team in Detroit (MI) - it was a cold week:



This was my first trip to the USA. At that time I did not expect to come back to the US for more than 130 times ... almost all trips related to standardization: MAP, MMS, UCA, IEC, IEEE, ...
The MAP (Manufacturing Application Protocol) project and especially the MMS (Manufacturing Message Specification) standard where the first combined attempt to define a single set of  international standards for manufacturing automation systems. As you may know: they failed - because they were far too early.
MMS (ISO 9506) defines many services that have been smiled at. But if you read today (2019-02-23) what experts in the OPC/UA World are looking at - then you wonder how it was possible in the 80s to define most of the basic services the industry is looking for TODAY:

• Client/Server
• Selfdescription
• Read/Write/Report
• Two-Way-DataExchange (like RPC)
• Standard Configuration
• Semaphore
• Event Management
• Journaling (Logging)
• ...

It really took 30+ years before the industry understood what is really needed besides the myriad of Fieldbusses!!

Since the MAP days we have learned some crucial lessons:

• In addition to Client/Server we need Publisher/Subscriber (as defined some 15 years after the MAP project in IEC 61850; GOOSE and Sampled Values)
• In addition to ISO/OSI Transport we need TCP/IP ... done in IEC 61850.
• We need many semantic models ... as the many Hundred Logical Nodes in IEC 61850, e.g., for electrical measurements MMXU or Temperature Supervision STMP, ...
• Standardized system configuration is key for any future automation system ... as defined in SCL (IEC 61850-6) for energy systems.

Fieldbusses are understood today as the "maximum credible accident". Heinrich Munz (Lead Architect Industry 4.0 at KUKA) says in the just published special issue ot the magazine "tsn & opc ua 2019" (www.computer-automation.de) on page 12: "Jeder Gerätehersteller muss die Anschaltung und das Engineering jedes seiner Produkte an mehr als zehn unterschiedliche Feldbusse entwickeln und pflegen - ein betriebs- und volkswirtschaftlicher Super-GAU." [Each vendor has to develop and maintain hardware and engineering tools for each of his products to be compliant with more than 10 different fieldbusses - economically a maximum credible accident.]
My personal resume after reading through the special magazine is this:

• The third fieldbus war started some years ago and is expected to go on for many years. 
• The standard series IEC 61850, IEC 62351, IEC 61968/70 (CIM), IEC 61400-25, ... provide most of what OPC-UA and TSN are looking for.
• It is likely that the providers of traditional and Ethernet-based Fieldbusses will migrate during the next years to OPC UA and TSN.
• OPC UA and TSN will be implemented and used - why not?
• In the meantime the energy domain is already using and extending the semantic models, applying the needed services and feeling happy with the standardized configuration language.
• What else do you need?

The French novelist Andre Gide nailed it when he wrote, "Everything that can be said has been said, but we have to say it again because no one was listening."

According to my 50 years of experience as a technician, the most crucial challenge in automation is this: People of different application domains (control center, RTU, protection, PLC programming, robot controlling, communication, security, engineering, maintenance, ... telecomms, internet, web, ...) DO NOT LISTEN TO EACH OTHER!!! If one expert of a specific domain talks - no one from the other domains is listening!
Talk together and have a look at what people have said and done even decades ago! It may be better than what you were told. It may save you hours and days and weeks ... of struggling.

Configuration Description Language for Extensions for Human Machine Interfaces

IEC TC 57 just published a very interesting committee draft for machine support of automatic mapping the SCL models to HMIs:

IEC 61850 (57/1984/CD):
Communication networks and systems for power utility automation –
Part 6-2: Configuration description language for extensions for human machine interfaces

Closing date for comments: 2018-06-01 

"This International Standard describes how the graphical components and their interactions
found within HMI applications are to be described using the Graphical Configuration
Language (GCL) and the HMI Configuration Language (HCL). It will describe how the
graphical elements – described in GCL – are to be bounded to the IEC 61850 elements
defined by IEC 61850’s System Configuration Language (SCL). ..."

The following excerpt from the CD gives an impression on how the HMI configuration is intended to be automatically derived (supported) by a new graphical configuration namespace:



Wow, this is really a major step forward!

First Amendment of IEC 61850-4: System and Project Management

IEC TC 57 just published the IEC 61850-4 Amendment 1 (57/1922/CDV)
– Communication networks and systems for power utility automation
– Part 4: System and project management

The main extensions of the edition 2 are:

1. New sub-chapter 5.3.6 describes the engineering tool workflow and its chronology (which SCL files are exchanged in between configuration tools) through 3 use cases: the classical use case, the change of system tool and the interaction between 2 projects.
2. New sub-chapter 6.4 talks about backward compatibility and deals with replacement or extension whatever the component is provided by the same or different manufacturer. To do so, it scrutinizes through 4 use cases, what kind of impacts could be acceptable for IED or tools.

The ballot closes 2018-02-02.
The CDV (committee draft for vote) is accessible for PUBLIC comments by every interested person.

Note that the amendment has already been blended into the edition 2 document for easier reading: 57/1923/INF

These extensions answer a couple of questions that come up during every seminar and in many discussions. They are extending the explanations of SCL (part 6).
The document is worth to study.

IEC TC 88 Started Work on SCL for Wind Power Plants

WOW! IEC TC 88 has published a new work item proposal (88/621/NP) for the specification of extending the SCL (System Configuration Language):

Wind energy generation systems –
Part 25-7: Communications for monitoring and control of wind power plants –
Configuration description language for communication in wind automation systems
related to IEDs

The objective of the NWIP is to describe the adoption of the System Configuration description Language (SCL) defined in IEC 61850-6 to the wind domain

"This part would extend the IEC 61400-25 series with a file format for describing communication-related IED (Intelligent Electronic Device) configurations of a wind turbine, wind power plant controller, metrological mast etc. The extension of SCL to wind domain would simplify integration of wind power plant equipment as well as their integration to the electrical system. The adoption of SCL allows formalised tool based exchange of IED parameters, communication system configurations, switch yard (function) structures, as well as description of the relations between them.
The purpose of this format is to formally and efficiently exchange wind turbine and wind power plant IED capability descriptions, and system descriptions between IED engineering tools and the system
engineering tool(s) of different manufacturers in a compatible way. The file format is also intended for providing report configuration and alarms as well as HMI interface information from a wind power plant. This information can be used to engineer overlying SCADA systems for the site, for connected DSO, TSO or fleet operators maintenance and surveillance systems. Finally, the SCL is intended as a documentation of the configuration and topology of the delivered system."

WOW! Why a WOW? During the fist years of standardization of the series IEC 61400-25 the proposal of applying and extending the SCL (IEC 61850-6) did not find enough support to start working on the issue! Time is passing and more and more experts understand the advantage of SCL!

Good luck.

How to get Interoperability and Interchangeability with IEC 61850?

The standardization process in the context of IEC 61850 is picking up quite fast. As you have learned in the posts of today and older ones, there are several new topics on the list of items to work on for future new parts of IEC 61850.
One of the crucial objectives is the interoperability and INTERCHANGEABILITY of devices from different vendors in a multi-vendor system.
To reach this goal, we need standards! Sure. But what is absolutely required is the EDUCATION of experts from Vendors, Utilities and System integrators.
We offer the right courses for you: With focus on protection, automation and SCADA.In English and German.
Due to the request from power engineers FMTP and NettedAutomation have scheduled several dates for public training courses in 2017:
The next courses are:

19-23 September 2016 in Stockholm, Sweden [EN]
10-13 Oktober 2016 in Karlsruhe, Germany [EN]
07-09 Dezember 2016 in Karlsruhe, Germany [DE]

Click HERE for more details.

Hurry to reserve your seat!

You would get more than in any other course - because two of most experienced experts (Andrea Bonetti and Karlheinz Schwarz) will guide you through the most crucial aspects of IEC 61850. The combined experience of the two is unparalleled.

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:
MySub_400kV_3A63_BayFunction_ABC/ACMMXU1.PhV.phsA

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.

IEC 61850 DLL Demo with Looging and Log-File

The DLL Demo based on SystemCorp’s IEC 61850 Stack/API can very easily be configured with the corresponding CID-File for the Server to log data attributes listed in a DataSet. The log entries are stored in an XML file.

All you need to do is: Add the following 3 lines in the configuration file (after line 52):

Directory: /Resources_localhost (/Resources_2machines)
File: /VHPServer_localhost.icd (/VHPServer_2machines.icd)

<LogControl datSet="BHKW_ST1" intgPd="0" logEna="true" logName="DLLDemo" name="DLLTestLog">
    <TrgOps dchg="true"/>
</LogControl>

Restart the Serer and you have a log that is filled with events coming through the DataSet "BHKW_ST1".

Model as seen by an IEC 61850 Client (Browser):

The file format (DLLDemo.Xml) is vendor-specific:

Two Log Entries (4 and 5):

Note: The time stamp “t” is “000…0” because the Server application program is not providing it to the Stack … this could be done by extending the C# application source code that comes with the Demo package … if you are familiar with C# programming.

The services QueryLogByTime and QueryLogAfter will be available in the future.

The Log Model is available in the SystemCorp Library. It means, e.g., it is available in devices like the HMS SG line. The log file may grow very fast … be careful not to consume all memory resources. In the future the file will represent a circular buffer so that it will never overflow (by overwriting the oldest entries – as defined in IEC 61850-7-2).

There is a possibility to convert the XML coded Log file into another XML based file: COMFEDE („Common Format for Event Data Exchange") published by IEEE.

Click HERE for Information on COMFEDE (DE).
Click HERE for Information on COMFEDE (EN).

Click HERE if you are interested to download the DLL Demo.

Question & Answer: Are “valKind” and “valImport” related?

The configuration of systems and IEDs with IEC 61850 tools (system tools, IED tools, protocol stacks) is a challenge for people involved in power system protection, monitoring, and automation.

I guess that you have some experience with the many rules and the underlying philosophy that are crucial for the correct operation of interconnected IEDs.

Quite often it is obvious how to apply a given rule in the configuration language (IEC 61850-6 SCL). First of all: You have to take into account the standard document AND the green tissues!

Example on the relation between “valKind” and “valImport”. Tissue 804 introduces the new attribute “valImport” in an SCL document:

http://tissue.iec61850.com/tissue/804

The need for that “valImport” attribute is discussed at the bottom of the tissue 804. The solution is well defined.

The two attributes can be applied for data attributes configured in an SCL file. There are two different categories of data attributes:

1. Models of “process” related information, e.g., scale factor of an Integer modeled measurement.

2. Models of “communication service” related information, e.g., Trigger options or integrity period of a report control block.

If in a SCL document (SCD) the process related values (e.g., scale) SHALL be fixed, these values must be set and declared as fixed. It is not allowed by an IED tool nor online to change these (fixed) values: Here are the corresponding attribute settings (valKind=RO AND valImport=false).

We have to be careful with rules (not defined in the standards) like the following:

If valKind=Set THEN valImport=true (if I can overwrite a value with a service, it makes sense to allow to configure a value at tool level; it may be useful for communication service related information of a control block, but not for process related information).

Be careful with the combinations of these two attributes … they are independent of each other. And: Not all tools may understand the philosophy below.

SCL Schema Accessibility in the near future

The SCL schema is published as part of the delivery of edition 1 and edition 2 of part 6. The publication of a Technical Corrigendum to IEC 61850-6 Ed. 1 and Ed. 2 is under way.

To provide an easier way to retrieve the latest version of the Schema a new possibility to access the Schema from the IEC Website is proposed in the document (57/1604/DC): Latest version of SCL schema and planned publication of a Technical Corrigendum to IEC 61850-6 Ed. 1 and Ed. 2.

This process is already proposed for the first corrigenda of part 6 and from Edition 2.1 onwards.

Please note: Currently the following valid schema files are currently used for conformance testing of IEC 61850:

- For Edition 1 of IEC 61850-6: SCL 1.7
- For Edition 2 of IEC 61850-6: SCL.2007B

Protection and Control with IEC 61850 – Very Successful Training in Prague (CZ)

Two crucial application domains for IEC 61850 are the Power Protection and Power Control – no doubt. What does this mean for the electrical engineers responsible for the reliability of the Power System? A lot!

The first 3 days joint Seminar of FMTP Power and NettedAutomation in Prague, CZ, (8-10 December 2014) was very successful. The Training was held in the Holiday Inn (Congress).

 

The 3 days were split between presentations and demonstrations of general IEC 61850 issues and special protection issues. The main topics were centered around the impact of IEC 61850 on the protection. Andrea Bonetti (FMTP) used several test tools from ABB and Megger, as well as an ABB protection relay (REL 670):

Andrea is one of the developers of the ABB series 670 and the Megger GOOSER. He really knows what he is talking about – when it comes to protection.

The attendees were absolute happy with the many lessons learned during the three days fully packed with experience. Note that Andrea has spent some time of his life in substations – many days and nights … listen to him next time:

Ecuador, Jan 26-29, 2015
Brussels, Feb 16-18, 2015
China, March 9-11, 2015
Bratislava, Apr 20-22, 2015
Berlin, May 18-20, 2015

Additional courses are in preparation.

What does IEC 61850 mean for Power Systems?

A lot. There are many different approaches to describe the benefits. You can start with the System Specification Description (SSD according to part IEC 61850-6, SCL) and go down to the signals and communication. Or you can describe it bottom-up. I like the bottom-up approach:

1. Take a signal (e.g. Voltage phase A in kV) coming trough a serial Modbus (Address 12122) by polling into an IEC 61850 Server device
2. Give it a NAME (MyMMXU1.PhV.phsA) based on a STANDARDIZED Structure (Logical Node MMXU), and
3. Use the protocol (MMS, ISO 9506) to just poll the current value with a MMS Read.

We may have 10 bays with each providing the voltage phase A: then we could model this as follows:
Bay1MMXU1.PhV.phsA
Bay2MMXU1.PhV.phsA
Bay3MMXU1.PhV.phsA
...
Bay10MMXU1.PhV.phsA

That's some basic benefit ... for a first “"brief introduction”.

In addition (there are many other features to look at), e.g.:

1. MMS allows to retrieve the Signal List (device model comprising all logical nodes ...) ...
2. The system configuration language (SCL) allows to carry the "signal list" in form of an XML file ...
3. SCL could carry the complete signal flow between any device in a system: who has which signal to offer, who needs which signal, how are signals carried between the many devices (real-time, non-realtime ...) ...
4. SCL could carry the single line diagram (topology) of an electrical system ...
5. SCL could carry how the information is related to the single line diagram ...
6. …

So, does IEC 61850 add to the complexity of power systems? No that much! See also:

http://blog.iec61850.com/2014/10/does-iec-61850-add-complexity-for.html

Be aware: There is more than IEC 61850 that has to be learned, understood and managed!

IEC 61850 ICD Designer update available

A new update of SystemCorp’s IEC 61850 ICD Designer is available for download: Version 2.00.011

Upgrade / installation:
http://licenses.systemcorp.com.au/downloads/ICDDesignerSetupV2.00.011.exe

Standalone version:
http://licenses.systemcorp.com.au/downloads/ICDDesignerStandaloneV2.00.011.zip

This is the same version available on the SystemCorp website “Demo”. All versions will operate as a demo if the dongle is missing. The demo version becomes the full version when a dongle is present.

The latest documentation is Revision 2.01 (contained in the above uploads):

The latest ICD Designer offers several new features – worth to test.

How to Generate IEC 61850 IED Models?

IEC 61850-6 (SCL – System Configuration Language) supports the design, engineering and configuration of systems … systems composed of many IEDs (Intelligent Electronic Devices). One key question is: How can I define a model of an IED?

Big vendors like ABB, GE, Siemens, … have their own vendor-specific tools. What’s about third-party tools? Or even freely available tools?

The following tools may be used for free (with some restrictions):

IEDmodeler from RedWind:

IED Modeler is a tool free for use as long as you have an access to the internet and accept their license … The program is free of charge for non-profit purposes including teaching and research at universities, colleges and other educational institutions, research at non-profit research institutions, and personal non-profit purposes.

Click HERE for more information.

ICD Designer from SystemCorp:

The ICD Designer can be used to model IEDs according to Edition 1 and Edition 2 of the core parts of IEC 61850. In addition to modeling IEDs it can be used to bind Models to real applications: bind the “XCBR2.Pos.stVal” to a specific memory location or to a Modbus Coil:

The “Pos.stVal” can be bound to a Modbus Slave:

This binding allows automatic configuration of the IEC 61850 Stack/API and binding to the corresponding Modbus device at address 321.

Other bindings are supported: DNP3, IEC 60870-5-104, …

The ICD Designer can be used to simplify the application of the SystemCorp IEC 61850 Stack/API.

Click HERE for more information on the ICD Designer. The ICD Designer can – of course – also be used for creating CID Files.

Security for XML based System and Device Configuration Information

Discussion on the protection of configuration information can be found HERE (just one blog post down). Please note that IEC TC 57 is working on a new part for series IEC 62351 (Data and communications security):

IEC 62351-11 Ed.1:
Power systems management and associated information exchange - Data and communications security – Part 11: Security for XML Files

The key objectives of this proposal are:

• Provide a mechanism to authenticate the source of the file.
• Provide a mechanism for tamper detection.
• Provide these security mechanisms in a manner that maintains as much compatibility with the current CIM, SCL, and other XML formats as possible.
• Provide a mechanism so that a source of data can identify what data may or may not be made available to other entities in addition to the initial receiving entity.

It is crucial for the whole industry to support these kinds of standardization projects. The user communities have to pay anyway: now or later.

We have that many good standards and draft material that should be implemented soon to make sure that we can keep control over a wide range of infrastructures.

Click HERE to download an White Paper on Security Standards in IEC TC57 written by Frances Cleveland, WG 15 Convenor [pdf].

What are the Benefits of IEC 61850?

The question “What are the benefits of IEC 61850” has different flavors and multiple answers – it depends on what are you looking for. If you are looking just at the communication protocol, there are answers like:

1. The client/server protocol (MMS) is a unified solution standardized some 25 years ago. It is a stable standard – unlikely to change in the future and accepted all over for many years.
2. The GOOSE messaging is very unique and provides real-time information exchange in the msec range – accepted all over
3. The Sampled Values messaging provides a unique solution for exchanging samples of currents, voltages, vibration measurements accepted all over.

If you are looking at the information models, there are really many crucial models defined and in use. No other standard (I am aware of) has such a rich set of information models that expose process information in a standardized way – all over accepted.

There is – of course – the crucial issue on the configuration language. In this post we will discuss the benefit of a unified model that allows to hide the different vendor-specific signal lists for Modbus communication in two different power quality meters. In the end, the unification of specific information profiles (or subsets) for, e.g., the electrical measurements makes IEC 61850 different compared to any other solution I know.

The power quality monitors used are: Janitza UMG 604 and Acuvim II. Both meters provide many measurements of the electrical system. The signals can be communicated by Modbus. Usually each vendor has a different approach to define the lists of signals – and especially the indexes used for the vary same signal is quite different and have to be mapped manually to any application – again and again. There is no way to agree on a single unified Modbus signal list that can be applied all over. The next figure shows the two devices, their signal “phase voltage” with different identifiers and indexes.

The unification of the information model is implemented in a simple gateway (com.tom BASIC 5.1). The gateway is based on a WEB-PLC that maps the incoming Modbus signals to IEC 61850 models. The IEC 61850 model uses the same logical node class and type. The type MMXU_0 is the subset of the MMXU class used in this application (of four data objects – as can be seen in the icd file). The instance MMXU1 can easily be “copied” to build a second instance: for the Acuvim II meter. Both instances use a unique MMXU logical node type (contained in the icd file). The model can be used to configure the IEC 61850 server device and an IEC 61850 client (in this case the IEDScout) as shown in the next figure.

The gateway solution is reasonable in case just a limited number of applications need the information communicated by IEC 61850.  The next step could be to integrate the “gateway” into the meter housing, as shown in the next figure:

The “heart” of the gateway (we use) is the Beck IPC@CHIP controller that could be applied as a subsystem in the meter. It manages the complete IEC 61850, IEC 61400-25, IEC 60870-5-104 or DNP3 communication.

The IEC 61850 models are the same as before in the case of using a separate gateway box. From a client point of view there is only one difference: there are two IP addresses and two IED names to take into account.

The configuration of the client could benefit from the unified information model contained in a standardized machine readable format (.icd). When you google for power meters with a Modbus interface (or any other fieldbus-like) interface you will get as many different signal list as solutions. In our case we can easily unify the information that comes from many different meters.

By the way, the unified model can be fed not only by a Modbus communication interface. Any other signal list communicated by the myriad of solutions could easily be unified! It does not matter how many different protocols you have to take into account – the very same IEC 61850 profile could serve them all. Define it once and use it for ever and all over.

The WEB-PLC based solution explained here is available – I have tested the concept with several devices: meters, monitoring devices, control devices. This approach could be applied right away – and you pay while you go. To get started with a extra box is in the range of some hundred Euro plus some time to understand the approach and learn how to get started with the product. The IPC@CHIP including IEC 61850 client and server (GOOSE and SMV), IEC 60870-5-104 server, and Modbus client costs less than 100 Euro – too cheap to ignore.

Let people define new protocols and … IEC 61850 can unify them all! The next days I will post a report on a hierarchical system with a Janitza UMG 604 and fan heater as the process, a com.tom device to monitor and control the process (with an IEC 61850 server), an a com.tom on top that could be used as a (proxy) gateway to the underlying com.tom (providing an IEC 61850 client, IEC 60870-5-104 server and an IEC 61850 server). The gateway interoperates in a plug&play manner with the underlying IEC 61850 IEDs.

I don’t fear the following situation:

nor this …

It is a change for IEC 61850 to unify the proliferation!

More to come shortly – stay tuned to this blog.

I had to wait almost 30 years to have a real simple and easy to use “MAP” solution running on my desk:

The MAP/TOP Demonstration in 1986 was too early! Definitely!

IEC 61850/IEC 61499 Based Engineering

You may remember the papers on the use of IEC 61850 in conjunction with IEC 61499 published a few years ago:

http://blog.iec61850.com/2012/09/ieee-award-for-paper-on-standards-based.html

Since then a couple of papers on the subject have been published. One of the latest has been published today:

G. Zhabelova, C.-W. Yang, V. Vyatkin , “SysGrid: IEC 61850 and IEC 61499 based engineering process for Smart Grid system design”, IEEE Conference on Industrial Informatics (INDIN’13), Bochum, July 29-31, 2013

Abstract — The paper proposes a novel computer-aided model-based system engineering process for Smart Gird applications. The process is supported by the SysGrid tool that plays the roles of system configurator and device configurator.
The design process starts with single line diagrams which are automatically transformed to executable function block specifications. The process is based on the Smart Grid control architecture that is a heterogeneous network of controllers communicating in a peer to peer manner. This “artificial nervous system” of the Smart Grid will be capable of self-healing and dynamic adaptation to renewable generation and ever-changing loads. The tool supports system-level design of automation logic in the form of function block networks with compliancy to IEC 61499. The capabilities of SysGrid are demonstrated through the process of designing a distributed protection application.

Click HERE to download the full paper.

Is IEC 61850 still there?

A very interesting discussion was started by a retired substation protection and automation engineer from one of the big German transmission operators. The engineer stopped at the boot 45/1 (hall 13) at the Hannover Messe last week. He saw the letters “IEC 61850” (see photo) and asked me: “Is IEC 61850 still around?”

He thought that IEC 61850 was just a hype some 10 years ago. His expectation was that IEC61850 is far to complex and expensive … and disappeared before it really hit the market. One of his babies was a very well know IEC 60870-5-101 profile for substation automation. In this profile you will find a nice “information model” of substations:

Ok, that is what many (not only retired) engineers guess. I helped him to understand the current situation of the big success of IEC 61850 all over.

Then I showed him an embedded Controller IED (Beck com.tom) that integrates IEC 61850 AND IEC 610870-5-104 (running separate or both at the same time):

This small box runs both … and it’s really affordable.

Then I showed him the requirement specification of Vattenfall’s VHP Ready that specifies both: IEC 60870-5-104 and IEC 61850:

There is almost no difference between the implementation of the information and services in both worlds. The difference is just, that IEC 61850 has standard models, a configuration language, GOOSE, SMV, and self-description. The price of a com.tom with 104 or 61850 is (I guess) the same.

Finally he said: “I am a consultant to a manufacturer of substation automation and protection systems; I have to tell them this story! They will like it – because they have already enquiries for IEC 61850 conformant IEDs.”

There is a need to educate more engineers to understand the situation!