IEC 61850 - What does Free allocation of the Logical Nodes mean?

Often people ask the question: Where should I allocate a specific function (and the corresponding Logical Node) in the hierarchy of: process, bay, substation, regional control center, central control center? 

In the following you will find some description from the Standard IEC 61850-5, a paper from 2001, a question I received the other day, my own brief answer to that question, and two answers from two good friends: Andrea Bonetti (Megger) and Joachim Lange (Solvay).

IEC 61850-5 (Communication requirements for functions and device models; Ed 2022) describes that the allocation is free to allow different architectures and levels were a function (respective a corresponding LN) can be allocated (means implemented).

Excerpt of Clause 9.2.1 Free allocation of Logical Nodes

"The free (arbitrary) allocation of functions or Logical Nodes respectively is not restricted to the common level structure."

The following excerpt of clause 10.1 Need for a formal system description is one of the crucial clauses in the whole standard series IEC 61850:

"Where the data is coming from (sending Logical Node) and is going to (receiving Logical Node), i.e. the static structure of the communication system, has to be engineered or negotiated during the set-up phase of the system. All functions in the IEDs have to know what data to send when and what data they need from functions in other IEDs to be able to fulfill their functions. To control the free allocation of functions respectively Logical Nodes and to create interoperable systems, a strong formal device and system description for communication engineering shall be provided. Such a description (System Configuration description Language) is defined in Part 6 of this standard (IEC 61850-6). This formal description shall also support the data exchange between different tools if applicable."

Be aware that the Logical Nodes are to be understood as a wrapper around a function. In most cases the function as such is behind the facade of the Logical Node. One exception is the Logical Node class FSCH (Schedule). The definition of FSCH contains a well defined state machine that is part of the function of a scheduler.

An old paper from the year 2001 may help you to understand the approach of IEC 61850

The Impact of the coming Standard IEC61850 on the Life-cycle of Open Communication Systems in Substations

By Lars Andersson, Klaus-Peter Brand, Wolfgang Wimmer; ABB Power Automation Ltd., Switzerland

Excerpt from the paper:

1. Free allocation of functions [KHS: and therefore free allocation of Logical Nodes]
2. Extension rules to support new functionality
3. Separation of communication from application issues in a well defined manner
4. Description of the station from the application communication point of view.

Click HERE for the paper published in the year 2001.

Question:

Hi Karlheinz,
I’m a system engineer with a question on IEC 61850 in substation automation.
In a ring with all IEDs and two RTUs, are the RTUs only SCADA gateways, or can they also host SAS control logic (e.g., with a T500’s basic logic capability)?
Should a SAS operate autonomously from SCADA or higher-level PLCs, and if so, should the IEC 61850 RTUs implement control logic for outage restoration, load shedding, etc., to ensure autonomy?

Answer from Karlheinz Schwarz

Dear xx,
Thanks for contacting me.
IEC 61850 is independent from centralized or decentralized approach. It depends on the philosophy of the utility how to architect the system. Functions could be in the multi-functional IED (Relay), bay controller, substation controller, SCADA, control center, ...
IEC 61850 may be used to run schedules in control IED right behind the electrical connecting point of a home, factory, ... using the LN FSCH - Scheduling.
In Germany we have the so-called FNN Steuerbox that uses schedules for limiting the power usage ...
Hope that helps.

Answer from Andrea Bonetti

IEC 61850 does not prescribe where control logic must be located (read it as the famous sentence "free allocation of the Logical Nodes").
The decision is up to the system designer and the utility’s operational requirements. If autonomy of the HV ring is desired, logic may be placed in RTUs, bay controllers, or other IEDs so that the system operates without SCADA. Any such requirement would come from utility or regulatory specifications, not from the IEC 61850 standard.

There is no IEC 61850 requirement that mandates where control logic must be located — whether in RTUs, IEDs, or higher-level systems.
IEC 61850 specifies how devices exchange information and how to engineer all of that (SCL engineering), not where the logic resides.
Whether the HV ring is autonomous is purely a system design choice defined by the utility’s operational philosophy, national regulations, or internal standards — not by IEC 61850 itself.
If autonomy is required (e.g., for outage restoration or load shedding without SCADA), the designer can choose to implement logic in RTUs, bay controllers, or other IEDs so they can function without higher-level supervision.
Obviously it depends also on the voltage level. Usually, higher voltage level –> less integration. Lower voltage level à more integration.
But there are exceptions to this rule like always.

Answer from Joachim Lange

In case of classical terminals, neither the terminal number nor the terminal function is defined in any standard. Personally, in case of CFC implication I use UDx baycontrol blocks, defining „my signals“ and a group with the  "GOOSE exchange" signals
- in case of blocking signals like in double busbar structures I do this as well, because I use busbar selective reverse blocking in dependance of position information,
- this means that disconnector positions enables/disables the blocking transmission to its circuit breaker protection.
It is even useful to avoid that a send out blocking signals triggers during test a not involved feeder.
Some grid companies use f.e. blocking signal in combination with breaker failure. This means when signal is not reset in time they trigger the breaker failure protection.
So the CFC function is really case wise.
We have in our house in the UD1 group all signals which are used for bay supervision.
Philosophy: I decentralise load shedding and automation functions into the bay control level ( discrete frequency / voltage levels with hysteresis).
Such bay controller measures autonomously its conditions.
I provide from above (Scada) the enabling/ disabling signals or mode selections ( power level ) or setpoint correction signals.
The advantage is that a single device failure may not impact a hole system.

Note that Andrea Bonetti (Megger), Joachim Lange (Solvay), Dr. Ghada Elbez (KIT), and I will conduct a comprehensive training starting 09.-13. March 2026 Karlsruhe (Germany) and 21.-25. September 2026 Karlsruhe (Germany).
We will provide the details in the next weeks. Stay tuned.

Here are the logos for that training:

IEC 61850 Is Very Crucial For Semantic Models And Interoperability

IEC 61850 provides a huge number of generic and specific semantic models ... Logical Nodes, Data Objects, Common Data Classes, Instance-Information, Topology Information, Information Exchange, Communication, Protocols, ...

Can you please show me an easy to understand example! Here you are!

The following figure shows how (meta) model information is added to a simple voltage measurement (right upper corner). The value is wrapped with a data object model comprising with many attributes like instCVal.mag.i or units ...
The logical device and and logical node instance information is added next. Finally the semantic of the information exchange (report model) is applied to the value - sure, there is a data set involved as well (not shown here).
All this information (general and specific (instance) semantic) could be described in an SCL document (using an XML based SCL schema). Note that some configuration information, e.g., engineering unit (kV), may be contained in the SCL document only. The device needs to process implicitly the voltage in kV. A device may allow to use the SCL document to configure the device to expose the voltage in V ... or mV ... A client (SCADA or ...) may read out the model at runtime (including the engineering unit, if that is implemented as a model attribute) or may just read locally the SCL document and get the engineering unit from the file. Note: the SCL document is the main document for the models and configuration ... keep it safe!! And check the online read model against the SCL file from time to time to compare the two in order to figure out any change!


Further in our example we have a simple bay topology with electrical equipment like generator, switch gears, voltage and current sensors. This topology could be engineered and documented with the SCL (System Configuration Language) - an XML schema for a whole system. The equipment is assigned to specific information models (MMXU.PhV.phsA. ...).
The system engineering could be managed, e.g., with the Helinks STS Tool. An easy to use tool.
The generic Information Model, e.g., MMXU (defined in IEC 61850-7-4) is concatenated with the application designation (MyGenSets/Gen11).


The various levels of semantics of the Message elements are:

1. Model Instance: Hierarchical Identification of the specific Model of Semantics (in SCL) 
2. Message Elements: Service Type, Identification, Value, Quality, and Timestamp (ACSI - Abstract Services)
3. Message Instance: Service Type, Instance of Identification, of Value, of Quality, and of Timestamp (Report)
4. Message semantic (ACSI mapped to MMS)

The modeling approach of IEC 61850 could be applied in most automation domains ... especially when electric power is applied.

Let me know please if there is a similar standard model defined for automation systems that may compete with IEC 61850 and IEC 61400-25. 

How Many and Which Information Models are defined in IEC 61850?

I guess you have heard that IEC 61850 defines a lot of Information Models. Yes, You are right.

The models are managed exclusively by the corresponding working groups with the Enterprise Architect UML Tool (the UML data base is for internal use only). The model version:

UML model of 61850 (wg10built6-wg18built3-wg17built5-jwg25built2-tc17built1-tc38built1.eap)

comprises the following number of Logical Node Classes, Data Objects (Attributes), Enumerations and Abbreviations:



An excerpt from the UML modes looks like this:



The UML Model is the single source data base that is used for the extensions and maintenance of the model, as well as the generation of Word or PDF documents ... The PDF documents are sold by IEC and other organizations.

You may complain that the standards are not for free ... hmm ... BUT look: You can download the various Code Components for free.

Click HERE for the Code Component for IEC_61850-7-4.NSD.2007A2.light.zip (IEC 61850-7-4 2007A2 NSD light, see the IEC 61850-7-4:2010 for full legal notices). The full version has additionally the semantic descriptions of the models.

Example of Enumeration:


Example of excerpt of LN Class MMU:



Click HERE to see the list of all Code Components as per today ... more to come soon.

To my understanding you can model many required information generated and consumed by a huge number of applications in almost all application domains of automation in the electrical system and beyond.

As the above example of MMXU shows, you can use this LN Class wherever you have 3 phase AC system!! In a building heating system for the electrical values of a compressor or a fan or a pump or ... the blue sky is the limit for the applications.

Click HERE to learn about crucial details discussing the LN Class MMXU and how it can be applied ... you may have never expected this comprehensiveness of the MMXU.

Note that the 3 phase system was first (more than 100 years ago) - then we have put a facade in front of the measurement function which exposes the measurements as data objects of the class MMXU. The application has driven the class - not vice versa.

The current edition 2.1 models defined in IEC 61850-7-3 and 7-3 are listed in the contents tables of the preview documents. The following Preview documents (free access) for models of the edition 2.1 consolidated versions are available:

Preview IEC 61850-7-3 Edition 2.1
Preview IEC 61850-7-4 Edition 2.1

Example of 7-4 from the preview:



In case you find any error in the standards, please visit the Tissue Database:
https://iec61850.tissue-db.com/parts.mspx

IEC Draft TR 61850-90-9 - "IEC 61850 for Electrical Energy Storage Systems" Published

IEC TC 57 just published the 138 page IEC Draft TR 61850-90-9

IEC 61850 for Electrical Energy Storage Systems

57/2128/DTR
Voting closes 2019-09-27

This is one of the next crucial extensions for DER-Models of IEC 61850-7-420. This TR will be merged into the 7-420 later on.

The Introduction states: " ...This technical report is primarily based on the recommendation 5.7.4. “interface, control and standard data elements”, of the IEC white paper ”Electrical Energy Storage” published in December 2011 by the MSB. The recommendation proposes the necessity of a standardization of interfaces between storage and other grid elements, protocols for data exchange and control rules, and data elements for input, output and control information supplied by or to storage systems. ..."

Click HERE for the mentioned IEC White Paper.

"This technical report describes IEC 61850 information model for electrical energy storage systems (EESS). Therefore the report only focuses on storage functionality in the purpose of grid integration of such systems at the DER unit level. Higher level Interactions are already covered in IEC 61850-7-420. ... "

The draft defines more than 150 new Data Objects. Excerpt of the first 15 Data Objects:



The blue marked text refers to the Logical Node from which this Data Object is inherited.

This document refers to the standards IEC 61850-7-x and defines additional very crucial information for the configuration, control, monitoring of a battery system.
It is very crucial for the success of the DER models to get implementation and application experience with these very comprehensive and complex models.
Taking into account that the mentioned White Paper was already published in 2011, we learn a crucial lesson: It took a lot of time to get where we are today. And it will take years to get these definitions implemented and used in the power delivery systems. In the mean time you need to tap the experience of engineers that understand the possible use-cases that can harvest the benefits of applying these standards.

Draft TR IEC 61850-90-6 for Distribution Automation Published

IEC TC 57 WG 17 just published the 277 page (!) draft TR 57/1929/DTR:

IEC 61850-90-6: Use of IEC 61850 for Distribution Automation Systems

Commenting period and ballot closes 2017-12-01.

This technical report provides basic aspects that need to be considered when using IEC 61850 for information exchange between systems and components within MV network automation. In particular, the report:

• Defines use cases for typical DA applications that require information exchange between two or more components/systems
• Provides modelling of components commonly used in DA applications
• Proposes new logical nodes and the extensions to the existing logical nodes that can be used in typical DA applications.
• Provides guidelines for the communication architecture and services to be used in DA applications
• Provides configuration methods for IEDs to be used in DA systems.

Basic function for which models will be selected or defined cover:

• Fault Passage Indication and report
• FLISR (Fault Location, Isolation and Service Restoration)
• VVC (Voltage and Var Control)
• Anti-Islanding Protection Based on Communications
• Automatic Switch Transfer
• Monitoring Energy Flow
• Environment Situation Awareness

A Distribution Automation System (DAS) can have up to tens of thousands of IEDs spreading
over a wide area distribution network.

Multiple new Logical Node Classes and extensions for existing LNs are proposed:



This draft is very detailed and easy to read.

IEC 61850: Usage of XML Schemata for Model Name Space Definitions

One of the crucial challenges in dealing with IEC 61850 is the sheer unlimited amount of Models (Logical Nodes, Data Objects, Data Attributes, Data Attribute Types, ... and related Services). How to manage these? How to figure out which model was valid last year, which model details are currently valid, ... questions, questions ...
What are the answers to these questions? Simply: good documentation of content, modifications, extensions, and changes.
The IEC TC 57 WG 10 has published a document that defines the rules for model content of IEC 61850 based core data model in IEC 61850-7-2, IEC 61850-7-3 and IEC 61850-7-4. Other domains (like DER, Hydro, Wind, etc.) could define their own data model based on IEC 61850 core data model to be able to use IEC 61850 core parts as a common layer.

The published 70 page document 57/1925/DTS contains the new draft rules:

Communication networks and systems for power utility automation –
Part 7-7: Basic communication structure –
Machine-processable format of IEC 61850-related data models for tools

The voting and commenting period closes 2017-12-15

"Year after year the IEC 61850 data models are extended both in depth with hundreds of new data items, and in width with tens of new parts.
In order to foster an active tool market with good quality, and at the end to improve IEC 61850 interoperability, we need a machine-processable file describing data model related parts of the standard as input. This is the purpose the new language Name Space Definition (NSD) defined by this part of IEC 61850.
This will avoid the need for any engineering tool related to the IEC 61850 data models to get the content of the standard manually entered, with the highest risk of mistakes. This will also help spreading easily any corrections to the data model, as requested to reach interoperability. Tool vendors will be able to integrate NSD in their tools to distribute the standard data models directly to end users."

This new document seems to be crucial for all experts that deal with models and their implementation in Tools and IEDs.

IEC 61850 Logical Node Group Designation

IEC 61850 uses a well defined designation of Logical Node Groups like MMXU for 3phase electrical measurements. The following groups are defined:

A   Automatic control
C   Supervisory control
D   DER (Distributed Energy Resources)
F   Functional blocks
G   Generic function references
H   Hydro power
I    Interfacing and archiving
K   Mechanical and non-electrical primary equipment
L    System logical nodes
M   Metering and measurement
P    Protection functions
Q    Power quality events detection related
R    Protection related functions
S    Supervision and monitoring
T    Instrument transformer and sensors
W   Wind power
X    Switchgear
Y    Power transformer and related functions
Z    Further (power system) equipment

A total of several hundred of Logical Nodes are already defined and published.

What is a Function in IEC 61850?

The term "Function" is used in a variety of flavors throughout the standard series IEC 61850. If you ask five experts, you may get six answers.
IEC TC 57 has proposed (57/1863/DC) to develop a new Technical report IEC 61850-6-100: "SCL Function Modelling for Substation Automation"
A "function" is more or less a synonym for operation or action ... as described in Wikipedia:
"A function model or functional model in systems engineering and software engineering is a structured representation of the functions (activities, actions, processes, operations) within the modeled system or subject area."
In my seminars I compare IEC 61850 with Logistics:



IEC 61850 defines simple and more and more complex functions. A schedule according to IEC 61850-90-10 defines a set of quite complex (or comprehensive) functions. In most cases the functions defined by IEC 61850 are just functional components that are used as bricks to build a comprehensive application function.
The brick-concept of IEEE 1550 (UCA 2.0) indicated the use of the standard models: the Bricks (which are now the Logical Nodes in IEC 61850).
IEC 61850-7-2 Services define functions (called services) that provide information logistics, e.g., for accessing the device information model, allow exchange of any value made available by a device based on events for real-time and non-real-time applications, or services for controlling a controllable item like a circuit breaker or a fan.
Functions may be composed using the standard IEC 61499 (Function blocks) as described in the following papers:
V. Vyatkin, G. Zhabelova, N. Higgins, K. Schwarz, and N.-K. C. Nair, Towards intelligent smart grid devices with IEC 61850 interoperability and IEC 61499 open control architecture, IEEE Conference on Transmission and Distribution, New Orleans, April, 2010
 N. Higgins, V. Vyatkin, N. Nair and K. Schwarz, “Intelligent Decentralised Power Distribution Automation with IEC 61850, IEC 61499 and Holonic Control“,IEEE Transactions on Systems, Machine and Cybernetics, Part C, 40(3), 2010,
J. Xu, C.-W.Yang, V. Vyatkin, S. Berber, Towards Implementation of IEC61850 GOOSE Messaging in IEC61499 Environment, IEEE Conference on Industrial Informatics (INDIN’13), Bochum, July 29-31, 2013
Click HERE for more papers.
More to come ... stay tuned to this blog!

How to use Generic Input/Output Logical Node "GGIO"

The Logical Node Class GGIO (Generic Process I/O) is (in my experience) the most liked and hated Logical Node. Why? GGIO is often used instead of well known Logical Nodes.
Example: Use of GGIO0.ST.Ind1.stVal instead of XCBR0.ST.Pos.stVal
The use of GGIO is not standardized!
You may use it or not ... one way or the other.
Last week I was contacted by an utility engineer on how to map reporting signals (M1-Boolean, M2-Boolean, M3- ...)?
There are two general approaches in the use of GGIO:

1. Add semantic to Prefix of LN and use many GGIO instances (M1_GGIO1, ...)
2. Add semantic to extended Data Objects in GGIO (M1, ...)


In the first case we instantiate GGIO 10 times.
In the second we extend the model by defining Data Objects M1 ... M10

The main difference is that in the second example we can use the prefix of the GGIO ("Report_") -> "Report_GGIO0" as a wrapper for Reporting. The semantic of the signals is further defined by extended Data Objects "M1", "M2", ...
Both modelling approaches are defined in IEC 61850-7-1 and 7-4. The second approach may not be supported by all tools and devices.
I personally would prefer the second approach.

IEC is about to prepare the "Use of IEC 61850 for electrical energy storage systems"

IEC TC 57 has just sent a 75+ pages draft document for comments by the national committees:

Draft IEC TR 61850-90-9 – Communication networks and systems for power utility automation – Part 90-9: Use of IEC 61850 for electrical energy storage systems

See: 57/1715/DC

The document is a very comprehensive document that provides a list of use-cases and solutions on how to use and extend the IEC 61850 models for electrical energy storage systems.

The



It is recommended for the various stakeholders to get more deeply involved into the further steps to get a standard information model for electrical storage systems!!

Sample use-case:



This document fits well into the set of drafts that are needed for power distribution systems.

More to come!

IEC CDV 61850-7-4 Ed.2.0 Amendment 1 just pulished

IEC TC 57 has just published a 269 page CDV that reflects the first amendment to IEC 61850-7-4 Ed.2.0:

IEC 61850-7-4 Ed.2.0 Amd.1: Communication networks and systems for power utility automation –
Part 7-4: Basic communication structure – Compatible logical node classes and data object classes

Everybody can read the CDV and comment online (see details below).

The commenting period closes 2016-04-15.

Compared to the second edition, this first revision of the second edition:

• Provides clarifications and corrections to the second edition of IEC 61850-7-4, based on the tissues = { 650, 671, 672, 674, 675, 676, 677, 679, 680, 682, 683, 685, 686, 689, 693, 694, 695, 696, 712, 713, 714, 715, 716, 722, 724, 725, 726, 727, 732, 734, 735, 736, 742, 743, 744, 748, 749, 772, 773, 774, 775, 776, 800, 802, 808, 819, 830, 831, 835, 838, 842, 843, 844, 849, 871, 877, 878, 879, 881, 882, 902, 908, 909, 910, 911, 912, 913, 920, 928, 932, 933, 937, 939, 940, 952, 967, 991, 1007, 1029, 1044, 1046, 1071, 1075, 1076, 1077, 1081, 1086, 1117, 1119, 1128, 1137, 1139, 1176, 1177, 1190, 1191, 1203, 1205, 1229, 1235, 1236, 1244, 1250, 1256, 1258, 1259, ... }
• Adds to each functional LN group a parent abstract Logical node where the functional nodes are children from (full object oriented model). Since all abstract LNs are in together in a common clause, the relative position of the functional LNs is not changed within their clause
• Adds new abbreviated terms
• Has extension of the list of abbreviate terms to be used for object names
• Has more precise combination rules for abbreviated terms to object names
• Has extensions by new logical nodes mainly from power quality domains and others
• Has corrections of editorial errors.

Please note that this CDV is available to the public for comments (yes: everybody can sign in and get access for personal comments!!):

Click HERE to register for public access and comments.

This allows everybody to ready the content and comment online.

Click HERE to visit the Tissue Database.

This CDV is the result of several years of key editors to reach a very high level of completeness and consistency of the information models throughout the various domains.

Note that the final result will be a new edition of 7-4: Edition 2.1 !! (not 3.0).

Congratulation to the editors for this great work!!

What is an IEC 61850 Data Model – Come and See

Data or device modeling is a crucial feature of IEC 61850 and IEC 61400-25. You may have seen many different approaches to explain how such a model looks like. Some five years ago I used these Russian dolls (matryoshka doll):

An IED contains a lot of “inner” objects.

 

Today I have thought that another approach may help you to understand the IEC 61850 approach:

What do you think? This and more will be explained in detail during my comprehensive – most liked – courses.

IEC 61850-90-8 Models for Electric Mobility

IEC TC 57 just published the 70+ page draft (57/1603/DTR) for comments:

IEC 61850-90-8 TR:
Communication networks and systems for power utility automation –
Part 90-8: Object model for electric mobility

Voting terminates on 2015-09-25

This technical report describes how current standardization for Electric Road Vehicles (EV) and the Vehicle-to-Grid Communication Interface can be linked to IEC 61850-7-420 standard for Distributed Energy Resources (DER). The technical report provides necessary background information and proposes an object model for E-mobility in order to establish an EV plugged into the power grid as DER according to the principles of IEC 61850-7-420. The basic information modeling in IEC 61850 and IEC 61850-7-420 already covers a lot of needs for the e-Mobility domain. Missing parts can be modeled as new logical nodes and data objects, which this technical report defines.

Scope
The scope of this document is to show how IEC 61850-7-420 can be used to model the essential parts of the E-mobility standards related to Electric Vehicles and Electric Vehicle Supply Equipments (IEC 62196, IEC 61851, IEC 15118) and the Power system (IEC 61850-7-420), in order to secure a high level of safety and interoperability.

Here is an overview about the topology of the logical nodes required (existing and new ones):

Standards are key for E-Mobility and many other power application domains.

Siemens reported using IEC 60870-5-104 for DEMS

Siemens DEMS 3.0 stands for third version of their “Decentralized Energy Management System”. It uses IEC 60870-5-104 for communication with power generators, storage devices or loads. The use of open communication and other solutions built-in reduce the engineering cost for virtual power plants by 60 percent – according to Siemens.

What could you do to apply the same cost reduction – or more – if you have to integrate IEDs that provide IEC 61850 information, information exchange and configuration language? Or how to connect a DEMS 3.0 system to IEC 61850?

Here is – I guess – the easiest and shortest time-to-market solution … without writing a single line of program code: The gateway using a so-called com.tom (communication to machine). The topology of an example is shown in the following figure. The gateway is implemented in the upper box.

All WEB PLC objects (inputs and outputs) related to IEC 61850 models are automatically generated from the corresponding SCL files. There is no need to do any manual configuration as long as you have the ICD files of the devices. The object names of the WEB PLC are derived from the object references of the IED/LD/LN.DO.DOA and so on. You see the path names in the I/O list.

All WEB PLC objects can be used to build applications like linking any input with any output (applying the same type – of course): single point input to single point output. The following diagram shows a simple gateway functionality to receive a command via IEC 60870-5-104, route it through an IEC 61850 client to an underlying IEC 61850 server that switches a fan on or off. The status of the FAN LN (using an extended Data Object OpSt) reports the status of the fan. This status is received from the underlying IED via an IEC 61850 report and routed to an IEC 61850 server and an IEC 60870-5-104 server in the gateway.

After “drawing” this diagram, all you need to do is to store the diagram to the gateway (com.tom Basic 3.1 S) and start the program. That’s it.

You may also have figured out the the com.tom Basic 3.1 S integrates an 5-port Ethernet Switch and another independent Ethernet port. This allows to build secure proxy servers/gateways.

The WEB PLC with IEC 60870-5-104, DNP3, Modbus, IEC 61850, … is a very easy, low cost and fast-to-market product that can be applied for many applications running on these communication solutions and for gateways. The application is freely configurable by drawing lines.

If you need complex functions, you can write them in C/C++ or IEC 61131-3 (CoDeSys) and wrap them for immediate use at the WEB PLC. For more complex applications you can program the application in C/C++ or CoDeSys and use the same communication.

Whatever protocol standard is used for a system (IEC 60870-5-104 for Siemens DEMS 3.0) you can easily integrate other devices that run DNP3, Modbus, IEC 61850, … with the com.tom WEB PLC gateway.

You want to learn more about the gateway, please contact us.

Click HERE for information about the com.tom family. The com.tom Basic 3.1, for example, costs 368 Euro plus some license costs for IEC 60870-5-104 and IEC 61850 – this includes already the 5-port Ethernet Switch!

Logical Nodes and Data Models for Steam and Gas Turbines

IEC has just published a committee draft (CD) with a proposal for new models to be used in steam and gas turbines:

57/1383/CD - AIEC 61850-7-410 A1:
Amendment 1 to IEC 61850-7-410: Communication networks and systems for power utility automation – Part 7-410: Basic communication structure – Hydroelectric power plants – Communication for monitoring and control

Comments could be provided until 2013-11-01

The draft contains the details of the following new logical nodes (with some 120 data objects):

EBCF	Block control function. This LN will represent one physical device that coordinates the control of the thermal pressure of the steam generator and the electrical power regulation of turbine / generator system
EFCV	Fuel control valve. This LN will represent the physical device of fuel control valve related to the gas turbine in a thermal power plant.
EGTU	Gas turbine production unit. This LN represents the physical device of the GT and the generator combination in a thermal power plant. It is intended as an extended rating plate that allows settings of data. It also acts as a placeholder for the current operating conditions of the unit.
ESCV	Steam control valve. This LN will represent the physical device of inlet control valve of the steam turbine in a thermal power plant.
ESPD	Speed monitoring. This LN is derived from HSPD
ESTU	Steam turbine production unit. This LN represents the physical device of the ST and the generator combination in a thermal power plant. It is intended as an extended rating plate that allows settings of data. It also acts as a placeholder for the current operating conditions of the unit.
EUNT	Thermal unit operating mode. The present status of the production unit
FDBF	Dead-band filter. This LN represents a settable filter for dead-band
FMTX	Trip matrix. This LN represents a matrix for linking various trip functions to equipment that shall be tripped or controlled during a fault.
GUNT	Production unit operating mode. The present status of the production unit
SECW	Supervision of electrical conductivity in water. This logical node represents a system for monitoring of electrical conductivity in water.
TECW	Measurement of electrical conductivity in water. This logical node represents a generic device for measuring the conductivity in water.

The LN Group E stands for “Enthalpy”; Enthalpy is a measure of the total energy of a thermodynamic system.

Another draft standard that “copies” IEC 61850 Logical Nodes

ISO/TC 205/WG 3 (Building Automation and Control System (BACS) Design) has published recently a new work proposal on power system information models [ISO/TC 205 / SC N 410].

Title: Facility Smart Grid Information Model

Purpose and justification of the proposal:
”The purpose of this standard is to define an abstract, object-oriented information model to enable appliances and control systems in homes, buildings, and industrial facilities to manage electrical loads and generation sources in response to communication with a “smart” electrical grid and to communicate information about those electrical loads to utility and other electrical service providers.

This proposed standard will define an information model intended to provide a basis for revision or creation of technology- specific communication protocol standards that enable products and services to control the operation of electrical energy generating and consuming devices found in homes, commercial buildings, institutional buildings, and in manufacturing and industrial facilities, in cooperation with energy providers in a "smart grid" environment.”

The new work item proposal states that “This proposal builds upon work done by IEC/TC 57 Power Systems Management and Associated Information Exchange … There is no known conflict with an existing IEC or ISO standard or project.”

There may be no conflict … the proposal (same as Draft standard BSR/ASHRAE 201P) “copies” Logical Nodes from IEC 61850 and modifies the Data Object names. For example:

Excerpt from Draft standard BSR/ASHRAE 201P:

5.7.3.3.1.5. DEROperationalModeControls

Operating mode at the ECP.
Control of the operational modes of the DER – constant watts, constant vars, …More than one mode can be set simultaneously for certain logical combinations (61850
Logical Node = DOPM).
Parent Class(es): CommonLN
UML element location: Model Elements from External Sources.IEC61850.61850-7-420. DEROperationalModeControls.

Table 5.193 - Class Attributes

Data Object	Description	CDC
OperationalModeConstantW	Mode of operation - constant watts.	SPC
OperationModeConstantPowerFactor	Mode of operation - constant power factor.	SPC
OperationModeConstantV	Mode of operation - constant voltage.	SPG

Excerpt from Standard IEC 61850-7-420 (LN DOPM):

Data Object	Description	CDC
OpModConW	Mode of operation – constant watts	SPC
OpModConPF	Mode of operation – constant power factor	SPC
OpModConV	Mode of operation – constant voltage	SPC

So, changing the names from abbreviated names to full text names makes it another standard information model … why? If other groups “copy” the Logical Nodes and Data Objects they should keep the names … Or?

I guess the main reason for this is:

Genesis 11:9 “Therefore, it is named Babel, because there the LORD mixed up the language of all the earth.” … languages spoken by humans and by computers!

List of almost all IEC 61850 Logical Nodes

A list of some 280 Logical Nodes from the following documents has been posted (see below):

• IEC 61850-7-4 Ed2
• IEC 61850-7-410 Ed1
• IEC 61850-7-420 Ed1
• IEC 61400-25-2 Ed1

Download the list of the 280 Logical Nodes [pdf; 314 KB].

You can see if the LN is new, extended (few, several, many extensions) or more or less unchanged.

You will find a lot of new LNs in IEC 61850-7-4 like the LGOS (GOOSE Subscription). The LN LGOS is defined for the monitoring of GOOSE messages:

Logical Node GOOSE Subscription LGOS:

DataObject	Semantic
NdsCom	Subscription needs commissioning
St	Status of the subscription
SimSt	Status showing that really Sim(ulation) messages are received and accepted
LastStNum	Last state number received
ConfRevNum	Expected configuration revision number Settings
GoCBRef	Reference to the subscribed GOOSE control block

NettedAutomation offers a comprehensive training on the Migration from the various Edition 2 parts of IEC 61850 that have been published so far.

How to define New Data Objects in IEC 61850?

The need to define new data objects is likely to have various reasons. One reason is that experts do not know which logical nodes and data objects are already defined. Let’s assume there is really a need for a new data object – there is not any data object that may fit.

Example (The following LN SIML, I found on the Web):

The standard LN SIML (Insulation Medium Supervision) provides the data object H2ppm (Measurement of Hydrogen (H2 in parts Per Million)):

There is a need to model H2ppm related semantic, e.g., “Hydrogen ppm Rate of Change” or “Hydrogen ppm Rate of Change Goodness of Fit”

These two semantic models are not defined in the standard. What is the best way to model these two?

1. Defining values in GGIO? – maybe not,
2. Defining new data objects in SIML? – may be the best solution (could be standardized later), or
3. Defining something like H2ppm1 (measured value), H2ppm2 (rate of change”, and H2ppm3 (roc Godness of Fit)? – That is definitely wrong!

Why are the following data objects in conflict with the standard modeling method?

Here is the definition for LN SIML (of the example I found) using multiple instances of H2ppm, defined in the Insulation Medium Supervision (Product Specification):

The standard IEC 61850-7-4 Edition 2 defines the LN as follows:

LN: SIML Name: Insulation Medium Supervision (Standard IEC 61850-7-4 Edition 2):

These data objects H2ppm1, H2ppm2, and H2ppm3 are not allowed – it is not allowed to instantiate data objects (with some exceptions, then the data object in the standard LN needs to be defined as MyDataObject1 – with a “1” at the end)!

For details on instantiating data objects see the following excerpt of IEC 61850-7-1 Edition 2 that defines the extension rule for data objects:

14.6 Specialisation of data by use of number extensions

Standardised data names in logical nodes provide a unique identification. If the same data (i.e. data with the same semantics) are needed several times as defined, additional data with number extensions shall be used. The rules for number extensions shall follow the naming conventions defined in IEC 61850-7-2 and be as follows:

• the number extension usage shall only be defined by the owner of the data namespace. This shall be done by adding the number extension 1 to a data object name (e.g. data1),
• data with no number extension shall not be extended by third parties,
• data with the number extension 1 can be extended. Number extensions may be ordered or not (1,2,3,4, or, 1,2,19,25),
• if only one instance of an extendable data is present in an LN, it shall have the number extension “1”.

14.8 Example for new Data

New Data “Colour of Transformer Oil”

The above figure shows also that a data Namespace Attribute “datNs” has to be specified for each new data object.

For the above listed additional semantic it would work with the following (standard conformant) extended data object definitions:

Example (wrong – semantic is in instances):
H2ppm1 (measured value)
H2ppm2 (rate of change)
H2ppm3 (roc Godness of Fit)

A standard conformant solution is (define new data object classes):
H2ppm (measured value)
H2ppmRoc (rate of change, extended data with datNs=Vendor so and so )
H2ppmRocGdns (roc Godness of Fit, extended data with datNs=Vendor so and so)

Please find further presentations on model extensions:
Click HERE for post1.
Click HERE for post2.

The Parts of IEC 61850 – Status 2011-06

The status (2011-07-15) of the various parts of IEC 61850 is as follows (blue means: Edition 2 of the corresponding document):

System Aspects

1 Introduction and Overview
2 Glossary
3 General Requirements (EMC, …)
4 System and Project Management
5 Comm. Requirements for Functions and Device Models (reaction time …)

Configuration

6 Configuration Language for electrical Substation IED’s (App., IEDs, System, …)

Abstract Communication Services

7-1 Principles and Models
7-2 Abstract Communication Services (ACSI)

Mapping to real Communication Networks (SCSM)

8-1 Mapping to MMS and ISO/IEC 8802-3
9-2 Sampled Values over ISO/IEC 8802-3

Testing

10 Conformance Testing
10-2 Interoperability test for hydro equipments based on IEC 61850

Data Models und usage of models

7-3 Common Data Classes
7-4 Compatible Logical Node and Data Classes
7-410 Hydroelectric power plants
7-420 Distributed energy resources (DER)
7-5 Usage of information models SAS
7-500 Use of LN to model functions (SAS)
7-510 Use of LN (hydro power plants)
7-520 Use of LN (DER)
7-10 Web-based access to the IEC 61850 models

Use-cases and network infrastructure

80-1 Guideline … CDC-based data model using IEC 60870-5-101 or IEC 60870-5-104

90-1 Using IEC 61850 for SS-SS communication
90-2 Using IEC 61850 for SS-CC communication
90-3 Using IEC 61850 for Condition Monitoring
90-4 Network Engineering Guidelines
90-5 Exchange of synchrophasor information
90-6 Use of IEC 61850 for Distribution Automation
90-7 Object Models for PV, Storage … inverters, …
90-8 Object Models for Electrical Transportation
90-9 Object Models for Batteries

The number of Information Models are:

7-3 Common Data Classes [40]
7-4 Compatible Logical Node / Data Classes [158 LN /982 DO]
7-410 Hydroelectric power plants [ 63/350]
7-420 Distributed energy resources (DER) [ 50/450]
90-3 Using IEC 61850 for Condition Monitoring [?]
90-5 Exchange of synchrophasor information [?]
90-6 Use of IEC 61850 for Distribution Automation [?]
90-7 Object Models for PV, Storage … (important!) [5/50]
90-8 Object Models for Electrical Transportation [?]
90-9 Object Models for Batteries [?]
61400-25-2 Wind Turbines [16/250]

SCADA Systems Benefit from IEC 61850 - Test it on your own

Survalent Technology (MISSISSAUGA, ON), reported the completion of the Princes' Islands IEC 61850 based SCADA system project for Ayedas Energy Distribution Company that serves more than 1.8 million customers on the Asian side of Istanbul (one of Turkey's largest utilities).

"The project was implemented using IEC 61850 protocol for electrical substation automation, and communicates with 47 SEL protection relays."

""Being able to run our SmartHMI software on the SEL 3354 platform allows customers to take advantage of the features of IEC 61850," states Bijana Dimitrievska, General Manager, Survalent Europe. "IEC 61850 allows protection and control functionality in the substation to be modeled into different logical nodes, and grouped under different logical devices. This saves considerable time in implementing new protection devices because you do not have to map device points to SCADA points as in the case of DNP protocol.""

Click HERE for the complete news release.

Click HERE for an example of a typical logical node (MMXU) for electrical characteristics (current, voltages, frequency, active power, ...).

Following you find a brief tutorial explaining why you could save "considerable time in implementing new devcies".

You can specify a typical LN MMXU type for your project and re-use this type in any protection or control device. A new protection device added in the future will provide the same model!! There is no need for new points mappings. The LN type could formally specified in an SCL DataTypeTemplate (IEC 61850-6).

Here is a special DataTypeTemplate (I just designed for this post) with phase voltages (PhV) and frequency (Hz) only: lnType="MyMMXU-Type_0" (see below):

The logical device "Measurements" uses one or more instances of this lnType:

<LN lnClass="MMXU" inst="1" prefix="" lnType="MyMMXU-Type_0"/>

representing MMXU1 (the first instance). The hierarchical model looks like this:

The same LnType can be used for devices from any vendor ... from a SCADA point of view all measurements (Hz and PhV) of all devices have the same structure and names. The values have to be mapped internally in the devices to the real data values of the devices' applications (encapsulated/hidden).

A SCADA system would need mainly to know the IP address. The LD names and LN instances could figured out by retrieving the self-description from the device. In our example the device would respond: I am a device that contains one LD "Measurements" with a LN "Measurements"; the LN has a DataObject "Hz" and a DataObject "PhV" with "phsA", "phsB" and "phsC".

Or the SACDA system just reads the SCL file to get the model. The SCL document of the model of the IED can be used to simulate this device ...

The IEC 61850 Evaluation Kit provided by SystemCorp could be used to easily implement this (or any other) model, create a server and a client running under Windows. And use the services: GetDaaObjecValues, Reporting, GOOSE ... It is just that easy.

If you want to expose emulated or real voltage values through IEC 61850 you have just to emulate them in your server application or bind them to real values you have on your PC. The application software of the kit comes in exe and source code ... you can start right away to get your data exposed in IEC 61850. For six months FREE evaluation. The kit has two clients (C and C#) and a server (C).

Click HERE for a link to download the evaluation kit. Enjoy!

Click HERE for a comprehensive set of slides on the IEC 61850 Evaluation Kit with step by step explanation on how to use the various tools [pdf, 2 MB]